Применение продукта Rational Quality Manager в конвейере непрерывного выпуска в рамках концепции DevOps

В статье описывается процесс применения API-интерфейса ANT для вызова скриптов автоматизации тестирования (test script). Этот подход облегчает поддержку выполнения тестов, техническое сопровождение машин для выполнения тестов и ведение истории результатов тестирования.

Продукт IBM® Rational® Quality Manager служит центром коллективной работы по планированию тестирования и управлению его результатами. Как показано на рис. 1, продукт Rational Quality Manager входит в состав решения Rational Solution for Collaborative Application Lifecycle Management, основанного на платформе Jazz™. С помощью продукта Rational Quality Manager можно поддерживать выполняемые в автоматическом и ручном режиме тестовые сценарии (test case), отслеживать соответствие тестовых сценариев требованиям, а также управлять изменениями, например, в соответствии с планами устранения дефектов и планами разработки. Этот продукт хорошо интегрируется с продуктами от других поставщиков.

Рисунок 1. Продукты Collaborative Lifecycle Management

Понятие фаз непрерывной реализации

Непрерывный выпуск или непрерывная интеграция - это практическая методика, в которой процесс между проверкой программного кода (далее - "код") и развертыванием готового программного продукта на производственном сервере осуществляется в автоматическом режиме. Как правило, между этими двумя фазами не требуется никого вмешательства в ручном режиме. В большинстве случаев между созданием программного кода и его развертыванием имеются различные фазы (см. рис. 2).

• Разработчики поставляют программный код в ветвь процесса, которая называется основной ветвью или ветвью интеграции. Рекомендованная практика состоит в том, чтобы в рамках одной поставки предоставлять не только сам основной код (т. е. код, который поступает в создаваемый продукт), но и автоматические тесты, необходимые для тестирования этого нового кода.
• Этот код подвергается проверке в ветви (или дереве) контроля исходного кода, после чего инициируется сборка этого кода. Сборка выполняется либо согласно установленному план-графику, либо инициируется при обнаружении изменений в каком-либо файле.
• В случае успешного выполнения сборки ее результаты устанавливаются на промежуточном сервере ( staging server), т. е. на сервере, который не используется в качестве "производственного" (рабочего) сервера ( production server). На этом промежуточном сервере теперь исполняется набор изменений, который предоставил разработчик.
• На промежуточном сервере выполняется набор тестов, чтобы удостовериться в том, что полученный от разработчиков код не ухудшил какую-либо функциональность и что новые тесты для новых функций работают достаточно хорошо. Это первые ворота качества (quality gate).
• Если все тесты завершились успехом, т.е. с совокупным вердиктом go ("прошел"), то набор изменений передается в "производственную" ("стабильную") ветвь. Это именно тот исходный код, который исполняется на производственном сервере.
• В стабильной ветви инициируется сборка, и результаты этой сборки развертываются на производственном сервере. Иногда на производственном сервере выполняется набор простых тестов на явные ошибки (smoke test), чтобы удостовериться в работоспособности новой сборки с последними изменениями от разработчиков. Это вторые ворота качества.

Рисунок 2. Простой конвейер выпуска

Добавление ворот качества

Чаще всего группы разработки программного обеспечения пользуются хорошо известными системами сборки. Эти системы охватывают диапазон от создаваемых вручную скриптов на ANT и Perl, оркеструющих процесс сборки, до более изощренных коммерческих продуктов, соответствующих концепции DevOps. Ворота качества можно реализовать вне зависимости от типа используемой системы сборки. Эта статья ориентируется на наиболее распространенную ситуацию, когда группы располагают средствами сборки и развертывания, предоставляющими программируемые механизмы отладки/диагностирования кода на различных языках (ANT, Rake, Jython, простой Java™), или какими-либо другими средствами, например, Maven или Hudson.

Создание скрипта автоматизации

Строго говоря, скрипт автоматизации не является обязательной частью процесса добавления ворот качества, однако это критически важный аспект обеспечения качества. В большинстве случаев у разработчиков уже имеются скрипты тестирования, которые они выполняют в своих средах разработки с целью валидации тех или иных функций. Обычно эти скрипты создаются при посредстве какой-либо платформы для написания тестов с использованием таких инструментов практикующего тестировщика, как Selenium, Java JUnit, Rational Functional Tester, HP QTP или других инструментов. Каждый тестовый модуль должен быть достаточно гранулярным, чтобы обеспечить содержательную валидацию конкретного отказа. Следует избегать тестов со слишком широким охватом, поскольку выявляемый с их помощью дефект оставляет под подозрением значительную часть функциональности создаваемого продукта. С другой стороны, следует избегать слишком узкоспециализированных тестов, поскольку они весьма затрудняют написание осмысленных сценариев тестирования (test scenario). В данной статье для иллюстрации используется пример скрипта тестирования, написанный на Java JUnit; однако подход можно распространить и на другие типы скриптов тестирования.

Определение скрипта тестирования

После создания скрипта тестирования начинайте подключать его к продукту Rational Quality Manager, чтобы среда Rational Quality Manager смогла выполнить этот скрипт. Продукт Rational Quality Manager использует концепцию типа скрипта (script type). Каждый тип скрипта соответствует компоненту исполнения под названием адаптер теста (test adapter). В примере на рис. 3 скрипт имеет тип JUnit or Selenium, который используется для указания на тест веб-драйвера Selenium и на тест JUnit. В конвейере непрерывного выпуска JAR-файл скрипта тестирования устанавливается на тестовой машине. Настройка адаптера теста описывается в следующем разделе.

Рисунок 3. Создание скрипта тестирования в среде Rational Quality Manager

Определение тестового сценария

Как показано на рис. 4, вам нужно добавить скрипт тестирования (test script) продукта Rational Quality Manager к тестовому сценарию (test case) продукта Rational Quality Manager. Тестовый сценарий - это базовый исполняемый объект в среде Rational Quality Manager. Результаты выполнений теста сохраняются со ссылкой на соответствующий тестовый сценарий. Эта запись носит название test case execution results (результаты исполнения тестового сценария). Рекомендуется поддерживать взаимно однозначное соответствие между тестовым сценарием и скриптом тестирования, а также присваивать им одинаковые имена. Адаптер теста можно специфицировать в процессе исполнения. Тестовые сценарии можно группировать по категориям. Категории могут оказаться весьма полезными, если впоследствии вы захотите создать отчеты для определенных продуктов, для определенных компонентов или для любой другой формы группирования по вашему выбору.

Рисунок 4. Создание тестового сценария Rational Quality Manager

Создание комплектов тестов

Комплект тестов (test suite) в Rational Quality Manager (см. рис. 5), - это способ агрегации набора тестовых сценариев. Комплекты тестов позволяют разработчику управлять набором скриптов автоматизации тестирования, которые он хочет выполнить для определенных ворот качества. Например, комплект тестов под названием Build Verification Tests (тесты для верификации сборки) может представлять собой набор скриптов тестирования, позволяющих быстро выявить в приложении дефекты т. н. "зеленых" потоков (green threads). Если создаваемое приложение имеет пользовательский интерфейс, то комплект тестов может включать в себя набор автоматических тестов пользовательского интерфейса, воспроизводящих его важнейшие функции. Рекомендуется применять этот комплект тестов к сборке перед ее передачей на следующую фазу. Кроме того, у вас может быть другая серия комплектов тестов, которые более детально проверяют каждую основную функцию. Например, соответствующий набор тестов API-интерфейса может тестировать обеспечивающие REST-интерфейсы. При выполнении комплекта тестов вы сможете добавить в него все необходимые вам тестовые сценарии.

Рисунок 5. Комплект тестов

Создание TSER-записей (test suite execution record)

Для созданных вами комплектов тестов нужно создать TSER-запись (test suite execution record - запись выполнения комплекта тестов) (см. рис. 6). Как правило, у разработчика уже есть план тестирования (test plan). Добавьте свой комплект тестов к этому плану тестирования. Для каждого плана тестирования нужно создать одну TSER-запись.

Рисунок 6. Создание TSER-записей

Установка и развертывание

Этот шаг обычно выполняется вашими средствами поддержки процесса непрерывного выпуска. Для этого вы можете применить пользовательский скрипт сборки IBM® uDeploy® или инструмент, подобный Chef, который устанавливает сборку после ее успешного создания из исходного кода. На этой фазе вы должны установить свое приложение и необходимые тестовые активы (в том числе все Junit-классы и все нужные JAR-файлы) в известном местоположении на целевой машине. Это местоположение используется при определении скрипта тестирования Rational Quality Manager на более позднем шаге. Если вы используете скрипты автоматизации тестирования, например, созданные с помощью IBM® Rational® Functional Tester, вы также можете использовать опцию общего ресурса, поддерживаемую адаптером Rational Functional Tester, чтобы сделать тестовые активы доступными для целевой машины.

Адаптер продукта Rational Quality Manager

В состав продукта Rational Quality Manager входит компонент под названием адаптер (adapter). Это удаленный компонент, который обычно устанавливается на тестовой машине. Этот адаптер взаимодействует с сервером Rational Quality Manager и вызывает скрипты тестирования, которые продукт Rational Quality Manager дает указание выполнять. Затем результаты выполнения этих тестов передаются обратно в Rational Quality Manager.

Установка надлежащего адаптера

В этой фазе установки также устанавливается вышеупомянутый адаптер Rational Quality Manager. Если вы пишете скрипты с помощью JUnit/Selenium, то вам нужно установить адаптер Selenium JUnit; если используете Rational Functional Tester, то вам нужно установить адаптер Rational Functional Tester. Указывая имя адаптера при конфигурировании, используйте полностью определенное доменное имя машины, на которой исполняется адаптер. Такой подход облегчает идентификацию адаптера, подлежащего использованию при выполнении тестового сценария и комплекта тестов.

Использование API-интерфейса ANT продукта Rational Quality Manager для вызова тестов

Возможно, вашим основным средством является ANT-скрипт. Продукт Rational Quality Manager предоставляет API-интерфейс на базе ANT под названием Rational Quality Manager Execution Tool, позволяющий вызывать на исполнение записи выполнения скрипта тестирования и записи выполнения комплекта тестов. Вызов инструмента Rational Quality Manager Execution Tool осуществляется из файла build.xml, ассоциированного с конкретными воротами качества. Идентификатор используемой TSER-записи сохраняется как свойство в ассоциированном файле свойств. Например, код в листинге 1 вызывает интеграционные тесты Rational Quality Manager.

Листинг 1. Вызов интеграционных тестов Rational Quality Manager

Любую информацию о конфигурации или о выполнении можно передать в тесты с помощью опции -variables

Используйте результаты для перехода к следующему шагу цикла

После того как выполнение завершено, ANT-задача инструмента Rational Quality Manager Execution Tool задает два свойства, отражающие состояние выполнения и ссылку на результаты выполнения. Это свойства rqmExec:verdict и rqmExec:result_url, соответственно. Кроме того, к записи сборки (build record) можно добавить журнальный файл и результат теста. В случае использования продукта IBM® Rational Team Concert™ вы можете выполнить следующие задачи.

• С помощью ANT-задачи logPublisher продукта Rational Team Concert присвойте состоянию результата сборки Rational Team Concert значение состояния исполнения Rational Quality Manager.
• С помощью ANT-задачи linkPublisher продукта Rational Team Concert добавьте в результат сборки Rational Team Concert ссылку, указывающую на запись исполнения Rational Quality Manager.

В листинге 2 показан пример кода для записи результата и его URL-адреса в журнальный файл.

Листинг 2. Запись результатов в журнальный файл

В листинге 3 показан пример кода для настройки свойства на основе состояния исполнения.

Листинг 3. Настройка свойства на основе состояния исполнения

В листинге 4 демонстрируется присоединение журнального файла к записи сборки.

Листинг 4. Присоединение журнального файла к записи сборки

В листинге 5 демонстрируется присоединение ссылки на результаты теста к записи сборки.

Листинг 5. Присоединение результатов к записи сборки

Анализ результатов

После начала цикла тестирования для конкретной сборки можно перейти из раздела Test Suite Result (результат комплекта тестов) в раздел Test Case Result (результат тестового сценария) и посмотреть на результаты (см. рис. 7). (Ссылка на результат комплекта тестов добавляется к сборке с помощью linkPublisher). Кроме того, вы получаете графическое представление результатов.

Рисунок 7. Подробные результаты тестового сценария

После накопления достаточного объема результатов данные можно подвергнуть углубленному анализу. Эта возможность доступна только в таких инструментах управления качеством, как Rational Quality Manager (без такого инструмента разработчику доступны только файлы результатов в файловой системе). Например, инструмент управления качеством позволяет рассмотреть состояние выполнения по категориям (см. рис. 8). Категории описываются в разделе Определение тестового сценария.

Рисунок 8. Анализ результатов по категориям

Заключение

Продукт Rational Quality Manager предоставляет весьма структурированный и удобный способ управления тестами, выполняемыми в конвейере непрерывного выпуска согласно концепции DevOps. Этот продукт можно использовать при поэтапном построении полнофункционального DevOps-предложения без необходимости каких-либо переделок. Управление тестовыми сценариями и анализ результата тестирования -два весьма существенных преимущества по сравнению с написанием скриптов тестирования в ручном режиме с помощью обычных средств сборки.