테스트를 왜 하는가?
소프트웨어 테스팅의 주 목적은 소프트웨어의 작동 여부(의도에 맞는) 및 품질 개선이다.
테스트를 거치지 않고 출시된 소프트웨어는 사용자의 경험을 망칠 수 있다.
어떻게 하는가?
소프트웨어 테스트는 다양한 분류를 가진다.
시각에 따른 테스트, 사용 목적에 따른 테스트
그리고 소프트웨어의 실행 여부에 따른 정적 테스트와 동적 테스트가 있다.
이번 글에서는 동적 테스트를 한번 파헤쳐 보자.
동적 테스트
동적 테스트란, 테스트 데이터를 기반으로 실제 프로그램을 실행하며 오류를 찾는다.
또한, 테스트 정보를 얻는 문서 종류에 따라 명세/구현 기반 테스트로 세분화된다.
명세 기반 테스트
명세 기반 테스트는 '블랙박스 테스트' 라고도 불린다.
소프트웨어 내부의 구조는 모르는 채로, 입력 값에 대한 예상 출력 값을 정해둔다.
그리고 예상 출력 결과와 실제 출력 값의 동일함이 해당 테스트의 결과가 된다.
사용자는 치킨의 재료를 넣어 맛있는 치킨이 나오길 원했고, 사용자의 요구는 충족되었다.
극단적인 예시지만, 입력값에 대한 예상 출력 값과 그 결과가 동일하다.
이 경우 성공이라고 할 수 있다.
명세 기반 테스트의 기법을 알아보자.
문법 기반(Syntax Driven)
문법 기반 테스트라는 말 그대로, 문법을 정한 후 적합/부적합 여부를 예측하여 테스트한다.
동등 분할(Equivalence Partitioning)
동등 분할 기법은 각 영역의 값을 그룹으로 나눠 임의의 값을 그 그룹의 테스트 결과로 본다.
경계 값 분석(Boundary Value Analysis)
동등 분할 기법과 비슷하지만, 입력 값의 경계를 이용하여 기대 결과와 함께 테스트한다.
최소, 중간, 최대의 값과 그 값의 +-1을 보통 테스트한다.
원인-결과 그래프(cause-effect graph)
입력 환경의 복잡성을 고려하기 위한 테스트 기법, 원인 결과 그래프를 만들어 위 기법들의 단점을 보완한다.
원인에 해당하는 입력 조건과 그 원인으로부터 발생하는 출력 결과를 가지고 만든다.
- 프로그램을 적합한 크기로 분할
- 규모가 큰 프로그램을 분할하여 원인-결과 그래프를 작성할 만한 크기로 분할한다.
- 원인과 결과를 찾는다.
- 명세서에서 원인과 결과를 찾아 일련번호와 같은 식별자를 각각 부여한다. 여기서 원인은 하나의 입력 조건이고, 결과는 출력 조건이다.
- 원인-결과 그래프를 작성한다
- 프로그램 명세가 의미하는 내용을 분석하여, 이에 알맞은 원인과 결과를 연결하는 논리 그래프를 작성한다. 그래프를 그리는 과정에서 그래프의 복잡성을 줄이기 위해 중간 노드를 사용할 수 있다.
사용되는 기호
제한 조건 기호
원인-결과 그래프를 바탕으로, 결과로부터 그 결과가 생기는 조건을 추적하여 그 사항을 기입한 의사결정 테이블로 변환한다. 의사결정 테이블(decision table)을 사용한 기법에서는 먼저 입력할 대상의 목록을 정한 후 입력 항목에 대해 가능한 모든 조합을 만든다.
입력 항목이 총점과 리포트인 경우에 가능한 조합이다.
그리고 조합한 8개 항목에 대한 다음과 같은 예상 결과를 [표 8-11]처럼 A+, A0, B+, B0, C+, C0, D, F로 나열한 후 예상되는 출력 값을 참(True, T로 표기)과 거짓(False, F로 표기)으로 표기한다.
• 1 : 90점 이상(T), 리포트 제출(T) → A+
• 2 : 90점 이상(T), 리포트 미제출(F) → A0
• 3 : 80점 이상(T), 리포트 제출(T) → B+
• 4 : 80점 이상(T), 리포트 미제출(F) → B0
• 5 : 70점 이상(T), 리포트 제출(T) → C+
• 6 : 70점 이상(T), 리포트 미제출(F) → C0
• 7 : 70점 미만(T), 리포트 제출(T) → D
• 8 : 70점 미만(T), 리포트 미제출(F) → F
작성된 의사결정 테이블을 기반으로 테스트 케이스를 도출한다.
예를 들어, 테스트 케이스 3번째의 테스트 데이터(총점 86점, 리포트 제출)를 생성했다면 결과 값이 B+가 되어야 한다.
구현 기반 테스트
구현 기반 테스트는 '화이트박스 테스트' 라고도 불린다.
소프트웨어 내부의 변수 혹은 서브루틴 등의 오류를 찾기 위해 프로그램 코드 내부 구조를 테스트 설계의 기반으로 사용한다.
하지만 소프트웨어 내부에 있는 모든 소스 코드를 검사하는 것은 많은 자원을 요구한다.
그렇기에 코드의 일부 경로를 테스트해야 하는데, 이를 위한 기준이 필요하다.
테스트 데이터 생성 기준, 테스트 데이터 적합성 기준을 알아보자
문장 검증 기준(Statement Coverage)
프로그램 내의 모든 문장이 최소한 한 번은 실행될 수 있는 테스트 데이터를 갖는 테스트 케이스를 선정하는 것이다. 이 기준은 다음과 같은 과정으로 수행한다.
1. 원시 코드를 제어 흐름 그래프 형태로 표현
2. 가능한 모든 경로를 구한다.
3. 문장 검증 기준을 만족하는 경로를 구한다.
4. 선택한 경로에 해당하는 테스트 케이스를 가지고 실행한다.
분기 검증 기준(Branch Coverage)
분기 검증 기준은 결정 검증 기준이라고도 하며, 문장 검증 기준의 문제점을 해결할 수 있다. 테스트 케이스를 선정하는 기준은 원시 코드에 존재하는 조건문에 대해 T가 되는 경우와 F가 되는 경우가 최소한 한 번은 실행되는 입력 데이터를 테스트 케이스로 사용하는 것이다.
-
원시 코드를 제어 흐름 구조의 그래프 형태로 바꾸어 표현한다.
-
가능한 모든 경로를 구한다
가능한 모든 경로를 나타내고, 분기 검증 기준의 만족 여부를 나타낸다. -
모든 경로 중 분기 검증 기준을 만족하는 경로를 선택한다
하지만 모든 분기를 지나치는 것이 모든 조건을 검사하는 것은 아니다.
이와 같은 문제를 해결하는 방법은 조건문 내의 개별 조건식에 대하여 각각 T와 F인 경우를 최소한 한 번씩 수행할 수 있는 테스트 케이스를 선정하는 것이다.
조건 검증 기준(Condition Coverage)
조건문이 OR인 경우, 첫 조건만 검사하고 뒤의 조건은 넘기게 된다. 뒤의 조건에 오류가 있음을 파악하기 위해 모든 조건을 검사하는 테스트 케이스를 작성하는 방법이다.
분기/조건 검증 기준(Branch/Condition Coverage)
개별 조건식과 전체 조건식을 모두 만족하는 테스트 케이스. 하지만 개별 조건식이 and인경우 마스크 현상으로 뒤의 조건이 씹힌다. 그걸 해결하는 기법이 아래.
다중 조건 검증 기준(Multiple Condition Coverage)
각각의 개별 조건문도 모두 검증하는 기법, and의 경우 둘 다 True, T F, F T의 경우를 준비하여 테스트
or의 경우 TT,FT,FF,TF를 모두 준비하여 테스트하는 것.
기본 경로 테스트(Basic Path Test)
원시 코드의 독립적인 경로가 최소 한번은 실행되는 테스트 케이스를 찾아 수행. 코드의 경로를 흐름도로 만들고 모든 경로를 실행하는 케이스를 만들어 테스트한다. 논리적인 경로는 갈라지며 이제 이게 순환 복잡도를 나타낸다. 순환 복잡도에 따른 테스트 케이스를 만들어 테스트하면 끝
순환 복잡도가 높을수록 테스트케이스가 많이 필요하고 복잡한 프로그램이라고 할 수 있다.
마치며
동적 테스트에 대한 두 가지 분류와 그 안의 다양한 기법들을 알아볼 수 있는 시간이였다.
소프트웨어의 버그는 유저에게 좋지 않은 경험을 제공한다는 생각을 가진 나에게는 이러한 기법의 필요성을 충분히 느끼게 할 수 있었다.
아무런 버그 없는 게임은 존재하지 않는다는 것을 명심하자.
출처 : [네이버 지식백과] 구현 기반 테스트 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 김치수)
