[소공 수업 정리] Test Techniques white

Code Coverage란?

프로그램의 소스 코드가 얼마만큼 테스트가 되었는가를 나타내는 지표

 

Coverage 측정 기준의 종류

1. All-node (Statement Coverage, Line Coverage, Node Coverage)

개발 소스의 각 라인이 수행되었는지를 확인하는 테스트 커버리지

- 코드의 각 line들이 다 한번씩 실행 되었는가?

 

2. Branch Coverage(Decision Coverage, Edge Coverage)

개발 소스의 각 분기문이 수행되었는지를 확인하는 테스트 커버리지

만약 소스에 if문이 있다고 했을 때 statement coverage는 true 조건 1가지에 대해 coverage 100%가 나올 수 있는 반면에 branch coverage는 if문에 대해 true 조건/ false 조건 각각이 수행되어야 100% 달성할 수 있다. 

- 코드의 분기문들이 최소한 T/F 한번씩 다 실행 되었는가?

- 만약 test case가 두개라면, 각 test case가 절반만 cover하더라도 종합적으로 모든 분기를 커버하도록 하면 된다.

- branch를 다 커버했다는 뜻은 모든 statement를 다 커버했다는 뜻과 같으므로 branch coverage는 statement covarage를 포함한다.

 

 

3. Condition Coverage

개발 소스의 각 분기문내에 존재하는 조건식 - ex) if (a==b or c=3)에서 내부 2개 조건문이 각각 true/false 경우로 수행되었는지를 확인하는 테스트 커버리지

** 최종 if문의 결과가 true였는지 false였는지를 따지지는 않으며, 같은 맥락에서 각 조건식 간의 조합에 대해서도 따지지 X

- 조건문 각각의 조건에 대해 실행 되었는가? 

- 즉 조건문 하나를 구성하는 모든 조건 상태들에 대해서 test가 수행됐는지를 살펴본다.

 

- condition coverage는 branch coverage와 분명한 차이가 존재한다.

- 동일한 test case에 대해 각각 coverage를 계산했지만 결과는 다르다. 즉 서로 반드시 포함관계를 갖지 않음.

 

• 브랜치 커버리지 (Branch Coverage):
  • 브랜치 커버리지는 코드 내의 모든 분기점(branch), 즉 조건문(예: if, else, switch)을 한 번 이상 실행하는 것을 목표로 한다.
  • 예를 들어, if (x > 0)라는 조건문이 있다면, 이 조건이 참일 때와 거짓일 때 두 가지 경우를 모두 실행해야 브랜치 커버리지가 100% 달성된 것
• 컨디션 커버리지 (Condition Coverage):
  • 컨디션 커버리지는 조건문 안에 포함된 각 조건(예: x > 0에서의 x > 0 부분)이 참과 거짓 모두를 실행해야 100%를 달성하는 것
  • if (x > 0 && y < 5)라는 조건이 있을 때, x > 0과 y < 5 각각에 대해 참과 거짓을 모두 실행해야 한다.

 

 

4. MC/DC - Modified Condition / Decision Coverage

Decision coverage, Condition coverage의 미흡점을 상호 보완하여 분기문의 조건문들이 모두 true/false가 test되도록 하면서 최종 if문의 결과도 true/false 각각이 테스트 되도록 하는 커버리지

- multiple condition coverage만 100퍼센트 만족하면 모든 종류의 coverage를 달성할 수 있었다.(강력!!!)

- 딱 한가지 단점이 모든 조합을 커버해야하기에 test case 수가 매우 많아진다. (2^n개)

- 이 절충안이 MC/DC이다. (n+1개 ~ 2n개)

A or B의 경우 ( A and B의 경우도 마찬가지)

- A가 바뀌었을때 결과가 달라지는 케이스, B가 바뀌었을때 결과가 달라지는 케이스에 집중한다.

 

- 이렇게 하면 3개의 테스트 케이스만으로도 의미있는 coverage가 가능

- 즉 하나의 condition이 decision에 영향을 미치는 pair들을 찾고 그것들을 검증하기 위한 test case를 만든다.                     

 

Data-flow based test

실행 경로와 함께 변수들의 data 흐름을 참고하는 기법 (변수들이 실행 됐는지, 안됐는지)

1) C-use (computational use) 

• 조건문을 제외하고 모든 것
• 변수에 값이 정의된 후 그 변수 값을 조건문 제외한 프로그램 문장에서 사용되도록 하는, 프로그램 경로가 적어도 한번은 실행되도록 하는 test

2) P-use (predicate variable use)

• 조건문에서 사용
• 변수에 값이 정의된 후 그 변수 값을 조건문 문장에서 사용되도록 하는, 프로그램 경로가 적어도 한번은 실행되도록

3) All-use

• P-use + C-use                                                                                                                                                                     

Fault Injection ( ex. Mutation Test)

• Mutent M : test 대상 program P에 fault가 삽입된 Program (인위적으로 결함을 만드는 것)
• P와 M의 결과 값을 다르게 하는 입력을 test data로 선정 M(d) != P(d)
  
  • 서로 다른 결과가 나왔다면, mutant M is dead (killed)
• Mutant operator 예시
  • SVR : scalar valiable replacement - 스칼라 변수는 우리가 흔히 사용하는 변수 like integer, float etc.
    •  A = B + D라는 원래 식이 있으면 A, B, D를 하나씩 바꾼 식을 M1, M2, M3
    • kills M2 : M2만 P와 결과가 달랐던 것. 
    • Coverage: Mutant Score = 1/3 ( Mutent 총 개수: 3 중 하나가 kill)
      • K(# of mutants killed) / (m-me), where - m: total # of mutants generated, me: # of equivalent mutants
• 그러나 프로그램 수에 비해 test 해야 하는 mutant 수가 압도적으로 많기에 mutant test 잘 쓰지 않음.
  • # of mutants = O(n^2), where # of statements in P = n
  • 도구 : Mothra, Proteum
•  

 

 

 

 

 

Reference

https://jsdysw.tistory.com/389