写在前面
质量是企业长远生存的根基，是企业竞争的免死金牌。作为质量控制团队的一员，保障和提高所负责系统的质量，是工作的核心。而完善的测试覆盖，是保证质量的有效手段。
测试按类型来分，分为功能测试和性能测试。功能测试，按照测试金字塔模型，又分为三种：单元测试、接口测试和 UI 测试。单元测试是方法级别的测试，是保证代码质量的基础，一般由开发同学自行完成。接口测试和 UI 测试是端到端的测试，需要覆盖完整的业务场景，一般由测试同学通过自动化的方式来完成覆盖，并加入持续集成中，保证所有提交的代码都不会影响产品的正常功能。
但接口测试和 UI 测试无法覆盖所有测试需求，比如算法。算法作为机器学习和人工智能的基础，其有效性至关重要，特别是在集团智能化运维的大潮下，各种算法层出不穷，寻找有效的方法对算法的优劣进行评测就成了测试团队的职责。但是算法不需要验证接口，也不需要测试 UI，而是需要建立一套有针对性的评测指标，并想办法得到被测算法的各项指标值来对算法进行评价。
算法测试
算法测试的流程其实很简单，只有三步：
- 构造输入
- 使用构造的输入来运行算法
- 获得输出，并使用算法的输出来计算各项指标值，对算法做出评价
把算法作为一个黑盒，测试需要做的就是完成第一步和第三步。其中最重要的又是第一步，因为输入确定了，输出基本就是确定的，不同点只是在于你如何分析而已。那么如何构造输入呢？有两种方法，一是手工构造数据集，优点是较简单，可以随意构造，缺点是无法反应线上的真实情况，会出现大量的漏测场景。还有一种方式是直接使用线上的数据，优点是场景覆盖全面，缺点是数据收集较为耗时。如果能构造一个测试系统，使得线上数据的收集＝》算法运行＝》输出评价成为一个完全自动化的流程，那么可以极大的提高算法测试的效率和有效性。
下面将以无人值守发布系统的算法测试为例，介绍一下上述测试思路的一种实现方法。
无人值守发布
无人值守发布（RiskFree）着力与解决快速分析新版本的应用的各项指标以识别异常，拦截有问题的发布，降低发布导致的故障率。无人值守发布系统的输入主要有三个：ali360 的系统监控和基础监控数据、sunfire 的业务监控数据、a3 的日志分析数据。通过算法对这三个系统的输入数据进行分析，得到异常分，对于异常分较高的应用触发拦截。
故障回放测试
要对无人值守发布系统进行测试，除了保证其基本功能外，最重要的是要对其算法的有效性进行验证，主要落在两个指标上：准确率和召回率：
- 准确率 ＝ 有效拦截 (潜在故障)/ 所有拦截
- 召回率 ＝ 有效拦截 / 所有应该拦截的发布单
测试需要构造一个数据集，使得通过该输入得到的输出可以正确的反映算法的准确率和召回率。给开发一个准确的参考，验证自己的优化是否有效。
输入数据集由各个监控系统的输出数据构成。且不说监控系统输出的数据量大且复杂，手工构造数据效率底下且工作量大。就算是最后手工成功构造了数据集，也无法保证数据的有效性和覆盖率。在测试流程里的准确率和召回率高，并不意味着在线上可以有效拦截故障，这就使测试的价值大打折扣。
所以最有效的方法就是直接录制线上的监控数据，并用该数据集做回放来验证算法的效果。而且为了提高测试效率，解放双手，需要将数据的选择、收集、回放、结果展示做成一个自动化流程，使得开发可以一键触发，选择任意想要的数据集进行回放。
对于无人值守发布系统来说，一次发布对应一个 plan。所以基本思路就是录制该 plan 运行过程中三个监控系统产生的所有数据，并分别存放在三个表中。然后调用 riskfree 提供的通过 planId 触发分析的回放接口，返回对应的录制数据，完成回放。最后在 plan 分析结束后收集结果，进行展示。下面将录制和回放模块分开做详细讲解。
录制流程
第一步是选择想要录制的 plan。本文中选择的是所有在发布过程中触发了拦截的 plan。为了计算回放之后的准确率和召回率，需要对这些 plan 进行打标，标记哪些是有效拦截，哪些是误拦截。标记标准为：无人值守触发拦截 && 发布单被手工关闭或回滚＝有效拦截，其他的都是误拦截。这种方法理论上可以保证标记的准确性。该任务由定时任务来完成，在每天的零点对前一天的发布单进行过滤，通过对无人值守发布和海狼的数据库的数据分析，计算出需要选择的 plan 和对应的标记，存储到本地的数据库中。
选好 plan 之后，需要将该 plan 分析过程中获取的三个监控系统的数据拉取下来并分别保存。流程很简单，只要把在分析过程中获取到的监控数据全部保存下来即可。由 riskfree 提供录制接口，通过 planId 来重新触发分析，在分析过程中将得到的监控数据通过录制模块提供的 API 存储到录制模块的 DB 中。因为监控系统会存储一个月左右的历史数据，所以只要录制及时，所有对应得监控数据都可以获取到。录制和回放可以使用同一个接口，通过配置项来判断本次触发是录制还是回放。当然录制模块需要做好幂等操作，确保不会有重复得数据被插入到数据集中。
录制模块提供了两种触发录制的方式。一是定时任务，会在每天的凌晨一点将第一步中筛选出的 plan 的监控数据收集下来；二是接口触发方式，可以指定某些 plan 或某个时间段内的 plan 进行录制，主要是重新录制在定时任务中录制失败的 plan。
回放流程
1.录制完成以后，本地的 DB 里会包含各个 plan 对应的所有监控数据，回放时只要将这些数据准确的返回给 riskfree 系统即可。为了完全拟合对监控系统的调用方式，需要提供一个 mock 层，分别 mock 对基础监控、业务监控和日志监控接口的调用。同样的输入，mock 接口和线上真实接口返回的数据必须完全一致。实际回放时，在 aone 的配置项里将监控系统的 URL 替换成 mock 层的 URL 即可。
2.riskfree 的上层是运行层。运行层封装了各种回放模式，包括按 planId 回放、按监控类型回放、按时间段回放、快速回放等等。开发可以通过接口对各种回放模式进行一键触发。运行层的底层是一个并发层，可以配置并发回放 Plan 的个数。通过并发的方式不仅可以压缩回放时间，提高测试效率。而且可以验证在高并发的情况下算法的性能表现。
3.最上面一层是展示层，展示方式包括钉钉提醒、测试报告和趋势图。每一次回放的开始和结束时会有钉钉提醒，结束时的钉钉提醒包含测试报告的链接。测试报告分为概述和详细信息两个部分。概述部分包括回放工单总数、有效拦截数、误拦截数、漏拦截数、准确率和召回率，六个指标，每一个指标都是一个锚点，可以直接跳转到详细信息中的对应位置。详细信息包括五个部分：漏拦截 Plan 详情、误拦截 Plan 详情、与上次回放结果不同的 plan 详情、与线上运行结果不同的 plan 详情以及全部回放的 plan 详情五个部分。每一个详情部分都是一个表格，包括线上 PlanId、回放后产生的线下 planId、本次运行结果、上次运行结果、本次回放耗时、上次回放耗时、对应发布单状态等等多个字段。概述信息和详细信息中的各个对比字段使得开发可以迅速准确的得到本次优化的结果，并快速定位问题。下图是某次回放结果的部分截图。
4.为了直观的展示历次算法优化的效果，对相同数据集、相同监控类型的回放结果自动生成趋势图，并在测试报告中生成对应的链接。下图是历次对 11-03 到 11-10 时间段的 a3 日志分析数据进行回放的趋势图。
写在最后
算法测试的重中之重是构造数据集，而线上真实的数据集往往比手工构造的数据集更有代表性。上文提到的录制＋回放的方法只需稍加变通即可应用在各个算法评测项目中。只要将录制和回放串成一个自动化的流程，即可一劳永逸，不必再担心数据集的构造和更新了。
作者介绍
李朝阳，阿里巴巴研发效能事业部运维域，高级测试开发工程师。2016 年加入阿里，作为质量控制团队的一员，负责混合云、集团 Docker 全链路、无人值守发布系统的质量保证。
更多技术交流：扫码加入钉钉群（群ID:11789512）
