在很多公司的测试流程中，自动化早就不是新鲜事了。

测试工程师自己写脚本、每天定时跑测试、生成报告也没问题——听起来已经挺“数字化”的。

但一深入了解流程，就会发现一个反差很大的现象：

脚本写好了、报告也有了，可系统里的测试记录，却还是靠“人工补录”。

项目经理想看覆盖情况，结果流程平台里空空如也；上线出问题，领导问“有没有测这个”，测试团队一查——根本没有对应的测试用例记录。

这不是哪家公司的特例，这是很多中小型团队在“自动化测试”这块常见的数字化断层。

用例管理「事后补录」= 错过了提效的关键时机

现在不少团队是这样操作的：

  1. 自动化测试脚本跑完，生成报告（JUnit、Allure 等）；

  2. 再通过插件或人工操作，把测试结果导入管理系统；

  3. 最后顺带“生成”一下测试用例，或者勉强补几条记录。

听起来流程挺顺，但问题也很明显：

  • 没跑就没有记录——系统上线前，你压根不知道测了哪些点；

  • 脚本写归写，用例补归补——中间缺乏结构映射；

  • 一旦出了事，追溯不便、追责模糊、过程失控。

更严重的是：大家以为已经“自动化了”，却根本没有“管理化”。

📌 现实和理想之间，还有一个“落地的动作”

当然，从流程设计角度来看，测试流程的顺序应该是：

有需求 → 写测试用例 → 再写测试脚本。

这是最标准的模型。但现实中，尤其是中小团队，节奏常常是这样的：

  • 需求还在变，测试工程师就已经开始写脚本；

  • 脚本里确实“有测试”，但系统里却查不到；

  • 测试用例的管理变成了“事后补课”，甚至被彻底忽略。

我们不否定理想流程，而是希望给现实中的团队一个更顺手的解决方式：

让“已经写了的测试脚本”，也能成为系统中“看得见、查得到”的测试记录。

第二个“断层”：用例里只有路径，没有内容

还有一种更隐蔽的问题是：一些团队虽然在任务系统中挂上了测试脚本路径，但——

点进去，是一串文件路径，甚至是个 Git 地址，没人点开看，没人真的知道脚本测了什么。

这就导致：

  • 测试经理看不到脚本逻辑；

  • 产品经理也无法确认功能是否被充分覆盖；

  • 回顾阶段想追溯验证流程，只能靠“人记忆”。

所以我们做了什么？

我们做了一个开源小工具，它的目标很简单：

把你写的测试脚本，自动提取成结构化内容，生成到你的流程管理平台中。

Image

说白了，就是让测试代码自己“说话”，一边写脚本，一边建记录。

而且不仅是“挂路径”，我们提取的是脚本里的内容结构，包括：

  • 测试类、测试方法名；

  • 方法注释、参数结构；

  • 如果你用 RobotFramework，还能提取出步骤级内容。

用例不再是“文件名 + 链接”，而是完整的、可复查的测试内容，直接在 Jira 中就能一目了然。

流程提效，不一定靠换系统

很多企业一提数字化测试管理，就想着重金换平台、上 CI/CD 大系统。其实多数时候，你只需要把现有流程“打通”一段，让测试和管理之间的数据流动起来。

我们这个工具就是个“流程小插件”，不换系统、不改工具，只是：

把你已经写好的脚本，用上管理的脑子。

🔧 工具试用与开源地址

这个工具目前已经实现第一版，分为两个版本供不同团队选择：

✅ Python CLI 工具（开源）

适合开发/测试团队本地集成，支持 Pytest、Unittest、RobotFramework 自动提取测试用例，测试管理系统目前只支持 Jira 上的 Top 1 测试管理插件 Xray，本地集群版和 Cloud 版都支持。

pip install atlassian-auto-test-case-manager

https://pypi.org/project/atlassian-auto-test-case-manager

✅ Jira Cloud 插件版本（即将上线）

我们也同步开发了流程平台插件版本，适配 Jira Cloud + Xray 这套主流组合：

  • 无需命令行操作，支持从 GitHub 远程读取脚本；

  • 一键生成测试用例；

  • 支持结构化展示，自动入库、自动同步，流程管理更轻量。

📌 当前已提交 Atlassian Marketplace 审核中，欢迎感兴趣的测试主管、项目经理留言预约体验。

我们相信：流程跑得快不重要，流程跑得对才最值钱。

关注我，一起让数字化管理真正落地。