作者：张雅瑜 编辑：毕小烦

一. 背景

随着业务的发展，应用越来越多，并且承载的业务量越来越大，对各个业务系统的稳定性及可用性带来了新的挑战：

1. 应用之间有很长的调用链路，有时候出问题的是上下游的应用，增加排查难度；
2. 线上应用均为集群部署，日志量巨大并且会定时清理，历史日志很难追溯及定位；
3. 通过 Zabbix 来监控机器，无法及时发现应用本身出现的问题。

因此，亟需一个系统来承载全局应用可用性保障能力，也就是 Warden。

最初 Warden 的功能仅包含监控报警，日志采集两大模块，随着可用性的需求越来越多，在日志和监控的基础上又衍生出来调用链流量分析，应用的稳定性指标等更多功能。

本文主要介绍公司自研的可用性保障平台（Warden）的自动化测试探索与实践，主要针对监控报警和日志采集两个模块。

Warden 主要由两部分组成：

• Warden Agent（以下简称 Agent）：采用无侵入的方式，作为一个单独的进程部署到业务应用所在机器，可以对磁盘上任意位置的日志进行解析，生成结构化日志上传；同时，还可对机器 CPU、内存、JVM 进程进行监控，每分钟上传一次的监控数据；
• Warden 服务端：下发采集指令和监控指令，收集 Agent 上传的数据并入库，对统计过来的数据进行分析后通过图表展示，发送报警。

系统架构图：

二. 如何进行自动化测试？

自动化测试基于功能测试而来，我们从功能测试的思路及校验点出发，然后看其如何转化为自动化用例。

功能测试分为以下三个部分：

1. 日志采集：对于不同格式的日志配置不同的解析方式，Agent 能正确解析日志并上传到消息中间件，服务端能正常接收消息并入库；
2. 监控数据采集：监控数据采集分两个部分，一个是基于日志计算出来的聚合数据，一个是对机器本身的监控，两者与日志的采集流程类似；
3. 报警功能：当某个监控数据的指标超过阈值，则会触发报警信息。

   2.1 功能测试

   功能测试应该怎么测呢？

结合 Warden 的系统架构，我们再更深入了解一下日志采集的过程：

流程图：

在功能测试中遇到的第一个问题便是：日志的来源

在生产环境下，日志是业务应用打印，由 Agent 采集的，每个业务应用打印的日志虽然有框架的规范，但是格式依然很多，甚至有一些自定义的格式，测试要覆盖尽可能多的日志格式，就不可能拿真实的业务应用进行日志打印。

如果拿线上应用的日志文件直接进行测试，也会有以下问题：

1. 日期问题：日期并非实时，而日期是 Agent 采集逻辑的一部分；
2. 逻辑问题：Agent 对已有日志的采集跟一边打印日志一边采集的逻辑会有所不同；
3. 格式问题：不同日志的格式虽然能收集齐全，但是对于一些异常情况的构造不够灵活，有一些潜在的非标准日志格式，线上的应用未必会有，但确有可能在某些异常场景下触发。

因此，权衡后的解决方案是：

准备一个测试工程，通过 HTTP 请求触发日志的打印，可以指定打印日志的格式、路径、打印的条数等，这个测试工程收集各种已有的日志格式，并且可以根据未来线上遇到的新场景来构造新的日志打印异常场景。

如下图所示：

测试用例要用到的配置：Warden 服务端 URL、测试工程 URL、中间件地址及配置

2.2 自动化测试

解决了功能测试的问题，要如何进行自动化测试呢？

先看看我们的自动化测试工程框架：

说明：

• 测试类：每个测试类对应一个测试用例，一般为一个接口或一个功能点；
• 父类：所有测试类都继承该类，测试类中的一些公用的方法可以提取到父类中，例如登录、配置文件中的参数获取等；
• Excel：数据驱动，每个测试用例，在不同的入参下会有不同的预期结果，将入参和预期结果填写在 Excel 中，每个测试类对应一个 Excel 文件；
• 配置文件：存储全局变量，例如用户名、密码、URL 地址等。

由于日志采集是一个完整的流程，为了方便用例的维护，我们抛弃了原先将某个接口作为一个测试类的方式，而是将整个流程作为一个测试用例，并创建一个对应的测试类。这个用例的输入就是不同格式的日志，输出就是服务端处理完之后存到库中的数据。

由于测试工程完全可以定制自己的日志，我们完全能预先知道会获得什么样的结果，也解决了自动化测试的流程中，如何校验服务端存储的日志是否正确的问题。

结合功能测试的流程，我们的自动化测试代码流程也就确定如下：

至此，我们有三个测试类，覆盖了日志采集、基于日志的监控和报警三大模块的功能。虽然还有一些其他的场景，比如跨天的日志采集，Agent 重启期间日志的补采等问题，暂时还用手工测试的方式，但已经能解决大部分主要功能的自动化场景。

三. 自动化测试如何提效？

在运行一段时间后，原有的自动化用例的问题也越发明显：耗时长。

耗时长的原因主要有以下两点：

1. 日志采集/监控的配置下发给 Agent，Agent 需要几秒后才会生效，因此在编辑配置到实际触发日志打印前，增加了 5s 的等待时间；
2. Agent 日志采集有 10s 左右的延迟，监控数据至少要等 1 分钟才会上传，所有数据到上传到中间件后，由服务端进行消费再到入库还有几秒的耗时，另外由于执行报警的定时任务执行时间间隔 1 分钟。

因此报警的触发最快是 1 分钟，最慢可能要 2 分钟，为了尽可能保证用例执行的成功率，在校验最终结果之前会设置较长的等待时间，以确保大部分用例能执行成功，个别失败的用例重试一次之后也能执行成功，执行 96 条用例大约耗时 1 小时 40 钟。

上面监控采集用例仅测试到基于日志的监控数据采集流程，没有对于机器的监控数据校验，因为校验监控数据的时候无法事先知道统计结果，而两者监控的处理流程是不同的。

基于以上的痛点，并且根据现实情况来看，服务端的需求较多（因为基于这些统计数据可以衍生出很多功能来），而 Agent 比较稳定，因此决定把 Agent 和服务端的测试用例区分开：

1. Agent 自动化测试：由于 Agent 的改动一般也会涉及到服务端的改动，因此还是保留原先完整流程的测试用例；
2. 服务端自动化测试：与 Agent 解绑，通过代码生成模拟的日志数据和监控数据直接上传到中间件供服务端处理。

这样一来，可大大节省等待 Agent 采集日志上的耗时，也不必等 1 分钟再校验监控数据，因为我们可以直接构造出上一分钟的监控数据。

改造后，三个自动化测试的流程如下：

1. 日志采集：

1. 监控数据采集：

1. 报警功能：

改造后，服务端部分的自动化用例 96 条，运行仅需要 30 分钟，主要是因为报警的定时任务 1 分钟执行一次，因此仍然需要最长等待 1 分钟。

四. 总结

在本次自动化用例的实现中，仍有一些不足与待改进的地方，比如耗时还是会偏长，我们可以进一步优化，将用例再行拆分，也许能让耗时更短，但这就需要维护更多的中间数据，前置准备的数据，大大增加了用例的维护成本。反之，用例若拆得太粗，像第一版的自动化用例那样，流程过长，也会导致用例容易失败，耗时长。

因此在不同的测试场景，我们需要平衡用例的稳定性、可靠性、可维护性、执行的便利性等各个方面，让用例真正做到为测试人员提供便利，而不是增加工作量。

（完）

微信搜索“毕小烦”或者扫描下面的二维码，即可订阅我的微信公众号。

如果文章对你有帮助，记得留言、点赞、加关注哦！