场景：
创建订单并支付，会奖励给用户积分，奖励积分的数据会入库，我需要拿到这个数据进行断言。但是从接口请求开始到数据入库可能会耗时 5 秒左右。接口自动化时这段时间要做等待。
思考：
1.异步的方式应该不行，我需要拿到数据进行断言。
2.同步的话还需要根据不同场景下数据的入库时间做等待。（比如创建订单生成的奖励积分数据入库需要 5 秒，退换货生成的库存变更数据入库只需要 3 秒）
3.如果是轮巡的方式，查到数据就返回，那只能保证拿到数据。因为数据入库之后还会发生变更。（比如保险订单的投保状态一开始入库时是待投保，等待第三方接口返回投保结果后，再更新状态为投保成功或投保失败。但我拿到的数据是待投保状态）
问题：
这种场景下的数据库数据的查询断言怎么处理比较好？或者这种等待应该怎么去做比较优雅？
有没有大佬处理过类似场景的？😂
从接口调用数据落库耗时 5 秒的 -- 这个过程都是同步的吗？还是说数据落库是异步实现？
自动化中异步查数据也不是不行吧，考虑用回调实现。。
holydog
回复
1.是异步的，像奖励积分，订单服务发个消息给会员服务就行了。
2.回调这块我还没怎么了解过，我去学习一下看行不行。感谢提供思路哈。
Francis
回复
如果不是要负责全链路的自动化实现，业务的自动化或许跟随服务收敛比较好，大概只需要关注订单生成后是否有消息生产以及生产消息内容是否正确就可以了哇？毕竟消息的消费是下游链路的事，自动化收敛一些的话，对稳定性也会有些帮助吧，维护成本也比较低了。。
当然都是在建立积分发放属于会员业务而不属于订单业务的基础上了。。当然还是得具体到业务来看。。
我们以前遇到过类似场景，自己封装了一个断言函数，大概逻辑是：
1、入参是超时时间、查询 sql 、预期值
2、在超时时间内，每隔 1s 去查数据库的值，并确认值是否符合。不符合就继续查询，符合就 return
3、达到超时时间后的下一次查询，还是不符合，就抛出断言异常
借鉴的是 selenium 的 WebDriverWait 的思路。如果想通用性更强（比如不只是查库，还可以是其它断言），推荐直接引入 awaitility ，这个库就是专门干这个活的。
holydog
回复
有道理，各自模块负责各自的自动化用例更好维护一些。但是我目前遇到的场景是端到端的用例，下单->支付->退换货这种的，这应该算是全链路了 ，这种用例也不是太多，所以想涉及到的一些重要的检查点就一起检查了，也不分订单还是会员了。
不想查数据库 就监控 binlog。
