接口测试 接口级集成测试怎么写,怎么体现价值

尼古拉斯赵四 · 2020年08月27日 · 最后由 云中一只猫 回复于 2020年09月03日 · 2557 次阅读

主要是想请教下各位大佬几个问题

  • 我们现在是用接口来实现业务的集成测试,想问下 这种方面 是写 python 代码来的有效率,还是使用接口平台效率高
  • 用例都写完了,怎么更能体现价值,只在测试冒烟阶段执行? 还是开发?生产都执行?

其实关于第一个问题,我个人是倾向于写python代码来的有效率,因为我们项目杂又多,对于集成测试,经常会有些超出接口的处理,比如ssh到环境上 进行资源的assert,对数据库assert,有时候还需要解析图片,解析csv。 但是身边一些同事觉得写代码学习成本高,认为接口平台页面上操作效率高,一些需求不满足 到时候二次开发就行
所以想问问各位大佬是如何看待这两个问题的

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 21 条回复 时间 点赞

个人认为接口集成测试最好平台 + 代码,双轨制。
1.平台支持接口测试,往往只能实现简单逻辑的接口测试;复杂的接口逻辑平台支持的话很麻烦;
2.复杂的接口逻辑使用代码实现轻松加愉快的;但简单的冒烟接口测试,代码实现就不如平台高效;

其他人的思路 不咋地的 好 , 做接口脚本落地 和 平台落地 ,
你肯定希望做平台落地,那平台落地 会导致 脚本维护的问题和 推广的问题,
其实 很早很早之前,就有解决方案了 不晓得 你有没有注意过;
首先 接口了 历程
工具 ➡️ 脚本 + 工具➡️平台 ,那我提供一个思路,就是将接口脚本当成 result api 进行开发 你可以挂在平台,也可以本地自由的覆盖跑;

1. 我们现在是用接口来实现业务的集成测试,想问下 这种方面 是写 python 代码来的有效率,还是使用接口平台效率高
你个人的倾向和别的同事的意见都没错。通过对比并评估两种方式的小批量实现即可得到答案,需要注意的是接口测试平台的研发或二次开发成本需要考虑在内,这是以两种方式都能实现整体目标(实现业务的集成测试)为前提,离开了这个前提,效率高低都是空谈。
2. 用例都写完了,怎么更能体现价值,只在测试冒烟阶段执行? 还是开发?生产都执行?
不存在 “更能体现价值” 之说,全面满足需求体现价值就是很好的。如果需求是只在冒烟测试阶段执行,那么在别的阶段也执行了就不是更能体现价值,这种(多余)价值也不该被认同。不该在开发和生产阶段执行,只能在测试阶段执行。

0x7C00 回复

业务流是不是对流程的测试啊,比如登录后去下单购买这样?这样完整的功能流程?

嘿Neal先森 回复

用例设计根据当前需要。一般接口用例分成单接口和业务流接口,正常和异常的 case 设计取舍还是根据当前团队情况。
简单例子:团队需要把和钱相关业务场景尽快覆盖,那就优先写正常 “钱”+ 部分异常 “钱” 相关的业务流用例.另外用例的展开也分阶段的,无法一蹴而就。

薄荷可乐 回复

入参模型是自动生成的。

我不是大佬噢,论坛里和论坛外很多很多真.大佬. 我上面回复是指【接口管理自动更新】哈。

0x7C00 回复

感谢大佬耐心回复,我也想问下你们是代码仓库变更,接口管理自动更新,还是接口自动化用例自动更新?

0x7C00 回复

同问 根据代码仓库代码自动生成接口测试用例?这个是怎么做到的?

0x7C00 回复

老哥,再问一下,研发代码修改了,接口自动生成,那接口参数呢,是否是由你这边维护,或者是也是自动生成

0x7C00 回复

根据代码仓库代码自动生成接口测试用例?这个怎么做到的?

0x7C00 回复

接口测试代码里每个异常用例,都需要写进代码吗?还是只考虑正常和一些常见的异常情况啊?

Midming 回复

你楼下有回复了一个。我们会做业务测试的,不可能脱离业务。

薄荷可乐 回复

接口是根据研发代码仓库里的文件自动生成的,研发有改动,我们也会同步一键修改.

Midming 回复

这个问题应该会转向外包吧,现在大公司 基本都外包手工测试

0x7C00 回复

测试人员全部转型测开的话,你们的测开具体做什么呢,手工测试都不做了吗?

0x7C00 回复

请问你们的接口怎么维护的

因为一直在做服务端方面测试,和大家交流下自己的思考.


  • 写 python 代码来的有效率,还是使用接口平台效率高?

    • 效率高低的考虑,再升级是把领导吩咐的事 orOKR 尽快完成。如果目的是短期做出来,那就使用接口平台. 如果不是第一个目的,选择 Python 写。从经验来看,使用接口平台中后期「3-6 个月之后」会遇到很多问题,最终放弃.现在我们是属于自己开发.原因很简答①之前的接口平台无法再支持我们业务复杂度的开发,如果扩展我们再写代码又回到了最初的选择上了②领导有要求测试人员全部转型测开.③团队人员技术基础素质很好. 所以答案就看目前所在团队的 OKR 了
    • 自动化的运行环境是一个通病,每个公司都有,我们现在做法在执行前会进行各种健康检查和第二步可选择的环境发布管理。按照经验,也是很有帮助的,我们可以很好的提前中断 case,避免误报。因为有消息通知机制,也会第一时间同步环境问题给所有人。
  • 用例都写完了,怎么更能体现价值,只在测试冒烟阶段执行? 还是开发?生产都执行?

    • 能够输出价值,才是我们所做事情意义所在。我的思考是①自动化用例设计很重要②自动化用例执行频率很重要③自动化用例数量很重要④执行节点很重要 [作为卡点,生产之前全量执行一次,在测试环境回归执行一次] 以上是第一层,第二层思考①接口自动化可能执行一段时间,也没有预防住和发现一些问题,所以 自始至终需要给团队和 leader 说明,有接口自动化项目肯定是非常好的加分项,不管对谁。对于业务来说,至少在服务端,我们可以很自信的说,放心上线服务端功能,这块不会出现 P0 问题。这是需要慢慢传递给所有人的②自动化测试提供了很好的工程效率③接口自动化是可以很好做横向和纵向的扩展的,例如横向的性能测试,业务监控等等,纵向的是收集错误用例历史数据分析,复制和回放等等。
  • 其实围绕一个接口自动化项目,也可以做很多事情,如果不从上面的技术角度扩展,就从项目角度可以延伸很多,一个简单例子借此机会提高培训团队人员 code 能力,借此项目扩展到其他维度的自动化等等,这个也可以和 leader 讨论,看 leader 的想法。

但是以上所有做的事情都有一个大前提,你有一个好领导,支持你!!!!😄

以上是个人浅见,希望有帮助!

根据领导支持的力度和团队本身的技术水平来决定

每天定时任务跑,每次构建后触发.
报告推送到邮件组或者钉钉群之类的.
做统计,用例数量,接口覆盖,发现问题次数
对比手工回归的耗时时间,看看节约了多少时间

接口测试可以放入每日集成,每天早晚跑。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册