임계값을 만지지 않았다

126케이스 한 런에서 FAIL은 하나. 그 하나를 통과시키는 방법을 알고 있었고, 쓰지 않았다.

126케이스를 완주했다. 937초. FAIL 하나.

그 하나를 통과시키는 방법은 알고 있었다. 판정 창을 30초에서 60초로 늘리면 된다. 한 줄이다.

판정이 다섯 종류인 이유

PASS와 FAIL만 두면 자동화는 거짓말을 한다. 확신이 없는 케이스가 갈 곳이 없어서 둘 중 하나로 밀려 들어가고, 밀려 들어가는 쪽은 대개 PASS다.

그래서 판정은 다섯이다. 로그 앵커로 기계가 단정할 수 있을 때만 PASS와 FAIL. 화면은 남겼는데 못 정하면 EVIDENCE. 실행 자체를 못 했으면 SKIP. 범위 밖이면 NA.

가장 큰 덩어리가 EVIDENCE 66건이다. 기계가 혼자 단정한 건 절반이 안 된다는 뜻이고, 그 숫자를 감추지 않는 것이 이 분류의 목적이다.

연속한 두 케이스가 같은 조작을 같은 로그 앵커로 판정하고 있었다. 앞 케이스가 30초를 기다렸고, 앵커는 그 뒤에 도착해 다음 케이스의 창에서 잡혔다.

이벤트는 정상 발생했다. 첫 번째 창이 놓쳤을 뿐이다. 제목이 같은 다른 네 건은 이번 런에서 전부 통과했고, 직전 런에서는 앵커가 30초 안에 도착해 이 케이스도 통과했다.

즉 결과가 타이밍에 좌우된다.

창을 늘리면 이번 런은 초록색이 된다. 원인은 그대로 남고, 다음 런에서 같은 자리가 다시 흔들린다.

구조 문제는 앵커 중복이다. 처방은 고유 앵커를 주거나 두 케이스를 합치는 쪽이고, 어느 쪽이든 기대값 확인이 먼저다. 이번 런은 FAIL 하나를 안고 닫았다.

SKIP 39건 중 9건이 “탭 대상 미매핑”으로 떴다. 좌표만 채우면 회수된다고 적었다. 가장 싼 커버리지 증가분이라고 썼다.

틀렸다. 채워도 0건 회수된다.

위젯 덤프 7,455개를 통째로 떠서 확인하니 대상은 실재했고 이름도 다 있었다. 막힌 건 좌표가 아니라 도달이었다. 조상 컨테이너 하나가 비표시라 좌측 HUD가 통째로 접혀 있었고, 런 내내 한 번도 열리지 않았다.

인게임 덤프 72개 중	등장
우측 HUD	72
좌측 HUD	0

좌표를 넣으면 SKIP 사유가 “미매핑”에서 “동작 실패”로 바뀔 뿐이다. 커버리지를 늘리려면 매핑이 아니라 그 화면에 도달하는 경로가 필요하다.

문자열 하나가 진단을 통째로 잘못된 방향으로 끌고 갔다. 사유 문자열은 로그 장식이 아니라, 사람이 읽고 다음 행동을 정하는 인터페이스다.

937초 중 브리지 왕복이 302초(32.3%). 그중 위젯 트리 덤프 하나가 186초, 런 전체의 19.8%다.

판정할 때마다 트리를 통째로 받아오는 구조라 그렇다. 필요한 위젯만 묻는 호출을 두면 줄어든다 — 얼마나 줄어드는지는 도입 전후를 같은 케이스 셋으로 재봐야 안다.

이 숫자를 보기 전까지는 셰이더 컴파일이 병목인 줄 알았다.

FAIL 1건은 제품 결함이 아니었다. 그렇다고 초록색으로 만들지도 않았다.

이 두 문장을 같이 쓸 수 있게 만드는 것이, 판정을 다섯으로 쪼개고 사유 문자열을 남기는 이유다.