Nerrvana в работе – настройка Jenkins для Selenium тестирования

Using Nerrvana - Jenkins setup for Selenium testing

Создание и настройка конфигурационного файла для плагина Nerrvana – запуск тестов – просмотр результатов тестирования

Part 1 – Nerrvana в работе – как это делается у нас
Part 2 – Nerrvana в работе – SVN втыкается в Jenkins
Part 3 – Nerrvana в работе – сборка приложения и Jenkins (часть 1)
Part 4 – Nerrvana в работе – сборка приложения и Jenkins (часть 2)
Part 5 – Nerrvana в работе – настройка Jenkins для Selenium тестирования – этот пост

В предыдущем посте мы автоматизировали процесс установки нашего приложения для тестирования. Сейчас Jenkins умеет реагировать на коммит, подготавливать и устанавливать наше приложение на deployment хосте. Мы также извлекли информацию о вновь закоммиченной ревизии приложения и сохранили её в файл version.txt.

Сегодня мы запустим тесты Selenium в Nerrvana с помощью плагина Jenkins. Плагин Nerrvana доступен на вкладке http://your_jenkins_instance/pluginManager/available. Не забудьте установить LFTP (yum install lftp) на том же сервере, где запущен Jenkins, так как он используется плагином для синхронизации тестов перед их запуском.

Рекомендуется запустить тесты из Nerrvana UI и проверить, что они выполняются без ошибок by Nerrvana. Процесс запуска тестов вручную описан на странице ‘Get Started‘.

Предположим, что тесты работают. Для того, чтобы создать конфигурационный файл для плагина Nerrvana, нужно зайти на страницу “Add new test run” или “Edit test run”. В секции, показанной ниже, выберите нужный Space (А), введите Test Run name (B) (постарайтесь не давать тест рану длинное имя, так как плaгин будет добавлять к имени номер Jenkins build и результат будет ещё длиннее), выберите executable file (C). Поле Description (D) рекомендуется оставить пустым и использовать возможность плагина добавлять в это поле информацию о коммите (созданный нами файл version.txt как раз используется для этого). Выберите интересующие вас платформы (E) и, если ваши тесты могут выполняться параллельно, – количество потоков на платформу (F). Теперь Nerrvana сможет создать конфигурационный файл (G), в котором вам нужно будет сделать лишь несколько изменений. Сохраните этот файл.

Generate Nerrvana Jenkins config in UI

В разделе ‘api-params’ находятся ключи доступа к Nerrvana API. Они подставляются автоматически при генерации файла. Вы можете изменить их на странице Settings, если в этом возникнет необходимость.

<api-params>
        <!-- Address of the Nerrvana gateway. -->
        <gateway>https://api.nerrvana.com</gateway>
        <!-- User-specific key which identifies user on Nerrvana side. -->
        <!-- Available as an 'API public key' on Settings page 
            (https://cloud.nerrvana.com/user/editAccount) 
            in Nerrvana. -->
        <apikey>a6c171d-20eb5-61e3-60991-8a1e523ce</apikey>
        <!-- This key is used by the Nerrvana plug-in to create a checksum of API 
            call parameters to ensure their consistency. -->
        <!-- Available as an 'API private key' on Settings page in Nerrvana. -->
        <secretkey>z3rCWlLdAP35eCCYAmQZ2kPw9X0LByrcc3XGh</secretkey>
    </api-params>

Имя Test Run-a указывается в секции ‘test-run-name’. Плагин будет добавлять к нему номер Jenkins build, таким образом генерируя новое имя для каждого нового Test Run-a.

<!-- Parameters related to Nerrvana-driven Selenium tests. -->
    <!-- Test Run name template, Jenkins build number will be added to the 
        end automatically. -->
    <test-run-name>Answers TRUNK</test-run-name>

Далее в элементе ‘test-run-descr’ идет описание Test Run-a – test-run-descr. Его можно оставить пустым или добавить, например, “Сгенерировано Jenkins плагином”.

<!-- Test Run description. All Test Runs created by this Jenkins build 
        step will have this description. -->
    <test-run-descr></test-run-descr>

В комментариях к элементу ‘test-run-descr-file’ поясняется, как можно использовать файл для добавления описания динамически. Мы заменим название файла на version.txt, так как именно такой файл генерируется в deployment части нашего build-а. Вы можете создавать файл и включать в него информацию, которую считаете необходимой.

<!-- Content of this file, if not empty, will be added to a description,
        defined by ‘test-run-descr’ parameter above.
        File path is relative to the Jenkins job workspace.
        During deployment phase you can extract revision number, commiter name and a
        commit message from your version control system, put them into this file and
        use them as a description.
        You can extract and parse SVN information into info.txt file with our little
        tool - https://github.com/deepshiftlabs/nerrvana-plugin-for-jenkins-ci
        You can read how we do it with SVN in our blog. -->
    <test-run-descr-file>version.txt</test-run-descr-file>

Вот как будет выглядеть созданный плагином Test Run, если:

- test-run-name – Answers TRUNK MySQL

- test-run-descr – Created by Nerrvana-Jenkins plugin

- содержимое test-run-descr-file:
Revision: 142
Commiter: igork
Date: 2012-10-17 07:39:20 +0000 (Wed, 17 Oct 2012)

Dynamic description

К ‘test-run-name’ добавлен номер Jenkins build-a – ‘build #51′. Описание получено конкатенацией ‘test-run-descr’ с содержимым ‘test-run-descr-file’.

Параметр ‘executable-file’ содержит, выбранный нами при генерации плагина, выполняемый файл – xbuild-mysql.sh.

<!-- Which executable file Nerrvana should use to start tests. -->
    <executable-file>xbuild-mysql.sh</executable-file>

Будучи исполненным, он должен быть в состоянии запустить ваши тесты. Вот его содержимое:

ant -f build-mysql.xml all > build.log 2 >& 1

Приведу под спойлером также и файл build-mysql.xml, но не буду останавливаться на том, что и как он делает. Если у вас возникнут вопросы – мы с радостью ответим.

<project name="dslabs-test" default="" basedir=".">
  <!-- BEGIN versions -->
    <property name="title"          value="Tests of http://answers.starty.co"/>
    <property name="version"          value="0.02.000"/>
  <!-- END versions -->
 
  <!-- BEGIN build properties -->
    <property name="build.compiler"       value="javac1.6"/>
    <property name="libdir"               value="${basedir}/lib"/>
    <property name="output"               value="${basedir}/output"/>
    <property name="sources"              value="${basedir}/src"/>
    <property name="resources"            value="${basedir}/res"/>
    <property name="dist"                 value="${basedir}/dist"/>
    <property name="logdir"               value="${basedir}/log"/>
    <property name="bindir"               value="${basedir}/bin"/>
    <property name="logs"            	value="${basedir}/logs"/>
    <property name="test.failonerror"     value="true"/>
    <property name="compile.debug"        value="true"/>
    <property name="compile.debuglevel"   value="lines,vars,source"/>
    <property name="compile.deprecation"  value="true"/>
  <!-- END build properties -->
 
    <taskdef resource="testngtasks" classpath="${libdir}/testng-5.8-jdk15.jar"/>
 
    <path id="classpath">
        <fileset dir="${libdir}">
            <include name="*.jar"/>
        </fileset>
    </path>
 
    <target name="clean">
        <delete dir="${output}"/>
        <delete dir="${logs}"/>
    </target>
 
    <target name="prepare" depends="clean">
        <mkdir dir="${output}"/>
        <mkdir dir="${logs}"/>
    <!-- !!!-->
        <mkdir dir="${logs}/html"/>
        <copy todir="${logs}/html/js">
            <fileset dir="${resources}/js" />
        </copy>
        <copy todir="${logs}/html/img">
            <fileset dir="${resources}/img" />
        </copy>
        <copy todir="${logs}/html/css">
            <fileset dir="${resources}/css" />
        </copy>
 
        <copy file="${resources}/log4j.xml" todir="${output}"/>
        <copy file="${resources}/testng.xml" todir="${output}"/>
        <copy file="${resources}/config-mysql.xml" tofile="${output}/config.xml"/>
    </target>
 
    <target name="bld" depends="prepare">
        <javac
            srcdir="${sources}"
            destdir="${output}"
            excludes=""
            encoding="UTF8"
            debug="${compile.debug}"
            deprecation="${compile.deprecation}"
            optimize="${compile.optimize}"
            debuglevel="${compile.debuglevel}">
            <classpath refid="classpath" />
        </javac>
    </target>
 
    <path id="tests_classpath">
        <fileset dir="${libdir}">
            <include name="*.jar"/>
        </fileset>
        <pathelement location="${output}"/>
    </path>
 
    <target name="run" description="${title}">
        <java classpathref="tests_classpath"
            fork="true"
            dir="${output}"
            classname="org.testng.TestNG"
            failonerror="false">
            <arg value="-d" />
            <arg value="${logs}/testng_reports" />
            <arg value="testng.xml"/>
        </java>
<!--delete dir="${output}"/-->
    </target>
 
  <!-- build all -->
    <target name="all" depends="bld,run" description="Clean, build, and deploy project"/>
</project>

Раздел ‘platforms’ содержит платформы, на которых мы решили выполнять тесты. В список включены все поддерживаемые платформы, а выбранные раскомментированы.

<!-- List of platforms to run tests against for this config. -->
    <platforms>
        <!-- List of available platforms. Uncomment to use. -->
        <!--platform>
            <code>centos_58_firefox_36</code>
            <name>Firefox 3.6 (CentOS)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_firefox_110</code>
            <name>Firefox 11.0 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_firefox_150</code>
            <name>Firefox 15.0 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_firefox_36</code>
            <name>Firefox 3.6 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_ie_8</code>
            <name>IE 8 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_opera_1162</code>
            <name>Opera 11.62 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_opera_1202</code>
            <name>Opera 12.02 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_safari_515</code>
            <name>Safari 5.1.5 (WinXP)</name>
        </platform-->
        <!--platform>
            <code>winxp_sp3_safari_517</code>
            <name>Safari 5.1.7 (WinXP)</name>
        </platform-->
 
        <platform>
            <code>winxp_sp3_chrome_2001132</code>
            <name>Chrome 20.0.1132 (WinXP)</name>
        </platform>
        <platform>
            <code>winxp_sp3_chrome_2101180</code>
            <name>Chrome 21.0.1180 (WinXP)</name>
        </platform>
    </platforms>

Параметром ‘nodes-count’ можно сконфигурировать плагин на запуск тестов параллельно. Подробнее о параллельном выполнении тестов читайте в документации. Если ваши тесты не работают параллельно, необходимо изменить количество nodes на 1.

<!-- How many Selenium nodes should be used for each platform. -->
    <nodes-count>2</nodes-count>

Следующий параметр требует настройки. Он указывает на месторасположение тестов в Jenkins workspace.

<!-- Parameters related to the transfer of the tests from Jenkins 
        to Nerrvana. -->
    <!-- Folder in the workspace of Jenkins job where Selenium tests will be 
        located. It is assumed that the SCM build step, which always occurs 
        BEFORE other steps, will put tests there. -->
    <folder-with-tests>.</folder-with-tests>

Наши Selenium-тесты находятся в том же репозитории в папке tests. Структура проекта была показана нами в посте Nerrvana в работе – сборка приложения и Jenkins (часть 1). Таким образом, в нашем случае этот параметр будет указан так:

<folder-with-tests>./tests</folder-with-tests>

Space ID, Space name и папка FTPS задаются внутри секции ‘space’. Эти параметры менять не нужно.

<!-- Nerrvana space previously created by you through the Nerrvana UI. -->
    <space>
        <id>4144</id>
        <name>Answers</name>
        <ftp-path>Answers/_files</ftp-path>
    </space>

В разделе ‘ftp’ находятся параметры доступа по FTPS. Здесь необходимо указать пароль вашей учётной записи в Nerrvana.

<!-- Address and credentials of the Nerrvana FTPS connection. Note that 
        a system running Jenkins should have LFTP application installed. -->
    <ftp>
        <server>ftp.nerrvana.com</server>
        <!-- Your username -->
        <username>demo123</username>
        <!-- Replace this value with your password!! -->
        <password>[p a s s w o r d]</password>
    </ftp>

Следующий параметр – ‘skip-tests-sync’ – позволяет ускорить тестирование, избежав ненужной повторной синхронизации тестов, если плагин Nerrvana вызывается несколько раз подряд в одном build-е. Сейчас мы оставим значение по умолчанию – false, так как вызываем плагин один раз. В следующем посте я покажу, как он используется нами в случае, когда тесты вначале запускаются для тестирования нашего приложения с MySQL, а потом с PostgreSQL.

<!-- You can skip test sync when you call the Nerrvana plugin many times 
        in a single job and tests were synced in a previous step. -->
    <skip-tests-sync>false</skip-tests-sync>

Параметры определяемые далее, понадобятся вам в том случае, если вы используете messages, которые может анализировать Nerrvana. Нами даны достаточно подробные описания этих параметров прямо в конфигурационном файле плагина.

<!-- Job status will be set to FAILED if test execution in Nerrvana is 
        unsuccessful (tests did not sync, executable file did not start your 
        tests, etc).
            If tests were executed successfully, you have a few options:
        1. Mark build as successful in Jenkins and analyse generated reports 
        for problems your tests discovered.
        2. If you want to mark a build as FAILED based on errors your tests 
        found, you can:
            (a) Add additional step, load results, parse them to analyse errors 
            your tests discovered, and mark build as FAILED based on it. Keep 
            this parameter as 'false' in this case.
            (b) Use Nerrvana "Messages" and let the Nerrvana plugin analyse 
            results, and change build status to FAILED based on it. Keep this 
            parameter as 'true' in this case and use additional parameter 
            'message-threshold' to add additional logic.
            If you use messages and invoke the Nerrvana plug-in several times 
            in the same build, keep this option as 'false' for all invocations 
            except the last one to let the build complete all tests and analyse 
            errors at the very end. -->
    <use-messages-to-set-build-status>false</use-messages-to-set-build-status>
 
    <!-- Defines the level at which a FAILED status is generated. If this 
        value is set to 'WARN', for example, and your tests generate one or more 
        'WARN' or higher severity messages (ERROR or FATAL), Nerrvana execution 
        status, and Jenkins build, will be FAILED. For the full list of levels, 
        visit http://www.nerrvana.com/docs/using-messages page. -->
    <message-threshold>ERROR</message-threshold>

Поскольку наши тесты генерируют такие messages, мы установим эти параметры таким образом:

<use-messages-to-set-build-status>true</use-messages-to-set-build-status>
    <message-threshold>ERROR</message-threshold>

Это значит, что плагин будет получать и сохранять messages в процессе выполнения тестов и проанализирует, нет ли в них сообщений уровня ERROR или выше (FATAL). Если есть – то build статус будет выставлен как FAILED в Jenkins.

Если вы не используете Nerrvana messages, и всё равно хотите выставлять статус build-а основываясь не на факте его успешного завершения, а на результатах тестирования, вы можете добавить дополнительный шаг build-а после выполнения Nerrvana плагина. Он получит файл с результатами тестирования из Nerrvana по FTPS, сделает его анализ и обновит статус build-а Jenkins.

Параметр ‘max-execution-time’ помогает прервать выполнение, если тесты, например, зациклились. Если вы уже выполнили тесты в Nerrvana, используя UI, то вы можете установить реальное значение с запасом уже сейчас.

<!-- Maximum execution time (in seconds). Defines how long the Nerrvana 
        plug-in will wait for tests to complete. Start by setting to a large 
        value and adjust accordingly after a few runs.-->
    <max-execution-time>3600</max-execution-time>

Последний параметр – ‘poll-period’ – определяет, насколько часто плагин Nerrvana будет опрашивать API о статусе выполнения тестов.

<!-- How often the Nerrvana plug-in will update test execution status 
        from Nerrvana (in seconds). -->
    <poll-period>20</poll-period>

Схема работы плагина, особенно в части опроса и выставления статуса build-а в зависимости от этих параметров, более подробно показана на странице документации.

Внеся все необходимые изменения в конфигурационный файл, мы можем добавить последний шаг в наш build …

Add Nerrvana plugin step

… и просто скопировать содержимое нашего файла в окошко конфигурации плагина.

Add Nerrvana plugin step - just copy/paste

Сохранив Jenkins job, мы можем сделать коммит и наблюдать за выполнением наших тестов в Nerrvana. Сначала я выполнил один тест на одной платформе. В UI можно видеть, как плагин создаёт Test Run и он сразу начинает выполняться.

Nerrvana Test Run started by Jenkins

К названию Test Run-а был добавлен номер build-а Jenkins, и описание содержит информацию, собранную из описания, которое мы задали в плагине и содержимого version.txt, которое преобразовал наш декоратор. Видно, что тест успешно завершился – нет сгенерированных сообщений.

Nerrvana Test Run completed

Из Nerrvana по ссылке (показано стрелкой на картинке выше) можем перейти к отчёту, который сгенерировал наш тест.

Our Selenium report for one test

В первый раз для того, чтобы быстро убедиться, что всё работает, я отключил все тесты, кроме одного – теста логина. Теперь я включу все тесты, сделаю коммит, и Jenkins запустит ещё один Test Run. Да, и я добавил ещё одну платформу.

Под спойлером вы увидите консольный лог Jenkins build-a, который как бы продолжается с того места, где мы закончили deployment в предыдущем посте (там вы тоже найдёте консольный лог с комментариями под спойлером).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
---BEGIN PLUGIN EXECUTION---
2012-10-17 07:39:24 ---INITIALIZATION STARTED---
2012-10-17 07:39:24
---BEGIN PLUGIN SETTINGS---
   Nerrvana HTTP address: https://api.nerrvana.com
   Nerrvana API key: a6c171d-20eb5-61e3-60991-8a1e523ce
   Secret key: z3rCWlLdAP35eCCYAmQZ2kPw9X0LByrcc
   Space ID: 4144
   Space: Answers
   Space path[FTPS folder]: Answers/_files
   Selenium nodes per platform: 1
   Test run name: Answers TRUNK
   Nerrvana platforms:
      Opera 12.02 (WinXP)
      Firefox 15.0 (WinXP)
   Executable file: xbuild-mysql.sh
   Nerrvana FTPS address: ftp.nerrvana.com
   Nerrvana FTPS user: demo123
   Nerrvana FTPS pass: dem0I23
   Workspace folder: ./tests
   Max execution time: 3600
   Poll period: 20
   Parse user messages mode[results analyzer]: ON
   User message threshold: ERROR
-----END PLUGIN SETTINGS---
2012-10-17 07:39:24 -----INITIALIZATION COMPLETED---
 
2012-10-17 07:39:24 Generated test run name: Answers TRUNK MySQL build #51
2012-10-17 07:39:24 Generated test run description:
Created by Nerrvana-Jenkins plugin
Revision: 142
Committer: igork
Date: 2012-10-17 07:39:20 +0000 (Wed, 17 Oct 2012)
Launching all tests on two platforms
 
2012-10-17 07:39:24 ---BEGIN UPLOADING TESTS TO NERRVANA FTPS---
[workspace] $ lftp -f upload-build-51-8414449724631519802.ftp
 
2012-10-17 07:40:16 -----END UPLOADING TESTS TO NERRVANA FTPS
 
2012-10-17 07:40:18 Creating and starting test run 
                    via Nerrvana HTTP API call...done.
2012-10-17 07:40:18 New test run ID#884.
2012-10-17 07:40:18 New execution ID#5486.
2012-10-17 07:40:18 ---BEGIN NERRVANA POLLING CYCLE 
                       (waiting for tests to complete)
 
2012-10-17 07:40:40    Current execution status: run
 
2012-10-17 07:41:02    Current execution status: run
 
------ Some оutput removed ---------------------------------
 
2012-10-17 07:44:17    Current execution status: run
 
2012-10-17 07:44:38    Current execution status: ok
 
2012-10-17 07:44:38 -----END NERRVANA POLLING CYCLE---
2012-10-17 07:44:38 Saving execution results into results.xml...
2012-10-17 07:44:38 Done.
2012-10-17 07:44:38 ---BEGIN TEST EXECUTION RESULTS---
2012-10-17 07:44:38 At least 43 message(s) from Nerrvana side reach(es) 
                    or exceed(s) threshold level (ERROR).
Message analyzer marks execution as failure.
2012-10-17 07:44:38 -----END TEST EXECUTION RESULTS---
2012-10-17 07:44:38
-----END PLUGIN EXECUTION---
 
Build step 'Nerrvana plug-in' marked build as failure
Finished: FAILURE

До строки 27 плагин показывает параметры, извлеченные из своего конфигурационного файла. В строках 28-34 создаются имя и описание нового Test Run-а.

В строках 36-39 тесты, находящиеся на стороне Jenkins синхронизируются с тестами находящимися в Nerrvana Space.

Затем создаётся новый Test Run и через API плагин получает ID Test Run-а и ID его выполнения (один и тот же Test Run можно запустить несколько раз, но каждое выполнение имеет свой уникальный внутренний ID) – строки 41-44. На этом этапе Test Run становится видимым в UI Nerrvana – “Answers TRUNK MySQL build #51″ создан и начинает выполняться.

Nerrvana Test Run started by Jenkins - all tests and two platforms

Теперь плагин опрашивает Nerrvana каждые 20 секунд (polling parameter), одновременно считывая появляющиеся в процессе выполнения Nerrvana messages – строки 45-58.

Как только тесты завершились (строки 59-60), плагин анализирует уровень ошибок (строки 61-63) и на основании анализа выставляет статус builda-а (строки 64-70). Если бы мы не анализировали сообщения Nerrvana, то build бы завершился успешно.

Воспользовавшись Nerrvana UI, мы видим, сколько времени заняло выполнение всех тестов на каждой платформе.

Nerrvana Test Run completed - all tests and two platforms

Так выглядят сообщения, которые считывает и анализирует плагин в UI.

Nerrvana messages can be analyzed by plugin

Видно, что отчеты (генерируемые нашим framework-ом) содержат больше тестов, чем при прошлом запуске (левая панелька).

Our Selenium report for all test

Ещё одним достоинством использования Nerrvana messages является тот факт, что плагин умеет создавать простые отчёты – (1). Нажмите на картинке ниже, чтобы увеличить её и увидеть цифры, на которые я ссылаюсь. В отчётах можно увидеть статус build-а и message threshold, используемые плагином (2), описание Test Run-а (3). В нашем случае – информация о коммите. Ссылки на названиях платформ (4) ведут на FTPS-сервер Nerrvana, где будут находиться подробные отчеты, сгенерированные вашими тестами. Ну и кликнув в последней колонке (5), мы раскроем таблицу и увидим сообщения, которые послали тесты из Nerrvana.

Очень часто разработчику достаточно только этого (особенно если он сам и писал тесты :) ).

Nerrvana plugin report in Jenkins

Мы описали весь процесс настройки и запуска тестирования. Однако, как вы уже поняли, мы тестируем наше приложение с двумя базами данных, а следовательно, используем немного более сложную конфигурацию – мы делаем два deployment-а и вызываем Nerrvana плагин два раза в одном и том же job-е Jenkins.

Об этом мы расскажем в последнем посте цикла. Поразмышляем мы и о том, как процесс можно улучшить и когда в этом есть смысл.

Print this post | Home

Comments are closed.