일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- agile
- 자동화
- 비기능테스트
- 테스트케이스
- csts
- 위험 기반 테스트
- 셀레니움
- 테스트 설계 기법에 따른 분류
- testcase
- regression test
- selenium
- 테스트 케이스
- test
- maintainability test
- Test Case
- testing method
- 품질
- risk-based testing
- 파이썬
- 애자일
- Testing
- ISTQB
- 테스트
- Software life cycle model
- seleium
- SQA
- QA
- RBT
- 유지보수성 테스트
- Python
- Today
- Total
목록risk-based testing (3)
Study_Note

테스트 계획 (test plan) 테스트 레벨/유형 결정테스트 강도는 테스트 레벨과 유형을 결정하는 중요한 요소이다. 고강도 테스트 또는 균형적 테스트로 분류된 피처는 모든 테스트 레벨에 걸쳐 테스트가 적용된다. 이는 해당 피처와 관련된 모듈들을 대상으로 컴포넌트 테스트를 수행한 후, 해당 모듈들이 통합된 시나리오에 대해 통합 테스트를 진행하고, 최종적으로 시스템 테스트까지 수행하는 방식이다. 만약 피처가 비기능적 특성을 지닌다면, 비기능 요구사항에 맞춘 유형 테스트가 추가될 수 있다. 예를 들어, 성능 관련 피처가 고강도 테스트로 분류되면 컴포넌트, 통합, 시스템 테스트에서 성능 테스트가 추가적으로 수행될 수 있다. 반면, 부가적 테스트 등급에 해당하는 피처는 컴포넌트 및 통합 테스트 단계에서는 제외될..

위험분석(Risk Analysis)위험 요소 식별 (Identifying Risk Factors)위험 분석 기반 테스트를 수행할 때, 첫 단계는 테스트가 필요한 피처들을 모두 나열하는 것이다. 이 과정은 테스트 범위를 설정하기 위한 출발점이 되며, 시스템의 기능적 및 비기능적 요소들이 모두 포함된다. 이렇게 식별된 피처들은 이후 위험 분석의 대상이 되며, 위험 분석 결과에 따라 테스트 계획이 수립된다. 피처들은 소프트웨어 요구사항 명세서를 바탕으로 식별할 수 있다. 요구사항 명세서는 시스템이 충족해야 할 기능적 요구사항뿐만 아니라 성능, 신뢰도, 가용성, 보안성과 같은 비기능적 요구사항도 포함하고 있다. 이 명세서는 테스트의 기준이 되는 중요한 문서이므로, 여기 나열된 요구사항들을 우선적으로 테스트할 피..

위험 기반 테스트 (risk-based testing, RBT)소프트웨어 위험기반 테스트는 잠재적인 위험을 식별하고 그에 따라 테스트 우선순위를 결정하는 테스트 전략입니다. 즉, 소프트웨어의 가장 중요한 부분, 가장 실패할 가능성이 높은 부분 또는 가장 큰 영향을 미치는 부분을 중점적으로 테스트하는 방식입니다. 모든 기능을 균등하게 테스트하는 것이 아니라, 위험이 큰 부분에 더 많은 자원을 집중하여 프로젝트의 품질을 보장하는 것이 핵심입니다. 소프트웨어 프로젝트는 일반적으로 제한된 시간과 비용 내에서 완료되어야 하며, 이를 효율적으로 관리하지 않으면 프로젝트 품질이 저하될 수 있습니다. 따라서 모든 소프트웨어 기능을 테스트하는 것은 이상적이지만, 현실적으로는 불가능한 경우가 많습니다. 이를 해결하기 위해..