作者|田希希

测试计划首先要了解业务特点和测试痛点，然后再定制合理的测试计划，使计划能够满足当前业务形态的测试，支持未来预期的需求，甚至为未来的系统重构做好提前预案。

微服务架构体系也有一个比较初级的阶段。虽然不是这种架构，但是还是和多种业务耦合在一起的，因为业务前期业务形态还没有完全形成。

它可以尽快满足现有需求，同时降低当前环境下的维护成本。

最初的测试系统也有类似的想法。从当时的背景来看，界面测试和UI测试才刚刚起步，旨在解决当前的问题，满足业务的快速上线。一步到位或过于激进的设计往往会减慢进展。

初始接口调用初始化、测试数据初始化、接口调用、结果验证都在一个Test方法中。这样可以快速响应当前需求并尽快获得测试结果。

随着业务的发展，交易系统和交易测试用例进行了一系列的修改和升级。交易系统是水平拆分和垂直拆分的微服务。原来的交易系统内部存在明显的业务隔离，并且有指标。尤其明显的是单个服务排队的问题，这是从QA角度最直观的判断服务需要拆分的指标。

从业务维度剥离出来后，左边有一个交易系统，它在原来的系统上增加了一层具有运营属性的服务。玩法的出现和增长，使得原有交易系统的业务量急剧增加。

原有的案例已经不再满足快速支撑业务的目标。直观上，事例数量不断增加，冗余代码量也随之增加。不同情况下重复调用同一个接口，不同情况下重复编写同一类型的验证方法。

基于以上业务变化，原有的模式已经不能满足当前的情况。我们首先对案例进行了抽象，减少了冗余，得到了如右图所示的测试系统界面。

提供统一的数据，并将对同一接口的调用抽象为模块。每个接口通过参数调用接口来区分要完成的操作；抽象验证方法是一个独立的模块，相似的验证聚集在一起，通过参数区分预期结果； Case层只需要调用接口组合操作，并在操作中调用当前操作的验证方法即可。

这样解决了冗余问题，大量接口和验证方法的复用提高了接口测试的效率。

随着垂直业务的增多，并且由于每个垂直业务的玩法不同，所需的交易环节也有不同的要求。为每个垂直业务单独开发和维护一套交易链路，会对交易系统乃至交易业务产生负面影响。换句话说，人工成本和维护成本是无底洞的投资。

于是，多面交易系统诞生了。交易维护核心交易环节，并以切面的形式承载个性化业务内容，供业务定制处理。

基于切面的思想，我们在测试系统中通过动态代理构建了两层切面。一个是操作层，一个是请求发送层。

操作层的代理将验证与操作分离，并通过上下文将其连接起来。用例不再需要关心验证，只需要调用操作接口。这进一步降低了编写用例的成本。当然，验证系统的设计成本也随之提升。但总体用例成本的降低也使得RD在测试系统上编写测试用例，无论什么参数流入验证系统，验证系统都可以处理计算出期望值，并通过查询业务系统接口或数据库。

另外一个代理层可以做一些基于请求和返回的测试工具，比如diff工具，来满足重构类的测试需求。

方面状态机流经配置的扩展点以锁定当前状态，执行扩展操作，并将主机顺序渲染给第三方，直到当前状态解锁。

随着业务的发展和系统的重构，交易系统的横向划分越来越清晰。上层是业务系统和推广系统，中层是交易系统和支付中心，底层是清算结算中心。

业务的横向划分使得交易系统的业务结构更加清晰，系统维护更加方便，但对测试来说是一个挑战。上层业务的小改动或者下层业务的小改动都会带来大量的回归工作。

针对该问题，将测试系统改进为可扩展的测试系统。改进方案是在验证系统上层抽象一层计算系统。计算系统维护了所有状态流数据、计算公式等，整体结构与之前版本相同。没有什么大的变化，主要是计算和验证分离得更清晰，计算的可维护性和可扩展性更强。这样，上层业务的改变只需要维护抽象公式中对应的变量即可实现全业务回归。

操作执行后，通过代理封装上下文并触发验证。经核实，该操作影响了其他上下文。例如订单操作影响红包和商品。红包商品的语境需要维护。上下文更新后，会触发相应的红包和商品。查看。

经过多次升级，上图是最终测试系统的架构，有两层代理，独立的上下文维护模块，独立的验证模块。

例如，各种文档流通系统可以参考用例、操作、上下文和验证系统的测试计划。交易系统中的订单系统实际上是状态机系统的一个应用。

方面系统的考验点是方面能力。因为切面是为了承载更多业务的定制能力而构建的，所以对于中台来说，更多的测试工作就是为了保证切面能力。

由于切面的构建是基于配置的，因此相应的测试系统必须验证配置能力和托管接口能力。测试方法如右图所示。

数据构造模块插入各种配置，用例执行命中配置的操作，执行托管接口，并验证配置的有效性和托管接口的有效性。

策略类和方面类之间的相似性基于配置。策略业务场景包括风控、支付风控等业务场景。

配置策略、触发操作、测试策略引擎并验证配置。测试策略引擎是轻量级描述策略的集合。

异常分为服务内部异常、域内部异常（服务间异常）和第三方服务异常。

服务之间的异常可以通过注入，服务内的异常可以通过检测解决方案注入。

过去的亮点