2019년 2월 1일
테스트 케이스 (Test Case)
I. 소프트웨어의 결함 예상 조건, Test Case
가. Test Case의 개념
 |
- 특정한 프로그램 부분 및 경로를 실행해보거나 요구사항에 준수하는 지를 확인하기 위해 개발된 입력 값, 실행 조건, 예상된 결과
- 테스트하려는 시스템이 수행해야 하는 Action들로 구성되는 일련의 단계
나. Test Case 설계의 중요성
- 테스트 수행의 많은 문제들은 Test Case 설계의 미흡함에서 발생
- 테스트 기술 없이 직관적으로 테스트를 수행하면 인력, 시간의 낭비 초래
- 기능적, 비 기능적 요구 사항에 대한 검증 및 확인 산출물로서 이용
- 향후 발생 될 가능성이 있는 결함에 대한 서전 검증 및 오류 Risk 최소화
- 요구사항과 부합, 일치성 확인 및 Test Case 로 인한 소통 오류 최소화
II. Test Case 구성요소 및 설계 유형
가. IEEE829 표준 기반 소프트웨어 Test Case 구성요소
| 구성요소 | 설명 |
|---|---|
| 식별자 (Identifier) | 항목 식별자 |
| 테스트 항목 (Test Item) | 테스트 할 모듈 또는 기능 |
| 입력 명세 (Input Specification) | 입력 값 또는 조건 |
| 출력 명세 (Output Specification) | 테스트 케이스 실행 시 기대 출력 결과 |
| 환경 설정 (Environmental Needs) | 테스트 수행 시 필요한 H/W, S/W 환경 |
| 특수 절차 요구 (Special Procedure Requirement) | 테스트 케이스 수행 시 요구 절차 |
| 의존성 기술 (Interface Dependencies) | 테스트 케이스 간 의존성 |
나. Test Case의 설계 유형
| 구분 | 테스트 기법 | 내용 |
|---|---|---|
| Black Box Test | 동등 분할 (Equivalence Partitioning) | 여러 Test Case 중에 실제로 수행할 대표적인 Test Case를 선택하는 방법 다양한 입력 사례들을 갖춘 각 시험 사례 유형 마다 최소의 시험 사례 작성 |
| 경계 값 분석 (Boundary Value Analysis) | 입력 값의 경계 값에서 오류 발생 가능성이 높다는 통계에 의한 Case 작성 | |
| 원인–결과 그래프 (Cause Effect Graphing) | 입력 데이터 간의 관계가 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 사례를 발견, 동등 분할과 경계 값 분석의 단점인 입력 환경의 복잡성을 완전하게 고려할 수 없는점 보완 | |
| 오류 예측 (Error Guessing) | 각 시험 기법이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아 보는 것 | |
| Pairwise Testing | 가능한 모든 입력 값을 테스트 하는것은 비현실적 모든 입력 값들의 조합 대신 모든 짝의 조합을 테스트, 모든 입력값을 테스트 하는것과 비슷한 효과 | |
| White Box Test | 제어 구조 시험 (Control Structure Testing) | 프로그램의 논리적 복잡도를 측정한 후 이 척도에 따라 수행 시킬 기본 경로들의 집합을 정의 시험영역을 최대화 시키며 독립경로들을 자동발견 |
| 루프 시험 (Loop Testing) | 프로그램 루프 구조에 국한해서 실시하는 시험 초기화 결함, 인덱싱 및 증가 결함, 루프의 경계에서 나타나는 경계 오류 발견 |
III. Test Case의 작성
가. Test Case 작성 절차
| 테스트 계획 검토 → 자료 확보 → 위험 평가 및 우선 순위 → 테스트 요구사항 정의 → 테스트 케이스 구조 설계 → 테스트 방법 결정 → 테스트 케이스 정의 → 테스트 케이스 타당성 검토 → 테스트 수행 |
나. White/Black Box기반 Test Case 도출 및 적용 기법
| 구분 | White Box | Black Box |
|---|---|---|
| 분류 관점 | 개발자 중심, 내부 논리 경로 위주, 알고리즘 위주 | 사용자 중심, 데이터 위주, 입출력 위주, 명세 기나 |
| 테스트케이스도출 | 소프트웨어 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출 | 테스트 케이스를 모델로부터 체계적으로 도출 |
| 주요 테스트 | 구조, 모듈 테스트 | 기능 테스트, I/O 테스트 |
| 테스트 기법 | 제어 구조, 루프 제어, 경로 시험, 결정 조건 | 동등 분할, 경계 값 분석, 의사 결정 테이블, 상태전이 테스트 |
| 테스트 포인트 | 프로그램 문장 및 라인 영역 분기 영역, 조건 영역 확인 | 테스트 오라클 (입,출력에 대한 올바른 예상 출력) 필요 |
| 결함 형태 | 초기화 결함, 런타임 메모리 Leak, 인덱싱 및 증가 결함 | 부정확하거나 누락가능, 성능 결함, 자료 구조나 DB 오류 |
다. White Box Test와 Black Box Test의 공통점
| 항목 | 설명 |
|---|---|
| 동적 테스트 기법 | – 원시 코드를 수행시켜 오류를 찾는 방법 – 프로그램을 통한 테스트 수행 |
| 품질 향상 | – 원시 코드의 품질 향상 – 원시 코드 시스템 내부 논리(White Box) – 성능 및 IF (Black Box) 중심 체크 |
| 상호 호환 | – 내부 로직의 정확성은 White Box로 검증 – IF 정확성은 Black Box로 병행 검증을 통해 보완 |
라. Test Case 작성 시 유의사항
- 테스트 케이스 설계는 테스트 이전에 이루어져야 하고, 이상적으로는 시스템 설계 시 작성 되어야 함
- 테스트 케이스에 대해 개발 그룹과 사용자 간 Baseline 확정
- 명확한 입력 값이 필요한 경우 입력 값 명시
About The Author
도리
4 Comments
교육자료에 사용해도 될까요
네~ 교육자료에 사용하셔도 됩니다.^^
좋은 글 감사합니다.
저도 해당 게시글을 바탕으로 교육 자료에 사용해도 될까요?
네~ 도움이 되신다면 얼마든지 교육 자료에 사용하셔도 됩니다.^^