收藏~通用系统测试计划模板(附参考模板)

2761 篇文章 16 订阅
2688 篇文章 27 订阅
本文提供了一个软件测试计划模板,包括文档简介、测试资源、测试策略、测试阶段标准、风险与应对计划等方面。强调了测试用例设计方法,如等价类划分、边界值分析、错误推测等,并指出质量目标和测试范围的重要性。此外,还提到了测试过程管理和交付物,以及如何根据实际情况动态调整测试计划。
摘要由CSDN通过智能技术生成

以下以一常用的软件测试计划模板为例 ,介绍了如何制订好一份测试计划。用于软件评测第一阶段,业务系统使用时需根据实际情况来适当增删,以及风险管理应对方案。
这里主要分为以下部分:
文档简介
测试资源与工具
测试策略
测试阶段的开始/结束标准
风险与应对计划
质量目标
测试过程管理
测试范围定义
测试排期(进度、人员安排)
测试交付物
附录-测试关注点


文档简介
一般包含测试计划编写目的、限制条件及参考文档
编写目的需要根据文档阅读人群来编写,如果项目属于外包性质的,需要考虑是否会合并在验收文档中。

测试环境
一般包含硬件环境和软件环境,如下图:

图片

测试工具
所有测试过程中使用到的工具,包含用例编写工具、执行测试工具、缺陷管理系统、需求管理系统等等。

测试策略及方法
常见的测试策略如下:
尽量做到在有限的时间里发现尽可能多的缺陷(尤其是严重缺陷)
测试计划与需求阅读同步进行
用例的设计需要高匹配产品需求,在需求的指导下设计出更多更有效的用例
逐步完善测试用例库(测试用例需要根据执行过程中不断修订,动态调整)
保证测试过程受控

常用的用例设计方法:
等价类划分法
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。

边界值分析法
边界值分析方法是对等价类划分方法的补充。通常输入和输出等价类的边界,就是应侧重测试的边界情况。

错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。错误推测方法的基本思想:列举出程序中所有可能有错误及易发生错误的特殊情况,根据它们来选择Case。

判定表法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表的优点是可以将复杂问题按照各种可能的情况全部列举出来,避免遗漏。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

场景分析法
对于业务功能测试领域,场景分析法是最普遍也是最主要的设计方法了。首先需要充分了解整体业务。结合分析应用场景,从用户角度出发设计Case,是一种面向用户的测试用例设计方法。

缺陷的严重级别定义
此处不作过多说明,通常按照行业标准定义。但业务为主的产品中,需由产品经理及用户代表来确定缺陷的严重程度,主要根据对用户使用的影响程度来计算。

另外,常见测试类型如下图:

图片

开始/结束标准定义

开始标准与结束标准通常按照公司内部的测试流程来确定,如测试交付产品经理或验收通过,或是达到已经定义好的质量标准。
中断标准
软件开发过程中,难免会出现一些意外导致项目中断,这时测试也应按照提前约定好的暂停,一般存在以下情况时:
软件项目需暂停以进行调整时,测试应随之暂停。
软件项目在开发生命周期内出现重大进度偏差,需暂停或终止时,测试应随之暂停或终止。
若开发任务暂停,则相应测试也暂停。

风险与应对计划
一般包含需求风险、时间风险、资源风险等,需要注意的是,每条风险识别都需要有对应的应对计划措施,至少2条。

质量目标
一般包含产品质量目标与测试质量目标
测试质量目标以下可作为参考:
所有的Case已执行过至少一遍
所有严重级别及以上的Bug已修复且测试人员验证通过
核心功能不允许有中级及以上的Bug
一般功能与终端用户不直接使用的功能不允许有中级以上的Bug
缺陷趋势呈下降并接近为0
在最后的10%时间内没有发现中级以上Bug
 
测试过程管理
通常包含测试文档的过程管理与缺陷处理的流程、汇报会议、进度日报形式等。
文档的过程管理如管理人员、存储、移交、分享等需要定义好形式,缺陷处理流程可以以缺陷管理系统中定义好的工作流来说明。

测试范围定义
测试范围可以按照项目计划书的里程碑来提前拟定,如哪个阶段需要进行底层框架的性能测试、是否需要完成接口测试、功能测试中包含哪些功能点等等。非测试范围一般说明不在本次范围内的功能点或测试类型,有时因项目进度原因可能临时对某些功能点进行删减,需要同步更新。

测试排期(进度、人员安排)
进度排期可参考以下几个节点进行划分,可以根据特定节点来划分不同的阶段。

图片


人员与任务安排可以根据前期已整理好的可用固定资源与临时资源调配来作好相应调动计划。

测试交付物
一般一个项目结束后需要交付的测试产物有:软件测试方案、测试用例、缺陷报告、项目测试报告、用户操作手册(若由测试团队提供时)

附录-测试关注点
附录中依据需要可以增加多个附录,如相关术语、缩略语的解释、测试需特别关注点等 。
测试关注点一般由技术负责人、所属产品经理及用户代表提供,可以在测试方案中提前明确以提醒测试人员的注意事项。
如增删查改功能点、数据导入、导出及特定输入框功能的测试侧重点
1 不能破坏数据库数据的关联和完整
2 检查多次使用back键的情况,在有back的地方,back回到原页面,再back重3 复多次,检查是否出错
4 修改正在使用的数据;
5 多次连续查询正确性
6 导入数据格式要求不应太苛刻,提示明确
7 数据的动态监测是否正确无误
8对于日期时间型数据,检查格式正确性以及时间日期的合理性。比如开始时间不能晚于结束时间等
9 重复数据处理,尤其是键值的重复

测试计划制订完成后,需要与项目中核心负责人确认,待审核通过后便可开始进行下一环节。需要注意的是,测试计划是隶属于项目计划书中的一部分,也是项目计划书的延伸,完成制订后仍需要根据实际情况来动态调整,才能达到最理想的指导目的。

最后:下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值