AI 辅助测试

• LLM 生成测试的可用性（能生成、能跑通、但覆盖率与真实性有限）
• 生成测试的局限：断言过弱、覆盖幻觉、与实现耦合、难以发现真 bug
• 有效性评估：变异杀死率、缺陷发现率、人工审查

LLM 生成测试用例的能力已相当可用，能快速生成单元测试、集成测试的骨架与常见场景，但存在明显局限：生成的断言往往"照着实现写"而偏弱（只验证实现本身而非行为契约）、容易产生"覆盖幻觉"（声称覆盖了分支实际没有）、对真实 bug 的发现能力有限、可能生成与实现强耦合的脆弱测试。生成测试的可用性取决于任务清晰度与代码可读性，对复杂业务逻辑生成质量大幅下降。评估生成测试的有效性不能只看"能跑通"，核心指标是：变异杀死率（Mutation Score，注入变异体后测试能否杀死，衡量测试真正检测行为的能力）、缺陷发现率（在植入缺陷的代码上能否发现）、以及覆盖率（行/分支/条件覆盖）与人工审查结合。生成测试应作为辅助快速铺覆盖，再通过变异测试与人工完善关键断言，而非直接信任。

得分点是"能用但不可全信"，并给出变异杀死率等有效性的客观度量。能指出"断言照着实现写"的局限，说明理解 LLM 生成测试的深层缺陷。

• 测试 Agent 的能力：自动探索、生成用例、执行、报错分析
• 落地边界：复杂业务与长链路稳定性、环境依赖、成本
• 覆盖充分性验证：覆盖率、用例目标分布、与人工用例对齐

大模型驱动的测试 Agent 能自动探索应用、生成并执行用例、分析失败并迭代，已在半自动测试中落地，但边界明显：对复杂业务规则、需要领域知识的长链路、真实环境浅层依赖（账号、支付、权限）的场景，Agent 容易陷入无效探索或生成表面用例；成本与稳定性（长上下文、token 消耗、循环失控）也是限制。Agent 适合"快速冒烟、探索性的广覆盖"，不适合完全替代领域专家设计的关键回归。验证覆盖充分性需：统计行/分支覆盖率交给 Agent 后的增益、对比 Agent 生成用例与人工用例在需求覆盖上的重合度、检查是否覆盖了核心业务路径与边界条件、用变异测试衡量 Agent 用例的缺陷发现能力，并设置"覆盖缺口"报告（需求未覆盖清单）由人工补足。Agent 的产出需人工抽检与门禁，避免低质量用例混入主套件。

得分点是"分清楚 Agent 能做什么与不能做什么"（落地边界），以及"用覆盖率+需求覆盖+变异测试验证充分性"。强调 Agent 是辅助而非替代，是务实判断。

• 覆盖率幻觉的定义：模型错误声称覆盖了某分支/路径
• 产生原因：模型不理解真实执行路径、臆断
• 以实际执行为准：用覆盖率工具实测而非信任模型

"覆盖率幻觉"指 LLM 声称其生成的测试覆盖了某个分支或路径，但实际执行时该分支根本没有被触发。原因是模型基于对代码的静态理解臆断执行路径，未考虑真实运行时条件、异常路径、数据流选择。此问题会导致测试套件看似覆盖充分、实则存在未测分支，而开发因此误判测试质量。验证方法的核心是"以实际执行为准"：用覆盖率工具（如 JaCoCo、Cobertura、Istanbul、gcov）实际运行测试，统计真实的行/分支/条件覆盖，而非采信模型的描述；同时逐分支检查"该分支是否真的被执行"（可用分支覆盖率的真实计数），并对高风险的未覆盖分支人工补测。还可结合"语句级追踪"验证每个断言对应的代码路径确实被执行。覆盖率幻觉的根治是建立"覆盖率实证 + 人工复核"的门禁，任何声称的覆盖都必须有工具实测背书。

得分点是"覆盖率必须以实测为准，不能信模型的自我描述"。能讲出用覆盖率工具实测并逐分支核对，以及建立实证门禁，体现对问题本质的理解。

• "照着实现写断言"问题：断言基于当前实现而非行为契约
• 危害：实现中的 bug 被断言"固化为正确"，测试形同虚设
• 避免方法：基于规格/契约生成断言、变异测试验证、人工复核

"照着实现写断言"指 LLM 根据当前代码实现来生成断言，导致断言只是"复述了现有实现"，这样即使实现有 bug，断言也会通过，测试失去发现缺陷的能力。避免方法：一是基于需求/规格/契约生成断言，而不是基于实现代码——让模型从接口文档、需求描述、行为规范推断期望值，使期望独立于实现；二是用变异测试验证——对实现注入变异体，若测试杀不死变异，说明断言形同虚设，需重写；三是期望值来自独立来源（如手工构造的黄金值、参考实现、规格定义的预期结果），而非模型直接从当前函数推导；四是断言应验证"行为结果"而非"内部实现细节"，避免与实现强耦合导致重构即失效。关键原则是"断言的期望值必须独立于被测实现"，否则断言与实现同源，验证失效。

得分点是"期望值必须独立于被测实现"。能讲出基于规格生成、变异测试验证、独立黄金值三个手段，并点出"断言与实现同源则验证失效"的本质，是加分项。

• 缺陷预测（Defect Prediction）：基于历史与代码特征预测缺陷模块
• 缺陷定位（Defect Localization）：如 SBFL、基于 IR/语义的定位
• 成熟度评估：准确率有限、误报率高、作为辅助而非替代

AI 辅助 Bug 检测（缺陷预测与缺陷定位）已从研究走向工程辅助，但成熟度有限。缺陷预测：用历史缺陷数据与代码特征（复杂度、变更频率、耦合度）训练模型预测哪些模块/变更更易出错，能给出"风险排序"，但精度有限、误报率高，适合作为优先级排序（优先审查高风险变更）而非直接判定。缺陷定位：在测试失败后定位可疑代码，SBFL（基于频谱的定位，统计失败用例执行过的语句）、基于 IR 的语义定位、基于大模型的日志/堆栈分析等方法能缩小嫌疑范围，但准确率距"精确定位"仍有差距，尤其对复杂分布式系统。实际价值在于"缩小范围 + 加速人工定位"，而非全自动修复。成熟度判断：静态分析（确定性规则）较成熟，ML 预测与 LLM 定位处于"辅助"阶段，需人工复核。落地时把 AI 结果作为信号叠加到人工流程，而非黑盒决策。

得分点是"务实评估成熟度"——缺陷预测/定位是辅助排序，不是全自动判定。能讲出 SBFL 与"缩小范围而非精确定位"的定位，体现对技术边界清醒认识。

• 自愈定位器原理：元素属性变化后用启发式/相似度重定位
• 实现方式：属性向量相似度、邻居/父级上下文、截图/视觉定位
• 可靠性边界：误定位风险、相似元素混淆、需人工确认

Self-Healing（自愈）定位器的原理是：当常规定位器（如 XPath、CSS、ID）因页面元素属性变化而失败时，AI 通过启发式匹配重新定位目标元素。常见策略：基于元素属性向量（id、class、text、name、aria 标签等）计算相似度，在候选元素中找最相似者；用父级/兄弟元素上下文定位（元素层级变化）；或基于视觉/截图与 OCR 定位。修复后可自动更新定位器或给出建议。可靠性边界：核心风险是"误定位"——当页面存在多个相似元素或元素语义变化时，AI 可能把目标定位到错误元素，导致测试悄然通过但测错了对象；因此自愈通常需要设置相似度阈值（低于阈值不自动修复）、记录修复日志、并对修复结果辅以人工确认。自愈适合低风险、元素频繁微调的场景，不能替代对关键交互的定位器人工维护。落地时应把"自愈操作"显式记录并纳入变更审查，避免静默错误。

得分点是"自愈的可靠性边界——误定位风险"。能讲出相似度阈值、修复日志、人工确认这些控制手段，说明理解自愈不是"万能修复"。

• 覆盖盲区检测：需求点 vs 用例映射、缺失场景提示
• 冗余检测：相似/重复用例、低价值用例
• LLM 结合需求文档与代码分析

AI 辅助测试评审用 LLM 分析需求、代码与已有用例，找出覆盖盲区与冗余。覆盖盲区检测：把需求拆解为"需求点/行为点"，与已有用例做映射，找出没有被任何用例覆盖的需求点（如边界、异常、权限、空值），并提示补充用例的方向；也可结合代码分支分析，指出未覆盖的分支。冗余检测：对用例做语义相似度对比，找出表达不同但行为重复的用例；识别被更优用例覆盖的低价值用例，以及"断言过弱"的无效用例。LLM 评审需结合需求文档、代码结构与用例上下文，避免只凭用例文本臆断。输出通常是一份"覆盖盲区清单 + 冗余清单 + 建议"，由人工确认后合并或删除，避免 LLM 误判（如把有细微差异的用例误判为冗余）。评审应作为需求变更后的常驻检查，与覆盖率工具结合验证。

得分点是"需求点-用例映射找盲区"与"语义相似度找冗余"两个方向，并强调 LLM 输出需人工确认以防误判。能结合覆盖率工具与需求拆解，体现落地意识。

• 选择器脆弱性：依赖 id/class 易因前端改动失效
• 语义化定位：role、name、testId、可访问性标签
• 快照（Accessibility Snapshot）与 LLM 辅助定位

UI 自动化中，选择器依赖 id/class 具体值，前端重构后极易失效，造成脆弱性。Playwright 中降低脆弱性的做法：优先使用语义化定位器而非脆弱的 CSS 选择器——用 role（如 button、heading）、name（可访问名称）、testid（专用测试 ID）、placeholder、text 等稳定属性，这些属性反映元素语义而非实现细节，前端改动样式时不易破坏。Playwright 的 getByRole、getByTestId、getByLabel 即为此设计。LLM 辅助层面：可用页面的可访问性快照（Accessibility Snapshot，把页面渲染成语义化树）作为 LLM 的输入，让 LLM 基于语义角色而非具体 DOM 结构生成定位器，从而更稳健；对复杂场景可让 LLM 生成"语义目标描述"再由框架解析。同时应约定统一的 testid 命名规范（如 data-testid），使测试与实现解耦。整体原则是"用语义而非实现细节"定位元素，配合稳定的测试 ID，降低脆弱性。

得分点是"语义化定位（role/name/testid）替代脆弱 CSS"与"可访问性快照 + LLM"。能讲清稳定测试 ID 与语义角色的价值，体现对 UI 自动化脆弱性的理解。

• 套件膨胀的成因：大量重复、低价值、强耦合用例
• 防止手段：去重、价值度量、分层、门禁
• 变异测试与覆盖增益衡量价值

AI 批量生成用例容易导致"测试套件膨胀"：用例数量激增但价值不高，反而拖慢 CI、增加维护成本。防止手段：一是去重——用语义相似度合并行为重复的用例；二是价值度量——用"覆盖增益"（新增用例是否提升了未覆盖分支/需求的覆盖）与变异杀死率衡量每个用例是否带来增量价值，不增价值的用例不纳入；三是分层回归——把用例分为 smoke（高频快速）、关键回归、全量回归，不同 CI 频率运行，避免全量套件拖慢主流程；四是设置门禁——只有通过变异测试或覆盖增益要求的用例才允许并入主套件；五是定期清理——周期性通过执行时长、失败率、覆盖率贡献评估，删除低价值用例，必要时用聚类把高度相似用例合并。AI 生成的用例应视作"候选"，经价值筛选后才入库，而非直接全量加入。

得分点是"以价值（覆盖增益、变异杀死率）度量而非以数量计"，以及"分层 + 门禁 + 定期清理"。能讲清候选入库前需筛选，体现对套件治理的理解。

• ROI 的收益维度：时间节省、覆盖率提升、缺陷提前发现
• 成本维度：工具成本、审查成本、维护成本、误报成本
• 量化方法：试验对比、指标采集

评估 AI 测试工具的 ROI 需量化收益与成本。收益维度：开发/测试时间节省——用对照组（用 AI 工具 vs 不用）统计生成并验收一批用例的耗时；覆盖率提升——AI 引入后行/分支覆盖率的增量；缺陷发现能力——AI 用例在植入缺陷样本上能否发现缺陷，或在真实项目中是否提前发现回归；减少人工编写重复用例的时间。成本维度：工具订阅/算力成本、人工审查与修正 AI 用例的成本（被采纳率越低，审查成本越高）、维护成本（AI 生成的脆弱用例增加后续维护）、误报与低质量用例的返工成本。评估方法：选择一组代表性项目做 A/B 对照，记录"用例创建时间、覆盖率、缺陷发现数、维护成本"等指标，计算净收益；同时评估"采纳率"（人工直接采用而非返工的比例）来衡量 AI 用例质量。ROI 应覆盖试点期（Pilot）与规模化期，避免试点环境过于理想。最终结论是"单位时间创造的可复用用例价值 / 投入成本"。

得分点是"收益与成本双维度 + A/B 对照 + 采纳率/返工成本"。能讲出"被采纳率低则审查成本高"这一关键，说明理解 AI 工具的隐性成本。

• 真实性：贴近生产数据分布（字段分布、取值相关性）
• 多样性：覆盖边界、异常、低频但关键的值
• 评估方法：分布对比、边界覆盖检查、对抗性

LLM 生成测试数据容易"全是常见值、缺少边界"，导致测试测不到真实异常。评估真实性：把生成数据的字段分布（数值直方图、类别分布、空值率、取值范围）与生产数据分布对比（如用 KS 检验、分布重合度），检查字段间相关性是否被保留（如年龄与档位、地区与货币的耦合）。评估多样性：统计生成数据是否覆盖了边界值（最小/最大、空值、超长、特殊字符、负数、零值）、低频但关键的业务分支、以及不同组合的交叉场景；可用"取值种类覆盖率"与"边界命中率"衡量。避免全是常见值的方法：在生成提示中显式要求覆盖边界与异常档位、为每个字段设定取值范围与边界批次、用"抽样 + 指定生成"结合（先按生产分布抽样主体，再单独生成边界/异常批次）、对生成结果做多样性审计（如聚类看是否集中在少数模式）。同时注意脱敏与隐私，避免生成数据泄露真实信息。

得分点是"用分布对比验证真实性、用边界命中率验证多样性"，并给出"主体按分布抽样 + 单独生成边界批次"的策略。能讲出字段相关性与脱敏，体现细致。

• 价值：快速起草测试计划、汇总测试报告、提高一致性
• 风险：编造数据（虚构执行结果、指标）、遗漏高风险项、引用错
• 人工校验点设置：数据溯源、关键结论、指标核验

AI 辅助文档生成的价值在于快速起草测试计划、汇总测试报告、统一格式、节省时间。风险主要是：编造数据——LLM 可能虚构执行结果、指标、通过率，甚至凭空生成"测试步骤已执行"；遗漏风险——对高风险场景或业务关键点可能漏掉；以及引用错误或过度概括。控制方法的核心理念是"让 LLM 只基于真实输入生成，不臆造"：把真实数据（执行记录、覆盖率、缺陷列表）作为上下文输入，要求 LLM 只能引用给定数据、不得编造；对缺失信息明确标注"待补充"而非自行填充。人工校验点设置：数据核验（报告中每个指标都能溯源到真实执行记录）、关键结论复核（通过/失败、风险项、发布建议）、遗漏检查（对照需求清单核对是否覆盖风险项）、以及对"AI 生成的可疑点"重点审查。高风险文档（如发布报告）应有人工专家签字，LLM 只做起草与汇总。

得分点是"把编造数据风险放在首位，用'只基于真实输入生成'约束"，并给出具体人工校验点。能讲出数据溯源与高风险文档人工签字，体现风险意识。

• 选型维度：语言/框架支持、IDE 集成、生成质量、成本
• 评估方法：试点、对比、真实项目验证
• 与现有测试栈的兼容性

AI 测试工具选型需综合多个维度：技术兼容性（支持的语言、测试框架、IDE 集成、CI 集成）、生成质量（用例正确率、覆盖率、变异杀死率）、易用性（配置成本、学习曲线）、安全与合规（代码是否上传、数据隐私）、成本（订阅、算力）、以及生态与厂商实力。评估方法：先做小范围试点（Pilot），在代表性项目上对比"用工具 vs 不用"的用例创建时间、覆盖率、缺陷发现率、维护成本与采纳率；不能只看演示效果，必须在真实代码库上验证生成质量。需评估工具与现有测试栈（JUnit、pytest、Jest、Playwright 等）的兼容性，以及生成用例能否通过变异测试。同时评估长期价值：工具是否持续迭代、是否锁定厂商、切换成本。选型应产出量化对比表（指标 × 候选工具），结合团队能力与项目规模决策，避免追求"最先进"而忽视适配性。

得分点是"从技术兼容、生成质量、成本、安全到求解的完整评估维度 + 试点验证"。能讲出安全合规（代码上传）与厂商锁定，体现选型经验。

• 可信度评估维度：变异得分、缺陷发现率、覆盖率
• 变异测试（Mutation Testing）原理
• 缺陷发现率（植入缺陷验证）

评估 AI 生成测试的有效性不能只看"能运行"，需用客观手段验证其"能否发现缺陷"。变异测试（Mutation Testing）：对被测代码注入变异体（如改变运算符、删除语句、改变条件），运行测试，若测试能"杀死"变异（检测出行为变化）则说明测试有效，用变异杀死率（被杀变异数/总变异数）衡量测试对行为的敏感度。缺陷发现率：在植入已知缺陷的代码上运行 AI 测试，统计能发现缺陷的比例，衡量其对真实缺陷的检测能力。覆盖率（行/分支）作为辅助，但覆盖率不直接等于有效性（覆盖了但断言弱也发现不了 bug）。综合评估时，用变异得分与缺陷发现率作为核心，覆盖率作为补充，并配合人工审查关键断言是否与行为契约一致。可信度验证应持续进行（每当 AI 生成新用例或代码变更时），并建立"低变异得分用例需返工"的门禁。AI 生成测试的可信度应通过"对缺陷的敏感性"而非"能跑通"来证明。

得分点是"以变异杀死率与缺陷发现率验证有效性，而非看能否运行"。能讲出"覆盖了但断言弱也发现不了 bug"这一关键，说明理解测试有效性本质。

• 缺陷分类/triage 任务：标注严重级别、指派负责人、分类
• 准确率度量：与人工标注/真实归属对比
• 误判成本：错分严重级别、错指派导致延迟

缺陷分类与 triage 中，大模型负责把缺陷分到正确类别、判定严重级别、推荐负责人。度量准确率：与人工标注或真实处理结果（如最终指派的负责人、最终确认的严重级别）对比，计算精确率、召回率、F1，以及"严重级别误判率"；可用历史已处理缺陷作为标注集评估。误判成本控制：不同类型误判代价不同——把严重 bug 误判为低严重会导致延迟修复，成本高；把低严重误判为高严重浪费资源。因此需对"高危误判"单独加权评估，并设置置信度阈值（模型置信度低时转人工决策）。误判成本控制手段：人机协同（模型给出建议、人工确认关键项）、对高风险类别强制人工复核、建立漏斗（模型先粗分，人工抽查）、持续用真实处理结果反哺模型评估。triage 的准确率应分"高损误判"与"低损误判"分别统计，避免均值掩盖高危误判。

得分点是"分严重级别度量误判成本 + 置信度阈值 + 人机协同"。能讲出"高危误判单独加权"是关键，体现对 triage 成本结构的理解。

• 缺陷定位：从失败日志/堆栈定位可疑代码
• 根因分析：从现象推断根本原因
• 技术手段：堆栈分析、日志分析、频谱定位、LLM 推理

AI 辅助缺陷定位与根因分析的目标是加快"从失败到根因"的收敛。定位技术：基于堆栈与日志的 LLM 分析（从异常堆栈、错误日志推断可能出错的代码与数据流）、SBFL 频谱定位（用失败用例执行到的语句统计可疑度）、基于提交/最近变更的定位（怀疑最近改动的代码）。根因分析：LLM 结合日志、配置、调用链、时序推断根本原因，给出假设与验证方向。能力边界：对单一、信息足、可复现的缺陷效率高，对复杂分布式系统、多因叠加、需要跨服务上下文的长链路，AI 只能给出候选假设，准确率有限且可能"自信地给出错误根因"。因此落地时 AI 输出应作为"候选根因 + 证据"，而非最终结论，需人工验证（如复现、看日志）。可信度控制：要求 AI 输出根因时附带证据链，对无证据的结论标记为"推测"，并做置信度分级。价值在于缩小排查范围、加速定位，而非替代工程师。

得分点是"把 AI 定位/根因当作候选假设而非结论，要求附带证据链"。能讲出堆栈分析、SBFL、最近变更等技术的适用场景，体现操作理解。

• AI 测试质量保障：人工复核的必要性
• 门禁设计：变异得分、覆盖率、审查通过率
• 分层复核：高价值测试人工、低价值抽样

AI 生成测试需要质量保障，否则低质量用例会混入主套件。核心是"人工复核 + 门禁"。人工复核：AI 生成的用例应视为"候选"，需人工审查其断言是否符合需求、是否与实现过耦合、是否覆盖真实场景；按风险分层——高价值/高风险测试（核心业务、支付、安全）强制人工复核，低风险测试可抽样复核。门禁设计：AI 用例入库前需通过若干门槛——变异杀死率达到阈值、覆盖率增量符合要求、代码审查通过、无已知反模式（如断言恒真、与实现同源）。门禁可量化（如变异得分 < 60% 的用例不通过）并自动执行，降低人工负担。此外建立"AI 用例质量指标"持续监控（入库后缺陷发现率、假阳性率、后期维护成本），把问题反馈给生成策略迭代。人工复核与门禁结合，既控制质量又不降低效率。

得分点是"AI 用例作为候选 + 分层人工复核 + 可量化门禁 + 持续反馈"。能讲出"变异得分门禁"与"入库后质量监控"，体现完整的质量闭环。

• 提示设计要素：角色、任务、约束、输出格式
• 上下文输入：代码、需求、测试规范、已有用例
• 提供足够上下文提升生成质量

AI 测试的提示设计直接影响生成质量。提示要素：明确角色（"你是资深测试工程师"）、任务（"为以下函数生成单元测试"）、约束（"覆盖边界与异常"、"断言必须基于行为契约"）、输出格式（"用 JUnit 返回 JSON 结构"）。上下文输入是提升质量的关键：仅给函数名生成的用例质量差，应提供被测代码、相关类型/依赖、需求描述、调用约定、已有测试风格与命名规范，让模型在充分上下文下生成。上下文粒度要控制：过多无关代码会稀释注意力，应用 RAG 检索相关内容（只给被测代码与相关依赖）。输出格式应强调可解析（结构化 JSON、指定语言/框架），并约束"不编造 API"（只用给定上下文中的符号）。提示应区分"生成场景"与"生成断言"的不同侧重，并版本化便于回归。提示设计要做到"给足背景、明确约束、限定格式"。

得分点是"提示要素（角色/任务/约束/格式）+ 充分上下文"以及"RAG 控制上下文粒度"。能讲出"只给被测代码与相关依赖避免稀释"，说明理解 LLM 上下文窗口局限。

• 知识库内容：缺陷模式、历史用例、环境手册、测试规范
• 构建流程：知识抽取、切分、向量化、索引
• RAG 检索辅助用例设计与问题定位

RAG 赋能的测试知识库把测试领域知识组织成可检索资产，供 LLM 在生成用例或定位问题时引用。知识来源：历史缺陷模式（某类 bug 的复现条件与修复）、历史用例（已验收的用例设计与断言）、环境手册（部署步骤、环境配置、常见坑）、测试规范与业务规则。构建流程：知识抽取与清洗（去重、去噪、标注来源）、切分（按文档/模块切成语义块）、向量化并建立索引（可加元数据如类型、系统、关键词以便过滤）、为每条知识保留来源引用以便溯源。使用：设计用例时，LLM 检索相关缺陷模式与历史用例，生成更贴合业务与历史的用例；定位问题时，检索相关历史案例与手册辅助根因分析。质量保障：知识库需定期更新（新增缺陷沉淀、过时手册清理）、加"来源引用"防幻觉、对检索相关性做评估（如检索命中率）。知识库的价值在于把组织经验沉淀为可复用资产，提升 AI 辅助测试的领域准确性。

得分点是"知识的来源与构建流程 + 检索辅助 + 来源引用防幻觉"。能讲出"缺陷模式沉淀 + 元数据过滤 + 定期更新"，体现知识库工程化。