接口自动化测试平台工程实践分享

问题的产生

业务背景

公司的后端包括http调用，一些核心业务链路为RPC调用。链路中还包括了诸多类型的中间键：Redis，MySql，Oracle都有，一条业务链中涉及到了诸多应用庞杂的接口入参类型等因素。

核心诉求

整合下核心诉求即为：
1.实现dubbo，http接口的调用
2.对中间键要有良好的整合
3.具备测试过程中的关键环节及功能：例如前置、后置、参数化、报表等
4.要有图形化的界面，将测试的重心放在设计上而不是编写测试代码上

调研

这些诉求流转到我手上的时候，看到了第四点，我嘴角微笑，情绪表示稳定。我倒吸了一口气。心情五味陈杂，而动手的过程中经历的事情，可以另开一篇经验贴了）
看到这点大致思路就是将整个业务场景要做大量的高阶抽象设计，要将测试过程中的每个节点，元素都抽象成对象，并且进行聚类，到了最上层展示层需要考虑暴露出哪些可配置或修改的属性给User。啊，说到User，那就又需要考虑到权限问题，hmmmm，还涉及到领导，再加个角色，hmmmm，这些统统用三方库三方库，有轮子用轮子，想想还有哪些轮子，关键的测试过程不是有框架么？调研一下TestNG，PyTest，JUnit。这些都是业内标杆级别的测试框架了，试着将这些图像化一下是不是问题就解决了呢？
图样图森破
关于自动化，了解下来业内有以下几种做法
1.框架（TestNG，JUnit等）+ Jenkins构建 部署到环境中实施：
测试开发的重点是：在测试框架内针对定制化的业务场景进行开发，例如提炼通用方法等。在实施业务测试过程中复用已有的方法实现业务的串联。
此种模式的侧重点是业务场景的功能性验证。
2.走纯底层的测试，基于Linux：
测试开发的重点是：由于被测对象的业务表现特征，只能通过底层的方式去验证其表现，例如模拟网络拥堵，通信异常等。
此种模式的侧重点是底层关键技术的验证，为一种特定类型的专项测试。
3.制造海量数据，批跑脚本：
测试开发的重点是：边界值，异常数据的制造，数据的流转验证。
此种模式的侧重点是业务中计算比重居多，对数据的准确性、一致性有要求的场景。
当然此种模式如果对数据的时效性有要求了之后，就变成了性能测试的一种
4.托拉拽图形化的平台/客户端对被测对象实施的测试：
这种产品市面上确实存在，但存在一定的局限性，可以理解为此种产品的公司目标是为客户的测试团队提供定制化服务，定制化程度过高，很难开箱即用。

小结

综上所述，所有的技术都不能脱离业务，而测试还需要考虑其中的管理意义，测试的环节，是一个与时间赛跑的，以数据论证，绝大多数公司的测试环节时间都是被压缩且紧张的过程，以何种技术、何种形式、投入多少人力在测试环节，想取得的效用，度量的标准等，这些都是技术+管理，所以测试的视野是很重要的。

而自动化的实施，更加需要考虑投产比这个问题，投入多少成本，取得多少效益？毕竟自动化与线上业务无关，有与没有自动化，不会为公司的主营业务创收，但带来的是必须是效率上的提升，或者成本上的下降，这也是为什么我说测试开发其实是技术+管理方方面面的技能点都要有。
言而总之，关于公司的这个项目，整理下来概要情况如下：
目标：在3个月的时间内，交付一个自动化测试设计平台。
核心功能：
1.满足公司业务链路接口调用，包含Dubbo，Http；
2.具备用例管理功能，能够统计出迭代中的关键指标（通过率，执行率，bug数）；
3.具备链路调试功能，运行时日志整合；
愿景：降低测试准入门槛，释放测试过程的时间成本。
再一次倒吸了一口凉气
看起来，也没什么难的。

问题的拆解

核心的问题

前文所述，平台是最终交付的产物，即平台为项目的最终目标。那么我们使用WBS工作任务分解去拆分我们的任务
将目标第1层拆解

接口调用 用例调度 管理功能 为三大核心业务模块，接口调用为直接与接口的执行；用例调度 为对执行的调度；管理功能 包含了平台的数据源以及一系列的管理职能，例如用例管理，统计报告等，形成流程的闭环。
第2层拆解

在第二次拆分后，发现颗粒度已经进一步细化了，至少大概了解每个模块下面有些什么了，然后进一步拆分，在拆的过程中，发现有一些模块是可以被复用的，例如参数化，是被dubbo和http复用的，那么修改设计。
第3层拆解
接口调用

用例调度

管理功能

拆解了三层，发现几乎快拆到实体（Entity）的纬度，那么细化一下
第4层拆解
接口调用

执行管控

管理功能

将模块拆解到这个地步，不禁发现一些现象，本以为调度是整个平台当中复杂的环节，但纵观整个拆解图可以发现，真正复杂的部分是测试过程中对象的拆解，就是基于数据的对象抽象。与此同时，可以看出有部分实体是在多个模块中出现的，WBS后，我们需要将共性的问题进行聚类合并，理清整体的设计思路。

设计业务流

既然已经完成了整体的模块化设计，并且完成了对测试过程中关键对象的抽象，那么接下来就需要完成业务流的设计。
首先确定下平台的用户角色
1.大老板：关注结果，报表统计；（重要、不紧急）
2.经理/组长：关注每轮迭代的实施过程，任务的完成度，缺陷是否闭环；（重要且紧急）
3.测试工程师：关注平台是否节约了时间成本，自动化覆盖率，测试执行的完成度；（重要且紧急）
接下来设计每个角色的业务流
业务流1 Boss 使用统计面板业务流

该业务流同样适合于平台用户的其他角色
业务流2 Leader/User

该角色包含了如下业务流：
1.设计自动化用例，并根据执行结果进行参数调试。
2.将调试完成的用例关联至测试计划里，形成用例的复用，完成回归测试的闭环。

自动化设计详细业务流 AutoTestDesign
1、用例设计–接口设计 InterfaceDesign

平台支持Http以及Dubbo接口，创建完成后，完成校验后会进行入库保存。
2、参数化配置 ArgsConfig
参数化配置的概要流程如下

参数化即为基于资源对象的描述抽象，在整个测试过程中的所有参数，皆可理解为基于资源的抽象，无论是数据库链接DbConfig，可复用的全局参数GlobalArgs，测试的入参TestArgs都是过程中的资源。
3、数据源配置 DataSourceConfig

在平台中，MySql、Oracle、Redis都被抽象为数据源的概念，配置数据源的过程即为图中所述。

自动化执行业务流 AutoTestExecution

该图描述了测试用例执行过程的业务流，其中部分的过程节点在前文中已有过描述，在此不再累述。

Pros & Cons

优点

至此，平台中自动化测试的关键环节及节点已经被设计完毕。此种设计通过隔离用户与测试代码，降低了自动化测试实施的准入门槛。通过使用该平台，可以降低大型企业对于测试人员招聘困难带来的自动化测试执行力不足的困境，适用于需要降本增效的企业等；通过贯通测试过程与管理环节出入口，使得接口自动化测试过程的透明度得以提高。

缺点

定制化程度较高，对于自动化过程的关键环节抽象需要投入较多的资源进行细节设计，且整个自动化实施的过程从原有的：写代码->执行，变成了：通过平台进行过程设计，增加了业务链路长度，设计的颗粒度变的精细，导致响应需求变更的效率下降。
在实施的过程中，我们经常遇到需求变更而带来的多环节细节修改，而以往敲代码实施的自动化，直接撸代码就能搞定。这也是略蛋疼的一点

后续还会与大家分享一些其他方面的经验，遇过的坑…

以上