结硬寨，打呆仗，持续推进BOSS自动化测试实践

结合当前的自动化测试工作，总结出了一些亮点：

2019年：“自动化测试是测试人员的事”

● 自动化测试的工作主要由测试团队负责推进实施(自动化设计、开发、录制、维护）。

● 开发负责人对自动化的关注多数仅是自动化测试的执行结果。

● 手工测试的占比依然占据了绝大多数的工作量。

2020年：“质量是设计出来的，测试工作不单测试人员的事”。

●  自动化测试的推进工作不再是由测试团队孤军奋战，协同推进才是我们新Flag。

●  开发参与自动化的设计、开发、录制、维护。

●  有目的、有计划的推进部分模块通过自动化测试逐渐替代手工测试。

在2016年启动自动化测试工作后，测试团队持续推动自动化测试工具改进，根据项目实际情况和实施过程中的问题不断优化，保证工具能匹配实际的项目情况，从而提高测试效率。

A)    持续优化自动化测试框架和用例模板

2020年自动化测试框架持续升级改造，将不同业务的自动化大纲、测试数据、测试步骤、预期结果校验、测试过程等全部模板化，并集中整合在EXCEL中。这样就可以在团队内共享测试文档，方便团队多维度评估自动化测试用例的覆盖有效性。同时在Excel用例模板的基础上开发自动化用例，可以让测试人员的录制效率大大提升。

B)    统一的数据库指向标签化

通过统一规范的变量命名规则，将自动化过程中涉及调用的数据库对象全部定义成公用的全局变量。测试人员在调用数据库相关操作的时候只要调用已统一封装好的关键字，就可以根据需要自由的选择需要使用数据库标签，避免了测试人员在开发自动化过程中重复设定目标数据库。

C)    通过全局开关，快速适配不同的环境

将数据库、主机、中间件等环境对象定义为全局变量，并加入全局开关设置，实现同一套自动化测试用例可以在系统测试和回归测试不同的环境执行。

D)    持续集成各类数据库：

Oracle,Alitbase,TimesTen,Mysql,OceanBase，BOSS系统目前已使用了5多种关系型数据库（计费账务：ORACLE/ALTIBASE/TimesTen 结算：Mysql/OceanBase)，统一集成各类数据库的操作是实现自动化测试的首要条件，也是保障数据操作一致性的关键 。2020年，测试团队封装了TimesTen,OceanBase数据库的操作，当前自动化框架已集成：Oracle, Alitbase, TimesTen，Mysql,OceanBase的关系型数据库。

E)    易配置、易扩展的十进制原始话单模拟接口

2020年云化预处理的自动化测试正式启动，要实现自动化测试首要难题即是解决模拟构造现网80多种存量的原始话单，70多种十进制原始话单。这些原始话单格式各不相同，少则20个字段，多则60-70个字段，如果逐个开发话单模板，投入成本较大，开发风格也不易保持一致性。最后测试团队使用EXCEL纵向定义各类十进制原始话单模板的方式。通过Excel定义话单模板不但易编辑、易排版，也更容易扩展话单字段，最后再通过统一的模拟接口实现所有十进制原始话单的模拟。截止到当前已完成16个十进制原始话单文件的自动化用例开发，累计完成412个自动用例，累计发现106个缺陷,生产问题1个。

F)    4G/5G在线消息模拟接口
在线计费的自动化测试数据模拟最为麻烦。一个用例场景需要实现：会话控制、返回码校验、切单、落单结果校验，其中4G消息需要将在线消息转换成字节流，5G消息需要解决基于HTTP2协议的消息发送，以及多层嵌套的Json参数替换。2020年初，完成了4G在线计费的自动化测试开发，累计30个场景。2020年7月完成了5G在线在线计费测试开发，累计31个场景。至此已覆盖了4G/5G在线场景90%以上的核心场景。

A) 企业级的流水线：

2020年6月RobotFramework成功接入开发云平台，并打通2条CI/CD流水线。

（图一）工单接口流水线

（图二）账务实扣流水线

B) 灵活的开源流水线：

结合工程项目流水线“短、频、快”的特性，构建独立的自动化测试环境，保障了流水线的持续构建。目前在BOSS的工程团队建立了默认的构建规则：在每天凌晨1点-8点每1个小时自动触发构建，来检验流水线的稳定性。

（图三）Jenkins流水线

自动化测试作为敏捷团队的共同目标，有计划、有策略的推进自动化，必须建立一套常态的推进自动化测试的流程：【启动】->【设计】->【评审】->【开发】->【录制】->【执行】->【跟踪】。

（图四）自动化开发过程

A）启动环节：

确认自动化测试覆盖的范围，自动化实现的相关技术难点以及完成时间，并落实相关责任人。

B）设计环节：

根据启动环节讨论的结果，设计实现自动化测试的Demo，并输出测试大纲。

C）评审环节：

评审测试大纲场景是否覆盖了手工测试的绝大部分场景。针对自动化的Demo，评审自动化的功能是否满足所有的测试大纲的用例场景，以及自动化的实现是否具备：易用性、易维护、易扩展、易控制。

D）开发环节：

针对评审结果实施自动化过程优化。

E）录制环节：

启动用例录制，确保自动化用例覆盖测试大纲的绝大多数的场景。

F）执行环节：

自动化用例不但需要在本机可以调试通过还需要Jenkins平台可以被正常调度执行，并创建流水线。

G）跟踪环节：

通过Jenkins流水线、grafana大屏可以跟踪团队自动化执行情况。

A)    自动化技能： 

BOSS测试团队要求全员掌握自动测试录制。

截止目前：

95%的人员已掌握自动化用例的录制。

40%的人员已掌握python二次封装开发。

20%的人员已掌握相对复杂封装调试开发，含Python/Java/Shell辅助工具开发。

B)    白盒测试：

为了提升自动化覆盖率，BOSS的各敏捷团队也尝试着提高测试人员代码阅读能力，这里例举2个团队的实践经验（不局限于）：

●  在云化预处理团队，为了提升自动化测试的覆盖率。团队要求测试人员掌握阅读C++代码的能力，通过代码挖掘测试场景。截止当前，16个原始话单文件处理已完成483个用例场景的开发。

●  在计费新业务团队，计费工单接口用例模板EXCEL化改造的过程，团队也要求测试人员能够通过阅读C++的代码提升用例场景覆盖率，原有的138个用例场景，预计改造后可以扩充到160个用例场景。

工欲善其事必先利其器。2020年初，测试团队针对BOSS自动化测试存在的不足，重构自动化测试框架，旨在：“过程模板压缩整合、测试数据集中化管理、减低用例耦合度、合理规划用例分类、主动模拟并发，实现轻量级压测”。

（图五）自动化开发准则

尽量使用统一的过程模板，覆盖尽可能多的自动化测试场景。统一的过程模板不但容易保障自动化用例规范的一致性，也便于后期的统一扩展控制，如：结果入库、全局开关设置、减少重复的过程模板维护投入。

改造前：以前一个自动化测试用例的相关数据分布在多处，如一个接口的用例：测试用例的相关参数以及用例描述在Ride上面，测试数据库脚本在.sql的脚本文件中，预期返回的预期结果在.txt的文件中。

改造后：通过EXCEL不但整合了测试用例相关所有相关的数据，还把测试描述，预期结果描述都整合到了EXCEL。同时我们还测试大纲、评审记录也一并合到EXCEL。

为了降低用例耦合度，在工具上，研发了“自动化生成独立用户的接口”实现一键触发生成，提高了构造测试用户的效率。在规范上要求，要求测试人员使用独立的测试用户开发自动化用例。

通过并发测试不但可以提高自动化测试的执行效率，而且也可以从侧面检查我们的自动化用例耦合度。另外，高并发的测试手段也是一种轻量级的压测，有助于我们发现系统存在的隐性问题。

（图五）并发测试暴露系统的隐性问题

自动化测试满足了“短、频、快”的特性，是提升测试效率扩大测试覆盖面的最有效手段。因此在后续的工作中，我们将继续围绕：

“持续改善自动化的架构；提升自动化可用性、易用性、易维护、易扩展；扩大测试覆盖面、覆盖率”的方向继续前进。

2019年我们将计费和账务的自动化代码做了一次整合，实现在中心内部资源共享。为了保障自动化代码的规范性，2020年我们计划将自动化代码从CVS迁移GIT，让开发一同参与自动化用例的开发。

工程项目团队：

自动化测试为主，手工测试为辅，推进开发测试。

新业务项目团队：

已经上线的工程项目的自动化测试用例，融合到新业务每周上线回归测试的自动化测试中。同时部分自动化测试用例覆盖度较高的模块尝试用自动化测试逐渐替代手工测试。

目前：全局开关适配了：系统测试环境、回归测试环境。

计划：增加全局开关设置增加适配开发环境。

目前自动化执行的节点只有3台(1台Windows服务器,2台Linux服务器）。其中最为耗时计费套餐资费总共2137个用例执行完成预计需要29分钟的时间，其中单个用例数最多的JOB有664个用例需要15分钟。如扩充执行节点到5台，2137个自动化用例预计可以在20分钟之内完成测试。

（图六）单个执行最耗时的JOB