我最近几乎每周都会接到类似的咨询：“我们想给自动化测试接入AI，你觉得第一步该干什么？”

说实话，第一次被问到的时候我也差点给出“先选模型、先搭平台”这种答案。但前后陪跑了几个团队之后，我的结论越来越一致：想让自动化测试真正接住AI，第一步不是选工具，不是买GPU，也不是定框架，而是先把存量测试资产变成AI能读懂的基线数据。这一步看起来非常不性感，但没有它，后面所有的“智能”都是空中楼阁。

这篇文章我想把“这一步”掰开揉碎讲清楚。它不解决某个具体脚本怎么写的问题，而是解决一个更底层的问题：你手上那堆自动化用例、历史执行结果、失败日志，到底该以什么形态交给AI，AI才接得住。文章适合三类人看：准备给自动化测试引入AI的测试负责人、正在做技术选型的测试架构师、以及被领导安排“调研一下AI测试”的测试工程师。我先说结论：接入AI之前，你得先有一份可学习、可评估、可维护的测试基线资产。

1. 先想清楚：你让AI干的活，到底依赖什么

1.1 别把“接入AI”理解成换一套工具

很多团队一提“接入AI”，第一反应是找个测试平台，把AI功能打开，然后期待它自动生成脚本、自动定位Bug。这个预期大概率会落空。

我见过比较务实的落地方式，不是把整个测试体系推翻重来，而是让AI嵌进原有流程里的某些具体环节。至少有三类事情是当前实践里真正能做出效果的：第一类是把自然语言转换成自动化用例，测试同学用一句中文描述场景，AI生成可执行的脚本；第二类是给已有的手工用例自动补步骤、补断言，让用例从“能跑”变成“知道什么是对”；第三类是失败诊断，用例跑挂了之后，AI分析日志和截图，给出最可能的失败原因和修改建议。

这三类事情有一个共同点：它们不是从零凭空变出结果，而是基于你提供的样本去做推理和生成。样本质量越高，结果越靠谱。如果没有样本，或者样本是乱的，AI给你的东西就大概率是“看起来像那么回事、实际跑不通”的废物。

1.2 所有方向都指向同一个前提：数据要被结构化

打个比方，你团队里来了个新同学，上手第一天你要他帮你看一个老模块的测试用例。你直接把几十个Excel文件、几百条微信群里的讨论记录、一堆只有自己能看懂的脚本扔给他，他能干好活吗？大概率不能。你得先告诉他哪些用例是有效的、哪些已经废了、期望结果是什么、以前失败的原因是什么。AI也是一样，甚至更苛刻：它比你新来的同学更较真，给它一份字段对不齐、断言含糊、历史结果缺失的数据，它学到的全是噪音。

这就是我说的“这一步必须要有”的含义：在正式让AI干活之前，你得花一到两周做一次存量测试资产的盘点、清洗和结构化，形成一份AI能直接“读得懂”的基线数据。

2. 这一步必须要有：从存量测试资产到AI基线数据

2.1 基线数据不是一份用例清单，而是三类资产

先说清楚“基线数据”到底长什么样。它不是把你现有的用例导出成一个Excel就完事了。真正能支撑AI落地的最小数据集合包含三类资产。

第一类是结构化用例集。每条用例至少要有模块名称、用例标题、操作步骤、预期结果、优先级、用例类型，其中用例类型要区分正向、反向、边界和异常。很多团队现有的用例里根本没有“用例类型”这个字段，这会直接影响AI判断“什么时候该测什么”。第二类是历史执行结果集。用例最近几次执行的时间、结果（通过/失败/跳过）、失败时的报错信息、失败原因标签，这些数据是AI学习“失败长什么样”的唯一来源。第三类是领域语义词典。说白了就是你业务里的常用词表，比如账号、权限、支付、优惠券、订单状态这些词之间的关联关系，以及测试数据里常用的参数模板。没有这份词典，AI生成的用例里会出现大量业务上说不通的组合。

拿一个常见的B端账号体系举例：结构化用例集至少有登录成功、密码错误、账号锁定、找回密码、验证码失效这几条，历史结果集能记录到“锁定后30分钟自动解锁”这个断言最近三次都跑通过，领域语义词典里有“登录态”“会话”“密码错误次数”这些词。这份三者合一的资产，才是AI真正需要的输入。

2.2 为什么要先做基线而不是直接上AI工具

我见过不止一个团队，买了商业测试平台的AI能力，跑了一周，效果很差，最后得出结论“AI测试不行”。其实不是AI不行，是基线没过关。这里有三条血的教训值得展开说。

第一条，没有基线的AI是在无效数据里找规律。你的脚本库里可能有一半用例已经随着版本迭代失效了，对象库里的元素定位早就擦边了，运行结果里大量用例因为环境问题失败。这些数据混在一起喂给AI，AI学到的不是“什么是正确”，而是“什么是混乱”。第二条，没有基线就无法评估效果。AI生成的用例到底是不是比人工写的好，覆盖是不是更全，发现缺陷的能力是不是更强，这些都要和基线做对比。没有基线，你连“指标变了没有”都说不清，更没法向上汇报。第三条，家庭作业式的问题往往藏在脏数据里。最典型的例子是断言写得含糊：“操作成功”“页面正常显示”这种完全不可验证的预期结果，如果不在基线阶段清除掉，AI照着这个风格学，生成的新用例一样是废的。

所以我的观点是：基线数据建设不是接入AI之前的“准备工作”，它本身就是接入AI的第一步，而且是不可跳过的一步。

3. 实操：三步把存量测试资产变成基线集

3.1 第一步：盘点与导出历史数据

这一步的目标不是追求完美，而是先摸清楚你手头有什么。通常需要从三个地方导出数据。

从测试管理平台导出用例数据，可能包括用例编号、所属模块、标题、步骤、预期结果、优先级；从CI平台导出最近三个月的执行记录，包括执行时间、执行结果、失败日志、耗时；从代码仓库里把历史测试脚本和最近相关的缺陷单列表也导出来。建议全部导成统一的CSV或者JSON格式，这个阶段不用做精细加工，但需要建立一个清单，记录每个数据源的准确时间范围和数据量，方便后面排查缺数。

我个人的习惯是将所有导出文件先放进一个临时目录，然后做一次“数量核对”，例如：对照测试管理平台显示的用例总数，确认导出的行数和总数一致；对照CI平台显示的最后100次执行记录，确认日志完整度在95%以上。这个步骤花不了一天，但能避免后面清洗到一半发现数据缺了一大块。

3.2 第二步：清洗、标准化、打标签

清洗是让数据从“能用”变成“AI能用”的核心环节。先做减法，再做标准化，最后打标签。

减法层面有三个硬性过滤规则：删除状态为“跳过”或“阻塞”的用例；删除最近三个版本迭代中从未执行过的用例；删除预期结果中只有“正常”“成功”这类不可验证描述的用例。这三个规则能帮你快速砍掉一大部分无效数据，留下的才是AI真正该学的样本。

接着是标准化，这一步最好让团队内部先定一个最小的字段协议。我常用的字段如下：

• case_id：用例唯一标识
• module：所属业务模块
• title：用例标题
• steps：操作步骤（数组格式）
• expected：期望结果（数组格式）
• level：优先级（P0/P1/P2）
• case_type：用例类型（正向/反向/边界/异常）
• last_result：最近执行结果（passed/failed）
• failure_reason：失败原因（字段级标签）
• exec_count：历史执行次数
• success_rate：历史通过率

字段不要贪多，能覆盖上面11个就足够支撑第一版基线了。标准化之后，我建议直接把每条用例转成JSON格式存下来，这样后面无论是做统计还是喂给模型，都不用再做格式转换。

下面是一个真实的示例片段：

{ "case_id": "AUTH_LOGIN_001", "module": "account", "title": "连续输错5次密码后账号锁定", "steps": [ "打开登录页", "输入已注册用户名", "输入错误密码", "重复步骤3共5次", "输入正确密码" ], "expected": [ "第5次提交后提示账号已锁定", "正确密码提交后仍提示账号已锁定", "页面展示剩余解锁时间：30分钟" ], "level": "P0", "case_type": "反向", "last_result": "passed", "failure_reason": "", "exec_count": 32, "success_rate": 0.97 }

如果历史数据量大，清洗建议用脚本完成。我自己常用Python快速处理，比如pandas读Excel过滤无效行，再统一字段名。

import pandas as pd df = pd.read_excel("raw_cases.xlsx") # 去掉跳过/阻塞 df = df[~df["status"].isin(["skipped", "blocked"])] # 去掉没有明确断言的 df = df[df["expected"].str.len() > 5] # 统一字段名 df = df.rename(columns={ "编号": "case_id", "模块": "module", "标题": "title" }) df.to_json("baseline_cases.json", orient="records", force_ascii=False)

所谓“打标签”，就是给历史失败用例补一个“失败原因”字段。如果历史缺陷单有记录，就人工映射过去；如果没记录，可以先只标一个大类，比如“环境问题”“数据问题”“代码变更”“定位器失效”，后面再逐步细化。这个标签体系是AI学习失败归因的关键输入，宁可粗一点，也不能缺失。

3.3 第三步：固化“种子基线集”，先跑通一个最小闭环

全量数据清洗干净之后，我再建议做一件很多人会忽略的事情：不要立刻拿全量数据去接AI，先挑一个模块，做一份100到300条的“种子基线集”。

选种子模块有几个筛选条件：功能相对稳定，最近三个版本没有大面积改动；流程型用例居多，操作步骤比较明确，有清晰的预期结果；历史通过率在95%以上，说明断言基本是可靠的；模块本身是核心业务，比如登录、订单、支付这类，价值足够高。满足这四个条件的模块，拿来做种子是最合适的。

种子基线集的好处是能让你以最小的成本跑通“基线数据、AI生成/诊断、人工验证、结果回流”这个闭环。我陪跑的一个团队就是用账号模块的230条用例做种子，两周内就把AI生成用例的流程打通了。如果一开始就想着把所有模块上万条用例全部做成高精度基线再启动，项目大概率会陷在整理数据里出不来。

4. 接AI前最常踩的坑：问题排查与避坑指南

4.1 常见问题速查表

很多团队不是不知道要做基线，而是做的时候都踩在同一批坑里。我整理了一张速查表，基本覆盖了接入AI前最常见的几个问题：

这张表建议直接打印出来，给团队做基线建设的时候逐条对照。

4.2 三个现场踩坑实录

先说非常常见的“全量整理好再开始”的拖延症。很多测试负责人一听说要整理数据，就启动了一个“要把所有模块、所有历史数据都清洗完”的大工程，结果一搞就是两个月，AI还没碰。我现在的做法是先切一个小模块快速出效果，用成果去说服团队和相关方，然后逐步铺开。

再说“脏数据喂给AI”的翻车现场。有个团队把清洗环节压缩了一半，把大量没有明确断言的用例也塞进了基线，结果AI生成的用例很多都带着“页面显示正确”这种无效断言，评审的时候被开发嘲笑了。后来回过头把基线里所有含模糊断言的用例挑出来删掉，AI输出质量才恢复。这里要强调一下：宁缺毋滥，基线数据的质量优先级永远高于数量。

还有一个坑是“没有评估指标就上”。有一个团队跑了一个月AI辅助测试，但是说不出任何效果数据，管理层的耐心很快就耗尽了。后来补了三个基础指标才算把项目救回来：AI生成的用例直接采用率（不需要修改就能用的比例）、AI在代码变更后生成的补充用例中实际发现缺陷的占比、AI归因建议被开发人员采纳修复的比例。这三个指标不需要做很重的统计系统，人工按周统计即可。

4.3 一个容易被忽略的细节：效果评估要和基线绑定

这里专门提醒一下效果评估的方法论问题。评估AI辅助测试有没有成效，不能只看“AI生成多少条用例”，而要回到基线来做对比。比如种子基线集里有230条用例，其中人工发现的缺陷数是A，AI补充的用例额外发现的缺陷数是B，那么你判断AI价值的时候要看B相对于A的提升比例，以及这些额外的缺陷是不是真实有效的。如果没有基线，你拿着“AI生成了500条用例”这个数字给领导看是没有意义的，因为多生成不等于多发现。

另外，在跑效果评估前一定要留出“对照期”。最简单的方法：沿用现有的人工测试流程跑两周，记录平均每条缺陷从发现到定位花费的时间；之后接入AI辅助诊断，再记录两周。两边数据一比，价值就出来了。这一步很笨，但很有用。

5. 基线到位之后：两条典型落地路径与运行闭环

5.1 路径一：AI生成增量用例

基线集建立后，最常用到的能力是AI基于现有用例的风格和业务规则，生成新的增量用例。

举个例子，种子基线集里已有的登录场景覆盖了密码错误、账号锁定、验证码失效，但代码变更给登录页新加了一个“滑块拼图验证”，这时候你用自然语言告诉AI：新增登录场景，页面多一个滑块拼图验证，验证失败后需要重新登录。AI就可以基于基线里已有的账号锁定用例的步骤风格，自动生成“滑块验证通过后正常登录”和“滑块验证失败5次后账号锁定”这两条新用例。人工只需要做一次评审，调整一下步骤里的细节，就能合入正式用例集。

这里有个实用的评审办法：AI生成的用例刚拿回来时，不要直接信，先抽20%做人工跑测，看步骤能不能复现、断言能不能成立。如果能复现而且断言在旧代码上不成立、在新代码上成立，说明这条用例是有增量价值的，可以收进基线。

5.2 路径二：AI辅助失败分析

另一个见效很快的场景是失败日志归因。没有AI的时候，一条用例挂了，测试同学可能要翻半天日志，还要去代码里找对应的逻辑关系。有了基线之后，AI可以基于历史失败原因标签，在几秒钟之内给出一个归因建议。

具体流程是：用例执行失败、AI读取失败日志和当前用例的历史成功率、AI对照基线里的失败原因标签和对应日志特征，给出“最可能的失败原因Top 3”，并附上“建议检查代码位置”。比如账号锁定那条用例失败了，AI看到历史失败记录里80%的同类失败是“断言等待时间不足”造成的，它会优先推荐检查等待策略而不是怀疑业务逻辑变了。这样做最大的价值是缩短排查链路，将“失败后定位原因”的时间从平均二十分钟压缩到几分钟。

不过要说清楚，AI给的是建议，不是结论。所以团队内部最好跟开发约定一个反馈机制：开发人根据AI建议定位并确认原因后，将最终结论回填到失败原因标签里。回填次数越多，AI后续的归因越准，这是一个持续变好的过程。

5.3 别忽视“返回去喂”的闭环：基线集要持续维护

基线数据不是一次性交付物，建完就扔在角落吃灰，那就跟没建一样。它需要维护，而且是用真实运行结果不断反哺。

我常用的维护机制是三件事。第一，每周做一次执行结果回填，把本周新跑完的用例结果合并进基线，尤其是新失败的用例，一定要补上失败原因标签。第二，每个月做一次基线用例淘汰，把连续执行超过20次都通过、且相关业务已经完全改版的用例，降级标记为低优先级备选，避免给AI的样本里塞太多过时模式。第三，每次人工评审通过AI生成的用例后，立刻把新用例合入基线，这样AI的学习样本池会越来越大。

等到基线集持续运行两三个月之后，你会慢慢感觉到AI生成的质量比最初稳定不少。这是因为喂给它的样本池从“一次性整理出来的静态数据”，变成了“跟着业务演进的活数据”。这一步才是自动化测试接入AI真正走向正轨的标志。

我在实际陪跑过程中最深的体会是，接入AI这件事，真正拉开团队差距的不是模型选得多好、参数量有多大，而是那批没人愿意花时间整理的存量测试资产有没有被正视。很多团队缺的不是AI能力，而是一份能喂给AI的干净基线。先沉下心来把基线做好，哪怕只做一个小模块，后面所有环节都会顺很多。

最后再给一个检验基线是否就绪的小方法：随便找一位测试同学，给他一条历史失败用例和对应的缺陷单，如果他能在一分钟内讲清楚用例测的是什么、为什么失败、正确的期待结果是什么，这就算就绪了；如果他支支吾吾说不清，那就还需要回到清洗和打标签这一步补课。数据基础打不牢，AI带来的只会是更多噪音，而不是更多价值。