사용 사례 테스트 예시
⚡ 스마트 요약
유스케이스 테스트는 사용자와 시스템 간의 상호작용을 실행하여 엔드투엔드 트랜잭션을 검증합니다. 이 기법은 시스템 및 인수 테스트 케이스를 도출하고, 통합상의 격차를 드러내며, 단위 테스트를 현실적인 사용자 워크플로로 보완합니다.

유스 케이스 테스트란 무엇입니까?
사용 사례 테스트 유스케이스 테스트는 시스템 전체를 대상으로 시작부터 끝까지 모든 트랜잭션을 포괄하는 테스트 케이스를 식별하는 소프트웨어 테스트 기법입니다. 이러한 테스트 케이스는 사용자와 소프트웨어 애플리케이션 간의 상호 작용을 설명합니다. 유스케이스 테스트는 개별 소프트웨어 구성 요소를 따로 테스트할 때 드러나지 않을 수 있는 취약점을 발견하는 데 도움이 됩니다.
A 유스 케이스 테스트에서 유스케이스는 액터 또는 사용자가 소프트웨어를 특정 방식으로 사용하는 것을 간략하게 설명한 것입니다. 유스케이스는 사용자 행동과 애플리케이션의 해당 응답을 기반으로 작성되며, 널리 사용되어 다음과 같은 사항을 도출합니다. 테스트 케이스 시스템 및 수용 수준에서.
사용 사례의 핵심 구성 요소
모든 사용 사례는 동일한 구성 요소 세트로 만들어집니다. 구성 요소를 미리 알면 테스트 케이스에 깔끔하게 매핑되는 코드 커버리지를 설계하기가 더 쉬워집니다.
- 배우: 상호작용을 시작하는 사용자 또는 외부 시스템. 텍스트 흐름에서는 "A"로 표시됩니다.
- 시스템 : 테스트 대상 소프트웨어는 액터의 동작에 응답하는 소프트웨어로, "S"로 표시됩니다.
- 사전 조건: 유스케이스가 시작되기 전에 시스템이 있어야 하는 상태입니다.
- 주요 성공 시나리오: 정상적인 실행 경로에서 액터와 시스템 단계의 순서.
- 확장/대체 흐름: 예외 처리, 유효성 검사 실패 또는 대안 선택을 처리하는 분기입니다.
- 사후 조건: 사용 사례가 종료된 후 시스템이 남아 있는 상태.
사용 사례 테스트 수행 방법: 예
사용 사례에서 행위자는 "A"로, 시스템은 "S"로 표시됩니다. 아래 예시는 웹 애플리케이션의 로그인 기능을 설명합니다.
| 주요 성공 시나리오 | 단계 | 기술설명 |
|---|---|---|
| A: 배우 S: 시스템 | 1 | A: 에이전트 이름과 비밀번호를 입력하세요 |
| 2 | S: 비밀번호 유효성 검사 | |
| 3 | S: 계정 액세스 허용 | |
| 확장 | 2a | 비밀번호가 유효하지 않습니다. S: 메시지를 표시하고 재시도를 요청합니다(최대 4회). |
| 2b | 비밀번호가 4회 유효하지 않습니다. S: 지원 종료 |
위 흐름도는 하나의 정상 경로와 두 가지 확장 경로를 설명합니다. 단계별로 읽어보면 다음과 같습니다.
- 사용자는 로그인 과정의 첫 단계로 이메일과 비밀번호를 입력합니다.
- 시스템이 비밀번호를 검증합니다.
- 비밀번호가 올바르면 접근 권한이 부여됩니다.
- 비밀번호가 유효하지 않으면 시스템은 메시지를 표시하고 최대 4번의 재시도 기회를 제공합니다.
- 네 번의 시도 후에도 비밀번호가 유효하지 않으면 시스템은 추가 시도를 차단합니다(이 예에서는 IP 주소를 차단하는 방식).
이 사용 사례에서는 성공 시나리오와 각 확장 기능의 테스트 케이스 하나씩을 추가로 테스트하게 됩니다. 이렇게 하면 최소한 세 가지 테스트 케이스가 생성됩니다. 유효한 로그인, 복구 가능한 잘못된 비밀번호, 그리고 반복적인 로그인 실패 후 계정 잠금입니다.
유스케이스 테스트의 장점
유스케이스 테스트는 요구사항과 테스트 케이스 사이에 자연스럽게 들어맞습니다. 주요 장점은 다음과 같습니다.
- 종단간 지원: 모듈 간의 트랜잭션을 테스트하며, 개별 함수를 테스트하는 것은 아닙니다.
- 사용자 중심 검증: 각 시나리오는 실제 사용자가 시스템을 사용하는 방식을 반영합니다.
- 초기화 trac능력: 사용 사례는 이해관계자 승인을 위한 수용 기준과 직접적으로 연결됩니다.
- 결함 방지: 회귀 분석 주기가 시작되기 전에 표면 통합 격차를 파악합니다.
- 재사용 가능한 유물: 동일한 사용 사례가 테스트 사례, 교육 자료 및 사용자 설명서에 활용됩니다.
사용 사례 테스트의 한계
이 기법은 강력하지만 모든 상황에 적용 가능한 것은 아닙니다. 다음과 같은 제약 사항에 유의하십시오.
- 단위 테스트를 대체할 수 없습니다. 하위 수준 구성 요소 오류에 대해서는 여전히 맞춤형 테스트가 필요합니다.
- 정확한 사용 사례에 따라 다릅니다. 모호한 흐름은 모호한 결과를 낳습니다.
- 기능 외적인 부분에 대한 보장 범위는 제한적입니다. 성능, 보안 및 접근성에는 각각 고유한 기술이 필요합니다.
- 유지보수 간접비: 비즈니스 규칙이 변경될 경우 사용 사례도 업데이트해야 합니다.

