기술사 학습노트 | imt-log

기술사 학습노트 › 소프트웨어 공학 › 소프트웨어 테스트

SOFTWARE ENGINEERING · 정보관리기술사 / 컴퓨터시스템응용기술사

소프트웨어 테스트 심화: 테스트 오라클, 화이트박스 커버리지, 고도화 검증 기법 해부

단순한 버그 찾기를 넘어 시스템의 무결성을 수학적/논리적으로 증명하기 위한 화이트박스 커버리지(MC/DC)의 포섭 관계, 참/거짓을 판별하는 테스트 오라클(Test Oracle) 체계, 그리고 오라클 문제를 극복하기 위한 돌연변이(Mutation) 및 메타모픽(Metamorphic) 테스트 기법을 심층 분석한다.

정보관리기술사 컴퓨터시스템응용기술사 소프트웨어테스트 테스트오라클 화이트박스테스트 MCDC 돌연변이테스트 메타모픽테스트 퍼징테스트 카오스엔지니어링

Ⅰ. 소프트웨어 테스트 패러다임의 진화와 심화 검증의 필요성

가. 품질 보증(QA)에서 품질 엔지니어링(QE)으로의 전환

과거의 소프트웨어 테스트가 개발이 끝난 후 결함을 발견하는 사후 적발(Defect Detection) 위주였다면, 현대의 테스트는 개발 초기부터 개입하여 결함을 예방(Shift-Left)하고, 테스트 스위트(Test Suite) 자체의 신뢰성을 검증하는 고도화된 품질 엔지니어링(Quality Engineering) 영역으로 진화하였다. 자율주행, 항공, 의료 등 생명과 직결된 미션 크리티컬(Mission-Critical) 도메인이 증가함에 따라 수학적이고 정형화된 테스트 커버리지 기준이 법적/표준적 요구사항으로 자리 잡고 있다.

나. 테스터의 근본적 딜레마: 오라클 문제(Oracle Problem)

테스트 케이스를 작성하여 시스템에 입력값을 넣었을 때, 시스템이 뱉어낸 결과값이 "정답인지 아닌지"를 어떻게 확신할 수 있는가? 특히 AI/머신러닝 알고리즘이나 구글 검색 엔진처럼 '사전에 완벽한 정답(Expected Result)을 알 수 없는 시스템'을 검증해야 하는 상황을 오라클 문제(Oracle Problem)라고 하며, 이를 극복하기 위한 다양한 고급 휴리스틱 및 메타모픽 기법이 대두되었다.

Ⅱ. 정답 판별의 메커니즘: 테스트 오라클 (Test Oracle)

가. 테스트 오라클의 개념 및 프로세스

테스트 오라클(Test Oracle)은 테스트 수행 결과가 참(Pass)인지 거짓(Fail)인지를 판단하기 위해, 사전에 정의된 참값(Expected Result)을 대입하여 실제 결과(Actual Result)와 비교하는 메커니즘이다.

나. 테스트 오라클의 4대 유형 (4단표)

오라클 유형	명칭 (Keyword)	검증 메커니즘 및 실무 적용 환경
참 오라클 (True Oracle)	모든 입력에 대한 확실한 정답	모든 가능한 테스트 입력값에 대해 기대하는 결과를 수학적으로 명확하게 산출할 수 있는 경우. 항공우주, 원자력 등 치명적 시스템에 제한적으로 사용된다.
샘플링 오라클 (Sampling Oracle)	특정 입력에 대한 샘플 정답	모든 입력값을 확인하는 것은 불가능하므로, 경계값 분석, 동등 분할 등을 통해 선정된 특정 몇몇 입력값에 대해서만 기대 결과를 제공하는 가장 일반적인 실무 오라클이다.
휴리스틱 오라클 (Heuristic Oracle)	직관과 경험에 기반한 추정	샘플링 오라클의 한계를 보완하기 위해, 특정 입력값의 정답은 샘플링으로 확인하고 나머지 값들은 테스터의 경험(휴리스틱)이나 직관에 의존하여 처리하는 방식이다.
일관성 검사 오라클 (Consistent Oracle)	변경 전후의 상태 비교	애플리케이션에 수정(Patch)이 발생했을 때, 변경 전의 실행 결과와 변경 후의 실행 결과가 동일하게(일관성 있게) 유지되는지를 확인한다. 회귀 테스트(Regression Test)에 필수적이다.

Ⅲ. 화이트박스 테스트 커버리지 포섭 관계 (Subsumption Hierarchy)

가. 제어 흐름(Control Flow) 기반 커버리지 계층 구조

화이트박스 테스트는 소스 코드의 내부 논리 구조를 검증한다. 각 커버리지(Coverage) 기준은 상위 계층이 하위 계층의 검증 요건을 포함하는 포섭 관계(Subsumption)를 가진다. 특히 MC/DC는 다중 조건 커버리지의 폭발적인 테스트 케이스 증가를 억제하면서도 높은 신뢰성을 보장하는 핵심 지표이다.

나. 항공/자동차(ISO 26262) 생명주기 필수: MC/DC의 핵심 메커니즘

MC/DC (Modified Condition/Decision Coverage)는 "개별 조건식이 다른 조건식의 결과와 무관하게, 전체 결정(Decision)의 결과에 독립적으로 영향을 미침을 증명"하는 커버리지입니다.
만약 `if (A and B)`라는 구문이 있다면, 다중 조건 커버리지는 $2^2 = 4$개의 테스트 케이스(TT, TF, FT, FF)가 필요하지만, MC/DC는 N+1개인 3개의 케이스(TT, TF, FT)만으로도 A와 B가 전체 결과에 미치는 독립적 영향을 증명할 수 있습니다. DO-178C (항공기 SW) 및 ISO 26262 (자동차 기능안전) 최고 안전 등급에서 의무화된 기준입니다.

Ⅳ. 오라클 문제 극복 및 테스트 품질 향상을 위한 고급 기법

가. 돌연변이 테스트 (Mutation Testing) - 테스트를 테스트하다

내가 만든 테스트 스위트(Test Suite)가 과연 꼼꼼하게 짜여 있는지 어떻게 알 수 있을까? 이를 확인하기 위해 소스 코드의 일부분을 고의로 변경(예: a + b를 a - b로 변형)한 수많은 돌연변이 코드(Mutant)를 생성한다.

• Killed (사살): 기존 테스트 케이스가 돌연변이 코드를 실행했을 때 'Fail'을 띄우면, 테스트 케이스가 결함을 제대로 잡아낸 것이므로 돌연변이를 사살(Killed)했다고 표현한다.
• Survived (생존): 돌연변이 코드를 넣었음에도 테스트 케이스가 'Pass'를 띄우면, 테스트 케이스가 허술하여 결함을 놓친 것이다.
• Mutation Score: (사살된 돌연변이 수 / 전체 유효 돌연변이 수) $\times$ 100. 이 점수가 높을수록 테스트 케이스의 신뢰성이 높음을 수학적으로 증명한다.

나. 메타모픽 테스트 (Metamorphic Testing) - 정답이 없는 AI의 검증

'검색 엔진'이나 '자율 주행 AI'는 입력값에 대한 완벽한 정답(Oracle)을 미리 알 수 없다. 메타모픽 테스트는 정답을 확인하는 대신, 두 개 이상의 입력값 사이에 존재하는 논리적 관계(Metamorphic Relation)가 출력값들 사이에서도 일관되게 유지되는지를 검증한다.

• 예시 (최단 경로 알고리즘): 서울에서 부산까지의 최단 거리가 400km인지 정답(참 오라클)은 모를 수 있다. 그러나 "서울 ➔ 대전 ➔ 부산의 거리 합은, 부산 ➔ 대전 ➔ 서울의 거리 합과 동일해야 한다"는 논리적 관계(MR)를 설정하고, 두 결과가 다르면 알고리즘에 결함이 있다고 판단하는 강력한 검증 기법이다.

다. 퍼즈 테스트 (Fuzzing / Fuzz Testing)

주로 보안 취약점(Buffer Overflow 등)을 찾기 위해 사용된다. 프로그램에 유효하지 않은, 예기치 않은, 무작위의 데이터(Fuzz)를 자동화된 도구로 무한히 입력하여 시스템의 충돌(Crash), 메모리 누수, 예외 처리 실패를 유도하는 블랙박스 기반의 강건성(Robustness) 테스트 기법이다.

Ⅴ. 최신 테스트 패러다임: 시프트 레프트(Shift-Left)와 카오스 엔지니어링

가. TDD와 BDD 기반의 시프트 레프트 (Shift-Left Testing)

결함은 SDLC(소프트웨어 생명주기)의 우측(운영/배포)에서 발견될수록 수정 비용이 기하급수적으로 증가한다. 따라서 테스트 활동을 생명주기의 좌측(요구사항/설계)으로 앞당기는 Shift-Left 철학이 필수가 되었다. 코드를 작성하기 전에 테스트 케이스를 먼저 작성하는 TDD (Test-Driven Development)와, 사용자의 행위(Behavior) 중심으로 기획자와 개발자의 언어를 맞추는 BDD (Behavior-Driven Development)가 CI/CD 파이프라인의 핵심으로 자리 잡았다.

나. 복원력 검증: 카오스 엔지니어링 (Chaos Engineering)

MSA(마이크로서비스 아키텍처) 기반의 거대한 클라우드 환경에서는 국지적인 장애가 전체 시스템의 마비로 이어질 수 있습니다. 카오스 엔지니어링은 넷플릭스의 '카오스 몽키(Chaos Monkey)'처럼 프로덕션(운영) 환경의 서버나 네트워크를 의도적이고 무작위로 다운(Down)시켜, 시스템이 스스로 장애를 격리하고 자동으로 복구(Resilience)하는지를 실험하고 검증하는 최고 난이도의 가용성 테스트 기법입니다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [소프트웨어 공학] 목록