谈谈曾经做的一个测试报告平台 (2)

作者：MegaQi

2022-10-24
上海
本文字数：2488 字
阅读完需：约 8 分钟

在上家某知名潮牌电商公司曾经独立做过一个业务 &领导需求的测试平台，今天让我来稍微回顾下。
大概按照进行的阶段分三片分享完，后边如果有可能再分享技术实现。
本篇为第中篇：数据报表和 Web 接口配置化

保持每周迭代发版的快节奏，在短短的一个月时间里平台又了不少新功能。

迭代功能

从大的需求方面有两处一个是 Dashboard，这块主要是团队负责人比较关注的层面，他们需要看一些度量信息和趋势变化。

【⬆️迭代图-1】包含两份数据：

平台的概览数据：其中包括绑定的项目数，平台调度执行数（包含手动触发和定时触发），还有近一个月的累计数和通过率。
日构建成功率：仪表盘查看项目当然执行和通过率情况，其中展示了当天多次运行的次数，最高（左），最低（右），平局（仪表盘）

这里的仪表盘采用了红黄绿灯，目前根据项目定的通用条件是，绿灯>＝95%，黄灯>70%，红灯<＝70%

【⬆️迭代图-2】趋势图表示 30 天内每日平均通过率，主要看某个项目通过率是否稳定，是否有某个点的异常情况，以及可以对比出哪个团队自动化做的比较好。图中因为项目多，目前各个团队自身脚本不稳定+多套微服务的测试环境不稳定因素导致了线乱，随着各方面的稳定，理想的趋势线应该是围绕 90%～100%区域呈现。

【⬆️迭代图-3&4】对应上边趋势图，使用堆叠柱状图展示当天执行测试业务的自动化用例数量（去重）以及累计数量，在全量定时全部配置的情况下，反应当天覆盖率，以及自动化 CASE 的增长变化。

画重点，上边这些图表最终使用的是 G2Plot 组件，官方的描述是开箱即用、易于配置、具有良好视觉和交互体验的通用统计图表库。一开始我调研的其实是 ECharts，但从原始数据结构简单性上来说确前者更容易上手，这两个组建库的使用方式我也将在《提测平台》系列的最后一节报表实现中具体讲讲。

另一需求是 快捷操作 功能，这块主要来自测试同学的较多的反馈需求，之前的进入代码管理执行计划，入口稍微有点深，在快速执行和推动研发自测执行的时候不方便，所以增加一个集快速选择执行和合并状态展示功能。

【⬆️迭代图-5&6】新增我的快捷管理，在头部选择项目、计划、环境便可立即执行，并支持收藏项目优先展示和快速进入项目管理，执行历史将汇集任务 &报告集合在一起进行展示和功能操作，这项功能大大提高了使用率和组外的推广效果。

【⬆️迭代图-7】展示是在原有每日定时基础上增加了 Cron 自定义定时，另外这块定时任务后端实现也从 python apscheduler 迁移到了 xxljob，开源 XXL-JOB 是一个分布式任务调度平台，源代码是两个 JAVA 工程项目，部署容易可以二次开发。

这个找个时间可以写个教程分享出来，提前了解可参考官网 https://www.xuxueli.com/。

迭代的内容只挑选几个变动比较大地方，其他交互优化/BUG 修复/小需求就不在这里讨论了。

平台打通

团队内部用例平台上有个转测单功能，主要是做测试流程管理和质量的卡点，其中对于某个需求可以设置在状态转变的时候触发自动化测试，然后收到自动化测试平台的执行完的回调结果，根据通过率决定卡点过不过，比如研发提测通过率大于 95%才可以进入下一阶段，否则直接通知打回，这是其中一个平台打通功能。

到这里以为就结束了吗？不不不，每天 10 个小时的高效不会只产出这些的，还有个年后的计划被提前的并行开发的大需求在周期内完成了...

单接口测试

类 Postman 界面化的单接口 web，团队维度接口和用例数据共享，目的还是根据公司内部和业务特性降低接口自动化门槛和统一框架与流程，为什么平台一开始就上这个功能，原因在第一篇的有提到过，就是快速将已有分散的自动化统一起来，引导大家平台使用，再有一定依赖度和更多的需求下，推出这个更易用版的界面化配置功能更容易切换，其实简单的说更容易让平台的得到推广和使用起来，看一看多少公司很多类似平台除了为了完成 KPI 和晋级 PPT，易用性、实用性、推广性有多难做。

【⬆️单接口图-1】展示了核心的页面架构，需求设计和实现上主要参考了现在个人认为比较不错的一个可协同 ApiFox 平台，参考就了参考了不避讳，官方的定位 Apifox = Postman + Swagger + Mock + JMeter，相比 Postman 和 Yapi 平台确实是一个服务端做接口管理的不错软件工具，感谢这么好的一个工具，想体验的可以直达官方https://www.apifox.cn/ 了解详情。由于是第一个内部测试板，功能没有上太多，主要是 Http 接口陪着和 CASE 管理的基础功能，以及一种 Json 格式的校验能力，展示上已树的形式全部展示，便于操快捷操作，这也是重点参考 ApiFox 的地方。

【⬆️单接口图-2】是环境管理，这个根据一个业务团队有多个微服务的特点是支持了一套环境下支持多个 HOST 配置，同时是支持部署平台内 Docker 服务 ID 的直接调用。

【⬆️单接口图-3】演示的是个 POST 接口用例请求，有请求参数和返回参数+配置的断言结果，内部基本除了 Dubble 就是标准 HTTP 的 GET/POST 请求，所以优先上的此功能。

【⬆️单接口图-4】配套的用例集管理，主要是创建测试计划进行测试执行。

【⬆️单接口图-5】和上边迭代中的快捷操作页面类似，是集任务调度，报告汇总和快捷执行为一体的“执行报告”管理页面，目前还只是作为状态展示和查询的一个简单页面。

【⬆️单接口图-6】报告部分结果保存与自动化的报告使用的是一个总表，详细表是两表，但展现形式上差不多，所以页面采用的是一个样式，包括飞书的消息通知都是一套，只是在个别字段和逻辑处理上加了兼容性。对于单口测试还只是个初版，这部分也画个重点，前端很多是要定制化所以页面实现是由组内前端同学共同开发而成的，后端技术上，请求逻辑断言等处理是利用 Python requests 库、eval 函数和 jsonpath 库实现了核心逻辑。

随着迭代这部分功能应该也会越来丰富，但绝不是重复造轮子再写个 WEB 版的 Postman，而是打造一个符合质量团队需求，适应业务形态的提升测试质量的效率平台，后续规划上短期和长期会有如下一些打算：