基于云化测试平台的功能拨测与告警

一、前言

1、拨测是什么

拨测是指对系统、应用或网站进行测试，以确定其是否正常工作。在软件开发的不同阶段，拨测都扮演着至关重要的角色。它可以帮助开发团队及时发现和解决问题，确保软件的质量和稳定性。
虽然拨测是保证软件质量的必要步骤，但如何进行有效的拨测也是非常关键的。一方面，开发团队需要具备一定的技术和经验，以确保拨测结果的准确性和可靠性。另一方面，开发团队也需要投入大量的时间和精力进行拨测，从而影响软件开发的进度和质量。以下是一些进行有效拨测的建议：

设计拨测计划： 在进行拨测前，开发团队需要制定拨测计划，明确拨测的目的和范围，以及测试的时间和资源。这有助于确保拨测的有效性和可重复性，并减少不必要的浪费。
选择适当的拨测工具和服务： 选择适当的拨测工具和服务非常重要，可以大大提高拨测的效率和准确性。开发团队可以选择一些成熟的拨测工具和服务。
模拟真实环境： 在进行性能测试时，开发团队需要模拟真实的使用环境，以确保测试结果的准确性。例如，如果软件需要在高负载环境下运行，那么在进行性能测试时，需要模拟这种高负载环境。
定期进行拨测： 软件开发是一个持续不断的过程，因此定期进行拨测非常重要。定期拨测可以帮助发现潜在的问题和漏洞，并及时进行修复和优化，从而提高软件的质量和可靠性。
分析拨测结果： 在完成拨测后，开发团队需要对测试结果进行分析和归纳，以确定哪些方面需要改进和优化。例如，如果发现性能问题，开发团队可以考虑优化代码或增加硬件资源来提高性能。

简而言之，拨测是指对系统、应用或网站进行测试，以确定其是否正常工作，是质量看护的一项重要手段。

2、带业务逻辑与不带业务逻辑

在明白的拨测的用途后，我们还需要对拨测做一个简单区分。
这里，我们从复杂度以及具体用途的视角，可以将拨测分为两类：一类是带业务逻辑的拨测，一类则是不带业务逻辑的拨测。

所谓不带业务逻辑的拨测，指的是发起的测试更多的关注点在于网络、接口等的具体可用性，是否通常正常。我们常用的health_check就是比较常见的不带业务逻辑的拨测，诸如“页面元素检测”、“API可用性快速检查”、“阿里云网络拨测工具
”等都是属于不带业务逻辑的类型，其特点主要是方便快捷、能够以秒级的形式做快速检查。
所谓带业务逻辑的拨测，则是指发起的测试并非简单的网络检查，而是会编写较为复杂的测试用例、构造满足条件的运行环境与数据、定义不同检查点及对应状态等，以此检查服务具体的业务逻辑可用性与正确性。这里的测试用例严格要求满足setup、 teststep、teardown等步骤，需要大量的执行机与资源环境，因此其特点主要是可测试完整、复杂的业务逻辑，但执行要求较高、速度较慢。

3、云化场景下的新挑战

到了今天，在企业总体上云、开发DevOps化后，看护现网质量的诉求呼声也越来越高，其中拨测作为质量看护的重要手段，也转变为基于云化测试平台的在线测试。

然而，虽然在线的云化测试平台简化的测试人员编写用例、构建执行环境的工作量，但海量的测试用例如何有效地利用、定时发起在线拨测，并采取分层分级的有效告警以满足研发段/现网的问题快速发现与拦截，成为了现阶段全新的挑战。

针对上述问题，我们构建了专属的测试任务管理调度与告警平台，在实现妥善管理在线拨测测试任务的同时，实现了现网的快速预警。

这里，我们主要使用如下技术栈：

Django + Python
- 使用Django作为开发基础框架，一方面框架较为成熟、易用；另一方面方便我们快速搭建前端交互与管理看板。
Celery + RabbitMQ
- 拨测本质上需要我们快速、定时发起测试任务，因此异步任务必不可少。这里，我们使用了Celery作为异步任务调度框架。
- Celery 需要一个中间件来进行接收和发送消息，通常以独立的服务形式出现，称为消息中间人（Broker）——这里，由于RabbitMQ 的功能比较齐全、稳定、便于安装，因此我们使用它作为Broker。
基于API Gateway（网关）的API调用
- 服务间的交互、测试任务数据的获取与发起等，都设计到我们自身的微服务与在线云化平台的交互，由于不涉及大批量的数据同步，因此我们主要使用API进行信息与数据的传递。
- 同时，为方便API的管理、授权、流控等，我们使用API Gateway来实现接口额访问。

二、基本方案

1、拨测的实现

总体来说，我们通过定义定时触发的异步任务的方式，对被看护服务在PaaS云化在线测试平台所配置的测试任务进行出发、检查执行结果并做相关告警。

在具体实现上：

服务首先会在云化测试平台中完成用例撰写、组织测试任务，确保在线用例可正确、成功运行；之后，我们自身服务会利用测试平台所提供的API进行任务详情信息获取（任务id、任务信息、标签信息等），并通过测试任务标签做拨测看护任务的筛选。
- 首先，在云化测试平台可以很方便的通过可视化的拖拽的方式完成用例的撰写、并自动生成测试脚本，这里拖拽的是一种名为ActionWord的单元，可以理解一个个原子化的接口，其本身也是通过API文档yaml所生成的。前置/后置/检查点等内容也可以很方便的设置。同时，也支持将不同的用例放在一起作为一个测试任务（测试套），总体执行、计算通过率等各项指标。
- 其次，服务可以灵活使用标签机制，对测试用例、测试任务打上不同类型、不同等级的标签，这样既方便管理、也为我们后续拨测与告警提供分层分级的依据。
- 最后，我们通过API所获取的并不是测试脚本内容或其他，而是通过对标签类型的查询筛选，先找到所有需要拨测的测试任务id信息，通过此id可以进一步通过调用API的方式在云化测试平台自动发起测试任务。
在完成必要的前置步骤后，我们会对获取来的这些测试任务信息进行定时触发、并定义回调接口在任务执行完成是自动将测试任务执行结果回传，而后我们直接对执行结果做判断分析，以实现对研发段/现网接口与功能特性的巡检与问题的快速发现。
- 首先，我们对测试任务的发起与结果获取均通过API进行交互；这里，由于本身测试任务执行时间长短不一（几秒钟到十几分钟不等），因此我们定义的回调接口方便快速获取测试任务的执行结果
- 其次，实际测试任务的执行并不是在我们服务侧处理，而是在云化测试平台执行。这时因为实际用例的执行还是需要执行机与执行环境的，这些需要大量的资源，而我们服务本身主要负责任务的触发调度与告警监控，没有条件、也没有必要大包大揽完成所有工作。
在获取到了测试任务执行结果后，我们会对结果数据做相关分析，判断异常点与异常情况，并根据异常等级发起告警。
- 对于异常情况而言，首先在线用例在撰写时都要求定义对应的CheckPoint：也就是所期望的接口的返回结果，例如状态码应该是200、返回值中应当带有Success等字段等，如果不满足检查点中所定义的条件，用例本身就会报错、显示执行失败。除了上述既定的失败的判断，我们还会根据接口失败的具体返回结果信息做进一步分析，尝试先于用户一步给出接口失败的原因。
- 对于拨测策略而言，我们会根据测试任务标签类型来对测试任务做不同的分类：
  - 对于服务的核心特性，我们会以极高的频次（例如数秒）快速发起测试，以一种探活的逻辑确保现网接口健康，避免重大故障发生；
  - 对于服务的重要特性，我们会对该类型的测试任务进行高频次（例如1分钟）的任务调度，及时发现重要故障；
  - 对于服务的普通特性，我们更偏向于以较低的频率（例如30分钟）进行类似巡检的策略确保总体功能可用；
- 对于告警策略而言，首先必须要说明的是，告警的分层分级必不可少，否则让服务被事无巨细的海量淹没会彻底丧失意义。对于拨测告警，我们一方面会根据出现故障的特性重要程度来判断，另一方面也会根据故障所处环境类型、故障服务等级、任务用例失败比例等来定义告警等级：
  - 首先，告警等级一般分为：致命、严重、普通、提示四类；
  - 其次，核心特性 > 重要特性 > 普通特性；生产环境故障 > 预发环境故障 > 测试环境故障；测试任务全量失败 > 测试任务部分失败；
  - 而后，告警本身也会有升级机制：例如若某个服务、某个环境下测试任务连续失败多次，会根据实际情况将服务等级从N提升至N+1级；
  - 最后，告警会根据不同的等级有不同的发送方法，包括但不限于：电话、短信、EIM卡片消息、邮件等等。