테스트 설계는 시나리오 오라클 범위와 위험을 별도 축으로 다룬다
테스트를 설명하는 네 가지 질문
테스트를 하나의 상호 배타적인 종류 목록으로 만들기 전에 다음 질문을 별도 축으로 다룬다.
- 시나리오: 정상 수용, 계약 거부, 장애·손상 방어 중 무엇을 겪는가?
- 오라클: 명시적 example·Golden 기대값, 계약 의미 비교, 속성·불변식, differential 중 무엇으로 옳음을 판정하는가?
- 범위: unit, component, integration, 경계 계약, end-to-end 중 어디까지 실행하는가?
- 위험: 경계값, 상태 전이, 복원력, 호환성, 동시성, 보안, 자원 한계 중 무엇을 막는가?
사례를 공급하는 방식과 옳음을 판정하는 기준
입력 생성 방식도 이 판정들과 구분한다. parametrize, property-based generation과 fuzzing은 사례를 공급하는 방식이며, 생성된 입력을 수용·거부·방어 중 어떻게 판정할지는 오라클과 계약이 별도로 정한다. Golden Dataset은 보통 입력과 기대값을 보존하는 데이터·오라클 역할이고, unit은 실행 범위이므로 둘을 같은 분류축에 놓지 않는다.
회귀 보호와 결함 탐색의 목적
테스트의 회귀 보호와 결함 탐색 - Yosef K는 테스트가 변경의 협의 경계를 만드는 역할을 강조한다. 이 관점을 테스트의 목적을 묻는 질문으로 연결한다. 선택한 행동의 재발 방지와 아직 드러나지 않은 결함 탐색은 서로 보완하며, 단위·통합이라는 실행 범위만으로 어느 목적을 수행했는지 정해지지 않는다.
Hypothesis의 예제는 작은 함수에도 생성 입력을 적용한다. 생성기가 얼마나 다양한 입력을 만들었는지, 속성이나 참조값이 옳음을 얼마나 잘 판정하는지, 실제 의존성을 어디까지 실행했는지는 각각 확인한다.
실패 입력을 발견하면 재현 조건과 함께 보존하고 회귀 사례로 검토한다. 명시적 사례의 보존은 일시적인 예제 DB나 버전 의존 재현 blob과 구분한다. 고정 seed만으로 외부 상태·스레드 순서·네트워크 시점이 통제되지는 않는다. 비결정성의 원인도 함께 확인한다.
2026-09-20 원문 및 위 공식 문서를 대조한 보강이다. 생성 검사의 상시 실행이나 모든 조합의 전수를 요구하지 않는다.
입력 선택 기법과 커버리지
동등 분할·경계값·결정표·상태 전이는 어떤 사례를 고를지 돕는다. 사례를 골랐다는 사실은 기대 결과가 옳거나 외부 의존성까지 실행됐다는 뜻이 아니다.
구문·분기 커버리지는 정한 코드 요소를 실행한 정도다. 100%라도 특정 데이터·경로의 결함이나 구현에서 빠진 요구를 놓칠 수 있으므로 오라클과 요구사항의 연결을 별도로 확인한다. 위험에 맞는 기법을 고르며 모든 조합을 채우는 목표로 쓰지 않는다.
탐색적 테스트도 목표·시간 범위·발견 기록을 둘 수 있다. 명세 기반 기법과 함께 사용하며, 비체계적 수동 조작으로 한정하지 않는다.
소프트웨어 분석설계 - WikiDocs의 테스트 기법 설명을 ISTQB v4.0.1 §1.3·4.2–4.4와 대조한 보강이다.
테스트 통과와 잘못된 구현의 구별
현재 구현이 테스트를 통과했다는 사실과, 그 테스트가 의도한 결함을 잡는다는 사실은 다르다. 중요한 회귀 검사의 판별력이 의심스러울 때는 구현 전·수정 전의 의도한 실패를 확인하는 red/green이나, 선택한 잘못된 코드 변형을 기존 검사가 잡는지 확인하는 뮤테이션 검사를 사용할 수 있다. 수집 오류나 환경 장애로 실패한 것은 해당 결함을 검출한 증거가 아니다.
이 검증은 선택한 결함·변형에 대한 증거다. 통과하거나 변형을 검출해도 누락된 요구사항, 기대값 자체의 오류, 대체한 외부 의존성의 성공까지 보장하지 않는다. 검사 수·커버리지·뮤테이션 점수를 높이는 것 자체보다 보호할 행동을 구별하는지가 중요하다. 모든 변경에 뮤테이션 검사를 추가하는 규칙이 아니라 위험과 기존 증거의 공백에 따라 선택하는 방법이다.
AI 코딩의 코드 리뷰와 검증 체계 - 개발자 사례 비교에서 Simon Willison의 red/green 설명과 Uncle Bob의 다층 검증 전략을 비교해 기존 시나리오·오라클·범위·위험 구분에 연결했다. 유명 개발자의 자기보고를 개인 환경에서의 효과나 인간 리뷰 폐지의 근거로 확대하지 않는다.
pytest 한 함수에 모여 보이는 서로 다른 역할
Vigilantis에서는 pytest 한 함수 안에 데이터, fixture, 실행 절차와 assert가 함께 보여 Golden Dataset, 계약 거부와 방어적 단위 테스트가 같은 종류처럼 해석되었다. 이 혼동은 프레임워크나 도메인에 한정되지 않으며, 서로 다른 보장 질문을 한 이름에 합칠 때 반복해서 생길 수 있다.
실제 처리기를 기준으로 삼아도 입력은 별도로 설계한다
공통 에이전트 운영 이관과 사이트 자동 갱신 검증 - 대화와 실행 기록의 사이트 철회 검사에서는 검사기가 나열한 주소만 확인하다가 누락이 반복됐다. 이전 파일·폴더에서 계약보다 넓은 유한 주소 집합을 만들고, 실제 사이트 핸들러가 이전에 응답했지만 새 게시에서 404가 된 주소가 검사 목록에 들어가는지 비교하도록 바꿨다.
그러나 처음의 입력에는 페이지가 비HTML 파일로 바뀌는 경우가 없었다. 이전 x.html이 새 x로 바뀌면 고정 주소는 새 파일로 이어지고 이전 버전 주소는 404가 되는데, 검사기는 둘을 같은 판정으로 처리했다. 실제 핸들러를 오라클로 썼어도 이 입력을 공급하지 않으면 결함을 찾지 못했다. 종류 전환·제거와 같은 이름의 우선순위 충돌을 추가해 두 주소의 판정을 따로 대조했다.
확인 범위도 별개다. 이 테스트는 실제 처리기의 로컬 HTTP 응답과 유한한 주소 계약을 검증하며, 실제 CDN의 캐시·무효화나 모든 인코딩 변형을 실행하지 않는다. 소유한 계약의 입력·판정·실행 범위를 명시하는 사례이며, 모든 테스트에 전수 조합이나 실서비스 재실행을 요구하는 기준은 아니다.
적용 범위와 한계
- 네 축은 테스트를 설명하고 빠진 보장을 찾기 위한 설계 모형이지, 공인된 하나의 표준 분류표나 수학적으로 직교하는 좌표계가 아니다.
- 축은 서로 영향을 줄 수 있다. 예를 들어 외부 장애라는 시나리오는 통합 범위와 복원력 위험을 요구할 수 있지만, 그렇다고 세 판정이 같은 것은 아니다.
- 모든 조합을 채우지 않는다. 테스트 대상이 소유한 책임과 실제 위험에 필요한 조합만 선택한다.
- Golden Dataset, contract test 같은 용어의 세부 범위는 프로젝트 계약에서 다시 정의한다.
승격 원문
- 프로젝트: Vigilantis
- 원문: 테스트의 시나리오 오라클 범위는 별도 축이다
- 확인일: 2026-09-03
근거
- 테스트 분류 검토 - ChatGPT 공유 대화
- ISTQB Certified Tester Foundation Level Syllabus v4.0.1 — 테스트 수준과 테스트 유형을 별도 개념으로 구분한다.
- pytest parametrization과 assertions — 사례 공급과 기대 판정이 프레임워크 안에서 서로 다른 역할임을 확인했다.
- Hypothesis Introduction — 생성된 입력과 그 입력에 적용하는 property가 구분됨을 확인했다.