基于爬虫的测试自动化经验分享

之前很难区分自动化测试和测试自动化之间的区别，一直傻傻分不清楚，最近在工作实践中，突然对测试自动化有了深入的理解。

个人理解：自动化测试侧重于测试，是一种测试技术。测试自动化侧重于自动化，是一种测试工作方式或者思路。

下面分享一下我的测试自动化一段经历，抛砖引玉，欢迎一起交流。

背景

公司基础架构组提供了一个监控大盘，里面对以业务线、服务、节点维度对节点进行了分类，对于单节点监控信息包括不限于：CPU，内存，JVM、Tomcat、QPS、RT、网络等等，更细节的监控指标这里就不多说了。

通常我们在做性能测试的时候，基本都是事先知晓被测接口和服务的调用链路，在测试中会看一下相关节点的的监控，一旦触发阈值，立刻停止增压，保持压力或者降低压力（考虑到监控延迟和请求堆积）。

痛点

第一个痛点：无法实时观察各个链路资源监控，每个节点一个监控页面着实有点多，各个节点的资源分布基本是一致的。第二个痛点：总有一些无法预知的资源节点逃脱预设监控范围，大多是服务间相互调用导致的。第三个痛点：统一报警规则不适用性能测试，无法定制化。

测试自动化

通过痛点的整理归类，原因就是两只眼睛盯不住那些监控。所以想到一个解决思路：通过爬虫解决监控问题，结合机器人通知及时预警。主要原因如下：

1. 需要判断的都是数字，可以定制化
2. 数据源可靠，数据结构几乎无变化
3. 监控的颗粒度足够小，满足需求
4. 机器人通知灵活可靠，定制化程度高
5. 监控地址规则固定，报警信息可一键直达监控

多级推送

为了更好地发挥报警系统的作用，我做了三个级别的报警推送，对应三个不同的报警机器人。

1. 普通监控：最低级别的监控，通常用于提醒即将发生的更严重预警
2. 严重预警：需要立即停止测试或者需要立即周知相关人员的资源占用率较高问题
3. 异常预警：包含各类异常情况，CPU毛刺严重，blocked线程，Tomcat线程池或者频繁GC问题

坑

当然这过程中也遇到各种各样的问题。下面记录一些问题以及我想到的解决办法：

1. 监控毛刺：Java服务的毛刺通常跟GC相关。解决方案：结合GC情况判断报警级别。
2. 服务重启：重启会导致各项监控指标剧烈变化。解决方案：结合QPS变化情况判断是否在重启。
3. 定时任务：通常会引起资源占用升高。解决方案：结合QPS变化以及平均值信息判断报警级别。
4. 重复报警：一个数据点被多次扫描到。解决方案：增加休眠补偿，将监控间隔和脚本间隔调节一致。
5. 指标设计：阈值设计参考日常测试标准，结合监控脚本运行记录小数据分析，调整阈值。
6. 历史数据：通过LevelDB记录历史数据，不依赖外部服务。

成果

• 极大减少了监控占用的精力，避免了遗漏
• 发现了几个线上服务的BUG
• 某几次服务异常，提前1 ~ 2分钟发出预警
• 报警文案增加小组标识，极大提升了存在感

做完这些总结突然发现如果把测试自动化和办公自动化放在一起，就更容易理解这个词了。