Brain436. 테스트 오라클 (Test Oracle)
⚠️ 이 문서는 테스터가 프로그램에 특정 입력값을 넣고 결과를 얻어냈을 때, "그 결과가 진짜로 맞는 결과인지, 아니면 틀린 버그인지"를 확신을 가지고 판정(Pass/Fail)할 수 있게 해주는 **절대적인 '정답지' 혹은 '판단 기준'**인 테스트 오라클을 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 고대 그리스의 '신탁(Oracle)'에서 유래한 말로, 테스트 오라클은 테스트의 결괏값이 참인지 거짓인지를 판단하기 위해 사전에 정의된 **'미리 알고 있는 정답(Expected Result)'**을 의미한다.
- 가치: 아무리 테스트 케이스를 1만 개 만들어도, 그 테스트를 돌려서 나온 결과가 맞는 건지 틀린 건지 대조해 볼 '정답지'가 없다면 그 테스트는 무용지물이다. 오라클은 테스트 자동화(Assert)의 심장이다.
- 기술 체계: 완벽한 정답을 다 만들어두는 참(True) 오라클, 샘플 몇 개만 확인하는 샘플링(Sampling) 오라클, 특정 조건(예: 앱이 뻗지 않음)만 만족하면 통과시키는 휴리스틱/일관성(Heuristic/Consistent) 오라클 등으로 나뉜다.
Ⅰ. 개요: 정답 없는 시험지 (Context & Necessity)
우리가 계산기 앱을 테스트한다고 가정해 보자.
- 입력(Input):
5 + 3 - 결과(Output):
8
이때 테스터는 어떻게 결과가 정상(Pass)이라고 판정했을까?
테스터의 머릿속에 이미 5+3=8이라는 **정답지(Expected Result)**가 있었기 때문이다. 이 정답지가 바로 **테스트 오라클(Test Oracle)**이다.
그런데 내비게이션 앱을 테스트한다고 치자.
- 입력: "서울역에서 부산 해운대까지 가는 가장 빠른 길"
- 결과: "서해안 고속도로를 타고 돌아가는 길" (응?)
이 결과가 진짜로 가장 빠른 길인지 버그인지 테스터가 알 수 있을까? 없다! 실시간 교통상황과 복잡한 알고리즘이 얽혀있기 때문에 인간의 머리로는 완벽한 '정답지(오라클)'를 미리 만들어둘 수가 없다. 이것을 소프트웨어 공학에서는 **오라클 문제(Oracle Problem)**라고 부른다.
📢 섹션 요약 비유: 수능 시험을 치고 났는데 평가원에서 정답지(오라클)를 안 나눠줬습니다. 학생이 1번 문제에 3번이라고 체크(결과)를 했지만, 채점할 정답지가 없으니 자기가 100점인지 0점(버그)인지 영원히 알 수 없는 막막한 상태가 됩니다.
Ⅱ. 테스트 오라클의 4가지 유형 (면접 빈출)
완벽한 정답지(오라클)를 만들 수 있다면 좋겠지만, 현실에서는 시간과 비용의 한계 때문에 4가지 수준의 타협안을 쓴다.
1. 참 오라클 (True Oracle)
- 개념: 세상의 모든 입력값에 대한 완벽한 정답(결괏값)을 다 알고 있는 신적인 상태.
- 적용: 항공기, 우주선, 은행 시스템 등 생명과 전 재산이 달린 미션 크리티컬(Mission Critical) 시스템에 엄청난 비용을 들여 구축한다. 전수 테스트가 가능하다.
2. 샘플링 오라클 (Sampling Oracle)
- 개념: 수만 개의 입력값 중, 대표적인 몇 개(샘플)만 정답지를 만들어 놓고 검사하는 현실적인 타협안.
- 적용: 대다수의 일반적인 비즈니스 소프트웨어에서 쓴다. 동등 분할이나 경곗값 분석으로 뽑은 딱 10개의 입력값에 대해서만 정답(오라클)을 미리 적어두고 검사한다.
3. 휴리스틱 오라클 (Heuristic Oracle)
- 개념: 샘플링 오라클로 10개만 정확히 검사하고, 나머지 입력값들은 "음.. 이 정도 값이 나왔으면 대충 맞겠지 뭐"라며 테스터의 경험(Heuristic)과 직관으로 정답을 유추하는 방식.
- 적용: 오라클 문제가 발생하는 복잡한 시스템이나, 시간적 압박이 심할 때 사람이 직접 눈으로 보며 "결과가 그럴싸한지" 추정한다.
4. 일관성 검사 오라클 (Consistent Oracle)
- 개념: "정답이 뭔진 나도 모르겠고, 어쨌든 어제 코드 고치기 전이랑 똑같이만 나오면 정상이야!"라고 판단하는 방식.
- 적용: **회귀 테스트(Regression Test)**에서 완벽하게 쓰인다. 과거 버전의 실행 결과 자체를 몽땅 캡처해 두고, 새 버전의 결과와 1픽셀이라도 다르면 에러(False)를 뿜게 만든다.
┌─────────────────────────────────────────────────────────────────────────────┐
│ 테스트 오라클(Test Oracle)의 정답지 비교 시각화 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 👑 [ 참 오라클 (True) ] : 100% 엑셀 정답지 구비 완료 │
│ "입력 1~1000까지의 모든 정답을 다 알고 있다! 완벽 채점!" │
│ │
│ 📊 [ 샘플링 오라클 (Sampling) ] : 중간고사 기출문제 10개만 구비 │
│ "입력 1, 50, 100 세 개만 정답 알고 있음. 나머지는 몰루~" │
│ │
│ 🤔 [ 휴리스틱 오라클 (Heuristic) ] : 눈치껏 채점하기 │
│ "10은 정답지 있어서 맞음! 15는.. 뭐 대충 근처 값 나왔네. 통과!" │
│ │
│ 📸 [ 일관성 오라클 (Consistent) ] : 어제 얼굴이랑 똑같은지만 봄 │
│ "정답은 나도 모르고, 어제 찍어둔 스크린샷이랑 오늘이랑 똑같네. 합격!" │
└─────────────────────────────────────────────────────────────────────────────┘
Ⅲ. 오라클 자동화와 단위 테스트 프레임워크
우리가 매일 쓰는 단위 테스트 프레임워크(JUnit 등)의 핵심이 바로 이 '테스트 오라클'을 코드로 자동화해 둔 것이다.
int result = calc.add(5, 3);
assertEquals(8, result); // <-- 8이 바로 '테스트 오라클(정답)'이다!
이 assertEquals(오라클, 실제결과) 함수가 없다면 자동화 테스트는 불가능하다. 기계는 스스로 정답을 생각해 낼 지능이 없기 때문이다. 따라서 테스터(개발자)의 가장 위대한 역할 중 하나는, 복잡다단한 요구사항 명세서를 읽고 프로그램이 뱉어내야 할 정확한 '참 오라클(True Oracle)'을 논리적으로 계산하여 컴퓨터에게 입력해 주는 것이다.
Ⅳ. 결론
"기준이 없는 테스트는 단순한 소모적 클릭질에 불과하다." 테스트 오라클(Test Oracle)은 테스트 활동의 혼을 불어넣는 잣대다. 우리가 시스템을 테스트한다는 것은 결국 "내가 기대하는 세계(Expected)"와 "컴퓨터가 보여주는 현실의 세계(Actual)"를 대조하는 숭고한 비교 철학이다. 오라클이 모호하거나(Heuristic) 아예 존재하지 않는다면(Oracle Problem), 그 어떤 화려한 자동화 툴과 100%의 커버리지도 모래성에 불과하다. 확실한 오라클을 확보하는 것, 그것이 테스팅의 가장 첫 번째 조건이자 가장 마지막 목표다.
📌 관련 개념 맵
- 전제되는 개념: 예상 결과 (Expected Result), 단언문 (Assertion - xUnit 프레임워크)
- 테스트 기법: 회귀 테스트 (Regression Test - 일관성 오라클 사용)
- 어려운 점: 오라클 문제 (Oracle Problem - 정답을 구하기 힘들거나 불가능한 상황)
- 오라클의 종류: 참(True), 샘플링(Sampling), 휴리스틱(Heuristic), 일관성(Consistent)
👶 어린이를 위한 3줄 비유 설명
- 내가 동생한테 "5 더하기 3이 뭐야?"라고 퀴즈를 냈어요. 동생이 "8!"이라고 대답했어요.
- 내가 동생의 대답이 맞는지 틀린지 채점하려면, 내 머릿속에 미리 "정답은 8이야"라는 정답지가 있어야만 하겠죠?
- 소프트웨어를 검사할 때도 똑같이 "이 버튼을 누르면 이 화면이 나와야 해!"라고 미리 정해놓은 완벽한 정답지가 필요한데, 이걸 멋진 말로 테스트 오라클이라고 한답니다!