Проблемы интеграции: 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-файл, в который будут помещены переменные окружения для отдельного проекта и указать этот файл как источник переменных окружения для каждого скрипта этого проекта. ............