目录
无论做什么工作,最重要的就是要把流程理清楚,技术都是为了更快更好的走完流程的,所以今天打算梳理一下测试工作的流程,也给大家做一个参考。首先先看思维导图,这张图是之前学习的时候做的笔记,现在来看确实也是这样的,当然百度也可以百度出来,这里只是把我实际的工作经历分享给大家。(图片看不清可以通过点击连接查看)https://i-blog.csdnimg.cn/blog_migrate/a8222b81ac43d3c573a1f581d92fb185.png
一.需求评审
参与人员:测试、开发、产品、项目经理
输出文档:需求说明文档.docx(项目经理完成)、需求设计文档.docx(开发人员完成)
在产品诞生之前首先要有需求,简单来说就是一个想法,然后通过需求评审来判断这个想法是否可行。不过这个阶段基本上都是产品经历、项目经理、测试经理来参与的,至少目前来说我还没参与过需求评审,就算参与了也提不出什么问题,所以在这里没有经历可以分享。
二.制定测试计划
参与人员:测试
输出文档:测试计划.xls(测试组长完成)
测试计划一般在需求评审之后,都是测试组长来安排的,这个也没有什么经历,听从安排就是了。大概就是根据需求的难度和紧急情况还有大家的工作能力,每一个测试人员安排2-3个需求,两天写测试用例,一周内完成测试环境的测试,一周完成灰度环境的测试,然后上线。
三.设计测试用例
参与人员:测试
输出文档:测试用例.xls(测试组长完成)
这一阶段就是初级测试人要上手的时候了,一般都有专门的模板,内容大概包括:测试功能、测试验证点、测试步骤、预期结果、实际结果、测试人员等。但是要真正的写好确实不简单,首先要把需求理解透彻,然后要把开发的实现逻辑理解透彻,最后结合测试方法、测试场景等进行多方面的考虑,写用例的时候既要考虑的全面一些,同时又不能写的太冗余,大家可以看之前的文章:如何保证测试用例的覆盖率http://t.csdn.cn/lgJYK。
四.执行测试
参与人员:开发、测试
输出文档:开发自测文档.xls(开发完成)、测试报告.xls(测试完成)
测试用例写好了,等待开发完成之后就可以执行测试啦(测试开始也有相应的标准,具体的可以和测试组长确认,一般情况下是需求确认、开发完成并且自测通过就可以开始了)。在执行测试的过程就有很多东西了,首先要搞清楚测试的环境,常见的有:开发环境、测试环境、灰度(预发布)环境、生产环境这四个。
开发环境:开发人员自测的环境,具体是怎么搞的我也没研究过,这是开发的事情了。
测试环境:测试环境就是给测试人员准备的环境了,和生产环境最大的区别就是服务器不一样,网络不一样;所以在测试之前需要测试人员手动部署环境,包括在服务器中启动应用、在数据库中执行SQL、还有连接内网。所以测试都要求大家了解Linux语言、SQL语言。环境搭建好之后就可以开始测试了,测试环境会有专门的测试链接或者APP或者账号,具体的还是要跟测试组长确定才行,然后根据测试用例执行测试就好啦。这个时候呢,可能会遇到一些问题,这些问题有可能是测试环境不行、也有可能是后台配置不行、也有可能是bug,不管遇到什么问题,建议大家先到bug管理平台提bug,毕竟这是自己工作的一部分,给领导证明自己没有在摸鱼。而想要提出一些有质量的bug,就要了解清楚bug有哪些分类,然后根据优先级让开发进行修改,修改完成之后再进行回归验证,确保修改是正确的。关于bug的内容后面有时间再专门整理一下吧,东西有一点多。
灰度(预发布)环境:这个环境其实和生产环境差不多,但是通过添加白名单或者其他方法让一些特定的用户优先享用一些功能,这样也可以让测试更加具有真实性,而又不影响在线用户的正常使用。在这里测试的时候最主要的就是不能影响在线用户的使用,所以在进行配置或者其他一些更改的时候要非常的小心,而且测试结束之后要记得删除配置,避免生产故障的发生。
生产环境:这就是用户真实使用的环境了,一般都是在凌晨的时候进行测试,这样能够防止一些意外发生的时候及时做出调整,又不影响大多数用户的使用。在新的功能上线的时候除了要对新功能进行测试之外,也要进行回归验证,也就是把原来的功能流程走一遍,确保新功能对旧的功能没有影响。
五.撰写测试报告
参与人员:开发、测试
输出文档:测试报告.docx(测试完成)
最后就是撰写测试报告了,在这里就必须要明确测试完成的标准是什么。一般情况下就是功能性的测试用例通过率达到100%;非功能性的测试用例通过率达到90%;然后所有提出的bug都得到了解决;或者遗留的问题不影响用户使用等。这些标准可以和测试组长进行确认,常规的基本上是这些。一般测试报告都要包括:测试环境、测试配置、测试步骤、测试截图、测试结果、bug数量等等,怎么写一般也都是有模板的,可能不止一个文件,具体找测试组长要就好了,最重要的是把测试用例执行完毕,确保测试的产品功能没有问题。