Створення інфраструктури автоматизації тестування за допомогою Rational Functional Tester -

У цій статті Шиной Захаріас (архітектор ПЗ, IBM Rational Functional Tester, IBM) описує створення інфраструктури автоматизації тестування з використанням Rational Functional Tester. Він продемонструє весь процес створення інфраструктури автоматизації, починаючи з введення до Rational Functional Tester та програмного інтерфейсу (API) find. У статті розглядаються приклади та сценарії.

Вступ до IBM Rational Functional Tester

IBM® Rational® Functional Tester є інструментом автоматизованого функціонального та регресійного тестування. Цей продукт надає тестувальникам засоби автоматизованого тестування, що дозволяють виконувати функціональне тестування, регресійне тестування, тестування інтерфейсу користувача і тестування, кероване даними. Rational Functional Tester включає вбудовану підтримку Web-, .Net-, Java-, Siebel-, SAP-додатків та додатків емуляції терміналів. Можна тестувати програми PowerBuilder, AJAX, Adobe Flex, Dojo Toolkit, GEF, документи Adobe PDF, а також програми для zSeries, iSeries та pSeries.

Переваги використання Rational Functional Tester

Переваги Rational Functional Tester:

Автоматизоване тестування з використанням технології ScriptAssure дозволяє тестувальникам створювати автоматизовані тести, стійкі до частих змін інтерфейсу додатків.
Storyboard Testing спрощує візуалізацію та редагування тестів завдяки використанню природної мови та знімків екрану.
Тестування, що керується даними, дозволяє багаторазово виконувати окремі тести з різними наборами тестовихданих.
Сценарії тестування дозволяють комбінувати записані дії користувача за допомогою настроюваних параметрів та можливостей інтелектуального керування сценаріями.
Інтеграція з IBM Rational Team Concert та IBM Rational Quality Manager надає доступ до елементів потоку операцій, а також підтримку логічних або складових SCM-активів тестів.
Створення інфраструктури автоматизації тестування за допомогою багатого набору програмних інтерфейсів.

Попередні умови

Для виконання прикладів цієї статті необхідно мати базові знання IBM Rational Functional Tester та встановити Rational Functional Tester версії 8.2.

Необхідність інфраструктури автоматизації

Більшість інструментів автоматизації просто дозволяє тестувальникам записувати взаємодії з інтерфейсом користувача та відтворювати їх під час тестування програми. Підхід "запис-відтворення" спрощує створення сценаріїв тестування, але ускладнює їхнє обслуговування. Групи тестування записують та перезаписують сценарії після кожної зміни програми. Хоча цей підхід можна використовувати для швидкого створення пакетів контрольних тестів, він має обмеження, оскільки для запису працездатного сценарію необхідний практично готовий додаток, що правильно функціонує. Групи тестування часто відмовляються від моделі "запис-відтворення" та пишуть контрольні тести вручну. Найчастіше тестувальники не можуть використовувати автоматизацію інтерфейсу користувача для регресійного тестування. Алгоритми розпізнавання об'єктів, складні та важкодоступні, роблять зміни у сценаріях громіздкими та у деяких випадках неможливими. Хоча інструмент, що пропонує алгоритми розпізнавання, робить зміни набагато більшекерованими він також має неприємний побічний ефект - не дуже надійне розпізнавання об'єктів.

Rational Functional Tester та інфраструктура автоматизації

Інфраструктура автоматизації дає багато переваг, таких як:

Потужні можливості створення сценаріїв. Можливість використання мов програмування Java та Visual Basic.
Об'єктно-орієнтований підхід до автоматизації тестування.
Алгоритм розпізнавання об'єктів та карти об'єктів.
Можливість динамічного пошуку об'єктів тестування за допомогою властивостей об'єктів.
Багатий набір інтерфейсів для створення сценаріїв без запису об'єкта.
Автоматизувати створення сценаріїв, навіть якщо програма недоступна.
Механізм розширення користувачів управління, що використовує проксі-об'єкт SDK.

Створення інфраструктури автоматизації у Rational Functional Tester з використанням find API

Використання API (програмного інтерфейсу пошуку) find при створенні інфраструктури автоматизації дає такі переваги:

Простий у використанні програмний інтерфейс пошуку (find API) елемента управління в додатку (Application Under Test - AUT) під час виконання.
Не потрібна карта об'єктів.
Стійка робота сценарію навіть за зміни програми.
Можливість використання API find з будь-якими об'єктами test у Rational Functional Tester (наприклад, GuiTestObject, BrowserTestObject і т.д.).
Можливість використання API find з об'єктом RootTestObject у Rational Functional Tester.

У Rational Functional Tester є два види API find:

find (Subitem Properties).
find(Subitem Properties, Boolean mappableOnly).

Поделементи API find

Поделементами можуть бути atChild() , atDescendant() і atList() .

atChild Одна або кілька властивостей, які повинні порівнюватися з прямим нащадком вихідного TestObject. atDescendant Одна або кілька властивостей, які можуть порівнюватися з будь-яким нащадком вихідного TestObject. atList Послідовний список властивостей для порівняння. Поделементами atList є atChild, atDescendant і atProperty. Спочатку порівнюється перший елемент списку, щоб одержати список кандидатів. Нащадки першого списку порівнюються з елементом списку тощо. mappableOnly Аргументи, що обмежують пошук. Якщо значення встановлено в true, пошук буде обмежений об'єктами тестування, що відображаються; інакше буде виконано пошук невідображуваних об'єктів тестування.

sind() з поделементом atChild

Якщо find() використовується в TestObject з поделементом atChild , find() порівнює одну або кілька властивостей із прямим (безпосереднім) нащадком TestObject.

Є три види find() з поделементом atChild:

find(atChild(Property[] properties))
find(atChild(String propName, Object propValue))
find(atChild(String propName1, Object propValue1, String , propName2, Object propValue2 ))

У лістингу 1 показано використання різних варіантів find() з atChild.

Лістинг 1. Різні варіанти find() з atChild

find() з поделементом atDescendant

Якщо find() використовується в TestObject з atDescendant , find() намагатиметься порівняти одну або кілька властивостей з будь-яким нащадком (не обов'язково з прямим/безпосереднім нащадком) TestObject.

Є три види find() з поделементом atDescendant:

find(atDescendant(Property[] properties))
find(atDescendant(String propName, Object propValue))
find(atDescendant(String propName1, Object propValue1, String propName2, Object propValue2 ))

У лістингу 2 показано використання різних варіантів find() з atDescendant.

Лістинг 2. Варіанти find() з atDescendant

find() з поделементом atList

find() з atList надає послідовний список властивостей для порівняння. Поделементами atList є atChild, atDescendant і atProperty. Спочатку порівнюється перший елемент списку, щоб одержати список кандидатів. Їхні нащадки порівнюються з наступним елементом списку. Потім процес продовжується.

Є п'ять типів find() з поделементом atList:

find(atList(subitems))
find(atList(subitems[]))
find(atList(subitems, subitems))
find(atList(subitems, subitems, subitems))
find(atList(subitems, subitems, subitems, subitems))

У лістингу 3 показано використання find() з atList.

Лістинг 3. find() з atList

find() з RootTestObject

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

Існують спеціальні властивості, які застосовуються до find() з RootTestObject. До них відносяться:

.processName Динамічно дозволяє процес тестування. Обмежує пошук процесами із зазначеним ім'ям. .processId Динамічно дозволяє процес тестування. Обмежує пошук процесами із зазначеним ідентифікатором процесу (pid). .domain Пошук у доменах верхнього рівня,що задовольняють властивості .domain. .hWnd Використовується в поєднанні з .domain; якщо властивість .domain задано як Win , відповідне вікно буде активовано для тестування. Handle Використовується в поєднанні з .domain; якщо властивість .domain задано як Net , відповідне вікно буде активовано для тестування.

У лістингу 4 RootTestObject використовується для введення тексту до програми notepad . Програма notepad налаштовується за допомогою майстра Application Configuration Wizard.

Лістинг 4. Приклад використання RootTestObject у сценарії

Створення інфраструктури автоматизації з використанням API find у Rational Functional Tester

Тепер, познайомившись з API find та його варіантами, ви можете розпочати створення інфраструктури автоматизації за допомогою цього інтерфейсу. Інженери автоматизації використовують інтерфейс API find для створення бібліотек, за допомогою яких тестувальники, які не мають технічної підготовки, розробляють сценарії тестування. Бібліотеки приховують складність ідентифікації об'єктів за допомогою інтерфейсів Rational Functional Tester. Користувач-початківець може використовувати зручні високорівневі функції для швидкого створення тестів.

Наприклад, тестувальник, який не має технічної підготовки, може написати тест за допомогою простих функціональних викликів, таких як:

ClickButton
EnterText
ClickLink
ClickImage
SelectComobboxItem
SelectRadio
CheckCheckbox

Тестувальникам потрібно лише ввести ім'я елемента керування чи текст. Пошук конкретного елемента керування за допомогою API find прихований від випробувачів. Інженери з автоматизації пишуть бібліотеки, що містять реалізацію вищезгаданих функцій, та надають їхінженерам-тестувальникам. Бібліотека приховує всі складнощі.

У лістингу 5 наведено приклад реалізації однієї з цих функцій за допомогою API find. Інженери з автоматизації пишуть бібліотеки та функції, а тестувальники використовують ці бібліотеки для створення тесту. Для операції "натиснути кнопку" інженер-тестувальник вказує ім'я (name) чи значення (value) кнопки (елемент управління button). Під час введення тексту в текстове поле використовується ім'я елемента керування текстом та значення тексту. У лістингу 5 наведено приклад для Web-додатків.

Лістинг 5. Приклад функції, що використовує API find

Метод ClickButton() використовує аргумент, у разі - властивість value кнопки. У методі findButton() інтерфейс API find використовується отримання елемента управління, відповідного властивості, переданому в API find. Метод можна налаштувати на пошук елемента керування на основі властивостей, наприклад .text або .name. Цю логіку можна також включити до підпрограми findButton() . Можна також написати різні види методів ClickButton , такі як ClickButtonByValue() , ClickButtonByName() або ClickButtonByLabel() , для пошуку кнопки за значенням, ім'ям або міткою.

У лістингу 5 метод ClickButton приймає аргумент, потім інженер-тестувальник передає властивість .value елемента управління. Якщо значення властивості .value або будь-яких інших властивостей, що використовуються в find() , не доступне, для отримання всіх властивостей і значень можна використовувати інструмент Test Object Inspector, який надається Rational Functional Tester (див. рисунок 1). У попередньому прикладі показаний перший елемент, який повертається find(). В результаті можна одержати більше одного кандидата. Якщо це станеться, змініть підпрограму так, щоб вона створювала більше властивостей і можна знайти унікальний елемент.

Малюнок 1. Інструмент Test Object Inspector

Крім того, інженери автоматизації можуть писати модулі для інших функцій, таких як clickText , EnterText і т.д. (Див. лістинг 6).

Лістинг 6. Приклади бібліотечних функцій, що базуються на API find

Якщо в різних примірниках або збірках програми змінюються деякі властивості, що використовуються в методі find() , можна перетворити значення цих властивостей на регулярні вирази і тим самим мінімізувати обслуговування сценарію.

Висновок

У статті описано використання програмного інтерфейсу find API Rational Functional Tester при створенні інфраструктури автоматизації тестування HTML-додатка. Такий самий підхід можна використовувати при написанні інфраструктур для інших програм, які підтримує Rational Functional Tester.