Стресс-тестирование (программное обеспечение)

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

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

Примеры:

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

Стресс-тестирование можно противопоставить нагрузочному тестированию:

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

Полевой опыт

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

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

Обоснование

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

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

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

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

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

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

Примеры

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

Стресс-тестирование обычно состоит из тестирования за пределами указанных пределов с целью определения точек отказа и восстановления после отказа. [1] [2]


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

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

Надежность

Платформа тестирования программного обеспечения на основе шаблонов для оценки эксплуатируемости уязвимостей повреждения метаданных, разработанная Дэн Фэнглеем, Ван Цзянем, Чжан Бинем, Фэн Чао, Цзян Чжиюанем, Су Юньфэем, обсуждает, как возросло внимание к обеспечению качества и защите программного обеспечения. Однако, к сожалению, современное программное обеспечение по-прежнему не защищено от кибератак, особенно при наличии небезопасной организации метаданных кучи. Авторы стремятся исследовать, могут ли метаданные кучи быть повреждены и использованы киберпреступниками, и предлагают RELAY, платформу тестирования программного обеспечения для имитации поведения человека при эксплуатации для повреждения метаданных на уровне машины. RELAY также использует меньше ресурсов, потребляемых для решения проблемы макета в соответствии с шаблоном эксплойта, и генерирует окончательный эксплойт.

Методология определения гранулярности учебных объектов, разработанная BENITTI, Fabiane Barreto Vavassori. Сначала авторы обсуждают, как учебный объект является одной из основных тем исследований в сообществе электронного обучения в последние годы, а гранулярность является ключевым фактором для повторного использования учебных объектов. Затем авторы представляют методологию определения гранулярности учебных объектов в области вычислений, а также пример из тестирования программного обеспечения. Позже авторы проводят пять экспериментов для оценки потенциала обучения из созданных учебных объектов, а также для демонстрации возможности повторного использования учебных объектов. Результаты эксперимента также представлены в статье, которые показывают, что учебный объект способствует пониманию и применению концепций.

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

Смотрите также

Ссылки

  1. ^ ab Gheorghiu, Grig. "Производительность против нагрузки против стресс-тестирования". Agile Testing . Получено 25 февраля 2013 г.
  2. ^ Чан, Х. Энтони (2004). «Ускоренное стресс-тестирование как оборудования, так и программного обеспечения» (PDF) . Ежегодный симпозиум по надежности и ремонтопригодности, 2004 г. — RAMS . Лос-Анджелес, Калифорния: IEEE. стр. 346–351. doi :10.1109/RAMS.2004.1324530. ISBN 0-7803-8215-3. Получено 19 октября 2020 г. .
Взято с "https://en.wikipedia.org/w/index.php?title=Stress_testing_(software)&oldid=1241387081"