Проблеми інтеграції: 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/