Профессионально организованное нагрузочное тестирование, как это ни удивительно, является уделом enterprise-проектов, банковских и государственных систем. Там работают подготовленные специалисты, выделенные команды, этот процесс поставлен на поток.

Что еще интереснее, ниша нагрузочного тестирования является уделом QA-специалистов, отдельно существуют люди, которые пишут тесты, а отдельно — команды, которые что-то делают по результатам тестирования. Ситуация напоминает дев без опсов, или опс без девов образца 2008-го.

В коммерческой веб-разработке ситуация другая: в большинстве проектов, за исключением совсем крупных, нагрузочное тестирование проводится «постольку-поскольку», чаще всего самими инженерами, которые разрабатывали проект. Время на это выделяется по остаточному принципу, сценарии тестирования прорабатываются часто «на глаз».

Хотя и есть попытки встроить нагрузочное тестирование в CI/CD, у этого есть свои сложности. Как минимум все хотят выкладываться быстрее, а тесты — штука долгая. Да и прод грузить хочется по договоренности, а не в момент выкладки. НТ становится проектом, реализующимся от случая к случаю, и набраться нужного опыта у инженеров из веб-разработки не получается.

В этих условиях может произойти настоящая беда: результаты НТ могут быть восприняты как руководство к действию для бизнеса (начать рекламную кампанию, решить не наращивать инфраструктуру или, наоборот, нарастить сверх меры, преждевременно запуститься). При том, что этим результатам нельзя верить, потому что, например:
* проект тестировали 5 минут вместо длительного времени,
* профиль тестирования был определен неправильно;
* тестировали среду, которая совсем не соответствовала тому, как работает прод;
* сайт отдавал HTTP 200, когда на самом деле не работал;
* и еще миллион причин.

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

Технологический стек: JMeter, Gatling, K6, мозг человека.