[CSTS] 동적 테스트 기법 정리: 명세 기반, 구조 기반, 경험 기반

 

 

동적 테스트 (Dynamic Testing)

• 소프트웨어를 실행하여 테스트를 수행하여 결함을 검출하는 것

명세기반 테스트

• 블랙박스 테스트라고도 불림
• 내부 논리 구조를 참조하지 않고 사용자의 요구사항이 기술된 명세나 설계 정보 등을 이용하여 테스트케이스를 개발함.
• 대상 시스템의 명세 정보를 얻을 수 있는 한 대상에 제한이 없음. 컴포넌트 테스트, 통합 테스트, 시스템 테스트 및 인수 테스트 등 전 과정에 걸쳐 사용 가능함.
• 주요 기법:
  • 동등 분할 (Equivalence Partitioning): 입력 데이터를 클래스별로 나눠 테스트하는 기법.
  • 분류 트리 기법 (Classification Tree Method): 시스템의 입력 조건을 계층 구조로 나누어 테스트.
  • 경곗값 분석 (Boundary Value Analysis): 경곗값을 중심으로 테스트하는 기법.
  • 신텍스 테스트 (Syntax Testing): 입력 데이터의 문법 구조를 테스트하는 기법.
  • 조합 테스트 (Combinatorial Testing): 다양한 입력 조합을 테스트하는 기법.
  • 상태 전이 테스트 (State Transition Testing): 상태 변화와 그에 따른 출력을 테스트.
  • 인과 그래핑 (Cause-Effect Graphing): 원인과 결과를 그래프로 나타내어 테스트.
  • 결정표 테스트 (Decision Table Testing): 논리적인 조건과 그에 따른 행동을 표로 정리하여 테스트.
  • 시나리오 테스트 (Scenario Testing): 사용자의 시나리오를 기반으로 테스트.

동등 분할 (Equivalence Partitioning)

• 소프트웨어 테스트의 핵심 방법 중 하나.
• 테스트를 효과적으로 수행하면서 테스트 케이스의 수를 최소화함.
• 입력 또는 출력 영역을 동등한 클래스로 분할하여 각 클래스에서 값 선택하여 테스트 케이스 작성.
• 동등 클래스가 정상 작동한다면 동등 클래스의 나머지 값들도 정상 작동한다고 가정

절차

1. 명세서에서 입력과 출력을 식별.
2. 입력 영역을 동등 클래스로 분할.
   1. 입력 조건이 범위인 경우: 만족하는 클래스와 만족하지 않는 클래스로 분할.
   2. 입력 조건이 특정 값을 기술하는 경우: 만족하는 클래스와 만족하지 않는 클래스로 분할.
   3. 입력 조건이 어떤 집합의 원소를 기술하는 경우: 원소를 포함하는 클래스와 미포함 클래스로 분할.
   4. 입력 조건이 개체 존재 여부를 따지는 경우: 존재, 미존재 클래스로 분할.
3. One-to-one 동등 분할을 통해 테스트 케이스 설계.
   1. 각 입력 필드에 대한 검증 작업을 피함.
   2. 유효하지 않은 테스트 케이스 설계 시, 하나의 필드만 유효하지 않은 입력으로 구성.
4. 최소화 동등 분할:
   1. 하나의 테스트 케이스에 여러 클래스 포함.

분류 트리 기법 (Classification Tree Method)

• 동등 분할 테스트를 체계적으로 수행하기 위해 분류 트리를 활용함.
• 테스트 대상 프로그램 행위에 영향을 줄 수 있는 특성을 도메인 지식, 경험, 명세 등을 활용하여 식별함.
• 동일한 영역을 다양한 관점에서 살펴볼 수 있도록 분류하거나 테스트 관련 에스펙트로 정의함.

절차

1. 명세서 등을 분석하여 대상 클래스에 적용할 수 있는 에스펙트를 식별함.
2. 각 에스펙트가 식별되지 않으면 해당 클래스의 분할을 종료함.
3. 각 에스펙트에서 클래스를 여러 서브 클래스로 분할함.
4. 각 서브 클래스에 대해 위 과정을 반복 수행함.
5. 분류 트리의 단말 노드를 적절히 조합하여 테스트 케이스를 설계함.

경계 값 분석 (Boundary Value Analysis)

• 입력 영역 경계 근처에 있는 값들을 활용하여 테스트 케이스를 설계하는 방법.
• 동등 분할과 유사하게 입력 및 출력 영역을 여러 클래스로 분할하여 테스트를 수행함.
• 클래스의 경계와 경계 근처에 있는 값들을 사용하여 테스트 케이스를 설계함.

절차

1. 명세서에서 입력 및 출력을 식별함.
2. 각 입력 및 출력에 대해 동등 분할을 수행함.
3. 각 분할된 클래스의 경계값을 식별함.
4. 2-value BVA 또는 3-value BVA에 따라 경계값 분석을 수행함.
5. 얻은 각 값에 대해 기대 출력을 명세로 구하여 테스트 케이스를 설계함.
6. 테스트 케이스를 구성할 때, 한 경곗값에 대해 하나의 테스트 케이스를 구성하는 일대일 방법이나 하나의 테스트 케이스에 여러 개의 경곗값을 포함하는 최소화 방식을 사용함.

조합 테스트 (Combinatorial Testing)

• 조합 테스트는 테스트 대상 프로그램 내 여러 클래스의 각 입력 인자를 동등 분할이나 경곗값 분석 등의 방법으로 여러 클래스 또는 값으로 분할한 후, 이들을 조합하여 테스트 케이스를 구성하는 방식

조합 테스트의 4가지 방법

• Each choice 테스트:
  • 각 입력 인자의 분할된 클래스에서 최소한 하나의 입력값이 테스트 케이스를 포함함.
  • 테스트 케이스 수가 매우 적으며, 코드가 단일 인자에만 의존할 때 유용함.
• 페어와이즈 테스트:
  • 각 입력의 값(또는 클래스)과 다른 입력의 값(또는 클래스)을 최소한 한 번은 조합하여 테스트하는 방법.
  • 모든 입력 간의 가능한 상호작용을 고려하지 않고 모든 두 입력 간의 상호작용만을 고려.
• AII combinations 테스트:
  • 모든 입력 인자의 모든 가능한 클래스 조합이 테스트 케이스에 포함되도록 하는 방법.
  • 모든 입력의 모든 클래스 조합을 고려하여 테스트 케이스를 작성.
• Base choice 테스트:
  • 기반이 되는 조합을 미리 선정하고, 그 중 하나의 인자만 변경하여 테스트 케이스를 생성하는 방법.
  • 주로 사용자의 관점에서 선택될 빈도가 가장 높거나 정상 동작할 것으로 예상되는 조합을 선택.

절차

1. 테스트 대상 프로그램의 입력을 식별
2. 명세를 분석하여 각 입력 인자를 적절한 방법으로 여러 클래스 또는 값으로 분할.
3. 적절한 조합 테스트 방법을 선택하여 입력값(또는 클래스)들을 조합.
4. 각 입력 조합에 대해 명세를 분석하여 기대 결과를 할당.

결정표 테스트 (Decision Table Testing)

• 결정표 테스트는 결정표를 이용하여 테스트 케이스를 설계하는 방법으로, 결정표는 조건을 기술하는 부분과 조건의 조합에 대해 취하는 행위를 기술하는 부분으로 구성

절차

1. 명세 등을 분석하여 모든 조건을 분석.
2. 모든 조건의 조합에 대한 행위를 결정.
3. 위 두 단계를 통해 결정표를 만듦.
4. 결정표에서 가능하지 않은 조건의 조합은 배제.
5. 결정표를 축약할 수 있는지 파악.
6. 결정표의 각 규칙이 최소한 한 번은 테스트될 수 있도록 테스트 케이스를 생성.
7. 축약된 결정표에서도 테스트 케이스가 최소 한 번은 테스트될 수 있도록 테스트 케이스를 생성.
8. 각 규칙을 실행하는데 요구되는 조건의 조합을 만족하는 입력과 출력을 식별하여 테스트 케이스를 구성.

상태 전이 테스트 (State Transition Testing)

• 시스템을 상태 전이도로 모델링한 후 테스트 케이스들을 상태 전이도에서 체계적으로 선정하는 방법.

상태 전이 테스트 방식

• 상태 테스트: 상태 전이도의 모든 상태를 최소한 한 번 방문하는 테스트 케이스들을 설계
• 단일 전이 테스트: 상태 전이도의 모든 유효한 전이들을 최소한 한 번 방문하는 테스트 케이스 설계
• All transitions 테스트(0-switch 테스트): 유효한 전이를 포함해 유효하지 않은 전이들도 최소 한 번 방문하는 테스트 케이스 설계
• 다중 전이 테스트: 상태 전이도에 있는 N+1개의 전이 시퀀스들을 최소 한 번 방문하는 테스트 케이스 설계

절차

1. 상태 전이도의 초기 상태를 전이 트리의 루트 노드로 설정.
2. 루트 상태에서 나오는 각 전이에 대해 전이 목적 상태에 해당하는 노드를 추가하고 루트 노드에 추가된 노드로 간선을 연결.
3. 목적 상태가 전이 트리에 이미 나와 있거나 종료 상태가 아니면, 동일한 과정을 각 목적 상태에 대해 반복.

시나리오 테스트 (Scenario Testing)

• 시나리오 테스트는 기존 요구사항 명세서에서 각 개별 기능에 대한 상세한 내용이 시나리오 형태로 기술되어 있다면 해당 기능을 테스트하는 방법
• 여러 번의 입출력을 순차적으로 수행하여 시스템이 요구사항에서 요구된 대로 동작하는지 확인
• 단순한 시스템의 경우 하나의 액티비티 다이어그램으로 전체 시스템의 테스트 시나리오를 표현할 수 있음
• 복잡한 행위 모델의 구축, 분석, 테스트 케이스 설계를 위해 숙련된 인력과 많은 시간 투자 또는 상용 도구의 지원이 필수
• 여유 자원이 충분하지 않은 경우 전체 시스템 단위가 아닌 요구사항 단위로 테스트 시나리오를 설계 가능
• 요구사항 간의 의존성이 크다면 의존적인 요구사항을 함께 고려하여 테스트 시나리오를 설계

절차

1. 테스트하려는 프로그램의 명세를 분석하여 기본 시나리오 및 대안 시나리오를 식별합니다.
2. UML 액티비티 다이어그램 등을 이용하여 식별된 시나리오들을 통합한 모델을 설계합니다.
3. 모델에서 테스트 시나리오를 추출하여 테스트 케이스로 매핑합니다.

구조 기반 테스트

• 프로그램의 제어 흐름이나 자료 흐름 정보를 기반으로 하여 테스트 케이스를 설계하는 방법
• 구조적 테스트, 화이트박스 테스트, 글래스 박스 테스트로도 불림
• 일부 경로만 테스트하는 방법 사용
• 가장 이상적인 것은 프로그램의 모든 경로를 최소 한 번 실행하여 테스트하는 것
• 주요 기법
  1. 문장 테스트: 프로그램의 모든 문장을 최소 한 번은 실행하도록 하는 테스트입니다.
  2. 결정 테스트: 프로그램 상에 있는 모든 결정문의 결과가 최소 한 번은 참과 거짓이 되도록 하는 테스트입니다.
  3. 조건 테스트: 프로그램의 모든 조건이 최소 한 번은 true와 false가 되도록 하는 테스트입니다.
  4. 결정/조건 테스트: 결정 테스트와 조건 테스트를 모두 만족하는 테스트 케이스 집합을 설계합니다.
  5. 다중 조건 테스트: 결정이 가질 수 있는 경우뿐만 아니라 결정을 구성하는 기본 조건들이 가질 수 있는 모든 가능한 조합까지 검증합니다.
  6. 기본 경로 테스트: 프로그램의 모든 경로 중에서 기본 경로를 테스트하도록 요구합니다.
• 커버리지를 높이는 구조기반 테스트: 문장 테스트> 결정 테스트> 결정/조건 테스트> 다중 조건 테스트

경험 기반 테스트

• 테스트 케이스 설계를 바탕으로 테스트를 수행하지 않고 도메인에 대한 테스터의 경험, 기존 테스트 결과, 테스터의 직관으로 주로 활용하여 테스트를 수행.
• 실행 가능한 소프트웨어가 필요하고, 환경이 요구되며 소스 코드는 사용되지 않음.
• 소프트웨어의 품질 요구사항인 가용성, 확장성, 신뢰성 등을 확인
• 주요 기법
  1. 오류 추정: 이 방법은 테스트 케이스를 설계할 때 개발자가 범할 수 있는 실수를 추정하고 그에 따라 결함을 검출하는 방법으로 동등 분할이나 경곗값 분석 같은 명세 기반 테스트 방법과 함께 사용될 수 있음
     • 오류 검출 대표 사례 
     • - 필수 입력이 누락된 경우 - 입력 항목의 길이 제약을 위반하는 경우 - 입력 항목의 형식을 위반하는 경우 - 입력 값의 명시적 또는 묵시적 제약을 위반하는 경우
  2. 탐색적 테스트: 이 방법은 테스트 대상에 대한 이해를 바탕으로 테스트를 진행, 테스터는 테스트를 실행하면서 즉석에서 테스트 케이스를 결정하고 문서화 없이 테스트를 수행
     • 적합한 상황 
     • - 시스템에 대한 이해와 정보가 부족한 경우 - 빠르게 변화하는 환경에서 적응해야 하는 경우 - 에자일 방법론을 사용하는 웹 응용 프로그램과 같은 환경에서 테스트를 수행해야 하는 경우