소프트웨어 테스트 인프라와 결과 관리 용어
테스트 기반부터 테스트 리포트까지, 테스트 설계·실행 환경·드라이버·스텁·인시던트 관리에 쓰이는 핵심 용어를 정리한다.
2026-08-14 · 최초 발행 2026-04-17
테스트는 설계 산출물에서 시작된다
테스트는 실행 단계에서만 만들어지지 않는다. 요구사항 정의서, 설계 사양서, 비즈니스 로직, 코드처럼 검증의 기준이 되는 산출물부터 정리되어야 테스트 범위와 기대 결과를 일관되게 다룰 수 있다.
테스트 기반 (Test Basis)
테스트 기반은 테스트 케이스 설계의 근거가 되는 산출물 전체를 가리킨다. 품질 관리자는 이를 분석해 테스트 조건(Test Conditions)을 만들고, 그 과정에서 요구사항의 모호함이나 누락을 찾아내는 정적 테스트 효과도 얻을 수 있다.
테스트 케이스 (Test Case)
테스트 케이스는 특정 프로그램 경로 또는 요구사항 충족 여부를 확인하기 위한 입력 값, 실행 조건, 예상 결과의 집합이다. 수행자가 달라져도 같은 결과를 얻을 수 있도록 구체적으로 작성해야 하며, 요구사항과의 추적성(Traceability)도 확보되어야 한다.
테스트 스위트 (Test Suite)
테스트 스위트는 관련된 테스트 케이스를 논리적으로 묶어 관리하는 단위다. 모듈, 기능, 시스템 전체처럼 목적에 따라 범위를 정할 수 있으며, 회귀 테스트 스위트나 연기 테스트(Smoke Test) 스위트로 나누어 실행하기도 한다.
테스트 스크립트 (Test Script)
테스트 스크립트는 실행 절차를 구체화한 문서 또는 자동화 도구가 수행할 수 있는 코드다. 수동 테스트에서는 작업 순서를 담은 매뉴얼이 되고, 자동화 테스트에서는 파이썬이나 자바스크립트 같은 언어로 작성된 실행 코드가 된다.
실행 조건을 갖추는 테스트 베드와 하네스
테스트 결과는 대상 소프트웨어뿐 아니라 그것이 동작한 환경과 실행 방식의 영향을 받는다. 환경을 재현하고 실행 결과를 모으는 체계가 필요한 이유다.
테스트 베드 (Test Bed)
테스트 베드는 테스트가 실행되는 물리적 환경이다. 서버, 네트워크 장비, 운영체제, 데이터베이스처럼 소프트웨어 실행에 필요한 하드웨어와 소프트웨어 구성을 포함한다. 운영 환경과 최대한 비슷하게 구성하면 환경 차이에서 비롯되는 결함을 더 일찍 찾는 데 유리하다.
테스트 대상 (Test Target)
테스트 대상은 검증하려는 소프트웨어 자체를 뜻한다. 전체 시스템일 수도 있고, 특정 컴포넌트나 라이브러리일 수도 있다. 테스트 전략에 따라 대상의 범위와 경계를 분명히 설정해야 한다.
테스트 하네스 (Test Harness)
테스트 하네스는 테스트 실행 자동화와 결과 수집에 필요한 프레임워크 및 도구의 묶음이다. 테스트 실행기(Test Runner), 결과 분석기, 드라이버와 스텁까지 포괄하며, 일관된 실행 결과를 확보하고 테스트 인력을 효율적으로 운용하는 기반이 된다.
아직 준비되지 않은 모듈을 다루는 방법
단위 테스트나 통합 테스트에서는 의존 모듈이 아직 개발되지 않았거나, 특정 동작을 통제해야 하는 경우가 있다. 이때 드라이버와 스텁이 테스트 대상 주변을 대신 구성한다.
테스트 드라이버 (Test Driver)
테스트 드라이버는 상위 모듈 역할을 대신하는 하위 모듈 테스트용 가제(Dummy) 소프트웨어다. 테스트 대상에 입력을 전달하고 실행 결과를 출력한다. 상향식(Bottom-Up) 통합 테스트에서 필수적으로 사용되며, 하향식(Top-Down) 통합 테스트보다 이 방식과 밀접하다.
테스트 스텁 (Test Stub)
테스트 스텁은 하위 모듈의 동작을 흉내 내는 프로그램이다. 테스트 대상이 호출하는 하위 컴포넌트가 준비되지 않았을 때, 미리 정의한 값을 반환하도록 만든 단순한 코드 조각이다. 하향식(Top-Down) 통합 테스트에서 주로 사용한다.
실행 기록은 결함 관리와 배포 판단으로 이어진다
테스트가 끝난 뒤에는 무엇이 실행됐고, 어떤 차이가 발견됐으며, 남은 위험이 무엇인지 남겨야 한다. 이 기록이 결함 추적과 배포 여부 판단의 근거가 된다.
테스트 로그 (Test Log)
테스트 로그는 실행 중 발생한 이벤트를 시간 순서대로 기록한 자료다. 실행된 테스트 케이스, 실행 시점, 출력 메시지 등을 상세히 남겨 결함 분석의 단서로 활용한다.
인시던트 리포트 (Incident Report)
예상 결과와 실제 결과가 다르면 이를 인시던트(Incident)로 정의하고 보고서를 작성한다. 인시던트에는 단순한 버그뿐 아니라 환경 설정 오류, 요구사항 오해 등 비정상적인 모든 상황이 포함된다. 결함 관리 시스템(BTS)을 통해 추적 관리한다.
테스트 리포트 (Test Report)
테스트 리포트는 정해진 테스트 수행이 끝난 뒤 작성하는 요약 보고서다. 테스트 목적 달성 여부, 통과율, 미해결 결함 현황, 품질 리스크를 종합적으로 분석해 소프트웨어 배포 여부를 결정하는 의사결정 자료로 사용한다.
테스트 기반에서 출발한 검증은 테스트 케이스와 스위트로 구체화되고, 테스트 베드와 하네스 위에서 실행된다. 드라이버와 스텁은 의존성을 통제하는 데 쓰이며, 로그와 리포트는 그 결과를 품질 판단으로 연결한다. 용어의 경계를 맞춰 두면 팀 내 의사소통 비용을 줄이고 테스트 활동의 책임 범위도 선명하게 만들 수 있다.
Sources
- ISO/IEC/IEEE 29119 Software Testing Standard
- ISTQB (International Software Testing Qualifications Board) Syllabus
- 정보관리기술사 소프트웨어 공학 도메인 지식 체계
- 소프트웨어 테스트 전문가(CSTS) 가이드라인