[자격증] CSTS_FL 요약정리 (테스트 설계 기법)

📌 테스트 설계 기법

🔹 정적 테스트 (Static Testing) (기쓰관리펙트감사)

• 테스트 대상을 실행하지 않고 오류를 찾아내는 방법
• 리뷰(Review): 여러 전문가가 모여 프로그램을 검토하여 결함을 검출하는 기법
  • 기술 리뷰
  • 워크 쓰루
  • 관리 리뷰
  • 인스펙션
  • 감사

📍 리뷰 절차

1. 경영진 준비
2. 리뷰 계획
3. 리뷰 절차 개요 설명
4. 작업물 개요 설명
5. 개별 준비
6. 그룹 검토
7. 재작업
8. 후속작업

📍 관리 리뷰

• 프로젝트의 진행 상황을 모니터링하고 일정 및 계획을 평가
• 프로젝트 문서 예시:
  • 설치 계획, 백업 및 회복 계획, 안정성 계획
  • 재난 계획, 비상 대책 계획, 진행 보고서, 테스트 결과 등

📍 기술 리뷰

• 프로젝트의 기술적 상태를 확인하는 과정
• 검토 대상: 요구사항 명세서, 테스트 문서, 유지보수 매뉴얼, 설치 절차 등

📍 인스펙션 (기술적 리스크)

• 가장 형식적인 리뷰 방식
• 참여자: 주재자, 작성자, 낭독자, 기록자, 검토자
• 절차:
  1. 리뷰 계획
  2. 인스펙션 절차 개요 설명
  3. 작업물 개요 설명
  4. 준비
  5. 검토회의
  6. 재작업
  7. 후속작업

📍 워크쓰루 (비형식적 검토)

• 작성자가 직접 작업물을 설명하며 결함을 검출하는 방식
• 작성자가 회의 주재자, 기록자 역할을 수행

📍 감사 (Audit)

• 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하는지 평가
• 비준수 사항을 식별하여 교정 활동 요구 보고서 작성

---

🔹 정적 분석 (Static Analysis)

• 자동화 도구를 활용하여 코드 품질을 분석
• 코딩 표준 준수 여부 및 코드 복잡도를 측정

📍 주요 분석 기법

1. 코딩 표준 (Coding Standard): 일관된 코드 스타일 유지
2. 순환 복잡도 (Cyclomatic Complexity)
   • 공식: 분기 노드 + 1 = 간선 개수 - 노드 개수 + 2
   • McCabe의 복잡도 분석법이 가장 널리 사용됨
3. 자료 흐름 분석 (Data Flow Analysis)
   • 정의(d), 사용(u), 무효화(k) 관계 분석
   • 심각한 결함: ku (무효화된 데이터가 사용됨)

패턴	설명
~d	처음 정의됨 (문제 없음)
du	define-use (문제 없음)
dk	define-kill (잠재적 결함, 사용되지 않음)
~u	처음 사용됨 (잠재적 결함, 정의 없이 사용)
ku	kill-use (심각한 결함, 무효화 후 사용)
dd	define-define (잠재적 결함, 중복 정의)
kk	kill-kill (잠재적 결함)

---

🔹 동적 테스트 (Dynamic Testing)

• 테스트 대상을 실행하여 결함을 찾는 방법 (Test Case 기반 테스트)

📍 구조 기반 테스팅

• 화이트박스 테스트(White-Box Testing) / 글래스 박스 테스트(Glass-Box Testing)
• 제어 흐름 및 자료 흐름을 이용하여 테스트 케이스 설계

📍 문장 테스팅 (Statement Testing)

• 모든 문장을 최소 한 번 실행하도록 설계
• 문장 커버리지(Statement Coverage) 측정 가능

📍 결정 테스팅 ()

• 프로그램 상에 나타난 모든 결정문의 결과가 참이 되는 경우와 거짓이 되는 경우를 최소 한 번 실행 하도록 함

• 결정 커버리지

  

📍 조건 테스팅 (Condition Testing)

• 모든 조건이 True, False를 최소 한 번 실행하도록 테스트

• 조건 커버리지 (Condition Coverage) 적용

  

📍 조건/결정 테스팅 (Condition/Decision Testing)

• 결정 테스트 + 조건 테스트를 함께 수행

• 변경 조건/결정 커버리지(MC/DC) 포함

  

📍 다중 조건 테스팅

• 결정이 가질 수 있는 경우뿐 아니라 결정을 구성하는 기본 조건들이 가질 수 있는 모든 가능한 조합까지 검증
• 프로그램의 결정들에 사용된 모든 조건의 조합을 테스트할 수 있는 입력 데이터를 테스트 케이스로 선정

---

🔹 상태 전이 테스팅 (State Transition Testing)

• 시스템을 상태 전이도로 모델링하고 테스트 케이스를 설계하는 방법

📍 상태 전이 테스팅 종류

유형	설명
상태 테스트	모든 상태를 최소 한 번 방문
단일 전이 테스트	모든 유효한 상태 전이를 최소 한 번 방문
All Transition Test	유효한 전이 + 유효하지 않은 전이까지 포함하여 최소 한 번 방문
다중 전이 테스트	N+1개의 전이 시퀀스를 최소 한 번 방문

---

🔹 경험 기반 테스트 (Experience-Based Testing)

📍 오류 추정 (Error Guessing)

• 테스터의 경험, 직관, 기술 능력을 활용하여 결함을 찾는 기법
• 공식적인 기법과 함께 사용해야 효과적

📍 탐색적 테스트 (Exploratory Testing)

• 사전에 테스트 케이스를 명확하게 정의하지 않고 수행
• 테스터의 경험과 직관을 활용하여 테스트
• 타임 박싱(Time Boxing) 기법 사용 (60~120분 테스트 집중)
• 테스트 차터(Test Charter) 기반으로 테스트 수행

---

🔹 위험 기반 테스트 (Risk-Based Testing)

• 소프트웨어 요구사항 명세서 기반으로 주요 기능(feature) 분석
• 긴급성, 심각성, 발생 가능성을 고려하여 위험도를 산정
  • 긴급성(Urgency)
  • 심각성(Severity)
  • 발생 가능성(Likelihood)

📍 테스트 강도 결정 기준

강도 수준	설명
고강도(High Intensity)	가장 위험한 기능을 집중 테스트
균형적(Balanced Testing)	일반적인 기능을 테스트
부가적(Additional Testing)	추가적으로 점검할 기능 테스트
결함 보고(Bug Reporting)	발생한 결함을 추적 및 보고

---

🎯 정리

• 정적 테스트: 코드 실행 없이 오류 탐색 → 리뷰, 인스펙션, 워크쓰루, 감사
• 정적 분석: 자동화 도구로 코드 복잡도 및 데이터 흐름 분석
• 동적 테스트: 실행을 통해 결함 탐색 → 화이트박스 테스트, 문장/조건/결정 테스팅
• 상태 전이 테스팅: 상태 및 전이 경로를 고려한 테스트 설계
• 오류 추정: 경험을 활용한 테스트 (공식적인 기법과 함께 사용해야 효과적)
• 탐색적 테스트: 사전 설계 없이 테스터의 경험과 직관을 활용하여 테스트
• 위험 기반 테스트: 기능별 위험도를 평가하여 테스트 강도를 결정