Рівень 16. Автоматизоване тестування
Рівень 16
Автоматизоване тестування
Що таке автоматизація? Мабуть, коли робот працює, а людина відпочиває
Робот запускає тест
Робот аналізує результат
Робот документує помилки
Людина відпочиває!
Ось так я сміюся, коли хтось так думає про автотести! Насправді автотести — це складна робота з їх написання, підтримки та обслуговування. Усе вищеперелічене, по суті, робить сам тестувальник. Автотести потрібно не лише створити (за тест-кейсами, які ви написали), а й запускати, аналізувати результати, а потім ще й документувати їх.
Цілі автоматизації
Основні завдання автоматизації тестів:
- Значне скорочення часу виконання повторюваних тестових операцій (regression testing)
- Якісне тестування продуктивності веб-застосунків. Ступінь надійності автотестів значно перевищує ручні перевірки й повністю усуває ефект пестициду.
- Єдиний можливий спосіб тестування навантаження.
- Оптимізація тестування: перерозподіл ресурсів відділу тестування (автоматизація дає змогу значно збільшити обсяги тестування силами тієї самої команди).
Критерії успішності автоматизації на проєкті
Наявність цих критеріїв вказує на ступінь корисності автотестів на вашому проєкті:
- Довгостроковий проєкт. Ви знаєте, що проєкт розвиватиметься рік і більше, а отже, буде багато регресійного тестування.
- Формалізований проєкт (наявність тест-плану, наборів тест-кейсів)
- Потреба у великій кількості ітерацій (повторення кейсів від релізу до релізу)
Тестовий скрипт
Тестовий скрипт — це логічно завершена частина коду, збережена в окремому файлі, яка є програмною реалізацією конкретного тест-кейса. Важливо розуміти, що тестовий скрипт — це втілення тестового сценарію в певному середовищі програмування/автоматизації.
Способи створення тестового скрипта:
1) Робота «тестового драйвера» — за допомогою Playback/Record-інструментів, як-от Selenium IDE, Katalon Studio, Testim IO та інших
2) Створення сценаріїв з нуля за допомогою мови програмування високого рівня та тестового фреймворка
Роботи завжди готові тобі допомогти. Головне — навчи нас, запрограмуй, і ми зробимо все, про що попросиш!
Основні труднощі автоматизації тестування ПЗ:
- Потреба постійно оновлювати тестові скрипти
У веб-тестуванні щоразу, коли програмісти змінюють селектори (імена класів елементів у DOM), тести доводиться виправляти, навіть якщо зміни не видно в інтерфейсі. У ручних сценаріях такої проблеми немає.
- Інтерпретація та аналіз результатів тестів
Як ви вже зрозуміли з попереднього практичного завдання, аналіз результатів тестів — це окрема робота, яка зазвичай займає в команди до одного дня під час виконання регресійного циклу перевірок.
- Автоматизація застосовна лише в добре формалізованому середовищі.
На вашому проєкті має бути якісна документація для підтримки автотестів.
Основні властивості, якими має володіти система автоматизованого тестування
- Наявність спеціального сховища тестів, яке дає змогу працювати в багатокористувацькому режимі та вести версійний контроль внесених змін, адже тести часто змінюються (система контролю версій, як-от Git або SVN)
- Наявність центрального сховища тестових ресурсів.
- Наявність системи керування тестовими ресурсами.
- Наявність системи функціонального автономного тестування
- Наявність засобів побудови звітів і кількісної оцінки якості поточної версії продукту.
- Наявність системи розподілу процесу тестування.
Лабораторія автоматизованого тестування
Під лабораторією автоматизації розуміють налаштовану систему із запуску тестів і аналізу їхніх результатів. Над її створенням мають попрацювати: системний адміністратор, архітектор автоматизованих систем, проєктувальники тестів, автотестувальники (розробники автоматизованих сценаріїв). А сьогодні ви виступите в ролі проєктувальників автоматизованих сценаріїв. Давайте розглянемо принцип роботи системи безперервної інтеграції та запуску тестів.
Розглянемо процес запуску автоматизованого тестування та отримання його результатів. Ця схема відображає класичний підхід до процесу автоматизації. Одразу уточнимо, що впроваджувати й підтримувати таку систему можуть лише архітектори автоматизованого тестування, а ми з вами лише ознайомимося з принципами її роботи. Порядок опису компонентів відповідатиме порядку створення лабораторії.
1. WebDriver — фреймворк для веб-автоматизації. Він надає методи взаємодії з веб-сторінкою популярними мовами програмування, як-от Java/Python/C#..., які дають змогу виконувати дії так само, як користувачі: вибір елемента, натискання на нього, вибір властивостей тощо.
2. Тестові скрипти. Це невеликі програми, які є реалізацією автотест-кейса високорівневою мовою програмування. Вони використовують методи фреймворка WebDriver і реалізують кроки тесту у вигляді команд. При цьому структура сайту, що тестується, описується окремо у форматі Page Object і підключається до тесту.
Приклад реалізації кроку тест-кейса:
Цей приклад наведено мовою Python. driver — це екземпляр вебдрайвера, реалізованого в конкретному драйвері, наприклад ChromeDriver, PlaylistPage — це Page Object, а команда assert виконує перевірку.
3. У цій архітектурі хаб представлений Selenium Grid — кластером, що складається з кількох Selenium-серверів. Він призначений для організації розподіленої мережі, яка дає змогу паралельно запускати багато браузерів на великій кількості машин. Наразі Selenium Grid починає застарівати, і паралелізацію можна виконувати засобами системи безперервної інтеграції.
Selenium Grid має топологію «зірка», тобто до його складу входить виділений сервер, який називається «хаб» або «комутатор», а решта серверів називаються «ноди» або «вузли». Мережа може бути гетерогенною, тобто комутатор і вузли можуть працювати під керуванням різних операційних систем, на них можуть бути встановлені різні браузери. Одне із завдань Selenium Grid — «підбирати» відповідний вузол, коли під час старту браузера вказуються вимоги до нього: тип браузера, версія, операційна система, архітектура процесора та низка інших атрибутів.
Раніше Selenium Grid був самостійним продуктом. Тепер фізично продукт один — Selenium Server, але в нього є кілька режимів запуску: він може працювати як самостійний сервер, як комутатор кластера або як вузол кластера — це визначається параметрами запуску.
4. Що стосується конкретних реалізацій фреймворка WebDriver, вони є для всіх основних браузерів. Драйвер — це програмний код, який уміє керувати своїм браузером за допомогою його рідних JavaScript-команд. Причому деякі з них розробляє команда Selenium, а деякі — розробники самих браузерів, як-от Google та Opera (вона ще жива! Хоч її час і минув).
5. Репозиторій і система контролю версій. Це універсальне сховище коду, яке нині використовується для всіх проєктів із розробки ПЗ. Окрім забезпечення множинного доступу, система керування версіями дає змогу зберігати кілька версій одного й того самого документа, за потреби повертатися до ранніх версій, визначати, хто і коли вніс ту чи іншу зміну, та багато іншого. Найпопулярніша СКВ зараз — GIT
6. Останнім і ключовим елементом лабораторії автоматизації є система безперервної інтеграції, яка об'єднує всі попередні компоненти та забезпечує віддалений, безперервний запуск тестів. Вона дає змогу автоматизувати ту частину процесу розробки будь-якого програмного забезпечення, у якій участь людини необов'язкова, забезпечуючи функції безперервної інтеграції. Працює всередині сервлет-контейнера, наприклад Apache Tomcat. Підтримує інструменти систем керування версіями, зокрема CVS, Git та інші. Може збирати проєкти за допомогою Apache Ant і Apache Maven, а також виконувати довільні сценарії оболонки та пакетні файли Windows. Збирання і запуск тестів можна ініціювати різними способами, наприклад після завантаження версії, за розкладом, за запитом на певний URL, після завершення іншого збирання в черзі.
Лабораторія для тестування продуктивності
Важливо розуміти, що навантажувальне тестування (ми вивчатимемо його лише на наступному рівні) належить виключно до автоматизованого тестування як окремий самостійний підвид. Адже навіть важко уявити, що можна навантажувати сервер, відправляючи сотні запитів на хвилину вручну. Для такої розваги довелося б наймати тисячу-другу статистів, які користувалися б цільовим ресурсом. Натомість один тестувальник емулює поведінку одного користувача (записує тестовий скрипт), а потім використовує цей автотест для імітації навантаження. Цей скрипт використовуватимуть машини-генератори навантаження для тестування поведінки сервера в заданому режимі. Лабораторія навантажувального тестування виглядатиме ось так:
Основні аспекти
- Автоматизація завжди тісно пов'язана з тестуванням вручну
- Доцільно автоматизувати лише той функціонал, який добре протестовано вручну, адже ручний тест є більш інтелектуальним
- В ідеалі кожен скрипт має ґрунтуватися на ручному тест-кейсі з належним рівнем деталізації
- Усе, що видається доцільним автоматизувати, потрібно автоматизувати. Насамперед це стосується регресійних тестів
Рівні автоматизованих тестів
- Unit-тести — пишуться програмістами для покриття тестами власного коду. Дають змогу переконатися, що вибрані функції (юніти) повертають правильні результати
- Integration-тести — пишуться програмістами або тестувальниками. Тестують взаємозв'язок юнітів між собою. Можуть використовувати БД та інтерфейси.
- E2E-тести (End to End — від початку до кінця) — тестують увесь функціонал комплексно, так, як його бачить користувач. Використовують GUI для виконання операцій.
Unit-тести vs E2E-тести
1. Хоча End to End тести найкраще імітують реальні користувацькі сценарії, ця перевага стає менш очевидною, якщо придивитися до всіх недоліків, що виникають під час отримання зворотного зв'язку після проходження тестів.
2. Юніт-тести теж мають один суттєвий недолік: навіть якщо юніти чудово працюють ізольовано, ви не знаєте, як вони взаємодіють і чи добре працюють разом.
3. Але навіть коли потрібно протестувати взаємодію модулів програми, необов'язково застосовувати E2E-тести. Для цього можна використати інтеграційний тест. Інтеграційний тест охоплює невелику групу юнітів, часто два блоки, і перевіряє їхню поведінку загалом, пересвідчуючись, що вони послідовно й правильно працюють разом.
Тестова піраміда
Це як МММ, тільки крутіше. Тестова піраміда від Google, яку вони часто радять застосовувати як перше наближення для розподілу тестів у форматі 70/20/10, а саме: 70% юніт-тестів, 20% інтеграційних тестів і лише 10% від усіх тестів — E2E.
Поки я читав цю надзвичайно корисну інформацію про автотести, у мене виникли запитання. Допоможи мені, будь ласка, розібратися. Як завжди, Магістр дасть підказку за хвилину.
1. Що таке автотестування?
2. Які бувають види автоматизованого тестування?
3. Що оптимально автоматизувати?
4. Чим відрізняються види автоматизованого тестування?
Практика створення автотестів
Сьогодні ти навчишся писати автотести! Так, це правда: вір чи ні, але після проходження цього рівня роботи тобі підкорятимуться! А опановувати ми будемо інструмент автоматизації під назвою Selenium IDE.
Selenium IDE — це помічник у виконанні тест-кейсів. Він належить до веб-скрипт-рекордерів із можливими елементами програмування. Цей інструмент є плагіном для Firefox, який уміє записувати дії тестувальника на веб-сторінці. Selenium IDE — найбазовіша програма із сімейства фреймворків для тестування веб-систем. Його старший брат, чистий Selenium, є найпопулярнішою бібліотекою для створення веб-автотестів багатьма мовами програмування. При цьому Selenium IDE не вимагає жодних знань програмування, адже тестування виконується за допомогою зарезервованих команд застосунку. Це, звісно, обмежує свободу дій тестувальника, але для більшості рутинних тестів цього цілком достатньо. Selenium IDE — це:
- Найпростіший інструмент запису/відтворення автотестів;
- Легко засвоюється за короткий час;
- Не потребує особливих навичок програмування
- Перший крок в опануванні автоматизованого тестування.
Як установити Selenium IDE
1) Відкрити/встановити останню версію браузера Mozilla Firefox
2) Через Firefox відкрити сторінку завантаження http://www.seleniumhq.org/download/ і знайти посилання для завантаження плагіна IDE, або скористатися прямим посиланням
4) Клікнути на іконку, і починати працювати!
Як це працює
1) Запустити застосунок;
2) Відкрити сторінку, що тестується;
3) Натиснути кнопку запису ;
4) Виконати необхідні дії на сторінці (покроково з тест-кейса);
5) Відтворити отриманий тест ;
6) Зберегти тест-кейс.
Приклад простого автотест-кейса
Результат
Розширення функціоналу: додавання логіки
1) Для розширення функціоналу IDE можна підключити додатковий користувацький модуль або створити власний.
2) У тестах можна використовувати JavaScript;
Це дає змогу:
- використовувати в тестах умовні оператори (if).
- використовувати безумовні переходи (go to).
- використовувати цикли.
- створювати змінні всередині тесту та працювати з ними.
- використовувати потужність мови JavaScript.
Щоб використовувати логіку в Selenium IDE, потрібно знати JavaScript
Підсумки щодо Selenium IDE
Переваги
1) Open-source проєкт;
2) Швидкість створення тестів;
3) Легкість роботи з IDE;
4) Не потребує знань програмування;
5) Має мінімально необхідний для створення автотестів функціонал;
6) IDE сам складає локатори (майже завжди правильно);
7) Експорт готового сценарію в Selenium RC або WebDriver "справжньою" мовою програмув.;
8) Не потребує фокусування на вікні браузера;
Недоліки
1) Лише Firefox;
2) Лише "прості" тести;
3) Не вміє працювати з нативними вікнами;
4) Не вміє працювати із завантаженням файлів;
5) Коректно працює лише на середній і низькій швидкості;
6) Для логіки потрібен JavaScript
7) Тести недовговічні (наприклад, падають при зміні балансу на картці)
8) Проблеми під час роботи з iframe і pop-up
Чому WebDriver, або огляд іншого ПЗ для автотестів
- WebDriver — безкоштовний проєкт із широкою підтримкою та повним описом російською мовою. Підтримується 5 мовами програмування + можливість підключення різних фреймворків, наприклад Thucydides.
- SilkTest 8.5 Платний проєкт, є crack. Уся документація англійською, підтримка платна, мова лише С++.
- IBM Rational. Платний проєкт. Більшість документації англійською, підтримка платна, мова лише Java. Ціна: $2,600.00.
- TestComplete. Платний проєкт. Крос-браузерність + тестування застосунків. (IE, Firefox, Chrome, Flash, Flex, AIR, Silverlight, Java, .NET compilers (Visual C#)) Ціна: $2,000.00
Selenium WebDriver
Для переходу на Selenium WebDriver необхідно:
1) Знання основ програмування однією з мов: Java, C#, Ruby, Python, Perl, PHP.
2) Знання основних можливостей і команд у Selenium WebDriver
3) Готові набори тест-кейсів і їхні пріоритети.
4) Визначення того, що автоматизувати в першу чергу.
5) Час (багато часу) на розробку автоматизованих тестів.
6) Можна експортувати вже готові тест-кейси з IDE (краще написати заново)
Підсумки щодо Selenium WebDriver
Переваги
WebDriver має всі можливості, доступні в Selenium IDE.
1. Open-source проєкт;
2. Уся потужність і можливості мови Java.
3. Складність тестів — будь-яка (обмежується фантазією автора).
4. Уміє завантажувати файли, аналізувати їх засобами Java.
5. Уміє робити скриншоти.
6. Має можливість виконувати в браузері JavaScript (корисно для складних проєктів з Ajax)
7. Проєкт розвивається та має підтримку.
8. Повноцінне тестування в:
a. Internet Explorer (будь-яка версія)
b. Mozilla Firefox (будь-яка версія)
c. Google Chrome (будь-яка версія)
d. Opera (будь-яка версія)
Недоліки
1. Бібліотека для браузера Safari у розробці.
2. Підтримка профілів є лише в браузері Firefox.
3. WebDriver і досі не підтримує нативні вікна (Basic HTTP authentication).
4. WebDriver не вміє перевіряти дизайн (верстку), техніка ScreenShot based test не рахується :)
5. Потрібно знати одну з мов: Java, C#, Ruby, Python, Perl, PHP
Проблема локаторів і особливості роботи різних браузерів
1) Локатори, написані для Firefox, можуть не підходити для Chrome та Internet Explorer (можуть змінюватися як id елементів, так і загальний xpath)
2) Фокусування на полі введення за замовчуванням у різних браузерах відбувається по-різному.
3) Firefox вставляє текст у кінці, інші браузери — на початку.
4) Якщо в елемента не прописано id або name, автотест сиплеться після найменшої зміни, іноді навіть в іншому функціоналі.
5) Якщо в елемента не прописано id або name, у різних браузерах можуть бути різні xpath і cssid, унаслідок чого крос-браузерність втрачається, і доводиться писати окремі автотести під усі браузери
Складнощі роботи з фреймами та вікнами
Під час роботи із Selenium WebDriver, якщо сторінка сайту дуже складна, має вкладену структуру фреймів або сайт відкриває нові вікна, потрібно бути дуже уважним. У таких випадках найчастіше виникають помилки Element not found, і не тому, що у вас неправильний локатор, а тому, що ви шукаєте не в тому фреймі чи вікні.
// Скидання фреймів, перемикання фокуса на сторінку
driver.SwitchTo().DefaultContent();
// Перемикання на потрібний фрейм
driver.SwitchTo().Frame("main");
Навчальне відео з роботи із SELENIUM IDE
Локатори Selenium, або як знаходяться елементи, до яких застосовуються команди
Локатори використовуються для знаходження елементів, до яких належать команди. Список локаторів Selenium досить великий:
- id – використовується атрибут id (ідентифікатор) елемента
- name – використовується атрибут name елемента
- identifier – використовується атрибут id елемента; якщо за id елемент не знайдено, пошук виконується за атрибутом name
- dom – використовується для пошуку елемента за DOM-виразом, який має починатися з document.
- xpath – використовується для пошуку елемента за XPath-виразом, який має починатися з //
- link – використовується для знаходження посилань із зазначеним текстом.
Бойові поради від Магістра
- Тобі на допомогу даю основні команди Selenium IDE.
- Якщо ваш автотест проходить у покроковому режимі, але падає під час запуску, то, найімовірніше, тест намагається виконати дію над елементом, який ще недоступний на сторінці. У такому разі потрібно додати команду waitForElementPresent + локатор елемента. Вона змусить тест чекати на елемент стільки мілісекунд, скільки ви вкажете в полі Value.
- Якщо чекати нема на що або це не допомагає, можна просто додати паузу — команда pause, але пам'ятайте, що такі команди значно подовжують тест.
- Не забувайте про перевірки! Тест має не лише прокликати весь шлях тест-кейса, а й перевірити очікувані результати за допомогою команд verify та assert.
- Залишайте коментарі між блоками тесту, щоб ваші наміри були зрозумілими.
- Критерії прийняття завдання:
- тести містять перевірки та верифікації кроків
- тести містять коментарі з описом дій
- тести завжди проходять, якщо багів немає
Домашнє завдання та практика
Практичне завдання — створити автотест за допомогою Selenium IDE. Готовий тест потрібно зберегти як html-файл, вивантажити його на мережевий диск і надіслати через форму. Це
Створити автотест потрібно не просто так, а за мануальним тест-кейсом — купівля печива. Для цього перетворіть мануальний тест-кейс на автоматичний, а саме спростіть його та розбийте на незалежні один від одного модулі. Не забувайте додавати у своєму тесті коментарі та перевірки, окрім кроків
Як гадаєш, які запитання будуть у тесті з теорії?
Пссссс... Іди скоріше сюди, я допоможу тобі з автоматизованим тест-кейсом. Завдання це непросте й потребує особливих навичок автоматизації. Щоб писати роботів, потрібно думати як робот — стисло й чітко. Візьми цей приклад автотесту, завантаж його собі та запусти. Запусти тест, і ти зрозумієш, що робить кожна команда, і тобі вже буде легше написати власний тест.
Для переходу на рівень 18 необхідно набрати щонайменше 15 балів (60%) за завдання рівня 17.