일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 |
Tags
- seleium
- agile
- 품질
- testing method
- Test Case
- maintainability test
- 셀레니움
- 비기능테스트
- RBT
- testcase
- Testing
- QA
- 테스트케이스
- 자동화
- ISTQB
- 파이썬
- 테스트 케이스
- test
- 유지보수성 테스트
- 테스트
- 애자일
- Software life cycle model
- regression test
- csts
- 위험 기반 테스트
- selenium
- risk-based testing
- Python
- SQA
- 테스트 설계 기법에 따른 분류
Archives
- Today
- Total
Study_Note
software test design techniques 본문
728x90
소프트웨어 테스트 설계 기법
반응형
(software test design techniques)
소프트웨어 테스트 설계는 테스트 케이스를 개발하기 위한 계획된 접근 방식을 의미합니다. 다양한 테스트 설계 기법이 있으며, 각각은 특정 상황에서 더 효과적일 수 있습니다. 몇 가지 주요한 소프트웨어 테스트 설계 기법을 살펴보겠습니다:
- 명세 기반 테스트 (Specification-Based Testing)
- 동등 분할(Equivalence Partitioning)
입력값을 동등한 파티션으로 나누어 각 파티션에 속하는 값들을 하나의 테스트 케이스로 그룹화합니다. 이를 통해 각 파티션에 속하는 값들을 대표할 수 있습니다. - 경계 값 분석(Boundary Value Analysis)
입력값의 경계 부분에 주목하여, 경계 값들을 중심으로 테스트 케이스를 작성합니다. 이는 주로 입력 값이 특정 범위에서 오류를 발생시키는 경향이 있는 경우에 유용합니다.
- 동등 분할(Equivalence Partitioning)
- 구조 기반 테스트 ('Structure-Based Testing' or 'Code-Based Testing')
- 문장 및 결정 테스트(Coverage)
코드의 모든 문장이나 결정을 최소 한 번 이상 실행하도록 테스트 케이스를 설계하는 것을 목표로 합니다. 대표적으로 문장 커버리지, 결정 커버리지, 조건 커버리지 등이 있습니다. - 경로 테스트(Path Testing)
프로그램의 모든 가능한 경로를 테스트하는 것을 목표로 합니다. 특정 경로를 따라가며 테스트 케이스를 작성합니다.
- 문장 및 결정 테스트(Coverage)
- 경험 기반 테스트 (Experience-Based Testing)
- 에러 추정(Error Guessing)
테스터들이 과거의 경험과 직관을 활용하여 특정 상황에서 어떤 종류의 에러가 발생할 가능성이 높은지를 가정하고 테스트 케이스를 작성합니다. - 체크리스트 테스팅(Checklist Testing)
특정 기준에 따라 테스트할 사항들을 목록화하고, 이를 참조하여 테스트를 진행합니다.
- 에러 추정(Error Guessing)
- 모델 기반 테스트 (Model-Based Testing)
- 상태 전이 다이어그램(State Transition Diagram)
시스템의 다양한 상태와 상태 전이를 모델링하여 테스트 케이스를 설계합니다. - 유스케이스 다이어그램(Use Case Diagram)
시스템의 기능적 요구사항을 유스케이스로 모델링하고, 각 유스케이스에 대한 테스트 케이스를 작성합니다.
- 상태 전이 다이어그램(State Transition Diagram)
- 화이트박스 및 블랙박스 테스트 (White-box and Black-box Testing)
- 화이트박스 테스트(White-box Testing)
코드의 내부 구조를 이해하고 테스트 케이스를 설계하는 방식입니다. - 블랙박스 테스트(Black-box Testing)
소프트웨어의 내부 동작을 몰라도 기능을 테스트하는 방식입니다.
- 화이트박스 테스트(White-box Testing)
이러한 테스트 설계 기법은 상호 보완적으로 사용될 수 있으며, 프로젝트의 특성과 목적에 따라 적절한 기법을 선택하는 것이 중요합니다. 종종 다양한 기법을 혼합하여 사용하는 것이 효과적일 수 있습니다
테스트 대상의 결함을 효과적이고 효율적으로 검출하기 위해서는 정적 테스트와 동적 테스트 두 가지 주요 테스트 기법을 사용합니다.
- 정적 테스트(Static Testing)
- 정의
소프트웨어가 실행되지 않는 상태에서 수행되는 테스트 활동으로, 코드나 문서를 검토하고 분석하는 과정을 포함합니다. - 활동 및 기법
- 코드 검토(Code Review)
소스 코드를 다른 개발자들과 함께 검토하여 오류를 발견하고 품질을 향상시키는 활동입니다. - 정적 분석(Static Analysis)
코드나 문서를 실행하지 않고도 분석 도구를 사용하여 오류를 찾고 검출하는 과정입니다. - 워크스루(Walkthrough)
개발된 문서나 코드를 팀 전체가 함께 훑어보며 피드백을 주고받는 활동입니다.
- 코드 검토(Code Review)
- 정의
- 동적 테스트(Dynamic Testing)
- 정의
소프트웨어가 실행되는 상태에서 동작을 확인하고 테스트하는 활동으로, 코드나 소프트웨어의 실행을 포함합니다. - 활동 및 기법
- 단위 테스트(Unit Testing)
개별 모듈이나 컴포넌트의 기능을 테스트합니다. - 통합 테스트(Integration Testing)
모듈이나 컴포넌트를 통합하여 상호 작용을 테스트합니다. - 시스템 테스트(System Testing)
전체 시스템이 기능적 및 비기능적 요구사항을 충족하는지 확인합니다. - 인수 테스트(Acceptance Testing)
최종 사용자가 시스템이나 소프트웨어를 수용할 수 있는지 확인합니다.
- 단위 테스트(Unit Testing)
- 정의
정적 테스트, 동적 테스트 구분과 설명
- 정적 테스트
- 목적
오류를 초기에 발견하고 수정함으로써 소프트웨어의 품질을 향상시키는 데 중점을 둡니다. - 수행 시점
소프트웨어가 실행되기 전에 수행됩니다. - 프로세스
주로 검토, 분석, 토론과 같은 과정을 포함합니다. - 효과
초기에 발견된 오류는 수정 비용이 낮고, 테스트 중 및 테스트 후 발견된 오류보다 수정이 더 용이합니다.
- 목적
- 동적 테스트
- 목적
소프트웨어의 실제 동작을 확인하고 예상된 결과와 비교하여 품질을 평가합니다. - 수행 시점
소프트웨어가 실행되는 동안 또는 실행 이후에 수행됩니다. - 프로세스
주로 테스트 계획, 테스트 케이스 설계, 실행, 결과 분석과 같은 과정을 포함합니다. - 효과
소프트웨어의 실제 동작을 확인하기 때문에 실제 사용 환경에서의 문제를 더 잘 파악할 수 있습니다.
- 목적
정적 테스트와 동적 테스트는 서로 보완적인 특성을 가지며, 프로젝트의 다양한 단계에서 혼합하여 사용되어 효과적인 품질 보증을 제공합니다.
'CSTS' 카테고리의 다른 글
test procedures (0) | 2024.01.08 |
---|---|
test case design (0) | 2024.01.05 |
feature & test types (1) | 2024.01.04 |
test target & test level (0) | 2024.01.04 |
testing, V&V, QA (0) | 2023.12.21 |