
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了软件测试的一些基础知识等内容,而本文我们就继续来学习一下,软件测试用例设计评审的重要性。
什么是用例评审
当我们写完测试用例后,并不代表这份用例都是正确的,所有场景都已经覆盖到,所以需要多方人员进行查缺补漏。
简而言之,用例评审就是产品、开发、测试一起对写好的测试用例进行review的过程。
参会人员
用例评审一定是要求产品(制定该需求的产品经理)、开发(实现该产品的前后端开发人员)、测试(负责该需求用例编写和执行的测试人员)都参与。
会议由测试人员主导,相应需求的测试同学依次上去讲解自己的测试用例。
何时进行
用例评审会议是在开发提测之前,一般会提前一天通知相关人员,并预约好会议室,确定大家时间是否方便。
会前准备
在用例评审之前需要确保测试用例编写基本完成,可以先把用例给测试小组的同事先评审一遍,看看有没有什么问题。
提前五分钟到达会议室做准备,把测试用例、需求页面、原型图、开发设计页面、UI图等都打开。
用例较多时,提前做好标注,哪些是优先级比较高的,哪些是前端用例,哪些是后端用例,哪些是有疑问的点,方便侧重点评审,省时省力,而不是每条用例都需要评审。
还可以将测试用例给到相关人员提前查阅。
作用
对于产品经理:
检查测试人员是否准确理解需求,确保每个需求点都覆盖到。
通过评审正常和异常的测试用例,来反思当时设计需求时未考虑的情况,也是自我回溯的一个过程。
对于开发人员:
检查自己的程序代码是否还有很多情况未考虑完善,对自己的代码也是一个自我回溯检查的过程,间接实现了测试左移。
对于用例中无法实现的逻辑及时沟通,三方达成高度一致。
对于测试人员:
测试人员作为用例评审会议的主角,作用就不必多说了。
会后
用例评审会议后,需要对评审中的问题进行跟进和完善。
需要产品经理补充和修改的点需要让其在需求文档和原型图上进行记录
对遗漏的测试点进行补充,对有误的测试点进行修正,并对用例进行管理
其他注意事项
会议时长好控制在1个小时之内,如果内容较多,可分多次评审
结合可视化界面,针对页面测试点可提前打开原型图、UI图、设计图等
陈述时要表达清晰,有主题和层次,比如上来可以先介绍一下你这个需求是干嘛的,然后再分部分细讲
对于有歧义的问题,需要与产品和开发同学确认清楚
评审过程中,参会人员可能会有视觉和听觉疲劳,主讲人要抓住重点和重要人员
对于评审过程中的问题,及时做好标记
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。