모든 경우를 테스팅 하는 것은 불가능하다
테스팅 기법들은 적당한 타협점을 찾는 것.
8.2 Black-box Testing
기능적 요구사항에 따라 4단계로 나눌 수 있다.
1) Identity independent testable features
- 명세만 가지고 있는 상태 (코드 x)
2) Identity relevant inputs
3) Derive test case specification
- 조합 나열
4) Generate test cases
- 실제 데이터 정하는 단계
조합 방법
1) 각 선택 조합
2) 모든 조합
3) 페어와이즈 조합 : 각 영역의 값을 다른 영역의 값과 최소한 한번은 짝을 짓는 조합
(테스트케이스를 줄일 수 있음)
(A,B)(A,C)(B,C) 는 각각의 조합을 모두 커버!
ex) A1 : 로그인 ID, A2 : 1st 패스워드, A3 : 2nd 패스워드로 가정
ex) (A,C)의 경우만 보면 (A1,C1),(A1,C2),(A2,C1),(A2,C2) 모든 조합이 포함되어있음
=> 모든 조합에 비해 테스트 케이스 수를 줄이면서도 오류 검출 능력은 사실상 비슷한 경향
(이유: 오류는 모든 입력의 조합에 의해 발생하기 보다 기껏해야 두 입력의 조합으로 발생하기 때문)
- 동등 분할 기법
- 경계값 분석
- 슬라이드 참고
- 18
- 슬라이드 참고
- 원인 결과 그래프
8.3 White-box Testing
Structural testing based on program code
Control-flow Graph
: 프로그램의 실행 흐름을 그려놓은 그래프
Cyclomatic complexity (⭐️ 용어)
: 소스코드의 복잡도를 나타내는 척도
겹치지 않는 기본 경로들을 카운팅 했을 때 값이 클수록 복잡하다고 가정
Test Coverage
Basic path coverage
All-path coverage
Statement coverage : 소스코드 내의 모든 문장이 최소 한번은 실행될 수 있도록 ex) testsuitcase1: {TC2}, testsuitcase2: {TC1, TC2}
Branch (=Decision) coverage : 소스코드 내의 모든 if문을 최소 한 번 실행
p.37 TC1은 Statement이지만 Branch는 아니다. -> False일 때의 경우를 커버해야함!
Condition coverage : 소스코드 내의 if문의 조건에서 가장 작은 단위의 조건을 하나씩 비교
❗️Branch vs Condiiton 구분
Branch : if문의 전체 조건 ex) A>1 && B==0
Condition : if문의 조건에서 더이상 분해할 수 없는 단위 ex) A>1, B==0
🤔 Branch와 Condition coverage 둘다 만족하는 방법은 없을까?
=> Multiple-condition coverage
but, 단점: 비용
🤔 더 나은 방법은 없을까?
=> MC/DC (모두가 해피한 방법)
Multiple condition coverage
MC/DC coverage : (Modified Condition Decision Coverage)
decision 결과가 다르고, 단 하나의 조건만 다른 것이 MC/DC 쌍 ex) p.43 (1st, 2nd) (1st, 3rd) (1st, 5th)
참고)
Unit testing tools
- Junit, CUnit, CPPUnit
- Mocking tools : Mockito, Cmock
- Coverage measurement tools : JaCoCo, Clover
