Как правильно провести исследовательское тестирование?

Всем привет. Поставили задачу узнать максимальную нагрузку которую выдержит система для того чтобы понять нужно ли добавлять мощности или нет(требований или каких то документов для тестирования нет от слова совсем). Я нагрузочным тестированием не особо силен и не совсем понимаю что да как. Описываю ситуацию: Начал с тестирования апи, выбрал первый ендпоинт который отвечает за поиск контрагентов, апи отправляет запрос через Elasticsearch и возвращает список компаний в формате json соответствующих отправленному запросу. В Jmeter создал 3 Thread Group с параметрами (users - 1000, ramp-up period - 100, loop count - 4) постепенно увеличивая кол-во пользователей, в каждой группе создал http request где в параметрах выставил токен и отправляемое значение по которому будет идти поиск (ТОО, КАЗ, ИП) Вопрос первый - правильно ли я вообще всё делаю? Вопрос второй - на какие данные в Summary Report мне опираться когда я буду составлять отчет о тестировании Вопрос третий - как этот отчет вообще должен выглядеть) Вопрос четвертый до какого момента мне продолжать увеличивать кол-во пользователей? до появления ошибок или опять же на какие данные в отчете мне опираться? Вопрос пятый - почему 1 и тот же ендпоинт выдает разное кол-во запросов в секунду при отправке разных значений(ТОО, ИП, КАЗ и т.д)? Заранее благодарю за помощь! Я в 99% случаев занимаюсь функциональным тестированием так что прошу строго не судить если вопрос оказался тупым введите сюда описание изображения


Ответы (1 шт):

Автор решения: Ivan G
  1. правильно ли я вообще всё делаю?

    Я бы увеличил количество итераций или вообще поставил -1, потому что есть ненулевая вероятность, что первые пользователи 4 раза выполнят запрос и все, а следующие еще даже не начнут. Так что в реальности у вас не 1000 пользователей, а меньше.

  2. на какие данные в Summary Report мне опираться когда я буду составлять отчет о тестировании

    Можете отдать "как есть", там особо нечего анализировать.

    Еще посмотрите на HTML Reporting Dashboard, те же результаты там представлены намного нагляднее.

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

  4. В идеале количество транзакций в секунду должно увеличиваться пропорционально нагрузке, но скорее всего в один прекрасный момент оно перестанет увеличиваться и или останется на одном уровне или вообще начнет падать из-за увеличивающегося времени отклика. Это называется saturation point, скорее всего - вы его и ищете.

  5. Потому что у разных сервисов разное время отклика.

→ Ссылка