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.

І наостанок

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

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

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

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А використовувати Allure — це не зашквар?

Погоджуюсь! Можливо порекомендуєте круті альтернативні репортинг системи?

Гарно розвернули.
Не сказав би, що я експер з репортингу. Але зазвичай результати виконання для ретроспективи і аналізу можна збирати прямо в тест-менеджмент системі. TestRail, Zephyr, TestLink etc. Особливо, якщо виконання міксується із мануальним виконанням і є інші учасники гри, яким простіше дивитися в цю систему.
деталізовані репорти можна дивитися на рівні тули/фреймворку, що користається. Pytest, newman, playwright...

Тобто ведеться два потоки: стислий:
— який кейс впав. Описано коротко і простою мовою (тест кейс + assertion Description [+ screenshot]). зберігається «довіку».
— детальний — що траплялося, під час падіння. детальні логи, trace, всі параметри середи запуску). Зберігається певний обмежений час (30, 90, n/2 днів).

На Selenium Grid — хорошая тула остановился. Если человек не знает в наше время про Selenoid — зачем он пишет статьи?

Можливо я неправильно зрозумів ваше питання, але в статті саме про Selenoid і говориться як про основний інструмент.

«звертайтесь до спеціаліста з відповідною експертизою» — експертиза це не Скіл, а процес uk.m.wikipedia.org/wiki/Експертиза

Я думаю, що слово «експертиза» в даному контексті вживалося як англіцизм, тобто набір знань чи навичок.
dictionary.cambridge.org/...​tionary/english/expertise

Гарна та прагматична оглядова стаття.
Все по поличках, чьотко)

Стаття зачіпає тільки верхівку тестової піраміди. Дуже сумно що в 2022 році першим пунктом подібного списку не є «використовуйте UI тести тільки там, де ви не можете перевірити функціонал за допомогою unit/integration/rest тесту(саме у такій послідовності)»

Подскажите, как это связано с инфраструктурой ?

Автор описав базові принципи організації інфраструктури, тим паче із найбільш болісною частиною де є приклад з ui тестами

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

Від цієї статті можна потім просто буде дописати доповнення про апі тести і все.
Ну і може трохи нюансів досипати про меседж кюхі, кафки, бпмс, sqs, пушки ну і тести з інтеграцію до бази.

Та ще окремим питанням, більш болісним можна було б покрити ще мобільні тести, або ембедед.

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

Підписатись на коментарі