Part.4 테스트 설계 기법 - ISTQB (1)

4.1 테스트 설계 및 구현 프로세스

테스트 설계 절차 : 공식적 또는 비공식적
테스트 설계 진행 방식 : 조직 구성, 개발 프로세스의 성숙도, 시간, 참여 인원 등의 정황에 따라 달라진다.
테스트 조건 : 하나 이상의 테스트 케이스로 확인 가능한 항목 또는 이벤트
 - 기능, 트랜잭션, 품질 특성, 구조적 요소 등
* 추적성 부여 : 테스트 조건과 요구사항 사이에 추적성을 부여하여, 요구사항이 변경되었을 때의 영향도 분석, 요구사항 커버리지의 달성 여부 등을 확인할 수 있다.
테스트 케이스 : 입력값의 묶음, 실행 사전조건, 기대결과, 사후 조건으로 구성됨 / 특정 테스트 조건을 확인하기 위해 개발
 - 공식적인 기법으로 먼저 작성한 후 경험기반의 비공식적 기법으로 보완 필요
테스트 케이스의 목적 : 요구되는 보장성을 갖는 테스트 케이스로 가능한 많은 결함을 발견하는 것

테스트케이스의 구성요소
1. ID : 테스트 케이스를 식별하기 위한 번호, 구분 식별자나 일련번호
2. 사전 조건 : 테스트 수행 전의 선행 조건, 구동환경, 테스트 데이터의 정의 등
3. 테스트 수행절차 : 7단계 이내의 구체적인 테스트 수행 단계
4. 기대결과 : 테스트 실행 후 의도한 대로 동작하였는지 판단
 - 필수 속성으로 결과값, 데이터나 상태의 변화, 그 외 결과를 기록
 - 테스트의 정상 수행 여부를 판단할 수 있는 중요한 속성
5. 구분 : 테스트 케이스를 분류하여 구분하기 위함
6. 추적성 : 테스트 설계의 바탕이 된 요구사항 및 적용된 기법을 기록
7. 중요도 : 시간적 제약이 있을 경우 테스트 대상을 선택하기 위한 기준이 됨. 테스트 하지 않을 것만 표시하는 경우도 있음
8. 합격/불합격 : 테스트 케이스를 수행한 결과에 대한 최종 확인
 - Pass : 의도대로 동작하였음
 - Fail : 의도대로 동작하지 않았음
 - Not Tested : 테스트가 수행되지 않았음
 - Blocked : 사전 조건이 충족되지 않아 테스트 불가

 

4.2 테스트 설계 기법의 종류

블랙박스 기법 (명세/경험 기반 기법 포함) : 내부구조(코드)를 참조하지 않고 테스트 베이시스, 사용자의 경험을 분석
 -> 기능적 혹은 비기능적 테스트 조건으로 테스트 케이스를 도출
화이트박스 기법(구조기반 기법) : 컴포넌트 혹은 SW의 구조에 바탕을 두고 테스트 케이스를 도출

[기법들의 일반적 특징]
명세 기반 기법
- 해결할 문제를 명세하기 위해 공식적 또는 비공식적 모델을 사용
- TC를 시스템적으로 도출하는 것이 가능하다.
- 커버리지 측정이 가능하지만 구조 기반 기법에 비해 제한적

구조 기반 기법
- 코드와 개발 설계 등의 SW 구현 정보를 기반으로 TC를 도출
- 테스트 커버리지 측정이 가능하며, 커버리지를 높이기 위해 추가로 TC를 시스템적으로 도출할 수 있다.

경험 기반 기법
- 테스트 관련 인력의 지식이나 경험을 통해 TC를 도출
- SW에 대한 지식 / 자주 발생하는 결함이나 관련 지식

상황에 따라 여러 기법이 동시에 사용될 수 있다.
ex) 명세 기반인 상태 전이 테스팅 기법으로 TC를 도출하는 과정에서, 동등 분할 / 경계법 분석/ 조합 테스팅 등을 사용
ex) 리스크와 중요도가 높은 TC는 제어 흐름 테스팅이나 다중 컨디션 커버리지를 달성하는 기법을 사용