Перевод статьи Shane Evans «Don’t do performance testing in production environments only».
“Тестирование производительности больше неактуально!” “Производительность должны проверять разработчики!” “Никому больше не нужно проводить тестирование производительности в тестовой среде!”.
Это лишь некоторые из утверждений, которые можно услышать, если речь идет о тестировании производительности. По мнению большинства, только PROD-среда имеет значение. Тестовые среды – это пустая трата времени. В этих утверждениях присутствует определенная логика, но все не так просто, как кажется. Тестирование в рабочей среде — в действительности, хорошая идея, но если это ваша единственная методология, вы обрекаете себя на катастрофу.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Как провести тестирование производительности неправильно
Например, в “Черную пятницу” 2014 года у одного известного интернет-магазина произошел сбой в работе, в результате чего он потерял потенциально миллионные доходы, а цены на акции незначительно упали. Отраслевые обозреватели раздули из мухи слона, заявив, что ритейлер должен был провести тестирование по-другому или использовать инструмент X вместо инструмента Y.
На самом деле клиент провел тестирование именно так, как его проинструктировал «ведущий поставщик облачного тестирования». Перед важным событием ритейлер следовал лучшим практикам провайдера по тестированию в рабочей среде. Что же пошло не так?
Скорее всего, команде QA, ответственной за все тестирование корпоративных приложений, не удалось убедить интернет-бизнес использовать те же инструменты, которые они использовали в течение многих лет. Эта команда добилась большого успеха, но, как это часто бывает, онлайн-команда купилась на шумиху о тестировании только в PROD-среде, используя инструмент, который был разработан для использования только в облаке.
Иногда возникает необходимость проводить тестирование и в глобальном масштабе, и в окружении, максимально приближенном к рабочему. Но если бы это был лучший и единственный способ тестирования, разве все не должны были бы делать это постоянно? Абсолютно нет.
Почему не стоит тестировать только в продакшене
Существуют сценарии, в которых тестирование в продакшене является правильным подходом, но эта стратегия подходит не для каждой ситуации. Этот тип крупномасштабного мультигеографического тестирования требует масштабной координации усилий и планирования в нескольких командах одновременно.
Кроме того, вы должны перевести реальных клиентов в предпроизводственную среду, которая была протестирована на работоспособность, и сделать это в период низкого уровня ее использования. Это означает, что тесты должны пройти успешно с первого раза. Они также должны предоставить информацию, необходимую для устранения любых проблем перед наступлением важного дня, иначе все время и энергия будут потрачены впустую.
Чтобы получить максимальную отдачу от проверки методом “большого взрыва”, до нее должно быть проведено несколько этапов тестирования. Эти небольшие, более целенаправленные сценарии должны быть запущены в тестовых средах, при этом все внешние зависимости либо реплицируются, либо виртуализируются таким образом, чтобы вы могли контролировать, являются ли зависимые службы, сетевые условия и ответы положительными или отрицательными.
Цель состоит в том, чтобы устранить все узкие места отдельных компонентов до того, как вся система будет собрана воедино. Таким образом, когда дело дойдет до “большого взрыва”, вы сможете быть уверены, что ни один компонент не выйдет из строя.
Вам также необходимо действительно понять, как именно используется ваша продукция. Кто ваши клиенты, откуда они, что конкретно они делают – вот некоторые из ключевых переменных, которые необходимо выяснить.
Почему не проходят тесты в прод-среде
Вернемся к нашему примеру с крупным интернет-магазином. Оказалось, что протестированные потоки клиентов не отражали реальных действий пользователей в “Черную пятницу”, когда система вышла из строя.
Все ожидали от пользователей стандартный процесса оформления заказа – выбор товара и его оплата в день распродажи. Однако пользователи уже добавили товары в свои корзины за несколько дней до этого, предположительно по несколько раз. Когда часы пробили полночь и товары со скидками поступили в продажу, большинство покупателей просто перешли в корзину для завершения оформления заказа.
Это не типичный сценарий. Единственный способ узнать, что это произойдет, — проанализировать использование в прошлом году и спрогнозировать рост нагрузки на интернет-магазин.
Также имело бы смысл следить за прод-средой в преддверии события, что, вероятно, не было сделано в данном случае. Хотя это вряд ли имело бы значение, если бы это было новое поведение пользователей. Поскольку тестирование методом “большого взрыва”, скорее всего, был проведено за несколько недель до “Черной пятницы”, у команды QA не было бы достаточно времени, чтобы понять, что происходит в рабочей среде, и скоординировать другие тесты.
Используйте непрерывное тестирование
Как же ретейлер из нашего примера мог поступить по-другому? Очевидно, что надо было провести серию тестов, начиная с внутренних систем и используя параметры использования, взятые из прошлогоднего события.
Этот процесс должен был начаться за несколько недель до масштабного тестирования в прод-среде. Заблаговременное начало этих тестов позволяет точно определить любые узкие места в отдельных компонентах, таких как серверы веб-приложений и службы, и обеспечить базовый уровень для последующего сравнения.
Тестирование отдельных компонентов можно запускать автоматически из системы непрерывной интеграции после каждой сборки для выявления любых аномалий, вызванных изменениями в коде каждого компонента. Также можно виртуализировать зависимости, такие как другие службы и сети, чтобы обеспечить согласованные условия, как положительные, так и отрицательные, для каждого запуска.
Затем за пару недель до ожидаемого события можно начинать тестирование методом большого взрыва, используя те же активы, которые мы использовали в лабораторных условиях – то есть те же сценарии с теми же настройками. Нужно планировать два теста вместо одного: первый для сравнения с базовыми тестами в предпроде, а второй для сравнения с тем, что мы видим в рабочей среде.
Это при условии, что оба теста не являются абсолютно одинаковыми. Не забывайте, что тестирование в лабораторных условиях должно быть основано на производственных данных за предыдущий год. Второй тест должен проводиться на основе последних доступных данных, то есть производственных данных, предшествующих событию. Это позволит нам сравнить то, что мы видели в прошлом году, и то, что изменилось с тех пор.
Если мы выполнили все проверки в тестовой среде, значит второй тест будет просто подтверждением наших предположений. Непрерывное тестирование начинается во время разработки, и его не следует откладывать на потом.
Проектирование производительности с помощью мониторинга приложений
Мы рассмотрели лишь один из примеров того, как тестирование производительности может быть перенесено на более ранние этапы жизненного цикла и продолжаться в течение всего времени разработки. Оно не должно прекращаться даже после релиза.
На самом деле, именно здесь результаты тестирования производительности подтверждаются системами производственного мониторинга, как синтетическими, так и реальными. Данные, полученные с помощью систем мониторинга производительности приложений (APM), затем возвращаются в цикл разработки следующего релиза. Это необходимо для улучшения производительности, а не просто для ее тестирования.
Но это уже совсем другая тема.