예제를 사용하여 테스트 사례를 작성하는 방법
토마스 해밀턴
테스트 케이스란 무엇입니까?
A 테스트 사례 한 세트입니다 조치, 입력 및 예상 결과 테스터가 소프트웨어의 특정 기능이 의도한 대로 작동하는지 확인하는 데 도움이 됩니다. 단계별 가이드 테스트할 내용, 테스트 방법, 예상 결과 등을 정의합니다.
테스트 케이스를 다음과 같이 생각하세요. 검증을 위한 레시피 — 정확한 재료(테스트 데이터), 공정(수행 단계), 완벽한 요리(예상 결과)가 어떤 모습인지 알려줍니다.
잘 작성된 테스트 사례는 다음을 보장하는 데 도움이 됩니다.
- 소프트웨어는 다음을 충족합니다. 비즈니스 및 사용자 요구 사항.
- 버그나 예상치 못한 동작이 발생합니다. 일찍 발견됨.
- 테스트는 가능합니다 반복하고 검토하다 모든 QA 전문가가.
- 팀은 할 수 있습니다 더듬다 각 테스트가 검증하는 요구 사항입니다.
👉 무료 라이브 소프트웨어 테스팅 프로젝트에 등록하세요
수동 테스트에서 테스트 사례를 만드는 단계
시나리오에 대한 테스트 사례를 만들어 보겠습니다. 로그인 기능 확인
단계 1) 시나리오를 설명하는 간단한 테스트 사례는 다음과 같습니다.
| 테스트 케이스 # | 테스트 케이스 Descript이온 |
|---|---|
| 1 | 유효한 이메일과 비밀번호를 입력하면 응답을 확인합니다. |
단계 2) 데이터를 테스트합니다.
테스트 케이스를 실행하려면 다음이 필요합니다. 테스트 데이터. 아래에 추가하세요
| 테스트 케이스 # | 테스트 케이스 Descript이온 | 테스트 데이터 |
|---|---|---|
| 1 | 유효한 이메일과 비밀번호를 입력하면 응답을 확인합니다. | 이메일: guru99@email.com 비밀번호: lNf9^Oti7^2h |
테스트 데이터를 식별하는 데는 시간이 많이 걸릴 수 있으며 때로는 테스트 데이터를 새로 생성해야 할 수도 있습니다. 문서화해야 하는 이유.
단계 3) 작업을 수행합니다.
테스트 케이스를 실행하려면 테스터는 AUT에서 특정 작업 세트를 수행해야 합니다. 이는 아래와 같이 문서화되어 있습니다.
| 테스트 케이스 # | 테스트 케이스 Descript이온 | 테스트 단계 | 테스트 데이터 |
|---|---|---|---|
| 1 | 유효한 이메일과 비밀번호를 입력하면 응답을 확인합니다. | 1) 이메일 주소를 입력하세요
2) 비밀번호 입력 3) 로그인을 클릭하세요. |
이메일: guru99@email.com
비밀번호: lNf9^Oti7^2h |
테스트 단계는 위에서 언급한 것처럼 간단하지 않은 경우가 많기 때문에 문서화가 필요합니다. 또한, 테스트 케이스 작성자는 회사를 떠나거나 휴가를 가거나 병가를 내거나 다른 중요한 업무로 매우 바쁠 수 있습니다. 최근 채용된 신입사원이 테스트 케이스 실행을 요청받을 수도 있습니다. 문서화된 단계는 작성자에게 도움이 될 뿐만 아니라 다른 이해관계자들의 검토도 용이하게 합니다.
단계 4) AUT의 동작을 확인하세요.
소프트웨어 테스트에서 테스트 케이스의 목표는 예상 결과에 대한 AUT의 동작을 확인하는 것입니다. 이는 아래와 같이 문서화되어야 합니다.
| 테스트 케이스 # | 테스트 케이스 Descript이온 | 테스트 데이터 | 예상 결과 |
|---|---|---|---|
| 1 | 유효한 이메일과 비밀번호를 입력하면 응답을 확인합니다. | 이메일: guru99@email.com 비밀번호: lNf9^Oti7^2h |
로그인이 성공해야 합니다 |
테스트 실행 시간 동안 테스터는 예상 결과를 실제 결과와 비교하여 통과 또는 실패 상태를 할당합니다.
| 테스트 케이스 # | 테스트 케이스 Descript이온 | 테스트 데이터 | 예상 결과 | 실제 결과 | 통과 실패 |
|---|---|---|---|---|---|
| 1 | 유효한 이메일과 비밀번호를 입력하면 응답을 확인합니다. | 이메일: guru99@email.com 비밀번호: lNf9^Oti7^2h | 로그인이 성공해야 합니다 | 로그인에 성공했습니다 | 패스 |
단계 5) 테스트 케이스와 별도로 다음과 같은 필드가 있을 수 있습니다.
테스트를 실행하기 전에 반드시 충족되어야 하는 사항을 명시하는 전제 조건입니다. 테스트 케이스의 경우, 전제 조건은 테스트 대상 사이트에 접근하기 위해 브라우저가 설치되어 있어야 한다는 것입니다. 테스트 케이스에는 테스트 케이스가 완료된 후 적용되는 사항을 명시하는 사후 조건도 포함될 수 있습니다. 테스트 케이스의 경우, 사후 조건은 로그인 시간과 날짜가 데이터베이스에 저장되어야 한다는 것입니다.
테스트 케이스의 핵심 요소
표준 테스트 사례에는 일반적으로 다음이 포함됩니다.
- 테스트 케이스 ID – 고유 식별자(예: TC001)
- 제목 또는 Descript이온 – 테스트에서 검증하는 내용
- 전제 조건 – 테스트 시작 전에 존재해야 하는 것
- 테스트 단계 – 수행할 정확한 작업
- 테스트 데이터 – 입력 값 또는 매개변수
- 예상 결과 – 당신이 봐야 할 결과
- 실제 결과 – 실제로 무슨 일이 일어났나요?
- Status – 통과, 실패 또는 차단
테스트 케이스 대 테스트 시나리오
A 테스트 시나리오 테스트해야 할 사항, 즉 광범위한 기능이나 사용자 여정을 설명합니다.
A 테스트 케이스, 반면에 해당 기능이 어떻게 검증될 것인지, 즉 정확한 단계, 데이터, 예상 결과를 설명합니다.
간단히 말해서 :
- 테스트 시나리오 = 아이디어 무엇을 테스트할 것인가.
- 테스트 케이스 = 구현 그 아이디어를 테스트하는 방법에 대해서.
이렇게 생각해 보세요.
"테스트 시나리오가 장의 제목이라면, 각 테스트 사례는 해당 장을 자세히 설명하는 단락입니다."
예시 그림:
더 명확하게 설명하기 위해 예를 들어 보겠습니다.
테스트 시나리오 :
"웹사이트의 로그인 기능을 확인하세요."
관련 테스트 사례:
- 유효한 사용자 이름과 비밀번호로 로그인을 확인하세요.
- 잘못된 비밀번호로 인한 오류 메시지를 확인하세요.
- 빈 필드로 로그인을 확인하세요.
- 비밀번호 확인 필드는 입력 텍스트를 숨깁니다.
여기서 시나리오는 다음과 같습니다. 단일 기능적 목표, 테스트 케이스는 그것을 다음과 같이 나눕니다. 구체적이고 검증 가능한 조건.
자세한 내용은 다음을 참조하세요. 테스트 케이스와 테스트 시나리오의 차이점
고품질 테스트 케이스 작성의 이점
- 고품질 테스트 케이스는 철저한 테스트 범위, 일관성, 그리고 전체 QA 프로세스에 걸친 추적성을 제공합니다.
- 그들은 테스터가 잡을 수 있도록 도와줍니다 버그가 일찍 발견되면 유지하다 회귀 안정성모든 기능이 비즈니스 요구 사항에 부합하도록 보장합니다.
- 잘 작성된 테스트 케이스는 다음과 같습니다. 명확하고 재사용 가능하며 반복 가능합니다. 모든 테스터나 자동화 도구가 안정적으로 실행할 수 있습니다.
- 그들은 또한 다음과 같은 역할을 합니다. 커뮤니케이션 브리지 개발자, 테스터, 이해관계자 간의 소통을 원활하게 하여 모호성을 줄이고 시간을 절약합니다.
- 테스트 목표, 단계 및 결과를 문서화함으로써 팀은 다음을 수행할 수 있습니다. 진행 상황 측정, 표준 준수 효율적으로 업데이트를 관리하세요.
- 가장 중요한 것은 좋은 테스트 케이스입니다. 유지 보수 비용을 절감하고, 자동화를 가속화하고 제공합니다 소프트웨어 품질에 대한 확신.
- 이는 새로운 테스터를 온보딩하기 위한 생생한 문서로 사용되며 AI 및 테스트 관리 도구.
테스트 케이스 작성 시 피해야 할 일반적인 실수
경험이 풍부한 테스터조차도 테스트 품질을 약화시키는 작은 실수를 저지릅니다.
이러한 실수를 피하면 극적으로 개선될 수 있습니다. 정확성, 명확성 및 유지 관리성 테스트 모음의.
- 모호한 단계를 작성합니다. "로그인 페이지 확인"과 같은 모호한 지침은 테스터를 혼란스럽게 합니다. 명확하고 실행 가능한 단계를 사용하세요.
- 부정적인 시나리오 건너뛰기: 전체 범위를 보장하려면 항상 잘못된 입력이나 경계 테스트를 포함하세요.
- 불분명한 테스트 데이터 재사용: 레이블이 없거나 일관성이 없는 데이터는 테스트 결과를 신뢰할 수 없게 만듭니다. 공유 테스트 데이터 시트를 유지하세요.
- 테스트 케이스를 너무 복잡하게 만들기: 길고 여러 단계로 구성된 사건은 관리하기 어렵습니다. 각 사건을 집중적이고 세부적으로 관리하세요.
- 제품 변경 후 업데이트 무시: 오래된 테스트 사례는 잘못된 결과를 낳습니다. Rev정기적으로 검토하고 수정하세요.
- 추적 불가능: 적용 범위와 규정 준수를 추적하려면 항상 테스트 사례를 요구 사항에 연결하세요.
- 동료 평가 건너뛰기: 새로운 시각으로 보면 불분명하거나 중복되는 단계를 일찍 발견할 수 있습니다.
