Тестирование на основе рисков
 | Тема этой статьи Википедии может не соответствовать общему правилу по известности . ( февраль 2012 г. ) |
Тестирование на основе рисков (RBT) — это тип тестирования программного обеспечения , который функционирует как организационный принцип, используемый для определения приоритетности тестов функций и функций программного обеспечения на основе риска сбоя, функции их важности и вероятности или влияния сбоя. [ 1 ] [ 2 ] [ 3 ] Теоретически существует бесконечное количество возможных тестов. Тестирование, основанное на рисках, использует (пере)оценку рисков для управления всеми этапами процесса тестирования, т. е. планирование тестирования, проектирование теста, реализация теста, выполнение теста и оценка теста. [ 4 ] Это включает, например, ранжирование тестов и подтестов по функциональности; методы тестирования, такие как анализ граничных значений , тестирование всех пар и таблицы переходов состояний, направлены на обнаружение областей, которые с наибольшей вероятностью будут дефектными.
Виды оценки рисков
[ редактировать ]Облегченная оценка риска
[ редактировать ]Облегченные методы тестирования, основанные на оценке риска, в основном концентрируются на двух важных факторах: вероятности и воздействии. [ 5 ] Вероятность означает, насколько велика вероятность возникновения риска, а воздействие измеряет, насколько серьезными могут быть последствия, если риск действительно произойдет. Вместо использования сложной математики эти методы основаны на простых суждениях и шкалах. [ 6 ] Например, команда может оценить вероятность риска как высокую, среднюю или низкую, а его влияние — как серьезное, умеренное или незначительное. Эти рейтинги помогают расставить приоритеты, на чем следует сосредоточить усилия по тестированию. [ 7 ]
Тяжелая оценка риска
[ редактировать ]Тщательное тестирование на основе рисков — это метод, используемый для тестирования программного обеспечения, фокусируясь на областях, где проблемы могут возникнуть с наибольшей вероятностью. Команда тестирования ищет наиболее важные части программного обеспечения, которые могут выйти из строя, и концентрируется на более тщательном тестировании этих частей. [ нужна ссылка ]
Существует четыре основных типа тяжелых методов тестирования, основанных на риске: [ 7 ]
- Стоимость воздействия : показывает, сколько денег может принести проблема в программном обеспечении. Он определяет это, размышляя о том, насколько вероятна проблема и сколько она может стоить.
- Анализ режимов и последствий отказов (FMEA) . Этот метод позволяет выяснить, какие части программного обеспечения могут выйти из строя, почему они могут выйти из строя и что может произойти, если они это сделают. Это помогает найти важные области, требующие внимания.
- Качественное функциональное развертывание (QFD) : этот метод помогает связать то, что нужно пользователям, с тем, что делает программное обеспечение. Он рассматривает риски, которые могут возникнуть из-за непонимания того, чего на самом деле хотят пользователи.
- Анализ дерева отказов (FTA) . Этот метод используется для выяснения того, почему что-то пошло не так, путем поэтапного рассмотрения различных причин.
Виды риска
[ редактировать ]Риск можно определить как вероятность того, что необнаруженная ошибка в программном обеспечении может оказать негативное влияние на пользователя системы. [ 8 ]
Методы оценивают риски по различным направлениям:
Деловой или операционный
[ редактировать ]- Высокое использование подсистемы, функции или возможности
- Критичность подсистемы, функции или возможности, включая стоимость отказа.
Технический
[ редактировать ]- Географическое распределение команды разработчиков
- Сложность подсистемы или функции
Внешний
[ редактировать ]- Предпочтение спонсора или руководителя
- Нормативные требования
Связанный с режимом сбоя электронного бизнеса
[ редактировать ]- Дефекты статического контента
- Дефекты интеграции веб-страницы
- Функциональный сбой, связанный с поведением
- Сбой, связанный с обслуживанием (доступностью и производительностью)
- Ошибка, связанная с удобством использования и доступностью
- Уязвимость безопасности
- Крупномасштабный сбой интеграции
Некоторые соображения по поводу расстановки приоритетов рисков изложены Венкатом Рамакришнаном в блоге. [ 10 ]
Ссылки
[ редактировать ]- ^ Бах, Дж. Проблема достаточно хорошего программного обеспечения (1995)
- ^ Бах Дж. и Канер К. Исследовательское тестирование и тестирование на основе рисков (2004).
- ^ Мика Лехто (25 октября 2011 г.). «Понятие риск-ориентированного тестирования, его преимущества и недостатки» . Ictstandard.org . Проверено 1 марта 2012 г.
- ^ Фельдерер, Майкл; Шифердекер, Ина (2014). «Таксономия риск-ориентированного тестирования» . Международный журнал по программным инструментам для трансфера технологий . 16 (5): 559–568. arXiv : 1912.11519 . дои : 10.1007/s10009-014-0332-3 . S2CID 11598143 .
- ^ Махеш, Хари (3 ноября 2023 г.). «Тестирование на основе рисков: стратегический подход к обеспечению качества» . testRigor Инструмент автоматического тестирования на основе искусственного интеллекта . Проверено 18 ноября 2023 г.
- ^ Шмитц, Кристофер; Папе, Себастьян (01 марта 2020 г.). «LiSRA: Облегченная оценка рисков безопасности для поддержки принятия решений в области информационной безопасности» . Компьютеры и безопасность . 90 : 101656. doi : 10.1016/j.cose.2019.101656 . ISSN 0167-4048 . S2CID 208109813 .
- ^ Jump up to: а б «Что такое тестирование на основе рисков: лучшие практики» . www.lambdatest.com . Проверено 18 ноября 2023 г.
- ^ Стефан Бессон (3 января 2012 г.). «Информация о статье: Стратегия тестирования, основанного на рисках» . Инженерия качества программного обеспечения ИТ . Stickyminds.com . Проверено 1 марта 2012 г.
- ^ Джеррард, Пол и Томпсон, Нил, Тестирование электронного бизнеса на основе рисков (2002)
- ^ О тестировании на основе рисков [1]
 | Эта программной инженерии, статья, посвященная является незавершенной . Вы можете помочь Википедии, расширив ее . |