该文章为转载，如有侵权 请联系本人邮箱：bxf0321@qq.com
一、接口自动化测试的“能“
用于项目的API层的http接口的功能逻辑验证：
减少手工测试的工作（回归验证；跨模块的验证）；
实现手工验证不能做的验证（如接口涉及大量数据的排序比较）
手工很难充分验证的功能逻辑（如接口的功能验证涉及大量的数据）
ps : 实际项目中接口自动化的根本目的是什么。个人认为是定时跑时，能监控接口，当接口功能失常时，可以及时发现，即发现bug。 因此，可以使用代码覆盖率来评估接口自动化的完整性，但更重要的是发现问题。
2. 接口自动化case用例设计原则
切记：
不要为了做自动化而做自动化，做的首要目标是问题出现时，能第一时间发现；
自动化中的代码覆盖率统计可以作为参考，但不能一开始就为了提高覆盖率，陷入case设计之中；
注意：
好的接口自动化case设计，依赖于case设计者的功能理解程度（手工测试的功力）+功能覆盖点
原则：
1. 将手工测试点转换为自动化用例。
case设计注意：
验证用例通过的标准---参考一个功能点容易出问题的地方/或者说，一个用例的通过说明此功能点一定没问题；
反之，一定有问题
2. 覆盖手工测试不易检查/太浪费时间的检查
如：
一个http接口设计大量的数据比较的时候；
接口的json返回不能直接检查功能点是否正确（需要调用另一个接口的json来间接验证时）；
一个接口的json返回需要和其他模块的接口联合”互相验证“（需要调用其他模块的接口的json，两个json相互来验证
彼此的正确性）
3. ”边缘性“的功能检查
这里主要指的是回归验证。如果系统涉及边缘性的功能验证，把此类功能设计层自动化用例
4. 接口验证的程度
接口的验证：即判断一个接口是否正常的标准。
注意：
接口参数”合理地“组合；
5. DB数据更新检查
（如果有必要）注意从接口的角度检查DB数据的更新：
其他系统的数据更新到待测系统DB中的数据；
每天待测系统由于用户操作更新到DB中的数据；
6. 接口自动化的数据准备
关于是否需要为接口自动化，特意在DB中准备需要的数据，适需要程度而定。
原则：除非必须，否则不用准备
如果不准备数据，无法完成对接口的验证，则自己准备数据即可。
注意：一旦自己准备数据，评估对其他功能验证的影响。确保DB中数据量和真实性（模拟的数据需要充足，并且
不能和真实数据差异性过大）。
自动化一般会选择每天定时跑。这里需要注意的一点就是定时跑的时间选择。
时间选择上注意几点：
1）在线上跑时，注意对线上接口的影响（一般要求：线上的回归验证可以随时跑）；
2）如果要检查DB数据更新的有关逻辑，注意数据的稳定性(如用户量少的时候)；
3）在测试时（非生产环境），接口涉及读，写DB，考虑是否需要定时跑。
首选接口自动化不是万能的，总有覆盖不到的时候。知道自动化的”不能“之处，才能更好配合手工测试出问题。
自动化的”不能“之处如下：
1）HTTP接口突然出现压力问题（前期的压测）；
2）web层面的手动测试(新功能上线后，对原有功能回归时，仍需要接口自动化验证接口，手工测试WEB页面功能)；
3）异常情况（如需要第三方api挂掉/超时的场景）
1） 实现变动 vs 维护的工作量vs 检查的详细程度；
检查详细程度： 自己和自己比； 自己 和 同类接口同一指标比较（因为口径不一致，或者内部实现变化，需要后续维护）
经验：自己和自己比 扩展和兼容性比较好（动态参数 + 完成功能检查）； 自己和别的接口比 看需求而定（接口提测前后 数据准确性检查比较参考）
ps : 小的点 ，执行时间 和 执行频率；
用途 ： 发现 功能失常，功能不可用
2） 接口监控 -执行时间 和 执行频率
检查详细程度 vs 执行时间 和 执行频率( 只能 和自己)；
检查详细程度 vs 经常频繁报警（一个接口什么算是正常的， 返回 非200 + 功能正常）
3） 数据 报表；
数据的正确性： 统计口径（业务方的口径 + 多个接口/模块 口径的差异 最后导致 业务方不一致）
痛点 当然源自难点：
1）当接口本身实现频繁变动、对接口的检查太过详细、开发修复缓慢时，那么不停的报警将会来了。
2） 不合理的自动化设计及维护方案，造成自动化成本大于自动化收益时，接口自动化就变得无足轻重了。实际项目中的体会是：为了自动化而自动化。特别测试场景过于复杂时，当自动化实现成本远大于手工测试成本时，就没有必要非去自动化测试了。
参考：
https://blog.csdn.net/huazhongkejidaxuezpp/article/details/52267126‘
网友评论