自动化测试用例设计原则:
- 1、一个脚本是一个完整的场景,从用户登陆操作到用户退出系统关闭浏览器。
- 2、一个脚本脚本只验证一个功能点,不要试图用户登陆系统后把所有的功能都进行验证再退出系统
- 3、尽量只做功能测试中正向逻辑的验证,不要考虑太多逆向逻辑的验证,逆向逻辑的情况很多,验证一方面比较复杂,需要编写大量的脚本,另一方面自动化脚本本身比较脆弱,很多非正常的逻辑的验证能力不强。
- 4、脚本之间不要产生关联性,也就是说编写的每一个脚本都是独立的,不能依赖或影响其他脚本。
- 5、如果对数据进行了修改,需要对数据进行还原。
- 6、在整个脚本中只对验证点进行验证,不要对整个脚本每一步都做验证。
接口自动化用例设计的基本原则
不要为了做自动化测试而做自动化,做的首要目标是问题出现时,能第一时间发现? 自动化中的代码覆盖率统计可以作为参考,但不能一开始就为了提高覆盖率,陷入 Case 设计之中。
注意:好的接口自动化 Case 设计,依赖于 Case 设计者的功能理解程度,手工测试的功力,功能测试覆盖点,在用例设计上面要遵循以下几点原则:
-
1.将手工测试点转换为自动化用例。Case 设计注意:验证用例通过的标准—参考一个功能点容易出问题的地方。或者说,一个用例的通过说明此功能点一定没问题;反之,一定有问题。
-
2.覆盖手工测试不易检查/太浪费时间的检查。例如一个 HTTP 接口设计大量的数据比较的时候; 接口的 json 返回不能直接检查功能点是否正确,需要调用另一个接口的 json 来间接验证时;一个接口的 json 返回需要和其他模块的接口联合” 互相验证 “,需要调用其他模块的接口的 json,两个 json 相互来验证彼此的正确性。
-
3.“边缘性”的功能检查。这里主要指的是回归测试验证。如果系统涉及边缘性的功能验证,把此类功能设计层自动化用例。
-
4.接口验证的程度。接口的验证:即判断一个接口是否正常的标准。注意:接口参数”合理地“组合。
-
5.DB 数据更新检查。注意从接口的角度检查 DB 数据的更新,·其他系统的数据更新到待测系统 DB 中的数据,每天待测系统由于用户操作更新到 DB 中的数据。
-
6.接口自动化的数据准备。关于是否需要为接口自动化,特意在 DB 中准备需要的数据,适需要程度而定。原则:除非必须,否则不用准备。如果不准备数据,无法完成对接口的验证,则自己准备数据即可。
注意:一旦自己准备数据,评估对其他功能验证的影响。确保 DB 中数据量和真实性,模拟的数据需要充足,并且不能和真实数据差异性过大。
下面我还收集了一些软件测试的视频资料:
对于【软件测试】的的朋友来说应该是最全面最完整的备战仓库,为了更好地整理每个模块,我也参考了很多网上的优质博文和项目,力求不漏掉每一个知识点,很多朋友靠着这些内容进行复习,拿到了BATJ等大厂的offer,这个仓库也已经帮助了很多的软件测试的学习者,希望也能帮助到你!
有需要的可以关注我的微信公众号:【程序员二黑】,免费分享给你们。
写给大家:每一个优秀的人,都不是带着与生俱来的光环的,也不一定是比别人幸运。他们只是在任何一件小事上,都对自己有所要求,不因舒适而散漫放纵,不因辛苦而放弃追求。雕塑自己的过程,必定伴随着疼痛与辛苦,可那一锤一凿的自我敲打,终究能让我们收获一个更好的自己。