📌블랙 박스 테스트
- 소프트웨어의 명세에 기반하여 테스트(코드를 직접 보지 않음)
- 명세서의 기능들을 동작하도록 테스트하는 것이 목적
- 명세에 없는 세부적인 오류는 찾기 힘듬
📖장점
- 도메인에 집중할 수 있다
- 코드가 필요 없다, test case 디자인을 미리 할 수 있다
- 명세에서의 논리적 오류를 찾을 수 있다
- 유닛 테스트나 통합 테스트 모두 적용 가능
📖과정
-
테스트 가능한 특징들을 뽑아낸다
-
해당 특징들의 입력들을 선별
- 입력 요소가 3가지에 각각 정상 3가지/비정상3가지/예외2가지 총 조합의 수 = 18가지
- 입력들의 조합으로 test case 명세서를 만든다
- 18가지 조합의 수 test case
- 명세를 기반으로 구체적인 test case 만든다
📖create/select test case
- Equivalence class partitioning : test case에 그룹을 나누고 각 그룹의 하나의 케이스만 뽑아낸다,
example) 1~100의 input 테스트시 1~50의 그룹1 / 51~100그룹2로 나누고 각 그룹의 대표하는 한가지 case만 추출하여 실제 테스트 - Boundary value analysis : 위에서 정한 그룹의 경계 데이터(1, 49, 52, 99 등)만 뽑아서 테스트
- Model-based testing : state diagram에서 모든 state를 커버하도록 테스트하는 것(이것도 그룹을 나누어서 대표 case를 하나 선별하는 것과 비슷한 느낌)
📖test case 조합 사이트
- 굉장히 다양한 조합 경우의 수의 케이스를 생성, 관리하는 툴
- www.pairwise.org / PICT / TSL generator
📌화이트 박스 테스트
- 코드를 직접 보고 코드 기반으로 테스트
- 코드에 구현된 것들을 동작하도록 테스트하는 것이 목적
📖장점
- test suites(테스트 그룹)를 비교가능 : A테스트그룹이 B테스트그룹을 포함하면서 비용이 비슷하다면? A테스트그룹만 선택함, 이러한 비교가 가능
- 객관적으로 테스트 결과를 확인할 수 있고 자동화 테스트가 가능
📖control flow graph
- 프로그램 제어 흐름을 그래프로 그려서 이 그래프를 커버하도록 테스트 케이스를 설계하는 방법이 존재
- basic path : 시작노드부터 끝노드까지 순회하는 각 경로를 지칭
- cyclomatic complexity : 독립적인 basic path의 개수로 계산하는 복잡도
- 모든 basic path를 커버하는 테스트 케이스를 설계하는 방법
- 4가지 basic path가 존재
📖Test Coverage
- basic path coverage : test suites(tc1, tc2, tc3 ...)가 basic path를 모두 cover할 때
- all path coverage : test suites(tc1, tc2, tc3 ...)가 모든 path 조합을 cover할 때
- statement, branch, condition, multiple condition, MC/DC 등등 존재
- 이러한 test suites들을 서로 포함 관계로 비교가 가능한 것이 특징
✒️statement Coverage
- 모든 코드를 적어도 한번씩 실행하여 cover하는 test suit
- 밑 예에서 TC2는 statement coverage
✒️branch Coverage
- 모든 branch(edge)를 cover하는 테스트 범위
- 밑의 예에서 F-F branch를 커버 + T-T branch를 커버하는 test suit가 branch Coverage
✒️condition Coverage
- 작은 단위의 조건문 까지 모두 cover하는 test suit
- 각 조건문의 T,F를 모두 테스트
✒️branch vs condition
✒️multiple-condition coverage
- 목표 : condition과 branch를 모두 만족하는 test case 디자인하기 방법1
- 각 조건에대한 모든 경우의 수 test suit, 조건이
n개 있으면2^n만큼의 경우의 수가 생김
- 너무 많은 test case
✒️MC/DC coverage
- modified condition, decision coverage
- 목표 : condition과 branch를 모두 만족하는 test case 디자인하기 방법2
MC/DC pair의 개념
if(A and B and C) { ... } 코드 존재,
TC1 : (A,B,C) = (T,T,T) -> outcome=T
TC2 : (A,B,C) = (T,T,F) -> outcome=F
C만 바꿨는데 결과가 바뀌었으므로, C가 결과에 영향을 미침
TC1 와 TC2를 MC/DC pair라 지칭한다 - MC/DC coverage는 이러한 MC/DC pair들을 모두 모아둔 것
- 위에서 C에대해서 MC/DC pair인데 A에대해서, B에대해서 모두 test case를 디자인하면 그것을 MC/DC coverage test suite라 한다
TC1-TC2/TC1-TC3/TC1-TC5라는 MC/DC pair로 MC/DC coverage 만족 최종 test suit = {TC1, TC2, TC3, TC5}
📖Test Coverage 포함 관계 비교
- 큰 원의 test suit를 테스트 했다면, 그에 포함되는 내부의 test suit를 테스트 할 필요는 없음
📌test trend
- 개발자가 직접 본인의 코드를 test하는게 일반적
- TDD 시행
- 테스트 자동화
