SW 테스트 기법
테스트는 보다 적은 테스트 케이스로 보다 많은 결함을 찾을 수 있도록 설계하기 위해, 테스트 기법을 활용할 필요가 있다. 현재 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) 입력 리스트가 이미 정렬되어 있는 경우
▣ 구조기반 기법
코드와 개발 설계 등의 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를 포함시켜서 테스트 케이스를 선정한다. |