SpiderTest: автотесты своїми руками



Досить часто серед початківців (і не дуже) тестувальників доводиться чути: «от якби я вмів писати автотесты, я б...». Як правило цим «якби» хлопці і обмежуються. На питання: «А чому не вчишся писати?» найчастіше відповідають: «Програмування це не моє». Дійсно, тим для кого програмування темний ліс, поринути у світ автотестів досить важко, адже скрипт сам себе не напише. У цій статті я хотів би поговорити про те, як з ручного тестувальника стати крутим автотестером.

Покопавшись в інтернеті, я знайшов найбільш популярні інструменти для автоматизованого тестування інтерфейсів:
• SilkTest;
• HP QuickTest Pro;
• QF-Test;
• Rational Robot;
• TestComplete;
• TestPartner;
• (хто згадає ще щось прохання писати в коментарі).

При пошуку свідомо ігнорувалися різні фреймворки для тестування, типу Selenium, Cucumber, Watir, Behave, мене цікавили готові інструменти.
Однак, всі представлені вище утиліти (за винятком QF-test) виявилися, по суті, середовищем для розробки, тобто вони пропонували використання свого «простого» скриптової мови для створення автотестів. Як спрощення, можна було записати дії, і вони сформувалися б скрипт, але такі записані тести ні до чого доброго не приводять (та й взагалі це не солідно). Самі по собі інструменти непогані (наприклад SilkTest), але для початківця автотестровщика абсолютно непридатні.
QF-test виявився привабливою робочою конячкою, здатної тестувати і web-інтерфейси і desktop-додатки. Використовуючи його, не потрібно писати скриптів і в цілому робота в ньому побудована зручно. Але у цієї утиліти знайшовся мінус: абсолютно неприваблива ціна (близько 1200 євро).

Перед тим як зажуритися остаточно, опустити руки і продовжувати використання Selenium WebDriver на пару з Cucumber, мені на очі потрапило додаток Костянтина Трофімова, яке я вважав неймовірно перспективним. Додаток називається SpiderTest, завантажити та ознайомитися з ним можна тут (встановлювати від імені адміністратора).

Незважаючи на скромний інтерфейс без модних спливаючих вікон, вилизаних форм і розвиненою панелі управління, утиліта володіє потужним інструментарієм і низьким порогом входження, а саме головне не використовує скриптів. Всі операції, які виконуються користувачем, є в списку дій. Для створення автотеста потрібно тільки вміти складати xpath, а цього можна навчити навіть домогосподарку! (Ось стаття і добре вводять в курс справи)

Інтерфейс програми
Знайомство з SpiderTest починається з головної форми, в якій передбачається створити тест-комплект — набір тестів для перевірки певної функціональності. Тест-комплект зберігається одним файлом в розширенні .sff.
Якщо відкрити заповнений файл тест-комплекту будь-яким текстовим редактором, типу notepad++, то можна побачити, що його структура складена у відповідності з принципами xml.



Повернемося до головної формі SpiderTest: у лівому вікні список тестів, а в правому вікні — детальний опис процедур, що виконуються в тесті. Прапорами відзначені тести, які будуть виконані.



Придумавши назва для першого тесту і зберігши його, ми отримуємо можливість перейти у форму його створення. Для цього потрібно натиснути на кнопку «Ред.» («Редагувати» прим. автора).



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

• Перейти на сторінку — відкриття сторінки в обраному браузері;
• Перейти на вкладку — перемикання на іншу вкладку. Можливо зазначення порядкового номера вкладки, або можна вказати Title;
• Виконати jscript — виконати зазначений jscript;
• Зробити скріншот – створення скріншоту;
• Відкрити в новій вкладці — відкриття бажаної сторінки в новій вкладці: можна вказати адресу в полі «Значення», або вказати id/class/name/xpath посилання (але це працює тільки для тега );
• Ввести текст – процедура введення тексту в зазначений елемент;
• Знайти елемент — пошук елемента на сторінці;
• Клацнути по елементу – імітація кліку лівою кнопкою миші за вказаною елемента;
• Навести вказівник миші на елемент – імітація наведення вказівника миші на елемент;
• Пауза — зупинка виконання тесту на вказаний час (в мілісекундах);
• Порівняти значення елементів — порівняння значень всіх знайдених елементів із зазначеним, якщо хоча б одне значення не дорівнює, то крок вважається проваленим; є можливість порівнювати значення частково, для цього необхідно помістити значення між знаками *;
• Перевірка відсутності елемента — пошук елемента на сторінці (час очікування появи елемента на сторінці 200 мілісекунд), якщо елемент не знайдений, то крок вважається пройденим;
• Порівняння значення атрибута — порівняння значення зазначеного атрибута елемента з зазначеним. Вказувати атрибут слід так: атрибут|значення;
• Очистити поле — очищення зазначеного поля від введеного тексту;
• Порівняти кількість елементів — пошук на сторінці елементи за вказаними критеріями, і потім порівняння їх кількості з зазначеним;

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

Єдина складність, яка може виникнути при складанні тестів – це визначення критерію пошуку. У списку представлено 5 видів критеріїв: id, class, name, xpath та css. Критерії – це способи дістатися до атрибута, з яких потрібно зробити дію, особисто я вибираю xpath і прописую його в колонці «параметри пошуку» і не морочусь, але багато хто вважає це мазохізмом, коли у елемента є id, але тут вже кожному своє.

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

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

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

Кроки і елементи
Наступною цікавою особливістю при створенні автотеста – створення списку часто використовуваних кроків і елементів. Цей список потрібен для спрощення написання сценарію.



Припустимо є дія, яка регулярно відбувається перехід на головну сторінку програми), розумно внести це дія в список часто використовуються і в подальшому не прописувати його, а просто викликати з цього списку (оптимізація!). Список кроків можна редагувати (проте редагувати можна тільки в полі «значення» і «опис», всі інші параметри недоступні).

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

Для редагування списків є спеціальна форма «Змінити список/вставити зі списку», потрапити в яку можна з меню «Дії».



Змінні
Ще однією «фішечки» можна вважати використання змінних. Про зручність використання змінних в програмуванні повинен знати навіть початківець тестувальник.



Приклад використання зміннихНа всяк випадок наведу наочний приклад зручності використання змінної. Ви склали тест для свого застосування на тестовому стенді за адресою mytestingstand.ru. Додали кроки з переходом на всілякі вкладки mytestingstand.ru/portal [1-100] і у вас все чудово працює. Але раптом хитрий менеджер проекту попросив вас протестувати це ж додаток на стенді дослідної експлуатації з адресою prodactionstand.ru. Що робити в такому випадку? Або переписувати адреси, або спочатку задати змінну, а потім тільки змінити значення цієї змінної.




Введення змінної в структуру тесту здійснюється за допомогою знаків $variable$



Змінні, до речі, використовуються різні. Можна вибрати один із 7 представлених методів.

Список методів, що використовуються в SpiderTest• Guid_once – генерація випадкового значення в форматі guid. Генерується один раз і використовується при виклику змінної скрізь одне і те ж
• Guid_always — генерація випадкового значення в форматі guid. При вивезенні змінної генерується кожен раз різний guid.
• Random_once – вибір випадкового значення в діапазоні зазначеного мінімуму і максимуму. Використовується одне значення скрізь
• Random_once(text) — вибір випадкового значення зазначених в однойменному стовпці. Значення зазначаються через крапку з комою. Використовується одне значення скрізь
• Random_always — вибір випадкового значення в діапазоні зазначеного мінімуму і максимуму. Значення змінюється при кожному виклику
• Random_always(text) – вибір випадкового значення зазначених в однойменному стовпці. Значення зазначаються через крапку з комою. Значення змінюється при кожному виклику
• Text – вибір зафіксованого значення.


Варто звернути увагу, що при виконанні тесту в різних браузерах у змінних guid_once і random_once будуть генеруватися в кожному браузері свої.

Є ще одна особливість цієї програми, про яку хотілося б розповісти – це взаємодія з CI-серверами (іншими словами з серверами безперервної інтеграції), але це вже досить складна тема і я планую розповісти про неї в наступній статті.
P. S. Завжди знайдуться люди, яким щось здасться зайвим, а чого-то на їх погляд буде не вистачати. Поділіться в коментарях своїми думками про те, чим можна покращити SpiderTest, а я зв'яжуся з автором і поділюся своїми ідеями.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.