12장 테스트 계획 - 12.4 테스트 전략 수립

12.4 테스트 전략 수립

1. 개별 테스트
2. 테스트 산출물
3. 테스트 설계 기법
4. 테스트 환경 요건
5. 테스트 데이터 요건
6. 재태스팅 및 리그레이션 테스팅
7. 테스팅 중단 및 재시작 조건
8. 테스트 메트릭
9. 테스트 완료 기준
10. 조직 테스트 전략과의 차이점

---

12.4.1 개별 테스트

• 프로젝트 테스트 계획의 하위 요소
• 프로젝트 테스트를 구성하는 개별 테스트(레벨 테스트 및 유형 테스트)를 나열
• 테스트 컨텍스트에서 파악된 테스트 범위를 바탕으로 개별 테스트 결정
• 공통적인 내용은 프로젝트 테스트 계획서에 기술
• 개별 테스트 고유한 내용은 개별 테스트 계획서에 기술
• 조직 테스트 전략에 이미 수행할 개별 테스트가 제시되어 있으므로 일치해야함
• 테스트 전략은 개별 테스트 마다 다를 수 있기 때문에 개별 테스트별로 계획서 작성

12.4.2 테스트 산출물

• 조직 테스트 전략 명세서를 바탕으로 테스트를 수행하면서 작성할 산출물 정의
• 테스트 입력과 출력, 자동화 도쿠 기술
• 테스트 산출물이 언제 누구에게 제공될지에 대한 계획도 기술

12.4.3 테스트 설계 기법

• 테스트 컨텍스트에서 명시된 테스트 대상과 피처를 바탕으로 테스트 설계 기법을 결정
• 정적 테스트 설계 기법과 동적 테스트 설계 기법이 있음
• 테스트 설계 기법은 최대한 많은 수의 결함을 검출하면서 최소의 비용이 소요되는 기법을 선택함
• 테스트 설계 기법이 조직 테스트 전략 명세에 명시되어 있다면 참조함
• 테스트 계획 활동 - 테스트 설계 기법 선정하고 핵심 전략 결정
• 테스트 설계 및 구현 활동 - 구체적으로 어떤 방법을 사용할지 결정
  • ex) 테스트 계획 활동에서 경곗값 분석 적용 선택 / 테스트 설계 및 구현 활동에서 2-value 방법으로 구체화
• 테스트 대상의 특성에 맞는 테스트 설계 기법 선택
  • 상태 의존적 동작 여부: 현재 입력과 더불어 과거의 입력에도 영향을 받는 경우 상태 의존적이라고 함
  • 동작 방식: 테스트 대상이 흐름 중심인지 이벤트 중심인지 파악
  • 테스트 변수 간의 제약사항 고려 여부

12.4.4 테스트 환경 요건

• 테스트를 수행하기 위해 필요한 환경을 식별
• 테스트 대상을 실행하기 위한 모든 환경으로 하드웨어, 운영체제, 소프트웨어, 테스트 도구 등 포함
• 테스트 계획 활동 시에는 테스트 대상의 실행 환경과 각 환경 항목의 요건을 정의
• 이 시점에 구체화하기 어려울 땐 테스트 설계 및 구현 활동에서 구체화해도 됨
• 개별 테스트에 따라 필요한 테스트 환경은 달라질 수 있음
• 실제 환경과 유사한 환경에서 테스트하면 좋지만 비용 등에서 어려움이 따름
• 컴포넌트, 통합 테스트는 개발자 환경에서 테스트
• 시스템, 인수 테스트는 테스트 대상 시스템 뿐만 아니라 운영 환경에 많은 영향을 받기 때문에 테스트를 위한 환경을 구성

12.4.5 테스트 데이터 요건

테스트 대상 입력 유형

• 테스트 대상에 입력되는 데이터
• 규모가 크고 복잡한 경우에는 파일 또는 데이터베이스에 정의되고 이를 참조할 수 있음

테스트 대상 상태 유형

• 테스트 케이스의 선행 조건에 명세된 상태로 설정하기 위한 테스트 데이터

테스트 환경 항목 유형

• 테스트 대상의 선행 조건을 충족시키기 위하여 테스트 환경 항목에 사용되는 데이터

12.4.6 재태스팅 및 리그레이션 테스팅

재태스팅

• 검출된 결함이 해결되었는지 여부에 앞서 결함을 검출한 테스트 절차를 활용하여 다시 테스트 수행
• 검출된 결함의 해결 여부가 검증될 때까지 반복적으로 수행
• 테스트 스크립트 혹은 자동화 도구 사용하여 테스트 절차를 자동으로 수행하는 전략 적용 가능
• 변경과 유형에 가용한 시간 등을 고려하여 재태스팅이 수행되는 개별 테스팅 선정
  • ex) 컴포넌트 내부만 변경하여 외부로는 영향을 끼치지 않을 때는 통합 테스팅 생략 가능
• 결함의 심각도에 따라 선택적으로 재테스팅을 수행하는 전략 수립 가능
  • ex) 낮은 심각도일 경우에는 컴포넌트, 통합 테스트를 생략하고 시스템 테스트 할 수 있음

리그레션 테스팅

• 소프트웨어 변경이 발생한 후 변경에 의한 결함이 없고 요구사항을 충족하는지 검증하기 위한 테스트
• 특정 레벨에 산정되지 않고 여러 레벨에서 수행 가능 ➡️ 개별 테스트에 대한 계획서보다는 프로젝트 테스트 계획서에 기술하는 편
• 시간과 비용에 따라 전체 레벨에서 수행하지 않고 수행할 테스트 레벨 결정할 수 있음
• 가해진 변경의 유형과 영향에 대한 추정을 바탕으로 테스트 레벨 결정
• 각 개별 테스트에서 어떤 리그레션 테스팅 전략을 적용할지도 결정
• 반복적인 수행이 필요하므로 테스트 절차를 자동화할 수 있는 도구 사용이 좋음

12.4.7 테스팅 중단 및 재시작 조건

• 테스트 활동의 수행을 중단하거나 중단된 테스트 활동을 재시작할 수 있는 조건을 명시
• 테스트 수행을 방해할 수 있는 중단 조건으로 설정
• 중단된 원이 해결되어 다시 시작할 때 수행해야 하는 테스트 명시

12.4.8 테스트 메트릭 

(*Metric: 정량적 측정 기준, 척도)

1. 테스트 계획 활동 메트릭
2. 테스트 설계 및 구현 활동 메트릭
3. 테스트 환경 구축 및 관리 활동 메트릭
4. 테스트 실행 활동 메트릭
5. 결함 보고 활동 메트릭

---

 

테스트 수행과 결과를 정량적으로 판단하는데 사용할 측정 메트릭을 결정

테스트 현황 보고서에 테스트 진척도를 파악할 때 지표로 이용 가능

테스트 종료 보고서에 테스트 완료 여부에 대한 평가 데이터로 활용 가능

 

1. 테스트 계획 활동 메트릭

• 테스트 대상 수: 계획된 테스트 대상의 수 
• 피처의 수: 계획된 전체 피처의 수
• 테스트 활동에 대한 진척도 파악 가능

2. 테스트 설계 및 구현 활동 메트릭

• 피처 집합 수: 테스트 대상별 피처 집합의 수
• 테스트 케이스 수: 개발된 전체 테스트 케이스의 수
• 테스트 절차 수: 개발된 전체 테스트 절차의 수
• 테스트 환경 항목 수: 식별된 테스트 환경 항목의 수
• 테스트 데이터 수: 식별된 테스트 데이터의 수

커버리지

• 테스트 케이스 및 절차가 목표로 하는 범위를 충분히 반영하였는지 커버리지를 통해 측정할 수 있음
• 테스트 케이스 및 테스트 절차를 통해서 요구사항, 설계, 소스 코드가 어느 정도 확인되었는지 측정할 수 있음
• 테스트 케이스 및 테스트 절차를 통해 확인되는 테스트 베이시스의 비중으로 얼마나 충분한 테스트를 하는지 보여주는 정량적 지표
• 테스트 베이시스 -요구사항, 설계, 소스 코드

 

커버리지 유형

요구사항 커버리지

• 테스트 케이스 및 테스트 절차가 제시된 요구사항을 어느 정도 확인하고 있는지를 의미
• 각 요구사항에 대한 테스트 케이스 및 테스트 절차 개발 여부에 대한 추적성을 바탕으로 요구사항 커버리지 계산 가능

 

설계 커버리지

• 설계 활동 결과물에 대해서 테스트 케이스 및 테스트 절차가 얼마나 많이 확인될 수 있는지를 의미
• 설계 단위에 대한 수행 커버리지는 전체 설계 단위 중에서 몇 개가 수행되었는지를 의미
• 설계 단위에 대한 호출 커버리지는 전체 호출 중에서 몇 개가 호출되었는지를 의미
• 설계 커버리지는 구조 설계 및 상세 설계의 결과물을 바탕으로 진행하며 두 설계의 단위가 상이하므로 설계 단위에 따라서 구체화함 

설계 단위가 함수일 때

 

설계 단위가 클래스일 때

각 클래스의 수준과 클래스가 가지는 연산의 수준에서 정의

 

설계 단위가 컴포넌트일 때

컴포넌트의 수준과 인터페이스 및 인터페이스를 구성하는 연산의 수준에서 정의

코드 커버리지

• 테스트 대상의 소스 코드 요소를 테스트 케이스 ㄸ는 테스트 절차가 얼마나 확인하는가를 의미
• 소스 코드의 요소는 문장, 결정 조건 등이 있음

3. 테스트 환경 구축 및 관리 활동 메트릭

• 계획된 테스트 환경과 테스트 데이터에 대한 준비 상황으로 메트릭 정의
• 테스트 환경 구출률
• 테스트 데이터 준비율

4. 테스트 실행 활동 메트릭

• 테스트 케이스 및 테스트 절차 실행과 그 결과를 바탕으로 메트릭 정의
• 실행된 테스트 케이스(테스트 절차) 수
• 통과된 테스트 케이스(테스트 절차) 수
• 실패 테스트 케이스(테스트 절차) 수
• 실행된 테스트 케이스 비율은 개발된 테스트 케이스 중에서 실행에 성공한 테스트 케이스의 비중으로 정의
• 테스트 절차도 동일

커버리지

• 실행된 테스트 케이스를 통해서 달성될 수 있는 요구사항 커버리지, 설계 커버리지, 코드 커버리지를 의미

5. 결함 보고 활동 메트릭

• 검출 결함 수: 검출된 결함의 개수
• 검출 결함 밀도: 검출된 결함 개수 / 태상 코드 행수
• 상태별 결함 수: 결함 생명 주기의 각 상태별 결함의 개수
• 결함 나이: 결함이 보고되고 종결될 때까지 걸린 시간
• 누적 검출 결함 수: 전체 기간에 걸쳐서 식별된 모든 결함의 수
• 상태별 누적 결함 수: 전체 기간에 걸쳐서 식별된 모든 결함을 각 상태별로 구한 수치
• 보고 기간 내에 측정된 각 메트릭 값을 전체 기간으로 누적한 수치도 메트릭으로 사용 가능
• 전체가 아니라 개별 테스트 대상별로 구할 수도 있음

12.4.9 테스트 완료 기준

1. 기본 유형의 테스트 완료 기준
2. 분석 유형의 테스트 완료 기준
3. 개별 테스트의 테스트 완료 기준

---

테스트 완료 기준은 테스트 완료 여부를 판단할 수 있는 객관적인 기준

기준을 강하게 하면 엄격한 수준으로 테스팅을 수행하고 높은 수준의 품질을 기대할 수 있음

기대하는 품질 수준에 따라서 테스트 완료 기준 설정할 수 있음

테스트가 종료되었을 때 해당 테스트의 수행 결과가 테스트 완료 기준을 충족시켰는지 평가하고 기록

 

1. 기본 유형의 테스트 완료 기준

세가지 유형은 단독뿐만 아니라 조합하여서 사용할 수 있음

 

테스트 케이스(테스트 절차) 유형

• 테스트 대상과 관련된 테스트 케이스 및 테스트 절차 중에서 어느 정도가 통과되었는지를 기준으로 삼음
• 컴포넌트테스트에서는 테스트 대상 모듈의 중요도에 따라서 통과 비율이 달라질 수 있음
• 통합 테스트에서도 중요한 기능/비기능에 대해서는 좀 더 높은 테스트 케이스 통과 비율을 가짐

테스트 커버리지 유형

• 테스트 케이스를 도출하는 기준 문서의 내용이 얼마나 다루어졌는지를 기준으로 삼음

 

결함 유형

• 발견된 결함 정보를 바탕으로 테스트 완료 기준 설정
• ex) 결함은 10개 이하여야 한다

2. 분석 유형의 테스트 완료 기준

테스트 대상 및 테스트 결과에 대한 분석을 바탕으로 테스트 완료 기준 설정 가능

동적 테스트 활동에 추가적인 노력이 필요하므로 시스템, 인수 테스트 등 주요 의사 결정을 하는 경우에 사용될 수 있음

 

신뢰 예측 모델 기반 방법

• 유사한 다른 시스템의 테스트 결과 또는 테스트 대상에 대한 정보를 바탕으로 신뢰도 예측
• 목표로 삼은 수준 이상으로 신뢰도 달성하면 테스트 완료

결함 탐침 기반 방법

• 테스트 전에 다양한 유형의 결함을 인위적으로 삽입한 후, 테스트에서 발견된 결함 중에서 삽입된 결함의 비율을 구함
• 이 비율을 이용하여 시스템에 남아 있는 발견되지 않은 결함의 수를 예측하고 일정 수준 이하이면 테스트 완료라고 판단
• 삽입되는 결함은 테스터에 바탕으 두므로 편향될 수 있음
• 균형적인 결함을 만드는 것이 어려울 수 있음

복수 테스트림 기반 방법

• 독립적인 두 개의 테스트팀이 테스트하여 각각 발견한 결함의 수를 바탕으로 전체 결함의 수를 예측
• 두 팀을 투입해야 하기 때문에 높은 비용 소요
• 테스트 전략과 테스트 경험에 따라서 결함 발견의 독립성이 보장되기 어려울 수 있음

3. 개별 테스트의 테스트 완료 기준

각 개별 테스트별로 구체적으로 설정

12.4.10 조직 테스트 전략과의 차이점

• 테스트 전략 대부분의 항목은 조직 테스트 전략 명세서에 정의되기 때문에 동일 내용은 참조로 기술하면 충분
• 조직 테스트 전략 명세와 차이 나는 사항은 차이점과 함께 다른 전략을 수립한 근거와 함께 기술