- Что такое стресс-тестирование
- Стратегия тестирования
- Стресс-тесты мобильных приложений
- Разница между нагрузочным и стресс-тестированием
- Тест-кейсы
- Инструменты
Часто говорят о стресс-тестировании в банковской сфере — это испытание устойчивости банка, которое проводится виртуально, при помощи компьютерной симуляции. Стресс-тестирование промышленного оборудования — также довольно распространенная процедура. Стресс-тестирование в ИТ — испытание пределов устойчивости программы. В данном гайде обсудим стресс-тестирование веб- и мобильных приложений.
Что такое стресс-тестирование и зачем его делают
Стресс-тестирование — процесс тестирования программного или аппаратного обеспечения на стабильность в условиях высокой нагрузки. Определяются пределы выносливости системы, при которых она выходит из строя. Чаще всего это некое количество одновременных пользователей/запросов к серверу. После этого оценивают качество обработки системой такой ситуации.
Проще говоря, сайт/приложение нагружают до предела, находят «точку отказа», и оценивают реакцию системы.
Пример: текстовый редактор MS Word имеет свой «предел устойчивости» при обработке больших файлов, выдавая ошибку или зависая при попытке скопировать файл более 8 Гб.
Стресс-тестирование должно:
- Проверить поведение системы в «ненормальных» условиях, при экстремальной нагрузке
- Определить цифровые значения одновременных пользователей/запросов к системе, при которых она выходит из строя
- Помочь найти способы нормально отработать ошибки, в первую очередь выдавая релевантные сообщения о них
- Лучше подготовить систему к возможным экстремальным условиям, в том числе проведением упреждающих мер типа улучшения ее кода, «чистки» баз данных, и подобные коррекционные действия
- Проверить «подпороговое» поведение системы, то есть не превышающее лимиты выносливости, но уже близко к ним; особенно что касается пользовательских данных — повреждаются ли они и в каком объеме, теряются или сохраняются, и пр.
- Помочь обезопасить систему от внешних угроз, поскольку нередко именно в «сверхнагруженных» условиях в системе начинаются внешние атаки
Стратегия стресс-тестирования
Такое тестирование типологически относится к нефункциональному тестированию, поэтому проводится после функциональных тестов. Тест-кейсы, подходы и инструменты зависят от приложения/сайта, и выбираются ситуативно. Вместе с тем, существуют общие правила (далее стратегия стресс-тестирования веб-приложения в ее общем, «эконом-варианте»):
- Определение сценариев и функций, которые будут «нагружены» более всего, и могут вызвать отказ всей системы. Например, в приложении для банкинга это функция перевода денег.
- Определение нагрузки на систему в разные дни, минимальное и максимальное значение.
- Создание тест-плана, сценариев, тест-кейсов, и тест-сьютов.
- Проведение стресс-тестов на 3-4 компьютерах с разной аппаратной конфигурацией (процессор, объем памяти и пр.)
- Проведение стресс-тестирования веб-приложения на 3-4 разных браузерах.
- Желательно уточнить не только саму «точку отказа», но и значения «немного ниже» и «немного выше» (когда система уже точно не отвечает), контролируя окружение и соответствующие тестовые данные.
- Для веб-приложений желательно также проверить поведение системы при низкой скорости подключения.
- Не спешить с выводами после 1-2 циклов нагрузки, нужно как минимум 5 циклов.
- Определить «идеальное время ответа» сервера и время ответа при достижении «точки отказа».
- Оценить поведение системы в «точке отказа» для разных частей/функций — запуск, входы (логины) пользователей, основные функции.
Стресс-тестирование мобильных приложений
Процесс такого тестирования (особенно нативных приложений), отличается от процесса с веб-приложениями. Чаще всего тестирование заключается в обработке огромных объемов данных в наиболее часто используемых экранах приложения. Например проверяют такое:
- Когда приложение падает при получении/отображении больших объемов данных. Например 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 бесплатных инструментов для нагрузочного тестирования.
