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

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

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

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

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

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