如何编写一份合格的测试计划

最新推荐文章于 2023-08-09 19:31:17 发布

是佳佳呀~

最新推荐文章于 2023-08-09 19:31:17 发布

阅读量1.9k

点赞数

分类专栏：软件测试

本文链接：https://blog.csdn.net/aijaijgnaw/article/details/112610713

版权

软件测试专栏收录该内容

32 篇文章 6 订阅

订阅专栏

一份测试计划至少20多页，包含人员分工、里程碑、风险把控、上线标准、测试入场的标准、参考文档提交文档术语定义等等。一般都是由在团队中比较有威望的人（工作时间长的老员工，团队负责人）来写，小公司一般不写测试计划，写测试方案。
写测试计划会给我们带来什么？
第一，如果不会写测试计划，永远都不可能成为团队负责人；
第二，至少会看，能够分析出来哪些内容对自己有参考价值；
第三，测试计划能够让一个流程变得规范起来。

测试计划

测试计划
一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。
它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。

测试计划的三要素：

时间控制（工作周期）根据时间来控制人的数量而不是根据人的数量来定工作周期
资源控制（硬件资源、软件资源、人员资源、人力资源）
范围控制（测试范围）

其他方面：

策略（测试策略）
风险控制（比如人员突然离职，需求突然变更，开发人员底层模块逻辑错误，服务器不稳定数量不够导致扛不起项目等等）

计划的作用

计划能给管理者和被管理者指明前进的方向
计划可以减少不确定性对组织的影响和冲击
计划可以减少无序和浪费
计划有利于管理和控制

关于测试计划

为什么要编写测试计划？
领导能根据测试计划做宏观调控，进行相应资源配置等；（比如配置好的电脑给性能测试和自动化测试用，配置一般的电脑给功能测试用。如果配置好的电脑给功能测试用，那是资源浪费）
测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
便于其他人员了解测试人员的工作内容，进行有关配合工作（整个测试流程中需要配合最多的两个部门是开发和运维，开发是互相解决问题，提bug与改bug之间的关系，有的项目周期把控不住可能是互相没配合好，开发人员改bug太慢，导致项目周期被拉长，并不是测试的问题。与运维之间大多都是性能测试和项目的部署上，因为每个版本需要部署才能看到新的版本）
什么时间开始编写测试计划？
需求分析后，在整个测试工作过程中，不断修改（随着人员的变化，时间的情况，开发人员的配合情况去不断地调整计划的内容，需求评审之后就可以开始写计划了）
由谁来编写测试计划？
具有丰富经验的项目测试负责人

测试计划的核心活动

确定测试策略
确定测试系统（软件和硬件）
预估工作量（资源和时间进度计划）
评估时间进度风险并准备风险缓解计划
准备并复查测试计划文档

测试计划的设计与实现
在这里插入图片描述

测试策略

确定测试顺序
先测优先级最高的需求
对新功能和修改功能进行测试
运用等价划分技术和边界值分析技术减少测试工作量
测试那些最有可能出现问题的地方
关注用户最常使用的功能和配置情况等

做一个网站的测试时要先做UI测试，再做表单值域测试，再做数据准确性测试，再做业务流程业务逻辑测试，然后再做兼容性测试、本地化测试、比较测试、易用性测试、性能测试、自动化测试等，最后做性能安全测试。

确定测试方法
需求分析阶段：对需求文档进行静态测试，主要采用审查走查的方法，验证需求的完整性、一致性、可行性（读，理解，不懂就去问，不清晰就去查，不了解不详细的就让人去补）
编码和单元测试阶段：白盒测试方法，由程序员完成（代码静态走查，动态执行，指令、数据库逻辑的测试）
集成测试阶段：灰盒测试方法，设计用例时注意等价划分和边界值方法（测接口，没有可视化界面）
系统测试阶段：黑盒测试方法，测试工具、进行自动化测试，包括系统的功能和性能测试（有可视化界面，主要使用工具）
验收测试阶段：动态、黑盒测试方法，由用户来进行

测试策略
入口标准：描述在开始之前需要做哪些工作（达到什么样的标准开始介入测试，拿到需求文档就可以开始写测试用例，拿到接口文档可以做接口测试）
出口标准：描述再怎样的情况下可以结束测试（100%没bug是不可能的，当实际情况满足预期结果时就可以结束测试了）
暂停/继续测试：描述如果缺陷妨碍测试进行下去，会发生什么事情。如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。（有些项目是限时的，当有些问题解决不了很慢时就暂停，不能算作测试周期）
通过/失败标准：执行每项测试应该有一个明确的预期结果。如果得到了预期结果，测试就通过。否则表示测试失败。

确定测试系统

确定测试系统
测试系统不禁止用于测试的硬件，也包括测试架构以及测试配置
测试架构：测试用例的组织形式
测试配置：软硬件环境
一般程序员提交代码后在测试环境进行测试，测试环境全都没问题后发布到HA环境（预生产环境），这时是验收测试，预生产环境没问题后再发布到正式环境。

预测工作量

预测工作量
确定要完成的任务：测试用例的组织形式
确定每个任务的所需工作量
确定完成每个任务的时间
为测试工作建立详细的时间进度计划和里程表

评估进度风险
开始测试时，所需硬件没有到位
开始测试时，测试的系统还没有布置好（测试环境，HA环境，正式环境）
开始测试时，测试用例还没有准备好
测试过程中，需求发生变更（用户界面需求，功能需求）
测试过程中，用户界面发生变更（基本没什么影响）

复查测试文档

是否详细描述工作的范围
是否估计定义测试用例和实施测试所需工作
是否确定所需资源（人、硬件、软件和工具）
是否为各个人物分配资源
是否制定进度表
是否确定进度安排或质量风险
是否制定解决风险的应急计划
是否追踪项目进展并采取纠正措施
是否在适当的时候重新定制
是否向整个项目提供测试状态的可视性
是否对失败或堵塞测试纠正后重新测试

测试计划注意事项

增强测试计划的实用性（满足“5W1H”）
坚持“5W1H”规则，明确内容与过程（5W1H：why,what,where,when,who,haw）
采用评审和更新机制，保证测试计划满足实际需求
测试计划和测试策略

测试计划编写6要素（5W1H）

why：为什么要进行这些测试（自己判断这个项目需要做哪些测试，比如比较测试，这个是第一个吃螃蟹的项目，整个市场没有第二个，跟谁比；比如性能测试，就是一个公司内部的投票软件，公司一共30人做并发五万的，那是有猫饼吧）
what：测试哪些方面，不同阶段的工作内容（每个阶段要做什么）
where：相应文档，缺陷的存放位置，测试环境等（bug往哪提，文档在哪找……）
when：测试不同阶段的起止时间
who：项目有关人员组成，安排哪些测试人员进行测试
how：如何去做，使用哪些测试工具以及测试方法进行测试

测试类型和目的

功能测试
用户界面测试
性能测试
兼容性测试
安全及访问权限测试

测试方法
通过程序界面执行程序，还是直接从代码中找缺陷？
是否需要导入自动化测试工具来改善测试策略？
如果需要到如测试工具，哪些测试仍需要手工测试？
如何判断测试工作完毕？
测试的目标是什么，哪些可能对测试执行产生影响？

功能测试

测试目标
确保所有的被测对象功能正常
测试方法
至少为每条测试需求设计两个测试用例，一个用来验证是否实现了应有的功能，一个用来检查功能的实现是否存在问题
符合业务规则的操作和数据是否可以得到预期的结果?
不符合业务规则的操作和数据是否都被拒绝接受，并提供出正确的、容易理解的提示信息。
所有的业务规则的实现是否通许区中的描述相互一致
系统测试阶段所有的测试用例均采用手工方式通过对用户界面的操作来执行。

性能测试

测试目标
确保系统在一般状态和极限状态下，都可以保持正常的响应速度和最大用户连接数量
测试方法
关于极限的模拟，将考虑使用以下几个方法实现：

在服务器端启动大量事务以模拟服务器端系统资源被大量占用的情况
使用某软件模拟网络拥挤情况
启动数据库事务来模拟数据库端对数据进行修改时的竞争情况
使用某软件录制性能测试脚本，虚拟50个用户同时操作的情况，并在10台计算机上连续运行7天
准备超过100万条数据，验证对大量数据进行查询和汇总的时间

确定测试资源

人力资源
测试工作完成需要多少人？
参与者都需要哪些技能？
每个人的工作准备如何分配？
是否需要专门的硬件工程师来协助网络和系统维护？
是否需要其他部门的同事共同参与？

硬件和软件资源
测试工作共需要多少台计算机？
计算机从何处调配？
有没有为测试环境的搭建单独准备一台服务器？
是否准备了不同配置的测试用例执行机器？
如果需要介入Internet专线，是否可以提供？
如果测试不同硬件的兼容性，是否有足够多的硬件资源可以使用？
常用的系统软件和软件工具在哪里可以找到？
是否需要把测试用机的操作系统统一？（必须统一，基本都是win7或者win10）

其他资源
文档的存放位置？
项目参与者的角色如何？
项目参与者的联系方式？