测试流程规范

墨蓝 2024-04-07 13:33 30阅读 0赞

一、目的

规范测试流程，提交测试效率和测试质量。

二、背景

测试流程是开展测试工作基础，本规范对测试流程中的关键环节点进行约定，明确测试时必须进行的工作项，所有测试任务必须按照本规范执行。

本流程只适用于测试部内部，测试部所有参与的项目或者任务都可以参照此流程。可根据实际的项目情况对此流程中操作步骤进行删减。

三、测试流程

1、需求评审

需求评审前需要同相应的产品确认测试的交付文档，以及测试是否需要压力测试、性能测试等信息。

参与需求评审会议后，测试必须要输出需求会议评审纪要。

主持人一般为产品，记录人为负责该项目的测试人员。

1）若在需求评审过程中遇到疑惑的地方请立即找产品当场确认，并把最终的确认结果记录在案。

2）若不能当场确认的问题，请产品给出最终确认完成时间并记录在案，后续持续跟踪并直到问题解决。

3）若负责该项目的测试人员请假，则由负责该项目的交接测试人员进行填写。

4）以下情况可以不用填写需求会议评审纪要：

a.测试工作量评估不超过三天，即工作量<=3天；

b.小型的项目，经过上级确认不用填写；

c.经过电话沟通且没有预定会议室评审的需求；

5）若比较紧急的项目，前期可以不用填写，但后续必须要补充的。

6）若项目迭代更新内容较工作量少于三天，无需编写会议评审记录。

2、需求会议纪要模板填写样例

1）会议主题：写当前项目，例如：甘肃供需系统需求评审。若有的项目分阶段开发的，可以在会议主题后面加上版本1.0等字样

用来区分。

2）会议时间：写当前时间，时间需要写开始和结束时间。例如：2022年2月21日10:00~2022年2月21日11:43。

3）主持人：一般写负责该项目的产品人员，若当前项目有多个产品负责，可以全部写上。

4）参与人：参与人员一般为开发、测试、产品人员，若特殊情况需要ui参与，也需一并写上。

5）记录人：一般写当前参与当前测试人员。若参与该项目有多个测试人员，由主要负责该项目人员编写，若请假则由参与项目的

其他测试人员编写。

6）评审主要内容：一般填写需求评审的大纲即可，可以具体到需求的二级目录下。不做要求，需注意的是必须要带上序号，让

人知道主要内容有哪几点。

7）待确认点汇总：一般填写会议上需求评审暂时确认不了的问题点，另外此处也可以填写需求中遗漏的点或者新增加的需求。

注意点：一定要在待确认的需求里面加上产品人员完成的时间节点，若到了完成时间节点产品还未完成，测试必须要实时跟踪。

若无待确认的需求或者新增需求可写暂无

8）备注：此处填写本次需要注意点即可，若无可不写。

3、需求确认清单

需求评审过程中或者需求评审完成后，有什么需求不明白的地方。可以全部汇总在一起，形式一个需求清单然后统一发给产品确认。

1）若有需要紧急确认的需求，可以直接先找产品确认。

2）若不需要紧急确认的需求，可以一起给产品确认。

3）若当前产品不能及时确认的需求，需产品给出最后确认时间。

4）若需求清单确认完成后测试需要将需求确认清单发送在钉钉群里同步给相应的开发，减少二次确认成本。

4、列大纲

在需求确认完成后，需要先列一个大纲。把所有的功能点或者流程全部梳理一遍，会对你写测试用例起到事半功倍的效果。

1）大纲功能点最少到二级

2）最好一个功能点写一个即可

3）做到条理清楚、层次分明、简明扼要

5、编写测试用例

测试用例编写可以按照功能划分或者业务划分再或者按照端（web、app、浙政钉、小程序）来划分：

1）一个功能点最好只写一条用例。不要一个用例里面几个功能点糅合在一起，这样不方便用例执行。

2）若用例编写过程中需要立即确认的点，可以立即找产品确认。

3）若不需要立即确认，可以先标红表示，然后等到需求评审时再进行统一确认。

4）若客户无特殊要求，测试用例编写在metershpere上或者Excel表格上，但是必须得导出一份同步到confluence上。

6、测试用例评审

用例评审时相关人员必须全部到场，由测试人员进行组织。测试人员最好是两名，一人负责讲解，一人负责记录。用例评审完成后测试人员把用例评审记录整理好

发送到钉钉群内，让相关研发人员查看一下还有没有遗漏或者记录错误的点。

1）测试用例评审通过或者未通过，需要做好相关记录。若未通过，请填写好未通过的原因。

2）若评审过程中有争议的地方，可以先记录在案。然后私下讨论，并把最后结果同步给项目组内成员。

3）若评审过程中修改的内容较小，可立即现场及时修改。

4）若评审过程中修改的内容较大，可以先记录，会议过后再修改。修改完成后，钉钉群里同步给相应的项目成员。

7、冒烟测试

用例评审完成之后，测试人员在metershpere上创建冒烟测试用例计划。并把需要冒烟的用例分配给相对应的开发，督促开发执行完成。

冒烟测试完成之后，由项目负责人或者研发负责人发送提测邮件，提测邮件中需要附上自测结果。

测试进行接收验证：

1）若验收不合格，立即邮件打回，并填写不合格的理由。

2）若验收合格，直接进入第一轮测试。

8、第一轮测试：测试用例执行

第一轮测试时需要对照着测试用例来执行，若执行过程中有与预期结果不符合的直接提bug即可。

9、第二轮测试：场景+兼容性+适配测试

第一轮测试完成后进入第二轮测试，需要结合实际的场景进行测试。若有要求进行兼容性和适配测试，则需要进行兼容性和适配测试。若无要求，可不用测试。

10、第三轮测试：bug验证

bug修复完成之后需要测试进行验证，验证无问题的bug直接closed。若验证还是有问题的bug，则需要reopen。若遇到开发驳回的bug或者遗留的bug需要同产品确实是否需要修改。

11、第四轮测试：回归测试

前面三轮测试完成之后方可进入回归测试，回归测试需要对以前的功能回归一遍。看看还有没有遗漏的地方，若有请及时联系开发解决，若无则立即联系产品，让产品进行验收。产品验收ok后方可上线。

12、第五轮测试：压力测试、安全测试、接口测试

若客户方有要求，则必须要求客户要求操作。若无要求，默认使用jmeter或者postman进行测试。若会其它测试工具也可以使用其它测试工具，这里不做限制。

把测试结果复制粘贴在测试报告中，一起打包发给客户即可。

13、产品验收验收测试

回归测试完成之后，测试需要通知产品进行产品验收测试。

1）若产品验收不通过，测试需上报给上级领导，并说明不通过的原因。

2）若产品验收过程中发现bug，测试需立即联系开发解决，解决完成之后再次找产品验收，直到验收通过为止。

3）若产品验收通过，方可上线。

14、上线

上线前需要发送上线邮件，需要通知项目组内所有成员。

上线前需要检查以下内容：

1）开发在上线前需要检查有没有要删除的数据或者日志；

2）开发要申请的数据库，或者操作权限是否都已申请；

3）上线是否有上线顺序；例如：先上线管理后台的菜单模块，PC端才能上线。

4）上线是否有需要注意要的点；例如：先配置后台的菜单模块，PC端方可进行验证。

5）测试数据是否已删除；

6）配置文件是否已配置；

7）相关账号是否已开通。

15、第六轮测试：线上回归测试

线上回归测试需要进行线上申请操作，通过产品或者项目经理或研发负责人通过后方可进行操作。线上的数据需要打上TS或者Ts或者ts等标志，测试完成后需要通知相关开发把测试数据清除掉。

16、文档编写

线上回归完成了之后，可以进行文档编写。顺便查看一下之前的文档是否有遗漏，若有遗漏请立即补充。

希望对您有所帮助，谢谢~

测试流程规范

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 5. 测试执行规范

相关测试流程规范

相关软件接口测试规范流程

相关流程保证质量（规范+测试+设计）

相关 code review流程规范。

相关 code review流程规范

相关 Git团队开发管理规范、GitFlow流程规范

相关软件测试计划规范

相关 git 团队开发流程规范

相关 Git 使用规范流程