Gatling and Page Object: a way to performance testing
Denunciar
Katherine GolovinovaSeguir
30 de Jul de 2019•0 gostou•328 visualizações
Gatling and Page Object: a way to performance testing
30 de Jul de 2019•0 gostou•328 visualizações
Baixar para ler offline
Denunciar
Tecnologia
By Ravil Ianbekov at Automation in Action: summer conference. Video: https://youtu.be/ambUpPYepL4 TOPIC DESCRIPTION This talk will be interesting for those who have a lot of experience in UI testing but would like to start testing performance. I will outline the capabilities of the Gatling framework and how to build test logic.
Katherine GolovinovaSeguir
Mais conteúdo relacionado
Similar a Gatling and Page Object: a way to performance testing
HTML Online Course HTML Course Online online html courses html online trainingEvanta Technologies
Vue and Firebase ExperiencesIsatu Conteh
Web Apollo: A Web-based Genomics Annotation Editing Platform. 13ArthGenMonica Munoz-Torres
Web Apollo: A Web-based Genomic Annotation Editing Platform ISB2013Monica Munoz-Torres
Java UI Course ContentNarendrareddyAvulaLI
Java Online TrainingPRO IT Online Training
Mais de Katherine Golovinova
Contract-based Testing Approach as a Tool for Shift LefKatherine Golovinova
Speed up application testing with azure container instancesKatherine Golovinova
Analyzing application activities with KSQL and ElasticsearchKatherine Golovinova
Testing Big Data solutions fast and furiouslyKatherine Golovinova
"Fast & Fail in real life of DevTestSecOps"Katherine Golovinova
Geodistributed databases - what, how, and why?Katherine Golovinova
Último
info_session_gdsc_tmsl .pptxNikitaSingh741518
Improving Employee Experiences on Cisco RoomOS Devices, Webex, and Microsoft ...ThousandEyes
Roottoo Innovation V24_CP.pdfroottooinnovation
Scaling out with WordPressKonstantin Kovshenin
BuilderAI Proposal_MalesniakMichael Lesniak
Mitigating Third-Party Risks: Best Practices for CISOs in Ensuring Robust Sec...TrustArc
Gatling and Page Object: a way to performance testing
- 1. Gatling and Page Object a way to performance testing
- 2. Agenda Prerequisites Step 1: Idea Step 2: Implementation Step 3: Obstacles Step 4: Additional tools Step 5: Lesson learns
- 3. Prerequisites: WebDriver experience: 5 years API testing: 5 months JMeter: 2 training sessions
- 5. Step 1: Idea: Commerce site UI testing API testing
- 6. Performance?
- 7. Desert
- 8. Step 2: Implementation Jmeter Gatling
- 10. Gatling peculiarities Scripting Maven OOTB integration Jenkins OOTB integration
- 13. Page Object like structure
- 14. Another example
- 15. Journeys
- 16. Browsing flow
- 17. Checkout flows
- 18. Feeders and configuration
- 19. Ways of parametrization Array of maps CSV JSON JDBC Redis
- 20. Feeders strategies .queue .random .shuffle .circular
- 21. Feeders and configurations
- 23. Feeders and configurations
- 24. Final set up
- 25. Different load types
- 26. At Once users (nbUsers) Constant users per sec (rate) during (duration)
- 27. RampUsersPerSec(rate1) to (rate2) during (duration) randomized HeavisideUsers(nUsers) over (duration)
- 28. Step 3: Obstacles Environment Requirements Team learning curve
- 29. Additional tools: Gatling maven plugin Gatling Gradle plugin Graphite server Grafana Docker
- 31. Lesson learn Gradle configs Jenkins job set up Feeders Real-time monitoring
- 32. TEST REPORTING BY GATLING
- 33. TEST REPORTING BY GATLING
- 34. THANK YOU!
Notas do Editor
- Всем привет! Думаю, что многие из вас занимаются функциональным тестированием, будь то с использованием автоматизации и/или вручную, и для автоматизации тестирования используют в основном веб драйвер. Кто из вас работал или знаком с этим чудестным инструментом? Надеюсь, мой рассказ поможет тем, кто хотел бы получить новый опыт работы с огромной областью нефункционального тестирования. Здорово, что мы собрались в этом зале, я рад вас приветствовать и мы начнем...
- Итак, о чем сегодня пойдет речь? Я расскажу, с чего началось мое знакомство с перформанс тестированием: - как и, пожалуй, все в жизни, оно началось с идеи и любопытства. Затем следовала фаза имплементации, и в ней я столкнулся с задачами, решение которых потребовало некоторых усилий, бессонных ночей за гуглом и тому подобных практик, с которыми, я уверен, мы все так или иначе знакомы. На 4 шаге появились инструменты, оказавшие помощь в улучшении процессов перформанс тестирования. И завершает мою презентацию слайд об уроках, которые я для себя вынес.
- И вот тот слайд, который мы все знаем - Page Object. Тот самый знаменитый паттерн, к которому можно по-разному относиться, однако нельзя не отметить, что в автоматизации - это самый распространненный и широкоиспользуемый подход к постоению авто-тестов, где страница представлена в виде объекта. Более того, Page object подход поддерживается самом библиотекой Webdriver. Подход PageFactory предполагает lazy - инициализацию полей через динамические прокси.
- теперь, откуда появилась идея? Был коммерс сайт, продававший преимущественно головные уборы. И нами была постоена экосистема для автоматизированного тестирования и его интеграции с мануальным тестированием - от АQA там был Cucumber-JVM/Selenide/Allure (джентельменский набор), строилось все на Maven'e, был Spring для сетапа профайлов для разделения desktop и mobile тестирования. Из API тестирования мы засетапили RestAssured с Jackson парсерами.
- У нас была стратегия того, как выстраивать AQA и MQA взаимодействия на проекте. Мы постоили систему, где вся пирамида тестирования, начиная с Unit-ов и заканчивая UI, стартовала на ветке девелопера. У нас были проверки чек стайла, сонар, деплой кода ветки девелопера на сервер в клауде, инициализация и прогон тестов. Однако у нас не было перформанс тестирования, и мы решили восполнить этот пробел, тем более, что заказчик упоминал это в скоупе работа.
- Первым техническим выбором, который стоял передо мной, стал выбором инструмента. Jmeter/Gatling. С Jmeter я был на тот момент немного знаком, какие-то hello worlds писал, но меня тогда напрягало то, что Jmeter, упращая вход в конфигурацию нагрузки, накладывает свои рамки в организацию и структуру кода. Как я узнал потом, до известной степени это можно сгладить плагинами, позводяющими писать нагрузку на груви/java.
- Гатлинг позволяет с помощью DSL, написанной на скале, организовать нагрузочное тестирование с помощью скала классов.
- В Гатлинг позволяет использовать как record and play подход, который является довольно полезным для понимания, как формируются запросы. Так гатлинг является инструментом, напсанным на Скале, и содержит относительно несложный DSL, позволяющий конфигурировать нагрузку. У Гатлинга есть out of the box интеграция с Maven, что помогло нам интегрировать модуль нагрузочного тестирования в существующий сет up. Так же можно использовать SBT инструмент для скала проектов. Так же есть Jenkins OOTB плагин, позволяющий получать отчетность.
- Gatling не является браузером - он не ранит JS, не применяет CSS стили, реагирует на UI события и так далее.
- Но Гатлинг очень старается им быть - к примеру, через настройку inferHtmlResouces можно сказать инструменту распарсить HTML, найти включенные ресурсы и подгрузить их асинхронно. Можно сетапить кастомные хеадеры. Для того, чтобы мимикрировать под настоящие браузеры, Гатлинг может ранить несколько параллельных соединений, когда он подгружает ресурсы на каком-либо хосте. Гатлинг может кешировать информацию в респонсах, но когда включено кеширование респонсов, чеки не работают
- .queue - дефолтное поведение с использованием итератора. .random - выдергивание случайного значения .shuffle - перемешивает данные, потом используется как кью circular - идет сверху вниз, а как только низ достигнут - наверх.
- Конфигурации можно выносить и хранить в отдельном conf файле.
- Cлева - nUsers, виртуальные пользователи в количестве nUsers поднимаются сразу - по готовности.
- Heavyside - Виртуальные пользователи поднимаются в количестве nUsers будут подниматься ступенями. Слева - рамп ап - в течение определенного времени будут подниматься виртуальные пользователи в количестве nUsers через равные временные интервалы. Временные участки можно рандомизировать.
- Первая вещь, о которой нужно задуматься - энвайрмент. Вообще, перформанс тестирование - очень сложная задача, требующая отдельного скиллсета, знания подсистем и так далее. И одним из требований является адекватная и отвечающая требования среда выполнения Вторым барьером может оказаться незнание требований в том числе и кастомером. Третье - если вы не один, а с вами есть команда - команде может быть довольно сложно работать на скале.