Доклад: Проблемы интеграции: 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:

--> ЧИТАТЬ ПОЛНОСТЬЮ <--