테스트 운영
WBS 의 구현된 항목을 노션에서 「테스트 완료」로 넘기기까지 무엇을 누르고, 무엇이 자동으로 돌고, 어느 지표를 보고 정하는지를 한 장에 모은 페이지입니다. 기준은 개발 서버 배포본(main)과 origin/dev 의 워크플로·판정 코드입니다.
사람이 하는 일자동 실행외부(노션·Studio)주의
한눈에 보기
「테스트 완료」는 사람이 노션에서 고르는 값이 아니라, 개발 서버에서 실제로 실행된 코드를 근거로 워크플로가 바꾸는 값입니다. 사람이 할 일은 개발 서버 화면을 끝까지 눌러 보는 것이고, 나머지(수집·판정·노션 쓰기·사이트 갱신)는 매시와 개발 배포·실서류 회차 뒤에 자동으로 따라옵니다.
1 · 사람
개발 서버 화면을 끝까지 누른다
시험 사건으로 접수 → 분류 → 추출 → 분석 요청 → 요약 → 보고서까지. 로컬 실행은 집계되지 않는다.
2 · 매시 :05
수동(dev) 커버리지 수집
manual-coverage 가 개발 서버 JaCoCo 기록을 덤프해 배포 사이 누적한다. 매일 돌고, 개발 배포 성공·실서류 회차 끝에도 돈다.3 · 수집 직후
화면별 기준 판정 → 노션
notion-wbs-sync 가 「테스트중」 행의 화면이 모두 기준(라인 70% 또는 엔드포인트 전부)을 넘으면 「테스트 완료」로 바꾼다.4 · 같은 시각
문서 사이트 다시 빌드
/tests/ 화면별 「테스트 완료」 칩, /wbs/ 완료 수, /trends/ 추이가 바뀐다.2026-10-20 수집 시점 값 — 현재 값은 /tests/
| 항목 | 값 | 보는 곳 |
|---|---|---|
| 수동(dev) 백엔드 라인 (10/14 이후 배포 7회 누적) | 약 44% (10,662 / 24,157줄) | /tests/ 수동(dev) 모니터링 |
| 수동(dev) 엔드포인트 호출 | 58 / 148 | /tests/ 수동(dev) 모니터링 |
| 테스트 완료 기준을 넘은 화면 (수동 기준) | 7 / 측정 33 | 아래 화면별 현황 · /tests/ 화면별 실행 확인 |
| 개발 서버 시험 사건 (TBD-*) | 10건 — 9건 보고서 초안까지, 1건 추출 실패 | dagent 사건 목록 · 테스트벤치 :3390 |
| 실서류 자동 E2E 테스트셋 | 42건 (돌려 가며 — 빠른 확인 1건, 전체 회귀 3건) | /e2e/ |
화면이 기준을 넘어도 그 화면을 다룬 노션 행이 「테스트중」이고 PR 본문에
커버리지 맵: <화면 id> 줄이 있어야 행이 넘어갑니다. 대부분의 「안 넘어간다」는 이 두 조건에서 걸립니다.테스트 완료까지의 사슬
세 줄기가 노션 판정 한 곳에서 만납니다. 위 줄(노션 상태)은 PR 단계를 따라 자동으로 「테스트중」까지 오고, 가운데 줄(자동 E2E)과 아래 줄(사람의 수동 테스트)이 판정 근거를 댑니다. 근거는 둘 중 하나만 넘으면 되고, 두 실행 기록은 합치지 않습니다.
테스트 완료 판정 조건
판정은 scripts/notion_wbs_sync.py 의 테스트 완료 판정과 docs-site/generators/tests_guide.py 의 화면 계산을 같이 씁니다. 그래서 /tests/ 의 「테스트 완료」 칩과 노션 판정은 같은 기준입니다.
#
조건
정확한 기준
안 맞으면
확인하는 곳
1
행 상태
노션 행이 테스트중이고
PR 열이 비어 있지 않다판정 대상이 아니다. 코딩완료에서 멈춰 있으면 아직 main 배포 전이다
노션 WBS ·
/wbs/2
판정 화면
그 행의 모든 PR 본문
커버리지 맵: 줄에 적힌 화면의 합집합줄이 없거나
없음·모르는 id 면 자동으로 넘기지 않는다PR 본문
3
수동(dev) 기준
화면 행 백엔드 클래스의 라인 70% 이상, 또는 화면 컨트롤러 엔드포인트 전부 호출 (
be.endpointExclusions 는 분모에서 뺀다)그 화면이 덜 눌렸다 — 아래 화면별 현황의 빈 엔드포인트부터
/tests/ 화면별 실행 확인 「테스트 완료」 열4
자동 E2E 기준 (대신)
같은 기준을 자동 E2E 누적값으로 — 여정이 지나가는 화면(서류 인입·분류·추출·분석 요청·요약·다시 분석·보고서 초안·전송)은 직전 회차에서 그 단계를 통과한 사건이, 화면 순회가 도는 화면은 직전 회차에서 그 화면 테스트가 모두 통과한 기록이 있어야 하고, 그 행 PR 이 화면의 연동 어댑터를 바꿨으면 쓰지 않는다
수동(dev) 근거로만 판정된다
/tests/ 「자동 E2E(dev) — 실서류」 · /e2e/5
모두 충족
선언 화면 전부가 3 또는 4 를 넘는다 → 「테스트 완료」 +
비고에 근거·배포 커밋한 화면이라도 모자라면 그대로 테스트중
notion-wbs-sync 런 요약 「자동 테스트 완료」 줄6
사람이 판정 (예외)
실제 백엔드
@real 시나리오가 그 기능을 사람이 눌러 보는 범위로 통과하면, 사람이 노션에서 바꾸고 PR 본문·비고에 시나리오를 남긴다외부 연동 자체가 대상인 행은 이 길로 끝내지 않는다
/quality/ 「실제 백엔드 E2E」완료 뒤 — 재검증 필요
테스트 완료 행은 처음 판정 때 개발 서버 배포 커밋을 검증 커밋 열에 찍습니다. 그 뒤 배포에서 다른 PR 이 이 행의 PR 이 고친 파일을 바꾸면 재검증 필요 열에 무엇이 언제 바뀌었는지 적습니다. 상태는 그대로 두므로, 다시 눌러 확인했으면 사람이 검증 커밋 을 비웁니다 — 다음 실행이 새 커밋을 찍고 표시를 지웁니다.
수동 테스트 한 바퀴
개발 서버에 올라간 위탁사 시험 사건으로 한 바퀴 돌 때의 순서입니다. 테스트벤치는 사건을 준비·되돌리고 기록을 보는 도구이고, 커버리지가 쌓이는 곳은 개발 서버 hwss-api 입니다.
평소에는 QA 라운드로 돕니다(결정 20261023-qa-round-with-manual-coverage). 주 1회(목요일 오후 기본), 아침에
manual-coverage 를 reset 으로 시작하고, 라운드 중에는 dev → 개발 서버 배포를 멈춥니다(머지는 해도 됩니다). 시나리오는 그 화면의 프론트 담당이 맡아 수동 QA 시나리오를 따라 하고 /quality/ 에 통과·실패·막힘을 기록합니다. 따라 한 만큼 수동(dev) 에 쌓입니다.#
할 일
방법
끝나면 보이는 것
1
대상 행 고르기
노션에서 「테스트중」 행을 고르고, 그 PR 본문의
커버리지 맵: 화면을 확인한다. 화면 id 가 빠졌으면 PR 본문에 먼저 적는다판정할 화면 목록
2
모자란 곳 확인
/tests/ 화면별 실행 확인에서 그 화면의 라인·엔드포인트(API c/t)를 본다. 엔드포인트가 몇 개 남았는지가 가장 빠른 길잡이다눌러야 할 기능 목록
3
사건 준비
테스트벤치
http://10.252.253.115:3390 에서 기존 시험 사건(TBD-*)을 체크포인트로 되돌리거나 새로 접수한다. 테스트벤치가 고칠 수 있는 것은 테스트벤치가 만든 사건, 실행 기록에 올린 사건, 접수번호가 TB…-·TEST- 인 사건뿐이다. 서류 구성은 /realdata/case-NN 에서 본다시작점에 선 사건
4
화면 진행
Chrome 에서 SSO 로그인 뒤 dagent 화면 버튼으로 진행한다. 테스트벤치는 SSO 때문에 분류 이후 「단계 시작」을 못 하므로 화면에서 누른다. 성공 흐름과 함께 수정·되돌리기·빈 결과 같은 갈래도 누른다
사건 상태가 다음 단계로
5
수집 (선택)
정시 :05 를 기다리거나 바로 돌린다
gh workflow run manual-coverage.yml -f reset=false수집 성공 → 노션 판정 · 사이트 빌드가 이어서 돈다
6
결과 확인
/tests/ 화면 행 「테스트 완료」 칩 → 노션 행 상태·비고 → notion-wbs-sync 런 요약 WBS <No>: … → 테스트 완료노션 「테스트 완료」
테스트벤치 PC 실행 기록(
TBM-*)은 개발 서버 DB 에 없는 사건이라 수동(dev) 수치에 들어가지 않습니다. 개발 서버 화면에서 진행한 것만 셉니다.자동으로 도는 것
평일 하루의 정시 실행입니다(KST). 점 하나가 한 번의 실행이고, 마우스를 올리면 시각이 보입니다. 실서류 정기 회차는 주말에 없습니다. 수동(dev) 수집·WBS 스냅샷은 매일(야간 포함, 표는 08~20시만) 돌고, 토 03:00 뮤테이션 테스트, 일 04:00 분류 정확도 벤치마크, 월 08:47 의존성 취약점 검사, 평일 21:00 준비형 E2E 가 따로 돕니다.
이벤트를 따라 도는 것
| 이런 일이 생기면 | 자동으로 도는 것 | 결과가 보이는 곳 |
|---|---|---|
| Draft PR 열기 · Draft 해제 · 리뷰 · dev 머지 | notion-wbs-sync — WBS: 줄의 행을 진행중 → PR 리뷰중 → 코딩완료로 | 노션 · /wbs/ |
| PR 열기·푸시·라벨 | trust-check — 기준 약화 감시·시나리오 게이트·바꾼 줄 커버리지·뮤테이션 | PR 「신뢰 게이트」 고정 댓글 |
| dev 머지 | 백엔드·프론트 검사(단위·시나리오·E2E·커버리지), PostgreSQL 통합 테스트 → 끝나면 사이트 빌드 | /quality/ · /tests/ 단위 열 · /trends/ |
| dev → main 릴리스 PR 머지 | deploy-dev 배포 → 기동 기록 비움 → .http 재생 · @real E2E → 노션 코딩완료 행을 테스트중으로 · 재검증 판정 · 수동(dev) 수집 · 실서류 배포 직후 회차(배정을 사람이 바꾸지 않았으면 최신 골든 시나리오셋, 없으면 전체 회귀) | 노션 · /quality/ 배포 뒤 장치 |
dev 머지(e2e/ 경로) · 평일 21:00 · 수동 | E2E Prepared Scenarios — 준비형 E2E. WBS 판정에는 섞이지 않고, 끝나면 사이트 빌드 | /e2e/#prepared |
| 수동(dev) 수집 성공 | 노션 테스트 완료 판정 + 사이트 빌드 | 노션 · /tests/ 수동(dev) |
| 실서류 자동 E2E 회차 끝 (성공·실패 무관) | 노션 테스트 완료 판정 + 사이트 빌드(회차 기록 D1 저장) | /e2e/ · /tests/ 자동 E2E(dev) |
| 사이트 빌드 · 노션 판정 끝 | WBS 스냅샷 (마지막 장이 10분 안이면 건너뜀) | /wbs/ |
Studio 실연동 점검·분류 벤치마크·PostgreSQL·@real 결과는 사이트 빌드를 따로 일으키지 않고, 다음 빌드 때 함께 반영됩니다.
어디서 무엇을 보나
페이지마다 답하는 질문이 다릅니다. 「테스트 완료」로 가는 길에서는 /tests/ 와 노션이 중심이고, 나머지는 「그 근거를 믿어도 되는가」와 「일정이 괜찮은가」를 봅니다.
/tests/ — 실제로 지나간 코드는 어디인가
- 화면별 실행 확인: 프론트 E2E · 백엔드 수동(dev) · 엔드포인트 · 테스트 완료 칩
- 수동(dev) 모니터링: 라인·엔드포인트·기준 충족 화면 추이, 배포별 전 → 직후 → 지금, 시간대별 증가
- 자동 E2E(dev) — 실서류: 직전 회차 사건별 결과와 모듈별 라인 (회차별 화면 순회·회차 상세는
/e2e/) - 판정 글자: 실행 확인(두 층 낮은 쪽 ≥ 80%) · 일부만(≥ 50%) · 거의 안 지나감 · 한쪽만 · 아무도 안 눌러 봄
/wbs/ — 일정이 계획대로 가는가
- 완료 = 노션 「테스트 완료」만 센다
- 금주 페이스 완료 ÷ 기대 완료: 순조 ≥ 0.9 · 주의 ≥ 0.7
- 하루 필요량 최근 3업무일 처리량 ÷ 하루 필요량: 순조 ≥ 1 · 주의 ≥ 0.7
- 지연 누적 어제보다 늘면 문제, 미룸 지난 일정을 완료 없이 미루면 문제
/e2e/ — 자동 여정이 매일 끝까지 가는가
- 스텁·실연동 사건 통과율(7일): 순조 100% · 주의 ≥ 50%
- 실연동 마지막 통과: 2일 미만 순조 · 7일 이상 문제
- 연속 실패: 0 순조 · 1~2 주의 · 3회 이상 문제
- 실패 지점(단계 × 분류), 단계 소요 추이, 서버 로그 요약
/e2e/scenarios/ · /e2e/sets/ — 회차가 무엇을 도는가
- 시나리오: 화면 순회·사건 여정·워크플로 시나리오 카탈로그, 계획만 있는 것
- 시나리오셋: 셋마다 최근 결과, 슬롯별 배정. 셋은 시나리오 페이지에서 고른다
- 골든 시나리오셋: 3회 연속 통과한 셋을 자동 동결, 해제는 사람(결정 20261101)
- 이름이 비슷한 골든 테스트셋은 자료 쪽이다 — 등록부는 개발 서버에만 있다(결정 20261024)
/quality/ — 지나간 곳이 맞게 동작한다는 근거가 있는가
- 신뢰 점검표 26개 장치 — 통과·실패·불안정·결과 없음·설정 필요
- 시나리오 통과율: 100% 순조 · 95% 이상 주의
- 요구사항 → 검증 근거, 뮤테이션 점수, Studio 실연동 점검·분류 정확도
- 수동 QA 기록(통과·실패·막힘, 14일 지나면 다시 확인) — 표시용, 판정에 안 들어감
/trends/ — 머지마다 지표가 오르내렸나
- 단위 라인·테스트 수·시나리오 통과·요구사항 근거 9개 지표
- PR(머지)별·날짜별 표, 「지표별 최근 변화」(직전·7일·30일 전 대비)
- 「내려감·새 실패」 표 — 내려간 측정과 그 사이 들어온 머지
/coverage/ — 화면마다 구현이 어디까지 왔나
- 프론트·백엔드·연동 층 상태, 진행 중 PR, 담당
- 「안 눌러 본 층 있음」 필터 — 실행 확인이 비어 있는 화면
- 테스트 판정의 화면 범위(클래스·컨트롤러·제외 엔드포인트)는 이 표(
coverage.json)가 정한다
세 페이지(/tests/·/quality/·/trends/) 맨 위 「지금 상태」 카드는 같은 기준을 씁니다 — 비율 0.5%p 이상 내려가면 문제, 마지막 측정이 48시간 넘으면 주의·168시간 넘으면 문제.
내려갈 때 보는 신호
수치가 내려가는 원인은 대부분 셋 중 하나입니다 — 배포로 바뀐 클래스가 0 에서 다시 세어짐, 테스트·시나리오가 깨짐, 측정이 멈춤.
| 신호 | 어디서 | 흔한 원인 | 할 일 |
|---|---|---|---|
| 배포 직후 수동(dev) 라인·엔드포인트가 배포 전보다 낮다 | /tests/ 수동(dev) 모니터링 「배포(릴리스)별」 — 음수 칸 | 바뀐 클래스는 그 배포부터 다시 센다(정상 동작) | 그만큼이 다시 눌러야 할 양 — 바뀐 화면을 다시 진행 |
노션에 재검증 필요 가 적혔다 | 노션 WBS · notion-wbs-sync 런 요약 | 다른 PR 이 이 행의 파일을 바꿔 배포됐다 | 다시 확인 → 검증 커밋 비우기 (상태는 그대로) |
| 「테스트 완료 기준 충족 화면」 수가 줄었다 | /tests/ 수동(dev) 추이 | 배포로 리셋된 클래스, 화면 범위(coverage.json)에 클래스·컨트롤러 추가 | 어느 화면이 빠졌는지 화면별 표에서 확인 |
| 「내려감」 빨간 고리 · 「새 실패」 빨간 점 | /trends/ · /tests/·/quality/ 「내려감·새 실패」 표 | 테스트 삭제·실패, 덮는 테스트 없이 코드 추가 | 표의 「직전 측정 뒤 들어온 머지」에서 원인 PR 확인 |
| 자동 E2E 연속 실패 · 실연동 마지막 통과가 오래됨 | /e2e/ 지금 상태 · 실패 지점 | Studio 쪽 지연·한도, 개발 서버 메모리 부족(건너뜀), 화면 변경 | 실패 분류·마지막 단계 확인. 그동안 그 회차에 걸린 화면은 수동 근거가 필요 |
| 「마지막 측정」 주의·문제 | 세 페이지 지금 상태 | 검사·수집 워크플로가 멈춤, 러너 이상 | Actions 에서 그 워크플로 마지막 런 확인 |
| 금주 페이스·하루 필요량 주의, 지연 누적 증가 | /wbs/ 한눈 현황 · 담당자별 지연 | 코딩완료·테스트중에서 테스트가 밀림 | 「코딩 완료 이후」 지연 행부터 수동 테스트 배정 |
| 점검표에 실패·설정 필요 | /quality/ 신뢰 점검표 | Studio 점검 실패, 환경 설정 누락 | 장치 카드의 「필요한 설정」·「오인 주의」 확인 |
사람이 정하는 것
자동 장치가 대신하지 않는 판단입니다.
| 정할 것 | 보고 정할 지표 | 선택지 |
|---|---|---|
| 오늘 어떤 행을 테스트할지 | /wbs/ 금주 목표·지연(코딩 완료 이후), 노션 테스트중 행 | 지연·이번 주 종료예정 행부터 |
| 릴리스(main 배포)를 언제 열지 | 노션 코딩완료 행 수, /quality/ dev 검사 상태 | 배포해야 행이 테스트중으로 오고, 배포마다 바뀐 클래스는 다시 세어진다 — 테스트 묶음 단위로 여는 편이 덜 다시 누른다. QA 라운드 중에는 열지 않는다 |
| 기준 미달 화면을 어떻게 끝낼지 | /tests/ 화면의 라인·API c/t | 남은 엔드포인트를 더 누른다 / 실제로 못 부르는 엔드포인트면 coverage.json 의 be.endpointExclusions 에 사유와 함께 뺀다 / @real 시나리오 통과로 사람이 완료 |
| 자동 E2E 가 안 지나가는 화면 | /e2e/scenarios/ — 그 회차에 배정된 셋의 스펙에 없는 화면. 빠른 확인 슬롯은 핵심 시나리오만 돈다 | 수동(dev) 또는 @real 만 근거가 된다 — 사람이 직접 눌러야 하는 목록으로 둔다 |
| 연동 어댑터를 바꾼 행 | 그 행 PR 의 변경 파일 | 자동 E2E 근거가 빠진다 — Studio 실연동으로 직접 확인하고 판정 |
| 재검증 필요 행 | 노션 재검증 필요 문구(바뀐 파일·PR) | 다시 눌러 확인하고 검증 커밋 비우기 / 영향 없다고 보면 그대로 비우기 |
| 하락이 정상인지 | /trends/ 내려감 표의 원인 머지 | 리팩터링·삭제로 인한 정상 하락이면 둔다 / 테스트를 지운 하락이면 그 PR 에 되돌림 요청 |
화면별 수동(dev) 현황
라인·엔드포인트는 2026-10-20 수집(배포 2f6494f2) 시점의 값입니다. 최신 값은 /tests/ 화면별 실행 확인에서 봅니다. 초록 행이 그때 수동 기준을 넘은 화면입니다. 「자동 E2E」 열의 ● 는 2026-11-03 스펙 기준으로 사건 여정이나 화면 순회가 그 화면을 돈다는 뜻이고(권한 검사만 있는 화면은 빼고), 실제 판정은 직전 회차 통과 여부에 달려 있어 /tests/ 에서 봅니다.
| 화면 | id | 라인 | 엔드포인트 | 자동 E2E |
|---|---|---|---|---|
| 사고조사 흐름 | ||||
| 사고조사 목록 | investigation-list | 71.5% | 4/4 | ● |
| 서류 인입 | workspace-intake | 52.1% | 6/11 | ● |
| 분류·미분류/저신뢰 조치 | workspace-classification | 65.5% | 5/8 | ● |
| 추출 검수 | workspace-extraction | 73.8% | 2/3 | ● |
| 다시 분석 4범위 | reanalysis | 64.4% | 2/2 | ● |
| 분석 조건 입력 | analysis-request | 65.1% | 2/6 | ● |
| 요약 확인·확정 | summary | 68.6% | 3/6 | ● |
| 보고서 초안 | report-draft | 44.0% | 4/7 | ● |
| 보고서 전송 | report-send | 1.1% | 0/2 | ● |
| 공통·사용자 | ||||
| 로그인 | login | 71.3% | 4/5 | ● |
| 최초 로그인 이메일 등록 | onboarding | 25.0% | 0/1 | ● |
| 내 정보 | profile | 37.3% | 2/6 | ● |
| 에이전트 채팅 | agent-chat | 24.5% | 3/7 | ● |
| 사용 내역 | conversations | 43.5% | 3/7 | ● |
| 지식컬렉션 참조 내역 | knowledge-references | – | – | |
| 지식 컬렉션 목록·등록 | collections | 14.7% | 3/34 | ● |
| 지식컬렉션 뷰어 | collection-viewer | 20.1% | 1/15 | ● |
| 통계 대시보드 | dashboard | 64.3% | 6/11 | ● |
| 관리자 | ||||
| 지식컬렉션 관리 | admin-knowledge | 16.0% | 1/23 | ● |
| 승인·검토 | approval-center | 7.6% | 2/11 | ● |
| 위탁사 워크스페이스 | client-workspace | 78.2% | 1/1 | ● |
| 수동-자동 분류체계 매칭 | classification-mapping | 42.6% | 3/5 | ● |
| 보고서 유형 설정 | report-types | 25.6% | 1/3 | ● |
| 청약서 폼 설정 | application-forms | 23.3% | 1/3 | ● |
| 병원 명칭 매핑 | hospital-aliases | 12.3% | 0/3 | ● |
| 에이전트 스튜디오·실행 테스트 | agent-studio | – | – | ● |
| 문서 분류·정보 추출 체계 | doc-type-schemas | 33.3% | – | ● |
| 요약 및 해석 체계 | summary-layout | 84.8% | – | ● |
| 보고서 양식 | report-templates | 4.3% | 0/8 | |
| 메일 발송 로그·계정 | mail-account | 12.2% | 1/5 | ● |
| 초안 전송 로그 | report-send-logs | 11.6% | 0/2 | |
| 파기 로그 | report-disposal-logs | – | – | |
| 감사 로그 | audit-logs | 40.7% | 1/2 | ● |
| 조직도 | organization | 50.2% | 4/8 | ● |
| 권한 관리 | permissions | 44.9% | 2/4 | ● |
2026-10-20 시점에 기준에 가까웠던 화면: 요약(68.6%, 엔드포인트 3개 남음) · 분류(65.5%) · 분석 조건 입력(65.1%) · 대시보드(64.3%). 그때 시험 사건 9건이 보고서 초안까지 갔지만 보고서 전송·다시 분석의 일부 갈래는 거친 흔적이 없었습니다.
놓치기 쉬운 것
- 로컬·테스트벤치 PC 실행은 세지 않는다. 개발 서버
hwss-api를 지난 요청만 수동(dev)에 쌓인다. - dev 머지 ≠ 개발 서버 배포. 배포는 dev → main 릴리스 PR 머지 때다. 그 전까지 행은 코딩완료에 머물고 판정 대상이 아니다.
- 배포 직후 기동 기록은 비운다. 앱이 뜰 때 실행된 줄은 빼고 사람이 누른 범위만 남긴다. 바뀐 클래스는 그 배포부터 0 에서 다시 센다.
- 수동 QA 기록은 판정에 안 들어간다.
/quality/의 통과·실패·막힘 기록은 사람용 메모다. - 자동 E2E 와 수동 수치는 합치지 않는다. 화면마다 둘 중 하나가 넘으면 되고, 「기준 충족 화면」 추이는 수동만 센다.
- 화면 범위는
coverage.json이 정한다. 화면 행에 클래스·컨트롤러를 더하면 분모가 커져 수치가 내려갈 수 있다. - 사이트 수치는 한 박자 늦다. 각 워크플로의 가장 최근 성공 런을 읽으므로, 출처 줄의 「이후 관련 머지 N개 미반영」을 함께 본다.
- 테스트 완료는 뒤로 돌아가지 않는다. 이후 변경은 상태 대신
재검증 필요열로만 알린다.
근거 문서
| 무엇 | 위치 |
|---|---|
| 테스트 완료 판정 결정 (수동 커버리지 · @real · 자동 E2E 추가) | docs/decisions/20261014-wbs-test-done-by-manual-coverage.md |
| 수동(dev) 커버리지 결정 | docs/decisions/20261006-manual-coverage-dev-server.md |
| 실서류 자동 E2E 결정 | docs/decisions/20261014-realdata-e2e-dev.md |
| QA 라운드 결정 | docs/decisions/20261023-qa-round-with-manual-coverage.md |
| 시나리오 층·자료 골든 테스트셋 결정 | docs/decisions/20261024-e2e-scenario-layers-golden-set.md |
| 시나리오셋·골든 시나리오셋 결정 | docs/decisions/20261101-workflow-scenario-sets-golden-metrics.md |
| 테스트벤치 개발 서버 배치 결정 | docs/decisions/20261019-testbench-dev-server.md |
| 개발 서버 릴리스 브랜치 결정 | docs/decisions/20261008-dev-server-release-branch.md |
| 노션 상태 갱신·판정·재검증 | scripts/notion_wbs_sync.py · .github/workflows/notion-wbs-sync.yml |
| 화면 판정 계산 (70% · 엔드포인트 · 자동 E2E 단계) | docs-site/generators/tests_guide.py |
| 수집 | .github/workflows/manual-coverage.yml · e2e-realdata-dev.yml · e2e-prepared.yml |
| 지표 페이지 구성·원천 | docs-site/README.md §8 ~ §8-7 |
| 협업 흐름(노션·PR·Slack) | /collab/ · /workflow/ |