CHAPTER 01 - 애플리케이션 테스트 케이스 설계(2)

2024년도 수제비 실기책(6판) 내용

---

4) 동적 테스트

(1) 화이트박스 테스트(구조 기반 테스트)

 

[1] 기본 구분

 

• 결정 포인트가 2개 있는 프로그램과 제어 흐름도는 아래와 같음
• IF 문이 2개 분기가 2개 이고, 문장(구문) 2개로 이루어져 있음

제어 흐름 그래프(Control Flow Graph)	프로그램(소스 코드)
	입력값 : X, Y, Z 1. IF ((X > 2) AND (Y==2)) 2. Z = Z / X     END 3. IF ((X == 3) OF (Z > 2)) 4. Z = Z + 1     END

 

• 제어 흐름 그래프는 프로그램 구조를 효과적으로 나타낼 수 있는 도구이며 화이트 박스 테스트 시에 우선 프로그램을 기본 블록과 제어 흐름으로 구성된 제어 흐름 그래프를 그랜 후에 테스트 케이스를 추출함
• 가장 좋은 화이트 박스 테스트는 프로그램의 모든 경로를 최소한 한 번은 테스트하는 방법이지만, 프로그램 경로가 많이 때문에 불가능에 가까움
• 대안으로 일부 경로만 테스트하는 방법을 화이트박스 테스트에서는 주로 사용하고 있음

[2] 테스트 커버리지 개념(기라코)

 

• 프로그램의 테스트 수행 정도를 나타내는 값으로 테스트 수행의 완벽성을 측정하는 도구
• 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
• 테스트의 정확성과 신뢰성을 향상시키는 역할을 함

유형	설명
기능 기반 커버리지	- 테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정하는 방법 - 100% 달성을 목표로 하며, 일반적으로 UI가 많은 시스템의 경우 화면 수를 모수로 사용
라인 커버리지	- 애플리케이션 전체 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스코드의 라인 수를 측정하는 방법 - 단위 테스트에서는 이 라인 커버리지를 척도로 삼음
코드 커버리지	- 소프트웨어 테스트 충분성 지표 중 하나 - 소스 코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트되었는지를 측정하는 방법 - 일반적으로 테스트 커버리지라고 하면 코드 커버리지를 일컬음

코드 커버리지 유형

[3] 테스트 커버리지의 구성

 

• 구문(문장, Statement), 결정(Decision), 조건(condition), 결정 포인트(Decition Point)로 구성되어 있음

테스트 커버리지 구성

• 소스 코드는 구문(문장)으로 구성되어 있고 조건문에 대한 결정이 있고, 결정에 대한 각 조건식이 있음
• 참과 거짓에 대한 결정 포인트(분기 노드)가 있는데, 소스 코드상의 if, while, for, switch문이 결정 포인트라고 할 수 있음
• 전체 조건식은 소스 코드에서 결정 포인트 내에 있는 모든 조건문이고, 개별 조건식은 전체 조건식에 연산자(AND, OR 등)로 구분한 각각의 조건식

[4] 구문(문장) 커버리지(Statement Coverage)

 

• 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 테스트 커버리지
• 조건문 결과와 관계없이 구문 실행 개수로 계산함
• 문장 커버리지(%) = 테스트 케이스 집합에 의해 실행된 문장의 수 / (전체 실행 가능한 프로그램 문장의 수) x 100

제어 흐름 그래프(Control Flow Graph)	프로그램(소스 코드)
	입력값 : X, Y, Z

 

[테스트 케이스] 구문 커버리지 100% 만족하는 테스트 케이스는?

 

1. TC 1: X = 4, Y = 1, Z = 0
2. TC 2: X = 3, Y = 2, Z = 9

[풀이]

1. TC 1: a -> b -> e = 수행된 구문 2 / 전체 구문 4 = 2 /4 = 50% 만족
2. TC 2: a -> c -> d -> b -> f -> g -> e = 수행된 구문 4 / 전체 구문 4 = 4/4 = 100% 만족

[5] 결정 커버리지(Decision Cevoerage)

 

• 각 분기의 결정 포인트 내의 전체 조건식이 적어도 한 번은 참(T)과 거짓(F)의 결과를 수행하는 테스트 커버리지
• 선택 커버리지, 분기 커버리지(Branch Coverage)라고도 함
• 결정 커버리지(%) = (테스트 케이스 집합에 의해 실행된 결정의 결과 수 / 전체 프로그램 결과 수) X 100%
• 결정 커버리지는 구문 커버리지를 포함

제어 흐름 그래프(Control Flow Graph)	프로그램(소스 코드)
	입력값 : X, Y, Z

 

[테스트 케이스] 결정 커버리지를 100% 만족하는 테스트 케이스는? (단, TC 수행은 순차적으로 실행)

 

1. TC 1: X=1.5, Y=2, Z=2
2. TC 2: X=3, Y=2, Z=1
3. TC 3: X=1, Y=3, Z=3

[풀이]

 

1. TC 1: a -> c -> d -> b -> f -> g -> e = A 분기문 : T, B 분기문 : T
2. TC 2: a -> c -> d -> b -> e = A 분기문 : T, B 분기문 : F
3. TC 3: a -> b -> f -> g -> e = A 분기문 : F, B 분기문 : T

• TC1, TC2의 테스트 케이스만 수행하면 B 분기문만 결정 커버리지를 만족하고 A 분기문의 결정 커버리지는 만족하지 못함
• TC1, TC2, TC3의 테스트 케이스를 모두 수행해야만 구문 커버리지를 만족한 상태에서 결정 커버리지를 100% 만족하게 됨
• TC 수행은 순차적으로 실행 이라는 조건이 없다면 TC2, TC3의 테스트 케이스만을 수행해도 구문 커버리지를 만족한 상태에서 결정 커버리지를 100% 만족하게 됨

[테스트 케이스] 결정 커버리지를 100% 만족하는 테스트 케이스 경로는?

 

• 결정 커버리지는 각 분기의 결정포인트 내의 전체 조건식이 적어도 한번은 참(T)과 거짓(F)의 결과를 수행해야 함
• 즉, 첫번째 분기문도 참, 거짓이 한번씩 와야하고 두번째 분기문도 참, 거짓이 한번씩 와야함
• 분기문 둘다 참일경우: 1234561
• 분기문 둘다 거짓일 경우: 124567
• 첫 번째 분기문은 참, 두번째는 거짓: 1234567
• 첫 번재 분기문은 거짓, 두번째는 참: 124561
• 답은 2개(1234561, 124567 / 1234567, 124561)

 

[6] 조건 커버리지(Condition Coverage)

 

• 각 분기의 결정 포인트 내의 개별 조건식이 적어도 한 번은 참(T)과 거짓(F)의 결과가 되도록 수행하는 테스트 커버리지(전체 조건식의 영향을 고려하지 않음)
• 조건 커버리지(%) = (테스트 케이스 집합에 의해 실행된 조건의 결과 수 / 전체 프로그램 조건의 결과 수) X 100%

제어 흐름 그래프(Control Flow Graph)	프로그램(소스 코드)
	입력값 : X, Y, Z

 

[테스트 케이스] 조건 커버리지를 100% 만족하는 테스트 케이스는? (단, TC 수행은 순차적으로 실행)

 

1. TC 1: X=3, Y=0.5, Z=2
2. TC 2: X=1, Y=3, Z=3
3. TC 3: X=0.5, Y=4, Z=1

[풀이]

1. TC 1: a -> c -> d -> b -> e
2. TC 2: a -> b -> f -> g -> e
3. TC 3: a -> c -> d -> b ->f -> g -> e

테스트 케이스	X > 1	Y > 3	X < 2	Y > 1
TC 1: X = 3, Y = 0.5, Z = 2	T	F	F	F
TC 2: X = 1, Y = 3, Z = 3	F	F	T	T
TC3: X = 0.5, Y = 4, Z = 1	F	T	T	T

 

• TC1, TC2 까지의 테스트 케이스를 수행하면, 2개의 결정 포인트 내의 전체 조건식이 적어도 한번은 참(T)과 거짓(F)의 결과가 되는 결정 커버리지를 100% 만족하게되지만 조건 Y > 3이 True가 되는 경우는 전혀 테스트 하지 못함
• 조건 커버리지의 경우 결정 포인트 내의 개별 조건식이 적어도 한번은 참과 거짓의 결과가 되는 테스트 케이스를 가져야 하므로 TC1, TC2, TC3의 테스트 케이스를 모두 수행 해야 구문커버리지를 만족한 상태에서 2개의 결정 포인트 내의 개별 조건식이 적어도 한번은 참과 거짓의 결과가 되는 조건 커버리지를 100% 만족하게 됨
• TC 수행은 순차적으로 실행이라는 조건이 없다면, TC1, TC3의 테스트 케이스만을 수행해도 구문 커버리지를 만족한 상태에서 조건 커버리지를 100% 만족함

(2) 블랙박스 테스트(명세 기반 테스트)

 

• 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 기능 테스트
• 블랙박스 테스트는 곧 명세 테스트이며 모든 종류의 소프트웨어 시스템에 대해 테스트가 가능함
• 전체 소프트웨어 테스트 레벨(단위, 통합, 시스템, 인수)에서 적용할 수 있는 기법

[1] 동등분할 테스트(Equivalence Partitioning Testing)

 

• 입력데이터의 영역을 유사한 도메인별로 유효값/무효값을 그룹핑하여 유효값/ 무효값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트하는 기법
• 동치분할 테스트, 균등 분할 테스트, 동치 클래스 분해 테스트라고도 함

[테스트 케이스 설계 사례]

 

• 공기업 취업 기준에 따라 19세에서 60세까지만 고용할 수 있음
• 단, 19세 ~ 20세는 인턴으로 고용해야하고, 21세 ~ 60세는 정규 직원으로 고용해야함

[풀이]

 

1. 사전고려
   
   
   1. 동등 분할 방식을 적용하기 위해서는 우선적으로 입력과 출력을 식별해야함
   2. 또한, 입력과 출력에 대하여 동등분할을 수행할 때 유효한 입력 및 출력 뿐만 아니라 유효하지 않은 입력 및 출력도 고려해야 함
2. 동일한 출력 결과를 가지는 입력 조건 식별
   
   1. 19세 <= 나이 <= 20: 인턴으로 고용
   2. 21세 <= 나이 <= 60: 정규 직원으로 고용
   3. 나이 < 19, 나이 > 60: 고용불가
   4. 나이가 정수가 아닐 경우
3. 동등 클래스 분할
   

   

   동등 클래스 분할

4. 동등 클래스의 대푯값 선정
   

   

   대표값 선정

5. 동등 클래스 분할을 통한 테스트 케이스 도출 

테스트 케이스	입력값:나이	테스트 케이스 설명	예상 출력	실제 결과
1	18	나이 < 19	고용 불가
2	20	19 <= 나이 <= 20	인턴
3	40	20 < 나이 <= 60	정규 직원
4	65	60 < 나이	고용 불가
5	35.5	실수로 입력	에러
6	50세	문자열로 입력	에러
7	null	입력하지 않은 경우	에러

 

[2] 경겟값 분석 테스트(Boundary Value Analysis Testing)

 

• 등가 분할 후 경곗값(클래스 간의 경계 바로 위, 바로 아래의 값)부분에서 오류 발생 확률이 높기 때문에 경곗값을 포함하여 테스트 케이스를 설계하여 테스트 하는 기법
• 최솟값 바로 위, 최대치 바로 아래 등 입력값의 극한 한계를 테스트하는 기법으로 한곗값 테스트라고도 함
• 다수의 오류들이 입력 영역의 경계에서 발생하는 특징이 있으며, 대부분의 경우 동등분할 테스트와 함께 사용함

경계값 선택 기준

입력 조건	선택 기준
값의 범위	범위의 끝에 속하는 유효 입력값 범위 바로 바깥에 속하는 유효하지 않은 입력값
몇 개의 값	- 입력값의 최솟값과 최댓값 - 최솟값과 최댓값의 바로 아래와 바로 위의 값
파일, 리스트, 테이블과 같은 정렬된 집합 형태	첫 번재 항목과 마지막 항목
그외	개인의 독창성과 직관에 따라 경계에 해당하는 여러 값 선택

 

경계값 선택 기준

방법	설명
2-value	- 경계에 있는 값 - 바로 위, 아래 중 하나의 값(경계가 유효하면 유효하지 않은 값, 유효하지 않으면 유효한 값 선택)
3-value	- 경계에 있는 값 - 경계 바로 위의 값 - 경계 바로 아래의 값

 

[3] 결정 테이블 테스트(Decision Table Testing)

 

• 요구사항의 논리와 발생 조건을 테이블 형태로 나열하여 조건과 행위를 모두 조합하여 테스트하는 기법
• 입력 조건의 모든 조합에 대한 시스템의 액션을 고려하여 테스트 케이스를 도출하는 기법
• 복잡한 논리적 관계를 표현하기 좋고 누락된 요구사항 검사에 용이함

[결정 테이블 테스트 사례]

 

• 각 열을 하나의 테스트 케이스로 구성

조건	Condition	TC1	TC1=2	TC1=3	TC2	TC3	TC4
	History	Y	Y	Y	Y	N	N
	Age > 40	Y	Y	Y		Y
	Age < 40				Y
	Age = 40						Y
	Children = 4	Y			Y		Y
	Children > 4					Y
	Children < 4		Y	Y
행동	Action					X
	350	X	X	X	X		X
	100	X	X	X
	50	X			X		X
Total		500	450	450	400	350	400

 

[4] 상태 전이 테스트(State Transition Testing)

 

• 대상/시스템이나 객체의 상태를 구분하고이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 테스트 하는 기법
• 시스템을 상태 전이도로 모델링 한 후 상태 전이도에서 테스트 케이스를 도출하는 기법
• 상태 전이도는 시스템 외부에서 들어오는 일련의 이벤트들에 대해 시스템 상태가 어떻게 전이되고 어떤 식으로 반응하는 가를 나타내는 도구

 

- 상태 전이도 사례

- 전구는 ON 상태 또는 OFF 상태에 있을 수 있는데, 스위치를 누르는 행위에 따라 ON 상태에서 OFF 상태로 전이 되거나, 반대로 OFF 상태에서 ON 상태로 전이됨

 

 

 

 

 

 

[5] 유스케이스 테스트(Use Case Testing)

 

• 시스템이 실제 사용되는 유스케이스로 모델링 되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화 하여 테스트 하는 기법

출처 - 수제비 도서 사진촬영

 

[6] 분류 트리 테스트(Classification Tree Method Testing)

 

• SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하여 테스트하는 기법
• 입력 및 동작을 다양한 기준으로 구분한 트리를 이용해서 테스트 케이스를 설계함
• 동등분할 영역을 구분하는 것과 유사하며 동등분할 테스트 커버리지 측정 원리와 동일함

 

출처 - 수제비 도서 사진촬영

 

[7] 페어와이즈 테스트(Pairwise Testing)

 

• 테스트 데이터값들 간에 최소한 한 번씩 조합하는 방식이며 이는 커버해야할 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 테스트 기법임
• 대부분의 결함이 두 입력값의 상호 작용에 기인하므로 가능한 모든 입력값의 조합을 테스트한 것과 비슷한 효과를 얻음
• 상대적으로 적은 양의 테스트 세트 구성이 용이하고 입력 변수 개수와 입력 가능 값이 많을수록 테스트 케이스 도출 복잡도가 높음

(3) 경험 기반 테스트

 

• 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한 직관과 기술 능력을 기반으로 수행하는 테스트기법

유형	설명
탐색적 테스트 (Exploratory Test)	- 테스트 스크립트 또는 테스트 케이스를 문서로 작성하지 않고 경험에 바탕을 두고 탐색적으로 기능을 수행해 보면서 테스트하는 기법 - 사전에 구체적으로 테스트 케이스를 설계하고 이를 바탕으로 테스트를 수행하는 방식이 아니라, 테스트 대상에 대한 이해, 테스트 케이스 설계, 테스트 실행을 병행하는 방식 - 무작위 테스팅이 아닌 중대한 테스트 위주, 테스트 엔지니어의 휴리스틱한 능력 필요, 제품을 익히면서 테스트를 설계하고 테스트 수행 - 구성요소는 테스트 차터, 시간제한(Time boxing), 노트(Note), 회고
오류 추정 (Error Guessing)	- 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스를 설계하여 테스트하는 기법 - 특정 테스트 대상이 주어지면 테스터의 경험과 직관을 바탕으로 개발자가 범할 수 있는 실수들을 나열하고, 해당 실수에 따른 결함을 노출하는 테스트 수행 - 오류 추정은 일반적으로 예상되지 않는 상황이 사용자 입력값으로 적절히 처리 되고 있는지 확인할 때 유용함 - 필수 입력, 입력 항목의 길이, 입력 항목의 형식, 입력값의 명시적 제약사항, 입력값의 묵시적 제약사항 등을 확인할 때 유용

 

** 휴리스틱(Heuristics) : 경험에 기반하여 문제를 해결하거나 학습하거나 발견해내는 방법

** 테스트 차터(Test Charter) : 수행될 각 테스트 세션에 대해 명확한 임무를 설정해 놓은 명령지

** 회고(Debriefing) : 탐색적 테스팅 세션 종료 후 팀원끼리 요약보고 시간을 갖고 테스트 수행 과정과 경험을 팀원과 공유하는 보고 회의

5) 테스트 케이스

• 특정 요구사항에 준수하는 지를 확인하기 위한 개발된 입력값, 실행 조건, 예상된 결과의 집합

(1) 테스트 케이스 필요 항목

구분	항목	설명
공통 작성 항목 요소	테스트 단계명, 작성자, 승인자, 작성 일자, 문서 버전	단위, 통합, 시스템, 인수 테스트 등의 테스트 단계와 테스트 케이스 작성자, 승인자, 작성일자, 버전 등을 작성
	대상 시스템	애플리케이션 개발 서버 또는 개발 시스템명 등을 작성
	변경 여부	테스트 케이스 변경 여부 및 변경 사유 등을 작성
	테스트 범위	테스트 대상 애플리케이션의 기능별 테스트 범위 및 업무별 테스트 범위를 식별
	테스트 조직	테스트 케이스 작성 및 테스트 수행을 담당할 조직 식별
개별 테스트 케이스 항목 요소	테스트 ID	테스트 케이스를 고유하게 식별하기 위한 ID를 작성
	테스트 목적	테스트 시 고려해야 할 중점 사항이나 테스트 케이스의 목적을 작성
	테스트할 기능	애플리케이션의 테스트할 기능을 간략하게 작성
	테스트 데이터  = 입력 데이터	테스트 실행 시 입력할 데이터(입력값, 선택 버튼, 체크 리스트 값 등)를 작성
	예상 결과  = 기대 결과	테스트 실행 후 기대되는 결과 데이터(출력 데이터, 결과 화면, 기대 동작 등)를 작성
	테스트 환경	테스트 시 사용할 물리적, 논리적 테스트 환경, 사용할 데이터, 결과 기록 서버 등의 내용을 작성
	테스트 조건  = 전제 조건	테스트 간의 종속성, 테스트 수행 전 실행되어야 할 고려 사항 등을 작성
	성공/실패 기준	테스트를 거친 애플리케이션 기능의 성공과 실패를 판단하는 조건을 명확하게 작성
	기타 요소	사용자의 테스트 요구사항 중 특별히 고려해야 할 내용을 간략하게 기술

6) 테스트 오라클(Test Oracle)

• 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법

(1) 테스트 오라클 종류(참샘휴일)

유형	설명
참(True) 오라클	모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
샘플링(Sampling) 오라클	특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클
휴리스틱(Heuristic) 오라클	샘플링 오라클을 개선한 오라클로 특정 입력값에 대해 올바른 결과를 제공하고 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
일관성 검사 (Consistent) 오라클	애플리케이션 변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클

---

2. 애플리케이션 테스트 시나리오 작성

1) 테스트 레벨(Test Level)

• 함께 편성되고 관리되는 테스트 활동의 그룹이며 프로젝트에서 책임과 연관되어있음
• 각각의 테스트 레벨은 서로 독립적

V 모델과 테스트 레벨

** V 모델 : SW 생명주기 각 단계별로 개발자 관점에서의 공정 과정상 검증과 사용자 관점에서의 최종 산출물에 대한 확인을 지원하기 위한 테스트 모델

 

[1] 테스트 레벨의 종류

 

• 분석, 설계, 개발 단계에서 부과된 조건을 만족하는지 검증을 수행하고, 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 단계에서 최종 산출물에 대한 확인을 함

종류	설명	기법
단위 테스트	사용자 요구사항에 대한 단위 모듈 서브루틴등을 테스트하는 단계	자료 구조 테스트, 실행 경로 테스트, 오류 처리 테스트, 인터페이스 테스트
통합 테스트	단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호 작용을 검증하는 테스트 단계	빅뱅 테스트, 샌드위치 테스트, 상향식 테스트, 하향식 테스트
시스템 테스트	통합된 단위의 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 단계	기능 / 비기능 요구사항 테스트
인수 테스트	계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계	계약 인수, 규정 인수, 사용자 인수, 운영상의 인수, 알파 / 베타 테스트

 

[2] 단위 테스트(Unit Test)

 

• 소프트웨어 설계의 최소 단위의 모듈이나 컴포넌트에 초점을 맞춘 테스트
• 사용자의 요구사항을 기반으로 한 기능성 위주의 테스트를 수행
• 명세 기반 테스트(블랙 박스 테스트)와 구조 기반 테스트(화이트박스 테스트)로 나누어지지만 주로 구반 테스트 위주로 수행한다

[3] 통합 테스트(Integration Test)

 

• 소프트웨어 각 모듈간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
• 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 테스트

[4] 시스템 테스트(System Test)

 

• 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행 되는지를 검증하는 테스트
• 컴퓨터 시스템을 완벽하게 검사하기 위한 목적 또는 성능 목표를 가지고 테스트

[5] 인수테스트(Acceptance Test)

 

• 최종 사용자와 업무의 이해관계자 등이 테스트를 수행함으로써 개발된 제품에 대해 운영 여부를 결정하는 테스트
• 시스템의 일부 또는 특정한 비기능적인 특성에 대해 인수 테스트를 통해 확인함

종류	설명
알파 테스트 (Alpht Test)	선택된 사용자(회사 내의 다른 사용자 또는 실제 사용자)가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트
베타 테스트 (Beta Test)	실제 환경에서 일정 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 인수 테스트

2) 테스트 시나리오(Test Scenario) 개념

• 테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세한 문서
• 테스트 수행 절차를 미리 정함으로써 설계 단계에서 중요시되던 요구사항이나 대안 흐름과 같은 테스트 항목을 빠짐없이 테스트함

(1) 테스트 시나리오 작성 시 유의점

 

• 테스트 시나리오 분리 작성: 테스트 항목을 하나의 시나리오에 모두 작성하지 않고, 시스템별, 모듈별, 항목별 테스트 시나리오를 분리하여 작성함
• 고객의 요구사항과 설계 문서 등을 토대로 테스트 시나리오를 작성
• 각 테스트 항목은 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인 등의 항목을 포함하여 작성