首先要知道测试用例的作用,通过用例我们能做什么?
只有清楚了测试用例的目标,我们才会更有针对性来进行优化。测试用例是为了达到最佳的测试效果或高效地揭露软件中隐藏的错误而精心设计的少量测试场景和测试数据。简单来说,测试用例是一份关于具体测试步骤的文档,它描述了测试的输入参数、条件及配置、预期的输出结果等,以判断被测软件的工作是否正常。
通过测试用例设计一个情况,软件程序在这种情况下,必须能够正常运行并且达到程序所设计的预期结果,如果程序在这种情况下不能正常运行,而且这种问题会重复发生,那就表示软件程序人员已经测出软件有缺陷,这时候就必须将这个问题标示出来,并且通知软件开发人员。软件开发人员接获通知后,将这个问题修改完成于下一个测试版本内。软件测试工程师取得新的测试版本后,必须利用同一个用例来测试这个问题,确保该问题已修改完成。
这时候测试人员才会基于评审之后的需求进行用例编写。
编写完成用例之后,是需要所有这个项目相关的负责人都要参与的。
因为一场成功的用例评审,至少能起到以下几个不错的效果。
参与评审的人员:
1.部门评审
测试部门全体成员参与的评审。
2.公司评审
这里包括了项目经理、需求分析人员、架构设计人员、运维人员、开发人员和测试人员。
3.客户评审
包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
通过评审的方式,使相关人员对于产品的需求认识尽可能达到一致,消除彼此之间的偏差。
1、对于产品经理来说,可以根据测试人员讲解用例的时候,能够思考自己的需求写得有没有问题,并且有没有可改善的地方,毕竟相对需求来说,用例是需求的更细化。当然也能够帮助测试人员检查他的用例在编写的时候有没有偏离需求。
2、对于开发人员来说,在编写代码的时候,我们往往看得是需求文档进行软件的开发,但是往往很多异常的情况,我们在编写过程中老想不全,这个时候我们在参加用例评审的时候,完全就可以通过用例评审,来反思自己代码有没有问题,有没有产生偏差,其实也间接的给我们开发人员提供很多异常情况的补充。
3、对于测试人员来说,难免自己一个人考虑不充分,这个时候,我们往往大家坐在一起进行评审,最明显的好处就是调动大家一起来帮你完善你的用例,检查出用例中未考虑到,以及错误的地方,其次是,对于其他的参与人员,也是一个业务学习的过程。
最佳方案
是为每个测试需求至少编制两种测试用例:
一种测试用例用于证明该需求已经满足,称作正向测试用例;
另一种测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这种测试用例称作反向测试用例,所以好的测试用例应该多关注“反向测试问题”。
通过测试用例的评审,对测试用例不断进行完善和维护,更全面地来覆盖有效的测试场景。
那我们到底如何设计测试用例呢,我也有录制的视频,感兴趣的大家可以看看。