Мифы автоматизированного и нагрузочного тестирования

В ней должны быть зафиксированы ключевые элементы процесса тестирования: сценарии нагрузки, профили, описание тестовых и продуктивных стендов, целевые метрики и показатели. Важный момент — согласование методики НТ с заказчиком. Без него тестирование даже не стоит начинать. Грамотно разработанная методика способна существенно сократить сроки проведения нагрузки, обеспечить прозрачность и предсказуемость результата.

2. Показатели работоспособности продукта под нагрузкой могут быть интересны только инженерам по нагрузочному тестированию. Это абсолютно ошибочное мнение. Показатели производительности продукта важны всем, начиная от аналитиков, архитекторов продукта, инженеров инфраструктуры и заканчивая бизнесом. Они важны так же, как и нефункциональные требования, предъявляемые к продукту.

Сложно делать бизнес, не понимая, на что способны программные решения, которыми приходится пользоваться. Формируя архитектуру системы и составляя технологический стек для нее, специалисты должны учитывать ряд факторов: ее производительность, SLA от смежных систем и их способность обеспечить производительность в рамках единого интеграционного взаимодействия.

3. Проверить производительность любой системы можно за 5 человеко-дней. Очень частое заблуждение, причем со стороны не только бизнеса, но и производства. Процесс нагрузочного тестирования включает не только генерацию большого объема данных для его подачи в систему, но и целый комплекс совместных работ различных специалистов. На разных этапах могут быть задействованы:

• бизнес-аналитик;
• системный аналитик;
• архитектор продукта;
• разработчик;
• инженер DBA;
• администратор инфраструктуры;
• инженер по НТ.

Нагрузочное тестирование будет эффективным только при тесном взаимодействии всех участников и общей заинтересованности в результате.

После каждой итерации НТ необходимо:

• анализировать продуктовые и системные метрики, показывающие влияние нагрузки на железо;
• оптимизировать продукт и/или инфраструктуру с помощью тюнинга настроек серверного ПО или самого продукта;
• документировать результаты для последующей настройки продуктивного стенда.

Поскольку тестирование — процесс итеративный, необходимо грамотно оценивать трудозатраты. В некоторых случаях, например, для комплексных интеграционных систем, процесс НТ может занять значительную часть времени, отведенного на всю разработку продукта. Таким образом, проведение тестирования за 5 дней — чистая профанация.

При нехватке времени имеет смысл делать короткий изолированный нагрузочный тест по критичным бизнес-функциям, сравнивающий производительность текущей и предыдущей (релизной) версий продукта. Это позволит убедиться в том, что изменения, внесенные в ПО, не вызвали деградации. Отметим, что это актуально для продуктов, которые «переживают» нагрузочное тестирование не в первый раз: когда уже подготовлены метрики и скрипты по НТ, команда знает узкие места, настроены мониторинг и генераторы нагрузки, собрана статистика показателей производительности на предыдущих версиях.

4. Автоматизация НТ невозможна или малоэффективна. Это не совсем так. Для передовых компаний уже стало традицией включать прохождение сценариев по нагрузочному тестированию в цикл непрерывной интеграции. Для этого выбирают основные сценарии по производительности. Для того чтобы процедуру можно было провести на обычном стенде для функционального тестирования, на него подается не пиковая нагрузка.

Сценарии ограничиваются временем прохождения (не более 1–2 часов) и функциональностью, они также стандартизированы по набору количественных метрик. Цель тестирования — убедиться в том, что уже собранные соседние билды существенно не отличаются по системным и продуктовым показателям при подаче нагрузки.

В данном случае автоматизация нагрузки — надежное подспорье для управления циклом разработки. Она позволяет оперативно узнавать о проблемах, связанных с деградацией показателей производительности, и анализировать их причины. Но данный инструмент плохо работает на краткосрочных проектах, не предполагающих развития (длительностью менее 3–4 месяцев). В этом случае автоматизация нагрузочных тестов — это, скорее, лишние расходы, которые себя не оправдывают.

Автоматизированное тестирование

1. Чем больше автотестов, тем лучше. В данном случае этот количественный показатель напрямую не связан с качеством продукта на выходе. На это влияет качество аналитики и проработки тест-дизайна, на основе которого автоматизировали кейсы. Если за продолжительное время автотесты нашли лишь несколько некритичных дефектов, это повод задуматься, а то ли мы вообще проверяем.

Другой важной составляющей является показатель успешности прогона автотестов. Если из-за проблем со скриптами он стабильно ниже 50%, очевидно, что такая автоматизация неэффективна.

2. Проблему с нестабильными тестами можно решить многочисленными ручными перепрогонами. Flaky tests, или нестабильные тесты — это вечная проблема автоматизации. Избавиться от нее на 100% практически невозможно — все равно какая-то доля тестов даст false positive или false negative. Даже у такого гиганта, как Google, количество flaky tests составляет порядка 1,5%. В других компаниях это число может доходить до 50%. С этим необходимо бороться: подключать разработчиков, дебажить каждый компонент и разбираться, с чем связано конкретное падение автотестов. Причин может быть несколько, начиная c серьезных проблем в самом продукте и заканчивая некорректно настроенной инфраструктурой и ошибками в скриптах.

Обратная ситуация тоже валидна: необходимо убедиться, что автотесты действительно проверяют то, что требуется. Поэтому важно хотя бы раз пройти сценарии вручную и удостовериться, что обнаруженные дефекты коррелируют с тем, что нашли автотесты.

3. 100-процентная автоматизация гарантирует успешный вывод в продуктивную эксплуатацию. Автоматизированное тестирование в первую очередь нужно для сокращения времени на принятие решения. Но на его основе нельзя делать полноценные выводы о выпуске продукта в прод. Это решение должен принимать человек. Здесь важна комплексная оценка: качество тестового покрытия требований, успешность прогона автоматических и ручных кейсов, критичность обнаруженных дефектов, сроки их исправления.

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

Чтобы минимизировать риски, в ряде случаев необходимо провести ручное приемочное тестирование в среде, близкой к продуктивной, с использованием реальных данных. А затем, уже с учетом перечисленных факторов, принимать итоговое решение. Раскатка всех компонент на продуктивные серверы должна осуществляться автоматически, причем в полном соответствии с тем, как это делалось на тестовых и препродакшен-стендах. Для этого можно использовать механизмы Continuous Integration и Continuous Deployment. Мы используем Development Pipeline, настроенный таким образом, чтобы каждое изменение в продукте проходило ряд автоматических проверок и далее раскатывалось на нужный стенд.

4. Автоматизированный Smoke-сценарий в 500 кейсов, прогоняемый за 15 часов, ― это норма.  В теории тестирования Smoke-тестом (или BVT — Build Verification Test) принято называть ограниченный набор проверок, который включает исключительно базовые и стабильные сценарии, направленные на обкатку основных бизнес-функций продукта. Как правило, при удачно организованном процессе автотестирования на Smoke-тест отводится не более 1 часа. Smoke-сценарий — это своего рода Quality gate и триггер для следующего шага. Его успешное прохождение позволяет отдавать билд на ручное тестирование и/или запускать расширенные сценарии автоматизации. Таким образом, Smoke-тест всегда должен быть зеленым. Если он стал красным, это повод поднять флаг, сигнализирующий разработке о том, что в билде возникла проблема и ее нужно устранить.

Автоматизированное тестирование позволяет сократить расходы и решает проблему нехватки ресурсов. Тезис в целом верный, но при правильном применении автоматизации. Давайте разберемся, в каких случаях она эффективна:

1. Подготовка тестовых данных. Отличная практика как первый шаг к автоматизации, особенно когда еще нет определенности в продуктовых сценариях. Также она является надежным подспорьем для функциональных тестировщиков.
2. Регрессионное функциональное тестирование при условии, что бóльшая часть функционала достаточно стабильна с точки зрения изменений, а текущий pass rate регресса не менее 75%. В противном случае много времени будет уходить на поддержку автотестов, особенно если автоматизаторы будут узнавать об изменениях в продукте по факту упавших тестов.
3. Большое количество итераций окружений, например, в случае кросс-браузерного тестирования веб-приложений. Это обширная задача с учетом возможности использования различных операционных систем, устройств и вариативности разрешения экрана. Безусловно, важным фактором здесь является распараллеливание тестов для сокращения времени общего прогона.
4. Непрерывная интеграция. Continuous Integration и Continuous Deployment — практики, по своей сути подразумевающие автоматизированные проверки функционала, поэтому без автотестов тут не обойтись.
5. Работа с данными. Мы говорим о больших наборах данных, формировании дата-сетов, анализе кода/логов на низком уровне — обо всем, что в ручном режиме делать трудоемко и просто неразумно. Сюда же относится тестирование в проектах Machine Learning.

Целесообразность применения автоматизации помогают вычислять калькуляторы ROI (Return on Investment). Подобные расчеты стоит применять для масштабных проектов. Основываясь на входных параметрах, можно рассчитать, в каких случаях использовать автоматизацию разумно, а где следует обойтись ручным тестированием. Понятно, что расчеты будут носить гипотетический характер, так как учесть все риски и нюансы проекта на начальной стадии не всегда возможно. Но если говорить обобщенно, то для краткосрочных проектов с малым количеством релизов выгоднее несколько раз провести ручное тестирование. Важно понимать, что скрипты автотестов и технологические решения по автоматизации (фреймворки) — это отдельные продукты. Недостаточно один раз их разработать — необходимо планировать трудозатраты и ресурсы на их поддержку в соответствии с изменениями.