电子技术与软件工程
Electronic  Technology  & Software  Engineering
软件开发与应用
Software  Development  And  Application 基于AOP 的系统级测试解耦方案在系统回归测试中的应用
高文辉
(小米金融北京市 100000 )
摘 要：本文以系统级的解耦测试为切入点，对3种解决方案的优点、弊端以及A0P 的技术在系统测试中的应用情况进行了简要的阐 述，并且将基于A0P 技术的系统测试方案及其与其它测试方案的不同之处作为关键展开分析和探讨，同时将某金融系统政策模型的主流程
作为范例，就基于A0P 回归测试方案的整个工作过程进行详述。
关键词：A0P；系统测试；解耦方案；回归测试；录制；流量；回放
在软件业，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
读写请求序列
读写iS 求序列
ra
读写请求序列
mock  B
□回
1 Q
mockC  |a
mock  D  ] | C  |
(db  0 (springboot实现aop
(
| mock  DB  |
mock  server
须适配协议，在协议类型集中度较高的场景里尤为适合运用，许多 具有较大系统的复杂检索系统都对其有所运用，并且所得出的解决 方案具有规范性、一致性。
3. 3方案3：基于AOP 的测试解耦方案
由于部分业务端在系统级测试方面有了更多的需求，然而上述 的2个方案因受制于一些问题而难以落实。
(1)读写结合：①可拆分各种业务场景，使其变成读写口不
62
电子技术与软件工程
Electronic Technology&Software Engineering
软件开发与应用Software Development And Application
-样的强耦合序列，要对各请求彼此间的数据依赖关联系得到确保。
②将线上录制作为测试准备的第一选择，从而使测试场景多样的诉求得到较好的满足。③由于有写请求，录制难以借助旁路方式来完成（以防线上数据受干扰），线上拓扑亦无法因此受干扰，所以不能选用上述的方案20
（2）有状态的数据源：测试的输入及数据源（譬如DB）里的数据状态有着比较强的耦合，在数据量比较大以及数据频频改变的状况Z下，难以精准地匹配请求与数据状态，所以无法运用上述的方案lo
（3）测试代价高：极具代表性的多出口及多入口使得协议适配需要付出极高的代价，所以不能选用上
述的方案1、2o 测试效率、质量是系统级测试解耦需要重视的两个方面，其展现于具体事项上分别是测试数据的管理代价、仿真性及可用性。因而，将基于AOP的系统级测试解耦方案分为3个阶段，具体如下：（1）线上数据录制：为使测试数据的仿真性及覆盖面得到有效的提升，使系统级测试对大数据量的诉求得到切实的满足，对于数据准备问题选用了线上进行数据录制的方法。
（2）数据管理：为使测试工作者的操作更易于达成，同时使所有业务场景对测试数据的需求都得到满足，可借助数据管理服务来统一清洗、筛选和管理线上的大数据，时的运用者能够经由平台所供的操作及规则在短时间里得出所需的测试数据，使测试效率得
到真正的提高。
（3）线下回放测试：基于测试场景完成对应测试环境拓扑的设立，同时通过回放来达成子系统解耦，让用户仅对自己的子系统加以重视，而对其他的依赖服务不加在乎。
4整体架构
以下是整体方案的突出特点：
（1）高效性：线上录制具有实时性，在此期间不需要人力支持；能够实时地推送数据，按类型进行数据管理。
（2）高仿真性：能够定制抽样线上数据，同线上使用者行为相统一。
（3）稳定性：使系统内部各模块的入口及岀口数据具有极高的统一性，以使整体测试的回放测试的稳定性得到确保。
由图3不难发现，录制组件和线下回放共同组成线上录制环节，而回放组件则涵盖在测试环节当中，在设计以及维护的时候一般对其进行组合管理，录制回放组件的达成是以AOP来规划以及达成的，这亦是测试解耦方案的关键所在，以下就AOP的原理做简要的阐述。
5A0P
AOP是一种统一维护程序功能的技术，是借助预编译方式以及运行期动态代理来达成的。简单来说，也就是在所需的代码里动态地置入代码，此类代码能够使所需的录制及回放解耦的功能得以达成，在具体运用的时候应将下述方面作为要点：
5.1配置要动态插入代码的切面
@Around（"execution（public*com.***.dispatch*（..））"）Public Object doAspectOnWebUnit（proceedingJoinPoint pjp）throws Throwable{
Super.initLoggingContext（Args（））;
return super.doAspect（pjp）;
}
5.2序列化/反序列化过程
序列化过程主要是将模块内部的对象序列化json明文且做压缩储存，反序列的过程即为转化读取自回放集的json明文，使其变成对象完成测试解耦。
5.3数据存储和管理
先用线上实时抽样录制，可借助对长度各异的抽样窗口的设立来对抽样进行控制，接着缓存压缩及落盘生成的数据，不但能够使所占的存储空间更小，而且还可以使线上服务所受的实时干扰减小，最后落盘的数据会经由离线任务向大数据存储内转存。
图4
5.4方案相对比
基于AOP的测试解耦方案与当前已有的测试解耦方案相对比来说，有着较大的不同，主要集中在下述方面：
（1）工作在应用层，与基于netbridge等的方案（即方案2）工作于网络层的区别，录制回放组件。①不需要进行协议适配。②不需要对业务模块的拓扑做更改，能够与系统读写结合的业务特征更相契合，不但使旁路维护的代价、线上数据受干扰的几率都有所减小，而且在协议适配及模块接入方面也无需付出成本。
（2）录制过程以线上录制为基础，有异于方案2运用旁路或者单独环境录制，不用对独立环境进行单独维护，在资源方面亦不存在另外的消耗，这使得测试准备的成本大为减小。
（3）统一管理录制及回放组件，借助开关来对录制/回放模块进行控制，组件可能够在线上、下一同工作，这使得管理工作更易于开展。
6基于A0P的测试解耦范例
图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，能够从平台中快速岀，同时向回放集里灌入。
63
电子技术与软件工程
Electronic  Technology  & Software  Engineering
软件开发与应用
Software  Development  And  Application 高校宿舍管理系统综述
唐瑞明李论陈珊
(长沙卫生职业学院 湖南省长沙市 410100)
摘要：本文通过综合运用多种研究方法，首先对当前学生宿舍管理工作存在的种种问题进行了深入的剖析，然后建立关于高校学生
宿舍管理系统功能需求。小程序与高校学生宿舍服务理念有着高度契合之处，结合高校宿舍小程序的产品特性构建了高校学生宿
舍小程序的服务模式。
关键词：小程序；高校宿舍管理系统；信息化管理
我国自1977年恢复高考以来，高等教育在社会上的地位不断 提升。2017年全国各类高等教育在校总规模达到3779 )｝人，高等
教育毛入学率达到45.7%，也就是每I-万人口中高等教育在校人数
为2576人⑴。随着高校学生人数的增长，宿舍暂时成为高校学生 在校生活和学习的“家”，对学生宿舍的管理成了学校日常管理的
重点内容。在当前模式下，人力模式还是很多高校对学生宿舍管理
的手段。⑵由宿管人员记录和保管每个宿舍维修信息、清洁信息、
物件维修信息，工作繁重，效率低下，而且很容易出错。目前也有
些高校也在使用信息化宿舍管理系统，通过B/S 设计模式，将每个 宿舍成员以及财产信息输入到服务器，宿舍管理人员以及物业人员 通过客户端进行查询学生信息以及维修记录，这种模式下的宿舍管
理系统并不能发挥最大能动性。在这种背景卜，课题组考虑设计利 用小程序实现高校宿舍管理系统，让学生通过小程序及时进行 宿舍财产保修、宿管人员通过小程序马上得到报修信息并进行维护。
校方老师通过系统了解学生宿舍每天卫生的检查情况，通过小程序
反应学生晚就寝等情况。该系统地使用真正到了，“学生参与、宿
管反应、校方监督”的宿舍管理系统。
1研究背景
随着改革开放的发展，市场上对人才资源的需求越开越多。政
府越来越注重高等教育工作。百年大计教育为本，国家越来越重视
教育的发展，出台了很多有利于高校发展的政策，下拨了许多用于 建设和发展高校规模的资源。同时，市面上的企业也开始向校园推
(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) 测试报告生成&分析。对应的difT 报告可借助测试工具 而得出，对于报告里面的diff，可由分类的报告以及流量分析能力 进行排查，从而把原因寻出来。
以下是比较多见的DIFF 方案：A ：和线上结果DIFF ； B ：不 同版本进行DIFFo 现如今的测试工具都能
够有效地支持2种方案， 可结合现实需求来做出最佳选择。
参考文献
[1] 童艳，孙君亮，王鹏宇.实时测控数据处理集软件测试系统
设计[J].自动化技术与应用,2019, 38 (06):50-53.
[2] 王洋，薛静，刘春龙，武咏啥.一种高速系统级虚拟测试环境
实现技术[J].航天控制, 2019, 37(02): 49-54.
[3] 陈创，陈文睿，李津.面向继电保护系统级测试的缺陷自动定
位方法[J].中国电力,2018,51 (05): 10-16.
[4] 陈天毅，陈旦，张永双，李树成.风洞控制系统测试性的优化
[J].电子技术与软件工程, 2018 (05): 133-134.
作者简介
高文辉( 1973-)，男，北京市人。大学本科学历，毕业于北京工 业大学。软件测试部主管，现就职于小米金融。研究方向为软件测 试自动化与质量管理。
64

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。