ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2
Denunciar
GoQASeguir
24 de Oct de 2022•0 recomendaciones•113 vistas
ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2
24 de Oct de 2022•0 recomendaciones•113 vistas
Denunciar
Tecnología
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
GoQASeguir
Más contenido relacionado
La actualidad más candente
Interaksi Manusia Dan Komputer 5Hide Maru
Biomolekul pptmunartisya
Protein (kimia hasil pertanian)DaveWattimena
Modul4-software-pptDita Safitri
Antibiotik PenicilinSelly Noviyanty Yunus
Laporan resmi praktikum intUniversitas Diponegoro
Similar a ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» Online QADay 2022 #2
РОМАН МЕЛЬНИК «Testing in CD_ how we implement it, risks etc.» Online QADay 2...GoQA
ОЛЕГ ЗАРЕВИЧ «How did we improve delivery using tests» Lviv QA Day 2019GoQA
Global logic tech talk switching to Angular.jsPavlo Iuriichuk
Павло Юрійчук — Перехід на Angular.js. HowtoGlobalLogic Ukraine
Як покращити Python web UI тестиRomanPobotin1
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»GoQA
![[Knowledge Sharing] - Unit Testing by Pavlo Serdyuk (UKR)](https://cdn.slidesharecdn.com/ss_thumbnails/1-190212161353-thumbnail.jpg?width=1600&height=908&fit=bounds)
Más de GoQA
ІЛОНА НАЗАРОВА «Аудит процесів на проекті очима QA» QADayGoQA
БОГДАН ЛОЗИНСЬКИЙ «Технічні аспекти для нетехнічних: автоматизація та баг реп...GoQA
КАТЕРИНА АБЗЯТОВА «Optimizing Testing Processes on Practical Cases» QADayGoQA
ЄВГЕНІЙ ПАСЄКА «Planning: the Killer of Creativity or the Path to Success» Q...GoQA
СЕРГІЙ ІВАНОВ «TLivium, або історія створення та пілотного запуску програми п...GoQA
ВІКТОРІЯ ПІДОПРИГОРА «Управління командою: Розвиток команди, оцінка навичок і...GoQA
ІГОР ДОДУХ «Інфраструктура для автотестів. Практичний досвід» 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 - може допомогти з чим… Вони перетестували всю систему вздовж і впоперек, знають більшість вразливих і повільних місць і ще навіть на етапі планування автоматизації можуть підказати де може не вистачати ресурсів на конкретних частинах системи. Схожа історія і з дев командою. Вони знають як написана та чи інша частина сервісів, як ведеться взаємодія між різними частинами системи і можуть бути корисними в підвищенні стабільності системи особливо при масштабуванні автотестів.