接口测试 接口自动化测试数据怎么来?涉及金钱的接口如何在线上回归?

风子 · 2023年03月15日 · 最后由 Tifa001 回复于 2023年03月23日 · 9324 次阅读

目前在用 pytest 做接口自动化,因为一开始就想要把这套接口自动化用到生产环境,所以考虑的问题比较多一点点。
我好像在 testhome 看过类似的文章,说测试数据分几类,比如公共通用的数据、动态数据(需要上一个接口返回才能使用)、死数据等等。
但是我搜索了下,还有看下自己收藏的文章,没有找到。
如果看到该问题,有类似的文章也可以贴下链接给我参考。感谢

请问:
1、在做接口自动化的过程中,参数的数据应该从哪里来比较好。是写死(这种切换一下环境就不能用了,不太好对吧?),还是从数据库里提取?(那如果数据库里有脏数据,会造成测试接口返回信息不准确吧?)

2、如果是动态数据,比如需要上一个接口查询商品,下一个接口添加购物车。如果上一个接口出问题,那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢?

3、请问你们已经落地的接口自动化,是在测试环境跑还是预发布、生产环境呢?因为感觉做出来只在测试环境跑,发现不了线上的问题。整个接口自动化意义不大。

4、如果在线上跑接口自动化,涉及到钱的接口,要怎么去跑呢?

共收到 18 条回复 时间 点赞

非常不建议自动化测试在生产环境跑,根据我的经验,自动化测试,基本不会被测试。。。你还想在线上跑涉及到钱的接口,这就是传说中的吃雷公屙火闪吧

吃雷公屙火闪 - 胆大包天

风子 #17 · 2023年03月16日 Author
Ouroboros 回复

哈哈,谢谢。那是否会用到做线上监控呢?那不也是在线上跑?求指点

风子 回复

监控和自动化测试完全是两码事。。。。

Ouroboros 回复

因为之前在某群看到某人说,监控就是对接口做个监控,我可能理解错了。我再了解了解,谢谢。

陈恒捷 回复

感谢捷哥的回答,让我更有信心了。😁

搬个板凳来看看

我们做了生产的服务监控,其实只是监控服务,周期啊 频率啊 自己控制,不要产生业务数据,不要给生产增加负担
目前我是一分钟轮训查询一个服务状态的,遇到服务异常 调云平台的电话服务打电话过来

以下亦纯个人经验:
1、除了配置数据,业务数据都是动态的:
我们是直接前置时通过调用相关接口生成,或者插入数据库生成相关数据,然后后置操作进行删除。这样一般不会有脏数据
2、遵循原则:测试用例之间保持独立性,因此各个用例不会关联影响。
至于多接口串联用例,自然必须每个接口都要正确
3、参考上述大佬回答就行
4、同样参考上述大佬回答,千万别线上跑!实在要跑,就拿一些合适的跑。比如我们的业务核心功能就是各种各样的检索,就算程序挂了,也不会造成脏数据,至于影不影响线上性能,那就另说

提出这种问题,看来楼主还没遭受过社会的毒打。千万不要自作主张动生产数据,无论什么目的,即使领导让你动,也要获取多方确认(领导、运维、业务等)后再实施。不然出了问题锅只能自己背,小测试的抗风险能力差,如果遇到这种问题,基本就是走人了,慎重!

风子 #12 · 2023年03月20日 Author
杨超 回复

感谢回答,给我提供了一个思路,等我把这个接口自动化做完,就可以做类似的东西,监控下生产环境。

风子 #12 · 2023年03月20日 Author
一日之纪 回复

感谢回答,学习了。我就按着你们说的这样,把测试环境的接口自动化做好来。

数据库里有脏数据,会造成测试接口返回信息不准确吧? 这个是指研发环境存在开发过程中的脏数据吗?

1、在做接口自动化的过程中,参数的数据应该从哪里来比较好。是写死(这种切换一下环境就不能用了,不太好对吧?),还是从数据库里提取?(那如果数据库里有脏数据,会造成测试接口返回信息不准确吧?)

参数数据主要来源肯定就是你的用例设计,其他来源都是补充。补充来源可以是线上流量(access log 里面可以抽取)、可以是埋点上报、也可以是数据库数据。但是关键问题是补充来源的数据是否全部可行,要加什么筛选标准,肯定不是随便一条数据就能拿来直接用,一方面有些数据涉及用户隐私安全,一方面有些数据不完整,一方面有些数据根本没权限拿,所以很多时候最关键的就是搞明白筛选标准和你的测试范围,不是万能的。
【是写死(这种切换一下环境就不能用了,不太好对吧?)】没看懂你说的写死是什么意思,是人为确定的参数?为什么切一下环境就不能用呢?能不能按照不同环节做兼容?还是说你的环境本身就有问题?

2、如果是动态数据,比如需要上一个接口查询商品,下一个接口添加购物车。如果上一个接口出问题,那么下一个接口也跟着出问题。这种接口传参怎么样比较好呢?

上个接口出问题用例应该直接报错结束吧,没什么特别的方法。上游你的控制不稳定,自然就不用想着下游能好过。这个解决的下手点不在于接口怎么传参,而是确定前置条件有无满足

3、请问你们已经落地的接口自动化,是在测试环境跑还是预发布、生产环境呢?因为感觉做出来只在测试环境跑,发现不了线上的问题。整个接口自动化意义不大。

全量用例是在测试环境跑,我们内部的预发布约等于生产环境,生产环境只跑很小一部分,而且都是读接口。在线上跑写接口就是给业务加脏数据污染,纯纯地坑研发,不仅可能发现不了线上问题,甚至可以引入问题让别人排查半天。这里的建议是把思路打开一些,发现线上问题除了接口自动化(巡检)外还有很多,比如监控、用户反馈跟进,更牛逼一点可以是舆情监控等手段

4、如果在线上跑接口自动化,涉及到钱的接口,要怎么去跑呢?

基本原则是涉及到钱就别在线上去跑自动化,出问题就是事故,老老实实线下自动化或者线上手工验证,不差那么点工作量。一方面钱相关的一般是线下有 mock,自动化会比较安全倒还好,但是线上没有 mock,第三方支付也很少会给你在线上开这样的测试口子,所以就别去较劲,要是自动化把别人的接口打挂了还要担责;另一方面,如果线下测完了没问题,线上还出问题,我觉得可以想想为什么两者的结果不一致,再去尝试排除这些差异点,至少保证己方是没责任的。建议先了解一下依赖的财经支付方在线上有什么限制再考虑

仅楼主可见
17楼 已删除

公司用的 apifox 跑接口,我一般用的是后置操作提取变量

风子 关闭了讨论 05月30日 10:35
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册