Load Testing
부하 테스트
부하 테스트는 계획된 트래픽 하에서 시스템의 속도와 신뢰성을 확인합니다. 계획에는 사용자 수, 요청 또는 작업 패턴이 설정됩니다.
다른 예시
체크아웃 테스트는 초당 120개의 요청을 20분간 전송합니다. 팀이 로드 도구를 관찰하는 동안 시스템은 p95 지연과 오류 한도 내에 머물러야 합니다. 워크로드 계획이 없는 랜덤 트래픽은 유용한 로드 테스트가 아닙니다.
주요 부분
- 01작업 부하 모델
- 02부하 생성기
- 03성능 임계값
사용할 때
실제 사용과 일치하는 안정적인 트래픽에서 용량과 서비스 목표를 점검할 때 이 용어를 사용하세요.
다음 경우에는 사용하지 마세요
통제되지 않은 부하를 프로덕션에 보내지 말고, 부하 도구가 병목인 경우 시스템 결과를 보고하지 마세요.
코드에서 사용된 이름
workload model → virtual users → thresholds 출시하기 전에
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 부하 테스트 (Load Testing)。 User context：체크아웃 테스트는 초당 120개의 요청을 20분간 전송합니다. 팀이 로드 도구를 관찰하는 동안 시스템은 p95 지연과 오류 한도 내에 머물러야 합니다. 워크로드 계획이 없는 랜덤 트래픽은 유용한 로드 테스트가 아닙니다. Validation approach：부하 테스트 (Load Testing)。 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 부하 테스트 (Load Testing) 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.