前言传统上，作为互联网软件工程师，接触最多的事务之一是持续集成(Continuous integration，简称CI )。 持续集成已成为主要互联网软件开发过程中的重要一环目前，CD(continuousdelivery，简称CD )已得到实践，可以看作是后集成时代的产物。 重要的是，无论是CI还是CD，都经常强调作为软件开发交付过程中的实践，而交付到生产环境CI或CD则无能为力。 赞成与否在线拨号测量系统是为了弥补这一不足。 现有的在线保障手段分为运输水平、产品水平、安全水平、服务水平、测试水平等维度。 本文重点介绍了在测试层面的实践。
基于测试脚本的在线监测，我们建立测试在线拨号系统的初衷有以下几点。
事先警告在线问题。 赞誉有很多业务部门，每个业务部门都有不同开发测试的学生对接，每次发布都很难充分准确地评估影响面。 运输水平监测多为被动预警。 也就是说，如果用户流量导致了在线错误，我们会收到警告。 用户体验不够。 我们需要在线在故障报警方面被动主动，周期性地了解各业务线的健康状况。 用较少的流量迅速发现在线问题。 我们的软件通常在上午流量非常少的时候发布。 发布完成后，恢复时间较长(手动)，测试面有限。 无法全部恢复辅助释放。 此时，敏捷结构需要覆盖全流量，在小流量的背景下，敏捷会发现在线问题。 了解紧急情况下业务的影响范围及其后的收敛情况。 例如，生产环境出现网络异常等非软件故障时，需要明确业务水平的影响； 网络恢复后，需要知道对业务的影响是否全部收敛。 在此之前，这些场景需要测试人员手动介入，灵活性和敏捷性非常差。 有了该系统，测试人员可以增加自己感兴趣的场景，场景可以通过自主触发和定时触发运行，通过报警系统通知相关人员，第一时间排除问题，减少故障影响，缩短故障时间
基础版本1.0使用通用的SpringWeb构建。 内部称为在线机器人检查。 系统结构如下
1.0版系统体系结构图
系统主要有三个模块。
任务调度模块。 此模块将实例运行封装在系统任务中，并使用Spring Quartz定时触发。 对外提供API是值得称赞的发布平台，每次系统发布上线都会积极触发用例的运行。 测试用例模块。 包括业务访问、断言和警告。 测试场景需要各骨干业务的测试学生投入开发。 警告模块。 正在评估内部警告平台。
1.0版流程图
系统将用例分为基础用例和场景用例，支持场景同时运行或依次同步运行。 具体执行策略由用例设计人员结合具体情况在用例开发过程中设定。
的问题基础版满足了最小的可用性。 这种方式的优点是前期快速可用，对于经常编写集成用例的人来说成本不高，而对于其他人(测试新人、开发、运维等)则不然。 总之，其缺点主要集中在以下几个方面。
骨干业务增多，用例代码开发成本上升； 随着用例数量的增加，后期用例维护成本较大的用例上线不灵活，需要在用例每次改变时重新发布； 无法直观地看到运行状况和业务展望状况； 每次不区分业务地执行，全量执行的用例代码都有冗馀性，效率很低。 配置和可视化由于这些不可避免的问题，我们重新设计并发布了2.0版。 为了解决上述问题：
测试用例和测试场景支持配置化，可以通过管理平台配置； 通过标准化用例配置、管理标准用例结构和断言策略指定平台和管理自己的用例，可以实时启用和消除用例更改，增加前端展示，以图表形式展示运行状况和业务前景设计一个用例执行框架，将方便不同人群浏览的平台对接起来，区分使用指定的APP应用名称跑哪个用例，实现核心代码的重用。 新的系统体系结构图如下
2.0版系统体系结构图
用例模型如下：
字段必需说明用例名称为推荐命名格式。 “用例类型：服务：方法”用例类型是两种选项http或dubbo用例说明是场景说明所属业务是用例所属业务阈值请求urlnohttp协议调用的URL请求标头http 与请求是否支持动态参数注入以实现用例之间的依赖服务名的dubbo协议的接口名(包名类名)相对应的请求方法为http协议：GET、POST、PUT等； dubbo协议：方法名称支持多个开/关控制开关，并声明如果关，它将不再发货。 默认打开是否登录否打开后，使用默认帐户进入登录操作。 默认on/on重试noon后，一次重试失败。 默认前/后检查否运行前/后检查，运行前/后检查，如果失败则中断*此处省略部分有评估的内部使用字段，以便更直观地显示在线业务健康状况
查看数据
新版本和旧版本的主要区别如下。
将执行流与数据流分开，测试用例设计不需要编码，支持定位，用例作为数据存储在DB中重用，用例执行引擎管理用例执行流。 封装通用事务(如登录、商店切换等)，并在统一的线程池中进行管理。 支持动态参数注入，实现了用例之间的相互依赖。 关于这个内容，稍后会单独说明。 任务的流程图如下。
2.0版流程图
任务执行引擎由不同的工作线程实现。 不同的业务用例同时运行，业务内部用例串联运行。 系统是用例类型(htt
p/dubbo）分发到具体任务流中。核心类设计
用例间依赖的实现从用例的复杂度上讲，我们的用例主要分为两大类：单一场景的基础用例和复杂场景的组合用例。组合用例是在基础用例的基础上进行一定的集成，用例的输入输出存在一定的依赖。我们实现用例依赖的方式有两种：
通过配置用例的前置后置关系。通过参数注入。第一种方式，在配置用例的时候，给它一个前置用例，当然前置用例也是在平台中管理的。这样当执行到该用例的时候，执行引擎会先去执行前置用例。
第二种方式，针对 Json 格式的入参，我们定义如下格式进行参数注入：
$#a,b,c#$
各个字段分别代表的含义为：
a:被依赖用例的ID
b:被依赖用例响应的字段（key值），比如：name
c:可选字段，当被依赖值位于 array 里面时，取其 index 下标
举例：{"code":"$#8,data,0#$","type":"$#10,type#$"}
参数注入的流程如下：
参数注入流程图
断言模块设计在新版系统里面，我们设计了四种类型的通用断言，几乎可以满足我们自己的所有应用场景。这四种类型分别是：
1.是否包含。
响应内容包含指定内容为 true，反之为 false。
2.非空/null。
响应内容非空/null为 true，为空/null为 false。
3.JSON 特定位置的值的“相等”判断。
这种情况系统首先会将响应内容转换成 json，添加断言时需要指定待比较对象在 json 串中的坐标。如果该坐标上的值与指定的值相等则为 true，反之为 false。
那么如何给一个 json 串的每个值设置一个独一无二的坐标呢？考虑到 json 存在嵌套关系且 key 可能重复，我们通过一种复合 key 的来表示这个坐标，例如有如下 json：
"data": {
"list": [
"1",
"2"
],
"info": {
"name": "<font color=#DC143C>认真的身影</font>",
"age": 18
}
},
"code": 200
}
对标红的值的断言可以这样表示:{"data":{"info":{"name":"认真的身影"}}}，如果返回的位置的值为"认真的身影"则判断结果为 true，否则为 false。
4.面向 JSON 的伪代码表达式判断
前面三种类型的断言仅满足了部分场景，对于一些复杂的断言仍然无法满足，比如上文 json 中 list size 的断言。为此，我们引入第四种断言方式---伪代码断言。针对 list size 的断言我们可以这样写:
<center>getJSONObject("data")getJSONObject("list").size() > 0</center>
代码在处理的时候会将该表达式拼接在 json 对象后进行执行。整段代码执行的结果为真断言为 true，否则为 false。
伪代码的动态编译、加载和调用，采用 GroovyShell 来实现。该部分代码实现如下：
新版系统满足了用例的可配置化以及可视化的要求，同时也牺牲了一部分的灵活性。例如一些复杂断言的伪代码会非常长，且可读性不高，一不留神就会出错；简单的用例依赖可以满足，复杂的用例依赖却很难满足。比如用例 A 在某些条件下依赖用例 B，其他条件下依赖用例 C，这种复杂依赖关系走配置化并不合适。基于以上考虑，我们在现有的系统的基础上又增加了插件化的特性，来支持复杂用例的接入。
3.0 版系统架构图
插件化的设计思想如下：
平台对外提供一套用例标准，测试同学开发符合标准的用例添加到平台即可运行。用例与平台完全解耦，用例在平台可配置。用例支持热插拔，平台无需重启。用例标准通过接口的形式对外提供，封装成jar包暴露出来。用例设计者直接依赖该jar包并实现指定接口即可。用例接口定义如下：
public interface AbstractTestCase { CaseResult before(); CaseResult run(); void after();}用例开发完成后打包成 jar 包上传到平台，一个 jar 包中可包含一个用例也可以包含多个用例。
jar 包上传后平台要做的事情如下：
动态把 jar load 进 JVM解析实现了 AbstractTestCase 接口的类按照指定策略调用类中的方法上报并展示结果数据获取 jar 包中实现了 AbstractTestCase 接口的代码如下:
/** * 获取jar包中某接口的实现类 */public static List<Class<?>> getAllImplClassesByInterface(Class c) { List<Class<?>> filteredList = new ArrayList<Class<?>>(); //判断是否是接口 if (c.isInterface()) { try { //获取jar包中的所有类 List<Class> allClass = getClassesByPackageName(); allClass.forEach(clazz -> { if (c.isAssignableFrom(clazz)) { if (!c.equals(clazz)) { filteredList.add(clazz); } } }); } catch (ClassNotFoundException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } return filteredList;} 未来未来有赞线上拨测系统会提供更丰富的功能，例如更灵活的用例执行策略，核心用例执行频率更高，边缘业务执行频率降低；更全面的报警策略，各个业务方可以自由定制关心的用例，线上问题第一时间触达；支持多机房，目前该系统只在单机房进行部署，有赞核心业务已完成多机房部署，拨测系统也会随之调整；系统支持分布式，为了防范系统单点故障，未来还会考虑进行分布式部署。
目前这套系统可以保障测试同学第一时间知晓有赞线上核心业务异常，将来保障的业务广度和深度会进一步提高，成为有赞线上质量保障至关重要的一环。