Стресс-тестирование (программное обеспечение)
Эта статья нуждается в дополнительных цитатах для проверки . ( сентябрь 2014 г. ) |
Стресс-тестирование — это деятельность по тестированию программного обеспечения , которая определяет надежность программного обеспечения путем тестирования за пределами нормальной работы. Стресс-тестирование особенно важно для критически важного программного обеспечения, но оно используется для всех типов программного обеспечения. В стресс-тестах обычно больший упор делается на надежность, доступность и обработку ошибок при большой нагрузке, чем на то, что считается правильным поведением в нормальных обстоятельствах.
Стресс-тест системы относится к тестам, в которых больший упор делается на надежность , доступность и обработку ошибок при большой нагрузке, а не на то, что считается правильным поведением в нормальных обстоятельствах. В частности, целями таких тестов может быть гарантия того, что программное обеспечение не выйдет из строя в условиях недостаточности вычислительных ресурсов (таких как память или дисковое пространство ), необычно высокого уровня параллелизма или атак типа «отказ в обслуживании» .
Примеры:
- Веб -сервер может быть подвергнут стресс-тестированию с использованием сценариев , ботов и различных инструментов отказа в обслуживании для наблюдения за производительностью веб-сайта во время пиковых нагрузок. Эти атаки обычно длятся менее часа или до тех пор, пока не будет найден предел объема данных, который может выдержать веб-сервер.
Стресс-тестирование можно противопоставить нагрузочному тестированию:
- Нагрузочное тестирование исследует всю среду и базу данных, измеряя при этом время отклика, тогда как стресс-тестирование фокусируется на выявленных транзакциях, доводя их до уровня, позволяющего нарушить транзакции или системы.
- Если во время стресс-тестирования транзакции подвергаются выборочной нагрузке, база данных может не испытывать большой нагрузки, но транзакции подвергаются сильной нагрузке. С другой стороны, во время нагрузочного тестирования база данных испытывает большую нагрузку, при этом некоторые транзакции могут не подвергаться нагрузке.
- Нагрузочное тестирование системы, также известное как стресс-тестирование, нагружает одновременных пользователей сверх уровня, с которым может справиться система, поэтому оно ломается в самом слабом звене во всей системе.
Полевой опыт [ править ]
Неисправности могут быть связаны с:
- характеристики непроизводственных сред, например, небольшие тестовые базы данных
- полное отсутствие нагрузочного или стресс-тестирования
Обоснование [ править ]
Причинами стресс-тестирования могут быть:
- Тестируемое программное обеспечение является «критичным», то есть отказ программного обеспечения (например, сбой ) будет иметь катастрофические последствия.
- При использовании традиционных методов тестирования времени и ресурсов, выделяемых на тестирование, обычно недостаточно для тестирования всех ситуаций, в которых программное обеспечение будет использоваться после его выпуска.
- Даже при наличии достаточного времени и ресурсов для написания тестов может оказаться невозможным заранее определить все различные способы использования программного обеспечения. Это особенно актуально для операционных систем и промежуточного программного обеспечения , которое в конечном итоге будет использоваться программным обеспечением, которого на момент тестирования даже не существовало.
- Клиенты могут использовать программное обеспечение на компьютерах, которые имеют значительно меньше вычислительных ресурсов (таких как память или дисковое пространство ), чем компьютеры, используемые для тестирования.
- Целостность входных данных не может быть гарантирована. Входные данные являются общими для всего программного обеспечения: это могут быть файлы данных, потоки и буферы памяти, а также аргументы и параметры, передаваемые исполняемому файлу командной строки, или пользовательские вводы, запускающие действия в приложении с графическим интерфейсом. Методы фаззинга и обезьяньего тестирования можно использовать для обнаружения проблем, связанных с повреждением или несогласованностью данных.
- Параллелизм особенно сложно протестировать традиционными методами тестирования. Стресс-тестирование может потребоваться для выявления условий гонки и взаимоблокировок .
- Программное обеспечение, такое как веб-серверы , которые будут доступны через Интернет, может подвергнуться атакам типа «отказ в обслуживании» .
- В нормальных условиях определенные типы ошибок , такие как утечки памяти , могут быть довольно незначительными, и их трудно обнаружить за короткие периоды времени, в течение которых проводится тестирование. Однако эти ошибки все еще могут быть потенциально серьезными. В некотором смысле стресс-тестирование в течение относительно короткого периода времени можно рассматривать как имитацию нормальной работы в течение более длительного периода времени.
с охватом Связь филиалов
ветвей Покрытие (особый тип покрытия кода ) — это показатель количества ветвей, выполненных при тестировании, где «100%-ное покрытие ветвей» означает, что каждая ветвь в программе была выполнена хотя бы один раз в рамках некоторого теста. Охват филиалов — один из наиболее важных показателей тестирования программного обеспечения; программное обеспечение с низким охватом филиалов обычно не считается тщательно протестированным. Обратите внимание, что [ редакция ] Метрики покрытия кода являются свойством тестов для части программного обеспечения, а не тестируемого программного обеспечения.
Достижение высокого охвата ветвей часто предполагает написание отрицательных вариантов тестов, то есть вариантов, в которых предполагается, что программное обеспечение каким-то образом дает сбой, в дополнение к обычным положительным вариантам тестов, которые проверяют предполагаемое использование. Примером отрицательного варианта может быть вызов функции с недопустимыми параметрами. Однако существует предел покрытия ветвей, которого можно достичь даже при отрицательных вариациях, поскольку некоторые ветви могут использоваться только для обработки ошибок, которые находятся вне контроля теста. Например, тест обычно не контролирует распределение памяти, поэтому тестировать ветки, обрабатывающие ошибку «недостаточно памяти», сложно.
Стресс-тестирование может обеспечить более высокий охват ветвей, создавая условия, при которых выполняются определенные ветки обработки ошибок. Покрытие может быть дополнительно улучшено за счет внедрения ошибок .
Примеры [ править ]
- Веб -сервер может быть подвергнут стресс-тестированию с использованием сценариев , ботов и различных инструментов отказа в обслуживании для наблюдения за производительностью веб-сайта во время пиковых нагрузок.
Нагрузочный тест и тест - стресс
Стресс-тестирование обычно состоит из тестирования за пределами установленных пределов с целью определения точек сбоя и тестирования восстановления после сбоя. [1] [2]
Нагрузочное тестирование предполагает контролируемую среду, перемещающуюся от низких нагрузок к высоким. Стресс-тестирование фокусируется на случайных событиях, хаосе и непредсказуемости. Используя веб-приложение в качестве примера, вот способы, которыми можно создать стресс: [1]
- удвоить базовое число для одновременных пользователей/HTTP-соединений
- произвольное закрытие и перезапуск портов на сетевых коммутаторах/маршрутизаторах, которые соединяют серверы (например, с помощью команд SNMP)
- отключить базу данных, а затем перезапустить ее
- перестроить RAID-массив во время работы системы
- запускать процессы, потребляющие ресурсы (ЦП, память, диск, сеть) в Интернете и на серверах баз данных
- наблюдать, как система реагирует на сбой и восстанавливается
- Сохраняет ли он свое состояние?
- Приложение зависает и зависает или происходит корректный сбой?
- При перезапуске может ли он восстановиться из последнего хорошего состояния?
- Выводит ли система содержательные сообщения об ошибках пользователю и в журналы?
- Нарушена ли безопасность системы из-за неожиданных сбоев?
Надежность [ править ]
![]() | Эта статья может придать чрезмерный вес определенным идеям, инцидентам или противоречиям . ( Март 2023 г. ) |
Платформа тестирования программного обеспечения на основе шаблонов для оценки возможности использования уязвимостей, приводящих к повреждению метаданных, разработанная Дэн Фэнлеем, Ван Цзянем, Чжан Бинем, Фэн Чао, Цзян Чжиюань и Су Юнфэй, обсуждают, как повышенное внимание уделяется обеспечению качества и защиты программного обеспечения. Однако сегодняшнее программное обеспечение, к сожалению, все еще не защищено от кибератак, особенно при наличии небезопасной организации кучи метаданных. Авторы стремятся выяснить, могут ли метаданные кучи быть повреждены и использованы киберзлоумышленниками, и предлагают RELAY, среду тестирования программного обеспечения для имитации поведения человека, эксплуатирующего повреждение метаданных на машинном уровне. RELAY также использует меньше ресурсов, потребляемых для решения проблемы компоновки в соответствии с шаблоном эксплойта, и генерирует окончательный эксплойт.
Методология определения степени детализации объектов обучения, разработанная БЕНИТТИ и Фабианом Баррето Вавассори. Авторы сначала обсуждают, что объект обучения является одной из основных тем исследований в сообществе электронного обучения в последние годы, а степень детализации является ключевым фактором для повторного использования объекта обучения. Затем авторы представляют методологию определения детализации объектов обучения в области вычислений, а также пример тестирования программного обеспечения. Позже авторы проводят пять экспериментов, чтобы оценить потенциал обучения на созданных объектах обучения, а также продемонстрировать возможность повторного использования объектов обучения. В статье также представлены результаты эксперимента, которые показывают, что изучение объекта способствует пониманию и применению концепций.
Недавняя статья «Проверка надежности программного обеспечения на основе облачных сервисов» имеет новаторский эффект и исследует, как индустрии программного обеспечения нужен способ измерения надежности каждого компонента программного обеспечения. гарантийно-проверочный метод на основе облачного сервиса В данной статье предложен . Сначала в статье обсуждается, насколько надежен каждый компонент, что будет определяться с точки зрения гарантийной проверки обслуживания компонентов. Затем в статье была определена эффективная модель компонента, и на основе предложенной модели процесс проверки службы компонента проиллюстрирован на примере приложения.
См. также [ править ]
- Тестирование программного обеспечения
- В этой статье рассматривается тестирование надежности программного обеспечения при неожиданных или редких (напряженных) рабочих нагрузках. См. также тесно связанные:
- Тестирование масштабируемости
- Нагрузочное тестирование
- Список программных инструментов для нагрузочного тестирования на странице Нагрузочное тестирование #Инструменты нагрузочного тестирования.
- Стресс-тест для общего обсуждения
- Тестирование черного ящика
- Тестирование производительности программного обеспечения
- Анализ сценариев
- Моделирование
- Тестирование белого ящика
- Ассоциация технической инспекции (TÜV) - тестирование и сертификация продукции
- Тестирование параллелизма с использованием средства проверки моделей CHESS
- Jinx (несуществующая из-за поглощения и отмены проекта) автоматизировала стресс-тестирование, автоматически исследуя маловероятные сценарии выполнения.
- Стресс-тест (аппаратный)
Ссылки [ править ]
- ↑ Перейти обратно: Перейти обратно: а б Георгиу, Григ. «Производительность, нагрузка и стресс-тестирование» . Гибкое тестирование . Проверено 25 февраля 2013 г.
- ^ Чан, Х. Энтони (2004). «Ускоренное стресс-тестирование аппаратного и программного обеспечения» (PDF) . Ежегодный симпозиум «Надежность и ремонтопригодность», 2004 г. — РАМН . Лос-Анджелес, Калифорния: IEEE. стр. 346–351. дои : 10.1109/RAMS.2004.1324530 . ISBN 0-7803-8215-3 . Проверено 19 октября 2020 г.