自动化测试用例设计原则（接口自动化用例设计的基本原则）

自动化测试用例设计原则：

• 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，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你！

有需要的可以关注我的微信公众号：【程序员二黑】，免费分享给你们。

写给大家：每一个优秀的人，都不是带着与生俱来的光环的，也不一定是比别人幸运。他们只是在任何一件小事上，都对自己有所要求，不因舒适而散漫放纵，不因辛苦而放弃追求。雕塑自己的过程，必定伴随着疼痛与辛苦，可那一锤一凿的自我敲打，终究能让我们收获一个更好的自己。