|
不要为了做自动化测试而做自动化，做的首要目标是问题出现时，能第一时间发现? 自动化中的代码覆盖率统计可以作为参考，但不能一开始就为了提高覆盖率，陷入 Case 设计之中。
?
注意：好的接口自动化 Case 设计，依赖于 Case 设计者的功能理解程度（手工测试的功力）+ 功能覆盖点，在用例设计上面要遵循以下几点原则：
1.将手工测试点转换为自动化用例。Case 设计注意：验证用例通过的标准---参考一个功能点容易出问题的地方。或者说，一个用例的通过说明此功能点一定没问题；反之，一定有问题。
2.覆盖手工测试不易检查／太浪费时间的检查。例如一个 HTTP 接口设计大量的数据比较的时候； 接口的 json 返回不能直接检查功能点是否正确（需要调用另一个接口的 json 来间接验证时）；一个接口的 json 返回需要和其他模块的接口联合” 互相验证 “（需要调用其他模块的接口的 json，两个 json 相互来验证彼此的正确性）
3.“边缘性”的功能检查。这里主要指的是回归验证。如果系统涉及边缘性的功能验证，把此类功能设计层自动化用例
4.接口验证的程度。接口的验证：即判断一个接口是否正常的标准。注意：接口参数”合理地“组合；
5.DB 数据更新检查。（如果有必要）注意从接口的角度检查 DB 数据的更新：
·其他系统的数据更新到待测系统 DB 中的数据，每天待测系统由于用户操作更新到 DB 中的数据；
6.接口自动化的数据准备。关于是否需要为接口自动化，特意在 DB 中准备需要的数据，适需要程度而定。原则：除非必须，否则不用准备。如果不准备数据，无法完成对接口的验证，则自己准备数据即可。
注意：一旦自己准备数据，评估对其他功能验证的影响。确保 DB 中数据量和真实性（模拟的数据需要充足，并且不能和真实数据差异性过大）。
推荐阅读：
自动化测试框架的类型有哪些？
怎样判断一个软件项目适不适合自动化测试？
企业选择自动化测试方案的几点建议
目前主要的自动化测试框架有哪几种？
|