Visual Regression Test
시각 회귀 테스트
시각적 회귀 테스트는 오늘 렌더링된 이미지를 동일한 브라우저 조건에서 승인된 참조 이미지와 비교합니다.
다른 예시
체크아웃 스크린샷은 고정된 브라우저 설정에서 승인된 참조와 비교됩니다. 잘린 키보드 포커스 링은 검토를 위해 픽셀 차이로 나타납니다. 변경된 모든 이미지를 확인하지 않고 승인하는 것은 회귀 테스트가 아닙니다.
주요 부분
- 01제어된 렌더러
- 02승인된 기준선
- 03검토 가능한 차이
사용할 때
DOM 값만으로 확인하기 어려운 눈에 보이는 변경 사항에 이 용어를 사용하세요.
다음 경우에는 사용하지 마세요
넓은 픽셀 범위의 불안정한 이미지를 숨기거나 의미 및 행동 체크를 스크린샷으로 대체하지 마세요.
코드에서 사용된 이름
current screenshot Δ approved baseline 출시하기 전에
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome：Complete the task with 시각 회귀 테스트 (Visual Regression Test)。 User context：체크아웃 스크린샷은 고정된 브라우저 설정에서 승인된 참조와 비교됩니다. 잘린 키보드 포커스 링은 검토를 위해 픽셀 차이로 나타납니다. 변경된 모든 이미지를 확인하지 않고 승인하는 것은 회귀 테스트가 아닙니다. Validation approach：시각 회귀 테스트 (Visual Regression Test)。 Why it fits：DOM 값만으로 확인하기 어려운 눈에 보이는 변경 사항에 이 용어를 사용하세요. Do not use it when：넓은 픽셀 범위의 불안정한 이미지를 숨기거나 의미 및 행동 체크를 스크린샷으로 대체하지 마세요. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary)：해당 출처에 대해 공식적인 것입니다. 다른 플랫폼이나 팀은 그 용어를 다른 방식으로 사용할 수 있습니다. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
이 요청을 확인하세요
Review how 시각 회귀 테스트 (Visual Regression Test) is used now. Definition: 시각적 회귀 테스트는 오늘 렌더링된 이미지를 동일한 브라우저 조건에서 승인된 참조 이미지와 비교합니다. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.