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.

Information

Founded
Location
Россия
Website
pixonic.com
Employees
201–500 employees
Registered