Test Coverage
테스트 커버리지
테스트 커버리지는 어떤 코드, 요구사항, 상태, 혹은 위험 요소를 테스트가 확인하는지를 보여줍니다. 비율은 단지 대략적인 표시일 뿐입니다.
다른 예시
팀은 92%의 코드 커버리지를 가지고 있어. 하지만 빠져있는 위험이 더 중요하기에 권한 테스트를 추가해.
주요 부분
- 01Code or behavior under test
- 02Observable evidence
- 03Coverage, failure, and recovery
사용할 때
놓친 영역을 찾고 위험을 논의하기 위해 보고서를 사용하십시오. 또한 변이, 요구사항, 생산 사실을 확인하십시오.
다음 경우에는 사용하지 마세요
목표 비율을 품질로 간주하지 마세요. 빈 체크와 검토되지 않은 제외는 피하세요.
코드에서 사용된 이름
line / branch / function / mutation coverage 출시하기 전에
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 테스트 커버리지 (Test Coverage)。 User context：팀은 92%의 코드 커버리지를 가지고 있어. 하지만 빠져있는 위험이 더 중요하기에 권한 테스트를 추가해. Validation approach：테스트 커버리지 (Test Coverage)。 Why it fits：놓친 영역을 찾고 위험을 논의하기 위해 보고서를 사용하십시오. 또한 변이, 요구사항, 생산 사실을 확인하십시오. 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 테스트 커버리지 (Test Coverage) 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.