Эта статья ориентирована на тестировщиков со средним и выше уровнем подготовки. Поэтому предполагается, что тестировщик знаком с такими инструментами компании Mercury Interactive как QuickTest (функциональное тестирование) и TestDirector (управление процессом тестирования). В данной статье все внимание будет сосредоточено на процессе их совместной интеграции, которая, будучи реализованной, дает ощутимые преимущества при разработке и тестировании конечного продукта (экономия времени, денежных средств и человеческих ресурсов, затрачиваемых на тестирование; тесная интеграция процессов разработки и тестирования, что, в свою очередь, также повышает качество разрабатываемого продукта).
Примечание: все нижеописанное взято из моего личного опыта работы, однако принимая во внимание то, что я занимаюсь тестированием web-сайтов, некоторые решения заточены именно под web-тестинг, хотя общая картина, я предполагаю, будет приблизительно такой же и для многих других случаев...
Главная цель: для проекта, скриптование которого осуществляется группой тестеров, реализовать выполнение пакета скриптов (test set) в полностью автоматическом режиме.
Приступим!
Предполагается, что QuickTest, TestDirector и плугины (plug-ins), необходимые для их совместной работы, установлены и все функционирует без проблем (на данный момент я использую QuickTest Professional версии 6.5 и TestDirector версии 7.2).
Возможно вы искали - Реферат: Кулинарные рецепты CSS
Итак, некоторый разрабатываемый продукт прошел входное тестирование. После этого, с помощью TestDirector, был создан некоторый набор тест-кейсов для тестирования этого продукта (этот набор включает в себя тест-кейсы для входного тестирования плюс тест-кейсы для расширенного и, возможно, экстремального тестирования). Теперь необходимо сгенерировать «заготовки» для скриптов (это экономит время на комментирование скриптов а также делает результаты выполнения скриптов более читабельными) с помощью того же TestDirector, после чего самое время приступить к разработке скриптов (а вот здесь в игру вступает QuickTest). Когда скрипты будут готовы, их необходимо объединить в пакеты (опять же, используя TestDirector), которые и будут запускаться для выполнения регрессивного тестирования (вот здесь, наконец-то, начинается взаимодействие «звездной пары» — TestDirector использует QuickTest для запуска отдельных скриптов некоторого пакета).
Теперь рассмотрим вопросы, которые могут возникать в процессе реализации всего вышеописанного:
— Как заставить скрипт понимать какие из запущенных во время исполнения скрипта экземпляров браузера необходимо использовать? Проблема в том, что TestDirector тоже запускается в браузере, и поначалу я часто встречался с ситуацией, когда, во время исполнения скрипта, QuickTest, запущенный TestDirector’ом, использовал браузер, в котором был загружен тот же TestDirector... естественно, на этом выполнение пакета скриптов прерывалось...
Решение: прописать для каждого объекта браузера (в репозитории объектов), используемого в скрипте, специальный (отсутствующий по умолчанию в списке стандартных атрибутов) атрибут “creationtime” – 0 для первого используемого браузера, 1 – для второго и т.д. Это дает возможность идентифицировать экземпляры браузера по времени их создания скриптом.
— Как избежать ошибок автоматического распознавания объектов во время выполнения скрипта?
Похожий материал - Доклад: Как писать заявку на разработку Web-узла
Решение: отказаться от «Smart Identification feature», после чего возрастет трудность и, соответственно, время написания скриптов, но в то же время возрастет и их надежность.
— Как минимизировать время, затрачиваемое на написание скриптов?
Решение: использовать общие репозитории объектов и общие библиотеки стандартных функций для отдельных проектов (повторное использование кода).
— Как минимизировать время, затрачиваемое на конфигурацию скриптов?
Решение: все скрипты отдельного проекта должны пользоваться общими переменными окружения; для этого необходимо создать ini-файл, в который будут помещены переменные окружения для отдельного проекта и указать этот файл как источник переменных окружения для каждого скрипта этого проекта. В таком случае, перед запуском пакета скриптов необходимо изменить только этот файл. Для удобства, к корневой ветке проекта в TestDirector можно присоединить линк на этот файл.
Очень интересно - Доклад: Ззачем нужна кнопка Reset на форме?
— Как избежать невозможности исполнения последующих скриптов пакета при возникновении ошибок на сайте, которые приводят к аварийному «подвисанию» или «размножению» браузеров и их диалоговых окон?
Решение: в конце каждого скрипта необходимо предусмотреть код, который итеративно будет закрывать все диалоги и браузеры, которые используются скриптом.
— Как избежать невозможности исполнения последующих скриптов пакета при возникновении ошибки в некотором из скриптов этого пакета?
Решение: настроить каждый скрипт проекта так, чтобы он останавливал свое выполнение в случае возникновения ошибки, вместо того, чтобы показывать 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:
Похожий материал - Реферат: Вирусы против технологии NX в Windows XP SP2
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: