Pull to refresh

Comments 8

Основная проблем gherkin это отсутвтие блоков, что делает его крайне не удобным языком для тестов. Взять те же отели, нам нужно посмотреть что у нас создалась бронь.

Дано незарегистрированный пользователь
Когда пользователь заходит на сайт
И делает бронирование
То создается 1 бронирование в системе

Чтобы проверить, на то что боннирование создалось. Нам надо убедится что создалась 1 запись в бд. Но посравнению с чем?

или нам очищать все бронирования перед началом теста:

Дано незарегистрированный пользователь
И в отеле нет ни одного бронирования
Когда пользователь заходит на сайт
И делает бронирование
То создается 1 бронирование в системе


Т.е. мы или каждый раз чистим базу, или перед тестом сохраняем количество бронирований в глобальной переменной. Что в любом случае дает знатный костыль.

Было удобнее если бы в функционале gherkin появилось что-то вроде:

Дано незарегистрированный пользователь
Создается 1 бронирование в системе:
    Когда пользователь заходит на сайт
    И делает бронирование


Без подобных вещей все тесты написанные для gherkin-спецификаций, подверженны огромной энтропии. Приэтом сами спецификации выглядят прекрасно.

image
Привет. Ты сам задаешь реализации для Gherkin шагов — их можно модифицировать как угодно. Начиная с 3 версии cucumber поддерживаются пост-действия и можно не только делать приведение к начальному состоянию в предыстории, но и после выполнения сценариев.

Никакой проблемы реализовать подобный сценарий нет:

Дано незарегистрированный пользователь
Создается 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;
Не вижу, честно говоря, в этом ничего искуственного. Ну а как еще подготовить эксперимент проверяющий добавление данных в базу? Представьте себе такой эксперимент: мы хотим убедиться, что если налить в чашку 200 мл воды, то вода не перельется через край. (Допустим мы должны проверит вместительность чашки)
Не опустошая чашку перед экспериментом у нас может получиться ложноотрицательный результат. Вы естественно подготовите чашку вылив из нее все содержимое и вытерев ее. Это не кажется вам ничем искуственным? Так и с базой, ничего искуственного в этом нет. Эксперимент всегда упрощает все до необходимого минимума. Мы также не льем в чашку кофе(хотя это будущий пользовательский сценарий), а льем воду, потому что это дешево, удобно и доступно в ходе эксперимента.

Здравствуйте. Интересная статья. Коллеги на одном из проектов пробовали сделать такое. 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ще у них есть решение для браузера, а так как у нас большая часть функционала находится именно там, то в браузере он тоже что-то делает и дает какие-то метрики.

Я правильно понимаю это что-то типа плагина, который настраивается на агенте с которого происходит запуск? Вы его настраивали? Какие метрики можно получить кроме скорости загрузки страниц?
Only those users with full accounts are able to leave comments. Log in, please.