테스트 자동화 프레임워크

희망을 갖지 마시길.....ㅠ.ㅠ

 

테스트 자동화 프레임워크 정리 부터 해봅니다.

STAF / eclipse

서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크

http://staf.sourceforge.net/

The Software Testing Automation Framework (STAF) is an open source, multi-platform, multi-language framework designed around the idea of reusable components, called services (such as process invocation, resource management, logging, and monitoring). STAF removes the tedium of building an automation infrastructure, thus enabling you to focus on building your automation solution. The STAF framework provides the foundation upon which to build higher level solutions, and provides a pluggable approach supported across a large variety of platforms and languages.

 

FitNesse / eclipse

http://fitnesse.org/

웹기반 테스트케이스 설계/실행/결과확인 등을 지원하는 테스트 프레임워크

 

NTAF

http://dev.naver.com/projects/ntaf/

NHN 테스트 자동화 프레임워크이며, STAF와 FitNesse를 통합

 

Selenium

http://seleniumhq.org/

다양한 브라우저 지원 및 개발언어를 지원하는 웹애플리케이션 테스트 프레임워크

 

watir

Ruby 기반 웹애플리케이션 테스트 프레임워크

http://watir.com/

 

6. SW 테스트 기법 (2)

▣ 구조기반 기법

코드와 개발 설계 등의 SW 구현 정보를 기반으로 테스트 케이스를 설계하는 기법이다.

● 구문 테스팅(Statement Testing)

프로그램 내의 모든 문장들을 한번 이상 수행하도록 테스트 케이스를 설계하는 기법이다.

 

[예제]

다음과 같은 제어 흐름도를 커버하는 구문 테스팅 테스트 케이스를 설계하기 위해서는 제어 흐름도의 모든 문장들을 통과하는 1개의 테스트 케이스가 필요하다.

【그림 II-17. 구문 테스팅 예제】

● 결정 테스팅(Decision Testing)

프로그램 내의 각 분기들을 한번 이상 수행하도록 테스트 케이스를 설계하는 기법이다.

 

[예제]

다음과 같은 제어 흐름도를 커버하는 결정 테스팅 테스트 케이스를 설계하기 위해서는 제어 흐름도의 모든 분기들을 통과하는 2개의 테스트 케이스가 필요하다.

【그림 II-18. 결정 테스팅 예제】

● 조건 테스팅(Condition Testing)

프로그램 내의 각 조건들을 보장하기 위해 조건들이 참이 되는 경우와 거짓이 되는 경우를 모두 수행하도록 테스트 케이스를 설계하는 기법이다.

 

[예제]

다음과 같은 조건을 커버하는 조건 테스팅 테스트 케이스를 설계하기 위해서는 3개의 테스트 케이스가 필요하다.

if(A>1 AND B<=0){
  A=B+4;
}

 

【표 II-17. 조건 테스팅 예제】

	A=2, B=-2	A=0, B=-2	A=0, B=2
A>1	true	false	false
B<=0	true	true	false
A>1 AND B<=0	true	false	false

● 데이터 흐름 테스팅(Data Flow Testing)

프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라, 프로그램의 테스트 경로들을 선택하는 방법이다.

 

【표 II-18. 데이터 흐름 테스팅 예제】

 

구분	내용
all-node	▶ 프로그램의 모든 node(statement)가 포함되도록 선정한다.
all-edge	▶ 프로그램의 모든 edge(statement의 흐름 또는 decision에 의한 branch등)가 포함되도록 선정한다.
all-defs	▶ 한 노드에서 정의된(assigned) 특정 변수가 그 값이 변하기 전에 적어도 한번은 활용될 수 있도록 path를 선정하고, 이에 따른 테스트 케이스를 추출한다. 노드는 프로그램 전체로 확장한다.
all-p-use (all-predicate-use)	▶ 한 노드에서 정의된 특정 변수가 그로부터 존재하는 모든 dpu의 원소(값이 바뀌지 않고 predicate use로 사용된 노드들)까지의 path가 존재하도록 선정한다. 노드는 프로그램 전체로 확장한다.
all-c-use (all-computation-use)	▶ 한 노드에서 정의된 특정 변수가 그로부터 존재하는 모든 dcu의 원소(값이 바뀌지 않고 computational use로 사용된 노드들)까지의 path가 존재하도록 선정한다. 노드는 프로그램 전체로 확장한다.
all-c-use/ some-p-use	▶ All-c-use를 적용시키되, c-use가 존재하지 않는 variable에 대해서는 p-use를 적용시키는데 이때는 all이 아닌 some으로 적용시킨다.
all-p-use/ some-c-use	▶ All-p-use를 적용시키되, p-use가 존재하지 않는 variable에 대해서는 c-use를 적용시키는데 이때는 all이 아닌 some으로 적용시킨다.
all-uses	▶ 한 노드에서의 variable에 대해 dcu, dpu를 만족시키는 path를 모두 고려하도록 테스트 케이스를 정한다.
app-paths	▶ 프로그램의 모든 path를 포함시켜서 테스트 케이스를 선정한다.

 

 

6. SW 테스트 기법 (1)

테스트는 보다 적은 테스트 케이스로 보다 많은 결함을 찾을 수 있도록 설계하기 위해, 테스트 기법을 활용할 필요가 있다. 현재 SW 테스트 관련 국제표준(ISO/IEC 29119)은 SW공학 기술위원회 표준화 분과가 운영되고 있으며, 작업그룹(WG26)에서 표준 제정을 담당하고 있다. 본 가이드에서는 국제표준(ISO/IEC 29119)에 따른 동적 SW 테스트 기법을 소개한다.

 

【표 II-14. 동적 테스트 기법의 분류】

명세기반 기법	구조기반 기법
▶ 등가분할(Equivalence Partitioning) ▶ 분류 트리 기법(Classification Tree Method) ▶ 경계값 분석(Boundary Value Analysis) ▶ 상태 전이 테스팅(State Transition Testing) ▶ 결정 테이블 테스팅(Decision Table Testing) ▶ 원인-결과 분석(Cause-Effect Graphing) ▶ 조합 테스트 기법(Combinatorial Test Techniques) ▶ 시나리오 테스팅(Scenario Testing) ▶ 오류 추정(Error Guessing)	▶ 구문 테스팅(Statement Testing) ▶ 결정 테스팅(Decision Testing) ▶ 조건 테스팅(Condition Testing) ▶ 데이터 흐름 테스팅(Data Flow Testing)

▣ 명세기반 기법

시스템에서 제공하는 기능 및 메뉴 등 명세를 기반으로 테스트 케이스를 설계하는 기법이다.

 

● 등가분할(Equivalence Partitioning)

SW나 시스템의 입력값은, 입력의 결과로 나타날 결과값이 동일한 경우, 하나의 그룹으로 간주될 수 있다. 그리고 이러한 그룹 내의 입력값은 내부적으로 같은 방식으로 처리됨을 가정한다. 동등분할은 이러한 원리를 이용하여, 입/출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가집합의 원소 중 대푯값 하나를 선택하여 테스트 케이스를 선정하는 것이다. 이 기법은 가능한 모든 경우의 수에서 테스트 개수를 줄여준다.

 

[예제]

A라는 학교에서 학생들의 성적에 따른 등급을 자동으로 계산해 주는 프로그램을 만들고자 한다. 100~90점은 A, 89~70점은 B, 69~50점은 C, 49점 이하는 D로 산정하고자 한다. 이때 등가분할에 의거한 데이터는 100<=점수<=90, 89<=점수<=70, 69<=점수<=50, 점수<=49로 총 4개의 데이터가 산출될 수 있다. 이것은 최소한 결과의 값을 선택하여 테스트를 수행한다는 것까지 보장한다.

● 분류 트리 기법(Classification Tree Method)

SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하는 기법이다. 트리구조를 시각화 하여 테스트 케이스를 설계하므로 불필요한 중복 및 누락을 회피할 수 있다.

 

[예제]

【그림 II-11. 표 만들기 예제】

 

위의 표 만들기 구조를 분류 트리 기법을 적용하여 분석하면 아래와 같이 시각화 하여 나타낼 수 있다.

 

【그림 II-12. 분류 트리 기법 예제】

● 경계값 분석(Boundary Value Analysis)

Partitioning을 이용하여 입출력 도메인을 equivalence class로 나누었을 때, 각 범위의 경계 값에서 결함이 발생하는 경우가 많다는 사실에 착안하여, 결함 검출 가능성을 높일 수 있도록 테스트 케이스를 설계하는 기법이다. 즉, equivalence class 안에서 테스트 케이스를 선정할 때, 임의의 데이터를 이용하는 것 대신에 class의 경계에 있는 데이터를 이용한다. 이 방법의 경우, 입출력의 수많은 변형이 존재할 수 있기 때문에 많은 수의 테스트 케이스를 요구 받게 되므로, 각 입력 변수를 위해 최소한 9개의 테스트 케이스를 선정해야 한다. 또 복잡한 계산을 요구하는 문제의 경우 equivalence class의 범위를 정의하는 것이 어려우므로 가능한 한 상세한 요구명세가 필요하다는 제한이 있다.

 

[예제]

조건이 a≦ X₁≦b 이고, c≦ X₂≦d 일 때, 각 범위의 경계값을 분석하여 아래와 같이 입력값을 산정할 수 있다.

【그림 II-13. 경계값 분석 예제】

● 상태 전이 테스팅(State Transition Testing)

시스템의 모든 입출력 상태를 식별하고, 도달 가능한 모든 상태의 입력 조합을 포함하는 상태 전이 테이블을 정의한 후, 테스트 케이스를 설계한다.

 

[예제]

디스플레이의 TIME 모드와 DATE 모드의 상태 전이 테스트 케이스를 아래와 같이 설계할 수 있다.

 

Case	1	2
Start State	S1	S2
Input	CM	CM
Expected Output	D	T
Finish State	S2	S1

【그림 II-14. 상태 전이 테스팅 예제】

● 결정 테이블 테스팅(Decision Table Testing)

요구사항의 논리와 발생 조건에 따라서 생성될 수 있는 결과를 테이블의 형태로 나열한 것으로, 조건과 행동의 모든 가능한 조합을 고려하여 테스트 케이스를 생성하는 기법이다.

 

[예제]

모든 사람은 350의 공제를 받는다. 단, 근무 이력이 있고, 나이가 40세를 초과하면 추가로 100의 공제를 받는다. 또한 앞의 조건과 상관없이 자녀가 4명이라면 40의 추가 공제를 받는다. 각 공제 조건에 따른 결과를 테이블 형태로 나열할 수 있다.

 

【표 II-15. 결정 테이블 테스팅 예제】

Condition	Case 1	Case 2	Case 3	Case 4	Case 5
근무이력	Y	Y	Y	Y	N
나이 > 40	Y	Y	Y		Y
나이 < 40				Y
나이 = 40
자녀 = 4	Y			Y
자녀 > 4		Y
자녀 < 4			Y
공제금액
350	X	X	X	X	X
100	X	X	X
50	X			X
총 공제금액	500	450	450	400	350

● 원인-결과 분석(Cause-Effect Graphing)

논리적으로 테스트 케이스를 생성하기 위해, 원인과 결과에 근거하여 테스트 케이스를 생성하는 방법으로, 시스템의 외부 동작만을 고려한다. 원인은 시스템의 내부 변화의 입력 상태를 나타내고, 결과는 시스템의 변환 또는 원인의 조합으로 인한 출력 상태를 나타낸다.

 

[예제]

원인과 결과에 대한 표기법을 아래와 같이 나타낼 수 있다.

【그림 II-15. 원인-결과 분석 기호 예제】

● 조합 테스트 기법(Combinatorial Test Techniques)

잠재적 조합 요소의 거대한 양을 처리하기 위한 테스트케이스를 선정하는데, 도움을 주는 통계적 테스트 기법이다. 요구되는 테스트 케이스의 이상적인 개수를 계산하고, 입력 값과 조건의 차를 식별하여, 테스트 케이스 선정 프로세스에서 최대 커버리지를 가지는 최소 개수의 테스트 케이스를 제공하는데 도움을 준다.

 

[예제]

파랑, 노랑, 빨강을 가질 수 있는 3개의 입력 값이 있을 경우, 조합 테스트 기법을 이용하여 다음 표와 같이 3³ 즉, 27개의 테스트 조합을 만들 수 있다.

 

【표 II-16. 조합 테스트 기법 예제】

 

Case	입력값 1	입력값 2	입력값 3	Case	입력값 1	입력값 2	입력값 3
1	파랑	파랑	파랑	15	노랑	노랑	빨강
2	파랑	파랑	노랑	16	빨강	노랑	파랑
3	파랑	파랑	빨강	17	빨강	노랑	노랑
4	노랑	파랑	파랑	18	빨강	노랑	빨강
5	노랑	파랑	노랑	19	파랑	빨강	파랑
6	노랑	파랑	빨강	20	파랑	빨강	노랑
7	빨강	파랑	파랑	21	파랑	빨강	빨강
8	빨강	파랑	노랑	22	노랑	빨강	파랑
9	빨강	파랑	빨강	23	노랑	빨강	노랑
10	파랑	노랑	파랑	24	노랑	빨강	빨강
11	파랑	노랑	노랑	25	빨강	빨강	파랑
12	파랑	노랑	빨강	26	빨강	빨강	노랑
13	노랑	노랑	파랑	27	빨강	빨강	빨강
14	노랑	노랑	노랑

● 시나리오 테스팅(Scenario Testing)

비즈니스 시나리오 또는 프로세스 흐름을 기반으로 테스트 케이스를 설계하는 방법이다. 시스템을 실제로 사용할 때 존재할 수 있는 결함을 발견하는데 유용하기 때문에, 인수 테스트를 설계하는데 유용하다.

 

[예제]

쇼핑몰 시스템의 경우 아래와 같은 다이어그램으로 나타낼 수 있다.

【그림 II-16. 시나리오 테스팅 예제】

 

다이어그램 안에 있는 상품 구입, 상품 등록, 재고 확인, 구입 취소, 취소 확인 시나리오에 대하여 Actor(회원/관리자)와 시스템의 교환을 스토리로 기술한다.

● 오류 추정(Error Guessing)

Ad-hoc Testing이라고도 불리며, 특정한 SW가 주어졌을 때, 직관과 경험의 의하여 어떤 특정한 형태의 결함이 발생할 것이라고 예측하고, 이 결함을 드러내 주는 테스트 케이스를 설계하는 기법이다. 직관적인 프로세스이기 때문에 특정한 프로시저를 가지는 것이 어렵다. 결함이 발생할 수 있는 상황들을 리스트로 열거해보고, 이 리스트를 테스트 케이스로 활용한다.

 

[예제]

정렬 프로그램에서 에러가 발생하기 쉬운 경우는 아래와 같으며, 해당 상황을 고려하여 테스트 케이스를 선정할 수 있다.
(1) 입력 리스트가 공란 리스트인 경우
(2) 입력 리스트가 하나의 원소만을 갖는 경우
(3) 입력 리스트의 모든 원소가 같은 값을 가지는 경우
(4) 입력 리스트가 이미 정렬되어 있는 경우

 

▣ 결함관리

결함 관리 활동을 수행하여 발생한 결함의 재발생을 막고, 유사 결함 발견 시 처리 시간을 단축하기 위한 활동이다.

【표 II-13. 결함관리】

결함 추적 관리 활동
착수 기준	입력물
▶ 단위 테스트 결함 추적관리  - 해당사항 없음	▶ 단위 테스트 결함 추적관리  - 테스트 활동 로그  - 결함관리대장
▶단위 테스트 결함 추적관리  - 설계 문서 결함 발견  - 통합 테스트 평가 완료	▶ 통합 테스트 결함 추적관리  - 테스트 활동 로그  - 결함관리대장
▶ 시스템 테스트 결함 추적관리  - 요구사항 명세서 결함 발견  - 시스템 테스트 평가 완료	▶ 시스템 테스트 결함 추적관리  - 테스트 활동 로그  - 결함관리대장
▶ 운영 테스트 결함 추적관리  - 요구사항 명세서 결함발견  - 운영 테스트 평가 완료	▶ 인수 테스트 결함 추적관리  - 테스트 활동 로그  - 결함관리대장
종료 조건	산출물
▶ 심각도 상위 수준의 결함 해결여부 확인	▶ 결함관리대장 ▶ 테스트 활동로그 ▶ 테스트 결과 보고서

● 결함관리 활동의 상세 절차

① 에러 발견

요구사항 분석, 설계, 테스트 수행 중에 에러가 발견될 경우, 전문 테스터와 프로젝트 팀과 의논한다.

② 에러 등록

결함관리대장에 발견된 에러를 등록한다.

③ 에러 분석

등록된 에러를 분석하여 단순 에러인지 실제 결함인지를 분석한다.

④ 결함 확정

등록된 내용이 결함으로 확정 될 경우, 결함을 결함확정 상태로 설정한다.

⑤ 결함 할당

결함을 해결할 담당자를 지정하고, 해당 결함을 할당한다. 이때 결함은 할당 상태가 된다.

⑥ 결함 조치

결함에 대한 수정 활동을 수행하고, 수정활동이 완료된 경우 결함을 결함조치 상태로 설정한다.

⑦ 결함 조치 검토 및 승인

수정이 완료된 결함에 대한 확인 테스트를 수행하여, 정상적으로 결함이 수정되었는지를 확인한다. 정상적으로 조치 완료된 경우 결함을 조치완료 상태로 설정한다.

【그림 II-10. 결함관리 활동 작업 흐름도】

 

5. SW 테스트 프로세스 (5)

▣ 테스트 평가

완료된 테스트 활동에서 데이터를 수집하여, 테스트에서 발견된 수치적 데이터와 함께 테스트 경험을 축적하는 단계이다.

 

● 테스트 평가

각 테스트 레벨 및 유형 별 테스트 결과를 상세히 분석하여 해당 테스트 활동의 종료 기준에 적합한지를 판단하는 활동이다.

【표 II-12. 테스트 평가】

테스트 평가 활동
착수 기준	입력물
▶ 단위 테스트 평가  - 테스트 케이스 실행 완료  - 테스트 결과 보고 작성 완료	▶ 단위 테스트 평가  - 테스트 계획서  - 테스트 결과 보고  - 결함관리대장
▶ 통합 테스트 평가  - 통합 테스트 실행 완료  - 통합 테스트 결과 보고 작성 완료	▶ 통합 테스트 평가  - 테스트 계획서  - 테스트 결과 보고
▶ 시스템 테스트 평가  - 시스템 테스트 실행 완료  - 시스템 테스트 결과 보고 작성 완료	▶ 시스템 테스트 평가  - 테스트 계획서  - 테스트 결과 보고  - 결함관리대장
▶ 운영 테스트 평가  - 운영 테스트 실행 완료  - 운영 테스트 결과 보고 작성 완료	▶ 운영 테스트 평가  - 테스트 계획서  - 테스트 결과 보고  - 결함관리대장
종료 조건	산출물
▶ 각 테스트 단계별 완료기준 만족	▶ 각 테스트 단계별 결과보고서 ▶ 각 테스트 단계별 테스트 케이스 명세서 ▶ 결함관리대장

● 테스트 평가 활동의 상세 절차

① 테스트 결과 상세분석

테스트 수행 결과로 작성된 모든 테스트 결과 보고와 결함관리대장을 검토한다.

② 테스트 커버리지 평가

실제로 제품의 모든 기능을 100% 테스트할 수 없으므로, 어느 정도 테스트가 수행 되었는지 파악하기 위해 커버리지를 측정한다.

③ 결함 분석 및 평가

- 테스트 수행 시 발견된 결함을 분석하여 의미 있는 정보를 도출한다.
 • 발견된 결함 평가는 SW 품질 및 신뢰성에 대한 정보를 제공한다.
 • 결함 분석 및 평가는 단순히 결함 수의 계산에서부터 통계 모델링 적용까지 다양한 방법을 적용하여 수행할 수 있다.

- 결함 분석을 위해 측정치를 작성하고, 결과에 대한 검토 및 분석을 수행한다.
 • 결함 분포: 특정 속성에 해당되는 결함 수
 • 결함 추세: 시간 흐름에 따른 결함 수에 대한 추이
 • 결함 에이징: 특정 결함 상태에 머물러 있는 시간

- 결함 분석에서는 하나 또는 그 이상의 결함 관련 파라미터와 연관하여, 결함 분포를 분석하는데, 가장 일반적으로 사용하는 결함 파라미터는 다음과 같다.
 • 우선순위(Priority): 결함 해결의 상대적인 중요성
 • 심각도(Severity): 결함의 상대적인 영향 정도
 • 근원(Source): 결함의 원인이 된 위치 및 근본적인 원인

④ 테스트 종료 결정

테스트가 수행되고 테스트 종료 조건을 만족할 경우 테스트 활동을 종료한다.

⑤ 테스트 결과 보고서 작성

테스트 결과 보고서는 테스트 대상 시스템의 품질과 테스트 상태에 대해 객관적인 평가를 내리고, 모든 이해관계자들과 의사소통 하는 수단으로 사용하기 위하여 작성된다. 경우에 따라 여러 관계자를 위한 문서를 만들 수 있는데, 대상이 누구냐에 따라 양식과 보고의 내용이 달라질 수 있다.
단, 테스트 결과는 다르게 왜곡해서는 안 되며, 독자의 수준에 따라 결과 보고서의 전문 용어의 사용 여부, 표현 방법 등이 달라질 수 있다.

⑥ 테스트 결과 보고서 검토 및 승인

작성된 테스트 결과 보고서를 프로젝트 관리자 및 품질보증 담당자등과 검토 및 협의를 수행한다.

【그림 II-9. 테스트 평가 활동 작업 흐름도】

 

5. SW 테스트 프로세스 (4)

▣ 테스트 실행

계획 및 구현된 테스트 활동을 실제로 실행하는 단계이다.

 

● 테스트 실행

준비되어 있는 테스트 케이스를 각 테스트 레벨별 테스트 계획에 따라 실행하는 활동이다.

 

【표 II-11. 테스트 실행】

테스트 실행 활동
착수 기준	입력물
▶ 단위 테스트 실행  - 코딩 작업 및 코드 검토 완료  - 단위 테스트 계획서, 테스트 케이스 작성 완료	▶ 단위 테스트 실행  - 코딩 작업 및 코드 검토 완료  - 단위 테스트 계획서, 테스트 케이스 작성 완료
▶ 통합 테스트 실행  - 단위 테스트 완료  - 통합 테스트 계획서, 테스트 케이스 작성 완료	▶ 통합 테스트 실행  - 단위 테스트 완료  - 통합 테스트 계획서, 테스트 케이스 작성 완료
▶ 시스템 테스트 실행  - 통합 테스트 완료  - 시스템 테스트 계획서, 테스트 케이스 작성 완료	▶ 시스템 테스트 실행  - 통합 테스트 완료  - 시스템 테스트 계획서, 테스트 케이스 작성 완료
▶ 인수 테스트 실행  - 시스템 테스트 완료  - 인수 테스트 계획서, 테스트 케이스 작성 완료	▶ 인수 테스트 실행  - 시스템 테스트 완료  - 인수 테스트 계획서, 테스트 케이스 작성 완료
종료 조건	산출물
▶ 설계 및 구현된 테스트 실행 완료	▶ 테스트 실행 로그 ▶ 갱신된 테스트 결과 보고서

● 테스트 실행 활동의 상세 절차

① 테스트 환경설정

테스트 계획서에 명시된 테스트 환경을 설정한다. 테스트 환경에는 HW와 지원 SW를 포함한다.

② 테스트 케이스 실행

해당 테스트 케이스를 실행한다. 자동화 도구를 사용할 경우, 테스트 자동화 스크립트를 실행한다.

③ 테스트 케이스 결과분석

실패로 기록된 테스트 실행 결과를 분석하여 사용자의 단순한 에러인지 결함인지를 판단하여, 결함 관리대장에 기록하고, 발견된 결함을 결함관리대장 양식을 이용하여 기록한 후 결함 내역, 결함 분류, 결함 발생 단계, 결함 심각도 등의 속성을 고려하여 입력한다.

④ 테스트 자산 개선

테스트를 수행하면서 변경된 테스트 케이스, 테스트 요구사항, 테스트 데이터 등을 업데이트 한다.

⑤ 테스트 결과 작성

테스트 케이스 명세서에 해당 테스트 케이스 실행 결과를 작성한다.

⑥ 테스트 실행 결과 검토

작성된 테스트 결과 및 결함조치 내역을 취합하여 프로젝트 관리자와 검토 및 협의를 수행한다.

⑦ 테스트 실행 결과 승인

테스트 케이스에 대한 승인을 요청한다.

【그림 II-8. 테스트 실행 활동 작업 흐름도】