서론
테스트 설계 기법은 테스트 케이스를 도출하고 수행하여 테스트 대상이 어느 수준까지 테스팅되었는지 확인하기 위해 사용된다. 이번 4장의 학습 목표는 "각각의 테스트 기법을 알고 적용하여 테스트 케이스를 도출할 수 있어야 한다."이다. 이를 기억하고 내용을 이해해 보자. 해당 장부터 자격증의 합불을 결정짓는다.
배우기에 앞서 용어 정리
용어를 확실하게 아는 것이 이해에 도움이 된다. ISTQB가 개발자뿐만 아니라 다른 직군도 시험을 충분히 볼 수 있기에 이해하기 쉽게 용어의 정의를 살펴보자.
- 설계 기반 테스팅: 컴포넌트나 시스템의 아키텍처 및 상세 설계를 기반으로 테스트 케이스를 설계하는 테스팅 접근법.
- 블랙박스 테스팅(Black box testing): 테스트를 수행할 때 소프트웨어의 내부 구조나 작동 원리에 대해 사전 지식이 없는 상태에서 테스트 케이스를 설계하고 실행하는 방법론
- 화이트박스 테스팅(White box testing): 테스트를 수행할 때 내부 구조와 동작을 이해하여 테스트 케이스를 설계하는 방법론
- 명세 기반 테스트 설계 기법: 컴포넌트나 시스템의 명세를 빠뜨리지 않고 테스트 케이스에 반영하고자 하는 테스트 설계 기법의 분류(블랙박스)
- 구조 기반 테스트 설계 기법: 컴포넌트나 시스템의 구조, 즉, 코드와 개발 설계 등의 소프트웨어 구현 정보를 중심으로 테스트를 설계하는 기법 분류.(화이트박스)
- 경험 기반 테스트 설계 기법: 테스터 경험, 지식과 직관에 기반하여 테스트 케이스를 도출하고 선정하는 절차
- 테스트 베이시스(Test Basis): 요구사항을 내포하고 있는 모든 문서.
- 커버리지(Coverage): 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도.
- 테스트 프로시저: 소프트웨어 테스트 과정에서 수행해야 할 구체적인 테스트 활동을 단계별로 기술한 문서
- 가드: 함수나 메서드의 초기에 특정 조건을 확인하여, 그 조건이 만족되지 않으면 함수를 빠르게 종료시키는 코드 패턴
- 추적성(traceability): 요구사항과 이와 연관된 테스트에서와 같이 문서나 소프트웨어에서 연관된 항목을 식별하는 능력.
- 동등 분할: 소프트웨어의 입력값을 몇 개의 동등한 그룹으로 나누고, 각 그룹에서 대표값을 선택하여 테스트하는 기법
- 경계값 분석: 경계값에 기반하여 테스트 케이스를 설계하는 블랙박스 테스트 설계 기법
- 상태 전이: 컴포넌트나 시스템의 두 가지 상태 간의 전이
- 상태 전이 테스팅: 유효하고 비유효한 상태 전이를 수행하도록 테스트 케이스를 설계하는 블랙박스 테스트 설계 기법
- 유즈케이스: 사용자와 시스템 사이의 대화에서 가시적인 결과를 트랜잭션의 순서.
- 유즈케이스 테스팅: 사용자 시나리오를 실행하도록 테스트 케이스를 설계하는 블랙박스 테스트 설계 기법
- 페어 파이즈: 모든 가능한 변수 쌍의 조합을 테스트하는 기법
- 오류 추정: 테스트 중인 컴포넌트나 시스템에서 유입된 오류의 결과로 어떤 결함이 발생할 것인지를 테스트의 경험을 사용하여 예측하고, 해당 결함만을 중점적으로 검출하는 테스트를 설계하는 테스트 설계 기법.
- 결점 공격: 의도적으로 결함을 소프트웨어에 주입하여 실제 결함을 찾는 테스트 기법
- 특성 테스팅: 테스터의 경험과 직관을 바탕으로 소프트웨어를 탐색하며 테스트하는 방식
- 기능성: 소프트웨어가 사용자에게 제공하는 기능 및 작업
- 신뢰성: 소프트웨어가 명시된 조건 하에서 사용될 때, 명시적이고 암묵적인 요구를 만족하는 기능을 제공하는 소프트웨어 제품의 능력
- 사용성: 명시된 조건 하에서 사용될 때 사용자에게 이해되고, 학습되고, 사용되고, 사용자에게 매력적일 수 있는 소프트웨어 능력
- 효율성: 정해진 조건하에서 사용하는 자원의 양과 관련하여 적절한 성능을 제공하는 소프트웨어의 능력
- 유지보수성: 소프트웨어 제품이 결함을 정정하고 새로운 요구를 만족시키기 위해 수정될 수 있고, 추후보다 쉬운 유지보수를 위하여 수저오딜 수 있거나 또는 변경된 환경에 적을 할 수 있는 용이성
- 이식성: 소프트웨어 제품이 다른 하드웨어나 소프트웨어 환경으로 전이될 수 있는 용이성
테스트 설계 및 구현 프로세스
테스트 설계 정차는 다양한 방식으로 진행될 수 있는 데 그 절차는 공식적일 수도 있고 비공식적일 수도 있다. 테스트 설계 진행 방식은 테스트 조직 구성, 테스팅과 개발 프로세스의 성숙도, 시간적 제약, 참여 인원 등 테스팅 정황에 따라 달라진다.
테스트 분석 과정에서 무엇을 테스트할지 결정하기 위해, 즉 테스트 조건(Test Condition)을 식별하기 위해 테스트 베이시스를 분석한다. 테스트 조건은 하나 이상의 테스트 케이스로 확인 가능한 항목 또는 이벤트이다. 테스트 조건과 명세 및 요구사항 사이에 추적성(Traceablity)을 유지함으로써, 요구사항이 변경되었을 때의 영향도 분석(Impact analysis)과 테스팅에 의한 요구사항 커버리지를 확인할 수 있게 한다. 또한 테스트 분석 과정에서 식별된 리스크를 기반으로 적절한 테스트 설계 기법을 선정해 테스트 케이스를 구현한다.
테스트 설계 과정에서 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화한다. 테스트 케이스는 입력값의 묶음, 실행 사전 조건, 수행 절차, 기대 결과와 실행 사후 조건으로 구성되며, 특정 테스트 조건을 확인하기 위해 작성한다.
테스트 케이스 구성 요소는 다음과 같다. 이 중 기대 결과는 필수 항목이며 원칙적으로 테스트 실행 전에 반드시 기대결과를 정의해야 한다. 추가적으로 테스트 수행 절차는 7단계 이내로 작성하는 것이 바람직하며 이를 넘을 경우 테스트 케이스를 2개로 분리하여 관리하는 것이 좋다.
- ID(식별 번호)
- 테스트 케이스를 식별하기 위한 번호나 식별자
- 테스트 케이스 명: 테스트 내용을 간단 명료하게 표현함
- 사전 조건
- 테스트 수행에 필요한 사전 조건에 대한 정보(선행 조건)
- 구동환경, 테스트 데이터에 대한 정의 등
- 테스트 수행 절차
- 구체적인 테스트 수행 단계(7단계 이내 권고)
- 기대 결과
- 테스트 실행 후 의도한 대로 동작 했는지를 판단하는 근거
- 실행 사후 사후조건이 필요하면 기대 결과에 포함하거나 별도로 기술함
- 결과(합격/불합격): 테스트 케이스 수행 결과
- Pass: 의도대로 동작함
- Fail: 의도대로 동작하지 않음
- Not Tested: 아직 테스트 수행하지 않음
- Blocked: 사전 조건이 충족되지 않아 테스트가 수행되지 않음. 테스트 결과 확인 불가
- 추적성: 테스트 케이스와 관련된 요구사항 및 적용된 기법 등 기록
- 중요도: 시간적 제약이 있을 경우 테스트 대상을 선택하기 위한 기준. 시간이 부족할 경우에 테스트하지 않을 것만 표시할 수도 있음.
- 비고: 테스트 케이스 작성 의도 등 관련 내용 기술
테스트 설계 및 구현 단계에서 테스트 케이스를 설계하고 작성한 후, 우선순위를 신청하고 배치하여 테스트 프로시저 명세서를 만든다. 테스트 프로시저는 효율적인 테스트를 위한 테스트 케이스 실행 순서이다.
테스트 케이스의 목적은 목표하는 보장성을 만족하는 최소한의 테스트 케이스로 가능한 많은 결함을 발견하는 것이다. 테스트 케이스는 공식적인 기법으로 먼저 작성한 후 반드시 경험기반의 비공식적인 기법으로 보완하는 것이 바람직하다.
소프트웨어 요구사항을 기반으로 구현되었는지 여부에 따라 테스트 전략이 달라지며, 각각의 경우에 결함을 발견하기 위해 수행해야 하는 테스트는 아래와 같다.
요구사항이 명시되어 있으나 구현되지 않은 경우
- 요구사항을 기반으로 테스트 케이스를 작성해 실행해야 한다.
요구사항대로 구현되었으나 때에 따라 정상동작 하지 않는 경우
- 요구사항을 기반으로 테스트 케이스를 작성해 실행하고 추가적인 테스트 케이스를 수행한다.(네거티브 테스트 포함)
요구사항에 명시되어 있지 않지만 구현된 경우
- 요구사항 기반의 테스트로 해당 결함을 발견하기 어려우므로 비공식적인 테스트(탐색적 테스팅을 사용할 수 있음)를 추가적으로 실행하여야 한다.
- 이 경우 결함을 발견하기 위해서는 실제 구현된 부분을 반영하여 요구사항을 변경해야 한다.
요구사항에 명시되어 있지 않지만 구현되었으며, 정상동작 하지 않는 경우
- 요구사항 기반의 테스트로 결함을 발견하기 어려우므로, 비공식적인 테스트(탐색적 테스팅을 사용할 수 있음)를 추가적으로 실행해야 한다.
- 기대 결과를 알기 어려우므로 요구사항을 기반으로 보다 체계적이고 강도 높게 비공식적인 테스트를 설계하고 실행해야 한다.
테스트 설계 기법의 종류
테스트 기법의 목적은 테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을 지원하는 것이다. 테스트 기법의 선택은 다음과 같은 여러 요소를 기반으로 이루어진다.
- 컴포넌트나 시스템의 복잡도
- 규제 기준
- 고객 또는 계약 요구사항
- 리스크 수준과 유형
- 사용 가능한 문서
- 테스터의 지식과 역량
- 사용 가능한 도구
- 시간과 예산
- 소프트웨어 개발 수명주기 모델
- 컴포넌트나 시스템에서 예상되는 결함 유형
일부 기법은 특정 상황과 테스트 레벨에 더 적합한 반면, 모든 테스트 레벨에 적합한 기법도 있다. 테스트 케이스를 작성할 때 테스터는 일반적으로 테스트 노력 대비 가장 좋은 결과를 얻기 위해 다양한 테스트 기법을 조합해서 사용한다.
테스트 분석, 테스트 설계, 테스트 구현 활동에서 테스트 기법의 사용은 매우 비공식적인 형식(거의 또는 전혀 문서화하지 않음)부터 매우 공식적인 형식까지 다양할 수 있다. 적절한 수준의 공식성은 테스트 및 개발 프로세스의 성숙도, 시간적인 제한, 안전 또는 규정 요구사항, 관련된 사람들의 지식과 역량, 준수해야 하는 소프트웨어 개발 수명주기 모델을 포함하는 테스팅의 정황에 따라 결정된다.
테스트 기법의 종류와 특성
테스트 기법을 블랙박스, 화이트박스, 경험 기반으로 분류할 수 있다.
블랙박스 테스트 기법(행위 기법 또는 행위 기반 기법이라고도 함)은 적절한 테스트 베이시스에 대한 분석을 기반으로 한다. 이 기법은 기능 테스팅과 비기능 테스팅 모두에 적용할 수 있다. 블랙박스 기법은 테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중한다.
화이트박스 테스트 기법(구조 기법 또는 구조 기반 기법이라고도 함)은 아키텍처, 세부 설계, 내부 구조, 테스트 대상의 코드에 대한 분석을 기반으로 한다. 블랙박스 기법과는 달리, 화이트박스 기법은 테스트 대상의 내부 구조와 처리에 집중한다.
경험 기반 테스트 기법은 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행한다. 이 기법은 블랙박스 및 화이트박스 테스트 기법과 결합해서 사용하는 경우가 많다.
소프트웨어(시스템) 내부 구조(코드) 참조 여부에 따라 블랙박스 기법과 화이트박스 기법으로 구분하는 방법 이외에 테스트 설계의 근원을 기준으로 명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류할 수 있다.
전통적인 분류
블랙박스 테스트 기법의 일반적인 특징은 다음과 같다.
- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로부터 도출한다.
- 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용한다.
- 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정한다.
화이트박스 테스트 기법의 일반적인 특성은 다음과 같다.
- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍처, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다.
- 커버리지는 선택한 구조 내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준으로 측정한다.
경험 기반 테스트 기법의 일반적인 특징은 다음과 같다.
- 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과 경험과 같은 테스트 베이시스로부터 도출한다.
근원에 의한 분류
명세 기반 기법고 경험 기반 기법을 블랙박스 기법으로 보고, 구조 기반 기법을 화이트박스 기법으로 간주하여도 상관없다.(동일한 것을 의미하는 것은 아님)
명세 기반 기법의 일반적인 특징은 다음과 같다.
- 해결할 문제를 명세하기 위해 공식적이거나 비공식적인 모델을 사용한다.
- 이러한 모델에서 테스트 케이스를 시스템적으로 도출하는 것이 가능하다.
- 커버리지를 측정할 수 있으나 그 의미가 구조 기반 기법의 커버리지에 비해 제한적이다.
구조 기반 기법의 일반적인 특징은 다음과 같다.
- 코드와 개발 설계 등의 소프트웨어 구현 정보를 기반으로 테스트 케이스를 도출한다.
- 수행된 테스트 케이스를 바탕으로 테스트 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 시스템적으로 도출해 추가할 수 있다.
경험 기반 기법의 일반적인 특징은 다음과 같다.
- 테스트 관련 인력의 지식이나 경험으로 테스트 케이스를 도출한다.
- 테스터, 개발자, 사용자의 소프트웨어에 대한 지식
- 소프트웨어에서 자주 발생하는 결함이나 결함 분포등의 지식
기본 설계 기법
블랙박스 테스트 기법
동등 분할
소프트웨어나 시스템이 특정 범위의 입력값에 의해 결과값이 동일하다면 이러한 입력값의 범위를 하나의 그룹(클래스)으로 구분할 수 있다. 그리고 특정 범위 내의 입력값은 내부적으로 같은 방식으로 처리된다고 가장하자. 이 원리를 이용해 입출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대푯값을 선택하여 테스트 케이스를 도출하는 것이 동등 분할(동등 파티션)이다. 유효한 값과 비유효한 값 모두에 대해 동등 분할을 구성할 수 있다.
- 유효값(valid values)이란 컴포넌트나 시스템에 입력되는 값이다. 유효한 값을 포함하는 동등한 파티션을 “유효 동등 분할”이라고 한다.
- 비유효값(invalid values)이란 컴포넌트나 시스템이 거부하는 값이다. 유효하지 않은 값을 포함하는 동등한 파티션을 “비유효 동등 분할”이라고 한다.
- 분할은 입력값, 출력값, 내부값, 시간 관련값, 인터페이스 매개변수를 포함하여 테스트 대상과 관련된 모든 데이터 요소에 대해 식별할 수 있다.
- 필요한 경우 모든 파티션은 하위 파티션으로(sub partitions) 나눌 수 있다.
- 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.
- 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(masked) 즉, 가려지는 것을 방지하기 위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다. 동시에 여러 장애가 발생할 때 겉으로 드러나는 하나의 장애 때문에 나머지가 인식되지 않아 장애가 가려지는 경우가 발생한다.
- 동등 분할은 모든 테스트 레벨, 모든 테스트 유형에서 적용이 가능하다.
동등 분할 기법으로 100% 커버리지를 달성하기 위해서는 식별한 모든 분할(비유효 분할 포함, 모든 등가 집합)의 각 분할에서 최소 한 개의 값을 사용해 테스트 케이스를 작성해야 한다. 동등 분할 커버리지는 일반적으로 백분율로 표기하며, 최소한 한 개의 값으로 테스트한 동등 분할 수를 식별한 모든 동등 분할의 수로 나눠서 계산한다. 동등 분할은 모든 테스트 레벨에 적용할 수 있다.
동등 분할은 대표값을 무엇으로 설정하는지에 따라 두 가지로 나눌 수 있다. 약한 동등 분할은 각 동등 분할 클래스에서 한 개의 대표값만을 선택하여 테스트하는 기법이다. 강한 동등 분할은 각 동등 분할 클래스의 모든 가능한 값을 테스트하는 기이다. 예를 들어 입력값이 1~ 10, 11~21, 21~30 세 개의 동등 분할 클래스로 나누어지는 경우, 약한 동등 분할은 클래스 (1~10: 5), (11~20: 15), (21~30: 25)으로 나눌 수 있다. 반면 강한 동등 분할은 클래스 (1~10: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10), (11~20: 11, 12, 13, 14, 15, 16, 17, 18, 19, 20), (21~30: 21, 22, 23, 24, 25, 26, 27, 28, 29, 30)으로 나누어 테스트한다.
경계값 분석
경계값 분석(BVA)은 동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 예방하기 위해 경계값까지 표함 하여 테스트하는 기법이다. 그러므로 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다. 분할의 최소값과 최대값(또는 첫 번째 값과 마지막값)은 해당 분할의 경계값이 된다.
예를 들어, 특정 입력 필드가 한 자리 정수값만 입력으로 받아들이고 정수가 아닌 값의 입력은 막기 위해 입력 방법을 키패드(keypad)로 제한한다고 가정해보자. 유효 범위는 1 이상 5 이하이다. 따라서 3 개의 동등 분할이 존재한다: 비유효(너무 낮음); 유효; 비유효(너무 높음). 유효 동등 분할의 경계값은 1과 5이다. 비유효(너무 높음) 분할의 경곗값은 6이다. 비유효(너무 낮음) 분할은 변수가 하나뿐인 파티션으로 유일한 값 0 이 경계값이 된다.
위의 예제에서는 각 경계에 대해 두 개의 값을 식별했다. 비유효(너무 낮음)와 유효 사이의 경계에 대해서는 테스트 값 0, 1 을, 유효와 비유효(너무 높음) 사이의 경계에 대해서는 테스트 값 5, 6을 선택했다. 이 기법의 여러 유형 중에는 경계당 세 개의 경계값을 식별하는 것도 있다: 경계 직전 값, 경계에 해당하는 값, 경계 직후의 값. 경계값을 세 개 선택하는 경우로 앞에 주어진 예제를 살펴보면, 낮은 쪽 경계에 해당하는 테스트 값은 0, 1, 2가 되고 높은 쪽 경계에 해당하는 테스트 값은 4, 5, 6 이 된다.
동등 분할의 경계에서 동작이 잘못될 확률이 동등 분할 중간의 값에서 잘못될 확률에 비해 높다. 명시된 경계값과 구현한 경계값 모두 의도했던 값보다 높거나 낮게 설정되거나, 모두 생략하거나 의도하지 않았던 경계값이 추가되었을 수 있다는 사실을 기억하는 것이 중요하다. 경계값 분석과 테스팅을 통해 소프트웨어가 경계값이 원래 속한 분할의 동작이 아닌 다른 분할의 동작을 수행하는 것과 같은 종류의 결함 대부분을 식별할 수 있다.
경계값 분석은 모든 테스트 레벨에 적용할 수 있다. 이 기법은 일반적으로 숫자의 범위(날짜, 시간 포함)와 연관된 요구사항을 테스트하는 데 적용된다. 경계값 분석 커버리지는 보통 백분율로 표기하며, 테스트한 경계값의 수를 식별한 모든 경계값의 수로 나눠서 계산한다. 이로서 경계값 테스트에 결함이 없었다는 것을 보장하게 된다. 또한 경계값 분석 기법은 종종 동등 분할의 확장으로 여겨지며 동등 분할과 동일한 방식으로 커버리지를 보장한다.
동등 분할과 경계값 분석이 사용하기 용이하고 활용도가 높은 기법이기는 하지만 아래와 같은 한계가 존재한다.
- 일련의 동작에 대한 조합 테스트에는 적합하지 않다.
- 입력 법위를 동등 분할하여 제현하더라도 입력값의 조합이 테스트 가능한 수를 넘어서는 경우가 많다.
- 입력 조합이 상호간에 독립적(의존성이 없는)이라는 가정에서만 적합한 기법이다.
- 출력이 입력 조건이나 변수들 사이의 관계에 다라 달라지는 경우, 입력 조건을 동등 분할하는 것이 매우 어려울 수 있다.
결정 테이블 테스팅
결정 테이블은 논리적인 조건이나 상황을 구현하는 시스템에서 요구사항을 도출하거나 내부 시스템 설계를 문서화하는 유용한 도구이다. 결정 테이블을 작성할 때 테스터는 시스템의 조건(주로 입력)과 예상 동작(주로 출력)을 식별한다. 이것들은 테이블의 각 컬럼은 비즈니스 규칙과 대응관계를 갖는다. 테이블의 행(rows)은 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다. 각 열(column)은 하나의 결정 규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의한다. 조건과 기대 결과의 값은 일반적으로 참 또는 거짓으로 표기하거나, 빨간색, 녹색, 파란색 등과 같은 비연속 값으로 표기하지만 숫자나 숫자 범위로 표기하는 경우도 있다. 이러한 여러 가지 유형의 조건과 기대 결과를 하나의 결정 테이블에 표기하는 경우도 있다.
결정 테이블의 일반적인 표기법은 다음과 같다.
조건
- Y: 조건이 참이라는 것을 의미 (T 또는 1로 표기할 수 있음)
- N: 조건이 거짓이라는 것을 의미 (F 또는 0 으로도 표기할 수 있음)
- —: 조건의 값이 중요하지 않다는 것을 의미 (N/A 로 표기할 수 있음)
기대결과
- X: 행동이 일어난다는 것을 의미 (Y, T, 1 로 표기할 수 있음)
- 공백(blank): 행동이 일어나지 않음을 의미 (—, N, F, 0으로 표기할 수 있음)
전체 결정 테이블에는 모든 조건 조합을 포괄 할 수 있는 충분한 열 (테스트 사례)이 있다. 예를 들어, 결과에 영향을 미치지 않는 열, 불가능한 조건 조합 등을 삭제하면 테스트 케이스 수가 상당히 줄어들 수 있다.
결정 테이블 테스팅에서 일반적인 최소 커버리지 기준은 테이블의 결정 규칙당 최소 한 개의 테스트 케이스를 작성하는 것이다. 이것은 일반적으로 모든 조건 조합을 포함한다. 커버리지는 일반적으로 백분율로 표기하며, 최소 한 개의 테스트 케이스로 테스트한 결정 규칙의 수를 식별한 모든 결정 규칙의 수로 나눠서 계산한다.
결정 테이블 테스팅의 장점은 중요한 모든 조건 조합을 식별하는 데 도움이 된다는 것이다. 그중에는 결정 테이블을 사용하지 않았으면 간과했을 수 있는 조합도 있을 수 있다. 또한, 요구사항의 누락된 부분을 찾는 데 도움이 된다. 이는 소프트웨어의 동작이 조건 조합에 영향을 받는 모든 상황에 적용 가능하며, 모든 테스트 레벨에 적용할 수 있다.
| 결정 테이블 장점 | 결정 테이블 단점 |
| 논리적으로 의존적인 가능한 모든 조건들의 조합을 생성함 요구사항 등 테스트 베이시스의 문제점을 발견하는 효과적인 테스트 케이스 생성 테스트 베이시스의 불완전성과 모호함 발견 가능 테스트 케이스를 만들면서 명세의 결함을 발견하는 것이 가능 |
작성에 많은 노력과 시간이 소요 될 수 있음(특히 테스트를 위해 결정 테이블을 만들어야 할 경우 작성 후 개발팀의 검토가 필요함) 복잡한 시스템은 표현하기 어려울 수 있으며 작성 시 논리적 실수 가능성 있음 |
상태 전이 테스팅
컴포넌트나 시스템은 현재 조건이나 기존 이력에 따라 이벤트에 대해 다르게 반응할 수 있다. 기존 이력은 상태라는 개념을 활용해서 요약할 수 있다. 상태 전이 다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여준다. 전이는 이벤트에 의해 시작된다. 이 이벤트는 전이라는 결과를 가져온다. 하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생할 수 있다. 상태 변화로 소프트웨어가 특정 행동을 할 수도 있다.
상태 전이 테스팅을 통해 다음과 같은 방식으로 테스트를 설계하는 것이 가능하다.
- 전형적인 상태의 순서를 커버하는 방식
- 모든 상태를 커버하는 방식
- 모든 상태 전이를 실행하는 방식
- 특정한 상태 전이 순서를 실행하는 방식
- 불가능한 상태 전이를 테스트하는 방식
| 구성요소 | 설명 | 표기법 |
| 상태 | 하나 또는 그 이상의 이벤트를 기다리는 시스템의 모드 | 원으로 표기, 원 안에 상태명 표기 |
| 전이 | 이벤트에 의해 한 가지 상태에서 다른 상태로의 변경 | 화살표 형태의 링크로 표시하며 상태와 상태를 연결함 |
| 이벤트 | 상태 전이를 유발하는 요인 | 화살표에 이름과 값으로 표시 |
| 가드 | 이벤트가 발생하는 조건 | 이벤트 오른편의 [ ]안에 조건이나 값으로 표시 |
| 액션 | 상태의 전이에 따라서 유발되는 동작 | 화살표에 이름과 값을 표시 |
상태 다이어그램으로 시스템을 설계하는 과정에서 도출할 수 있는 결함을 아래와 같이 모델상의 결함과 구현상의 결함으로 분류할 수 있다.
- 모델상의 결함
- 초기상태 누락
- 전이 또는 액션의 누락
- 가드를 전이 대신 상태에 표기함
- 가드의 중복 또는 불일치
- 구현상의 결함
- 여분/누락/훼손 상태
- 액션이 틀리거나 누락됨
- 스니크 패스, 트랩 도어
상태 전이 테스팅은 소프트웨어 요구사항을 다이어그램으로 정확하게 표현했다면 상태 전이 커버리지를 갖는 테스트 케이스를 절차에 따라 기계적으로 누락 없이 도출할 수 있다.
- 상태-이벤트 테이블 구성
- 전이 트리 구성
- 반은 테스트 케이스 구성
- 무반응 테스트 케이스 구성
- 가드 또는 조건 테스트 구성
- 테스트 프로시저 구성
상태 전이 테이블은 상태 간의 모든 유효 전이와 잠재적인 비유효 전이뿐만 아니라, 유효 전이와 관련된 이벤트, 결과 조치를 보여준다. 상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비유효 전이는 표시하지 않는다.
테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나 모든 상태 전이를 실행하거나 특정한 상태 전이 순서를 실행하거나 또는 불가능한 상태 전이를 테스트하도록 설계할 수 있다.
상태 전이 테스팅은 메뉴 기반 애플리케이션에 사용하며, 임베디드 소프트웨어 업계에서 널리 사용하고 있다. 이 기법은 또한 구체적인 상태를 포함한 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는 데 적합하다. 상태의 개념은 추상적이다. 이는 코드 몇 줄 또는 전체 비즈니스 프로세스를 나타낼 수도 있다
커버리지는 일반적으로 백분율로 표기하며, 식별한 상태나 전이 중 테스트된 수를 식별한 모든 상태나 전이의 수로 나눠서 계산한다
유스케이스 테스팅
유스케이스나 비즈니스 시나리오를 기반으로 테스트를 명세화할 수 있다. 이런 유스케이스에서 테스트를 도출할 수 있으며, 이것은 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법이다. 유스케이스는 소프트웨어 기능에 대한 요구사항을 통합한다. 유스케이스는 액터(actor, 즉 사용자, 외부 하드웨어, 기타 컴포넌트나 시스템)와 대상(유스케이스를 적용하는 컴포넌트나 시스템) 간의 관계이다.
유스케이스에는 예외 동작 및 오류 처리를 포함한 기본 동작의 가능한 변형이 포함된다. 테스트는 정의한 동작을 실행하도록 설계된다. 커버리지는 일반적으로 숫자로 표기하며, 테스트한 유스케이스 동작 수를 모든 유스케이스 동작 수로 나눠서 계산한다.
유즈케이스는 시스템이 설제 사용되는 방식에 기반하여 "프로세스 흐름"을 기술한다. 따라서 유즈케이스에 기반하여 생성된 테스트 케이스는 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는 데 유용하다. 특히, 인수 테스트를 설계할 때 유용하다.
화이트박스 테스트 기법
시스템 또는 소프트웨어의 구조가 테스트 스위트에 의해 테스트된 정도를 커버리지라 하며, 특정 구조의 종류에 대해 커버된 백분율로 표시한다. 일반적으로 코드의 구조를 테스트하는 기법은 특정 커버리지를 달성하기 위해 테스트를 설계하고 테스트 케이스를 도출하기 위해 사용된다. 명세기반 테스트 기법과는 달리 코드를 기반으로 한 테스트 기법과 커버리지와의 관계는 어느 정도 명확하다.
코드의 구조가 테스트 스위트에 의해 테스트된 정도를 백분율로 나타내는 커버리지에는 그 강도에 따라 아래와 같이 다양한 장류가 존재하고 보장하는 범위가 모두 다르다. 보장성이 높고 강력한 커버리지는 출시 전에 반드시 100% 결함을 제거해야 하는 리스크가 높은 일부분의 테스트에서 달성해야 하고, 보장성이 낮은 커버리지는 리스크가 낮은 소프트웨어 테스트에 적용한다.
전체조건식은 코드에서 분기하는 결정포인트 전체를 의미한다. 즉 if나 while에 있는 조건문 전체를 칭한다. 개별조건식은 전체조건식에 연산자로 구분되어 있는 개개의 조건식을 의미한다.
- 구문 커버리지(SC): 테스트 스위트에 의해 실행된 구문이 몇 퍼센트인지 측정하는 것으로 다른 커버리지에 비해 가장 약하다.
- 결정커버리지(DC): 테스트 스위트에 의해 실행된 결정 포인트 내의 전체조건식이 최소한 참이 한 번 그리고 거짓이 한 번씩 선택되었는지 측정하여 퍼센트로 표현하는 것이다. 개별 조건식의 개수와 관계없이 테스트 최소 개수는 2개로 도출되면 조건, 조건/결정 커버리지에 비해 약하다.
| DPoint | A | B |
| 0 | 1 | 0 |
| 1 | 1 | 1 |
- 조건 커버리지(CC): 전체조건식의 결과와 관계없이 각 개별조건식이 참 한번, 거짓 한번을 모두 갖도록 개별조건식을 조합하는 것으로 결정 커버리지 보다 강력한 형태의 커버리지이다.
| DPoint | A | B |
| 0 | 1 | 0 |
| 0 | 0 | 1 |
- 조건/결정 커버리지(C/DC): 전체 조건식의 결과가 참 한번, 거짓 한번을 갖도록 각 개별조건식을 조합하는 데, 이때 각 개별 조건식도 참과 거짓을 한 번씩 모두 갖도록 조합하는 것으로 결정 커버리지와 조건 커버리지를 포함하는 커버리지이다.
| DPoint | A | B |
| 0 | 0 | 0 |
| 1 | 1 | 1 |
- 변경 조건/결정 커버리지(MC/DC): 각 개별조건식이 다른 개별조건식에 무관하게 전체조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 것으로 결정 커버리지, 조건/결정 커버리지보다 강력하다.
| DPoint | A | B |
| 0 | 1 | 0 |
| 0 | 0 | 1 |
| 1 | 1 | 1 |
- 다중 조건 커버리지(MCC): 결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 조합을 고려하여 100% 커버리지를 보장한다.
| DPoint | A | B |
| 1 | 1 | 1 |
| 0 | 1 | 0 |
| 0 | 0 | 1 |
| 0 | 0 | 0 |
다중 조건> 변형 조건/결정 > 조건/결정 > 조건 > 결정 > 구문
| 커버리지 분류 | SC | DC | CC | C/DC | MC/DC | MCC |
| 프로그램 내에 있는 모든 구문을 적어도 한 번 수행 | O | O | O | O | O | O |
| 프로그램 내에 있는 모든 결정 포인트에 대해 모든 가능한 결과를 적어도 한 번 수행 | O | O | O | O | ||
| 프로그램 내에 있는 결정 포인트 내의 모든 개별조건식에 대한 가능한 결과에 대해 적어도 한번 수행 | O | O | O | O | ||
| 결정 포인트내에 있는 모든 개별 조건식은 독립적으로 전체조건식(판단문)의 겨로가에 영향을 줌. 즉, 결정포인트내의 다른 개별조건식의 결과와는 독립적으로 해당 개별조건식은 전체조건식의 결과에 영향을 줌 | O | O | ||||
| 결정 포인트 내의 개별조건식 결과에 대한 모든 가능한 조합을 적어도 한번 수행 | O | |||||
| 포함 관계 |
구문 테스팅과 커버리지
구문 테스팅은 코드의 잠재적으로 실행 가능한 구문을 실행한다. 커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행한 구문의 수를 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산한다.
결정 테스팅과 커버리지
결정 테스팅은 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다. 이것을 달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다. 예를 들어, IF 문에서 결과가 참인 경우와 거짓인 경우, CASE 문에서 기본 결과를 포함한 가능한 모든 결과를 필요로 하는 테스트 케이스 등이 있다.
커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행된 결정문 결과의 수를 테스트 대상의 가능한 모든 결정문 결과의 수로 나눠서 계산한다
구문 및 결정 테스팅의 가치
100% 구문 커버리지를 달성하면 코드에 존재하는 모든 실행 가능한 구문을 최소한 한 번씩은 테스트했다는 것을 의미하지만, 모든 결정 로직을 테스트했다는 것을 보장하지는 않는다. 구문 테스팅은 결정 테스팅보다 커버리지가 낮다.
100% 결정 커버리지를 달성하면 명확한 거짓 구문이 명시되지 않은 경우에도 결과가 참인 경우와 거짓인 경우를 포함한 모든 결정 결과가 실행되었다는 것을 의미한다. 구문 커버리지는 다른 테스트에 의해 실행되지 않은 코드의 결함을 찾는 데 도움이 된다. 결정 커버리지는 다른 테스트가 참과 거짓 결과 모두를 테스트하지 않은 코드의 결함을 찾는 데 도움이 된다. 100% 결정 커버리지는 100% 구문 커버리지를 보장하지만, 반대의 경우는 성립하지 않는다.
경험 기반 테스트 기법
경험 기반 테스트 기법을 적용할 경우 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한 애플리케이션과 기술에 대한 경험을 기반으로 도출한다. 이 기법은 체계적인 다른 기법으로는 쉽게 찾아내기 어려운 테스트를 식별하는 데 도움이 된다. 테스터의 접근 방식과 경험에 따라 이 기법으로 달성하는 커버리지와 효과성은 매우 다양하게 나타날 수 있다. 이 기법을 사용할 경우 커버리지를 평가하기 어려울 수 있으며 측정이 불가능할 수도 있다.
오류 추정
오류 추정은 다음을 포함한 테스터의 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는 기술이며 다음을 포함한다.
- 애플리케이션의 과거 동작
- 발생하기 쉬운 오류의 유형
- 다른 애플리케이션에서 발생한 장애
오류 추정 기법에 대한 체계적인 접근법은 발생 가능한 오류, 결함, 장애 목록을 작성하고 이런 장애와 그것의 원인이 되는 결함을 노출하는 테스트를 설계하는 것이다. 이러한 오류, 결함, 장애 목록은 경험, 결함 및 장애 데이터 또는 소프트웨어가 실패한 이유에 대한 일반적인 지식을 기반으로 작성할 수 있다.
탐색적 테스팅
탐색적 테스팅에서는 비공식 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가한다. 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한 테스트를 작성하는 데 활용된다. 탐색적 테스팅에서는 테스트 케이스를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 것과 동시에 테스트를 설계하고 테스트를 계획한다. 그렇기에 탐색적 테스팅은 테스트 케이스 기반의 공식적 테스팅과 반대되는 개념의 "테스팅 접근법"이다.
탐색적 테스팅은 아래와 같은 내용을 포함한다.
- 제품 탐색
- 테스트 설계
- 테스트 실행
- 직관
- 검토 가능한 결과물
탐색적 테스팅의 절차는 아래와 같다.
- 제품의 목적 식별
- 기능 식별
- 잠재적으로 불안정한 부분 식별
- 각각의 기능 테스트 및 문제점 기록
- 일관성 검증 테스트 설계 및 기록
그렇다고 탐색적 테스팅에서 테스트 산출물이 전혀 없는 것은 아니다. 테스팅의 한 세션이 종료된 후에는, 팀원끼리 요약 보고하는 시간을 갖는다. 이때 테스트 노트에 포함되어야 할 내용은 다음과 같다.
- 테스트한 제품에 대한 노트 및 기록
- 발견한 결함과 장애에 대한 노트 및 기록
- 어떻게 테스트하였는지를 기술하는 요약된 문서
탐색적 테스팅은 때로 세션 기반 테스팅을 사용하여 활동을 구성한다. 세션 기반 테스팅에서는 탐색적 테스팅을 정해진 시한(time-box)동안 수행하며, 테스터는 테스트 목적이 포함된 테스트 차터(test charter)를 활용해 테스팅 방향을 설정한다. 테스터는 테스트 세션 시트에 수행 단계와 발견 사항을 기록한다.
탐색적 테스팅은 에브혹 테스팅, 게릴라 테스팅, 직관적 테스팅과 유사한 개념의 테스팅이지만, 정해진 임무와 목표, 결과물이 존재한다는 측면에서 다르다.
탐색적 테스팅은 명세가 충분하지 않거나 적은 경우 또는 테스팅에 상당한 시간적 압박이 있을 때 가장 유용하다. 또한, 탐색적 테스팅은 다른 보다 공식적인 테스팅 기법을 보완하는 데도 유용하다. 테스트 케이스를 문서화하는 데 소요되는 시간을 최소화하여 테스트를 "실행"하는 것에 집중한다.
탐색적 테스팅은 아래와 같은 내용을 포함한다.
- 제품 탐색
- 테스트 설계
- 테스트 실행
- 직관
- 검토 가능한 결과물
탐새적 테스팅에서 제안하는 테스트 절차는 아래와 같다.
- 제품의 목적 식별
- 기능 식별
- 잠재적으로 불안정한 부분 식별
- 각각의 기능 테스트 및 문제점 기록
- 일관성 검증 테스트 설계 및 기록
탐색적 테스팅을 성공적으로 수행하게 되면 다음과 같은 효과(장점)를 볼 수 있다.
- 경험적 테스팅을 체계화 시킬 수 있다.
- 테스트 케이스를 작성하는 시간을 줄여 보다 많은 테스트를 실행할 수 있다.
- 테스터 또는 테스트 엔지니어의 연량을 월등히 향상시킬 수 있다.
- 적은 테스트 인력으로 많은 테스트를 수행할 수 있다.
- 명세가 거의 없고 시간이 부족한 경우 테스트를 효과적/효율적으로 수행할 수 있다.
탐색적 테스팅은 반응적 테스트 전략과 밀접하게 관련되어 있다. 탐색적 테스팅은 다른 블랙박스, 화이트박스, 경험 기반 기법과 통합하여 사용할 수도 있다.
| 테스트 케이스 기반 테스팅 | 탐색적 테스팅 |
| 테스트가 먼저 설계되고 기록된다. 나중에 다른 테스터가 이를 수행한다. |
테스트가 설계됨과 동시에 수행된다. 테스트가 반드시 기록되어야 하는 것은 아니다. |
| 준비된 연설을하는 것과 같다. 테스트는 미리 착안된 생각에 따라 수행한다. |
대화를 하는 것과 같다. 테스트는 아이디어를 반영하고, 생각을 발전시키는 방향으로 수행한다. |
| 테스트의 실행을 관리하는 것이다.(Controlling test execution) | 테스트 설계를 향상 시키는 것이다.(Improving test design) |
| 테스트 실행을 시작하기 전에 테스트 케이스를 작성한다. | 프로젝트 기간 내내 테스트 계획/설계와 실행을 반복한다. |
| 테스트 문서 작성, 검토에 많은 에너지를 소비함으로써 테스트의 효율성이 감소하는 경우가 있다. | 테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복잡한 테스트에 상대적으로 많은 노력 투자가 가능하다. |
| 테스터 간의 (특성, 능력) 차이를 제거하려는 노력 | 테스터 간의 (특성, 능력) 차이를 십분 활용하는 노력 |
| 테스터가 아닐 수 있는 테스트 설계자가 테스트를 설계한다. | 테스트 설계작일 수 있는 테스터가 테스트를 설계한다. |
| 완벽하게 한번에 테스팅을 수행한다. | 점진적으로 주기적으로 테스팅을 수행한다. |
체크리스트 기반 테스팅
체크리스트 기반 테스팅에서는 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있지만, 기존 체크리스트를 수정하지 않고 그대로 사용하는 경우도 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다.
체크리스트는 기능 및 비기능 테스팅을 포함한 다양한 테스트 유형을 지원하기 위해 작성할 수 있다. 구체적인 테스트 케이스가 없는 경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다. 이런 체크리스트는 상위 수준으로 작성되기 때문에 실제 테스팅에서 어느 정도의 가변성이 있기 마련이며, 따라서 커버리지는 늘어날 수 있지만 재현 가능성은 줄어들 수 있다.
고급 설계 기법
명세 기반 기법
명세 기반 기법은 주어진 명세를 바탕으로 테스트 케이스를 도출하는 것을 의미하며, 해당 테스트 케이스를 실행해 중대한 결함이 없음을 보장한다. 명세 기반 기법 적용 시 고려해야 할 사항이다.
- 시스템이 상태 다이어그램, 유즈케이스 등의 모델로 표현되어 있지 않을 경우, 명세 기반 기법을 적용하기 위해서는 테스트 전문가가 요구사항 분석서와 설계(기준)서를 먼저 작성한 후 테스트 케이스를 작성하는 것을 고려해야 한다.
- 조기 테스트 설계에 활용한다. 동작하는 소프트웨어가 없어도 명세만 있다면 명세 기반 기법으로 테스트 케이스를 도출할 수 있다. 이는 개발 초기에 테스팅이 진행될 수 있다는 것을 의미하며 테스트 케이스를 도출하는 과정에서 개발자/분석가/아키텍트가 발견하기 어려운 결함을 효과적으로 발견할 수 있다.
명세 기반 기법으로는 상태 전이 커버리지, 상태 경로 커버리지, 유즈케이스, 결정 테이블 테스팅 등이 있다. 또한, UML로도 많이 표현한다.
분류 트리 기법
분류 트리 기법은 소프트웨어 일부 도는 전체를 트리 구조로 분석 및 표현하고 이를 바탕으로 테스트 케이스를 도출하는 기법이다. 분류 트리 기법의 장점은 다음과 같다.
- 테스트 아이디어를 트리 구조로 시각화하여 테스트 케이스를 설계하므로 의도한대로 테스트 케이스를 도출할 수 있다.
- 시각적으로 보면서 트리 구조 끝단의 조합을 통해 테스트 케이스를 작성하므로 일부분만 테스트를 진행한다거나 중복된 테스트 수행을 피할 수 있다.
- 복잡한 시스템 혹은 어플리케이션의 일부 또는 전체를 테스팅하는 데 적합하다.
- 개발 설계를 체크하는 용도로 사용이 가능하여, 조기 테스트 설계에 활용할 수 있다.
- 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능하다.
파라미터와 값을 알 수 있는 경우에는 페어와이즈 또는 직교 배열 조합 테스팅 기법을 적용할 수 있다. 또한, 일정 수준의 보장성을 확보하고 싶다면 해당 테스트 대상 부분에 페어와이즈 또는 직교 배열 조합 테스팅 기법을 사용하면 된다.
페어와이즈 조합 테스팅
페어와이즈 조합 테스팅은 커버해야할 기능적 범위에 비해 상대적으로 적은 량의 테스트 세트를 구성하여 소프트웨어의 결함을 찾고 테스트에 대한 자신감을 얻을 수 있는 방법 중의 한가지이다. 페어와이즈는 관찰 결과 대부분의 결함이 2개 요소의 상호작용에 기인한다는 것에 착안하여 2개 요소의 모든 조합을 다룬다. 즉, 페어와이즈 조합의 의미는 테스트를 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한번씩은 조합을 이루게 된다.
하지만, 페어와이즈 조합 테스팅은 모든 조합을 고려해 테스팅했을 때 발견할 수 있는 결함을 모두 발견할 수 있는 것은 아니다. 그러나 페어와이즈 조합 테스팅 기법을 사용하여 테스팅한 결과에 결함이 없었다는 것까지는 보장성을 제공해준다. 그리고 경험적으로 의미 있고 결함을 발견할 가능성이 높다고 판단되는 조합을 추가하여 관리 가능한 선에서 조합을 늘리는 것은 조합 테스팅의 효과성을 높이는 데 도움이 된다. 물론, 늘어난 조합을 포함하여 도출한 테스트 케이스가 보장하는 범위는 페어와이즈 조합 테스팅 기법이 보장하는 범위까지이다.
만약 파라미터가 많아지고 경로나 종류가 다양해질 수록 수많은 조합이 생겨난다. 그러면 테스트에 엄청난 시간과 비용이 소요될 것이다. 이런 경우, 합리적으로 일정 수준의 보장성을 확보하면서 조합의 수를 줄여 주어야 한다.
직교 배열 테스팅
직교 배열 테스팅은 페어와이즈 조합 테스팅과 유사한 테스팅 기법이며, 차이점은 직교 배열의 행과 열이 페어와이즈하다는 것이다. 각 행과 열이 페어와즈하드는 것은 어느 행의 조합도 서로 다른 행의 조합과 서로 다르고, 어느 열의 조합도 서로 다른 열의 조합과 서로 다르다는 것을 의미한다. 그리고 직교 배열은 각 행 및 열에 선택 가능한 입력값들이 반드시 한번 이상은 들어가게 되어있다. 이로 인해 조합의 수를 줄임으로써 테스트 케이스의 수를 합리적으로 줄일 수 있다.
구조 기반 기법
구조 기반(화이트박스) 테스팅은 아래 예시와 같이 소프트웨어나 시스템의 구조를 중심으로 테스팅하는 것이다.
- 컴포넌트 레벨의 구조는 구문, 결정 또는 분기점 등 코드 그 자체이다.
- 통합 레벨의 구조는 한 모듈이 다른 모듈을 호출하는 관계를 도식화한 콜 트리 등이다.
- 시스템 레벨의 구조는 메뉴 구조, 비즈니스 프로세스 혹은 웹 페이즈 구조 등이다.
구조 기반 기법으로는 구문 테스팅과 커버리지,결정 테스팅과 커버리지, 조건 테스팅과 커버리지, 변형 조건/결정 커버리지 등이 있다.
분할 방법으로 접근한 결정 커버리지
분할이란 논리적 테스트 칼럼의 각각을 선택한 커버리지로 생성한 모든 논리적 조합으로 분할하여 테스트 케이스를 작성하는 방식이다. 모든 조합을 분할해서 나열하기 때문에 결함 원인은 매우 빨리 발견될 수 있지만 테스트 케이스 수가 크게 증가한다.
포함이란 논리적 테스트 칼럼의 각각을 선택한 커버리지로 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 테스트 케이스로 작성하는 1:1 전환 방식이다. 따라서 하나의 테스트 케이스에서 개별조건식은 다른 결정 포인트의 결과값과 독립적으로 확인할 수 없으므로 결함의 원인을 항상 즉각적으로 판단하기 어렵지만 어느 정도 커버리지를 만족하면서 테스트 케이스 수를 줄일 수 있는 방법이다.
테스트 기법 선택
어떤 테스트 기법을 사용할지 결정하는데 고려해야할 사항은 아래와 같다.
- 시스템 유형 및 특징
- 강제적 표준 또는 법적 기준 적용 여부
- 고객 또는 제약상의 요구사항
- 리스크 수준
- 리스크 유형
- 테스트 목표
- 문서의 존재 유무
- 테스터의 지식수준
- 시간과 예산
- 테스트 레벨
- 개발 수명 주기
- 유즈케이스, 상태 다이어그램 등 개발 설계 모델 존재 유무
- 발견된 결함 유형 등 이전의 경험
일반적으로 여러 가지 테스트 기법을 동시에 복합적으로 선택해 사용한다. 몇몇 특정 기법은 특정 상황과 테스트 레벨에 더 적합할 수 있으나, 대부분의 기법은 모든 테스트 레벨에 적용할 수 있다.
소프트웨어 특성에 따른 테스팅
품질 특성을 기준으로 테스트 케이스를 도출하는 것도 유용하게 테스트를 설계할 수 있는 방법 중 하나이다. 이러한 테스팅 방법을 여기서는 특성 테스팅이라고 한다. 특성 테스팅은 테스트 접근법 중 하나인 방법론적 접근법에 속한다. 특성 테스팅으로 테스트 케이스를 도출하는 방법은 아래와 같다.
- 각 품질 특성을 평가항목으로 보고 테스트 대상에 대한 평가항목의 비율을 선정한다.
- 각 품질 특성별로 테스트 대상의 특징 및 경험을 고려하여 테스트 케이스를 도출한다.
특성 테스팅은 기능 테스팅도 포함하지만 기능 이외의 비기능 테스팅도 포함한다. ISO/IEC 9126에서 품질 특성에는 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등이 있다. 각각의 품질 부특성은 일명 메트릭(Metrics)으로 불리는 측정 요소들로 구성되어 있는데, 메트릭을 활용해 테스트 케이스 도출에 도움을 받을 수 있다. 그리고 메트릭을 이용해 테스트 결과(리포트)를 수치화할 수 있다.
기능성
기능성은 요구되는 기능 및 성능을 만족시키는 능력을 의미한다. 기능성에 해당하는 품질 부특성은 다음과 같다.
- 적합성: 사용자 요구 기능을 제공하는 능력
- 정확성: 올바른 또는 정확한 결과를 제공하는 능력
- 상호운영성: 다른 시스템과의 상호 작동 능력
- 보안성: 정보 및 데이터를 보호하는 능력
- 준수성: 기능성 관련 표준, 규정, 관례 등을 따르는 능력
신뢰성
신뢰성은 규정된 시스템 환경에서 결함 없이 의도한 기능 및 작업을 수행하는 소프트웨어의 능력으로 정의된다. 신뢰성에 해당하는 품질 부특성은 아래와 같다.
- 성숙성: 사용자의 오류를 피하는 능력
- 오류 허용성: 내재된 결함으로부터 성능을 유지하는 능력
- 회복성: 장애발생 시 기능 및 데이터를 복구하는 능력
- 준수성: 신뢰성 관련 표준, 규정, 관례 등에 따르는 능력
다음은 신뢰성 테스트 조건의 일반적인 사례이다.
- 사용자가 로그인 화면에서 암호 입력란 20자 이상을 입력하면, 더 이상 입력되지 않으며 소리로 경고음을 출력한다.
- 화상 대화 기능이 동작하지 않아도 화상 대화 기능 외 다른 기능 또는 시스템에 영향을 주지 않아야 한다.
- 클라이언트/서버 제품인 경우, 네트워크를 차단했거나 시스템 전원이 단절되었을 때, 해당 상황을 감지하고 실행 중이었던 메신저 프로그램이 자동으로 로그아웃 되어야 한다.
사용성
사용성은 사용자가 이해하고 배우기 쉬운 정도를 말한다. 사용성에 해당하는 품질 부특성은 아래와 같다.
- 이해성: 사용자가 운용 방법이나 조건 등을 쉽게 파악하게 하는 능력
- 학습성: 소프트웨어 운용법을 쉽게 배울 수 있게 하는 능력
- 운용성: 소프트웨어를 쉽게 운영하고 제어할 수 있게 하는 능력
- 친밀성: 사용자에게 호감을 주는 능력
- 준수성: 사용성 관련 표준, 규정, 관례 등을 따르는 능력
다음은 사용성 테스트 조건의 일반적인 사례이다.
- MS 윈도우용으로 작성된 제품일 경우 글꼴이 윈도우 기본 글꼴인 [굴림, 9]가 기본 설정되어 있어야 한다.
- 대중화된 다른 메신저와 대화창의 구조가 비슷해야 하며 사용자가 적응하기 어려운 구조를 피해야 한다.
- 광고를 제외한 전체 윈도우 및 메시지 창은 원색을 피하고 전체 색감을 통일해야 한다.
효율성
효유성은 자원의 적절한 사용 및 적정한 반응시간 정도를 말한다. 효율성에 해당하는 품질 부특성은 아래와 같다.
- 시간효율성: 기능 수행 시 적절한 응답시간, 처리시간, 처리율을 제공하는 능력
- 자원효율성: 기능 수행시 적절히 자원을 사용하는 능력
- 준수성: 효율성 관련 표준, 규정, 관례 등을 따르는 능력
다음은 효율성 테스트 조건의 일반적인 사례이다.
- 각 사용자가 설정한 대화 상대자가 저장된 대량의 데이터베이시스에서 해당 목록을 검색하여 3초 이내에 메인 화면 창에 표시하여야 한다.
- 메신저에 접속하는 동시 사용자 1만 명을 처리할 수 있어야 한다.
유지보수성
유지보수성은 소프트웨어의 수정 및 변경의 용이성을 말한다. 유지보수성에 해당하는 품질 부특성은 아래와 같다.
- 분석성: 장애 원인을 진단할 수 있게 하는 능력(로그 생성 및 확인)
- 변경성: 변경 요청 사항을 쉽게 구현할 수 있게 하는 능력
- 안정성: 변경에 따른 예상 밖의 결과를 최소화하는 능력
- 시험성: 변경된 결과를 검증할 수 있게 하는 능력
- 준수성: 유지보수성 관련 표준, 규정, 관례 등을 따르는 능력
다음은 유지보수성 테스트 조건의 일반적인 사례이다.
- 제품이 패치될 경우 또는 버전 업 되었을 때 사용자의 개입 없이 자동으로 업데이트되어야 한다.
- 메신저 서버에 장애가 발생했을 때, 알람 기능이 동작해야 하고 문제 발생 상황이 로그 파일에 기록되어 있어야 한다.
- 메신저 서버에서 실행 중인 시스템이 교체되거나 증설되어, 시스템의 이름 또는 IP가 변경되거나 추가되었을 때, 제품이 정상적으로 동작하는지 확인한다. 이러한 변경이 가해진 후 사용자가 추가적인 작업을 어디까지 해야 하는지에 대한 기준이 있어야 한다.
이식성
이식성은 지원하는 다양한 운영환경에서 운영될 수 있는 소프트웨어의 능력이다. 이식성에 해당하는 품질 부특성은 아래와 같다.
- 적응성: 최소한의 조치만으로 이식될 수 있는 능력
- 설치성: 사용자가 지정한 환경으로 설치될 수 있는 능력
- 대체성: 공동 운영환경에서 다른 소프트웨어를 대체할 수 있는 능력
- 공존성: 동일 환경에서 다른 소프트웨어와 충돌 없이 구동할 수 있는 능력
- 준수성: 이식성 관련 표준, 규정, 관례 등을 따르는 능력
다음은 이식성 테스트 조건의 일반적인 사례이다.
- 메신저는 윈도우 95 이상에서 설치되어 작동된다. 단, 윈도우 95/98에서 실행 시 MS 라이브러리의 버전이 "C:\windows\system\oleaut32.dll"최신 버전으로 대치되어야 한다.
- MSN 메신저, 네이트온 및 다른 메신저 프로그램과 충돌 없이 실행되어야 한다.
- 영문 윈도우에서 영문 버전이 설치되어 정상적으로 실행되어야 한다.
주섬주섬
공부 정리를 위한 블로그이며, "개발자도 알아야 할 소프트웨어 테스팅 실무 제3판"과 실라버스를 참고하였다.
참고
STEN
www.sten.or.kr
'IT 진로 > 자격증' 카테고리의 다른 글
| STQB_CTFL 6. 테스트 지원 도구 (1) | 2024.05.17 |
|---|---|
| STQB_CTFL 5. 테스트 관리 (0) | 2024.05.16 |
| STQB_CTFL 3. 정적 테스팅 (0) | 2024.05.12 |
| ISTQB_CTFL 2. 소프트웨어 개발 수명주기와 테스팅 (0) | 2024.05.11 |
| ISTQB_CTFL 1. 소프트웨어 테스팅의 기초 (0) | 2024.05.10 |
댓글