Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Стресс-тестирование - это деятельность по тестированию программного обеспечения, которая определяет надежность программного обеспечения путем тестирования, выходящего за пределы нормальной работы. Стресс-тестирование особенно важно для « критически важного » программного обеспечения, но используется для всех типов программного обеспечения. Стресс-тесты обычно делают больший упор на надежность, доступность и обработку ошибок при большой нагрузке, чем на то, что считается правильным поведением при нормальных обстоятельствах.

Полевой опыт [ править ]

Неисправности могут быть связаны с:

  • характеристики непроизводственных сред, например небольшие тестовые базы данных
  • полное отсутствие нагрузочного или стресс-тестирования

Обоснование [ править ]

Причины стресс-тестирования включают:

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

Связь с покрытием филиала [ править ]

Покрытие ветвей (конкретный тип покрытия кода ) - это метрика количества ветвей, выполняемых при тестировании, где «100% покрытие ветвей» означает, что каждая ветвь в программе была выполнена хотя бы один раз в рамках некоторого теста. Покрытие филиалов - один из самых важных показателей для тестирования программного обеспечения; программное обеспечение с низким охватом ветвей обычно не считается тщательно протестированным. Обратите внимание, чтометрики покрытия кода [ редактирование ] являются свойством тестов для части программного обеспечения, а не тестируемого программного обеспечения.

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

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

Примеры [ править ]

  • Веб - сервер может быть нагрузочное тестирование с использованием скриптов , ботов , а также различные отказ в обслуживании инструментов для наблюдения за производительность веб - сайта во время пиковых нагрузок.

Нагрузочный тест и стресс-тест [ править ]

Стресс-тестирование обычно состоит из тестирования, выходящего за установленные пределы, для определения точек отказа и восстановления после отказа. [1] [2]


Нагрузочное тестирование подразумевает переход контролируемой среды от низких нагрузок к высоким. Стресс-тестирование фокусируется на более случайных событиях, хаосе и непредсказуемости. Используя веб-приложение в качестве примера, вот способы, которые могут вызвать стресс: [1]

  • удвоить базовое число для одновременных пользователей / HTTP-соединений
  • произвольно отключать и перезапускать порты на сетевых коммутаторах / маршрутизаторах, которые подключают серверы (например, с помощью команд SNMP)
  • отключите базу данных, затем перезапустите ее
  • перестроить RAID-массив во время работы системы
  • запускать процессы, потребляющие ресурсы (ЦП, память, диск, сеть) на веб-серверах и серверах баз данных
  • наблюдать, как система реагирует на сбой и восстанавливается
    • Сохраняет ли он свое состояние?
    • Приложение зависает и зависает или нормально перестает работать?
    • Может ли он восстановиться после перезапуска из последнего исправного состояния?
    • Выводит ли система значимые сообщения об ошибках для пользователя и в журналы?
    • Нарушена ли безопасность системы из-за неожиданных сбоев?

См. Также [ править ]

  • Тестирование программного обеспечения
  • В этой статье рассматривается тестирование надежности программного обеспечения при неожиданных или редких (стрессовых) нагрузках. См. Также тесно связанные:
    • Тестирование масштабируемости
    • Нагрузочное тестирование
    • Список программных инструментов для нагрузочного тестирования: Нагрузочное тестирование # Инструменты нагрузочного тестирования
  • Стресс-тест для общего обсуждения
  • Тестирование черного ящика
  • Тестирование производительности программного обеспечения
  • Анализ сценария
  • Моделирование
  • Тестирование белого ящика
  • Technischer Überwachungsverein (TÜV) - тестирование и сертификация продукции
  • Тестирование параллелизма с помощью программы проверки моделей CHESS
  • Jinx (несуществующий из-за поглощения и отмены проекта) автоматизировал стресс-тестирование, автоматически исследуя маловероятные сценарии выполнения.
  • Стресс-тест (оборудование)

Ссылки [ править ]

  1. ^ a b Георгиу, Григ. «Производительность против нагрузки против стресс-тестирования» . Гибкое тестирование . Проверено 25 февраля 2013 года .
  2. Перейти ↑ Chan, H Anthony (2004). «Ускоренное стресс-тестирование аппаратного и программного обеспечения» (PDF) . Ежегодный симпозиум «Надежность и ремонтопригодность», 2004 г. - РАМН . Лос-Анджелес, Калифорния: IEEE. С. 346–351. DOI : 10,1109 / RAMS.2004.1324530 . ISBN  0-7803-8215-3. Проверено 19 октября 2020 .