AITA 开发手记 02｜用例导进来了，然后呢？

上一篇聊了聊，我为什么想做一个面向金融测试的 AI 测试平台。

真正开始动手以后，我先遇到了一个很基础的问题：

手里已经有 Excel 用例了，怎么把它们接进平台？

最开始，我觉得这件事应该不复杂。

读一下 Excel，把用例名称、前置条件、操作步骤、预期结果取出来，存进数据库，再交给 AI 整理。

但做着做着，我发现，读出单元格里的文字只是第一步。

真正麻烦的是：这些文字，人能大概看懂，但程序不一定知道该怎么处理。

01｜表格里有内容，不代表用例就说清楚了

先看一条很常见的用例。

乍一看，该有的字段都有了。

熟悉系统的人拿到它，可能也能开始测试：找个账号，准备一笔交易，再看看系统有没有拦截。

但如果要交给程序继续处理，问题就来了。

“填写数据”，具体填哪些字段？

“额度不足”，当前额度是多少，申请金额又是多少？

“正确拦截”，是出现提示、禁止提交，还是进入另一条审批流程？

这些信息没有写出来，后面的脚本就很难有一个明确的执行依据。

所以，这次开发让我先想清楚了一件事：

我要整理的，不只是 Excel 的格式，还有用例里没有讲清楚的内容。

02｜第一步，先把不同表格里的字段对上

当然，业务问题要慢慢解决，眼前还是得先把表格导进来。

不同项目的 Excel，表头往往不一样。

同样是操作步骤，有的叫“测试步骤”，有的叫“操作过程”；预期结果也可能叫“预期输出”或“检查点”。

还有一些表格，前几行是标题和说明，真正的表头在后面。一个文件里，也可能有多个工作表。

因此，我没有直接要求所有人先改成同一份模板，而是先做了字段映射。

简单来说，就是让使用者确认：

这一列是用例名称，这一列是前置条件，这一列是步骤，这一列是预期。

其他暂时用不上的业务列，也尽量保留下来。

比如风险类别、业务编号、用例等级，现在可能还没有对应的功能，但不应该因为平台暂时不认识，就把它们丢掉。

这一步看起来只是导入功能，却会影响后面所有处理。

字段一旦对错，AI 整理得再认真，也是在处理错位的内容。

03｜导入以后，先别急着让 AI 全部重写

几百条用例导进来，很容易产生一个想法：

直接让 AI 帮我清洗一遍，不就好了？

我也考虑过这个方向，但这里有一个问题：清洗到底允许改到什么程度？

比如，原来的预期是：

超过限额时拦截。

AI 整理成：

当申请金额大于或等于可用额度时，系统应禁止提交。

读起来确实更完整了。

但它把“超过”变成了“大于或等于”。

只多了几个字，边界规则就变了。

如果这段内容直接覆盖原用例，后面的测试可能一直在验证一个没人确认过的规则。

所以，我现在采用的思路是：先保留原文，再生成建议，最后由人决定是否采纳。

AI 可以帮忙整理表达，也可以指出问题。但材料里没有的业务规则，应该先问清楚。

04｜有些问题，普通程序就能先检查

在调用 AI 之前，其实可以先做一些基础检查。

例如：

• 用例名称是不是空的。
• 有没有操作步骤和预期结果。
• 是否出现“正常”“正确”“符合要求”这类模糊表述。
• 一条步骤里是不是塞了太多操作。
• 是否存在名称相同或内容相似的用例。

这些检查不一定需要模型参与。

先把明显的问题找出来，既方便人工处理，也能让后面的 AI 整理更有针对性。

不过，检查结果也需要注意分寸。

比如，两条用例标题一样，不代表它们一定重复，可能只是测试数据或者角色不同。

遇到这种情况，我更倾向于提示“疑似重复”，让人看一下，而不是直接合并或删除。

毕竟，少一条测试覆盖，表格看起来可能还更整齐了，但问题反而被藏起来了。

05｜AI 更有用的地方，是帮我把问题问出来

这次做用例整理，我越来越觉得，AI 的价值不只是把句子写得顺一点。

有时候，它能帮我们发现：这条用例到底还缺什么。

还是拿额度校验举例。

原始内容是：

提交超额度交易，验证系统拦截。

整理时，值得提出的问题可能是：

这里指的是单笔限额，还是累计限额？

用什么数据构造“超额度”？

在哪个操作之后检查结果？

拦截后，交易应该处于什么状态？

这些问题一旦列出来，人工审核就有了具体的着力点。

测试人员可以去查需求，也可以找业务人员确认。确认完，再补回用例。

当然，AI 也可能漏问题，或者提出不适用的建议。所以这一步仍然是辅助审阅，需要结合实际业务核对。

理想的结果，是让人少做一些重复整理，多花一点时间确认真正影响结论的地方。

06｜整理完成以后，为什么还要转成 JSON？

到了这一步，用例已经比原来清楚了。

但如果后续每个模块都直接读取 Excel，就会遇到另一个麻烦：大家都得理解不同表格的格式。

生成脚本要读一次，执行要读一次，报告可能还要重新找一遍用例编号。

以后换了模板，这些地方又要跟着改。

所以，我在中间加了一层标准用例描述，用 JSON 保存。

它主要表达几件事：

• 这条用例是谁，有哪个版本。
• 测试前需要满足什么条件。
• 按顺序做哪些操作。
• 在什么时机检查什么结果。
• 最初来自哪份材料。

举个简化后的例子。假设业务已经确认了额度规则和下面这些测试条件，一条描述可以整理成这样：

{"case_id": "CASE-001","case_version": 1,"title": "申请金额超过可用额度时拦截","preconditions": ["测试账号具备交易录入权限","可用额度为100万元"  ],"steps": [    {"id": "s1","description": "填写申请金额101万元"    },    {"id": "s2","description": "提交申请"    }  ],"assertions": [    {"id": "a1","after_step": "s2","expected": "提示额度不足，申请未提交成功"    }  ],"source": {"file": "交易测试用例.xlsx","sheet": "额度校验","row": 12  }}

这是说明思路的简化示例，金额和规则均为假设，不是实际项目规则，也不是可执行脚本。

JSON 的好处，是后面的程序可以按照相对固定的结构读取内容。

比如，知道 steps 里是步骤，知道某条断言关联 s2，也知道出了问题可以回到 Excel 的哪一行。

但这里有一个很容易误解的地方：

变成 JSON，不等于变成自动化。

上面的“提交申请”，还没有对应到具体页面、按钮和执行方法。“额度不足”也还需要确定从哪里读取、怎样比较。

这些都需要后续继续处理。

标准描述解决的是“内容怎么组织”，自动化绑定解决的才是“具体怎么执行”。

07｜为什么我还要保留来源和版本？

刚开始整理用例时，很容易只关注最后那份干净的数据。

但真正用起来以后，经常需要回头查：

这条用例最初在哪个文件里？

这段预期是导入时就有，还是 AI 建议后改的？

审核通过以后，又有没有人修改过？

如果没有来源和版本，最后只能重新翻表格、查聊天记录。

因此，AITA 里会保留用例的导入批次、工作表和行号，也会记录后续修改。

用例发生变化后，之前导出的 JSON 也需要标记为过期，不能让人误以为它还是当前版本。

这部分功能可能没有 AI 生成那么显眼，但对于持续维护一个项目很重要。

毕竟，用例整理不会只做一次，需求还会继续改。

08｜目前做到了哪里？

目前，AITA 这部分已经有了 Excel 导入、字段映射、基础问题检查、AI 清洗建议、人工采纳，以及标准 JSON 预览和导出的基础链路。

但它还有一些限制。

比如，目前导入主要支持 .xlsx，复杂的合并单元格、图片里的内容，还不能指望平台完整理解。字段映射也需要人工确认。

至于整理后的用例能不能真正支持后面的自动化，还要拿具体业务场景继续验证。

接下来，我准备沿着这条线往下做：

选一条确认过的用例，看看它怎么对应到页面操作，哪些步骤能够复用，哪些地方还得补数据、补规则或者人工实现。

这次做下来，我最大的感受是：

把用例交给 AI 之前，先得知道哪些内容已经确定，哪些问题还没有答案。

表格读出来很快，把一条用例说明白，往往才是更费功夫的部分。

AITA 开发手记继续更新。下一篇，准备聊聊：AI 整理出来的用例，哪些修改可以采纳，哪些必须再问一句“依据是什么”？

关于 AI 测研社

专注 AI 测试工程化与自动化 Agent。

分享真实项目、可运行代码、技术实践和开源工具，探索 AI 如何融入自动化测试工作流。