测试计划

测试计划是一份详细的文档，描述了软件的测试区域和活动。它概述了测试策略、目标、测试计划、所需资源（人力、软件和硬件）、测试估算和测试交付物。

测试计划是每个软件测试的基础。它是确保所有计划活动列表以适当顺序可用性的最关键活动。

测试计划是按照一个由测试经理完全监控和控制的定义流程来执行软件测试活动的模板。测试计划由测试负责人 (60%)、测试经理 (20%) 和测试工程师 (20%) 准备。

测试计划的类型

测试计划有三种类型

• 主测试计划
• 阶段测试计划
• 特定类型的测试计划

主测试计划

主测试计划是一种包含多个测试级别的测试计划。它包含完整的测试策略。

阶段测试计划

阶段测试计划是针对测试策略的任何一个阶段的测试计划。例如，工具列表、测试用例列表等。

特定测试计划

为主要测试类型（如安全测试、负载测试、性能测试等）设计的特定测试计划。换句话说，为非功能性测试设计的特定测试计划。

如何编写测试计划

制定测试计划是测试管理过程中最关键的任务。根据 IEEE 829 标准，请遵循以下七个步骤来准备测试计划。

• 首先，分析产品结构和架构。
• 现在设计测试策略。
• 定义所有测试目标。
• 定义测试区域。
• 定义所有可用资源。
• 以适当的方式安排所有活动。
• 确定所有测试交付物。

测试计划组件或属性

测试计划包含各种部分，有助于我们推导出整个测试活动。

目标：它包含关于模块、功能、测试数据等的信息，这些信息表明了应用程序的目标，即应用程序的行为、目标等。

范围：它包含需要与应用程序相关的方面进行测试的信息。范围可进一步分为两部分

• 在范围内
• 范围外

在范围内：这些是需要严格（详细）测试的模块。

范围外：这些是无需严格测试的模块。

例如，假设我们有一个 Gmail 应用程序要测试，其中要测试的功能包括撰写邮件、已发送邮件、收件箱、草稿，而不应测试的功能包括帮助等。这意味着在计划阶段，我们将根据产品给定的时间限制来决定要检查哪些功能。

现在如何决定哪些功能不应测试？

我们有以下方面可以决定哪些功能不应测试

• 如上所述，帮助功能不打算测试，因为它是由技术作家编写并由另一位专业作家审查的。
• 假设我们有一个应用程序具有P、Q、R 和 S 功能，这些功能需要根据需求进行开发。但在这里，S 功能已被其他公司设计和使用。因此，开发团队将从那家公司购买 S，并集成 P、Q 和 R 等附加功能。

现在，我们不会对 S 功能执行功能测试，因为它已在实际中使用。但我们将对 P、Q、R 和 S 功能之间进行集成测试和系统测试，因为新功能可能无法与 S 功能正常工作，如下图所示

• 假设在产品的第一个版本中，已开发了P、Q、R、S、T、U、V、W……X、Y、Z 等元素。现在客户将提供新功能的需求，以改进第二个版本的产品，新功能是A1、B2、C3、D4 和 E5。

之后，我们将在测试计划中编写范围，如下所示

范围

要测试的功能

A1、B2、C3、D4、E5（新功能）

P、Q、R、S、T

不应测试的功能

W……X、Y、Z

因此，我们将首先检查新功能，然后继续检查旧功能，因为它们在添加新功能后可能会受到影响，这意味着它也会影响影响区域，所以我们将对 P、Q、R……T 功能进行一轮回归测试。

测试方法

它包含关于在应用程序上执行各种测试（如功能测试、集成测试和系统测试等）的信息。在此，我们将根据应用程序的要求决定对各种功能执行哪种类型的测试。在这里，我们还应该定义我们将使用哪种测试方法，以便每个人，如管理层、开发团队和测试团队，都能轻松理解，因为测试术语不是标准的。

例如，对于独立的应用程序，如Adobe Photoshop，我们将执行以下类型的测试

烟雾测试→功能测试→集成测试→系统测试→随机测试→兼容性测试→回归测试→全球化测试→可访问性测试→可用性测试→可靠性测试→恢复测试→安装或卸载测试

假设我们要测试 https://www.jeevansathi.com/ 应用程序，那么我们将执行以下类型的测试

方法

此属性用于描述在执行测试时应用程序的流程以及供将来参考。

我们可以通过以下方面来理解应用程序的流程

• 通过编写高层场景
• 通过编写流程图

通过编写高层场景

例如，假设我们正在测试Gmail应用程序

• 登录 Gmail - 发送电子邮件并检查是否在已发送邮件页面
• 登录……。
• ……
• ……

我们编写这些是为了描述要用于测试产品的方​​法，并且仅针对关键功能，我们将编写高层场景。在这里，我们不会专注于涵盖所有场景，因为由特定测试工程师决定要测试哪些功能。

通过编写流程图

编写流程图是因为编写高层场景是一个耗时的过程，正如我们在下图中看到的

我们创建流程图以带来以下好处

• 易于覆盖
• 易于合并

方法可分为以下两部分

• 自上而下的方法
• 自下而上的方法

假设

它包含有关在测试过程中可能出现的问题或故障的信息，并且在编写测试计划时，会做出确定的假设，例如资源和技术等。

风险

这些是我们为了在当前版本中测试应用程序而需要面对的挑战，如果假设失败，则会涉及风险。

例如，应用程序受到的影响是发布日期被推迟。

缓解计划或应急计划

这是一个为克服风险或问题而准备的备用计划。

让我们一起看一个关于假设、风险和应急计划的例子，因为它们是相互关联的。

在任何产品中，我们的假设是所有 3 名测试工程师都将留到产品完成为止，并且他们每个人都被分配了不同的模块，如 P、Q 和 R。在此特定场景中，风险可能是如果测试工程师在项目中间离开。

因此，应急计划是为每个功能分配主要负责人和次要负责人。这样，如果一名测试工程师离开，次要负责人将接管该特定功能，并帮助新测试工程师，以便他/她可以理解他们分配的模块。

假设、风险和缓解或应急计划始终针对产品本身。各种风险类型如下

• 客户视角
• 资源方法
• 技术意见

角色与职责

它定义了整个测试团队需要执行的完整任务。当一个大项目出现时，测试经理是编写测试计划的人。如果有 3-4 个小型项目，那么测试经理会将每个项目分配给每个测试负责人。然后，测试负责人编写他/她所分配项目的测试计划。

让我们看一个例子，从中我们可以理解测试经理、测试负责人和测试工程师的角色和职责。

角色：测试经理

姓名：Ryan

责任

• 准备（编写和审查）测试计划
• 与开发团队开会
• 与测试团队开会
• 与客户开会
• 每月召开一次站立会议
• 签发发布说明
• 处理升级和问题

角色：测试负责人

姓名：Harvey

责任

• 准备（编写和审查）测试计划
• 主持每日站立会议
• 审查和批准测试用例
• 准备 RTM 和报告
• 分配模块
• 处理计划

角色：测试工程师 1、测试工程师 2 和测试工程师 3

姓名：Louis, Jessica, Donna

分配模块：M1、M2 和 M3

责任

• 编写、审查和执行测试文档，包括测试用例和测试场景
• 阅读、审查、理解和分析需求
• 编写应用程序流程
• 执行测试用例
• 相应模块的 RTM
• 缺陷跟踪
• 准备测试执行报告并将其传达给测试负责人。

调查表

它用于解释工作时间，需要做什么，或者这个属性涵盖了每个测试活动何时开始和结束？并且还为特定日期的每个测试活动提供了确切的数据。

因此，正如我们在下图中看到的，对于特定活动，将有一个开始日期和结束日期；对于每个特定构建的测试，将有一个指定日期。

例如

• 编写测试用例
• 执行过程

缺陷跟踪

这通常借助工具完成，因为我们无法手动跟踪每个错误的狀態。我们还评论了在测试过程中发现的错误如何发送给开发团队以及开发团队如何回复。这里我们也提到了错误的优先级，如高、中、低。

以下是缺陷跟踪的各种方面

• 跟踪错误的技巧
  ……
  ……
  ……
  ……
• 错误跟踪工具
  我们可以评论将用于跟踪错误的工具名称。一些最常用的错误跟踪工具是 Jira、Bugzilla、Mantis 和 Trac 等。
• 严重程度
  严重性可以是以下
  阻塞者或致命缺陷
  ……
  ……（在测试计划中举例说明）
  例如，模块中存在缺陷，我们无法继续测试其他模块，因为如果错误被阻塞，我们就无法继续检查其他模块。
  批判性
  ……
  ……（在测试计划中举例说明）
  在这种情况下，缺陷将影响业务。
  主要
  …….
  ……（在测试计划中举例说明）
  次要
  ……
  ……（在测试计划中举例说明）
  这些缺陷会影响应用程序的外观和感觉。
• 优先权
  高-P1
  ……
  中-P2
  ……
  低-P3
  ……
  ……
  P4

因此，基于错误优先级（如高、中、低），我们将将其归类为 P1、P2、P3 和 P4。

测试环境

这些是我们将在其中测试应用程序的环境，这里有两种环境，即软件和硬件配置。

软件配置是指有关各种操作系统（如Windows、Linux、UNIX 和 Mac）和各种浏览器（如Google Chrome、Firefox、Opera、Internet Explorer 等）的详细信息。

而硬件配置则指有关各种大小的RAM、ROM 和处理器的信息。

例如

• 软件包括以下内容

Server (服务器版)

注意：以上服务器是测试团队用于测试应用程序的服务器。

客户

注意：以上详细信息提供了测试团队将用于测试应用程序的各种操作系统和浏览器。

• 硬件包括以下内容

服务器：Sun StarCat 1500

此特定服务器可供测试团队测试其应用程序。

客户

它具有以下配置，如下所示

注意：它将提供测试团队的系统配置。

• 安装软件的流程
  ……
  ……
  ……

开发团队将提供安装软件的配置。如果开发团队尚未提供流程，我们将将其写为测试计划中的基于任务的开发（TBD）。

入口和出口标准

这是在开始和停止测试过程之前需要满足的必要条件。

入口标准

入口标准包含以下条件

• 白盒测试应已完成。
• 理解和分析需求并准备测试文档，或当测试文档准备就绪时。
• 测试数据应已准备好。
• 构建或应用程序必须已准备好
• 模块或功能需要分配给不同的测试工程师。
• 必要的资源必须准备好。

出口标准

出口标准包含以下条件

• 当所有测试用例都已执行。
• 大多数测试用例必须通过。
• 取决于错误的严重性，这意味着不应有任何阻塞性或主要错误，而应存在一些次要错误。

在开始执行功能测试之前，应遵循以上所有入口标准。在执行功能测试并进行集成测试之前，应遵循功能测试的出口标准，因为出口标准的百分比由开发和测试经理之间的会议决定，因为他们的协作可以达到百分比。但是，如果不遵循功能测试的出口标准，我们就无法继续进行集成测试。

这里根据错误的严重性，意味着测试团队将决定是否继续进行下一阶段。

测试自动化

在此，我们将决定以下内容

• 哪些功能需要自动化，哪些不需要自动化？
• 我们将使用哪种自动化测试工具，采用哪种自动化框架？

我们只在第一个版本之后自动化测试用例。

这里出现的问题是，我们将根据什么来决定哪些功能需要测试？

在上图中，正如我们所见，最常用的功能需要反复测试。假设我们要检查 Gmail 应用程序，其中基本功能是撰写邮件、已发送邮件和收件箱。所以我们会测试这些功能，因为在手动测试过程中，它花费的时间更长，而且也变得单调乏味。

现在，我们如何决定哪些功能不应测试？

假设 Gmail 应用程序的帮助功能不应反复测试，因为这些功能不经常使用，所以我们不需要频繁检查。

但是如果某些功能不稳定且有很多错误，这意味着我们不会测试这些功能，因为在手动测试期间需要反复测试。

如果有一个功能需要频繁测试，但我们预计该功能的需求会发生变化，所以我们不检查它，因为更改手动测试用例比更改自动化测试脚本更方便。

工作量估算

在此，我们将计划每位团队成员需要投入的工作量。

测试交付物

这些是来自测试团队的输出文档，我们将其与产品一起交给客户。它包括以下内容

• 测试计划
• 测试用例
• 测试脚本
• RTM（需求可追溯性矩阵）
• 缺陷报告
• 测试执行报告
• 图表和指标
• 发行说明

图表和指标

Graph

在此，我们将讨论我们将发送的图表类型，并且我们还将提供每个图表的样本。

正如我们所看到的，我们有五个不同的图表，显示了测试过程的各个方面。

图 1：在此，我们将显示每个模块已识别出多少缺陷以及已修复多少缺陷。

图 2：图 1 显示了每个模块已识别出多少严重、主要和次要缺陷，以及为各自模块修复了多少。

图 3：在此特定图表中，我们表示版本图，这意味着在每个版本中，每个模块已识别和修复了多少缺陷。基于模块，我们确定了错误。我们将添加R来显示 P 和 Q 中的缺陷数量，我们还添加S来显示 P、Q 和 R 中的缺陷。

图 4：测试负责人将设计错误趋势分析图，该图每月创建并发送给管理层。这就像产品结束时进行的预测。而且，我们还可以对错误修复进行评级，正如我们在下面的图像中观察到的，弧线有一个向上的趋势。

图 5：测试经理设计了这种类型的图表。此图表旨在了解错误评估中的差距以及实际发生的错误，此图表也有助于改进未来的错误评估。

指标

如上所述，我们创建了图 1 中的错误分布图，并利用上述数据，我们还将设计指标。

例如

在上图中，我们保留了特定项目中所有测试工程师的记录，以及已识别和修复的缺陷数量。我们还可以将此数据用于未来的分析。当有新需求时，我们可以根据以上指标确定他们之前发现的缺陷数量，将具有挑战性的功能提供给谁进行测试。我们将更好地了解谁可以很好地处理有问题的功能并找到最大数量的缺陷。

发布说明：这是一份在产品发布期间准备并由测试经理签署的文档。

在下图，我们可以看到最终产品已开发并部署给客户，最新发布名称为Beta。

发布说明包括以下内容

• 用户手册。
• 待处理和打开的缺陷列表。
• 已添加、修改和删除的功能列表。
• 产品测试的平台列表（操作系统、硬件、浏览器）。
• 产品未测试的平台。
• 当前版本修复的错误列表，以及上一版本修复的错误列表。
• 安装过程
• 软件版本

例如

假设Beta是应用程序的第二个版本，在第一个版本Alpha发布之后。在第一个版本中发现的一些缺陷已在后续版本中修复。在这里，我们还将指出从 Alpha 版本到 Beta 版本新添加、修改和删除的功能列表。

模板

此部分包含产品中将使用的所有文档的模板，并且所有测试工程师将在项目中仅使用这些模板来维护产品的_一致性_。这里有各种在整个测试过程中使用的模板，例如

• 测试用例模板
• 测试用例审查模板
• RTM 模板
• 错误报告模板
• 测试执行报告

让我们看一个测试计划文档的样本

第 1 页

第 3 页 - 第 18 页

第 20 页

在第 1 页，我们主要填写版本、作者、评论和审查者字段，并在经理批准后，在批准者和批准日期字段中注明详细信息。

测试计划通常由测试经理批准，测试工程师仅审查。当有新功能出现时，我们将修改测试计划并在版本字段中进行必要的修改，然后将其再次发送以供进一步审查、更新和经理批准。每当发生更改时，都必须更新测试计划。在第 20 页，参考文件指定了我们将用于编写测试计划文档的所有文档的详细信息。

注意

谁编写测试计划？

• 测试负责人→60%
• 测试经理→20%
• 测试工程师→20%

因此，从以上我们可以看出，在 60% 的产品中，测试计划由测试负责人编写。

谁审查测试计划？

• 测试负责人
• 测试经理
• 测试工程师
• 顾客
• 开发团队

测试工程师从其模块的角度审查测试计划，测试经理根据客户意见审查测试计划。

谁批准测试计划？

• 顾客
• 测试经理

谁编写测试用例？

• 测试负责人
• 测试工程师

谁审查测试用例？

• 测试工程师
• 测试负责人
• 顾客
• 开发团队

谁批准测试用例？

• 测试经理
• 测试负责人
• 顾客

测试计划指南

• 精简您的测试计划。
• 避免重叠和冗余。
• 如果您认为不需要上面已经提到的某个部分，请删除该部分并继续。
• 具体化。例如，当您将软件系统指定为测试环境的一部分时，请注明软件版本而不是仅名称。
• 避免冗长的段落。
• 尽可能使用列表和表格。
• 根据需要更新计划。
• 不要使用过时且未使用的文档。

测试计划的重要性

• 测试计划为我们的思维指明方向。这就像一本必须遵守的规则书。
• 测试计划有助于确定验证被测软件应用程序质量所需的精力。
• 测试计划有助于外部人员（如开发人员、业务经理、客户等）理解测试细节。
• 测试计划中记录了测试计划、测试策略、测试范围等重要方面，以便管理团队可以审查并将其用于其他类似项目。