Smoke Test
스모크 테스트
Smoke Test는 작고 빠른 테스트 모음이야. 빌드가 더 깊은 테스트나 실사용을 견딜 수 있는지 알려줘.
다른 예시
배포 후, 자동화 프로그램이 첫 화면을 열고 테스트 계정으로 로그인해. API 응답 하나를 읽고 문제없는 거래를 하나 보내.
주요 부분
- 01Code or behavior under test
- 02Observable evidence
- 03Coverage, failure, and recovery
사용할 때
패키징이나 배포 후 실행하세요. 장기 테스트나 실제 트래픽 전에 명확히 깨진 버전을 중지하세요.
다음 경우에는 사용하지 마세요
전체 회귀 테스트를 스모크 테스트라고 부르지 마세요. 통과했다고 해서 극단적인 경우가 검증되는 것은 아닙니다.
코드에서 사용된 이름
critical-path probes after build/deploy 출시하기 전에
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 스모크 테스트 (Smoke Test)。 User context：배포 후, 자동화 프로그램이 첫 화면을 열고 테스트 계정으로 로그인해. API 응답 하나를 읽고 문제없는 거래를 하나 보내. Validation approach：스모크 테스트 (Smoke Test)。 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 스모크 테스트 (Smoke Test) is used now. Definition: Smoke Test는 작고 빠른 테스트 모음이야. 빌드가 더 깊은 테스트나 실사용을 견딜 수 있는지 알려줘. 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.