Проблемыинтеграции: Mercury Interactive QuickTest &TestDirector
Роман Касьяненко
Этастатья ориентирована на тестировщиков со средним и выше уровнем подготовки. Поэтомупредполагается, что тестировщик знаком с такими инструментами компании MercuryInteractive как 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 eachtest 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 samesection
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 testscript:
…
While Browser(«title:=(?!MercuryTestDirector).*»,«index:=0»).Exist
While Browser(«title:=(?!MercuryTestDirector).*»,«index:=0»).Dialog(«text:=MicrosoftInternet Explorer», «index:=0»).Exist
Browser(«title:=(?!MercuryTestDirector).*»,«index:=0»).Dialog(«text:=MicrosoftInternet Explorer», «index:=0»).Close
Wend
Browser(«title:=(?!MercuryTestDirector).*»,«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 duringtest run:» dropdown list to the «stop run» value
11. Close «Test | Settings…» dialog and save
Воти все!
Теперьпакет скриптов можно запускать на выполнение, которое абсолютно не требуетвашего присутствия (чего мы и добивались). Каждое утро я просматриваюрезультаты выполнения пакета скриптов. А вечером, уходя с работы домой, янажимаю всего одну кнопку — «Run all tests».
Надеюсь,кому-то все это пригодится так же как пригодилось мне.
Список литературы
Дляподготовки данной работы были использованы материалы с сайта software-testing.ru/