테스트 계획 템플릿(샘플 문서 예)
토마스 해밀턴
테스트 계획 템플릿이란 무엇입니까?
테스트 계획 템플릿 테스트 전략, 목표, 일정, 추정 및 결과물, 테스트에 필요한 리소스를 설명하는 자세한 문서입니다. 테스트 계획은 테스트 중인 애플리케이션의 품질을 검증하는 데 필요한 노력을 결정하는 데 도움이 됩니다. 테스트 계획은 테스트 관리자가 세부적으로 모니터링하고 제어하는 정의된 프로세스로 소프트웨어 테스트 활동을 수행하기 위한 청사진 역할을 합니다.
만들기 테스트 계획 소프트웨어 테스팅 프로젝트의 성공을 보장하려면 필수입니다. 테스트 계획을 처음 접하는 경우 이 튜토리얼을 참조하세요. 테스트 계획을 세우는 방법
테스트 계획 템플릿
아래에서 테스트 계획의 중요한 구성 요소를 찾으십시오.
- 1 소개
- 1.1 범위
- 1.1.1 범위 내
- 1.1.2 범위 외
- 1.2 품질 목표
- 1.3 역할과 책임
- 2 테스트 방법론
- 2.1 개요
- 2.2 테스트 레벨
- 2.3 버그 분류
- 2.4 정지 기준 및 재개 요구 사항
- 2.5 테스트 완전성
- 3 테스트 결과물
- 4 자원 및 환경 요구 사항
- 4.1 테스트 도구
- 4.2 테스트 환경
1) 소개
프로젝트에 사용된 테스트 전략, 프로세스, 작업 흐름 및 방법론에 대한 간략한 소개
1.1) 범위
1.1.1) 범위 내
범위는 소프트웨어의 특징, 기능적 또는 비기능적 요구사항을 정의합니다. 될거야 테스트
1.1.2) 범위 외
범위 외는 소프트웨어의 특징, 기능적 또는 비기능적 요구 사항을 정의합니다. 수 없습니다 테스트
1.2) 품질 목표
여기에서는 수동 테스트 및 자동화 테스트를 통해 달성하려는 전반적인 목표를 언급합니다.
테스트 프로젝트의 일부 목표는 다음과 같습니다.
- 테스트 대상 애플리케이션이 기능적 및 비기능적 요구사항을 준수하는지 확인하세요.
- AUT가 고객이 정의한 품질 사양을 충족하는지 확인하세요.
- 버그/문제는 라이브로 시작하기 전에 식별되고 수정됩니다.
1.3) 역할과 책임
다음과 같은 다양한 팀 구성원의 역할과 책임에 대한 자세한 설명
- 품질 관리 분석가
- 테스트 관리자
- 구성 관리자
- 개발자
- 설치 팀
그 중에서도
2) 테스트 방법론
2.1) 개요
프로젝트에 특정 테스트 방법론을 채택한 이유를 언급하세요. 프로젝트를 위해 선택된 테스트 방법론은 다음과 같습니다.
- 폭포
- 반복적 인
- 기민한
- 익스트림 프로그래밍
선택한 방법론은 여러 요인에 따라 달라집니다. 테스트 방법론에 대해 읽을 수 있습니다. LINK
2.2) 테스트 수준
테스트 수준은 테스트 중인 응용 프로그램(AUT)에서 실행될 테스트 유형을 정의합니다.). 테스트 수준은 주로 프로젝트 범위, 시간 및 예산 제약에 따라 달라집니다.
2.3) 버그 분류
분류의 목표는 다음과 같습니다.
- 각 버그에 대한 해결 유형을 정의하려면
- 버그의 우선순위를 정하고 모든 "버그 수정 예정"에 대한 일정을 결정합니다.
2.4) 정지 기준 및 재개 요건
일시 중지 기준은 테스트 절차의 전부 또는 일부를 일시 중지하는 데 사용되는 기준을 정의하는 반면, 재개 기준은 일시 중지된 테스트를 언제 재개할 수 있는지 결정합니다.
2.5) 테스트 완전성
여기에서 테스트가 완료되었다고 판단할 기준을 정의합니다.
예를 들어, 테스트 완전성을 확인하는 몇 가지 기준은 다음과 같습니다.
- 100% 테스트 커버리지
- 모든 수동 및 자동 테스트 케이스 실행
- 열려 있는 모든 버그가 수정되었거나 다음 릴리스에서 수정될 예정입니다.
3) 테스트 결과물
여기에서는 테스트 수명 주기의 여러 단계에서 제공될 모든 테스트 아티팩트를 언급합니다.
간단한 결과물은 이렇습니다
|
4) 자원 및 환경 요구
4.1) 테스트 도구
다음과 같은 도구 목록을 만드세요.
프로젝트 테스트에 필요
4.2) 테스트 환경
최소값을 언급합니다 하드웨어 애플리케이션을 테스트하는 데 사용될 요구 사항입니다.
수행원 소프트웨어 클라이언트별 소프트웨어 외에 추가로 필요합니다.
- Windows 8 이상
- Office 2013 이상
- MS익스체인지 등
5) 용어/약어
프로젝트에 사용된 용어나 약어를 언급하세요.
| 용어/약어 | 정의 |
|---|---|
| API | 애플리케이션 프로그램 인터페이스 |
| AUT | 테스트 중인 애플리케이션 |
샘플 테스트 계획 문서 뱅킹 웹 애플리케이션 예
1 소개
테스트 계획은 Guru99 Bank 프로젝트의 모든 테스트 활동의 범위, 접근 방식, 리소스 및 일정을 규정하기 위해 설계되었습니다.
이 계획에서는 테스트할 항목, 테스트할 기능, 수행할 테스트 유형, 테스트를 담당하는 인력, 테스트를 완료하는 데 필요한 리소스와 일정, 계획과 관련된 위험 등을 식별합니다.
1.1 범위
1.1.1 범위 내
소프트웨어 요구사항에 정의된 웹사이트Guru99 Bank의 모든 기능 명세서 테스트를 받아야 한다
| 모듈 이름 | 적용 가능한 역할 | 기술설명 |
|---|---|---|
| 잔액 조회 | 관리자 고객 |
빠른 : 고객은 여러 개의 은행 계좌를 가질 수 있습니다. 자신의 계좌 잔액만 확인 매니저: 관리자는 모든 고객의 잔액을 볼 수 있습니다. 그의 감독을 받다 |
| 자금 이체 | 관리자 고객 |
고객 : 고객은 자신의 "자신"으로부터 자금을 이체할 수 있습니다. 어떤 대상 계정으로든 송금 가능. 매니저: 관리자는 모든 소스 은행에서 자금을 이체할 수 있습니다. 계정에서 대상 계정으로 |
| 미니 문 | 관리자 고객 |
미니 명세서에는 계정의 최근 5개 거래가 표시됩니다. 고객 : 고객은 자신의 "소유"에 대한 미니 명세서만 볼 수 있습니다. 계정 매니저 : 관리자는 모든 계정의 간략한 명세서를 볼 수 있습니다. |
| 맞춤형 명세서 | 관리자 고객 |
사용자 정의 명세서를 사용하면 필터링하고 표시할 수 있습니다. 날짜, 거래 가치에 따른 계정 내 거래 고객 : 고객은 맞춤형-만 볼 수 있습니다. 그의 "자신의" 계정 매니저: 관리자는 모든 사용자 정의 명세서를 볼 수 있습니다. 계정 |
| 비밀번호를 변경 | 관리자 고객 |
고객 : 고객은 본인 계정의 비밀번호만 변경할 수 있습니다. 매니저: 관리자는 자신의 계정의 비밀번호만 변경할 수 있습니다. 그는 고객의 비밀번호를 변경할 수 없습니다. |
| 새로운 고객 | 매니저 | 매니저: 관리자가 새로운 고객을 추가할 수 있습니다. |
| 매니저 |
매니저 : 관리자는 주소, 이메일 등의 세부 정보를 편집할 수 있습니다. 고객의 전화번호. |
|
| 새 계정 | 매니저 |
현재 시스템은 2가지 유형의 계정을 제공합니다. • 저장 • 현재의 고객은 여러 개의 저축 계좌를 가질 수 있습니다(자신의 이름으로 하나, (공동명의 다른 사람 등) 그는 여러 회사에 대해 여러 개의 당좌예금을 가질 수 있습니다. 그는 소유하고 있습니다. 또는 그는 여러 개의 당좌 및 저축 계좌를 가질 수 있습니다. 매니저 : 관리자는 기존 계정에 새 계정을 추가할 수 있습니다. 고객. |
| 계정 수정 | 매니저 | 매니저 : 관리자는 기존 계정에 대한 계정 세부 정보를 추가하고 편집할 수 있습니다. |
| 계정 삭제 | 매니저 | 매니저 : 관리자는 고객의 계정 삭제를 추가할 수 있습니다. |
| 고객 삭제 | 매니저 |
고객은 활성 당좌 또는 저축 계좌가 없는 경우에만 삭제할 수 있습니다. 매니저 : 관리자는 고객을 삭제할 수 있습니다. |
| 입금 | 매니저 |
매니저 : 관리자는 모든 계좌에 돈을 입금할 수 있습니다. 일반적으로 은행 지점에 현금을 입금할 때 이루어집니다. |
| 취소 | 매니저 |
매니저 : 관리자는 모든 계좌에서 돈을 인출할 수 있습니다. 일반적으로 은행 지점에서 현금을 인출할 때 이루어집니다. |
1.1.2 범위 외
이러한 기능은 소프트웨어 요구 사항 사양에 포함되어 있지 않으므로 테스트되지 않습니다.
- 사용자 인터페이스
- 하드웨어 인터페이스
- 소프트웨어 인터페이스
- 데이터베이스 논리
- 통신 인터페이스
- 웹사이트 보안 및 성능
1.2 품질 목표
테스트 목표는 다음과 같습니다. 확인 웹사이트 Guru99 Bank의 기능, 프로젝트는 테스트에 중점을 두어야 합니다. 은행업무 계좌 관리, 출금, 잔액 등. 에게 보증 이 모든 작업이 작동할 수 있습니다 일반적으로 실제 비즈니스 환경에서
1.3 역할 및 책임
프로젝트는 다음을 사용해야 합니다. 외주 프로젝트 비용을 절약하기 위해 구성원을 테스터로 참여시킵니다.
| 그렇지 않습니다. | 회원 | 작업 |
|---|---|---|
| 1. | 테스트 관리자 | 전체 프로젝트 관리 프로젝트 방향 정의 적절한 자원 확보 |
| 2. | Test | 적절한 테스트 기술/도구/자동화 아키텍처 식별 및 설명 테스트 접근 방식 검증 및 평가 테스트를 실행하고, 결과를 기록하고, 결함을 보고합니다. 아웃소싱 회원 |
| 3. | 테스트 중인 개발자 | 테스트 케이스, 테스트 프로그램, 테스트 스위트 등을 구현합니다. |
| 4. | 테스트 관리자 | 테스트 환경과 자산이 관리되고 유지되도록 구축하고 보장합니다. 테스트 실행을 위해 테스트 환경을 사용하도록 테스터를 지원합니다. |
| 5. | SQA 회원 | 품질보증을 맡다 테스트 프로세스가 지정된 요구 사항을 충족하는지 확인하십시오. |
2 테스트 방법론
2.1 개요
2.2 테스트 레벨
Guru99 Bank 프로젝트에서는 3가지 유형의 테스트를 수행해야 합니다.
- 통합 테스트(개별 소프트웨어 모듈을 그룹으로 결합하여 테스트)
- 시스템 테스트: 완전한, 통합 된 지정된 요구사항에 대한 시스템의 준수 여부를 평가하는 시스템
- API 테스팅: 테스트 중인 소프트웨어에 대해 생성된 모든 API를 테스트합니다.
2.3 버그 분류
2.4 정지 기준 및 재개 요구 사항
팀원들이 다음 사항을 보고하는 경우 40% 테스트 케이스 실패한, 개발팀이 실패한 사례를 모두 수정할 때까지 테스트를 일시 중단하세요.
2.5 테스트 완전성
- 다음을 나타내는 기준을 지정합니다. 성공한 테스트 단계 완료
- 달리기 요율은 필수입니다 100% 명확한 이유가 주어지지 않는 한.
- 패스 비율은 80 %를 합격률을 달성하는 것은 필수
2.6 프로젝트 과제와 추정 및 일정
| 태스크 | 회원 | 노력 추정 |
|---|---|---|
| 테스트 사양 만들기 | 테스트 디자이너 | 170인시 |
| 테스트 실행 수행 | 테스터, 테스트 관리자 | 80인시 |
| 시험 보고서 | 시험 장치 | 10인시 |
| 테스트 납품 | 20인시 | |
| 금액 | 280인시 |
이 작업을 완료하도록 예약
3 테스트 결과물
테스트 결과물은 아래와 같이 제공됩니다.
테스트 단계 전
- 테스트 계획 문서.
- 테스트 케이스 서류
- 테스트 설계 사양.
테스트 중
– 테스트 도구 시뮬레이터.
- 테스트 데이터
– 테스트 추적 가능성 매트릭스 – 오류 로그 및 실행 로그.
테스트 주기가 끝난 후
- 테스트 결과/보고서
- 결함 보고서
- 설치/테스트 절차 지침
- 릴리즈 노트
4 자원 및 환경 요구 사항
4.1 테스트 도구
| 그렇지 않습니다. | 자료 | Descript이온 |
|---|---|---|
| 1. | 서버 | 설치하는 데이터베이스 서버가 필요합니다 MySQL 섬기는 사람 Apache 서버를 설치하는 웹 서버 |
| 2. | 테스트 도구 | 테스트 결과를 사전 정의된 형태로 자동 생성하고 자동화된 테스트 실행이 가능한 테스트 도구 개발 |
| 3. | 네트워크 | 최소 1Mb/s 속도의 LAN 기가비트와 인터넷 회선 5개를 설정하세요. |
| 4. | 컴퓨터 | 최소 4대의 컴퓨터 실행 Windows 7, 램 2GB, CPU 3.4GHZ |
4.2 테스트 환경
여기에는 애플리케이션을 테스트하는 데 사용되는 최소 하드웨어 및 소프트웨어 요구 사항이 언급되어 있습니다.
클라이언트별 소프트웨어 외에 다음 소프트웨어가 필요합니다.
- Windows 11 이상
- Office 2021 이상
- MS익스체인지 등
