5973-1 (Проблемы интеграции: Mercury Interactive QuickTest & TestDirector)

Проблемы интеграции: Mercury Interactive QuickTest & TestDirector

Роман Касьяненко

Эта статья ориентирована на тестировщиков со средним и выше уровнем подготовки. Поэтому предполагается, что тестировщик знаком с такими инструментами компании Mercury Interactive как QuickTest (функциональное тестирование) и TestDirector (управление процессом тестирования). В данной статье все внимание будет сосредоточено на процессе их совместной интеграции, которая, будучи реализованной, дает ощутимые преимущества при разработке и тестировании конечного продукта (экономия времени, денежных средств и человеческих ресурсов, затрачиваемых на тестирование; тесная интеграция процессов разработки и тестирования, что, в свою очередь, также повышает качество разрабатываемого продукта).

Примечание: все нижеописанное взято из моего личного опыта работы, однако принимая во внимание то, что я занимаюсь тестированием web-сайтов, некоторые решения заточены именно под web-тестинг, хотя общая картина, я предполагаю, будет приблизительно такой же и для многих других случаев...

Главная цель: для проекта, скриптование которого осуществляется группой тестеров, реализовать выполнение пакета скриптов (test set) в полностью автоматическом режиме.

Приступим!

Предполагается, что QuickTest, TestDirector и плугины (plug-ins), необходимые для их совместной работы, установлены и все функционирует без проблем (на данный момент я использую QuickTest Professional версии 6.5 и TestDirector версии 7.2).

Итак, некоторый разрабатываемый продукт прошел входное тестирование. После этого, с помощью TestDirector, был создан некоторый набор тест-кейсов для тестирования этого продукта (этот набор включает в себя тест-кейсы для входного тестирования плюс тест-кейсы для расширенного и, возможно, экстремального тестирования). Теперь необходимо сгенерировать «заготовки» для скриптов (это экономит время на комментирование скриптов а также делает результаты выполнения скриптов более читабельными) с помощью того же TestDirector, после чего самое время приступить к разработке скриптов (а вот здесь в игру вступает QuickTest). Когда скрипты будут готовы, их необходимо объединить в пакеты (опять же, используя TestDirector), которые и будут запускаться для выполнения регрессивного тестирования (вот здесь, наконец-то, начинается взаимодействие «звездной пары» — TestDirector использует QuickTest для запуска отдельных скриптов некоторого пакета).

Теперь рассмотрим вопросы, которые могут возникать в процессе реализации всего вышеописанного:

— Как заставить скрипт понимать какие из запущенных во время исполнения скрипта экземпляров браузера необходимо использовать? Проблема в том, что TestDirector тоже запускается в браузере, и поначалу я часто встречался с ситуацией, когда, во время исполнения скрипта, QuickTest, запущенный TestDirector’ом, использовал браузер, в котором был загружен тот же TestDirector... естественно, на этом выполнение пакета скриптов прерывалось...

Решение: прописать для каждого объекта браузера (в репозитории объектов), используемого в скрипте, специальный (отсутствующий по умолчанию в списке стандартных атрибутов) атрибут “creationtime” – 0 для первого используемого браузера, 1 – для второго и т.д. Это дает возможность идентифицировать экземпляры браузера по времени их создания скриптом.

— Как избежать ошибок автоматического распознавания объектов во время выполнения скрипта?

Решение: отказаться от «Smart Identification feature», после чего возрастет трудность и, соответственно, время написания скриптов, но в то же время возрастет и их надежность.

— Как минимизировать время, затрачиваемое на написание скриптов?

Решение: использовать общие репозитории объектов и общие библиотеки стандартных функций для отдельных проектов (повторное использование кода).

— Как минимизировать время, затрачиваемое на конфигурацию скриптов?

Решение: все скрипты отдельного проекта должны пользоваться общими переменными окружения; для этого необходимо создать ini-файл, в который будут помещены переменные окружения для отдельного проекта и указать этот файл как источник переменных окружения для каждого скрипта этого проекта. В таком случае, перед запуском пакета скриптов необходимо изменить только этот файл. Для удобства, к корневой ветке проекта в TestDirector можно присоединить линк на этот файл.

— Как избежать невозможности исполнения последующих скриптов пакета при возникновении ошибок на сайте, которые приводят к аварийному «подвисанию» или «размножению» браузеров и их диалоговых окон?

Решение: в конце каждого скрипта необходимо предусмотреть код, который итеративно будет закрывать все диалоги и браузеры, которые используются скриптом.

— Как избежать невозможности исполнения последующих скриптов пакета при возникновении ошибки в некотором из скриптов этого пакета?

Решение: настроить каждый скрипт проекта так, чтобы он останавливал свое выполнение в случае возникновения ошибки, вместо того, чтобы показывать message box с описанием ошибки (это пункт конфигурации скрипта по умолчанию, однако он уместен лишь на стадиях написания и отладки скрипта).

Теперь подведу итог общей инструкцией (взято из «конвеншенов» компании, в которой я работаю), руководствуясь которой необходимо разрабатывать каждый скрипт конкретного проекта:

1. Load QuickTest (create new test script)

2. Go to «Test | Settings…»

3. On «Run» tab do following:

check «Disable Smart Identification during the test run» checkbox

4. On «Environment» tab do following:

select «User-defined» value in «Variable type» dropdown list

check «Load variables and values from external file (reloaded each test run)» checkbox

specify file with environment variables in the «File:» editbox

5. On the «Resources» tab do following:

specify library files in the «Associated library files:» section

tab select «Shared» radiobutton

specify object repository file in the activated editbox in the same section

6. Close «Test | Settings…» dialog and save

7. Develop test script according to the corresponding test case

8. Insert code which closes all browsers and dialogs instances, except browser instance in which TestDirector is loaded, in the end of the test script:

…

While Browser("title:=(?!Mercury TestDirector).*","index:=0").Exist

While Browser("title:=(?!Mercury TestDirector).*","index:=0").Dialog("text:=Microsoft Internet Explorer", "index:=0").Exist

Browser("title:=(?!Mercury TestDirector).*","index:=0").Dialog("text:=Microsoft Internet Explorer", "index:=0").Close

Wend

Browser("title:=(?!Mercury TestDirector).*","index:=0").Close

Wend

…

9. After test script is finished, go to «Test | Settings…» again

10. On «Run» tab do following:

change «pop up message box» value of the «When error occurs during test run:» dropdown list to the «stop run» value

11. Close «Test | Settings…» dialog and save

Вот и все!

Теперь пакет скриптов можно запускать на выполнение, которое абсолютно не требует вашего присутствия (чего мы и добивались). Каждое утро я просматриваю результаты выполнения пакета скриптов. А вечером, уходя с работы домой, я нажимаю всего одну кнопку — «Run all tests».

Надеюсь, кому-то все это пригодится так же как пригодилось мне.

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://software-testing.ru/