Велика кількість програмних продуктів і компонентів, які створюються і випускаються сьогодні, можуть розглядатися як повністю веб-орієнтовані утиліти, створені для виконання певних завдань у всесвітній павутині.

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

Саме тестування є досить важливою і фундаментальною частиною розробки програмного продукту.

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

Саме тестування допомагає нам знаходити помилки якомога швидше, ще до того, як додаток буде випущено. Швидкість, з якою можна швидко виявити такі проблеми, повністю залежить від обраного вами підходу до тестування, кількості тестувальників, їхнього загального досвіду, а також від інструментів, які ви вирішите використовувати в процесі пошуку помилок.

Існує багато підходів до автоматизації тестування.

Часто можна почути такі абревіатури, як KDT, DDT та BDD. І більшість тестувальників дотримуються таких підходів у процесі побудови методології тестування програмного продукту.

Сенс тестування на основі ключових слів

Тестування за ключовими словами - це спеціалізований підхід, коли використовуються певні ключові слова, що детально описують набір виконуваних дій, які так чи інакше необхідні для завершення певного етапу тестового сценарію.

Спочатку формується набір ключових слів, потім асоціації (певна дія або функція), пов’язані з цим ключовим словом. Це означає, що кожен такий крок тесту, наприклад, відкриття та закриття іконки браузера, клацання мишею на об’єкті, описується спеціальним ключовим словом - відкрити браузер або клацнути.

У процесі тестування за ключовими словами є можливість створювати прості функціональні тести на будь-якому етапі розробки програмного продукту, перевіряючи різні частини програми.

Дуже простий спосіб створити такий тест - записати його. Після запису його можна редагувати та налаштовувати відповідно до необхідних вимог.

У процесі виконання тестових кейсів всі ключові слова інтерпретуються відповідно до використовуваної бібліотеки тестів.

Основні етапи створення тестів ключових слів:

• створення списку ключових слів;
• використовуючи ключові слова як виконувані файли;
• створення групи тестових кейсів;
• робота зі скриптами;
• робота з автоматизованими скриптами.

Переваги такої форми тестування:

• Такий підхід дозволяє групі функціональних тестувальників планувати і проводити автоматизоване тестування ще до того, як розроблений продукт вийде на фінальну стадію.
• Всі тести можна розробляти без спеціальних знань мов програмування.
• Такий підхід не залежить від понять і визначень будь-якої мови програмування або спеціального веб-інструменту.

Тест на основі ключових слів у TestComplete 7

Починаючи з 7-ї версії TestComplete, продукт може автоматично записувати так званий тест, керований ключовими словами.

Надалі ми будемо використовувати скорочену назву KD-тесту.

Процес запису тесту

Спочатку створимо простий KD-тест. Для цього потрібно натиснути правою кнопкою миші на проекті, а саме на елементі KEYWORDSTESTS і вибрати спеціальний пункт меню - ADD - New Item.

У пункті творчого проекту введіть назву нового тесту (назвемо його KDTI).

Після цього у TestComplete буде відкрито нову панель тесту KD.

KD Test Panel

Отже, ми маємо абсолютно порожній тест, який можна легко редагувати (про це ми поговоримо трохи пізніше).

Тепер наше завдання - записати тест, використовуючи доступні можливості програми TestComplete.

Перейдіть на панель інструментів у верхній частині діалогового вікна і натисніть кнопку Записати новий тест. У нашому випадку ми спробуємо записати прості математичні операції на простому калькуляторі (наприклад, додати 2 до 3). В результаті ми отримаємо ось такий цікавий скрипт:

Сценарій

У всьому стовпчику item ми бачимо назву об’єкта, з яким втрутилася система, у стовпчику Operator - поточну операцію (наприклад, ClickButton - імітація натискання на кнопку), у стовпчику Value - встановлений параметр операції (наприклад, назва кнопки, у нашому випадку), а в стовпчику Description - опис поточної операції. І якби ми використовували в такому проекті NameMapping, то значення в колонці item було б, наприклад, більш чітким і читабельним:

Значення у стовпчику позиції

Уявімо, що ми хочемо очистити поле калькулятора перед виконанням наступних операцій. Для цього потрібно натиснути на кнопку Скасувати.

Щоб додати певний крок до вже створеного тесту, скористайтеся спеціальною кнопкою “Додати до тесту”, розташованою на панелі інструментів. Після натискання на неї ви одразу перейдете в режим запису тесту, запишете всі виконані дії і, нарешті, додасте їх в кінець раніше створеного і збереженого сценарію.

Виконані дії

Спеціальні кнопки зі стрілками дозволяють перенести будь-яку додану дію на потрібний рядок. У нашому випадку ми очистимо поле калькулятора перед виконанням необхідних обчислень.

Кнопки зі стрілками

Кнопка “Запустити тест” дозволяє запустити наш тест і переконатися, що все працює належним чином.

Кнопка запуску тесту

Процеси модифікації раніше записаних тестів

Основна відмінність простого тесту від тестів групи KDT полягає в тому, що другі допомагають виконувати ті ж операції, але на основі спеціального візуального редактора, який використовується замість системи написання програмного коду. Крім того, ви можете використовувати спеціальні цикли, пошук за іменами, спеціальні налаштування, а також використовувати умовні вирази для оригінальних блоків перехоплень і винятків.

Почнемо з найпростіших і найзрозуміліших дій. Наприклад, з процесу додавання інформації в журнал повідомлень (Messenger).

У лівій частині панелі інструментів KDT є блок Операції, який допомагає нам додавати нові дії та тести до системи.

Операційний блок

Тут операції класифікуються за спеціальними логічними групами:

• Тестові завдання - операції з елементами керування, робота з меню, а також процес пошуку об’єктів;
• Logging - робота з журналами;
• Check-point - створення та додавання контрольних пунктів;
• Оператори - створення групи умов або циклів;
• Різне - інші технічні можливості (затримка прокрутки, робота індикаторів).

Давайте спочатку виконаємо дуже просту дію: процес відображення в лозі повідомлення “дія 3+2”. Для цього потрібно перемістити елемент Log Message з панелі на такий рядок скрипта, де нам потрібно вивести це повідомлення.

Одразу після цього ми побачимо спеціальне діалогове вікно, в якому встановлюються параметри:

Повідомлення журналу

У цьому вікні ми вкажемо, який тип повідомлення буде використано, і можемо додати до нього текст, якщо бажаємо.

Далі ми натискаємо на кнопку Готово і завершуємо дію або натискаємо на кнопку Далі, щоб одразу перейти на другу сторінку діалогового вікна, де ми можемо вивчити всі параметри і відредагувати їх значення за потреби.

Параметри роботи

В результаті наш проект отримає закінчену структуру:

Готова структура проекту

Так само ми додаємо всі інші елементи скриптів. Наприклад, тепер ми хочемо перевірити значення, як тільки Калькулятор завершить дію.

Таким же чином ми переміщуємо необхідний елемент з Операцій в місце, де нам потрібно провести тестування, і на основі спеціального інструменту Finder Tool відзначаємо спеціальне текстове поле, а потім натискаємо кнопку Далі.

Створити контрольну точку власності

На наступній сторінці вікна Create Property Checkpoint відмічаємо необхідну дію і натискаємо кнопку Next. На третій сторінці вибираємо необхідну умову перевірки. У нашому випадку ми відзначаємо параметр “Дорівнює”.

Параметри порівняння

Параметр рівності

Давайте запустимо наш тест ще раз, щоб переконатися, що все працює належним чином. В результаті ми бачимо результати роботи нашого скрипта:

Результати роботи нашого сценарію

Процес перетворення тестів на основі ключових слів

Хоча тести KDT є абсолютно простими і зрозумілими, не всі операції можна виконати лише з їх допомогою. Певною мірою це пов’язано з особливостями розробки певних мов програмування, а певною мірою - з тим, що лише за допомогою класичної мови програмування можна створювати досить складні конструкції, які не оперують лише KDT.

Тому, якщо ви хочете використовувати записаний тест KDT на обраній мові програмування, вам потрібно буде виконати конвертацію.

Щоб перетворити KDT-документацію на простий тест, потрібно 3 рази клацнути правою кнопкою миші і вибрати спеціальний пункт “Перетворити на скрипт”.

Перетворити на елемент сценарію

Потім у вікні Specify Routine Name, що відкрилося, виберіть конкретний модуль і введіть ім’я функції, в яку буде перетворено текст.

Вікно вказівки назви підпрограми

В результаті отримуємо наступний скрипт:

Приклад сценарію

Як бачимо, нічого складного і при правильній побудові та оптимізації процесів тестування можна підготувати широке середовище, в якому можна одночасно використовувати кілька типів і видів тестування. Адже, як відомо, QA як послуга - це не просто тестування всього функціоналу, а робота з багатьма компонентами на основі численних інструментів і методів.