测试计划

测试计划是详细的文档，描述了软件测试领域和活动。它概述了测试策略，目标，测试计划，所需的资源(人力资源，软件和硬件)，测试估计和测试可交付成果。

测试计划是每个软件测试的基础。这是最关键的活动，它确保按适当顺序提供所有计划活动清单。

测试计划是一个模板，用于作为定义的过程进行软件测试活动，该过程由测试经理完全监视和控制。测试计划由测试负责人(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/应用程序，因此我们将执行以下类型的测试：

Smoke testing	Functional testing	Integration testing
System testing	Adhoc testing	Compatibility testing
Regression testing	Globalization testing	Accessibility testing
Usability testing	Performance testing

方法

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

我们可以借助以下方面来了解应用程序的流程：

• 通过编写高级方案
• 通过编写流程图

通过编写高级方案

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

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

我们写这篇文章的目的是描述测试产品所必须采取的方法，并且仅针对将要编写高级方案的关键功能。在这里，我们不会专注于涵盖所有场景，因为特定的测试工程师可以决定是否必须测试哪些功能。

通过编写流程图

编写流程图是因为编写高级方案是花费时间的过程，如下图所示：

我们正在创建流程图，以带来以下好处，例如：

• 覆盖范围很容易
• 合并很容易

该方法可以分为以下两个部分：

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

假设条件

它包含有关在测试过程中可能发生的问题或问题的信息，当我们编写测试计划时，可以像资源和技术等那样做出有保证的假设。

风险

这些是我们在当前版本中测试应用程序所需要面对的挑战，如果这些假设失败了，那么就意味着风险。

例如，对于应用程序的影响，发布日期将被推迟。

缓解计划或应急计划

这是准备克服风险或问题的备份计划。

让我们一起看一个假设，风险和应急计划的例子，因为它们彼此关联。

在任何产品中，我们都将假设所有三名测试工程师都将一直呆在那里，直到产品完成为止，并且他们每个人都被分配了不同的模块，例如P，Q和R。在这种特定情况下，风险可能是如果测试工程师将项目留在了项目中间。

因此，应急计划将为每个功能分配主要所有者和下属所有者。因此，如果一位测试工程师离开，则下属所有者将接管该特定功能，并帮助新的测试工程师，以便他/她可以了解他们分配的模块。

假设，风险，缓解或应急计划始终对产品本身准确无误。各种风险如下：

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

角色与责任

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

让我们看一个示例，在该示例中我们将了解测试经理，测试主管和测试工程师的角色和职责。

角色：测试经理

姓名：Ryan

责任：

• 准备(编写和审查)测试计划
• 与开发团队进行会议
• 与测试团队举行会议
• 与客户进行会议
• 每月举行一次站立会议
• 注销发行说明
• 处理升级和问题

角色：测试负责人

姓名：哈维

责任：

• 准备(编写和审查)测试计划
• 举行每日站立会议
• 审查并批准测试用例
• 准备RTM和报告
• 分配模块
• 处理时间表

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

姓名：路易斯，杰西卡，唐娜

分配模块：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和处理器的不同大小的信息。

例如

• 该软件包括以下内容：

服务器

Operating system	Linux
Webserver	Apache Tomcat
Application server	Websphere
Database server	Oracle or MS-SQL Server

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

客户

Operating System	Window XP, Vista 7
Browsers	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7, and Internet Explorer 8

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

• 硬件包括以下内容：

服务器：Sun StarCat 1500

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

客户：

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

Processor	Intal2GHz
RAM	2GB
….	….

注意：它将提供作为测试团队的测试工程师的系统配置。

• 安装软件的过程………..…..

开发团队将提供如何安装软件的配置。如果开发团队尚未提供该过程，那么我们将在测试计划中将其写为基于任务的开发(TBD)。

进入和退出标准

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

入学标准

进入条件包含以下条件：

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

退出标准

退出条件包含以下条件：

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

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

在这里，基于漏洞的严重性意味着测试团队将决定进一步进行下一阶段。

测试自动化

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

• 哪些功能必须自动化而不是自动化?
• 我们将在哪种自动化框架上使用哪种测试自动化工具?

仅在第一个版本发布后，我们才能自动化测试用例。

这里出现的问题是，我们将在什么基础上决定必须测试哪些功能?

在上图中，我们可以看到最常用的功能需要反复测试。假设我们必须检查Gmail应用程序，其基本功能是“撰写邮件”，“已发送邮件”和“收件箱” 。因此，我们将测试这些功能，因为在执行手动测试时，这会花费更多时间，并且这也成为单调的工作。

现在，我们如何决定不对哪些功能进行测试?

假设由于不经常使用Gmail应用程序的“帮助”功能而未对其进行一次反复的测试，因此我们不需要经常对其进行检查。

但是，如果某些功能不稳定并且有很多错误，这意味着我们将不会测试这些功能，因为在进行手动测试时必须反复测试它。

如果某项功能需要经常进行测试，但是我们希望对该功能进行需求更改，那么我们就不会进行检查，因为与自动化测试脚本中的更改相比，更改手动测试用例更为方便。

努力估算

在此，我们将计划需要每个团队成员都要付出的努力。

测试结果

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

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

图形和指标

图形

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

如我们所见，我们有五个不同的图，它们显示了测试过程的各个方面。

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

图2：图1显示了为每个模块确定了多少严重，主要和次要缺陷，并为各自的模块修复了多少。

Graph3：在此特定图形中，我们表示构建智能图，这意味着在每个构建中，已为每个模块识别并修复了多少缺陷。根据模块，我们确定了错误。我们将添加R来显示P和Q中的缺陷数量，并且还将添加S来显示P，Q和R中的缺陷。

Graph4：测试负责人将设计每月创建的Bug趋势分析图，并将其发送给管理层。就像在产品末期进行的预测一样。在这里，我们还可以对错误修复进行评分，因为我们可以看到下图中的弧线有上升的趋势。

Graph5：测试管理器已经设计了这种类型的图。该图旨在了解对错误的评估与已经发生的实际错误之间的差距，并且该图还有助于改进将来对错误的评估。

指标

如上所述，我们在图1中创建了bug分布图，并且在上述数据的帮助下，我们还将设计指标。

例如

在上图中，我们保留了特定项目中所有测试工程师的记录，以及已发现并修复了多少缺陷。我们也可以将这些数据用于将来的分析。当出现新要求时，我们可以根据上述指标，根据他们较早发现的缺陷数量，决定由谁来提供具有挑战性的测试功能。而且，我们将处于更好的状况，知道谁可以很好地处理有问题的功能并找到最大数量的缺陷。

发行说明：这是一份在产品发行过程中准备并由测试经理签名的文档。

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

发行说明包括以下内容：

• 用户手册。
• 未决和未决缺陷列表。
• 已添加，已修改和已删除功能的列表。
• 测试产品的平台(操作系统，硬件，浏览器)列表。
• 未在其中测试产品的平台。
• 当前版本中已修复的错误列表，以及先前版本中已修复的错误列表。
• 安装过程
• 软体版本

例如

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

模板

此部分包含将在产品中使用的文档的所有模板，并且所有测试工程师都将在项目中仅使用这些模板来维护产品的一致性。在这里，我们在整个测试过程中使用了不同类型的模板，例如：

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

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

第1页

第3页-第18页

第20页

在第1页中，我们主要只填写“版本”，“作者”，“注释”和“审阅者”字段，而在经理批准之后，我们将在“批准者”和“批准日期”字段中提及详细信息。

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

注意：

谁编写测试计划?

• 测试线→60％
• 测试经理→20％
• 测试工程师→20％

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

谁审查测试计划?

• 测试线
• 测试经理
• 测试工程师
• 顾客
• 开发团队

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

谁批准测试计划?

• 顾客
• 测试经理

谁编写测试用例?

• 测试线
• 测试工程师

谁审查测试用例?

• 测试工程师
• 测试线
• 顾客
• 开发团队

谁批准测试用例?

• 测试经理
• 测试线
• 顾客

测试计划指南

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

测试计划的重要性

• 测试计划为我们的思考提供了方向。这就像规则手册，必须遵循。
• 测试计划有助于确定必要的工作，以验证被测软件应用程序的质量。
• 测试计划可帮助那些人了解与外部相关的测试详细信息，例如开发人员，业务经理，客户等。
• 测试计划中记录了测试计划，测试策略，测试范围等重要方面，以便管理团队可以对其进行审查，并将其重新用于其他类似项目。