테스트 케이스 란 무엇입니까?
테스트 사례는 소프트웨어 응용 프로그램의 특정 기능이나 기능을 확인하기 위해 실행되는 일련의 작업입니다.
이 튜토리얼은 테스트 케이스 디자인과 다양한 컴포넌트의 중요성을 설명합니다.
이제 테스트 시나리오 로그인 기능 확인을 고려해보십시오.
테스트 사례 1 : 유효한 사용자 ID 및 비밀번호 입력시 결과 확인
테스트 사례 2 : 유효하지 않은 사용자 ID 및 비밀번호 입력 결과 검사
테스트 케이스 3 : 사용자 ID가 비어 있고 로그인 버튼을 누른 경우 응답 확인
이것은 테스트 케이스에 불과합니다. 테스트 시나리오는 다소 모호하며 다양한 가능성을 제시합니다. 테스트는 모두 매우 구체적이라는 것입니다. 필요합니다. 테스트 케이스가 필요합니다.
- 이제 테스트 케이스를 고려해보십시오. 올바른 에이전트 이름과 암호를 입력 할 때 응답을 확인하십시오. 이 테스트 케이스에는 입력 값, 즉 담당자 이름과 비밀번호가 필요하다는 것은 명백합니다.
- 이것은 테스트 데이터에 불과합니다. 테스트 데이터를 식별하는 데 시간이 오래 걸릴 수 있으며 때때로 테스트 데이터를 새로 만들어야 할 수도 있습니다. (문서화해야하는 이유)
- 우리가 계속 진행하기 전에 "완벽한 목표를 위해 먼저 목표를 세우고 무엇이든 부르십시오"라고 말한 재치있는 사람의 말을 고려해보십시오.하지만이 철학에 의해 살아 가지 않는다면, 대부분 당신이 생각하지 않는 것입니다. 테스트 케이스에 예상 결과가 있어야합니다.
- 테스트 케이스의 경우 예상되는 결과는 로그인이 성공해야한다는 것입니다.
- 예상 결과가 문서화되지 않은 경우 결과가 좋지 않은 것으로 계산 된 작은 차이를 놓칠 수 있습니다.
- 많은 계산이 포함 된 직원의 월급을 계산하는이 예제를 고려하십시오. 기대되는 결과를 문서화 할 필요성이 명백해진다.
- 테스트 케이스 작성자가 퇴사했거나 휴가 중이거나 병이 들거나 다른 업무에 매우 바빠서 최근에 고용되어 테스트 케이스를 수행하라는 요청을 받았다고 가정 해 보겠습니다. 이 경우 테스트 시작 단계가 문서화되어 있어야합니다.이 경우 애플리케이션 시작, 상담원 이름 입력, 암호 입력, 확인을 클릭하십시오.
- 이 간단한 테스트 단계에서는 문서화가 필요하지 않습니다.
- 그러나 테스트 단계는 다음과 같이 보입니다. 필요성이 즉각적으로 명백해질 것이라고 생각한다.
- 테스트 케이스를 따로 따로 구분하면 테스트가 실행되기 전에 필요한 것들을 지정하는 사전 조건과 같은 필드가있을 수 있습니다.
- 테스트 케이스의 경우 사전 조건은 Flight Reservation Application을 설치해야합니다.이 튜토리얼을 시청하는 사람들의 50 %는
- 또한 테스트 케이스에는 테스트 케이스가 완료된 후 적용되는 모든 것을 지정하는 사후 조건이 포함될 수 있습니다.
- 테스트 케이스의 경우 사후 조건은 로그인이 데이터베이스에 저장된 시간 및 날짜입니다.
- 테스트 사례를 실행하는 동안 실제 결과 열에서 관찰 된 결과를 문서화하고 일부 스크린 샷을 첨부 할 수도 있으며 결과에 따라 PASS & FAIL 상태를 표시 할 수 있습니다.
- 이 전체 테이블은 Word, Excel 또는 기타 테스트 관리 도구로 만들 수 있습니다. 테스트 케이스 디자인에 대한 모든 것입니다.
표준 테스트 케이스의 형식
다음은 표준 로그인 테스트 케이스의 형식입니다.
| 테스트 케이스 ID | 테스트 시나리오 | 테스트 단계 | 테스트 데이터 | 예상 결과 | 실제 결과 | 통과 실패 |
|---|---|---|---|---|---|---|
| TU01 | 유효한 데이터로 고객 로그인 확인 |
| 사용자 ID = guru99 암호 = pass99 | 사용자가 애플리케이션에 로그인해야합니다. | 예상대로 | 패스 |
| TU02 | 잘못된 데이터로 고객 로그인 확인 |
| 사용자 ID = guru99 암호 = glass99 | 사용자는 애플리케이션에 로그인해서는 안됩니다. | 예상대로 | 패스 |
테스트 케이스 작성시 다음 정보를 포함 시키십시오.
- 테스트중인 요구 사항에 대한 설명
- 시스템이 테스트되는 방법에 대한 설명
- 테스트중인 응용 프로그램의 버전, 소프트웨어, 데이터 파일, 운영 체제, 하드웨어, 보안 액세스, 물리적 또는 논리적 날짜, 시간, 다른 테스트와 같은 필수 구성 요소 및 테스트중인 요구 사항과 관련된 기타 설정 정보
- 입력 및 출력 또는 동작 및 예상 결과
- 모든 증거 또는 첨부 파일
- 활성 대문자 사용
- 테스트 케이스는 15 단계 이상이어야한다.
- 자동 테스트 스크립트는 입력, 목적 및 예상 결과로 주석 처리됩니다.
- 설치 프로그램은 사전 요구 사항 테스트의 대안을 제공합니다.
- 다른 테스트에서는 잘못된 비즈니스 시나리오 순서 여야합니다.
좋은 테스트 사례 예제 작성을 위한 베스트 프랙티스.
1. 테스트 케이스는 간단하고 투명해야합니다.
테스트 케이스는 가능한 한 간단하게 작성하십시오. 테스트 케이스 작성자가 이를 실행할 수 없으므로 명확하고 간결해야합니다.
홈 페이지로 이동, 데이터 입력, 클릭 등과 같은 독단적 인 언어를 사용하십시오. 이를 통해 테스트 단계를 쉽게 이해하고 실행을 더 빠르게 테스트 할 수 있습니다.
2. 최종 사용자가 테스트 케이스를 작성하십시오.
모든 소프트웨어 프로젝트의 궁극적 인 목표는 고객 요구 사항을 충족하고 사용하기 쉽고 작동하는 테스트 사례를 만드는 것입니다. 테스터는 최종 사용자 관점을 염두에두고 테스트 케이스를 작성해야합니다.
3. 테스트 케이스 반복을 피하십시오.
테스트 사례를 반복하지 마십시오. 다른 테스트 케이스를 실행하기 위해 테스트 케이스가 필요한 경우, 사전 조건 열의 테스트 케이스 ID로 테스트 케이스를 호출하십시오
4. 가정하지 마라.
테스트 케이스를 준비하는 동안 소프트웨어 응용 프로그램의 기능 및 기능을 가정하지 마십시오. 사양 문서에 충실하십시오.
5. 100 % 보장
테스트 케이스를 작성하여 사양 문서에 언급 된 모든 소프트웨어 요구 사항을 확인하십시오. 트레이서 빌리티 매트릭스 를 사용 하여 기능 / 조건을 테스트하지 않은 상태로 두지 않습니다.
6. 시험 경우는 식별 가능해야한다.
나중에 결함을 추적하거나 소프트웨어 요구 사항을 식별하는 동안 쉽게 식별되도록 테스트 케이스 ID의 이름을 지정하십시오.
7. 테스트 기법 구현
소프트웨어 응용 프로그램에서 가능한 모든 조건을 검사 할 수는 없습니다. 테스트 기술을 사용하면 결함을 발견 할 가능성을 최대한 높이면서 몇 가지 테스트 케이스를 선택할 수 있습니다.
BEA (Boundary Value Analysis) : 이름에서 알 수 있듯이 지정된 값 범위에 대한 경계 테스트를 정의하는 기술입니다.
등가 분할 (Equivalence Partition : EP) : 이 기법은 범위를 동일한 동작을하는 경향이있는 동일한 부분 / 그룹으로 분할합니다.
상태 전이 기법 (State Transition Technique) :이 방법은 소프트웨어 동작이 특정 동작에 따라 한 상태에서 다른 상태로 변경 될 때 사용됩니다.
오류 추측 기법 : 이것은 테스트하는 동안 발생할 수있는 오류를 추측 / 예상합니다 . 이것은 공식적인 방법이 아니며 응용 프로그램에 대한 테스터의 경험을 활용합니다
8. 셀프 클리닝
작성한 테스트 케이스는 테스트 환경 을 사전 테스트 상태로 리턴 해야하며 테스트 환경을 사용할 수 없도록 렌더링해서는 안됩니다. 이는 구성 테스트의 경우 특히 그렇습니다.
9. 반복 적이고 자립적 인
테스트 케이스는 테스트 할 때마다 매번 동일한 결과를 생성해야합니다.
10. 동료 검토.
테스트 사례를 작성한 후 동료가 검토하도록합니다. 귀하의 동료는 쉽게 놓칠 수있는 테스트 케이스 디자인의 결함을 발견 할 수 있습니다.
테스트 사례 관리 도구
테스트 관리 도구는 테스트 사례를 관리하고 유지 관리하는 데 도움이되는 자동화 도구입니다. 테스트 케이스 관리 도구의 주요 기능은 다음과 같습니다.
- 테스트 사례 문서화 : 도구를 사용하면 템플릿을 사용하여 테스트 케이스 작성을 신속하게 처리 할 수 있습니다.
- 테스트 케이스를 실행하고 결과를 기록한다 : 테스트 케이스는 도구를 통해 수행 될 수 있으며, 얻어진 결과를 쉽게 기록 할 수 있습니다.
- 결함 추적 자동화 : 실패한 테스트는 자동으로 버그 추적기에 연결되며, 버그 추적기는 개발자에게 할당되며 전자 메일 알림을 통해 추적 할 수 있습니다.
- 이력 추적 성 : 요구 사항, 테스트 케이스, 테스트 사례의 실행은 모두 도구를 통해 상호 연결되며 각 사례는 서로 추적하여 테스트 적용 범위를 확인할 수 있습니다.
- 테스트 케이스 보호 : 테스트 케이스는 재사용 할 수 있어야하며 버전 제어 불량으로 인해 손실되거나 손상되지 않도록 보호해야합니다. 테스트 케이스 관리 도구는 다음과 같은 기능을 제공합니다.
- 이름 지정 및 번호 매기기 규칙
- 버전 관리
- 읽기 전용 저장 장치
- 제어 된 액세스
- 오프 사이트 백업
널리 사용되는 테스트 관리 도구는 다음 과 같습니다 : Quality Center 및 JIRA
자원
- 사용되는 템플릿은 프로젝트마다 다를 수 있습니다.
TestCaseTemplate.xls'블랙박스 테스트' 카테고리의 다른 글
| 요구 사항 추적 성 매트릭스 (RTM)를 만드는 방법 (0) | 2018.11.29 |
|---|---|
| 소프트웨어 테스팅의 테스트 기초는 무엇입니까? (0) | 2018.11.28 |
| 테스트 시나리오에 대해 알아보니.. (0) | 2018.11.26 |
| 회귀 분석이란 무엇입니까? 테스트 사례, 도구 및 예 (0) | 2018.11.25 |
| 새너티 테스트와 연기 테스트 : 소개 및 차이점 (0) | 2018.11.24 |
