[Software Engineering] RBT, TDD, Test Coverage

Risk-based Testing (RBT)

1. What is Risk?

 

• 미래에 부정적인 결과를 초래할 수 있는 요소로, 일반적으로 영향(Impact)과 발생 가능성(Likelihood)으로 표현됨.

2. Risk-based Testing

 

• 위험 식별 (Identify Risks)
  • 시스템의 어떤 부분에 위험이 있는지 식별
  • 위험 요소: 시스템 복잡도, 새로운 기술 사용, 부족한 비즈니스 지식, 코드 품질 등
  • 브레인스토밍 기법을 활용하여 최대 35개의 위험 요소 식별 가능
• 위험 분석 (Analyze Risks)
  • 위험 점수 계산: 위험 = 영향(Impact) × 발생 가능성(Likelihood)
  • 발생 가능성을 결정하는 요소:
    • 복잡성, 재사용성, 인터페이스 개수, 크기, 기술, 개발팀의 경험 수준
  • 영향도를 결정하는 요소:
    • 사용자 중요도, 재정적 피해, 안전성, 사용 빈도, 외부 가시성, 수정 비용
• 테스트 설계 및 수행 (Build and Perform Tests)
  • 위험 분석 결과를 바탕으로 우선순위가 높은 영역을 집중적으로 테스트
• 모니터링 및 보고 (Monitor and Report)
  • 지속적인 모니터링과 테스트 진행 상황을 보고

3. Risk Matrix

 

위험을 발생 가능성과 영향도를 기준으로 분류하여 테스트 전략을 수립함.

• STA (Severe Test Area): 집중 테스트 필요
• STTA (Strong Test Area): 강한 테스트 필요
• ITA (Intensive Test Area): 집중 테스트 필요
• FTA (Fundamental Test Area): 기본 테스트 필요

 

 

Test-Driven Development (TDD)

 

1. What is TDD?

 

• TDD는 테스트를 먼저 작성한 후 개발을 수행하는 기법
• TDD는 단순한 설계를 장려하고 개발자의 신뢰감을 높임.

2. TDD Cycle

 

실패하는 테스트 작성 -> 코드를 작성하여 테스트 통과 -> 코드 리팩토링

 

3. Requirement

 

• TDD는 자동화된 단위 테스트를 먼저 작성하여 코드 요구사항을 정의함.
• 일반적으로 xUnit 같은 테스트 프레임워크를 활용하여 테스트 수행.

 

Test Coverage

 

1. Test Coverage

 

• 테스트 커버리지는 테스트 수행 범위를 나타내는 측정 값
• 일반적으로 퍼센트(%)로 표현되며, 일정 수준의 커버리지를 목표로 테스트 진행

2. Requirements Test Coverage

 

• 소프트웨어 요구사항을 기준으로 테스트를 수행하는 방식
• 사용자의 입장에서 테스트를 수행하기 때문에 기능 확인과 검증이 가능
• 그러나 요구사항 기반 테스트만으로는 코드 내 숨겨진 결함을 발견하기 어려움

3. Structural Test Coverage

 

• 코드의 구조적 요소를 기반으로 한 테스트
• 주로 제어 흐름(Control Flow) 분석을 통해 커버리지 평가

4. Types of Coverage

• 문장 커버리지(Statement Coverage)
  • 모든 코드 문장이 최소 한 번 실행되는지 확인
  • 단점: 논리적인 결함을 모두 탐지하지 못할 가능성

• 결정 커버리지(Decision Coverage)
  • 각 분기문(if, while 등)이 참과 거짓을 최소 한 번 실행하는지 확인
  • 단점: 특정 조건의 조합을 확인하지 않음 (if(A or B)라면 B와 상관 없이 A에 따라서 True/False가 결정된다.)

 

• 조건 커버리지(Condition Coverage)
  • 각 개별 조건이 참과 거짓을 최소 한 번 실행하는지 확인 (if(A or B)에서 테스트 케이스 (A: T, B: F), (A: F, B: T)가 CC를 만족함)
  • 단점: 전체 조건 조합을 검증하지 않음
• 조건/결정 커버리지(C/DC)
  • 결정 커버리지 + 조건 커버리지
  • (A: T, B: T), (A: F, B: F)는 if(A or B)를 toggle하는 테스트 케이스이긴 하지만 if(A and B)에 대한 테스트 케이스와 구분할 수 없다.
  • Test case가 Condition을 toggle할 수 있고 각 개별 조건이 참과 거짓을 최소 한 번 실행하는지 확인을 하지만, 각 개별 조건이 전체 결정 결과에 독립적으로 영향을 미치는 지 확인할 수 없다.
• 수정된 조건/결정 커버리지(MC/DC)
  • 각 개별 조건이 전체 결정 결과에 독립적으로 영향을 미치는지 테스트
  • (A: T, B: F), (A: F, B: T), (A: F, B: F)는 각 개별 조건이 if(A or B)에 독립적으로 영향을 미치는 지 확인할 수 있다.
  • Test case가 Condition을 toggle할 수 있고 각 개별 조건이 참과 거짓을 최소 한 번 실행하면서, 각 개별 조건이 전체 결정 결과에 독립적으로 영향을 미치는지 까지 확인할 수 있다.
  • n개의 개별 조건이 존재할 때, 최소 n + 1개의 test case를 선정해야 한다.
• 다중 조건 커버리지(MCC)
  • 모든 조건 조합을 테스트하는 가장 강력한 커버리지 기준
  • 단점: 테스트 케이스 수가 기하급수적으로 증가하여 현실적으로 어렵다.
  • n개의 개별 조건이 존재할 때, 최소 2n개 이상의 test case를 선정해야 한다.