Recommended
More Related Content
What's hot
What's hot (20)
Similar to Gatling and Page Object: a way to performance testing
Similar to Gatling and Page Object: a way to performance testing (20)
More from Katherine Golovinova
More from Katherine Golovinova (20)
Recently uploaded
Recently uploaded (20)
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
- 10. Gatling peculiarities Scripting Maven OOTB integration Jenkins OOTB integration
- 14. Another example
- 15. Journeys
- 16. Browsing flow
- 17. Checkout flows
- 19. Ways of parametrization Array of maps CSV JSON JDBC Redis
- 24. Final set up
- 26. At Once users (nbUsers) Constant users per sec (rate) during (duration)
- 27. RampUsersPerSec(rate1) to (rate2) during (duration) randomized HeavisideUsers(nUsers) over (duration)
- 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!
Editor's Notes
- Всем привет! Думаю, что многие из вас занимаются функциональным тестированием, будь то с использованием автоматизации и/или вручную, и для автоматизации тестирования используют в основном веб драйвер. Кто из вас работал или знаком с этим чудестным инструментом? Надеюсь, мой рассказ поможет тем, кто хотел бы получить новый опыт работы с огромной областью нефункционального тестирования. Здорово, что мы собрались в этом зале, я рад вас приветствовать и мы начнем...
- Итак, о чем сегодня пойдет речь? Я расскажу, с чего началось мое знакомство с перформанс тестированием: - как и, пожалуй, все в жизни, оно началось с идеи и любопытства. Затем следовала фаза имплементации, и в ней я столкнулся с задачами, решение которых потребовало некоторых усилий, бессонных ночей за гуглом и тому подобных практик, с которыми, я уверен, мы все так или иначе знакомы. На 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 через равные временные интервалы. Временные участки можно рандомизировать.
- Первая вещь, о которой нужно задуматься - энвайрмент. Вообще, перформанс тестирование - очень сложная задача, требующая отдельного скиллсета, знания подсистем и так далее. И одним из требований является адекватная и отвечающая требования среда выполнения Вторым барьером может оказаться незнание требований в том числе и кастомером. Третье - если вы не один, а с вами есть команда - команде может быть довольно сложно работать на скале.