Комментарии 8
Дано незарегистрированный пользователь
Когда пользователь заходит на сайт
И делает бронирование
То создается 1 бронирование в системе
Чтобы проверить, на то что боннирование создалось. Нам надо убедится что создалась 1 запись в бд. Но посравнению с чем?
или нам очищать все бронирования перед началом теста:
Дано незарегистрированный пользователь
И в отеле нет ни одного бронирования
Когда пользователь заходит на сайт
И делает бронирование
То создается 1 бронирование в системе
Т.е. мы или каждый раз чистим базу, или перед тестом сохраняем количество бронирований в глобальной переменной. Что в любом случае дает знатный костыль.
Было удобнее если бы в функционале gherkin появилось что-то вроде:
Дано незарегистрированный пользователь
Создается 1 бронирование в системе:
Когда пользователь заходит на сайт
И делает бронирование
Без подобных вещей все тесты написанные для gherkin-спецификаций, подверженны огромной энтропии. Приэтом сами спецификации выглядят прекрасно.
Никакой проблемы реализовать подобный сценарий нет:
Дано незарегистрированный пользователь
Создается 1 бронирование в системе:
Когда пользователь заходит на сайт
И делает бронирование
Не понял в чем проблема с Gherkin.
Дано незарегистрированный пользователь
Дано в системе 0 бронирований от пользователя.
Когда пользователь заходит на сайт
И делает бронирование
То в системе 1 бронирование от пользователя
Да, это можно так решить. Но тест на степ Дано в системе 0 бронирований от пользователя это по факту, DELETE FROM booking WHERE user_id = ?. Или 'TRUNCATE users', что на самом деле не совсем корректный тест, так как мы искуственно подчищаем базу.
Мы проверяем увеличене на единицу.
Хотелось бы иметь что-то вроде
describe `Создается 1 бронирование в системе:`;
before_count = SELECT COUNT(*) FROM bookings where user_id = ?;
run nested steps;
after_count = SELECT COUNT(*) FROM bookings where user_id = ?;
after_count - before == 1;Не опустошая чашку перед экспериментом у нас может получиться ложноотрицательный результат. Вы естественно подготовите чашку вылив из нее все содержимое и вытерев ее. Это не кажется вам ничем искуственным? Так и с базой, ничего искуственного в этом нет. Эксперимент всегда упрощает все до необходимого минимума. Мы также не льем в чашку кофе(хотя это будущий пользовательский сценарий), а льем воду, потому что это дешево, удобно и доступно в ходе эксперимента.
Здравствуйте. Интересная статья. Коллеги на одном из проектов пробовали сделать такое. Cucumber для нагрузки. Доступность облаков будила фантазию. Но не сделали — это не для всех задач подходит.
На другом проекте также использовали функциональные тесты, уже успешно и регулярно. Но не для нагрузки в широком смысле понимания, а как индикатор появления узких мест после внесения небольшой изменений в проект. Думаю, как и у Антона Косякина. Подход такой:
- запуск тестов + сбор метрик производительности (длительность выполнения, память, процессор, количество error/warn/info/debug в логе)
- изменение системы
- запуск тех же тестов + сбор метрик производительности
- сравнение метрик от теста 1 и 2 на одном графике — и так от сборки к сборке
Такой вариант хорошо работает. Если показатели производительности ухудшились, то причина скорее всего в функциональности и изменениях, которые были между запусками тестов. То есть — причина более-менее локализована. Это плюс. И очень быстрая обратная связь разработчикам — это самый главный плюс. Они не боятся вносить изменения в код.
Из минусов — нет точного понимания, какие будут показатели RPS (запросов в сек), TPS (операций в сек). Ведь функциональный тест может зависнуть, и если вчера за минуту выполнялось 60 тестов (1 TPS), то сегодня выполняется только 1 тест в минуту (1/60 TPS) — то есть нагрузка на систему подаётся в 10 раз меньшая, и результаты запусков не сравнимы. Предположу, что в данном подходе такое может случиться. Это открытая модель нагрузки. В JMeter/Gatling/Yandex.Tank контроль TPS/RPS — решаемая задача, с понятными ограничениями.
Также, достаточно дорого поддерживать много генераторов нагрузки, если она подаётся браузером — браузер требует очень много оперативной памяти, JMeter требует сильно меньше, а Gatling, так как гораздо меньше потоков, требует ещё меньше памяти. Для реализации нагрузки 100 операций в минуту через браузер (много)/http-api-robot (только аутентификация), может понадобится 20 станций. С ростом потребностей (1000 операций в минуту), доля http-api-robot будет расти, а доля браузера снижаться. А потом (10 000 операций в минуту) и вовсе решите перейти на модель, когда всю нагрузку подаёт 4 станции с Gatling/JMeter, и ещё на одной параллельно выполняется функциональный тест в BDD-формате — для оценки отзывчивости интерфейса под высокой нагрузкой.
1. В Allure 2 нет вкладки perfomance. Вы что-то самостоятельно кастомизировали? Можете поделиться кастомизацией Allure?
2.
Eще у них есть решение для браузера, а так как у нас большая часть функционала находится именно там, то в браузере он тоже что-то делает и дает какие-то метрики.
Я правильно понимаю это что-то типа плагина, который настраивается на агенте с которого происходит запуск? Вы его настраивали? Какие метрики можно получить кроме скорости загрузки страниц?
Мои коллеги и товарищи делали очень полезный фреймворк для нагрузочных тестов на JVM nonocloud https://m.habr.com/company/jugru/blog/275883/
Cucumber в облаке: использование BDD-сценариев для нагрузочного тестирования продукта