基于AOP的系统级测试解耦方案在系统回归测试中的应用

高文辉

（小米金融 北京市 100000）

在软件业，AOP为Aspect Oriented Programming的缩写，即通常所言的“面向切面编程”，它是一种技术，主要是借助预编译方式以及运行期间动态代理来使程序功能的统一维护得以达成。它是软件开发中的一个关键方向，是函数式编程的一种衍生范型，而且同时还是OOP的延续，亦为Spring框架里的一个关键内容。通过AOP能够有效地隔离业务逻辑的每个部分，以使这些部分彼此间的耦合度减小，程序的可重用性加强，并且对开发的效率的提升也颇有帮助。

按照测试分层的理论，系统级测试可将具有更大影响面的问题找寻出来，但也需要付出更高的成本，与其相关联的模块数量比较多，应对系统级别的健康状况加以重视。如图1所示。

近年来，在企业内部许多负责系统测试体系当中，系统级测试的价值愈加突出，为使系统级的质量以及效率都得到切切实实的提升，在测试的时候通常会拆分全系统，使其分化为一定数量的子系统，从而使得子系统独立测试变为现实，也就是我们所说的测试解耦。以下借助具体的例子对测试解耦过程（详见图2）展开详细的分析和阐述，假定全系统共由4个模块（在现实中的数量可能不止于此）所构成，则测试工作者能够对子系统A、A+B等做独立测试，也可以测试A+B+C+D这样的全系统，具体的测试拓扑完全由测试人员来根据测试场景来自由设定。

1 进行系统级测试解耦的主要原因

（1）较佳的可控性，更精准地开展测试，使测试效率得到有效的提升：子系统1的测试工作者，在测试前期仅需对1的测试状况加以了解，并对其内部问题加以重视，最后再展开全系统测试，对整体系统的无误性进行重视。

（2）提高测试稳定性：模拟对其他子系统以及依赖服务/数据，使得系统彼此间的干扰所导致的排查代价有所减小，测试稳定性得到提升。

（3）减少资源消耗：全系统多个模块（上百个）会造成极大的资源消耗，将其分为独立子系统值后进行单次测试，则可减少资源占用，使得测试更易于达成。

2 在测试解耦出现之后，系统级测试的新问题

（1）怎样更高效地将所需的依赖模拟数据供给被测子系统，以使所有场景的测试需要得到满足，而且测试质量不会降低？

（2）性能测试等许多系统级测试在开展测试的时候运用的是线上请求的方式，怎样对与此方式相适用的相应依赖数据进行生成，以使测试效率得以切实提高？

3 测试解耦方案

测试解耦方案在测试领域里的运用比较多见，在对其进行整理之后，将其大致分成3种，以下展开详细的阐述：

3.1 方案1：基于数据/日志同步+模拟的数据隔离方案

在有着高稳定性数据、相对较小的规模、数据格式化较为一致以及高规范性日志的只读系统中比较适宜运用，有许多团队对其进行选用，在实现方案方面主要是结合业务系统的特点来规划及运用的，并非完全一致的。

3.2 方案2：基于netbridge/capture/tcpcopy的截包回放方案

图1

图2：测试解耦示意图

图3

在大多数类型的只读系统中都比较适宜运用，其在网络层，必须适配协议，在协议类型集中度较高的场景里尤为适合运用，许多具有较大系统的复杂检索系统都对其有所运用，并且所得出的解决方案具有规范性、一致性。

3.3 方案3：基于AOP的测试解耦方案

由于部分业务端在系统级测试方面有了更多的需求，然而上述的2个方案因受制于一些问题而难以落实。

（1）读写结合：①可拆分各种业务场景，使其变成读写口不一样的强耦合序列，要对各请求彼此间的数据依赖关联系得到确保。②将线上录制作为测试准备的第一选择，从而使测试场景多样的诉求得到较好的满足。③由于有写请求，录制难以借助旁路方式来完成（以防线上数据受干扰），线上拓扑亦无法因此受干扰，所以不能选用上述的方案2。

（2）有状态的数据源：测试的输入及数据源（譬如DB）里的数据状态有着比较强的耦合，在数据量比较大以及数据频频改变的状况之下，难以精准地匹配请求与数据状态，所以无法运用上述的方案1。

（3）测试代价高：极具代表性的多出口及多入口使得协议适配需要付出极高的代价，所以不能选用上述的方案1、2。

测试效率、质量是系统级测试解耦需要重视的两个方面，其展现于具体事项上分别是测试数据的管理代价、仿真性及可用性。因而，将基于AOP的系统级测试解耦方案分为3个阶段，具体如下：

（1）线上数据录制：为使测试数据的仿真性及覆盖面得到有效的提升，使系统级测试对大数据量的诉求得到切实的满足，对于数据准备问题选用了线上进行数据录制的方法。

（2）数据管理：为使测试工作者的操作更易于达成，同时使所有业务场景对测试数据的需求都得到满足，可借助数据管理服务来统一清洗、筛选和管理线上的大数据，时的运用者能够经由平台所供的操作及规则在短时间里得出所需的测试数据，使测试效率得到真正的提高。

（3）线下回放测试：基于测试场景完成对应测试环境拓扑的设立，同时通过回放来达成子系统解耦，让用户仅对自己的子系统加以重视，而对其他的依赖服务不加在乎。

4 整体架构

以下是整体方案的突出特点：

（1）高效性：线上录制具有实时性，在此期间不需要人力支持；能够实时地推送数据，按类型进行数据管理。

（2）高仿真性：能够定制抽样线上数据，同线上使用者行为相统一。

（3）稳定性：使系统内部各模块的入口及出口数据具有极高的统一性，以使整体测试的回放测试的稳定性得到确保。

由图3不难发现，录制组件和线下回放共同组成线上录制环节，而回放组件则涵盖在测试环节当中，在设计以及维护的时候一般对其进行组合管理，录制回放组件的达成是以AOP来规划以及达成的，这亦是测试解耦方案的关键所在，以下就AOP的原理做简要的阐述。

5 AOP

AOP是一种统一维护程序功能的技术，是借助预编译方式以及运行期动态代理来达成的。简单来说，也就是在所需的代码里动态地置入代码，此类代码能够使所需的录制及回放解耦的功能得以达成，在具体运用的时候应将下述方面作为要点：

5.1 配置要动态插入代码的切面

@Around(“execution(public * com.***.dispatch*(..))”)

Public Object doAspectOnWebUnit(proceedingJoinPoint pjp) throws Throwable{

Super.initLoggingContext(pjp.getArgs());

return super.doAspect(pjp);

}

5.2 序列化/反序列化过程

序列化过程主要是将模块内部的对象序列化json明文且做压缩储存，反序列的过程即为转化读取自回放集群的json明文，使其变成对象完成测试解耦。

5.3 数据存储和管理

先用线上实时抽样录制，可借助对长度各异的抽样窗口的设立来对抽样进行控制，接着缓存压缩及落盘生成的数据，不但能够使所占的存储空间更小，而且还可以使线上服务所受的实时干扰减小，最后落盘的数据会经由离线任务向大数据存储内转存。

图4

5.4 方案相对比

基于AOP的测试解耦方案与当前已有的测试解耦方案相对比来说，有着较大的不同，主要集中在下述方面：

（1）工作在应用层，与基于netbridge等的方案（即方案2）工作于网络层的区别，录制回放组件。①不需要进行协议适配。②不需要对业务模块的拓扑做更改，能够与系统读写结合的业务特征更相契合，不但使旁路维护的代价、线上数据受干扰的几率都有所减小，而且在协议适配及模块接入方面也无需付出成本。

（2）录制过程以线上录制为基础，有异于方案2运用旁路或者单独环境录制，不用对独立环境进行单独维护，在资源方面亦不存在另外的消耗，这使得测试准备的成本大为减小。

（3）统一管理录制及回放组件，借助开关来对录制/回放模块进行控制，组件可能够在线上、下一同工作，这使得管理工作更易于开展。

6 基于AOP的测试解耦范例

图4是较有代表性的基于AOP的测试解耦范例，也是对测试解耦的工作经过进行展现，右、左侧分别是线下测试过程、线上录制过程，以下对此经过进行阐释，主要是以下述2个场景为例。

6.1 场景1：测试线下子系统（只涵盖了模块A）的时候，应完成以下步骤

（1）线上录制，仅需在接入的时候一次性接入即可。

（2）将子系统A的依赖、压力两类数据自数据管理平台里找寻出来，也就是对其中的全部出口、入口数据进行筛查和挑选，此类数据上均被标记为A，能够从平台中快速找出，同时向回放集群里灌入。

（3）通过插件形式向模块A里放进回放组件，把回放模式打开，将A开启。

（4）将测试驱动工具打开，同时将A的入口数据视为驱动工具的数据输入，正式进行测试。

（5）分析及比较测试结果，并将相应的测试报告得出。

6.2 场景2：在测试线下子系统（只涵盖了模块A+B）的时候，应完成以下步骤

（1）线上录制，进行在接入的时候一次性接入即可。

（2）将子系统A、B的依赖、压力两类数据自数据管理平台里找寻出来，也就是对其中的全部出口、入口数据进行筛查和挑选，此类数据上均被标记为A，能够从平台中快速找出，同时向回放集群里灌入。

（3）通过插件形式向模块A、B里放进回放组件，把回放模式打开，将A、B开启。

（4）将驱动工具打开，同时将A的入口数据视为驱动工具的数据输入，正式进行测试。

（5）分析及比较测试结果，并将相应的测试报告得出。

由此可以发现，测试重视子系统（譬如A+B）的时候，仅需对这2个模块进行部署即可，同时借助录制的依赖数据来回访解耦其他依赖的数据以及服务，录制回放组件使得数据的统一性、唯一性得到确保。

6.3 新模块接入的关键步骤

（1）在模块的目录之下放入日志组件，把录制模式开启，完成对启动命令以及需注入的aop规则的配置。

（2）通过线下测试之后能够伴随模块上线。

6.4 整体的工具的特征

（1）通用性：①Java系统通用。②回放数据的定制能够通过自定义方式完成。

（2）易用性：①模块一次性接入，不用对代码进更改。②线上实时录制，在维护方面无需成本。

（3）仿真性：①线上抽样录制，具有比较高的仿真性。②能够使数据的准实时更新得以达成，同时还能确保延迟<2h，更适宜于接口经常改变的服务。

6.5 DIFF测试作为范例来对工作过程以及整体测试过程

将某个系统里的节点DIFF测试作为范例来对工作过程以及整体测试过程进行详述，具体如下：

（1）工具接入【一次性】。在模块的lib之下放进组件包，借助agent参数加以开启，检查录制逻辑以及模块功能，若一切都是正常的，则进行录制接入；反之则要对新的AOP类型的适配进行思考，以线下测试环境为基础完成整个过程。

（2）线上录制。在线上模块里放进组件，可结合平台做相关的设置及维护，部以使此方面的成本有所减小，把录制开关打开，就能够开展持续抽样录制，录制数据的储存借助大数据平台来完成，以线上服务为基础完成整个过程。

（3）流量筛选。根据一定维度汇总在流量管理平台里放进线上录制的数据，客户可经由平台将所需的流量筛查和挑选出来，也能够为平台设立具体的规则，自动产生流量，并在回放集群里放进回放数据，以数据管理评为为基础完成整个过程。

（4）线下回放测试。经由（1）在被测模块里放进工具，把回放模式开启，挑选入口数据做测试驱动，并测试解耦回放数据，以统一的测试服务平台完成整个过程。

（5）测试报告生成&分析。对应的diff报告可借助测试工具而得出，对于报告里面的diff，可由分类的报告以及流量分析能力进行排查，从而把原因找寻出来。

以下是比较多见的DIFF方案：A：和线上结果DIFF；B：不同版本进行DIFF。现如今的测试工具都能够有效地支持2种方案，可结合现实需求来做出最佳选择。