正常交易，我们买几件商品，从对应的库存中，扣掉几件就可以了。早期，因为是两个系统，两个事务，测试需要考虑如何保证事务的一致性。我们需要考虑：
1.正常正向交易场景，是否能够正常扣减正确。
2.正常正向交易场景，商品扣减失败，交易创建失败，商品需要回补。
3.当商品扣减成功后，因为交易异常，回补前，商家编辑了库存，如何回补。
4.交易调用库存中心扣减超时了，这时前端会提醒用户系统异常，请重试；对于超时，库存中心并无感知，它有可能已经把库存给扣减成功了。那么，方案中交易是如何告知库存中心，这时一般采用异步消息。
5.下单过程中，出现请重试，交易系统是新建一个交易单还是复用交易单。
6.如果复用交易单，对于库存回补，异步回补库存消息到达可能会在本次扣减成功后到达，系统如何确保不会错误回补。
7.交易作为消息的推送者，如果消息推送失败，是否会重试；即要求消息不能丢失，又要确保回补不会因为消息生产者重试，导致多次回补。
所以，有赞测试小伙伴，需要对需求、系统实现方案非常了解，掌握系统拓扑结构，掌握自己Owner的业务及其周边业务。
2.2 任务
不管是在传统行业还是互联网行业，总是会存在任务或者是脚本。有轮询从存储介质获取数据处理，也有接受消息中心处理的任务。
举个业务场景，在有赞系统购买会员卡。商家会创建一个会员卡商品，用户购买该商品，然后系统把会员卡发放到买家的账户里。交易下单与发放会员卡，通过消息中心将业务连接在一起，会员中心系统监听交易支付成功消息，然后放卡。
我们考虑哪些内容：
1.正常正向业务，我买了某张会员卡商品，我是不是得到这张会员卡。
2.会员中心接收到消息中心推送的消息后，是先存储，再处理，直接消费掉消息，或者是直接处理，处理成功再消费消息。
3.对于先存储，再处理，相当于需要在启动一个任务，消费落地在本地的数据。
4.对于直接处理，处理失败，需要抛会一个异常或者false；让消息中心重新推送。
5.存在重新推送，那么，执行任务是否符合幂等。
6.该Topic消息失败重试，是否会有降级策略；例如ABC三个消息，A处理失败，A就不能立即重发，等待5秒，把时间片留给BC；每失败一次时间片+5秒。
7.消息重试N次，会被抛弃，一旦抛弃，是否可能出现资损；就该场景，我买了会员卡，是必须发到用户手里。所以需要有T+1核对。
8.T+1核对，有业务方或者数据中心，交易日第二天，将会员卡商品的交易明细与会员卡中心发卡明细做核对，对差异数据进行补全或做其他方面的处理。
9.会员中心作为事件处理方，如果需要多系统协作，需要做到幂等及事务一致性，或者实现断点续传能力；
我们采用尽可能完备的测试质量规范，尽可能的提高系统的稳定性与可靠性。
2.3 系统回调
系统回调，也是系统弱依赖的一种表现形式。A系统需要B系统，但是B系统又不能立刻给出成功与否的答复，就会采用回调来实现。例如第三方支付、保险公司出单、购买理财产品交易。 这种场景，依赖方发送Request，执行方会回复说请求已收到。待执行方处理完成后，回复给说执行成功或者失败。就好比我在微信上跟某A说，你帮我办件事，他说好的；某A处理完成后，微信上跟我说，我处理完了，处理结果是这样的。
1.我们需要跟执行方确定双方系统幂等验证的条件。
2.如果涉及跨防火墙通讯，需要考虑验证信息传输的正确性及合法性。
3.对于回调后，如果存在复杂的业务处理，是不是先存储回调结果，再处理。
4.对于某些特殊业务，还需要有T+1核对，保证双方系统的一致性。
5.需要关注对方系统的性能，是否能够支撑相关业务的能力。
同时，考虑其他特殊场景。举个例子，交易下单支付后，请求第三方支付，可能支付成功了，但是一直没有回调，这时交易超时关闭订单，这时回调了，这时系统如何处理。
2.4 系统对象生命周期
我们在做测试方案设计，处理前面的三点，还会从对象生命周期考虑设计方案。
1.我们需要知道，每个系统对象存在多少个状态，比如交易订单(如上图)。
2.每个状态间是否可以正向扭转，逆向扭转，扭转条件是什么。
3.例如，待支付状态，如果买单下单，不支付走了；这个单子不能一直是待支付，所以系统需要能够发现长期未支付，直接关闭；同时需要支持，买家关闭等。
4.关闭订单时，系统能直接把单子关闭吗？它有没有可能已支付，只是支付回调还没有回来。
5.如果因为系统设计，支付未回调之前，被关闭了；回调回来后，系统该怎么做，确保不会出现买家钱付了，单子被关闭了。
6.对象不同状态的相关方有哪些，每个相关方都有哪些权限或者系统提示文档如何等。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
