테스트 커버리지 (Test Coverage)
쉽게 풀면
교과서 10개 단원 중 시험 범위가 몇 단원인지를 생각해봅시다. 시험 범위가 3단원뿐이라면, 나머지 7단원에 오류가 있어도 시험에서는 절대 드러나지 않습니다. 소프트웨어도 마찬가지입니다. 개발자가 작성한 단위 테스트가 전체 코드 중 몇 퍼센트를 실제로 실행해보는지를 수치로 나타낸 것이 테스트 커버리지입니다. 예를 들어 "커버리지 80%"라면 코드 100줄 중 80줄은 테스트가 한 번이라도 지나가며 확인했고, 나머지 20줄은 한 번도 검증되지 않은 채 남아있다는 뜻입니다.
왜 중요한가
테스트 커버리지는 소프트웨어 품질을 정량적으로 비교할 수 있는 몇 안 되는 지표 중 하나이기 때문에 소프트웨어 공학 논문에서 새로운 테스트 기법의 효과를 입증하는 핵심 척도로 자주 사용됩니다. 자동 테스트 생성, 퍼징(fuzzing), 정적/동적 분석 기법을 제안하는 연구는 대개 기존 방법 대비 커버리지 향상 정도를 실험 결과로 제시하며, 이는 버그 발견 가능성이나 유지보수 안정성을 간접적으로 뒷받침하는 근거로 쓰입니다.
논문에서는 이렇게 쓰입니다
이 문장은 "새로운 방법으로 테스트를 자동 생성했더니, 검증되지 않고 남아있던 코드의 비율이 크게 줄었다"는 뜻입니다.
커버리지에는 여러 종류가 있으며, 어떤 기준으로 측정하느냐에 따라 결과가 다르게 나타날 수 있다는 것을 실증적으로 보여준 문장입니다.
테스트 커버리지 개념이 전통적인 소프트웨어 코드뿐 아니라 딥러닝 모델의 내부 동작을 검증하는 지표로도 확장되어 쓰인다는 것을 보여주는 문장입니다.
조금 더 깊게 보면
테스트 커버리지는 측정 단위에 따라 코드 한 줄이 한 번이라도 실행되었는지를 보는 구문(라인) 커버리지, 조건문의 참·거짓 분기가 모두 실행되었는지를 보는 분기 커버리지, 함수 호출 여부를 보는 함수 커버리지 등으로 나뉘며 요구되는 엄밀함의 수준이 서로 다릅니다. 논문을 읽을 때는 어떤 종류의 커버리지를 측정했는지, 그리고 커버리지 향상이 실제 결함 탐지율 향상으로 이어졌는지를 함께 확인하는 것이 결과를 정확히 해석하는 데 중요합니다.
주의할 점
커버리지 수치가 높다고 해서 코드에 버그가 없다는 뜻은 아닙니다. 테스트가 그 코드를 "지나가기만" 했을 뿐 결과값을 제대로 검증하지 않았을 수도 있기 때문입니다. 따라서 커버리지는 테스트가 얼마나 꼼꼼한지를 보여주는 참고 지표이지, 품질을 보장하는 절대적 증거로 오해해서는 안 됩니다.