x
© 1995-2019 Компания «Инфосистемы Джет» Разработано в Liqium
Программное обеспечение Мифы автоматизированного и нагрузочного тестирования
Автор
Александр Садыков заместитель начальника отдела тестирования компании "Инфосистемы Джет"
Статей: 2 Фото-факт: 26

24

0.

12

0

3

Управление качеством, или Quality Assurance (QA), — процесс многогранный, так или иначе он присутствует во всех составляющих разработки ПО. Грамотная организация QA способствует ускорению Time-to-Market и выводу на рынок изменений с ожидаемым уровнем качества. Автоматизированное и нагрузочное тестирование — неотъемлемые процедуры QA, позволяющие оптимизировать и дополнить базовые подходы к тестированию. В то же время неквалифицированное использование этих процедур увеличивает цикл разработки и приводит к ошибочному пониманию уровня качества программного продукта. Такое тестирование не дает верной картины того, насколько код качественный.

 

Ниже мы разберем типичные заблуждения, связанные с процессами автоматизированного и нагрузочного тестирования.

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

1.Методика нагрузочного тестирования (НТ) ― никому не нужный документ, на составление которого уходит много времени. Для того чтобы составить грамотную методику, необходима глубокая аналитика, основанная на нефункциональных требованиях, продуктивной статистике использования или проблематике производительности железа и программного продукта на стороне заказчика.

 

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

Случай из практики

 

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

 

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

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

 

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

 

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

Случай из практики 

 

Мы разрабатывали систему с хранилищем данных объемом более терабайта для крупного российского банка. Детальный анализ хотя бы одной метрики производительности в среднем занимает около полуднЯ и может потребовать привлечения DBA-специалиста. Зачастую это затратно для проекта. Автоматизация сбора критичных для системы метрик и сравнение результатов тестов по ним позволили сократить суммарное время на операцию нагрузочного тестирования до пары часов. Это значительно снизило трудозатраты на тестирование и локализацию нефункциональных дефектов от релиза к релизу.

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

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

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

 

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

 

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

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

 

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

 

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

Случай из практики 

 

Мы разрабатывали систему с хранилищем данных объемом более терабайта для крупного российского банка. Детальный анализ хотя бы одной метрики производительности в среднем занимает около полуднЯ и может потребовать привлечения DBA-специалиста. Зачастую это затратно для проекта. Автоматизация сбора критичных для системы метрик и сравнение результатов тестов по ним позволили сократить суммарное время на операцию нагрузочного тестирования до пары часов. Это значительно снизило трудозатраты на тестирование и локализацию нефункциональных дефектов от релиза к релизу.

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

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

 

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

 

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

 

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

Случай из практики 

 

Мы проводили анализ автоматизации для крупной компании: тестировалась сложная интеграционная система. Выяснилось, что было разработано несколько сотен автотестов, которые запускались ежедневно на нескольких окружениях. Доля flaky tests в проекте составляла 60% (!). На стороне заказчика был выделен сотрудник, который регулярно прогонял автотесты до тех пор, пока они не становились зелеными на одном и том же билде. Мы провели аудит стека автотестов, выкинули из него неэффективные, а оставшиеся переписали.

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

 

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

 

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

Случай из практики 

 

Мы проводили длительное ручное и автоматизированное тестирование многокомпонентной системы для крупной компании. Затем выполняли деплой на продуктивную среду. Скрипты для раскатки на тестовые и продуктивные среды разрабатывали разные люди: в первом случае — инженеры по автоматизированному тестированию, во втором — DevOps-инженеры. В итоге продукт разворачивался в иной конфигурации, отличной от той, которая была протестирована. Это приводило к нестабильности работы всей системы и большому числу обращений от конечных пользователей. Мы перешли к одной версии скриптов для «раскатки» продукта. Теперь в подобных проектах все скрипты для CI/CD пайплайна нам разрабатывают только DevOps-инженеры.

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

Случай из практики 

 

В проекте разработки мобильного приложения был Smoke-test, который проходил 5 часов и всегда был красным по разным причинам. К тому же он содержал нестабильные flaky tests. К этому все привыкли, поэтому время, отведенное на стабилизацию продукта, постоянно превышалось, из-за этого релиз регулярно откладывался. После введения культуры короткого зеленого Smoke-теста значительно сократилось время на стабилизацию продукта, и обновления выпустили в срок.

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

 

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

 

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

Случай из практики 

 

На одном проекте для крупного ритейлера нужно было «подхватить» разработанные ранее автотесты. Покрытие было достаточно хорошим. Прогон всех регрессионных автотестов занимал около суток. Заказчик был доволен результатом, поскольку прогон сценариев в ручном режиме длился несколько дней. Но нас эти показатели не устраивали. Оптимизировав тестовые сценарии и использовав более совершенные механизмы для параллельного запуска, мы добились того, что прогон всех сценариев занимал не более полутора часов.

Вывод

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

Следите за нашими обновлениями

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Оформить
подписку на журнал
Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Ваш комментарий отправлен.
После прохождения модерации комментарий будет опубликован на сайте.
Оставить
комментарий
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня