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

在上家某知名潮牌电商公司曾经独立做过一个业务 &领导需求的测试平台，今天让我来稍微回顾下。

大概按照进行的阶段分三片分享完，后边如果有可能再分享技术实现。

本篇为第上篇：自动化结果汇聚功能

由于业务和人员的极速扩张，整个局面处于百废待兴阶段，有太多方方面面的事情要做，前五个月基本上都是在给各式各样的需求进行支援，最近的两个月多月才比较固定做技术域的事情。

所在组主要是做一些平台和工具开发，以及一些专项测试，基本好多公司在做的我们也都在搭建，比如用例、造数、覆盖率等等平台 &工具，以及移动、服务专项等，我是负责从 0 开始搭建的一个接口自动化平台需求，初期主要实现测试结果持久化和质量分析。要得急第一个版本上线要求一周（摊手🤷‍♂️）。

上图给出了目前平台的整体功能的架构，最初的想法和搭建平台的目的在这里总结下，大概有以下几个方面：

• 背景原因: 质量部门按照业务域划分，一般都有来自原有团队现有框架，亦或新团队从以前公司带过来的框架，无法短时间再造迁移，也不太可能统一一种框架；

• 业务痛点: 测试结果没有数据库持久化，都是利用现有的工具包生成的静态文件报告，无法做统计相关分析和历史数据查询；

• 效率问题：自动化本身想要想要起作用，除了框架和代码的稳定高质量，还要做持续集成，分散在各小组基本只能做到 jenkins 定时调度，而且这部分都是一些重复性的工作。

主要是这三点，其实还有包括如运营推广、与其他平台打通等不利的多方面因素，基于上边这些，就诞生了这个自动化平台，其实严格来说算是一个主打报告功能，辅助执行等功能的这么一个平台。然后对于平台功能直接参考上图，短期内规划如此，暂不展开讲了。

接着来看下一个技术相关的图，它主要简单清晰的展示了已实现部分和未来涉及到技术内容，结果上报的部分最开始是通过提供一个开放 API 上报接口，让各个团队的自动化话框架自行改造，将每次本地或者 Jenkins 运行的测试结果上传给平台。

随着业务对接和功能的迭代，其实各团队虽然各框架结构实现方法各不相同，但运行方式总体就是 JAVA TestNG 和 Python pytest 两种，个别使用了 JUnit，而在 JAVA 自动化项目持续集成的方式都是 maven 命令行，Python 项目就是 py 文件执行。所以在汇集结果上报数据的处理无外乎两种方式：

• TestNG：使用自定义监听器，如继承 ITestListener 和 IReporter

• Pytest：使用 Hook，比如利用 pytest_runtest_makereport

这两个框架在自定义报告有很多可研究的地方，后边会搞个系列讲讲，这里仅做个抛砖引玉，既然各测试组都用相同的东西做相同的事情，并且有的组技术能力也有一定的壁垒，因此就有了为了解决这个痛点而出现的 JAVA 上报工具包和 Pytest 上报插件，通过简单的引用配置就能最小成本快速的上报。

再有另外一个核心的功能是平台支持了 Jenkins 无感知的配置和 Pipeline 调度，给出几张截图来看看初步成果。

图 1: 操作新建绑定代码项目，后端会自动配置好 Jenkins 服务

图 2: 进入绑定的项目配置对应的执行计划，TestNG 为 XML，Pytest 为 py 文件。同时支持定时配置，飞书通知基本配置，另外在新建测试后就会自动进行调度执行，然后通过技术架构的三种方式把结果上报到平台，平台进行汇总统计。

图 3: 调度执行完成后，从项目测试报告 tab 或者收到的通知简报上可以跳转到报告详情页，主要展示测试报告的详细信息，并且把错误的 case 优先分类展示，让其第一时间进行确认和处理。

平台还会持续迭代，从文章开始的产品架构图和技术架构已经展示了未来迭代的更多功能，当然规划还是在实际的落地和后续的使用反馈中不断调整变化，很应景我司的一个文化“拥抱变化”。

之前一直想找个点，做个开源的项目，并且希望能有一定的使用价值，而不是为了开源而做再做一个类似接口 web 工具，这个报告平台和插件也许就是个不错的方向，可以在积累一段时间，踩过一些坑后对其重新梳理，把功能更通用需求方面整理，将平台和工具包一并分享出来。

如喜欢通过“点赞👍收藏❤️关注➕”鼓励作者

文章中如有错误或疑问欢迎指正和交流。

大奇 MegaQi｜InfoQ 签约作者