问答 如何维护接口测试的断言及测试数据
最近在梳理接口测试的东西，处理业务逻辑的接口会遇到这样的场景：
例如打卡，第一次传参后，返回打卡成功，第二次传同样参数，返回已打卡。如果只断言返回 code 感觉不是很严谨，判断 msg 就会有两次返回结果不同的问题，换 key 的话也会有类似的问题，因为状态不同返回 key 也会不同。
我目前管理测试数据的方法是放在 yaml 中维护，格式大概如下
有没有除了加些判断更好的维护断言的方法或者可以如何优化测试用例
------------------分割线------------------------
总结下收到的回复
A.关于测试场景，我这里的测试用例对应的场景简单来说就是打卡，预期结果打卡成功,那么构造测试数据的时候一定是传一个没有打卡过的用户 ID 与 token，这个测试用例首次执行是通过的，这没有疑问，当这个测试用例第二次执行，一定无法通过，因为 msg 返回的不是打卡成功。关于 6 楼和 8 楼所提到的重复打卡场景是在另一组测试数据中维护的，不放在这里讨论。
所以这里的问题只是，打卡成功这组测试数据已经无法满足现在的场景要求了，而且不想手动取维护它，寻求一个好的解决思路。此前有个想法是去更新断言，现在想着也不合适，如果断言更新了等于少了一个测试场景，这不合理。
B.一楼说的是一个解决思路，但是目前如果清除痕迹涉及到的数据会更多，比如要去数据库恢复状态，所以在思考有没有更简便的方式
为什么要打卡两次呀，如果是为了覆盖二次打开的场景，应该可以增加一个断言把
小猫咪能有什么坏心眼呢
回复
我这里的登录就是打卡，是我表达不准确
我都意思是：从打卡到打卡后的其他操作为一条线，打卡后的再次打卡 - 这类操作为一条线
前面的是可以形成流水线的，后面的场景则大多为零碎的场景，这两种场景可以区分以 msg 进行校验，这也是一种减少脏数据影响的方法
手工是可以实现的，只不过用例太多就。。。
陈恒捷
回复
原因是我不能保证测试代码只执行一次，并且每次执行之后重新清洗测试数据的过程有点麻烦。希望每次执行都是通过的，或者说测试数据使用过一次不可以在被这个场景使用的时候，如何去更新它
今晚打老虎
回复
你这个例子跟我这实际场景并没有关系啊。首先我所说的按业务顺序执行，是一定先执行登录 - 在执行打卡诸如此类的，不同的 msg 来做区分该怎么理解？
另外这跟分类不相关吧，或许你可以理解为单纯的测试数据脏了，就如一楼所说的，是一个解决思路
小猫咪能有什么坏心眼呢
回复
能不能说明下，为何用例里会存在这个接口调用两次的情况，是本身为了校验两次调用返回值不同故意这么做，还是别的而原因？
个人理解，只要能明确区分接口是第一次被调用还是非第一次，这个断言写起来和普通的没啥差别。至于 message 要不要校验，看业务场景中的重要程度吧。一般前端代码逻辑里只会用 code ，不同 code 走不同的逻辑。而 message 一般直接展示，不会针对性做什么业务逻辑的，所以就算有问题，也只影响用户体验，不一定影响具体功能。当然到底是不是这样，最好你问下项目里的开发同学确认下。
小猫咪能有什么坏心眼呢
回复
如果就这个问题而言的话，是两个不同场景，需要使用两条用例来进行覆盖，已登录和未登录的情况下肯定是不同的 msg
---状态不同理应返回的 value 也会不同，我说的顺序是以不同 msg 来做区分，不同前提做区分，以此例来看可以将未登录和已登录做不同的场景前提，分开执行其用例或者对执行逻辑做修改
使用 code 肯定是不足的，使用 msg 的问题可以考虑不同脚本顺序下对应的不同 msg，以此做断言
--断言的使用还是需要接口响应的具体区分来做前提的，不然就是很容易出现这种响应结果无法区分具体原因或者具体正确性的情况
code 是不够的，可以去断言回包里面的某个字段信息，这个信息可以放到类似 response 区域下面，去 json path 去获取验证内容是否符合。
response:
关键需要验证的 key:验证内容
第二次打卡的数据，想办法让它变成未打卡形式。可以第一次打卡完清理下数据。