一. 背景

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

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

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

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

Warden 主要由两部分组成：

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

系统架构图：

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

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

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

功能测试应该怎么测呢？

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

流程图：

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

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

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

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

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

如下图所示：

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

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

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

说明：

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

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

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

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

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

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

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

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

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

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