10 вразливих місць в інфраструктурі для автотестів, на які варто звернути увагу

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт! Я Ігор Додух, Automation QA Lead. Я працюю в QA ще з 2015 року і практично весь цей час займався саме автоматизацією. За свою кар’єру зробив понад 10 проєктів from scratch, а сьогодні працюю в P2H — міжнародній компанії з українським корінням, де виступаю наставником і ментором для команди з 7 автоматизаторів.

Хочу розказати вам про 10 типових проблем та помилок, які виникають у процесі автоматизації. Особливо в новачків. Сподіваюсь, знайомство з ними допоможе убезпечитись і не допускати їх у вашій роботі.

Одразу невеличкий дисклеймер: цю статтю ми написали у співавторстві з копірайтеркою та редакторкою Катериною Старокольцевою-Скрипник. А тепер прошу до прочитання.

Спочатку про процеси та інфраструктуру

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

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

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

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

Що ж таке ця інфраструктура? Інфраструктура — це набір систем та сервісів, які забезпечують функціонування автоматизованих тестів. Щоб автотести успішно їхали, треба налаштувати інфраструктуру.

Я з командою, наприклад, працюємо за такою системою:

Тести пишуться на мові Python з використанням фреймворку PyTest + Selenium. Далі тести відправляються в GitLab, де за тригером створюється pipeline. Він складається з трьох кроків:

• на першому кроці тести збираються в Docker image, щоб запускатися в ізольованому середовищі;
• на другому кроці тести запускаються, створюється сесія браузера в Selenoid (Selenium Grid) і тести починають взаємодіяти із системою, яка тестується через браузер. Результати виконання тестів збираються в артефакти джоби;
• в наступному кроці результати виконання тестів беруться з артефактів, оброблюються та відправляються в Allure-репорт і Slack-канал.

А тепер перейдемо безпосередньо до складнощів та помилок, які найчастіше роблять при роботі з автотестами.

10 типових проблем та помилок

Локальний запуск

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

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

Оптимальний же варіант — контейнеризація. Ми працюємо з Docker + Kubernetes, вони як ізольовані середовища дають стабільний постійний результат назовні. Тобто тести виконуються незалежно, наче кожен грається у своїй пісочниці.

Також рекомендую використовувати Selenium Grid — чудове рішення, щоб не працювати з локальними браузерами.

Недостатньо ресурсів (RAM, CPU) для роботи з браузерами

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

Обмеження в налаштуваннях тестової системи

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

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

Недостатня кількість browser instances

Якщо говорити про Selenoid чи Selenium Grid, то в роботі з ними важливо налаштувати чітку і правильну кількість browser instance. Програма може використовувати лише конкретну, обмежену кількість браузерів (наприклад, 5 Chrome чи Firefox) в залежності від налаштувань. У нас налаштований один Selenium Grid з 10+ browser instances на кілька проєктів. Ми робимо так, бо це зручно — маємо великого клієнта з кількома підпроєктами, тому немає сенсу підтримувати окремі Selenium Grid.

Таких тестів може бути запущено декілька. У випадку Selenoid нові тести просто переходять у режим очікування, поки попередня сесія завершується. А от з Selenium Grid не все так добре, адже автотест може просто відвалитися у разі відсутності незалучених browser instances. Тому прораховуйте кількість інстансів з урахуванням часу виконання та максимального навантаження.

Погана архітектура тестів

Якщо ви плануєте запускати тести в Selenium Grid, вам потрібно підготувати структуру тестів до паралельного запуску. В першу чергу тести мають бути незалежні між собою, використовувати унікальні тестові дані для кожного тесту. Сама архітектура фреймворку також може передбачати використання однієї тестової сесії на все виконання, і коли зʼявляється більше сесій (апі чи браузера), дані починають плутатись між ними та поведінка тестів стає непередбачуваною.

Browser timeout

У Selenium Grid є така особливість: після простоювання тестів браузер автоматично закривається. Якщо у вас є звичка налаштовувати все шляхом копіювання прикладів з інтернету, то можна необачно накопіпастити параметри, за якими після хвилини простою браузер буде закриватися.

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

Зберігання старих allure reports

Ми переважно працюємо з великою кількістю проєктів, а звіти тестів — це досить ресурсомістка річ зі значною кількістю скриншотів. Останні 20-30-50 запусків тестів автоматично зберігаються у кеші. В результаті ваші тести можуть падати саме через цю проблему. Тому рекомендую раз в якийсь період підчищати репорти, якщо цього не робиться автоматично. Ця звичка збереже вам багато нервів.

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

Неструктуровані репорти

Коли ви бачите, що щось впало — йдіть перевіряти репорт. Щоб швидко розібратися у проблемі — потрібно організувати загальну структуру. Зрозуміло протегані тести, структура відповідно до вимог репортинг-системи (в нашому випадку — Allure), Test Suites, назви самих тестів та всі залежності допоможуть нам побачити, чому тест впав та в якому саме місці.

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

Обмеження доступів

Тести зазвичай крутяться на одному сервері, Selenium Grid — на іншому, а тестова — система іще на іншому. Між цими серверами обов’язково мають бути доступи, без будь-яких обмежень. Неможливість комунікувати між цими серверами може легко фейлити наші тести, що дуже неприємно.

Я раджу, за необхідності, додавати потрібні адреси у white list або створювати публічні адреси доступні в рамках VPN.

Непродуманий scaling

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

Ідеально — запускати тести в паралель за тестовими наборами (Test Suites). Ми, наприклад, досить успішно практикуємо таке рішення. Для зменшення кількості й групування тестів можна використовувати всіма улюблені test design techniques.

І наостанок

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

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

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