Gatling and Page Object: a way to performance testing

Editor's Notes

• #2: Всем привет! Думаю, что многие из вас занимаются функциональным тестированием, будь то с использованием автоматизации и/или вручную, и для автоматизации тестирования используют в основном веб драйвер. Кто из вас работал или знаком с этим чудестным инструментом? Надеюсь, мой рассказ поможет тем, кто хотел бы получить новый опыт работы с огромной областью нефункционального тестирования. Здорово, что мы собрались в этом зале, я рад вас приветствовать и мы начнем...
• #3: Итак, о чем сегодня пойдет речь? Я расскажу, с чего началось мое знакомство с перформанс тестированием: - как и, пожалуй, все в жизни, оно началось с идеи и любопытства. Затем следовала фаза имплементации, и в ней я столкнулся с задачами, решение которых потребовало некоторых усилий, бессонных ночей за гуглом и тому подобных практик, с которыми, я уверен, мы все так или иначе знакомы. На 4 шаге появились инструменты, оказавшие помощь в улучшении процессов перформанс тестирования. И завершает мою презентацию слайд об уроках, которые я для себя вынес.
• #5: И вот тот слайд, который мы все знаем - Page Object. Тот самый знаменитый паттерн, к которому можно по-разному относиться, однако нельзя не отметить, что в автоматизации - это самый распространненный и широкоиспользуемый подход к постоению авто-тестов, где страница представлена в виде объекта. Более того, Page object подход поддерживается самом библиотекой Webdriver. Подход PageFactory предполагает lazy - инициализацию полей через динамические прокси.
• #6: теперь, откуда появилась идея? Был коммерс сайт, продававший преимущественно головные уборы. И нами была постоена экосистема для автоматизированного тестирования и его интеграции с мануальным тестированием - от АQA там был Cucumber-JVM/Selenide/Allure (джентельменский набор), строилось все на Maven'e, был Spring для сетапа профайлов для разделения desktop и mobile тестирования. Из API тестирования мы засетапили RestAssured с Jackson парсерами.
• #7: У нас была стратегия того, как выстраивать AQA и MQA взаимодействия на проекте. Мы постоили систему, где вся пирамида тестирования, начиная с Unit-ов и заканчивая UI, стартовала на ветке девелопера. У нас были проверки чек стайла, сонар, деплой кода ветки девелопера на сервер в клауде, инициализация и прогон тестов. Однако у нас не было перформанс тестирования, и мы решили восполнить этот пробел, тем более, что заказчик упоминал это в скоупе работа.
• #9: Первым техническим выбором, который стоял передо мной, стал выбором инструмента. Jmeter/Gatling. С Jmeter я был на тот момент немного знаком, какие-то hello worlds писал, но меня тогда напрягало то, что Jmeter, упращая вход в конфигурацию нагрузки, накладывает свои рамки в организацию и структуру кода. Как я узнал потом, до известной степени это можно сгладить плагинами, позводяющими писать нагрузку на груви/java.
• #10: Гатлинг позволяет с помощью DSL, написанной на скале, организовать нагрузочное тестирование с помощью скала классов.
• #11: В Гатлинг позволяет использовать как record and play подход, который является довольно полезным для понимания, как формируются запросы. Так гатлинг является инструментом, напсанным на Скале, и содержит относительно несложный DSL, позволяющий конфигурировать нагрузку. У Гатлинга есть out of the box интеграция с Maven, что помогло нам интегрировать модуль нагрузочного тестирования в существующий сет up. Так же можно использовать SBT инструмент для скала проектов. Так же есть Jenkins OOTB плагин, позволяющий получать отчетность.
• #12: Gatling не является браузером - он не ранит JS, не применяет CSS стили, реагирует на UI события и так далее.
• #13: Но Гатлинг очень старается им быть - к примеру, через настройку inferHtmlResouces можно сказать инструменту распарсить HTML, найти включенные ресурсы и подгрузить их асинхронно. Можно сетапить кастомные хеадеры. Для того, чтобы мимикрировать под настоящие браузеры, Гатлинг может ранить несколько параллельных соединений, когда он подгружает ресурсы на каком-либо хосте. Гатлинг может кешировать информацию в респонсах, но когда включено кеширование респонсов, чеки не работают
• #21: .queue - дефолтное поведение с использованием итератора. .random - выдергивание случайного значения .shuffle - перемешивает данные, потом используется как кью circular - идет сверху вниз, а как только низ достигнут - наверх.
• #24: Конфигурации можно выносить и хранить в отдельном conf файле.
• #27: Cлева - nUsers, виртуальные пользователи в количестве nUsers поднимаются сразу - по готовности.
• #28: Heavyside - Виртуальные пользователи поднимаются в количестве nUsers будут подниматься ступенями. Слева - рамп ап - в течение определенного времени будут подниматься виртуальные пользователи в количестве nUsers через равные временные интервалы. Временные участки можно рандомизировать.
• #29: Первая вещь, о которой нужно задуматься - энвайрмент. Вообще, перформанс тестирование - очень сложная задача, требующая отдельного скиллсета, знания подсистем и так далее. И одним из требований является адекватная и отвечающая требования среда выполнения Вторым барьером может оказаться незнание требований в том числе и кастомером. Третье - если вы не один, а с вами есть команда - команде может быть довольно сложно работать на скале.