Тестирование на погружение (Soak Test) в программном обеспечении: значение и примеры.
Томас Гамильтон
⚡ Умное резюме
Тестирование на длительную нагрузку (Soak Testing) применяет к приложению устойчивую, реалистичную нагрузку в течение продолжительного периода времени, чтобы выявить проблемы, которые проявляются только со временем. Утечки памяти, исчерпание соединений и медленное снижение производительности — вот дефекты, которые оно призвано обнаружить.
Что такое испытание на замачивание?
Тестирование на выдержку — это тип нефункционального тестирования, который используется для измерения производительности программного приложения при огромном объеме нагрузки в течение длительного периода времени. Цель тестирования на выдержку — убедиться, что программное приложение выдерживает большие объемы использования, и проверить, что произойдет, если оно выйдет за рамки проектных ожиданий.
На изображении ниже показан цикл тестирования, показывающий, на каком этапе выполняется тестирование на выдержку (Тип теста производительности) выполняется в приложении.
В этом типе тестирования в основном отслеживается использование памяти приложением в системе. Оно тестируется на уровне системы, чтобы выяснить, выдержит ли система очень высокий объем использования, и увидеть, что произойдет, если выйти за рамки ее проектных ожиданий.
Зачем проводить тестирование на выдержку?
Система может вести себя нормально при использовании в течение 2 часов, но когда одна и та же система используется непрерывно в течение 10 часов или более, она может выйти из строя или вести себя ненормально/случайно/может привести к сбою. Чтобы предсказать такой отказ, проводится тестирование на выдержку.
Когда проводить тестирование на выдержку?
Испытание на выдержку следует проводить в следующих случаях:
- Прежде чем сборка будет развернута на клиенте, то есть перед выпуском любого приложения на конкретной платформе, она должна пройти успешную серию нагрузочных тестов при высоких или эквивалентных уровнях трафика. После этого проводится испытание на выдержку. Это помогает нам определить, как запустить какое-либо конкретное приложение в течение длительного периода времени. Если в течение периода, т. е. когда система находится в режиме Soak, будут обнаружены такие проблемы, как утечки/повреждения памяти, о них следует немедленно сообщить.
- Лучшее время для тестирования на выдержку — выходные, поскольку приложение должно находиться в рабочем состоянии в течение дня или ночи. Это полностью зависит от ограничений ситуации тестирования. Испытания на выдержку являются одним из наиболее важных требований соответствия, которые каждая компания должна строго соблюдать.
Стратегия тестирования на выдержку
Тестирование на выдержку в течение длительного сеанса — это стратегия, при которой система находится под нагрузкой в течение более длительного времени.
Простой пример: пользователь остается в системе в течение многих часов, выполняя ряд бизнес-транзакций. Таким образом создается много данных. На систему/сервер базы данных может быть большая нагрузка, что может привести к остановке/сбою системы/сервера базы данных.
При длительном тестировании на выдержку действия в течение нескольких дней (скажем, 30 дней) выполняются в ограниченные сроки (скажем, 2 дня). Количество транзакций в этот ограниченный период времени должно соответствовать или превышать количество транзакций за несколько дней. В центре внимания должно быть количество обработанных транзакций. Наиболее важной частью тестирования на выдержку является проверка доступной памяти ЦП и объема памяти, которая будет использоваться. Нам нужно записывать использование памяти в начале и в конце теста на выдержку. При необходимости, использование памяти такими средствами, как Java Виртуальные машины также важны и требуют мониторинга.
Ниже приведены еще несколько проверок, которые должен выполнить любой пользователь/тестер перед началом тестирования на выдержку:
а) Мониторинг потребления ресурсов базы данных.
б) Мониторинг потребления ресурсов сервера (за исключением использования ЦП).
в) Тест на выдержку должен выполняться с реалистичным параллельным доступом пользователей.
Характеристики испытаний на выдержку
Стандартный метод испытания на выдержку должен иметь следующие характеристики:
- Продолжительность большинства испытаний на выдерживание часто определяется имеющимся временем.
- Любое приложение должно работать без перерыва, если оно требует длительного периода времени.
- Он должен охватывать все сценарии, согласованные заинтересованными сторонами.
- В большинстве случаев каждая система имеет регулярный период окна обслуживания, и время между такими периодами окна является ключевым фактором для определения объема теста на выдержку.
Примеры испытаний на замачивание
- В случае банковского домена, когда имеется большой объем данных от продавцов, тестер будет непрерывно нагружать систему на период от 70 до 150 часов, чтобы проверить, как приложение ведет себя в течение этого периода загрузки.
- Предположим, что имеется 33,000 60 входов в систему, которые необходимо провести через систему, это соответствует семи с половиной дням активности. В этом случае 70–6-часовое испытание на выдержку можно начать к вечеру пятницы, около XNUMX:XNUMX, и завершить его может Monday утро в 6 утра. Только при таком тесте можно будет наблюдать любое ухудшение характеристик в контролируемых условиях.
- В случае с видеоиграми Mobile приложения и т. д. предполагают оставление игры или приложения в работающем состоянии на длительный период времени в различных режимах работы, таких как холостой ход, пауза на титульном экране и т. д., чтобы выяснить, может ли приложение справиться с постоянно ожидаемой нагрузкой. .
Распространенные проблемы, наблюдаемые во время тестирования на выдержку
- Распределение памяти (утечки памяти, которые в конечном итоге могут привести к кризису памяти или ошибкам округления, которые проявляются только со временем).
- Использование ресурсов базы данных (неспособность закрыть курсоры базы данных при некоторых условиях, что в конечном итоге может привести к остановке всей системы).
- Это также может привести к ухудшению производительности, т. е. к тому, чтобы время отклика после длительного периода постоянной активности было таким же хорошим, как и в начале теста.
- Неспособность закрыть соединения между уровнями многоуровневой системы при некоторых обстоятельствах, что может привести к остановке некоторых или всех модулей системы.
- Постепенное ухудшение времени отклика некоторых функций, поскольку внутренние структуры данных становятся менее эффективными во время длительного тестирования.
Как этот тест вписывается в семейство тестов производительности
Испытания на производительность — это общий термин. Варианты, описанные ниже, отличаются только формой приложенной нагрузки и продолжительностью её удержания, поэтому их так часто путают друг с другом.
| Тип теста | Схема нагрузки | Вопрос, на который он отвечает |
|---|---|---|
| Тестирование нагрузки | Ожидаемая пиковая нагрузка, кратковременная | Достигает ли система поставленных целей при нормальной пиковой нагрузке? |
| Стресс-тестирование | Доведено до предела возможностей до отказа | Где происходит сбой, и происходит ли он корректно? |
| Пиковое тестирование | Внезапный резкий всплеск, затем спад | Выдерживает ли оно и восстанавливается ли после дорожно-транспортного происшествия? |
| Испытание на выносливость | Нормальная нагрузка удерживалась в течение многих часов. | Снижается ли производительность со временем? |
| Тестирование на замачивание | Постоянная нагрузка в течение длительного периода времени | Наблюдаются ли утечки памяти или истощение ресурсов? |
| Тестирование стабильности | Изменение нагрузки в зависимости от условий | Сохраняет ли система свою надежность при изменении условий? |
| Объемное тестирование | Обычные пользователи, очень большой объем данных | Справится ли система с ростом базы данных? |
Испытания на выносливость и испытания на замачивание часто рассматриваются как синонимы. В обиходе они описываются следующим образом: оба теста выдерживают постоянную нагрузку в течение длительного периода времени. Там, где команды различают их, тестирование на выносливость фокусируется на том, увеличивается ли время отклика, в то время как тестирование на длительную нагрузку фокусируется на потреблении ресурсов, таких как память, файловые дескрипторы и пулы соединений. Запуск одного из тестов обычно дает данные по обоим.
Ключевые показатели, которые необходимо отслеживать во время тестирования.
Эффективность теста производительности напрямую зависит от того, что вы записываете во время его выполнения. Зафиксируйте эти шесть показателей на стороне сервера и клиента, а затем сравните их с базовым показателем, а не с интуицией.
| Метрика | Что это вам говорит | Предупреждающий знак |
|---|---|---|
| Среднее время ответа | Типичный пользовательский опыт | Любое восходящее движение по ходу трассы |
| 95-й процентиль времени ответа | Опыт самых медленных пользователей | Значительно выше среднего, что означает непоследовательность. |
| Увеличить пропускную способность | Обрабатываемые запросы в секунду | Падение при постоянной нагрузке |
| Коэффициент ошибок | Доля неудачных или истекших по времени запросов | Любое повышение выше согласованного порога |
| Использование ЦП и памяти | запас ресурсов сервера | Воспоминания, которые поднимаются вверх и никогда не возвращаются |
| Подключения к базе данных и потоки | Истощение бассейна | Количество случаев, которые неуклонно растут без публикации, |
Прочитайте среднее значение и процентиль вместе. Среднее значение 800 мс с 95-м процентилем 900 мс свидетельствует о стабильной работе системы. То же среднее значение с 95-м процентилем 9 секунд означает, что проблемы возникают у одного из двадцати пользователей, и это скрывает средний показатель.
Обращайте внимание на форму, а не только на значение. В любом длительном тесте ровная линия запасов — это проходной балл, а растущая — это утечка, даже если абсолютное число на момент завершения теста все еще находится в пределах допустимого значения.
