😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеЧто такое стресс-тестирование: мини-гайд

Что такое стресс-тестирование: мини-гайд

Автор

Дата

Категория

Часто говорят о стресс-тестировании в банковской сфере  — это испытание устойчивости банка, которое проводится виртуально, при помощи компьютерной симуляции. Стресс-тестирование промышленного оборудования — также довольно распространенная процедура. Стресс-тестирование в ИТ — испытание пределов устойчивости программы. В данном гайде обсудим стресс-тестирование веб- и мобильных приложений.

Что такое стресс-тестирование и зачем его делают

Стресс-тестирование — процесс тестирования программного или аппаратного обеспечения на стабильность в условиях высокой нагрузки. Определяются пределы выносливости системы, при которых она выходит из строя. Чаще всего это некое количество одновременных пользователей/запросов к серверу. После этого оценивают качество обработки системой такой ситуации.

Проще говоря, сайт/приложение нагружают до предела, находят «точку отказа», и оценивают реакцию системы.

Пример: текстовый редактор MS Word имеет свой «предел устойчивости» при обработке больших файлов, выдавая ошибку или зависая при попытке скопировать файл более 8 Гб.

Стресс-тестирование должно:

  • Проверить поведение системы в «ненормальных» условиях, при экстремальной нагрузке
  • Определить цифровые значения одновременных пользователей/запросов к системе, при которых она выходит из строя
  • Помочь найти способы нормально отработать ошибки, в первую очередь выдавая релевантные сообщения о них
  • Лучше подготовить систему к возможным экстремальным условиям, в том числе проведением упреждающих мер типа улучшения ее кода, «чистки» баз данных, и подобные коррекционные действия 
  • Проверить «подпороговое» поведение системы, то есть не превышающее лимиты выносливости, но уже близко к ним; особенно что касается пользовательских данных — повреждаются ли они и в каком объеме, теряются или сохраняются, и пр.
  • Помочь обезопасить систему от внешних угроз, поскольку нередко именно в «сверхнагруженных» условиях в системе начинаются внешние атаки

Стратегия стресс-тестирования

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

  1. Определение сценариев и функций, которые будут «нагружены» более всего, и могут вызвать отказ всей системы. Например, в приложении для банкинга это функция перевода денег.
  1. Определение нагрузки на систему в разные дни, минимальное и максимальное значение.
  2. Создание тест-плана, сценариев, тест-кейсов, и тест-сьютов.
  3. Проведение стресс-тестов на 3-4 компьютерах с разной аппаратной конфигурацией (процессор, объем памяти и пр.)
  4. Проведение стресс-тестирования веб-приложения на 3-4 разных браузерах.
  5. Желательно уточнить не только саму «точку отказа», но и значения «немного ниже» и «немного выше» (когда система уже точно не отвечает), контролируя окружение и соответствующие тестовые данные.
  6. Для веб-приложений желательно также проверить поведение системы при низкой скорости подключения.
  7. Не спешить с выводами после 1-2 циклов нагрузки, нужно как минимум 5 циклов.
  8. Определить «идеальное время ответа» сервера и время ответа при достижении «точки отказа».
  9. Оценить поведение системы в «точке отказа» для разных частей/функций — запуск, входы (логины) пользователей, основные функции.

Стресс-тестирование мобильных приложений

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

  • Когда приложение падает при получении/отображении больших объемов данных. Например email-приложение одновременно получает несколько (сот) тысяч писем; шопинговое приложение выводит несколько тысяч карточек товаров
  • Когда тормозит скроллинг, приложение виснет при быстрой/хаотической промотке
  • Когда пользователь не может быстро посмотреть карточку, выполнить все действия с ней, выбрав ее из большого списка карточек
  • Одновременное отправление на сервер множества однотипных действий типа добавления/удаления в «Избранное», добавления товара в корзину и удаления, и подобное
  • Хорошей практикой является «нагрузка» приложения большим объемом данных при слабой мобильной сети типа 2G/3G, и контроль крэшей/зависания с соответствующим сообщением об ошибке
  • Также сквозное E2E-тестирование большим объемом данных в 2G-сети

Собственно, стратегия в случае мобильного приложения:

  • Определить «главные» экраны, содержащие карточки товаров, значимые изображения, с основными функциями — как целевые для стресс-тестирования
  • Определить как целевые наиболее важные функции приложения
  • Создать тестовый стенд (testbed), ориентируясь, в том числе, на смартфоны среднего и нижнего ценового диапазона
  • Желательно проводить параллельное тестирование на многих девайсах одновременно
  • И не пользоваться эмуляторами и симуляторами
  • Не тестировать в Wi-Fi-сетях, они вряд ли обеспечат качественное стресс-тестирование
  • Провести как минимум один стресс-тест «в полевых условиях»

Разница между нагрузочным и стресс-тестированием

Стресс-тестированиеНагрузочное
Ищут пределы выносливости системыПроверка поведения системы при стандарной рабочей нагрузке
Как система поведет себя при превышении предела выносливостиОценка поведения системы (например времени ответа сервера) при ожидаемой нагрузке
Верифицируется обработка ошибокОбработка ошибок не проверяется столь тщательно как при стресс-тесте
Проверка возможности угроз безопасности, утечек памяти, и подобноеНе обязательны такие проверки
Проверка устойчивости системыПроверка надежности системы
Превышение максимального количества пользователей/запросовВозможно очень большое, но все же «рабочее» количество пользователей/запросов

Тест-кейсы

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

В тест-кейсе нужно будет проверить, что, например:

  • При достижении «точки отказа» (максимального количества пользователей/запросов/действий) система отвечает правильным сообщением об ошибке.
  • При различных конфигурациях устройств/процессоров/памяти/скорости сети.
  • Когда система перестает отвечать при достижении большого количества одинаковых пользователей/запросов (например операций покупки в той же карточке товара или операций перевода средств), выдается правильное сообщение об ошибке в операции.
  • Если большое количество пользователей/запросов выполняют разные операции (например один логинится, другой запускает приложение, третий выбирает карточку и так далее), выдается правильное сообщение об ошибке.
  • Время ответа в «точке отказа» является приемлемым (удовлетворяющим требования).
  • Плохая производительность приложения/сайта при плохой скорости сети / плохом покрытии сопровождается соответствующим сообщением об ошибке по таймауту.
  • Также убедиться, что работа приложения/сайта на сервере не ухудшает производительность других приложений/сайтов на том же сервере.

Перед выполнением стресс-тестов следует проверить, что:

  • Все функциональные баги приложения устранены и верифицированы.
  • Успешно проведено сквозное и интеграционное тестирование.
  • В код не будут вноситься правки, которые могут повлиять на процесс стресс-тестирования.
  • Другие команды знают о предстоящем стресс-тестировании и его сроках (часто его проводят ночью).
  • Созданы бэкапы системы на случай серьёзных неполадок.

Инструменты

Проводить такое тестирование вручную, разумеется, неудобно. Да и вряд ли это даст надежные результаты. Существуют автоматизированные инструменты:

Load Runner

Специализированный инструмент от корпорации HP для нагрузочного тестирования, подходит и для стрессового. Работает с т.н. VuGen, то есть генерирует виртуальных пользователей/запросы. Имеются удобные аналитические отчёты, которые можно выводить в виде графиков и диаграмм. 

Neoload

Платный инструмент для тестирования веб- и мобильных приложений. Способен симулировать более тысячи одновременных пользователей, проверяет производительность системы и время ответа сервера. Облачная интеграция как нагрузочного, так и стресс-тестирования. Хорошо масштабируется и довольно простой. 

JMeter

С открытым кодом, работающий с JDK 5 и выше. В основном применяется для веб-приложений. Также может тестировать LDAP, FTP, JDBC. 

Grinder

Так же с открытым кодом и тоже Java-based. Можно динамически менять параметры в процессе. Хорошая система репортов и assertions, что помогает в анализе результатов. Есть консоль, которая применяется в качестве IDE для создания и изменения тестов и агентов, регулируя нагрузку. 

Webload

Бесплатный инструмент, имеющий и платную версию. Но в бесплатной версии ограничение до 50 пользователей. Поддерживает и мобильные приложения. Работает со всеми протоколами: http, https, Push, ajax, есть также IDE, консоль генерации нагрузки, панель анализа, и средства интеграции с Jenkins, APM.

Итак

  • Стресс-тестирование — это проверка системы под экстремальной нагрузкой с целью найти «точки отказа». 
  • Такое нефункциональное тестирование выполняется обычно в конце цикла
  • Стресс-тестирование представляет собой экстремальный случай нагрузочного
  • В целом, 90% случаев инструмент для нагрузочного тестирования может быть тот же, что и для стресс-тестирования. Поэтому не лишним будет ознакомиться с Топ-15 бесплатных инструментов для нагрузочного тестирования.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
$1100*
медианная зарплата в QA в ноябре 2021

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

💬 Telegram-обсуждения

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

Последние комментарии