测试计划
测试计划
测试计划是描述软件测试领域和活动的详细文档。它概述了测试策略、目标、测试计划、所需资源(人力资源、软件和硬件)、测试估计和测试可交付成果。
测试计划是每个软件测试的基础。它是确保所有计划活动列表按适当顺序可用的最关键的活动。
测试计划是一个模板，用于将软件测试活动作为一个定义的过程进行，由测试经理。测试计划由测试主管(60%)、测试经理(20%) 和测试工程师(20%) 制定。
测试计划的类型
测试计划的三种类型
主测试计划
阶段测试计划
测试类型特定的测试计划
主测试计划
主测试计划是一种具有多个测试级别的测试计划。它包括一个完整的测试策略。
阶段测试计划
阶段测试计划是一种测试计划，它涉及测试策略的任何一个阶段。例如，工具列表、测试用例列表等。
特定测试计划
为安全测试等主要测试类型设计的特定测试计划、负载测试、性能测试等。换句话说，就是为非功能测试设计的特定测试计划。
如何编写测试计划
制定测试计划是测试管理过程中最关键的任务。根据 IEEE 829，请按照以下七个步骤来准备测试计划。
首先，分析产品结构和架构。
现在设计测试策略。
定义所有测试目标。
定义测试区域。
定义所有可用的资源。
以适当的方式安排所有活动。
确定所有测试可交付成果。
测试计划组件或属性
测试计划由各个部分组成，这有助于我们推导出整个测试活动。
目标: 它包含关于模块、特性、测试数据等的信息，这些信息表明应用程序的目标是指应用程序的行为、目标等。
范围: 它包含需要与应用程序各自进行测试的信息。 Scope可以进一步分为两部分:
范围内
范围外
范围内: 这些是需要严格测试(详细)的模块。
范围外: 这些是模块，不需要严格测试。
例如，假设我们有一个 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 等独立应用程序，我们将执行以下类型的测试:
冒烟测试→ 功能测试 →集成测试→系统测试→临时测试→兼容性测试→回归测试→全球化测试→可访问性测试→可用性测试→可靠性测试→恢复测试→安装或卸载测试
| 冒烟测试 |
功能测试 |
集成测试 |
| 系统测试 |
临时测试 |
兼容性测试 |
| 回归测试 |
全局测试 |
无障碍测试 |
| 可用性测试 |
性能测试 |
|
方法
这个属性用来描述应用程序在执行测试时的流程，供以后参考。
我们可以理解在以下方面的帮助下应用程序的流程:
通过编写高级场景
通过编写流程图 通过编写高级场景
例如，假设我们正在测试 Gmail 应用程序:
登录 Gmail-发送电子邮件并检查它是否在"已发送邮件"页面中
登录…….
……
……..
我们写这篇文章是为了描述测试产品必须采取的方法，并且只针对我们将编写高级场景的关键功能。在这里，我们不会专注于涵盖所有场景，因为可以由特定的测试工程师决定哪些功能必须进行测试。
编写流程图是因为编写高级场景需要一点时间，如下图所示:
我们正在创建流程图以实现以下好处，例如:
覆盖很容易
合并很容易
该方法可以分为以下两个部分:
自上而下的方法
自下而上的方法
假设
它包含有关在测试过程中可能发生的问题或问题的信息，当我们编写测试计划时，将做出有保证的假设像资源和技术等。
风险
这些是我们在当前版本中测试应用程序以及假设是否会失败时需要面对的挑战
例如，对应用程序的影响，发布日期推迟。
缓解计划或应急措施计划
它是为克服风险或问题而准备的备用计划。
让我们一起看一个假设、风险和应急计划的例子，因为它们是相互关联。
在任何产品中，我们将做出的假设是所有 3 名测试工程师都会在那里，直到产品完成并分配给他们每个人不同的模块，如 P、Q 和 R。在这个特定场景中，风险可能是如果测试工程师将项目留在其中。
因此， 应急计划将为每个功能分配一个主要和下级所有者。因此，如果一名测试工程师离开，下级所有者将接管该特定功能并帮助新的测试工程师，因此他/她可以理解他们分配的模块。
假设、风险和缓解或应急计划总是针对产品本身的。各种类型的风险如下:
客户视角
资源方法
技术意见
Role & Responsibility
它定义了需要由整个测试团队执行的完整任务。当一个大型项目到来时，测试经理就是编写测试计划的人。如果有 3-4 个小项目，那么测试经理会将每个项目分配给每个测试主管。然后，测试负责人为他/她分配的项目编写测试计划。
让我们看一个例子，让我们了解测试经理、测试主管和测试工程师的角色和职责。
角色: 测试经理
姓名: Ryan
职责:
准备(编写和审查)测试计划
与开发团队召开会议
与测试团队召开会议
与客户进行会面
每月召开一次站立会议
签署发行说明
处理升级和问题
角色: 测试主管
姓名: Harvey
职责:
准备(编写和审查)测试计划
召开每日站立会议
审查并批准测试用例
准备 RTM 和报告
分配模块
处理时间表
角色: 测试工程师 1、测试工程师 2 和测试工程师 3
姓名: 路易斯、杰西卡、唐娜
分配模块: M1、M2 和 M3
职责:
编写、审查和执行由测试用例和测试场景组成的测试文档
阅读、审查、理解和分析需求
编写应用程序的流程
执行测试用例
各个模块的 RTM
缺陷跟踪
准备测试执行报告并将其传达给测试主管。
Schedule
它用于解释工作的时间安排，需要完成哪些工作，或者该属性涵盖每个测试活动的确切开始和结束时间？并且还提到了特定日期的每个测试活动的确切数据。
因此作为我们可以在下图中看到，对于特定的活动，会有一个开始日期和结束日期；对于特定版本的每次测试，都会有指定的日期。
例如
编写测试用例
执行过程
缺陷跟踪
通常是借助工具来完成的，因为我们无法手动跟踪每个错误的状态。我们还评论了我们如何传达在测试过程中发现的错误并将其发送回开发团队以及开发团队将如何回复。这里我们还提到了高、中、低等错误的优先级。
以下是缺陷跟踪的各个方面:
跟踪错误的技术
.....
……
……
……
错误跟踪工具
我们可以评论工具的名称，我们将使用该名称来跟踪错误。一些最常用的错误跟踪工具是 Jira、Bugzilla、Mantis 和 Trac 等。
严重程度
严重程度可能如下:
阻止或阻止
.....
.....(用测试计划中的一个例子)
例如，模块中会有缺陷；我们无法进一步测试其他模块，因为如果错误被阻止，我们可以继续检查其他模块。
关键
……
.....(用测试计划中的示例)
在这种情况下，缺陷会影响业务。
主要
....
....(在测试计划中举例说明)
次要
.....
.....(在测试计划中举例说明)
这些缺陷是那些会影响应用程序外观的。
优先
高 P1
.....
中 P2
.....
低 P3
.....
.....
P4
因此，根据bug的高、中、低优先级，我们将其分为P1、P2、P3和P4、
测试环境
这些是我们将测试应用程序的环境，这里我们有两种类型的环境，分别是软件和硬件配置。
软件配置是指关于不同操作系统的详细信息，例如Windows、Linux、UNIX和Mac以及各种浏览器，例如 Google Chrome、Firefox、Opera、Internet Explorer 等。
硬件配置意味着有关RAM、ROM 和处理器的不同大小的信息。
例如
软件包括以下内容:
服务器
| 操作系统 |
Linux |
| 网络服务器 |
Apache Tomcat |
| 应用服务器 |
网络领域 |
| 数据库服务器 |
Oracle 或 MS-SQL Server |
注意: 以上服务器是测试团队用来测试应用程序的服务。
客户
| 操作系统 |
Windows XP，Vista 7 |
| 浏览器 |
Mozilla Firefox、Google Chrome、Internet Explorer、Internet Explorer 7 和 Internet Explorer 8 |
注意: 以上详细信息提供了测试团队将在其中测试应用程序的各种操作系统和浏览器。
硬件包括以下内容:
服务器: Sun StarCat 1500
测试团队可以使用这个特定的服务器来测试他们的应用程序。
Client:
它有如下配置，如下:
| 处理器 |
Intal2GHz |
| 内存 |
2GB |
| .... |
.... |
注意: 它将提供作为测试团队的测试工程师的系统配置。
软件安装过程
……
.....
.....
开发团队将提供如何安装软件的配置。如果开发团队还没有提供流程，那么我们会在测试计划中将其写为基于任务的开发(TBD)。
进入和退出标准
这是一个必要条件，需要在开始和停止测试过程之前满足。
进入标准
进入标准包含以下条件:
应该完成白盒测试。
理解和分析需求并准备测试文档或测试文档准备好时。
测试数据应该准备好了。
必须准备构建或应用程序
模块或功能需要分配给不同的测试工程师。
必要性必须准备好所有资源。 退出条件
退出条件包含以下条件:
当所有测试用例都执行完毕时。
大多数测试用例必须通过。
取决于错误的严重程度，这意味着不能有任何阻止程序或主要错误，但存在一些小错误。
在开始进行功能测试之前，应遵循上述所有进入标准。在我们进行功能测试之后，在我们进行集成测试之前，应该遵循功能测试的退出标准，因为退出标准的百分比是由开发和测试经理的会议决定的，因为他们的协作可以达到的百分比。但是如果不遵循功能测试的退出标准，那么我们就无法进一步进行集成测试。
这里根据错误的严重性意味着测试团队会决定继续进行下一阶段。
测试自动化
在此，我们将决定以下内容:
哪些功能必须自动化，哪些不能自动化？
我们将在哪个自动化框架上使用哪个测试自动化工具？
我们只有在第一次发布后才自动化测试用例。
这里出现的问题是，我们将决定哪些功能必须
在上图中，我们可以看到最常用的功能需要反复测试。假设我们必须检查 Gmail 应用程序，其中基本功能是撰写邮件、已发送邮件和收件箱。因此，我们将测试这些功能，因为在执行手动测试时，需要更多时间，而且它也变得单调乏味。
现在，我们如何决定不测试哪些功能？
假设 Gmail 应用程序的帮助功能没有经过反复测试，因为这些功能不经常使用，所以我们不需要经常检查。
但是如果某些功能不稳定并且有很多错误，这意味着我们不会测试这些功能，因为它必须在手动测试的同时进行一次又一次的测试。
如果有一个特性需要经常测试，但我们预计该特性的需求会发生变化，所以我们不检查它，因为更改手动测试用例更舒服与自动化测试脚本中的变化相比。
工作量估算
在此，我们将计划每个团队需要应用的工作量我mber.
测试可交付成果
这些是测试团队的输出文件，我们将其与产品一起交给客户。它包括以下内容:
测试计划
测试用例
测试脚本
RTM(需求可追溯性矩阵)
缺陷报告
测试执行报告
图表和指标
发行说明 图形和度量
图形
在这里，我们将讨论的类型我们将发送图表，我们还将提供每个图表的样本。
正如我们所见，我们有五个不同的图表显示了测试过程的各个方面。
Graph1: 在这里，我们将展示在每个模块中已经识别出多少缺陷以及修复了多少缺陷。
图 2: 图 1 显示了每个模块已经确定了多少关键、主要和次要缺陷，以及有多少已针对各自的模块进行了修复。
Graph3: 在此特定的图，我们表示构建明智图，这意味着在每个构建中，每个模块有多少缺陷已被识别和修复。基于模块，我们已经确定了错误。我们将添加 R 来显示 P 和 Q 中的缺陷数量，我们还添加 S 来显示 P、Q 和 R 中的缺陷。
Graph4: 测试负责人将设计错误趋势分析 每月创建的图表并将其发送给管理层。这就像在产品结束时进行的预测一样。在这里，我们还可以对错误修复进行评分，因为我们可以观察到弧形在下图中具有向上趋势。
Graph5: 测试经理设计了这个图的类型。此图旨在了解错误评估与已发生的实际错误之间的差距，此图也有助于改进未来对错误的评估。
指标
如上，我们创建了错误分布图，如图 1 所示，借助上述数据，我们还将设计指标。
例如
上图中我们保留了记录特定项目中所有测试工程师的数量以及已识别和修复的缺陷数量。我们还可以将这些数据用于未来的分析。当新的需求出现时，我们可以根据上述指标，根据他们之前发现的缺陷数量来决定为谁提供具有挑战性的特性进行测试。我们将更好地了解谁能很好地处理有问题的功能并找出最大数量的缺陷。
发布说明: 产品发布并由测试经理签名。
在下图中，我们可以看到最终产品已开发并部署给客户，最新版本名称为Beta.
发行说明包括以下内容:
用户手册。
待处理和开放缺陷列表。
添加、修改和删除的功能列表。
测试产品的平台(操作系统、硬件、浏览器)列表。
产品未经测试的平台。
当前版本中修复的错误列表，以及上一版本中修复的错误列表。
安装过程
软件版本
例如
假设Beta是应用程序的第一个版本Alpha之后的第二个版本强>被释放。在第一个版本中发现的一些缺陷已经在后来的版本中修复了。在这里，我们还会指出从 alpha 版本到 beta 版本的新增、修改和删除的功能列表。
Template
这部分包含了产品中会用到的文档的所有模板，所有的测试工程师只会使用这些模板项目保持产品的一致性。在这里，我们在整个测试过程中使用了不同类型的模板，例如:
测试用例模板
测试用例审查模板
RTM 模板
错误报告模板
测试执行报告
让我们看一个测试计划文档样本
Page-1
Page3-page18
Page-20
In-Page 1，我们主要只填写版本、作者、评论和审阅者 字段，在经理批准后，我们会在批准日期和批准日期字段中提及详细信息。
大部分测试计划由测试经理批准，而测试工程师只对其进行审查。并且当新功能到来时，我们会修改测试计划并在版本字段中做必要的修改，然后再次发送给经理进一步审查、更新和批准。每当发生任何更改时，都必须更新测试计划。在第 20 页，参考资料详细说明了我们将用于编写测试计划文档的所有文档。
注意:
谁编写测试计划？
测试线→60%
测试经理→20%
测试工程师→20%
因此，我们可以从上面看到在 60% 的产品中，测试计划由测试负责人编写。
谁审查测试计划？
测试主管
测试经理
测试工程师
客户
开发团队
测试工程师从他们的模块角度审查测试计划，测试经理根据客户意见审查测试计划。
谁批准测试计划？
客户
测试经理
谁编写测试用例？
测试主管
测试工程师
谁来审查测试用例？
测试工程师
测试主管
客户
开发团队
谁批准测试用例？
测试经理
测试主管
客户
测试计划指南
收起您的测试计划。
避免重叠和冗余。
如果您认为不需要上面已经提到的部分，请删除该部分并继续。
要具体。例如，当您指定一个软件系统作为测试环境的一部分时，请提及软件版本而不仅仅是名称。
避免冗长的段落。
尽可能使用列表和表格。
在需要时更新计划。
不要使用过时和未使用的文档。
测试计划的重要性
测试计划为我们的思考指明了方向。这就像一本必须遵守的规则手册。
测试计划有助于确定验证被测软件应用程序质量所需的工作。
测试计划可帮助这些人了解与开发人员、业务经理、客户等外部相关的测试细节。
测试计划中记录了测试计划、测试策略、测试范围等重要方面，以便管理团队可以对其进行审查并将其重用于其他类似项目。
