接口自动化测试的 “能” 与 “不能”

发表于:2020-10-07 19:52  作者:佚名   来源:知乎

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 功能测试 接口测试

  一、接口自动化测试的 “能 “
  接口自动化的目标
  ·用于项目的 API 层的 HTTP 接口的功能逻辑验证? 减少手工测试的工作(回归验证;跨模块的验证)? 实现手工验证不能做的验证(如接口涉及大量数据的排序比较)? 手工很难充分验证的功能逻辑(如接口的功能验证涉及大量的数据)
  P.S. 实际项目中,接口自动化的根本目的是什么?
  个人认为是定时跑时,能监控接口,当接口功能失常时,可以及时发现,即发现 Bug。因此,可以使用代码覆盖率来评估接口自动化的完整性,但更重要的是发现问题。
  接口自动化 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 检查的详细程度;
  检查详细程度:自己和自己比;自己和同类接口同一指标比较(因为口径不一致,或者内部实现变化,需要后续维护);
  经验:自己和自己比,扩展和兼容性比较好(动态参数 + 完成功能检查);而自己和别的接口比 看需求而定(接口提测前后 数据准确性检查比较参考);
  P.S. 小的点,执行时间和执行频率;
  用途:发现功能失常,功能不可用;
  2)接口监控 —— 执行时间和执行频率
  ·检查详细程度 vs 执行时间和执行频率 (只能和自己);? 检查详细程度 vs 经常频繁报警(一个接口怎样算是正常的,返回非200+功能正常)
  3)数据报表;
  数据的正确性:统计口径(业务方的口径+多个接口/模块口径的差异后导致业务方不一致)。
  接口自动化之痛点
  痛点当然源自难点:
  ·当接口本身实现频繁变动、对接口的检查太过详细、开发修复缓慢时,那么不停的报警将会来了。?不合理的自动化设计及维护方案,造成自动化成本大于自动化收益时,接口自动化就变得无足轻重了。实际项目中的体会是:为了自动化而自动化。特别测试场景过于复杂时,当自动化实现成本远大于手工测试成本时,就没有必要非去自动化测试了。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道