ISTQB/ SW 테스팅 ) 4장. 테스트 설계 및 구현 프로세스, 테스트 설계 기법의 종류, 명세 기반 기법 - 동등 분할, 경계값 분석, 결

슬슬 한번씩 더 읽어봐야 이해가 되는 부분이 왔다. 그래도 꽤 재밌구만!!

---

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

▶ 테스트 설계의 진행 방식
 - 테스트 조직 구성
 - 테스팅과 개발 프로세스의 성숙도
 - 시간 절약
 - 참여인원 등 테스트 정황에 따라 달라짐
▶ 무엇을 테스트할지 결정하기 위해 테스트 베이시스 문서 분석
 - 테스트 베이시스 - 요구사항 명세서, 개발 설계서 등
▶ 테스트 조건
 - 기능, 트랜잭션, 품질 특성 또는 구조적 요소
▶ 테스트 설계 과정
 - 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함
▶ 테스트 케이스
 - 입력 값의 묶음
 - 실행 사전 조건
 - 기대 결과와 실행 사후 조건으로 구성
▶ 테스트 표준 문서
 - 소프트웨어 테스트 문서 표준(IEEE 829)
 - 테스트 설계 명세와 테스트 케이스의 표준 양식 제안
▶ 테스트 용이성 평가

테스트 분석 및 설계 단계	- 평가 대상 : 테스트 베이시스(개발 명세) - 낮은 품질의 테스트 베이시스는 테스트 케이스 도출이 어려우므로 테스트 베이시스의 테스트 용이성을 평가해 테스트 베이시스의 품질을 높임. - 명세서가 테스트를 고려해 작성됐는지 확인(테스트를 위한 API 설계 등)
테스트 구현 및 실행 단계	- 완결성    >> 테스트에 필요한 모든 것이 다 있는가? - 주요 기능성    >> 주요 기능이 잘 동작하는가? - 테스트 시작조건 준수 여부 검증 - 테스트 환경 검증    >> 테스트 인프라 확인(하드웨어, 도구, 테스트 데이터)    >> 기타 어플리케이션(stub, driver)

 
▶ 테스트 분석, 설계, 구현

▶ 테스트 케이스
 - 정의
   >> 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음.
   >> 실행 사전 조건, 기대 결과와 실행 사후 조건의 집합
   >> 테스트 돼야 하는 Test Condition((상황)을 입력 값과 기대결과로 표현
 - 작성 목적
   >> 요구되는 보장성을 갖는 최소개의(최적의) 테스트 케이스로 가능한 많은 결함을 발견할 수 있도록 정의한 목표 수준의 테스트 보장성 확보

< 테스트 케이스의 목적 >
1. 최소한의 테스트 케이스로 많은 결함을 발견하는 것.
2. 테스트 대상을 가능한 빠짐없이 테스트하여 테스트 보장성을 확보할 수 있도록 설계되어야 함.
3. 공식적 기법과 경험 기반의 비공식적 기법을 모두 이용해야 함.
 - 공식적 기법을 먼저 작성한 후에 비공식적인 기법으로 보완이 필요함.

 
  - 예시 테스트 케이스                                                                                                            결과값, 데이터나 상태 변화

▶ 테스트 케이스 개발 및 작성
 >> 테스트 케이스 개발 시 우선순위 선정 - 테스트 프로시져 명세서(테스트 케이스의 실행 순서) 만듦 - 테스트 실행 스케쥴 작성(테스트 실행도구를 사용하여 테스트를 수행하면 테스트 프로시저는 테스트 스크립트로 기술할 수 있음)
▶ 테스트 수행 절차
 >> 얼마나 상세하게 작성하는 것이 좋을 지 작성해야 함 - 테스터의 스킬, 능력, 해당시스템에 대한 이해를 고려하여 테스트 케이스의 상세함을 조절해야 함.
 >> 만약 외주를 주는 경우는 자주 테스터가 바뀌더라도 작업을 수행할 수 있도록 상세하게 수행 절차를 기록하여야 함.
▶ 테스트 케이스 작성
 >> 테스트 수행 절차를 얼마나 상세하게 작성하는 것이 적절한 지 결정해 주어야 함(테스트 케이스당 7스탭이내로 수행 절차를 작성하는 것이 바람직)
 >> 7스텝이 넘을 경우는 두 개로 분리하여 관리하는 것이 좋음

4.2 테스트 설계 기법의 종류

▶ 블랙박스 기법 VS. 화이트박스 기법

블랙박스 기법(>> 명세기반 기법과 경험기반 기법) - 완성제품	화이트박스 기법(>> 구조기반 기법) - 소스 대상
- 테스트 대상의 내부구조(코드)를 참조하지 않고 테스트 베이시스 그리고 개발자와 테스터, 사용자들의 경험을 바탕으로 기능적 혹은 비기능적 테스트 케이스를 도출하고 선택하는 방법.	- 컴포넌트(단위) 또는 소프트웨어(시스템)의 구조(코드)를 중심으로 테스트 케이스를 도출.

 
▶ 테스트 설계의 근원(Origin)을 기준
 - 명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류

명세 기반 기법	- 테스트 대상에 관한 공식적/ 비공식적 모델(명세) 사용 - 모델로부터 테스트 케이스를 체계적으로 도출	= 블랙박스 테스트 (공식적 방법)
구조 기반 기법	- SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출 - 작성한 테스트 케이스로부터 커러리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가할 수 있음.	= 화이트박스 테스트 (공식적 방법)
경험 기반 기법	- 테스터, 개발자, 사용자 등의 지식 활용 - 발생 가능한 결함과 그 분포 등에 대한 지식 활용 - 문서화 필요	= 탐색적 테스트 (비공식적 방법)

명세가 나오면 블랙박스, 구조가 나오면 화이트박스

4.3.1 명세 기반 기법(Specification - based)

▶ 명세 기반 기법

 - 종류 : 동등 분할, 경계값 분석, 조합 테스팅, 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅.

 

4.3.1.1 동등 분할

▶ 동등 분할
 - 입력 / 출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대표값을 선택하여 테스트 케이스를 도출하는 방법.
 - 동일한 입력에 대해 항상 동일한 결과를 갖도록 클래스 구분
 - 적용 방법
   >> 주어진 시스템 정보를 분석해 입력/ 출력 영역을 유사한 특징을 가진 클래스로 분할
   >> 분할된 클래스에서 각 클래스를 대표하는 테스트 케이스 도출
   >> 모든 Valid equivalence class(유효)가 커버될 때까지 테스트 케이스 생성
   >> 모든 Invalid equivalence class가 커버될 때까지 테스트 케이스 생성

4.3.1.2 경계값 분석

▶ 경계값 분석
 - 동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트
 - 분할 영역의 최대값과 최소값이 그 영역의 경계값
 - 동등 분할과 마찬가지로 모든 테스트 레벨, 테스트 유형에 적용
 - 동등 분할의 확장으로 여겨지며 동일한 방식으로 커버리지 보장

4.3.1.3 결정 테이블 테스팅

▶ 결정 테이블
 - 시스템의 동작을 결정하는 비즈니스 규칙을 정의하는 방법
 - 입력 값들이 논리적인 관계(Binary Condition - 참과 거짓)를 갖는 경우, 입력 값을 원인 / 결과로 나누어 기술
    -- > 테스트 케이스 작성
 - 구현이나 명세에 잠재된 오류를 찾는 데 효과적으로 이용
▶ 특징
 - 테이블 분석을 통해 중복, 발생 불가능한 상황, 모순이 생기는 상황을 제외시키고 나머지의 결정과 액션 조합
 - 좋은 테스트 데이터 선택을 위해, 경계 값 또는 동등 분할 기법 사용
 - 불가능한 Rule을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적.
▶ 결정 테이블 장단점

장점	- 요구사항 등 테스트 베이시스의 문제점을 발견할 수 있는 효과적인 테스트 케이스 생성 가능 (테스트 케이스를 작성하면서 결함 발견, 인스펙션 등 리뷰미팅에 테스트 전문가가 참여한다는 의미)  - 테스트 베이시스의 불완전성과 모호함 식별 가능
단점	- 작성에 노력과 시간이 많이 소요될 수 있음(특히 테스트를 위해 결정 테이블을 작성해야 하는 경우) - 복잡한 시스템은 표현하기 어려울 수 있으며, 작성 시 논리적인 실수 가능성있음(개발팀 검토 필요)