소프트웨어 테스트는 용어가 비슷해 한 표를 통째로 외우기 쉽습니다. 하지만 문제를 풀 때는 무엇을 근거로 테스트를 설계하는지, 어느 범위에서 수행하는지, 어떤 항목을 얼마나 실행했는지를 각각 구분해야 합니다.
화이트박스와 블랙박스는 테스트 설계 근거로 나눕니다
블랙박스는 동적 테스트와 같은 말이 아닙니다. 화이트박스도 프로그램을 실행해 결과를 확인할 수 있습니다. “내부를 보느냐”보다 “테스트 케이스를 무엇에서 도출했느냐”를 먼저 보세요.
단위·통합·시스템·인수는 검사 범위와 목적을 봅니다
- 단위함수·클래스·모듈 같은 개별 구성요소를 검사하는가
- 통합구성요소나 시스템 사이의 인터페이스와 상호작용을 검사하는가
- 시스템완성된 시스템 전체가 요구사항을 만족하는지 검사하는가
- 인수사용자·고객의 요구와 운영 준비 여부를 확인하는가
커버리지는 분모와 충족 조건을 먼저 씁니다
커버리지 비율을 계산할 때는 전체 대상 수를 분모, 실행하거나 충족한 대상 수를 분자로 둡니다. 테스트 케이스 수가 많다는 사실만으로 높은 커버리지가 보장되지는 않습니다. 구조 기반 테스트와 커버리지 기준 원문근거 원문 을 함께 확인하세요.
결정 커버리지와 조건 커버리지를 분리하기
결정식이 A && B일 때 테스트가 (A=true, B=true), (A=false, B=true) 두 개뿐이다. 결정 커버리지와 조건 커버리지는 충족되는가?
테스트가 두 개이고 참·거짓이 있으므로 모두 100%이다.
전체 결정 결과는 true와 false가 각각 한 번 발생해 결정 커버리지는 충족한다. A는 true·false를 모두 가졌지만 B는 true만 가졌으므로 조건 커버리지는 충족하지 않는다.
- 01결정 결과 계산
각 테스트에서 A && B 전체 결과가 참인지 거짓인지 적습니다.
- 02개별 조건 표시
A와 B 각각이 참·거짓을 모두 가졌는지 별도 표로 확인합니다.
- 03분모를 따로 두기
결정 결과와 개별 조건 값의 전체 대상을 같은 분모로 섞지 않습니다.
판별 포인트테스트 케이스 수가 아니라 어떤 결정 결과와 조건 값이 실제로 나타났는지가 커버리지를 결정합니다.
정적 테스트는 실행하지 않고 작업 산출물을 확인합니다
리뷰와 정적 분석은 소프트웨어를 실행하지 않고 요구사항, 설계, 코드 같은 작업 산출물을 검사합니다. 동적 테스트는 실행되는 소프트웨어에 입력을 주고 실제 결과를 확인합니다. 정적 분석 도구가 코드를 다룬다고 해서 동적 테스트가 되는 것은 아닙니다.
서술 답안은 분류명 뒤에 판단 근거를 붙입니다
“블랙박스 테스트”만 쓰지 말고 “내부 구조를 보지 않고 명세의 입력과 기대 결과에서 테스트 케이스를 도출한다”처럼 구별 기준을 한 문장으로 붙이세요. 커버리지를 묻는 문제는 정의와 계산 대상까지 함께 쓰면 표현이 흔들리지 않습니다.
테스트 용어처럼 비슷한 개념을 구별하는 연습은 정보처리기사 실기 단답형 암기법과 함께 보면 좋습니다.