1.3 Завдання на лабораторну роботу

1.3.1 Ознайомитися з довідковим матеріалом, наданим IBM Rational Functional Tester.

1.3.2 Вивчити пакети, що входять в IBM Rational Functional Tester.

1.3.3 Дослідити класи, що надає IBM Rational Functional Tester, для виконання тестування програмного забезпечення.

1.3.4 Ознайомитися з ієрархією класів.

1.3.5 Проаналізувати API.

1.3.6 Вивчити порядок розробки скриптів, що виконують тестування.

1.3.7 Ознайомитись з командами та їхніми параметрами, що дозволяють використовувати можливості IBM Rational Functional Tester з командного рядку.

1.3.8 Вивчити порядок розробки проекту Functional Test.

1.3.9 Створити тест за допомогою Script Recorder для сайту. Запис скрипту повинен містити три тестових об'єкта, кілька простих точок верифікації з регулярним виразом, кілька точок верифікації для перевірки коректності обробки даних, набір тестових даних в пул даних (не менше п'яти), код, який зберігає скриншот екрану в тестовий лог.

1.3.10 Оформити звіт з роботи.

1.3.11 Відповісти на контрольні питання.

1.4 Зміст звіту

1.4.1 Тема та мета роботи.

1.4.2 Короткі теоретичні відомості.

1.4.3 Результати роботи з IBM Rational Functional Tester.

1.4.4 Висновки, що містять відповіді на контрольні запитання, а також відображують результати виконання роботи та їх критичний аналіз.

1.5 Контрольні запитання

1.5.1 Для чого використовується IBM Rational Functional Tester?

1.5.2 Яке програмне забезпечення дозволяє тестувати IBM Rational Functional Tester?

1.5.3 До яких середовищ може відбуватися інтегрування IBM Rational Functional Tester?

1.5.4 Який базовий клас у ієрархії класів тестування?

1.5.5 Порядок розробки скриптів тестування?

1.5.6 Основні команди командного рядку роботи з можливостями IBM Rational Functional Tester?

1.5.7 Порядок створення проекту Functional Test?

Лабораторна робота №2 Розробка власних скриптів тестування

2.1 Мета роботи

Навчитися розробляти власні скрипти тестування IBM Rational Functional Tester.

2.2 Основні теоретичні відомості

Як було сказано раніше, тестовий скрипт є повноцінною програмою на Java – це не Javascript і не яка-небудь спеціальна мова, – що дає виключно потужні можливості додавати до тесту необхідну нестандартну функціональність. Так само, Functional Tester пропонує багатий інтерфейс програмування додатків (API), за допомогою якого можна отримувати доступ до тестових об'єктів і контролювати виконання тесту.

У процесі запису тесту в минулій лабораторній роботі номер кредитної карти і дата закінчення вводилися вручну, потім використовувався помічник керованих даними команд для вказівки Functional Tester заповнювати ці поля з пулу даних в процесі прогону тесту. Цей процес залишив в тесті декілька необов'язкових команд. Вони не заважають виконанню тесту, проте їх можна видалити, для того, щоб побачити, як працювати з кодом скрипта вручну.

З файлу PlaceОrder.java тестового скрипта, видаліть чотири рядки, показані на рис.2.1 (врахуйте, що якщо при переміщенні між полями тестованого додатка використовувалася кнопка Tab замість миші, команди виглядатимуть по-іншому).

Рисунок 2.1 – Код, який буде видалений

Тепер додамо код, який зберігає скриншот екрану в тестовий лог. У тестовому скрипті знайдіть рядок, що встановлює дату закінчення, взяту з пулу даних. Рядок починається з expirationDateText().setText.

Встановіть курсор у кінець рядка та натисніть Enter для початку нового рядка.

Введіть текст logI та натисніть Ctrl-пробіл. З'явиться вікно зі списком можливих варіантів завершення коду, як показано на рис.2.2. Ця функція називається Помічник введення коду (Code Assist).

Натисніть клавішу вниз для вибору другого елементу зі списку. Це logInfo(), статичний метод класу RationalTestScript, який створює інформаційний запис у тестовому лозі, приймаючи рядок в якості аргументу (мітку), і об'єкт BufferedImage (скріншот для збереження).

Рисунок 2.2 – Помічник введення коду

Натисніть Enter для додавання виклику методу в код скрипта.

Далі необхідно вказати аргумент-рядок, для цього просто введіть "Screen Snapshot" (разом з лапками) і натисніть Tab для переходу до вказівки аргументу-зображення.

Для отримання зображення екрану, використовуйте метод кореневого тестового об'єкта. Введіть getRootTestObject(). Використовуйте помічник введення коду для прискорення введення, якщо потрібно.

Додайте крапку з комою в кінець рядка. Збережіть зроблені зміни. Скрипт тепер повинен виглядати так, як показано на рис.2.3.

Рисунок 2.3 – Додавання в скрипт виклику logInfo()

Запуск автоматичного регресійного тесту.

1. Натисніть кнопку запуску скрипта (Run Functional Test Script) на панелі інструментів. Налаштувальник прогонки тесту дає можливість вказати ім'я логу і необхідні опції перед запуском тесту. Натисніть Next для використання імені логу за замовчуванням.

2. У вікні опцій прогонки (Playback Options) налаштувальника можна вказати кількість наборів даних, на яких буде здійснюватися прогонка тесту. У полі кількості ітерацій пулу даних (Datapool Iteration Count) встановіть Iterate Until Done. Це означає, що Functional Tester виконає тест один раз для кожного набору даних з пулу.

3. Натисніть Finish і Functional Tester почне виконувати тестування. Врахуйте, що якщо даний тест запускався раніше, може бути запропоновано перезаписати лог.

Запит та налаштування значень властивостей об'єктів. Витягти значення властивості можна програмним шляхом за допомогою виклику методу getProperty. Дана властивість може використовуватися для динамічного порівняння в процесі виконання додатка попереднього варіанту значення з поточним значенням, щоб додати до сценарію Rational Functional Tester переходу, заснованого на поточному значенні властивості, що міститься в будь-якому об'єкті і т.д.

У прикладі з лістингу 1 метод getProperty використовується для того, щоб визначити, чи містить кнопка повідомлення «ОК». Якщо містить, то буде натиснута кнопка OK .

Лістинг 1: Використання методу getProperty

// додайте цей код в тестовий проект після рядка //yourOrderHasBeenReceivedYourOr().performTest // (YourOrderHasBeenReceivedYouVP()); String prop= (String) yourOrderHasBeenReceivedYourOr(). getProperty("accessibleContext.accessibleName"); System.out.println(prop); if ("OK".equals(ok2().getProperty("accessibleContext.accessibleName"))) {ok2().click();}

Якщо потрібно дізнатися, якими властивостями володіє деякий об'єкт, можна відкрити карту тестових об'єктів Test Object Map і переглянути перераховані в ній властивості (рисунок 2.4).

Рисунок 2.4 − Властивості у карті тестових об'єктів

Крім того, можна переглянути доступні властивості, записавши тимчасову точку верифікації (verification point, VP) властивостей об'єкта або вставивши команду для витягання значення властивості в змінну за допомогою майстра VP and Actions.

Rational Functional Tester також підтримує метод setProperty. Однак цей метод не дає гарантії результату. Причина полягає у тому, що метод setProperty викликає внутрішні методи, які можуть порушити цілісність тестованого додатка.

Способи пошуку тестових об'єктів. Основний компоновочной блок сценарію Rational Functional Tester – це тестовий об'єкт, який постійно використовується, TestObject. TestObject являє собою точку з'єднання між відтворюваним сценарієм і тестованим додатком. Кожному TestObject у згенерованому сценарії тестування відповідає об'єкт у додатку, на базі якого ведеться запис сценарію, і цей об'єкт тепер присутній і в карті тестових об'єктів Test Object Map.

Зазвичай взаємодіють з тестовими об'єктами TestObject з використанням карти об'єктів. Однак Rational Functional Tester підтримує також засоби для програмного пошуку TestObject. Пошук ведеться по парі ім'я-значення, що визначає властивості TestObject або TestObjects, які потрібно знайти. Пошук може бути глобальним або обмежуватися нащадками батьківського вузла TestObject.

Rational Functional Tester використовує об'єкт з ім'ям RootTestObject для глобального подання тестованого додатка.

• Якщо потрібно виконати пошук по всьому додатку, викличте пошуковий метод для RootTestObject.

• Якщо потрібно знайти конкретний об'єкт, просто викличте пошук для цього TestObject. Пошук за конкретним TestObject знайде лише дочірні об'єкти цього TestObject.

Наприклад, щоб знайти усі кнопки додатка, необхідно використовувати пошук по класу:

// додайте цей код в тестовий проект замість //рядка ok3().click();

RootTestObject root = RootTestObject.getRootTestObject() ;

TestObject[] to = root.find(atDescendant(".class",

"javax.swing.JButton"));

for (int i=0;i<to.length ; i++)

System.out.println(to[i].getProperties());

// замість прямого звернення ok3().click();

// звертаємося до кнопки із знайденого масиву

GuiTestObject OKButton = new GuiTestObject (to[0]);

System.out.println(OKButton.toString());

OKButton.click();

Залежно від обраного об'єкта, пошук обмежується об'єктами в ієрархії нижче вибраного.

Виконуємо прибирання-видалення реєстрації тестових об'єктів. Заключний аспект використання методу пошуку стосується видалення реєстрації об'єктів. Метод TestObject.find повертає нове посилання на TestObject (яка іноді називається обмеженим посиланням, пошуковим посиланням або зіставленим посиланням). Такі посилання утримують доступ до об'єкта до тих пір, поки ви явно не скасуєте їх реєстрацію, а це означає, що вони можуть викликати проблеми, якщо залишити їх без уваги.

Rational Functional Tester видаляє реєстрацію обмежених посилань тільки після завершення виконання всього тесту, а не одного конкретного сценарію. Поки існує обмежене посилання на об'єкт, Rational Functional Tester може не допустити повного звільнення об'єкта в додатку. Наприклад, поки зберігається обмежене посилання на Java™-об'єкт, цей Java-об'єкт не вважається втратившим актуальність і тим, що підлягає видаленню. Тому рекомендується явно видалити реєстрацію усіх створених пошукових посилань відразу після того, як вони стануть непотрібними.

Клас RationalTestScript містить декілька методів, що видаляють посилання на тестові об'єкти TestObjects:

• com.rational.test.ft.script;

• RationalTestScript.unregister;

• unregisterAll.

При роботі з TestObjects безпосередньо використання таких посилань може викликати нестабільність роботи додатка. Тому необхідно вчасно видаляти реєстрації тестових об'єктів TestObjects.

Способи вирішення поширених проблем з браузерами. Поліпшити виконання тесту за допомогою методу waitForExistence.

При відтворенні сценаріїв тестування запуск браузера все ще триває в той час, як вікно відтворення сценарію очікує виконання першої команди. Така поведінка обумовлюється тим, що більш сучасні браузери працюють повільніше, можливо, через свої додаткові елементи, наприклад, вкладки, які необхідно завантажити саме під час запуску. Тому при запуску браузера рекомендується використовувати метод waitForExistence. Це можна зробити за допомогою точки верифікації Wait for Selected TestObject:

1. У процесі запису сценарію запустіть додаток;

2. Натисніть кнопку Insert Verification Point or Action Command на панелі інструментів Recording;

3. На сторінці вибору об'єктів Select an Object майстра Verification Point and Action Wizard натисніть лівою кнопкою миші на значку Object Finder і перетягніть його на HTML-сторінку (не просто в область вікна браузера, а саме на сторінку);

4. Натисніть кнопку Next;

5. На сторінці вибору дій Select an Action майстра Verification Point and Action Wizard встановіть прапорець Wait for Selected TestObject;

6. Якщо потрібно, зніміть прапорець для Use the defaults, щоб змінити параметри максимального часу очікування Maximum Wait Time та інтервалу перевірок Check Interval, які дорівнюють відповідно 2 хвилинам і 2 секундам;

7. Натисніть кнопку Finish.

Інший варіант – самостійно додати виклик після команди startApp. Все, що необхідно зробити – це додати посилання на тестовий об'єкт BrowserTestObject і виклик методу waitForExistence.

Обробка незапланованих активних вікон. З браузерами (і деякими Java-додатками) пов'язана ще одна поширена проблема – це численні спливаючі вікна. Незаплановані активні вікна найбільш часто зустрічаються, коли сценарії виконуються на різних машинах або з різними браузерами, або якщо браузери мають різні настройки.

У довідковій системі Rational Functional Tester описані два ефективних рішення. Одне з рішень – скористатися класичною методикою try-and-catch (лістинг 4) і дочекатися появи повідомлення. Якщо повідомлення не з'явиться, можна продовжувати.

Лістинг 4. Очікування спливаючого діалогового вікна

try { // Dialog_HtmlDialogButtonOK().waitForExistence(5,1); Dialog_HtmlDialogButtonOK().click(); } catch(ObjectNotFoundException e) { }

Якщо очікування має тривати певний час, можна видалити з коду рядок після символу коментар.

Ще одне рішення, що вимагає трохи більше зусиль – це реалізація простої перевірки, аналогічної перевірки з виключенням onObjectNotFound. Включивши цю реалізацію в допоміжний суперсценарій, можна обробляти події для будь-якого сценарію Rational Functional Tester, що є розширенням цього допоміжного суперкласу.

Поліпшення сценаріїв за допомогою допоміжного суперкласу. За замовчуванням, всі сценарії Rational Functional Tester є розширення класу RationalTestScript і тому успадковують ряд методів (таких як callScript). Більш досвідчені тестувальники можуть віддати перевагу створення власних допоміжних суперкласів, щоб розширити клас RationalTestScript, додавши в RationalTestScript власні методи чи замінивши існуючі.

Можна визначити допоміжний суперклас, який Rational Functional Tester буде використовувати при кожному створення або записі сценарію в проекті. Цей допоміжний клас за замовчуванням вказується у властивостях проекту функціонального тесту. Крім того, у властивостях проекту функціонального тесту можна вказати допоміжний суперклас для окремого сценарію на сторінці властивостей сценарію. Після створення сценарій зберігає посилання на суперклас за замовчуванням як на власний допоміжний суперклас.

Допоміжні суперкласи корисні для спільного використання функцій кількома сценаріями. Саме в допоміжний суперклас можна помістити код, який можна буде зробити доступним для кожного сценарію. Будь-який розміщений тут код буде успадковуватися будь-яким допоміжним класом, який розширює допоміжний суперклас.

Виконуючи регресійне тестування, тестувальники зазвичай генерують набір сценаріїв; одночасно з цим розробники оновлюють і змінюють додаток. Більш того, розробники можуть у процесі розробки змінювати властивості деяких об'єктів або ієрархію об'єктів. При відтворенні збереженого сценарію з оновленим додатком у процесі тестування можуть виникати помилки, обумовлені неможливістю знаходження об'єкта.

Коли розробники оновлюють або змінюють додаток, вони змінюють також заголовок вікна відповідно до версії додатка. У збереженій карті сценаріїв зібрані об'єкти з різних карт об'єктів різних екранів додатка. Кожна карта об'єктів використовує один і той же об'єкт вікна в якості батьківського для всіх об'єктів в ієрархії. Заголовок вікна – критично важлива властивість, що використовується для ідентифікації об'єкта. При відтворенні збережених сценаріїв з новою версією додатка, в якій змінено заголовки вікон, будуть часто виникати помилки ObjectNotFound. IBM ® Rational ® Functional Tester вважає змінені заголовки помилками, оскільки вони не відповідають заголовкам у сценарії.

Алгоритми розпізнавання об'єктів Rational Functional Tester засновані не тільки на самому об'єкті. Вони перевіряють також властивості об'єктів, які знаходяться вище в ієрархії, перевіряючи ланцюжок предків до самого верхнього об'єкту.

Щоб Rational Functional Tester перестав вважати зміни властивостей помилками, необхідно зменшити ваговий коефіцієнт критичної властивості до 0. Зрештою, змінений заголовок вікна не є помилкою. У результаті Rational Functional Tester не буде використовувати дану властивість для ідентифікації об'єкта. Проте в Rational Functional Tester глобальної настройки для зменшення вагового коефіцієнта заголовка вікна немає. Це означає, що його необхідно вручну змінити в кожній карті, яка містить відповідний об'єкт. Уявіть, що існують сотні карт об'єктів, які потрібно змінити. Оцініть час, що може знадобитися для кожної ітерації.

Необхідний програмний спосіб для централізованої установки вагових коефіцієнтів властивостей спільних об'єктів, що входять в тест. Замість ручної зміни коефіцієнтів у кожній карті об'єктів або повторних зчитувань властивостей об'єкта в карти можна змінити його під час виконання. У наявний метод додається допоміжний суперклас (helper), який потім викликається з кожного сценарію, де потрібно змінити ваговий коефіцієнт властивості об'єкта. Після додавання такого методу тестувальники отримують можливість виконувати старі сценарії з оновленими додатками, лише злегка змінюючи ці сценарії. Більше того, тепер зміни, наприклад, в заголовку вікна більше не призводять до помилок.

Для створення допоміжного суперкласу, що змінює ваговий коефіцієнт властивостей об'єкта:

1. В Rational Functional Tester клацніть правою кнопкою миші на назві проекту і виберіть Add Test Folder (рисунок 2.5).

Рисунок 2.5 − Створення папки суперкласу

2. Створіть файл допоміжного суперкласу: виберіть File > New > Helper Superclass (рисунок 2.6).

Рисунок 2.6 − Створення папки суперкласу

3. У полі Folder введіть шлях до папки.

4. Виберіть назву проекту в списку Project.

5. Введіть ім'я класу в поле Script name (рисунок 2.7).

Рисунок 2.7 − Вказівка імені допоміжного суперкласу, проекту та папки

6. Натисніть кнопку Finish. Rational Functional Tester створює сценарій в редакторі Java ™ Editor. Цей сценарій можна використовувати для ручного введення Java-коду.

7. Введіть метод, доступний для сценарію. Використовуйте для створення методу наведений в наступному лістингу код, змінивши його відповідно до проекту.

Лістинг 1. Вихідний код допоміжного суперкласу

package superclasses; import java.io.File; import java.util.Enumeration; import com.rational.test.ft.object.map.IMappedTestObject; import com.rational.test.ft.object.map.ObjectMap; import com.rational.test.ft.script.RationalTestScript; public abstract class ScriptSuperClass extends RationalTestScript { public void changeweight(){ // Отримати відносний шлях до карти об'єктів для сценарію. String map=this.getScriptName().toString().replace(".", "//"); String mapName = "resources//"+map+".rftxmap"; // Шлях до проекту String projectDir = "C:\\youtprojectLocation"; // Відкрити файл карти об'єктів File f = new File(projectDir, mapName); ObjectMap om = ObjectMap.load(f); Enumeration e = om.elements(); while (e.hasMoreElements()){ // Знайти об'єкт за його роллю в UI. IMappedTestObject obj = (IMappedTestObject) e.nextElement(); String role = obj.getRole().toString(); if(role.equals("Document")){ Object titleValue = obj.getProperty(".title"); // зменшити ваговий коефіцієнт заголовка. obj.setProperty(".title", titleValue, 0); } // Зберегти карту об'єктів ObjectMap.store(om, f); } } }

Після створення допоміжного суперкласу використовуємо його у сценарії.

Введення допоміжного суперкласу в дію:

1. В Rational Functional Tester клацніть правою кнопкою миші на сценарії, в якому ви збираєтеся використовувати метод щойно створеного суперкласу.

2. Виберіть Properties (рисунок 2.8).

Рисунок 2.8 − Властивості сценарію

3. Виділить Functional Test Script в правій панелі і натисніть кнопку Browse поруч з полем Helper Superclass. Відкриється вікно специфікації.

4. Введіть перший символ імені користувача допоміжного суперкласу в поле Select default helper superclass for the script (вибір допоміжного суперкласу за замовчуванням для сценарію). Rational Functional Tester запропонує список відповідних елементів.

5. Виберіть потрібний елемент і натисніть кнопку OK (рисунок 2.9).

Рисунок 2.9 − Вибір суперкласу для сценарію

6. Викличте метод допоміжного суперкласу в сценарії (рисунок 2.10).

Рисунок 2.10 − Виклик методу суперкласу

Час співробітників, що займаються тестуванням, є цінним ресурсом. У регресійних тестах необхідно концентруватися на істотні зміни у додатку, а не на замінах заголовків вікон та інших незначних змінах. Якщо встановити ваговий коефіцієнт для заголовка вікна в 0, зміни в цьому аспекті тестованого додатка не будуть викликати помилок, і можна буде використовувати свій час для тестування дійсно важливих змін.