软件测试计划

前言

相信大多数的软件测试工程师都听说过或者简单了解过测试计划，但是你真的知道什么是测试计划么？你真的知道如何编写测试计划么？大多数人应该是一脸茫然。百度的结果五花八门，有没有相对规范的标准呢？答案是没有，至少我没有找到。那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。

一、测试计划的定义

• IEEE 829-1983 测试计划的定义及目的
• 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了 测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。
• 软件测试计划是指导测试过程的纲领性文档。计划可以统一认识，可以规划过 程。
• 测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试目标（被测 特征）、测试优先级、测试配置/测试资源<硬件、软件、人力、技术等>、测 试周期、进度安排（测试任务、人员安排）、 测试策略、测试方法/途径、测 试交流、风险分析、测试标准、需交付文档等内容。
  测试计划的注意事项：
  软件测试计划应当尽早的制定
  软件测试计划在测试活动中处于中心位置
  它设定了测试准备工作和执行测试的必备条件
  同时形成了测试过程质量保证的基础

二、测试计划的内容

测试计划.png

1. 测试目的

这部分描述文档内容简要。例如本文档描述XXX项目系统测试的范围、方法、资源、进度。

2. 参考文档

这部分列出进行测试计划的输入文档

3. 测试范围

3.1. 测试对象

描述被测对象：如果被测对象的发布特性随版本不同而不同，需要明确对象版本。对于不属于测试范围的对象，也应该在此进行描述

3.2.需要测试的特性

说明所有需要测试的对象的特性以及特性组合。
前端、移动端、后端、小程序各个系统功能

3.3. 不需要测试的特性

说明所有不需要测试的对象的特性以及特性组合。

序号	邮箱的测试范围	说明
1	外观界面测试	检查邮箱的界面是否符合需求文档中所要求的界面 是否美观、合理和人性化
2	功能测试	根据需求文档检查邮箱的主要功能是否正确的实现
3	易用性测试	检查邮箱是否操作简单、易用、是否符合通用的操作习惯
4	兼容性测试	检查邮箱与市面上主流浏览器的兼容性，例如360浏览器、 Firefox60、QQ浏览器、搜狗浏览器等等
5	安全性测试	检查邮箱是否达到需求文档中的安全要求，是否存在安全隐患
6	性能测试	检查邮箱是否达到了需求文档中所定义的性能要求

4. 测试资源

4.1. 软件需求

这部分描述测试需要的软件的版本、LICENSE数量

资源	描述	数量
服务器	操作系统： Windows7 /Linux Centos Web服务器：Apache2.2 DB: Mysql5.5 运行环境：PHP
测试机	操作系统： Windows10 家庭版 浏览器： IE11 , 谷歌，火狐	可以使用虚拟机

4.2. 硬件需求

这部分描述测试需要的硬件的配置和数量

资源	描述	数量	备注
计算机	CPU： 四核2.0GHz 内存：8G 硬盘: 120G 网络：1000M带宽	12	可以用虚拟机
安卓手机	12+512 一亿像素 6000ma 处理器888，天玑1000+ 5G网络	一亿	最高配

4.3. 人力需求

这部分描述测试需要的人员的要求(技术水平和经验)和数量

人员	职责	备注
开发	测试登录模块
测试经理	人员管理 质量管理 提供技术支持 编写测试计划和报告 进度管理 组织相关测试的评审
功能测试工程师	负责需求分析 用例设计 评审 用例执行，提交bug，跟踪bug 搭建测试环境 回归测试用例，bug	完成测试组长交代的其他工作任务
系统管理员	维护测试环境； 分配测试管理系统权限

5. 测试风险分析

这部分描述测试任务可能遇到的风险，以及规避的方法
1．可能遇到的情况
2．该情况发生的可能性
3．该情况发生后对测试造成的影响如何
4．我们该如何应对突发情况
模板

风险编号	风险描述	风险等级（高、中、低）	责任人	风险对测试的影响	规避方法
1	测试登录模块	高	张三

可能存在的风险以及规避方法

	人	资料	方法	环境	时间
风险	人员不足	资料欠缺/需求变动	方法（技术不足）	环境（测试环境/测试机不足）	时间（提前 延迟）
规避	招聘 借调	需求分析工作及时 提前进行	培训 或者招聘会的	购买/借同事	由测试经理/项目经理进行工作的监督，时刻把握测试进度

6.测试策略

为每个需要测试的特性和特性组合规划测试方法。选用的测试方法应确保每个需要测试的特性和特性组合的测试有效性。测试方法描述可以包括：测试方法和技术、测试完备性的评估方法、测试完成的准则、环境和资源的要求。如果存在影响测试方法选择的约束条件，也可以在这部分进行描述

测试策略	策略说明
界面测试	为了验证整体界面是否符合公司需求说明

7.测试准则

测试任务	启动准则	暂停准则	再启动准则	结束准则

7.1.测试启动准则

这部分描述计划中描述的测试任务的启动准则，例如系统测试执行是再完成单元测试、配置经理提交给测试组完整版本时启动系统测试执行任务

7.2.测试结束准则

这部分描述计划中描述的测试任务的结束准则，例如测试结果证明系统符合需求，遗留的问题在质量标准允许范围内

7.3.测试暂停/再启动准则

这部分描述出现什麽样的异常情况时暂停测试，以及在什麽条件时重新启动测试

8.测试任务

这部分描述需要完成哪些测试任务来完成测试计划、设计、实现、执行和报告，测试任务中应该包括对测试输出的评审工作

任务编号	前置任务	任务描述	需要的技能	责任人	计划完成时间

9. 时间进度

测试任务	负责人	预期开始时间	预期结束时间	时间进度	备注

10. 人员分工

姓名	工作内容	职务	备注

11. 测试输出

这部分规划测试任务的所有文档输出，根据项目特点进行规划：
测试计划、测试设计说明书、测试案例说明书、测试规程、测试日志、测试问题报告、测试分析报告
如果需要某些文档合并为一篇文档，例如把测试设计说明书和测试案例说明书合在一篇文档中，需要进行说明

文档名称	负责人	放路径
测试计划	XXX	XXX
测试设计说明书	XXX	XXX
测试案例说明书	XXX	XXX
测试规程	XXX	XXX
测试日志	XXX	XXX
测试问题报告	XXX	XXX
测试分析报告	XXX	XXX

三、测试计划模板

测试计划的内容：

• 测试范围 明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？

• 测试策略 明确怎么测？对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。

• 资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。

• 进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。

• 发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？

• 风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。

我们把这些内容模板化，形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划，都可以用这样的模板来使用。

image

在此模板的基础上，我们一点点来剖析如何编写测试计划。

在这里插入图片描述

在这里插入图片描述

这里的参考资料可以有：（可行性分析报告、软件需求定义、软件系统分析、软件概要设计、软件详细设计、软件测试需求、硬件可行性分析报告、硬件需求分析、硬件概要设计、硬件原理图设计、硬件结构设计、硬件测试需求、模块开发手册、测试时间表及人员安排、测试计划、测试方案、测试报告、测试分析报告、用户操作手册、安装指南等）
2 测试范围
测试范围的确定来自于需求文档，依据是项目的交互稿和需求分析结果
2.1功能测试范围的分析
功能点的拆分、接口测试、UI测试
2.2系统测试范围的分析
（1）容错处理
（2）兼容性要求
（3）配置要求
（4）性能要求
（5）安全性要求
（6）可靠性、日志文件

在这里插入图片描述

3.测试策略
为了更好确定软件测试策略，可以问如下一些问题：
(1).回归测试的范围如何确定？
(2).如何利用可重复性的测试？
(3).测试缺乏可预见性，如何收集衡量测试结果的指标？
(4).如何建立稳定的、模拟系统实际运行的测试环境？
(5).如何从无穷的输入数据中选择合理的、有效的测试数据集？
(6).如何衡量这份测试策略的有效性？
1、基于测试技术的测试策略
(1).任何情况下都要使用边界值分析方法
(2).等价类划分法是对边界值分析方法的有效补充
(3).如果功能的输入数据/条件存在多种组合情况，则使用因果图
(4).错误推测法
(5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
(6).白盒测试
2、分阶段的测试策略
(1).严格执行代码审查
(2).单元测试和集成测试，准备自动化测试
(3).系统测试中，以每次发布用户基线为结束标志
(4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
(5).在功能测试、安全性测试、配置测试中进行探索性测试
3、基于测试方案的综合测试策略
(1).测试优先级，优先级越高，越早测试，测试力度越大
(2).使用尽可能少的测试用例，发现尽可能多的程序错误
(3).测试策略尽量简单、清晰
(4).基于缺陷分析的测试策略

在这里插入图片描述

4、测试资源
测试人力资源包含两个维度：
1、测试人员数量
2、测试人员经验、能力。
环境资源一般包括：
1、测试服务器环境（尽量与线上环境保持一致）
2、终端环境（PC配置，手机型号）
3、测试工具（bug管理工具，用例管理工具，性能测试工具等）
在我们的测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。

在这里插入图片描述

5、进度安排
测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。
可以用工作分解结构表方法评估工作量：
1、列出本项目需要完成的各项任务
2、细化每个任务，尤其是测试阶段，需要对模块进行拆分，拆分到可衡量和细化的维度
3、预先设计测试点，按照测试点来估算
4、给每个维度估算时间，需要优化和重复操作的部分
5、在已估算结果上浮动10%-15%

在这里插入图片描述

6、发布标准
测试完成的标准，也就是说做到什么样算是测试工作做完了。主要包括：
1、测试计划里所有测试类型都已经完成了
2、功能上、兼容性上没有影响用户使用的Bug
3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
在满足了测试本身的前提下，产品要发布还需要满足要求：
1、产品需求都已完成
2、交互视觉走查都已完成
3、一流的小部分Bug项目组完成了风险评估，都认可且问题不大
4、产品使用说明或用户手册或更新log都已完备等等。

在这里插入图片描述

7、风险说明
测试风险分类：
1、测试范围的风险，测试遗漏、需求变更；比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；
2、测试进度的风险，工作量预估不准确、耦合任务延迟、测试人员变动；比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；
3、产品质量的风险，代码质量、测试人员能力；比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。
测试风险的控制方法：
1、根据风险发生的概率和带来的影响确定风险的优先级，然后才去措施避免那些可以避免的风险；
2、风险转移，比如去掉新功能，转移风险；
3、不可避免的风险，就设法降低风险，如提高测试用例的覆盖率；
4、事先做好风险管理计划，喜欢里程碑和验收管理；
5、有一套应急、有效的处理方法，比如全员了解，注意日常观察，及时发现风险出现的征兆；
6、做计划时，要留有余地
7、制定文档标准。

在这里插入图片描述

到这里我们就完成了一份测试计划。有的人可能依旧存在疑问：做计划真的有那么重要么？我们实际工作中有很多项目根本就没有计划依旧可以完成的啊！我们来看一下不做计划可能会有哪些问题~
 首先，如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据，在公司里怎么来协调和安排呢？
 其次，测试人员的分工明确，会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题，导致工作混乱效率低下。
再就是测试进度失控。到底什么时候做完没有一个预期，其他的团队怎么安排工作呢？进度有没有失控也没有判断依据，临到预计的上线时间才发现还有很多没有测到、没测完，直接影响整个项目的进行。
还有就是应对需求变更困难，对可能出现的风险没有准备。一旦出现问题，大家一片混乱，很容易导致测试遗漏和项目延期。
 最后就是没有统一发布标准，上线意见不一致。测试团队认为Bug太多不能上线，开发团队认为都是小Bug不要紧，先上线再说，导致争执不下的局面。、
 当然根据项目不同还可能存在其他一些列问题…
 总而言之，测试计划的作用非常重要。

• 指导测试过程
• 协调项目安排
• 提高测试效率
• 提高测试质量
  做测试计划对测试人员的能力和要求是非常高的，从另一个角度来说，测试计划可以体现一个测试人员的自我修养。一个测试人员需要很好的经验沉淀、有很多好的全局意识才能做好一个项目的测试计划。
  希望大家都能够很好的胜任编写测试计划这项工作。