위험 기반 테스트
Risk-based testing |
RBT(Risk-based testing, RBT)는 소프트웨어에서 특징과 기능의 시험의 우선순위를 정하기 위해 사용되는 조직 원리로서 기능하는 소프트웨어 시험의 일종으로, 실패의 위험, 그 중요성과 가능성 또는 실패의 영향에 기초한다.[1][2][3][4]이론적으로, 가능한 테스트는 무한히 많다.위험 기반 시험은 시험 계획, 시험 설계, 시험 구현, 시험 실행 및 시험 평가의 모든 단계를 통제하기 위한 위험(재) 평가를 사용한다.[5]여기에는 예를 들어, 기능성에 대한 시험 순위 및 하위 테스트가 포함된다. 경계 값 분석, 올페어 테스트 및 상태 전환 표와 같은 시험 기법은 결함이 있을 가능성이 가장 높은 영역을 찾는 것을 목표로 한다.
위험 평가
 |
위험을 평가하기 위해서는 두 릴리스 또는 버전 사이의 변경사항을 비교하는 것이 중요하다.중요한 비즈니스 모듈을 평가하는 것은 시험의 우선순위를 정하는 첫 단계지만 진화적 위험의 개념은 포함하지 않는다.[clarification needed]그런 다음 변경 기반 테스트와 회귀 테스트의 두 가지 방법을 사용하여 확장한다.
- 시험 팀은 변경 기반 시험을 통해 릴리스의 변경사항을 평가한 후 수정된 모듈을 대상으로 시험 우선순위를 정할 수 있다.[vague]
- 회귀 테스트는 버그 수정과 같은 변경이 테스트 대상 소프트웨어에 새로운 결함을 도입하지 않았음을 보장한다.회귀 테스트의 주요 이유 중 하나는 소프트웨어의 한 부분의 변경이 소프트웨어의 다른 부분에 영향을 미치는지 여부를 판단하기 위함이다.
이 두 가지 방법은 시험팀이 비즈니스 모듈의 위험, 변화 및 중요도에 기초하여 시험의 우선순위를 정할 수 있도록 한다.특정 기술은[which?] 이러한 종류의 시험 전략을 설정하기 쉽고 소프트웨어 변경으로 유지하기가 매우 쉽다.[vague]
위험 유형
위험은 탐지되지 않은 소프트웨어 버그가 시스템 사용자에게 부정적인 영향을 미칠 수 있는 확률로 식별할 수 있다.[6]
이 방법은 다양한 차원에 따라 위험을 평가한다.
비즈니스 또는 운영
- 하위 시스템, 기능 또는 기능의 높은 사용
- 고장 비용을 포함한 서브시스템, 기능 또는 기능의 중요도
기술
- 개발팀의 지리적 분포
- 서브시스템 또는 기능의 복잡성
외부의
- 스폰서 또는 임원 선호도
- 규제요건
- 정적 내용 결함
- 웹 페이지 통합 결함
- 기능 동작 관련 고장
- 서비스(가용성 및 성능) 관련 오류
- 사용성 및 접근성 관련 고장
- 보안 취약성
- 대규모 통합 실패
참조
- ^ Gerrard, Paul; Thompson, Neil (2002). Risk Based E-Business Testing. Artech House Publishers. ISBN 978-1-58053-314-0.
- ^ 바흐, J.충분히 좋은 소프트웨어의 도전 (1995)
- ^ Bach, J. 및 Kaner, C. 탐색 및 위험 기반 테스트(2004)
- ^ Mika Lehto (October 25, 2011). "The concept of risk-based testing and its advantages and disadvantages". Ictstandard.org. Retrieved 2012-03-01.
- ^ Michael Felderer, Ina Schieferdecker: 위험 기반 테스트의 분류법.STTT 16(5): 559-568(2014)
- ^ Stephane Besson (2012-01-03). "Article info : A Strategy for Risk-Based Testing". Software Quality Engineering IT. Stickyminds.com. Retrieved 2012-03-01.
- ^ Gerrard, Paul and Thompson, Neil Risk-Based Testing E-Business(2002)
