Конференция завершена. Ждем вас на HighLoad++ в следующий раз!

10 ошибок (высоко)нагрузочного тестирования в 2021 году. О нагрузочном тестировании для разработчиков, девопсов и тимлидов

Тестирование, нагрузочное тестирование

Нагрузочное тестирование

Бэкенд / другое
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Непрерывная интеграция
Методологии и процессы разработки ПО; Сроки и приоритеты
Нагрузочное тестирование

Доклад отозван

Целевая аудитория

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

Тезисы

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

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

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

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

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

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

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

Генеральный директор ITSumma.
15 лет в техническом менеджменте.
Постоянный участник и докладчик конференций Highload++ и РИТ++ с 2010 года.
Интересы: оптимизация производительности, траблшутинг, отказоустойчивость

ITSumma

Работают на рынке с 2008 года. Специализируются на управлении инфраструктурой, веб-разработке, внедрении DevOps-практик, BigData, оптимизации производительности, мониторинге и круглосуточной технической поддержке.

Видео

Другие доклады секции

Тестирование, нагрузочное тестирование