테스트 설계에 대해 기재해봅니다.
3. Test Design - 테스트 설계
분석한 내용을 바탕으로, 요건이나 조건을 만족시키는 테스트케이스를 검토해나가는 것이 테스트 설계 프로세스입니다. 이 테스트 설계 단계에서는 꼭 기획서에 기재되어있는 내용, 혹은 예상되는 User-story뿐만 아니라 비정상 패턴 등도 고려해나가며 테스트 케이스를 작성해야합니다.
| 카테고리 | 패턴 | 테스트 조건 |
|---|---|---|
| 입력값 input | 영어 | 영어를 입력해보기 |
| 숫자 | 숫자를 입력해보기 | |
| 특수기호 | 특수기호를 입력해보기 |
위와 같은 내용이 있다면, 영어와 숫자를 같이 조합한다던지, 영/숫/특수기호를 섞는다던지 의 패턴등도 고려되야한다는 것입니다.
여기에서는 테스트 설계시 몇가지 관점에 대해 소개합니다.
테스트 설계시의 관점
테스트 대상을 망라할 것.
무엇을 기준으로 망라하는 것인지는, 테스트 기법에 따라 다시 달라집니다. (사양 기반 / 구조 기반 / 경험 기반)
좀 더 적은 테스트 케이스로 할 수 있는지 확인할 것.
테스트 조건을 모두 망라하는 것은 정말 필요합니다. 그러나 모든 조건들을 전부 망라하여 확인한다는 것은 시간적, 리소스적으로 어려움이 있습니다.
때문에 망라한 테스트 케이스들 중에서 취사선택을 하고, 특정 테스트케이스를 확인하면, 다른 테스트케이스도 확인된다는 논리적 판단을 해야합니다.
좀 더 많은 결함(Bug)를 찾아낼 수 있는 테스트를 할 수 있는지 확인할 것.
다만, 적은 테스트 케이스라 할지라도, 좀 더 많은 결함을 도출해낼 수 있는 패턴도 분명 존재합니다. 테스트케이스를 과감하게 줄인다고는 하여도, 그러한 특이 패턴은 포함하도록 합니다.
프로덕트/서비스를 사용하는 유저들은 무슨 짓을 할 지 아무도 모릅니다.
테스트 순서, 우선순위를 확인할 것.
테스트를 진행하는 순서에 따라, 특정 케이스는 확인할 수 없게 되어버린다던지 등의 문제가 발생할 수 있습니다. (테스트로 인하여 생긴 데이터의 영향 등.)
혹은 특정 테스트는 다른 테스트의 의존적인 관계 등의 많은 변수가 있을 수 있습니다. 테스트 설계 시에 이러한 순서와 우선순위 등에 대해서도 확인해야합니다.
테스트 기법
테스트 설계시에는 어떻게 테스트할 것인지에 대한 방법의 선택도 중요합니다. 테스트를 실시하는 테스트 단계(혹은 테스트 레벨)에 따라 어느정도 정해진 기법들이 있습니다.
명세 기반 테스트 (Specification-based Test)
보통 Blackbox test라고도 하는, 기획서나 User-story, Use-case등을 기반으로 진행하는 테스트입니다.
| 테스트 방법 | 설명 |
|---|---|
| 동치분할법 | 입력값 입력조건에 대해 Grouping |
| 경계분할법 | 입력값과 경계값을 중심으로 확인 |
| 결정표(Decision Table) | 여러 조건의 조합의 상호작용을 결정표로 정리하여 망라 |
| 원인 분석 그래프 | 사양의 논리구조를 원인결과 그래프로 정리하여 망라 |
| 상태전이 | 프로덕트의 상태를 Sequence diagram등으로 표시하고, 그것을 망라 |
| All-pair | 특정 방법으로 2개의 파라미터간의 조합을 전부 망라 |
| 직교표 | 직교표를 사용하여 2개의 파라미터를 전부 망라 |
| n-wise | 특정 방법으로 임의의 n개의 파라미터간의 조합을 전부 망라 |
| 도메인 분석 | 관계성이 있는 여러개의 입력값들을 동시에 테스트를 진행하여, 각각의 입력값들의 조건 판정을 망라 |
| Classification Tree | 조건 들을 일종의 Tree로 그려 망라 (약간 마인드맵과 비슷) |
| Use-case | 유스케이스를 토대로 테스트케이스를 망라 |
뭐 모든 방법을 사용하는 것은 아니고... 동치분할, 경계분할, 결정표, All-pair, Use-case 정도는 흔하게 사용되는 방법일 것 같습니다.
구조 기반 테스트 (Structure-based Test)
보통 Whitebox test라고도 하는, 실제 구동되는 source code를 기반으로 하는 테스트 방법입니다. Unit test단계에서 실행되는 대부분의 테스트들이 이에 해당됩니다.
| 테스트 방법 | 설명 |
|---|---|
| Control flow test | 처리 흐름을 어떠한 flow로 정리하고, 그것을 망라합니다. 조건분기, 조건판정 등도 포함됩니다. (흔히말하는 if statement) |
| Data flow test | 어떠한 입력값이 흘러가는 데이터의 흐름을 망라합니다. |
경험 기반 테스트 (Experience-based Test)
테스트 담당자의 지식이나 경험을 토대로 테스트케이스를 도출해내는 방법입니다.
| 테스트 방법 | 설명 |
|---|---|
| 결함 추측 | 왠지 테스트해보면 결함이 있을 것 같은 곳을 중심으로 테스트합니다. 대부분의 결함은 특정 모듈에 집중되어 있는 경우가 많습니다. |
| 체크리스트 | 테스트의 목적에 따라 작성한 체크리스트를 기반으로 각 항목별로 체크를 진행합니다 |
| 탐색적 테스트(Exploratory Testing) | 이전 테스트들로부터 얻은 지식이나 경험을 바탕으로 테스트를 실시해나가며 테스트케이스를 작성해나갑니다. |
그 외..
위 열거한 방법들 외에도, 예상 결과를 사전에 정의하지않고, 테스트 준비작업 없이 자유롭게 조작해나가며 테스트를 하는 ad-hoc test 나 두 명 이상이 하나의 팀이 되어 서로 논의해나가며 테스트를 하는 Pair test 등이 있습니다.
이 단계 테스트 설계가 큰 문제없이 진행된다면, 바로 테스트 구현까지 진행합니다.
또한 테스트 구현 및 테스트 실행시에 걸릴 일정도 이 단계에서 도출해낼 수 있을 것 입니다.
Ref
