问答如何维护接口测试的断言及测试数据

小猫咪能有什么坏心眼呢 · 2021年04月06日 · 最后由 huangwang 回复于 2021年04月09日 · 4563 次阅读

最近在梳理接口测试的东西，处理业务逻辑的接口会遇到这样的场景：
例如打卡，第一次传参后，返回打卡成功，第二次传同样参数，返回已打卡。如果只断言返回 code 感觉不是很严谨，判断 msg 就会有两次返回结果不同的问题，换 key 的话也会有类似的问题，因为状态不同返回 key 也会不同。
我目前管理测试数据的方法是放在 yaml 中维护，格式大概如下

有没有除了加些判断更好的维护断言的方法或者可以如何优化测试用例

------------------分割线------------------------

总结下收到的回复
A.关于测试场景，我这里的测试用例对应的场景简单来说就是打卡，预期结果打卡成功,那么构造测试数据的时候一定是传一个没有打卡过的用户 ID 与 token，这个测试用例首次执行是通过的，这没有疑问，当这个测试用例第二次执行，一定无法通过，因为 msg 返回的不是打卡成功。关于 6 楼和 8 楼所提到的重复打卡场景是在另一组测试数据中维护的，不放在这里讨论。

所以这里的问题只是，打卡成功这组测试数据已经无法满足现在的场景要求了，而且不想手动取维护它，寻求一个好的解决思路。此前有个想法是去更新断言，现在想着也不合适，如果断言更新了等于少了一个测试场景，这不合理。

B.一楼说的是一个解决思路，但是目前如果清除痕迹涉及到的数据会更多，比如要去数据库恢复状态，所以在思考有没有更简便的方式

1 个赞

共收到 17 条回复时间点赞

Mango #17 · 2021年04月06日

第二次打卡的数据，想办法让它变成未打卡形式。可以第一次打卡完清理下数据。

陈子昂 #2 · 2021年04月06日

code 是不够的，可以去断言回包里面的某个字段信息，这个信息可以放到类似 response 区域下面，去 json path 去获取验证内容是否符合。
response:
关键需要验证的 key:验证内容

小猫咪能有什么坏心眼呢 #16 · 2021年04月07日 Author

对

陈子昂回复

是的，现在是这样做的所以在处理测试数据上遇到上面的问题

今晚打老虎 #4 · 2021年04月07日

使用 code 肯定是不足的，使用 msg 的问题可以考虑不同脚本顺序下对应的不同 msg，以此做断言
--断言的使用还是需要接口响应的具体区分来做前提的，不然就是很容易出现这种响应结果无法区分具体原因或者具体正确性的情况

小猫咪能有什么坏心眼呢 #14 · 2021年04月07日 Author

对

今晚打老虎回复

用例的顺序已经是按照顺序在跑的，但是不能解决两次调用的问题

今晚打老虎 #13 · 2021年04月07日 1 个赞

对

小猫咪能有什么坏心眼呢回复

如果就这个问题而言的话，是两个不同场景，需要使用两条用例来进行覆盖，已登录和未登录的情况下肯定是不同的 msg
---状态不同理应返回的 value 也会不同，我说的顺序是以不同 msg 来做区分，不同前提做区分，以此例来看可以将未登录和已登录做不同的场景前提，分开执行其用例或者对执行逻辑做修改

陈恒捷 #12 · 2021年04月08日

对

小猫咪能有什么坏心眼呢回复

能不能说明下，为何用例里会存在这个接口调用两次的情况，是本身为了校验两次调用返回值不同故意这么做，还是别的而原因？

个人理解，只要能明确区分接口是第一次被调用还是非第一次，这个断言写起来和普通的没啥差别。至于 message 要不要校验，看业务场景中的重要程度吧。一般前端代码逻辑里只会用 code ，不同 code 走不同的逻辑。而 message 一般直接展示，不会针对性做什么业务逻辑的，所以就算有问题，也只影响用户体验，不一定影响具体功能。当然到底是不是这样，最好你问下项目里的开发同学确认下。