[ISTQB_FL] 4장 - 테스트 분석과 설계

[CSTS 요약 정리] 2. 테스트 설계기법

[CSTS 요약 정리] 2. 테스트 설계기법

 

동적 테스트 

• 블랙박스 테스트 기법( 명세기반테스트 )은 테스트 대상의 명시된 동작에 대한 분석을 기반으로 한다. 따라서 테스트 케이스는 소프트웨어 구현 방식에 의존하지 않는다. 
• 화이트박스 테스트 기법 ( 구조기반테스트 ) 은 테스트 대상의 내부 구조와 처리에 대한 분석을 기반으로 한다. 소프트웨어 구현 방식에 의존하기 때문에 테스트 대상의 설계나 구현이 끝난 후에 테스트 케이스를 만들 수 있다.
• 경험 기반 테스트 기법은 블랙박스와 화이트박스 테스트 기법으로는 식별하지 못할 수 있는 결함을 찾게 해준다.

---

블랙박스 테스트 기법

---

동등 분할

• 100% 커버리지= 식별한 모든 분할(유효 분할과 비유효 분할)을 실행
• 분할 집합이 다수인 경우, 가장 간단한 커버리지 기준은 Each choice coverage
  • Each choice coverage : 각 분할 집합에서 최소한 하나의 입력값을 실행

---

경계값 분석

• 두 개 선택(2-value) 경계값 분석 : 각 경계값에 대해 두 개의 커버리지 항목을 도출
  
  • 100% 커버리지=  식별한 모든 경계값을 실행

• 세 개 선택(3-value) 경계값 분석 : 각 경계값에 대해 세 개의 커버리지 항목을 도출
  
  • 100% 커버리지=  식별한 모든 경계값, 경계값과 이웃한 양쪽의 값을 실행

---

 

Q.

비밀번호의 길이가 6자 이상 12자 이하여야 하는 입력 필드를 테스트하고 있다. 

입력 필드는 처음에 비어 있다(비밀번호 길이 = 0). 

 

100% 세 개 선택(3-value) 경계값 커버지리 달성을 위해 테스트해야 할 비밀번호 길이는?

비밀번호 길이는 세 개의 동등 분할로 나눌 수 있다.

1. 너무 짧은 비밀번호 {0, 1, …, 4, 5}

2. 가능한 비밀번호 {6, 7, …, 11, 12}

3. 너무 긴 비밀번호 {13, 14, …}

 

→ 100% 세 개 선택(3-value) 경계값 커버지리를 달성하려면?   0, 1, 4, 5, 6, 7, 11, 12, 13, 14 값을 테스트해야 한다.  

 

 

---

결정 테이블 테스팅

• 100% 커버리지= 실현 가능한 모든 조건 조합을 실행
• 조건이 많으면 모든 결정 규칙을 실행하는 데 오랜 시간이 걸릴 수 있다.

---

상태 전이 테스팅

• 모든 상태 커버리지
  • 100% 커버리지= 모든 상태를 확인
  • 모든 전이를 실행하지 않고도 달성할 수 있다.
• 유효 전이 커버리지 ( 0-switch )
  • 100% 커버리지= 모든 유효 전이를 실행
  • 유효 전이 커버리지 100%를 달성하면, 모든 상태 커버리지도 달성된다.
• 모든 전이 커버리지
  • 100% 커버리지= 모든 유효 전이와 비유효 전이를 실행
  • 모든 전이 커버리지 100%를 달성하면, 모든 상태 커버리지와 유효 전이 커버리지도 달성된다.

 

---

화이트박스 테스트 기법

---

• 구문 테스팅 (문장 테스트) 
  • 100% 구문 커버리지= 코드의 모든 실행 가능한 구문을 적어도 한 번은 실행
• 분기 테스팅 (결정 테스트) 
  • 100% 분기 커버리지= 코드의 모든 분기(결정문의 모든 결과)를 적어도 한 번은 실행

 

※코드의 가능 경로를 모두 실행하는 것은 불가능하다.

---

• 화이트박스 테스팅의 가치

•  모든 화이트박스 기법은 테스트 중 전체 소프트웨어 구현을 고려하므로 소프트웨어 명세가 모호하거나 뒤떨어지고 불완전한 경우에도 결함을 쉽게 감지할 수 있다.
•  화이트박스 기법은 정적 테스팅(예: 코드 드라이 런 중)에 사용할 수 있다. - 아직 실행할 준비가 되지 않은 코드 외에도 슈도 코드(pseudocode) 또는 제어 흐름 그래프로 모델링할 수 있는 기타 상위 수준 및 하향식(top-down) 논리를 검토
•  화이트박스 커버리지 측정치는 객관적인 커버리지 측정값을 제공하고 커버리지를 높이기 위해 추가로 필요한 테스트를 만들기 위해 필요한 정보를 제공

 

---

경험 기반 테스트 기법

 

• 오류 추정
  • 테스터의 지식(애플리케이션의 과거 동작, 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형 , 다른 유사 애플리케이션에서 발생한 장애 유형)을 기반으로 오류, 결함, 장애 발생을 예측
• 탐색적 테스팅
  • 명세가 부족하거나 부적합할 경우, 테스트에 시간적 압박이 심할 경우  
  • 테스터가 풍부한 경험과 도메인 지식을 가지고 있고 높은 수준의 분석 기술, 호기심, 창의성 등 필요 기술을 갖춘 경우에  효과적
• 체크리스트 기반 테스팅

 

---

협업 기반 테스트 접근법

---

• 협업 기반 사용자 스토리 작성

사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.

사용자 스토리는 세 가지 중요 요소를 가지며,  이를 합쳐서 '3C'라고 부른다.

 

• 카드(Card) - 사용자 스토리를 설명하는 매체 (예: 인덱스 카드, 전자 게시판 항목)

• 대화(Conversation) - 소프트웨어 사용 방법에 대한 설명 (문서 또는 구두로)

• 확인(Confirmation) - 인수 조건

---

• 인수 조건

 사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건이다. (테스트 컨디션으로 볼 수 있다.)  인수 조건은 보통 3C 중 대화(Conversation)를 통해 결정된다. 인수조건은 사용자 스토리 범위 정의,  이해관계자 간 합의 도출, 긍정과 부정 시나리오 설명, 사용자 스토리 인수 테스팅의 베이시스 제공, 정확한 계획 및 추정에 사용된다. 

• 사용자 스토리의 인수 조건 작성법: 대부분의 인수 조건은 이 두 가지 형식 중 하나로 문서화할 수 있다. 
  • 시나리오 기반 (예: 행위 주도 개발에서 사용하는 Given/When/Then 형식)
  • 규칙 기반 (예: 베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑)

---