Автоматизація тестування вебсайту: Pytest, Allure, Selenium + кілька секретних інгредієнтів

Вже більше року у Acronis новий логотип, про те, як він створювався можна прочитати тут. В рамках ребрендингу оновився і сайт www.acronis.com. Для побудови сайту ми вибрали CMS Drupal. Сайт вийшов класний зовні і непростий всередині: 28 локалей (!), чуйний веб-дизайн, каруселі, визарды, спливаючі вікна… в результаті довелося задіяти безліч різних модулів друпал, деякі з них кастомизировать і писати власні. При роботі такою динамічною, складною системи неминучі помилки. Їх попередженням і виявленням займається команда контролю та забезпечення якості вебсайту. У цій статті ми хочемо поділитися своїм успішним рецептом автоматизації тестування нашого сайту.



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

Чого хочемо?
Отже, починаємо складати вимоги до системи автоматичного тестування. Ми помітили, що на обробку досить простих дефектів витрачається дорогоцінний час, захотілося мінімізувати кількість заводяться в баг-трекер дефектів, але не втрачаючи такі помилки з поля зору. Тому роботу з такими дефектами було вирішено покласти на систему звітів автотестів. Вимагалося, щоб репортинг був дуже зручним, зрозумілим, інформативним і приємним. Таким, щоб будь-який член нашої дружної web-команди міг подивитися звіт, швидко зрозуміти, в чому справа, і пофіксити дефект. Відповідно всі дивляться: розробники фиксят сайт, тестувальники фиксят тести. У підсумку маємо «зелений сигнал світлофора» і GO у продакшн.

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

  • Зручний, зрозумілий, інформативний репортинг;.
  • Паралельний запуск тестів;
  • Параметризація тестів;
  • Успадкування тестових даних по локалям;
  • Тестування в середовищі, найбільш наближеною до користувача;
  • Мінімізація помилкових спрацьовувань;
  • Зручна підтримка і доставка оточення для тестування;
  • Мінімум власної розробки і кастомізації;
  • Open source;
  • Python.
Муки вибору
Першим ділом ми звернули увагу наRobot Framework. Це популярне рішення, яке вже згадувалося публікаціях Acronis. Встановили, почали пробувати. Плюсів, звичайно, багато, але зараз не про них. Основне протипоказання для нас – це робота RF з параметризованными тестами і штатний репортинг результатів для них. Слід зауважити, що абсолютна більшість задуманих нами тестів – це саме параметризрвані тести. У звіті RF, якщо один з випадків у параметризованому тесті провалено, то весь тест позначається як провалений. Також репортинг RF з коробки був незручний для більшості наших хлопців – багато часу йшло на розбір результатів пробних автотестів. Своєрідне «просте» написання тестів за допомогою ключових слів у випадку тестів складніше виявилося непростим завданням. У той же час, завдяки в тому числі і Хабру, ми звернули увагу на Allure від Яндекс.

Подивилися, всім сподобалося, у всіх виникло бажання працювати з цією системою, що, треба зауважити, дуже важливо. Ми вивчили інструмент, переконалися, що проект активно розвивається, має багато готових адаптерів для різних популярних тестових фреймворків, в тому числі і для python. На жаль (а може, й на щастя) виявилося, що для python існує адаптер тільки для фреймворку pytest. Подивилися, шанували, спробували – виявилося, крута штука. Pytest багато вміє, простий у використанні, розширити функціонал за рахунок готових і власних плагінів, велике інтернет-спільнота, ну а параметризація тестів на ньому така, як нам потрібна! Запустили, написали пару пробних тестів, все відмінно. Тепер справа за паралельним виконанням тестів, тут вибір рішень невеликий – тільки pytest-xdist. Встановили, запустили…

Ложка дьогтю
Виявилося, що pytest-xdist конфліктує з Allure Pytest Adaptor. Почали розбиратися, проблема відома, вже тривалий час обговорюється і не вирішена. Також готового рішення для спадкування тестових даних по локалям знайти не вдалося,

Секретні інгредієнти
Щоб оминути ці проблеми, ми вирішуємо написати тул (обгортку) на python. Ця обгортка буде готувати тестові дані з урахуванням спадкування, передавати їх тестів, передавати тестів дані тестового середовища (браузер, наприклад), а також запускати тести в заданий кількість потоків. Після виконання тестів – об'єднувати отримані в різних потоках звіти в один і публікувати кінцеві дані на вебсайт.

Параллелинг вирішили реалізувати досить просто, як паралельний виклик кожного одиничного тесту через командний рядок. При такому підході довелося реалізовувати передачу тестових даних у тест самостійно. Завдяки фикстурам в pytest це справа кількох рядків. Важливо! Також необхідно закоментувати пару рядків (allure-python/allure/common.py), що відповідають за видалення старих файлів в директорії звітів allure адаптера.

Тестові дані для параметризованих тестів вирішено було зберігати в tsv-файлах, статичні тестові дані – в yaml. Приналежність тестових даних до тесту і локалі вирішили визначати за допомогою назв та ієрархії директорій, в яких ці дані знаходяться. Спадкування ведеться від основної базової локалі «en-us», шляхом видалення, додавання унікальних даних. Також в тестових даних можливо використовувати ключове слово 'skip' і 'comment' – для скасування запуску конкретного тестового випадку з зазначенням причини. Таке спадкування, наприклад, якщо необхідно використовувати одні і ті ж дані для всіх локалізацій сайту, то спадкування відбувається автоматично без будь-яких додаткових параметрів. До речі, для даних конфігурацій тесту (оточення, час очікування і т. д.) також реалізували спадкування, але вже не на основі локалізації, а на основі успадкування глобального конфігураційного файлу, конфіг тестів.



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





Останнє, що затьмарювало нашу радість, це випадки зависання окремих запусків у тестовій середовищі. Забув згадати, що в якості середовища для тестування ми вирішили використовувати класичний Selenium (як оточення, найбільш наближене до реального). При великій кількості перевірок у selenium збоїв не уникнути. А також всіма улюблені» помилкові спрацьовування, вони дуже ускладнюють безперервну інтеграцію і «зелений сигнал світлофора» для продакшн.

Подумали і знайшли вихід. Зависання – побороли доопрацюванням нашої обгортки. Додали можливість вказати максимальний час виконання окремого тесту і, якщо він не виконується за вказаний час, ми його грубо перезапускаємо. А помилкові спрацьовування прибрали за допомогою доповнення rerun-xfails для pytest. Цей плагін автоматично перезапускає провалені всі тести, кількість спроб знову ж ставимо в конфігураційному yaml-файл для кожного тесту або загальний.

Епілог
І, нарешті, ось воно – щастя початківця автоматизатора: стабільна зручна робоча система. Вона проста в обслуговуванні, дозволяє провести тестування максимально швидко і без помилкових спрацьовувань, надає дуже зручну звітність про результати тестування.

p.s.
Друзі, за вашим фидбекам тут на Хабре ми б хотіли зрозуміти, наскільки цікавий наш досвід. Є ідея опублікувати вийшло готове рішення у вигляді docker-контейнера.

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

0 коментарів

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