Планируя нагрузочное тестирование, лучше инвестировать в реалистичность симуляции или использовать быстрый и грязный подход?
Многие тестировщики стремятся к реализму, но создание реалистичной симуляции может занять много времени и усилий. Это может значительно задержать нагрузочное тестирование, что приведет к серьезным рискам. А как отмечают Кент Бек и Синтия Андрес в книге “Extreme Programming Explained”, выявление проблем на ранней стадии обходится дешевле, чем их устранение в конце жизненного цикла разработки.
Другой вариант – запускать “достаточно хорошее” тестирование как можно раньше. Я бы сказал, что во многих случаях этот подход дает лучшие результаты. Мы можем потратить 20 процентов усилий на настройку теста и при этом узнать 80 процентов того, что мы хотим знать, и выявить проблемы, когда их еще дешево и легко исправить.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Правило 80/20 в тестировании производительности
Правило 80/20, также известное как принцип Парето, гласит, что для многих вещей 20% усилий дают 80% результата.
Создание сценария нагрузочного теста может быть отличным примером действия принципа Парето. Настроить нагрузочный тест довольно сложно. Существует масса параметров, которые можно настроить, чтобы добиться желаемого поведения пользователей и симуляции.
Многие хотят идеально смоделировать реальность в нагрузочном тесте, чтобы точно узнать, сколько реальных пользователей сможет выдержать их производственная система.
К сожалению, имитировать реальность очень сложно. Это значит, что на создание такого теста уходит много времени и сил. Причем даже при значительных усилиях часто упускается какой-то критический аспект, из-за которого имитация оказывается нереалистичной.
Конечным результатом может быть очень дорогой и/или трудоемкий нагрузочный тест, который может так и не дать вам желаемых результатов. А если создание нагрузочного теста обходится организации дорого, скорее всего, там постараются избегать нагрузочного тестирования.
Часто нагрузочное тестирование проводят непосредственно перед запуском, когда времени на устранение обнаруженных проблем практически нет. К тому же, на столь поздней стадии стоимость их устранения будет высокой.
Упрощайте нагрузочное тестирование и запускайте его пораньше
Здесь вступает в силу принцип Парето: если вы не пытаетесь идеально смоделировать реальность, ваша конфигурация будет намного проще. Вы можете обойтись лишь 20 процентами усилий по настройке нагрузочного теста.
В результате вы, возможно, не получите точное число пользователей, которых может обслуживать ваш сайт в производственных условиях. Зато вы узнаете, не отклоняется ли производительность от желаемой, и, вероятно, выявите узкие места.
Когда ваш тест проще настраивать и проводить, вы можете запускать больше тестов на разных этапах разработки и узнать гораздо больше в совокупности, чем узнали бы из одного теста.
Возможность запускать больше тестов на ранних стадиях позволяет обнаружить и устранить проблемы в зародыше. А это обычно означает экономию времени разработки и снижение общей стоимости проекта. Более частое тестирование также способствует повышению уверенности команды и ее вовлеченности в тему производительности продукта.
Лучшие практики нагрузочного тестирования
Все это, конечно, очень хорошо, но как это сделать на практике?
То, где именно отсекать сложности в нагрузочном тестировании, зависит от вашей ситуации. Но, вероятно, стоит использовать упрощенную версию поведения пользователя при разработке нагрузочного теста.
Симулированный пользователь в вашем тесте может быть гораздо более статичным в своем поведении, чем реальный. Возможно, он должен просто получать доступ к заданной последовательности страниц или контента без всякой рандомизации. Или вы можете заставить симулируемых пользователей обращаться к случайно выбранным страницам вашего сайта, игнорируя тот факт, что некоторые страницы посещаются гораздо чаще, чем другие.
Если вы тестируете приложение, управляемое API (например, мобильное приложение), вам лучше не заботиться о потоках пользователей, а попытаться задействовать конечные точки API – либо в комплексе, либо по отдельности.
Допустим, вы знаете, сколько вызовов в секунду будет иметь конечная точка API “X” при 1000 одновременных пользователей. Вы можете запустить нагрузочный тест, генерирующий такое количество запросов в секунду, и посмотреть, сможет ли ваша внутренняя система справиться с этим и где в вашей системе возникают узкие места. Затем проделайте то же самое для каждой конечной точки (конечно, при желании можно использовать несколько конечных точек в одном тесте).
Часто правильное моделирование потоков пользователей не дает много дополнительной информации, зато существенно усложняет конфигурацию нагрузочного теста. Самый простой тест, который можно провести, – это тестирование одной конечной точки API за один раз. Это легко настроить, но если вы проведете такой тест несколько раз для каждой важной конечной точки и на ранней стадии разработки вашего приложения, вы будете уверены в их производительности к моменту релиза.
Доведение симуляции до реалистичной
В проведении более сложных тестов есть определенная польза. Но я бы сказал, что если вы не проводите более простые нагрузочные и стресс-тесты достаточно часто, вам, вероятно, следует начать с них, прежде чем приступать к масштабным, сложным тестам, которые точно имитируют реальность. Простые тесты – это низко висящий плод:
- Проведение простых тестов означает, что каждый тест требует меньше времени и усилий.
- Меньше времени и усилий на тест позволяет проводить больше тестов.
- Большее количество тестов дает вам больше возможностей для итераций и оптимизации настройки тестов.
- Большее количество небольших тестов также позволяет проводить тестирование на более ранних этапах процесса разработки. Это, в свою очередь, позволяет выявлять проблемы на более ранних этапах и снижать затраты на их устранение и риски срыва сроков поставки.
Проведение многочисленных и при этом более простых тестов позволит вам многое узнать о том, как проводить более сложные, масштабные тесты:
- Вы лучше поймете, какой тип трафика создает нагрузку на ваш бэкенд
- Вы увидите, как реагирует ваш бэкенд, и будете знать, где “копать”, какие функции протоколирования использовать и как вообще получить максимальную отдачу от тестирования.
Это означает, что когда придет время проводить сложное, масштабное тестирование, вы будете лучше подготовлены к нему.
Учитывайте, что лучшее – враг хорошего
Реализм – это хорошая цель, но не забывайте о компромиссах. Если вы будете откладывать тестирование до тех пор, пока не создадите идеальную симуляцию, вы упустите возможность устранить проблемы на ранней стадии. Ищите способы начать с простого тестирования, а затем перейти к более сложным симуляциям.
Помните, что раннее тестирование также не является панацеей. Проблемы могут закрасться на поздних этапах разработки, и непрерывное тестирование поможет избежать их устранения в последнюю минуту.
Наконец, помните, что у вас ограниченное время и напряженный график. Если вы сможете получить 80 процентов результатов при 20 процентах трудозатрат, у вас появится больше времени для решения других насущных проблем.
Перевод статьи Ragnar Lonn «When should I start load testing?».