10. 명세 기반 테스트(블랙박스 테스트)

프로그램의 내부 논리 구조를 참조하지 않고

사용자의 요구사항이 기술된 명세나 설계 정보 등을 이용하여 테스트 케이스를 개발

 

명세 기반 테스트

프로그램 코드 내부 구조를 전혀 모르는 사람이 수행하는 것이 더 좋음

외부 테스터라도 프로그램 기능과 도메인에 관한 이해는 충분해야 함

 

XP의 테스트 주도 개발에서는 개발자가 먼저 테스트 케이스 작성 후 코드 구현

 

• 코드가 아닌 명세를 바탕으로 테스트 케이스를 설계하므로 서브나 전체 시스템처럼 규모가 큰 단위에도 적용 가능
• 테스터가 구현 언어나 알고리즘 구현에 관한 지식이 없어도 테스트 수행 가능
• 사용자 관점에서 테스트를 수행해서 효과적으로 결함을 검출할 기회가 제공됨
• 명세 결함이 드러나는 기회가 되며 명세가 완성되는 순간 테스트 케이스를 설계할 수 있음

명세에는 있지만 구현되지 않는 기능이 있는 결함을 누락 결함이라고 함 

프로그램 코드에 누락된 기능에 관한 정보는 명세에서 얻을 수 있고, 누락 결함 검출 가능

---

동등 분할

---

소프트웨어 테스트의 근간을 이루는 방법

테스트를 효과적으로 수행하면서도 테스트 케이스의 개수를 줄이는 방법

입력이나 출력 영역을 동등 클래스라 불리는 몇 개 영역으로 분할하여 각 클래스에서 값을 선택해서 테스트 케이스 이용

 

절차

• 명세에서 입력과 출력을 식별
• 각 입출력 영역을 동등 클래스들로 분할
  이때 프로그램이 사용되는 입출력에 관한 도메인 지식을 이용하거나 과거의 경험을 이용해서 분할
• 각 동등 클래스에서 최소 하나의 대푯값을 선정해서 반영하고, 테스트 케이스 테이블 작성

동등 클래스 입력영역 분할 규칙

• 입력 조건이 범위를 기술하는 경우 조건을 만족하는 하나의 클래스와 조건을 만족하지 못하는 두 클래스로 분할
• 입력 조건이 특정 값을 기술하는 경우에는 입력 조건을 만족하는 경우 입력 조건을 만족하지 않는 두 클래스로 분할
• 입력 조건이 어떤 집합의 원소를 기술하는 경우에는 그 원소만으로 이뤄진 클래스와 그렇지 못한 클래스로 분할
• 입력 조건이 어떤 개체가 존재하는지 따지는 경우에는 있는 경우와 없는 경우 각각 하나의 클래스로 만듦

 

One-to-one 동등 분할 

• 입출력 영역을 분할한 클래스들과 테스트 케이스 간 일 대 일 관계를 명시적으로 보여줌
• 프로그램이 테스트 케이스를 타당하게 입력 받아 처리하면 입력 필드에 대한 검증 작업을 하지 않는다는 의미
• 프로그램이 입력으로 받아들이지 않으면, 테스터 입장에서는 어떤 필드가 잘못됐는지 알 수 없음
• 유효하지 않은 테스트 케이스 설계 시 한 번에 하나의 필드만 유효하지 않은 입력으로 구성하는 것이 바람직

최소화 동등 분할

• 하나의 테스트 케이스에 여러 개의 클래스가 포함되도록 함

---

분류 트리 기법

---

동등 분할 테스트를 분류 트리를 이용하여 체계적으로 수행할 수 있게 해줌

우선 테스트 대상 프로그램 행위에 영향을 줄 수 있는 특성들을 도메인 지식, 경험, 프로그램의 명세 등을 이용하여 식별

동일한 영역을 여러 다른 관점에서 볼 수 있게 해주는 특성을 분류 또는 테스트 관련 에스펙트라고 함

 

절차

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

---

경곗값 분석

---

경곗값 분석은 입력 영역 경계 근처에 있는 값들을 이용하여 테스트 케이스를 설계하는 테스트 방법

경곗값 테스트는 동등 분할과 마찬가지로 입출력 영역을 여러 클래스로 분할

경곗값 분석은 클래스의 경계와 경계 근처에 있는 값들을 사용하여 테스트 케이스 설계

 

절차

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

---

조합 테스트

---

테스트 대상 프로그램 내 여러 클래스의 각 입력 인자를 동등 분할이나 BVA 등의 방법으로

여러 클래스 또는 값으로 분할했을 때 이들을 조합해서 테스트 케이스를 구성하는 방식

• Each choice 테스트 : 각 입력 인자의 분할된 클래스에서 최소한 하나의 입력값이 테스트 케이스에 포함되도록 함
• 페어와이즈 테스트 : 각 인자의 값(또는 클래스)과 다른 인자의 값(또는 클래스)을 최소한 한 번은 조합하여 테스트
• All combinations 테스트 : 모든 입력 인자의 모든 가능한 클래스 조합이 테스트 케이스에 포함되도록 함
• Base choice 테스트 : 기반이 되는 테스트 조합을 미리 선정
  사용자의 관점에서 선택될 빈도가 가장 높고, 일반적으로 정상 동작할 수 있는 것을 선정
  선정된 기반 테스트에서 한 인자에만 변경을 주고 나머지는 기반 테스트의 값으로 고정하여 테스트 케이스 생성

절차

• 테스트 대상 프로그램의 입력을 식별
• 명세 등을 분석하여 각 입력 인자를 동등 분할이나 BVA를 통해 여러 값이나 클래스로 분할
• 적절한 조합 테스트 방법을 선정하여 입력 값을 조합
• 각 입력 조합에 대해 명세를 분석하여 기대 결과를 할당

---

결정표 테스트

---

결정표를 이용해서 테스트 케이스를 설계하는 테스트 방법

결정표는 조건을 기술하는 부분과 조건의 조합에 대해 취하는 행위를 기술하는 부분으로 구성

 

절차

• 명세 등을 분석하여 모든 조건을 분석
• 모든 조건의 조합에 대한 행위를 결정
• 첫 번째와 두 번째 단계를 통해 결정표를 만듦
• 가능하지 못한 조건의 조합은 배제
• 결정표를 축약할 수 있는지 파악
• 결정표의 각 규칙이 최소한 한 번은 테스트될 수 있도록 테스트 케이스 생성

축약된 결정표에서 테스트 케이스 생성 시 최소 한 번은 테스트 될 수 있도록 테스트 케이스 생성

규칙을 실행하는데 요구되는 조건의 조합을 만족하는 입출력을 식별하여 테스트 케이스를 구성

---

상태 전이 테스트

---

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

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

절차

• 상태 전이도의 초기 상태를 전이 트리의 루트 노드로 함
• 루트 상태에서 나오는 각 전이에 전이 목적 상태에 해당하는 노드를 추가하고 루트 노드에 추가된 노드로 간선 연결
• 목적 상태가 전이 트리에 이미 나와 있거나 종료 상태가 아니면 같은 과정을 각 목적 상태에 수행

---

시나리오 테스트

---

기존 요구사항 명세서에서 각 개별 기능에 대한 상세한 내용이 시나리오 형태로 기술되어 있다면 기능 테스트 수행 가능

여러 번의 입출력을 순차적으로 수행

시나리오에 맞게 하기 위해 요구사항에 기록된 기능의 동작 흐름을 분석하여 테스트 시나리오 결정

결정된 테스트 시나리오 기반으로 테스트 수행해서 시스템이 요구사항에서 요구된 대로 동작하는지 확인

 

절차

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

단순 시스템일 경우 하나의 액티비티 다이어그램으로 전체 시스템의 테스트 시나리오를 표현할 수 있음

복잡한 행위 모델의 구축, 분석, 테스트 케이스 설계를 위해 숙련된 인력과 많은 시간 투자 또는 상용 도구 지원 필수적

 

여유 자원이 충분하지 못하면 전체 시스템 단위가 아닌 요구사항 단위로 테스트 시나리오 설계 가능

요구사항 간의 의존성이 크면 의존적인 요구사항을 함께 고려해서 테스트 시나리오 설계