测试计划模板（带有 Web 应用程序示例的示例文档）

测试计划是一份详尽的文档，概述了完成软件测试所需的测试策略、目标、时间表、估计、可交付成果和资源。测试计划帮助我们确定确认被测试应用程序质量所需的工作量。测试计划是将软件测试操作作为一个定义的过程进行的蓝图，测试经理密切监视和控制。

根据 ISTQB 的定义，“测试计划是一份详细说明预期测试活动的范围、策略、资源和时间表的文件”。

让我们看一个测试计划的示例/场景：您想在会议上与团队成员讨论测试计划，但他们不感兴趣。

在这种情况下你会怎么做？

A) 我是经理；按照我的指示。

B) 现在，让我解释一下为什么需要测试计划。

什么是测试计划，为什么它很重要？

创建测试计划文档有几个优点。

帮助测试团队以外的其他人了解测试的细微差别，例如开发人员、业务经理和客户。

我们的思考以测试计划为指导。它类似于一组必须遵守的规则。

测试计划记录了重要的特性，例如测试估计、测试范围和测试策略，以便管理团队对其进行评估并重新用于其他项目。

编写测试计划的最佳方法是什么？

您已经知道测试管理过程中最重要的职责是创建测试计划。要根据 IEEE 829 制定测试计划，请遵循以下概述的阶段。

• 检查项目。

• 创建测试策略

• 创建测试目标列表。

• 指定测试标准

• 组织资源

• 搭建测试环境

• 估计和时间表

• 建立测试可交付成果

测试计划模板的定义是什么？

测试计划模板是一份详尽的文档，概述了测试策略、目标、时间表、估计和可交付成果，以及测试所需的资源。测试计划帮助我们确定确认被测试应用程序质量所需的工作量。测试计划是将软件测试操作作为测试经理密切监视和控制的定义过程进行的蓝图。

为了确保任何软件测试项目的成功，您必须首先创建一个测试计划。

下面列出了测试计划的重要组成部分。

• 介绍性段落

• 目的

• 工作范围

• 范围用尽

• 质量保证目标

• 测试方法

• 大图

• 测试级别

• 错误分类

• 暂停要求和暂停标准

• 测试的完整性

• 测试的可交付成果

• 对资源和环境的要求

• 测试仪器

• 测试环境

简要介绍

项目测试技术、流程、工作流程和方法的简要概述

目的

测试计划的目的。

工作范围

被测试程序的范围确定了它的特性、功能和非功能需求。

范围用尽

超出范围是指不会被评估的软件特性、功能性和非功能性需求。

质量目标

• 在本节中记下您希望通过手动和自动测试实现的总体目标。

• 您的一些测试项目的目标可能包括以下内容 -

• 确定被测应用程序符合所有功能和非功能标准。

• 确定 AUT 是否满足客户的质量要求。

• 在上线之前，会检测并纠正错误和问题。

职责和角色

详细描述了各种团队成员的角色和职责，包括 -

• 质量保证分析师

• 测试经理

• 配置经理

• 开发商

• 安装团队

测试方法

一般信息- 说明为什么为项目选择了某种测试方法。项目选择的测试方法可能是

• 瀑布

• 迭代

• 敏捷

• 极限编程 (XP)

多个变量会影响所使用的方法。

测试级别

要对被测应用程序执行的测试类型由测试级别 (AUT) 定义。测试级别通常由项目范围以及时间和金钱限制决定。

错误分类

• 分类的目的是找出您的问题所在。

• 选择将用于每个问题的错误解决方案类型

• 确定问题的优先级并为所有“待修复的错误”设定时间表。

暂停标准和恢复要求

暂停标准提供了可以暂停全部或部分测试过程的条件，而恢复标准则指定了测试一旦中断后何时可以继续。

确保一切正常。

在本节中，您将设置确定测试是否完成的标准。例如，确定测试是否完成的一些标准可能是 -

• 测试覆盖率为 100%。

• 已完成所有手动和自动测试用例。

• 所有未解决的错误都已解决或将在即将发布的版本中解决。

待测试的可交付成果

在整个测试生命周期的各个阶段提供的所有测试工件都将包含在此处。

下面列出了基本的可交付成果。

• 计划测试

• 实例探究

• 需求可追溯性矩阵

• 测试策略

• 测试指标

• 客户认可

环境和资源需求

测试仪器- 列出有用的工具，例如

• 跟踪需求的工具

• 错误跟踪软件

• 自动化工具

项目必须经过测试。

测试环境

它规定了测试应用程序的最低硬件要求。

除了客户端特定的软件外，还需要以下软件。

• Windows 8 及以上版本

• Microsoft Office 2013 及更新版本

• 例如，Microsoft Exchange。

缩写词/术语

提及项目中使用的任何术语或首字母缩略词。

• API 代表“应用程序接口”。

• AUT 代表被测应用

文档银行 Web 应用程序的测试计划示例

介绍性段落

测试计划为 Guru99 Bank 项目的所有测试操作指定了范围、策略、资源和时间安排。

该计划确定要测试的内容、要测试的功能、要进行的测试类型、负责测试的人员、完成测试所需的资源和时间表以及计划的风险。

范围用尽

这些特性不会被评估，因为它们不是软件需求规范的一部分。

• 用户界面

• 与硬件的接口

• 软件接口

• 逻辑数据库

• 通讯接口

• 网站性能和安全

质量保证目标

测试目标是验证网站 Guru99 Bank 的功能。该项目应专注于测试银行操作，例如账户管理、取款和余额等，以确保所有这些操作都能在现实世界的业务环境中正确运行。

职责和角色

为降低项目成本，项目应使用外包人员作为测试人员。

测试方法

测试级别

电子商务网站项目需要进行三类测试。

• 完整性检查（将各个软件模块组合并作为一个组进行测试）

• 系统测试是在一个综合的、集成的系统上完成的，以查看它是否符合系统的要求。

• API 测试 - 验证为被测程序创建的所有 API 是否正常运行。

错误分类

暂停要求和暂停标准- 如果团队成员表示 40% 的测试用例失败，则应暂停测试，直到开发团队修复所有失败的实例。

测试的完整性

• 指定成功完成测试阶段的要求。

• 除非提供有效的理由，否则运行率必须为 100%。

• 通过率设置为80%，需要通过。

项目的任务、估算和时间表

测试的可交付成果

以下是测试可交付成果 -

在测试阶段之前

• 包含测试计划的文档。

• 包含测试用例的文档

• 测试设计规范

在审判期间，

• 用于测试工具的模拟器。

• 测试数据

• 错误日志和执行日志 - 测试追踪能力矩阵

当测试周期完成时，

• 测试报告/结果

• 缺陷报告

• 安装/测试程序指南

• 发行说明

对资源和环境的要求