ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2
•
0 recomendaciones•126 vistas
Online QADay 2022 #2 ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» telegram: wwww.t.me/goqameetup fb: www.fb.com/goqaevent fb: www.fb.com/qaday.org linkedin: https://www.linkedin.com/company/goqa/ Сайт: www.online.qaday.org
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2
Similar a ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2 (20)
Más de GoQA
Más de GoQA (20)
ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2
- 2. About Ihor Dodukh Automation QA Lead in P2H QA since 2015 Leading AQA team Built over 10 projects from scratch Worked with
- 3. ● Infrastructure ● Goals ● Tools ● Configuration example ● Bottlenecks ● Tests scaling ● Collaboration Agenda
- 7. Goals 1 2 3 Tests Store CI/CD
- 8. Goals 1 2 3 4 Tests Store Execute CI/CD
- 9. Goals 1 2 3 4 Tests Store Execute Report 5 CI/CD
- 11. Tools 1 2 Store
- 15. Tools 1 2 3 4 Tests Store Execute Report 5 CI/CD
- 16. Configuration example Tests Push Server A 1 2 3 Build Test Report GitLab Images Docker PyCharm Allure Reports #channels Slack Chrome Firefox Safari Selenoid Microservice #1 Server C Microservice #2 Microservice #N Mock service Tested System Server B
- 17. Bottlenecks ● Browser instances ● Tests architecture ● CPU/RAM consumption ● Browser timeouts ● Access Selenoid
- 18. ● Results history ● Reports structure ● CPU/RAM consumption ● Access Bottlenecks Allure
- 19. ● 3rd-party services ● Mock service ● Scaling ● CPU/RAM consumption ● DB connections limit ● Access Bottlenecks Tested system
- 20. Tests scaling ● Number of tests ● Test suites ● Test design techniques ● Parallel run
- 21. Collaboration ● DevOps ● Customer ● Manual QA ● Developers
- 22. Questions ?
Notas del editor
- Навіть наприклад в jenkins по дефолту генерується HTML репорт у форматі Junit
- Tests architecture - структура і логіка виконання тестів можуть бути не готовими до паралельного запуску. Наприклад обмеження в тестових даних. Залежності між тестами. Available browser instances - що це означає? Коли ви налаштовуєте Селеноід для роботи з тестами, cpu/RAM - як варіант можна після налаштування запустити максимальне навантаження і перевірити стабільність роботи Timeout limits - таймаут браузера в селеніум грід може випадково бути меншим за таймаут очікування в тестах. Таким чином наприклад тести можуть чекати якийсь елемент умовно 1 хв, а браузер після 30 секунд бездіяльності автоматично закривається. Ці цифри умовні і від реальних можуть відрізнятись, але варто тримати в голові подібний розвиток подій. Access - як від тестів до селеноіда, так і з селеноїда до всіх сервісів системи яку ми тестуємо.
- Особливістю роботи Алюр репорту, який не плагін в Jenkins а окремий сервіс, складається в тому що кожні наступні результати генеруються наступним чином. Алюр оперує даними у форматі JSON. Так от, щоб згенерувати новий репорт беруться всі JSON файли попередніх репортів до них додаються JSON результати з нового прогону і далі відправляється команда generate report. І з кожним наступним прогоном навантаження на Алюр збільшується і він їсть більше ресурсів. І в якийсь момент ресурси закінчуються (здається найбільше страждає RAM). Тому важливо слідкувати за тим скільки ви хочете бачити результатів останніх запусків і слідкувати за доступністю ресурсів. Reports structure - всі кроки в тестах мають бути протегані алюр анотаціями і всі перевірки мають бути всередині алюр кроків. В іншому випадку алюр стає менш інформативним і ми не побачимо на якому кроці звалився тест і яка перевірка не була пройдена. Буде просто упавший тест без деталей. Access - якщо у вас гітлаб і алюр на різних серверах, або навіть в різних інфраструктурах (так також буває), то важливо перевіряти доступ між цими серверами. Зазвичай проблеми якщо і є то вирішуються на етапі налаштування. Але бувають різні випадки, інфраструктуру можуть змінювати, і т.д.
- 3rd-party services - автотестам не потрібно залазити на чужу територію. Якщо є 3rd-party service - його потрібно заміняти моком. Mock service - зачасту це допоміжний сервіс який не супер оптимізований і коли автотести починають часто до нього звертатися, мок може не витримувати і або довго відповідає або взагалі падає. Scaling - тестове оточення може бути досить стабільним коли тестувати на ньому вручну. Але коли працюють автотести, частота запитів на систему значно вища і деякі частини системи можуть потребувати скейлінг. Тобто щоб кілька копій одного компоненту працювали в парі і паралельно обробляли запити. CPU/RAM consumption - насправді не тільки вони а ще черги які можуть забиватися Access - Це не вичерпний список можливих вразливих місць. Але з цими даними вже можна полегшити собі життя при пошуку причин нестабільності системи.
- Tests scaling - під цим мається на увазі розростання кількості тестів з часом. В цьому випадку час на виконання тестів збільшується і потрібно шукати шляхи прискорення. В нашому випадку найоптимальнішим варіантом виявився паралельний запуск тестів по сьютам. В такому разі варто враховувати що навантаження як на систему яку тестуємо так і на тестові інструменти зростає. Тут ми знову перетинаємось з тими вразливими місцями (bottlenecks) які бачили на попередніх слайдах.
- Зараз не говоримо шляхи і причини колаборації при повному процесі розробки. Мова йде тільки про інфраструктуру. І саме тому на першому місці я поставив DevOps. DevOps - це ті з ким вам потрібно обовʼязково товаришувати. В першу чергу якщо щось йде не так ви звертаєтесь до девопс. Знаю кейси коли саме через напруженість у комунікації між девопсами і AQA було важко запросити якісь невеликі правки в інфраструктурі. Звичайно це їх робота і вони мають це зробити, але в них досить довго знаходились більш пріоритетні задачі доки проблема не була ескальована вище. Так, це вже більше про софт скіли і комунікацію, але на практиці пункт досить важливий. Customer. Чим Customer може допомогти в інфраструктурі? Ресурсами. Наприклад виділити сервер під селеніум грід або через клієнта запросити більше RAM бо репортинг система почала споживати більше ресурсів. Manual QA - може допомогти з чим… Вони перетестували всю систему вздовж і впоперек, знають більшість вразливих і повільних місць і ще навіть на етапі планування автоматизації можуть підказати де може не вистачати ресурсів на конкретних частинах системи. Схожа історія і з дев командою. Вони знають як написана та чи інша частина сервісів, як ведеться взаємодія між різними частинами системи і можуть бути корисними в підвищенні стабільності системи особливо при масштабуванні автотестів.