AI测试用例审核员面试题库（含必背题目）

AI测试用例审核员面试题库第1页共1页AI测试用例审核员面试题库解决「面AI测试用例审核员问不出真本事、评分全靠感觉」：48题覆盖基础认知·实操应用·项目追问·风险避坑·开放思辨，每题附参考答案与追问链，含评分表与红旗信号使用说明一、题库定位本题库面向AI测试用例审核员（人机协同改造岗）的招聘面试，覆盖48题，适用于L1～L3三个层级。核心考察三件事：能不能判断一条用例能不能测出问题、能不能说清为什么、能不能把判断变成可执行的处置。题库不考察测试理论的名词解释，所有基础题都要求结合具体例子回答。凡只能背定义的候选人，在本岗无法胜任，因为审核的日常动作是"看一条具体用例，下一个具体结论"。使用建议：L1取基础认知8题+实操应用4题+风险避坑4题；L2取基础6题+实操6题+项目经验4题+风险4题；L3加开放思辨4题，并加深项目经验题的追问层数。二、题目结构与建议用时部分题量建议用时考察目的适用层级一、基础认知题1220～25分钟判断是否真的理解覆盖、断言、边界、粒度L1～L3二、实操应用题1035～45分钟现场给材料，看能否落地判断L1～L3三、项目经验题825～30分钟追问到细节，验证经历真实性L2～L3四、风险与避坑题1020～25分钟看边界感与压力下的处置L1～L3五、开放思辨题815～20分钟看判断力上限与岗位认知L3合计48120～150分钟建议拆为两轮，单轮不超过75分钟—三、评分锚点（1～5分）分值表现特征判定说明5能给出具体判定标准，主动指出反例与边界，能说出"这种情况我会转澄清"可直接承担独立审核4判断正确，理由基本到位，个别边界需提示可在1个月内独立3判断方向对，但理由停留在原则层面，给不出具体改法需带教2～3个月2判断时对时错，依赖"感觉"和"经验上一般"不宜独立审核1认为"格式规范即合格"，或无法说出任何判定标准不匹配本岗四、面试官注意事项●必须带真实材料。实操题若用编造的用例，候选人会当成考题去猜标准答案；用真实项目里被驳回过的用例，才能看出他的判断是否与生产实际一致。●不接受"看情况"。本岗的核心是下结论，回答里出现三次以上"看情况"且不给判断条件，按2分处理。●追问要追到动作。候选人说"我会要求补反向用例"，追问"补几条、补哪几类、依据是什么"，答不出说明只是知道概念。●区分设计与审核。会写用例的人不一定能审。判断方法是给一条"看起来很好但断言模糊"的用例，看他第一眼落在哪。●记录原话。评分表里要写候选人的原话片段，不要只写"较好""一般"，否则复核时无法校准。一、基础认知题（12题）Q1.你们团队的"需求覆盖率"是怎么算的？分子分母分别是什么？参考答案要点：1.分母是"可验证需求条目数"，不是需求文档页数，也不是功能点数。条目要拆到能写出"在哪看、看什么、等于什么"的粒度。2.分子是"至少有一条用例覆盖的条目数"，覆盖的判定标准是该用例的断言能验证该条目的核心行为，不是标题里出现了该功能名。3.常见错误口径有两种：一条用例挂多个需求ID抬高分子；把需求拆得过细（把"按钮置灰"和"接口拒绝"拆成两条）抬高分母再逐条覆盖。4.优秀回答会补充：P0条目单独统计，要求100%，整体覆盖率才有意义。追问：如果一条用例同时覆盖三个条目，你算覆盖三个还是一个？Q2.什么样的预期结果算"可判定"？请用一句话给出判定标准。参考答案要点：1.三要素：在哪看（界面、接口响应、数据库表、日志）、看什么（字段、条数、状态、金额、耗时）、等于什么（具体值或明确规则）。2.反例：显示正确、操作成功、提示友好、数据一致。这些词没有比对基准，任何人执行都能得出不同结论。3.可判定的极端标准：这条断言能不能被自动化脚本直接写成assert。能，就可判定。4.优秀回答会指出：业务成功不等于请求成功，接口返回200但code=5001是常见陷阱。追问：如果需求本身没给具体值，你怎么写断言？Q3.边界值应该从哪里来？如果来源缺失你怎么办？参考答案要点：1.来源优先级：字段字典（长度、精度、枚举、上下限）优于接口文档，优于数据库表结构，优于需求文档描述。2.每个有数值约束的字段取四点：下界减一、下界、上界、上界加一；字符串另加0长度、1字符、上限、上限加一、特殊字符（中文、emoji、单引号、换行）。3.来源缺失时的正确动作是标"约束缺失"退回需求方，而不是凭经验设一个值。凭经验设的值一旦与实现不符，用例本身就是错的。4.加分点：会提到金额还要看精度位与舍入规则，时间还要看时区与跨日边界。追问：需求写"金额不能太大"，你怎么处理？Q4.正向用例和反向用例的配比，你按什么定？参考答案要点：1.按需求类型定，不按个人习惯。查询类约2:3，单表增删改约3:5，涉及金额约4:8，状态流转每条合法流转1条、每对非法流转1条，审批类约3:6。2.依据是失效概率分布：输入校验、权限、状态机是缺陷高发区，正向路径通常一次就通。3.反向必须覆盖四类：非法输入、越权、必填缺失、类型或格式错误。涉及金额还要加负数、零、精度超限、余额不足、重复扣款、并发扣款。4.不合格回答："看项目情况""一般正反各一半"。追问：如果开发说所有入口都做了校验，还需要这么多反向用例吗？Q5.配对覆盖（两两组合）什么时候能用，什么时候不能用？参考答案要点：1.能用：一般业务功能、因子多但相互独立、缺陷主要由单因子或两因子交互引发的场景。2.不能用：涉及金额、库存、额度、权限的组合。这类场景三因子同时生效才会暴露问题（如"跨租户+已支付+批量"才出现的越权退款）。3.使用时要留痕：在组合表上写明总组合数、压缩后数量、未覆盖的组合及理由。核心不是"压到多少"，是"知道漏了什么"。4.加分点：会提到关键值组合作为折中，即对每个因子取最可能出问题的值再交叉。追问：四因子、每因子5个值，全组合625条，你怎么说服经理接受配对覆盖的25条？Q6.一条用例应该验证几个点？怎么判断该不该拆？参考答案要点：1.一条用例一个判定，最多2条断言且必须同源——同一动作的直接结果。2.拆分信号：断言跨系统（订单库+短信表+积分表）、断言之间无因果关系、失败时无法定位是哪一环出错。3.拆分不减少验证点，只是让失败可定位。汇报工作量时用"验证点数"而非"用例条数"，否则拆分看起来像注水。4.不合格回答："能拆就拆"或"一条用例覆盖越多越高效"。追问：拆完之后用例数翻三倍，你怎么向经理解释这不是在凑数？Q7.前置条件为什么必须"可构造"？不可构造的前置怎么处理？参考答案要点：1.前置不可构造，用例就无法被执行，等于没写。执行方遇到跑不通的用例，通常会跳过，跳过就等于漏测。2.判定标准：另一个人在测试环境30分钟内能复现出同样的前置状态。3.必须写四要素：账号与角色、数据所处状态、系统配置项与取值、依赖服务的桩状态。4.不可构造时标"阻塞"，给替代方案（如用桩服务模拟第三方、用脚本批量造数、降级为抽检），不能写"已登录""系统正常"糊过去。追问：需要生产数据才能复现的问题，你怎么设计用例？Q8.幂等和并发，用例具体怎么写？参考答案要点：1.幂等：同一请求提交两次，断言"业务只生效一次"——订单表只有1条记录、库存只减1、流水只有1笔，第二次返回明确的重复提示或返回首次结果。2.并发：明确并发数、并发方式（同一账号多线程、多账号同时操作）、断言最终状态（库存为0、成功订单数等于库存数、无超卖、无负库存）。3.关键点：必须查库断言，不能只看接口返回，因为并发问题往往接口都返回成功。4.加分点：会提到分布式场景要看最终一致的时间窗，断言要写"≤N秒内达到某状态"。追问：100并发下单，成功50单、库存剩0，这个结果算通过吗？依据是什么？Q9.你怎么判断两条用例是冗余的？参考答案要点：1.不比标题字面，比"操作+断言"是否等价：同样的前置、同样的动作路径、验证同一个判定，即为冗余。2.三步：先按关联需求聚类，再按断言比对（看验证的字段与预期值），最后人工确认边界差异（数据不同但验证点相同的也算冗余）。3.冗余不等于可删。同一验证点有两条时，保留断言更严、前置更完整的那条；两条各有边界差异的，合并为参数化用例。4.参考线：单批次冗余率不超过10%，跨批次重复入库应为0。追问：一条用99元测、一条用100元测，验证点都是"支付成功"，算冗余吗？Q10.回归集应该多大？怎么控制它不无限膨胀？参考答案要点：1.参考线：回归集占用例库的20%～35%。超过40%通常意味着"只进不出"。2.入集标准：P0全进，P1按业务重要性选入，P2/P3进抽检池。3.出集机制：连续两个版本未发现缺陷且需求未变更的降级；对应功能已下线或重构的移出；断言模糊的先改写再决定去留，不要直接删。4.加分点：会提到回归集规模要与执行工时挂钩，跑不完的回归集等于没有回归集。追问：删掉一条用例，怎么保证不是把覆盖点一起删了？Q11.从机制上看，为什么大模型生成的用例普遍只覆盖正向路径？参考答案要点：1.训练语料里"标准业务流程"的描述远多于"异常与越权"，模型学到的是主流写法。2.生成时缺少负面约束：提示里若只说"根据需求生成用例"，模型会按"需求写了什么就测什么"来做，而需求文档本身很少写异常分支。3.模型无法判断业务风险分布，不知道这个系统里"权限"和"金额"是高风险区，因此不会主动加密。4.有效对策不是"让它多想"，而是在提示里加硬约束（每条需求至少1条非法输入、1条越权、1条必填缺失），并把角色清单、字段字典放进输入。追问：加了约束之后仍然漏，你会怀疑是提示问题还是输入问题？怎么区分？Q12."缺陷发现率"这个指标，为什么可能被用例数量稀释？参考答案要点：1.口径是"确认缺陷数÷执行用例数"。分母被注水（大量重复、断言模糊的用例）时，比值下降，看起来像测试质量变差，实际是分母虚高。2.反向操作也存在：把已知缺陷写成用例，执行时"发现"，分子虚高。3.纠偏：分母只统计"有效执行"的用例（排除跳过、阻塞、断言无法判定的）；分子只统计首次发现时间晚于用例创建时间的缺陷。4.加分点：会提出用"每千条有效用例发现缺陷数"替代原始比值，并配合漏测率一起看。追问：如果团队指标突然从1.8%掉到0.6%，你先查什么？二、实操应用题（10题）Q13.这里有300字需求（现场提供），请25分钟内写出8条用例，至少3条反向。参考答案要点：1.先花3分钟拆条目，把需求切成可验证点，写在纸上再动笔——不拆直接写的人，8条里通常有5条重复。2.正向覆盖主流程与至少1个分支；反向必须含非法输入、越权、必填缺失各1条。3.每条写全四要素：关联条目、前置（账号角色与数据状态）、步骤（原子动作）、断言（三要素）。4.评分看四点：条目拆分是否合理、反向是否真的反向（不是"输入错误数据"这种笼统写法）、断言是否可比较、前置是否可构造。追问：你这8条里，哪一条最可能在上线后拦住问题？为什么？Q14.这条用例的预期结果写的是"订单创建成功，库存扣减，用户收到通知"。请改写。参考答案要点：1.先判粒度：这是3个验证点、跨3个存储，必须拆成3条。2.拆后断言：订单表新增1条，order_no等于返回值，status=10，amount=99.00；商品表stock由100变99；通知表新增1条，模板ID匹配，接收人为脱敏尾号。3.补观测方式：分别写明用接口查、用SQL查、用后台查。4.不合格回答：只把"成功"改成"返回200"——这仍然是请求层断言，没验证业务结果。追问：如果这个系统有消息队列，通知是异步的，断言怎么写？Q15.给一条含5个断言的用例，现场拆分并说明拆分依据。参考答案要点：1.依据是"同源原则"：同一动作的直接结果可保留，跨系统、跨模块、跨存储的结果必须拆。2.拆完检查：拆分前验证点数等于拆分后条数，少了说明漏拆。3.保留父编号，子用例加后缀，保证与历史缺陷的关联不断链。4.加分点：会指出拆分后应共享同一份数据构造，避免每条都造一遍导致执行时间翻倍。追问：拆成5条后，其中1条失败，你怎么判断是产品缺陷还是前面步骤没执行成功？Q16.需求写"客服可以代客户取消订单"，请设计越权相关用例。参考答案要点：1.先建权限矩阵：角色（买家、卖家、客服、财务）×操作（查看、取消、审批、导出），逐格确认允许与禁止。2.四类必测越权：买家直接调接口取消他人订单；客服取消已完成订单（超出可操作状态）；客服无审批取消超限额订单；已冻结或离职的客服账号执行取消。3.还要测"有权但越界"：客服只能取消本店铺订单，测跨店铺。4.每条断言都要落到数据状态：订单status未变、操作日志记录拒绝原因、返回明确错误码。追问：前端把按钮置灰了，还需要测接口层越权吗？Q17.金额字段，你会设计哪些用例？参考答案要点：1.边界：0、0.01、上限、上限加一、负数、超长小数（如0.001）。2.精度：两位小数舍入规则（0.005是进位还是拒绝）、乘法与折扣后的尾差处理、分摊到多条明细时总额是否等于原额。3.业务：余额不足、超单笔限额、超日累计限额、退款金额大于原单、部分退款后再次退款。4.并发与幂等：重复提交只扣一次、并发扣款不透支。5.断言必须查库：账户余额、流水条数、订单金额三者一致，且精度为两位。追问：0.005这个值，需求没写舍入规则，你的用例预期结果怎么写？Q18.需要10万条订单数据做列表与导出测试，你怎么造、怎么清？参考答案要点：1.造：写批量插入脚本，明确字段取值分布（状态按比例、时间跨度覆盖12个月、金额分档），执行时间要实测并写进前置条件（如"约4分钟"）。2.校验：造完先count确认条数，再抽3条核对字段，避免脚本字段错位。3.清：truncate专用临时表或按batch_id删除，写明清理语句；不能用生产库数据。4.隔离：大数据量用例单独标记，放在批次末尾执行，避免影响其他用例的查询结果。5.加分点：会提到导出测试还要看内存与超时，10万条是否异步、是否有分页上限。追问：脚本造的数据时间字段都是同一秒，会掩盖什么问题？Q19.给一个订单状态机（待支付、已支付、已发货、已完成、已关闭），你怎么设计用例？参考答案要点：1.合法流转每条1条：待支付→已支付→已发货→已完成；待支付→已关闭；已支付→已关闭（退款）。2.非法流转每对1条：已发货→待支付、已完成→已支付、已关闭→已支付，断言状态不变且返回明确错误码。3.并发流转：发货与取消同时触发，断言最终只有一方生效，另一方收到明确失败。4.越权流转：无权限角色执行流转、跨店铺流转。5.状态与副作用绑定：每次流转断言对应副作用（库存、流水、通知）同步发生，不能只看status字段。追问：状态机图没有，只有代码，你怎么补齐这张图？Q20.你驳回了一条用例，作者坚持认为没问题，你怎么处理？参考答案要点：1.先把争论落到可验证的点上：不是"我觉得不行"，而是"这条断言写的是显示正确，请指出在哪看、看什么、等于什么"。2.给对照：拿一条同批次合格的用例并排看，差异一目了然，比讲原则有效。3.给台阶：如果是断言写法问题，直接给改写建议；如果是需求不明，一起转澄清，把矛头从人转向需求。4.有争议升级：提交测试组长按判定基准裁定，裁定结果回写进规则，避免下次再争。5.底线：不因为对方坚持就改成"通过"，但也不在公开场合否定对方能力。追问：如果组长裁定支持作者，你怎么做？Q21.明天发版，400条用例只审了100条，经理要求全部入库。你怎么做？参考答案要点：1.不接受"全部标已审"，这是记录失真，不是进度妥协。2.给方案：已审的100条正常入库；剩余300条按P0优先续审，通常P0占20%，2小时内能覆盖；其余标"草稿"不入回归集。3.给风险说明：书面列出未审部分的覆盖缺口与可能影响，让经理在知情下决策。4.给后续：约定补审时间点，并在下个版本把审核前置到生成当天，避免再次堆积。追问：如果经理说"出了事我负责"，你还坚持吗？怎么坚持？Q22.一个8000条的用例库，回归要跑5天，你怎么瘦身？参考答案要点：1.先分类不动刀：按关联需求聚类，按断言质量分三档（可判定、需改写、无法判定）。2.先改写再删除：大量低质用例其实是断言没写好，直接删会丢覆盖点。先改写300条最关键的。3.再去重：按"操作+断言"比对，同验证点保留最严的一条，保留编号映射。4.再分级：P0/P1进回归集（目标25%），其余进抽检池；连续两版本零缺陷的降级。5.验证效果：回归工时下降、同期缺陷发现数不降。两个数同时成立才算成功。追问：瘦身后第一个版本就漏了一个线上缺陷，你怎么解释？三、项目经验题（8题）Q23.请讲一次你从零搭建用例评审流程的经历。参考答案要点：1.背景要具体：团队规模、用例库条数、原来怎么审（或无审核）、最大的问题是什么（漏测、返工、还是执行跑不通）。2.动作要落到机制：定了什么判定标准、用什么清单、谁有驳回权、争议怎么裁定、指标怎么统计。3.结果要有数：一次可用率、覆盖率、返工率、缺陷发现率的前后对比，至少两个数。4.反思要真实：说清哪条规则落地失败、为什么失败、后来怎么改。追问链：●追问1：这套标准推行时，最大的阻力来自谁？●追问2：你怎么让资深测试接受"按清单审"而不是"凭经验审"？●追问3：清单里哪一条被证明没用？你怎么发现的？●追问4：如果换一个业务域，这套标准要改哪几处？●追问5：这套东西现在还在用吗？被改过几次？评分要点：5分要求能说清"规则的失效边界"；3分只能描述流程，说不出阻力与调整；1分为纯流程背诵。红旗：全程用"我们"不用"我"；说不出任何数字；把流程说成一次成功、零阻力。Q24.讲一次线上漏测，你做的用例级复盘。参考答案要点：1.必须区分三类归因：覆盖缺失（该场景无用例）、断言失效（有用例但断言是"正常"）、执行跳过（有用例但没跑或被标已知问题）。2.证据要具体：漏测场景对应覆盖矩阵的哪一格、对应用例编号、断言原文。3.改进动作要与归因匹配：覆盖缺失补用例并回查矩阵为何漏格；断言失效改写并统计同类占比；执行跳过查分级与跳过审批。4.验证改进有效：下一版本同类场景是否有用例、断言是否可判定、是否被执行。追问链：●追问1：这个场景当时为什么没写用例？是没想到还是需求没写？●追问2：同类场景在库里还有多少条？你怎么快速找出来？●追问3：如果归因是断言失效，你们库里模糊断言占比多少？怎么统计的？●追问4：改进之后，同类缺陷还发生过吗？评分要点：5分能明确归到一类并给出可验证的改进；3分三类混着说；1分只说"加强了测试"。红旗：把责任全推给开发或需求方；说不出用例编号；改进动作是"提高重视程度"。Q25.讲一次你引入AI生成用例的落地过程。参考答案要点：1.输入侧做了什么：字段字典、接口文档、角色清单、历史用例与缺陷单怎么打包。2.提示侧做了什么：输出格式约定、反向用例硬约束、数据必须具体值。3.审核侧做了什么：首轮规则筛查、逐条判定、驳回分类统计。4.数据：生成条数、一次可用率、审核人时、入库条数、缺陷发现率变化。5.反思：哪类缺陷是改模板解决的，哪类是改输入解决的，哪类至今没解决。追问链：●追问1：第一批生成的一次可用率是多少？现在多少？●追问2：可用率提升主要来自模板还是输入？●追问3：有没有出现过"生成的用例把现有bug写成预期"的情况？怎么发现的？●追问4：工具换了模型版本后，质量有波动吗？你怎么监控？评分要点：5分能区分"输入问题"与"模板问题"并给出证据；3分只说"用了AI，效率提升"；1分说不出可用率。红旗：把"生成条数"当成果；说不出审核环节；声称可用率90%以上却给不出统计口径。Q26.讲一次大规模用例去重的经历。参考答案要点：1.规模与手段：多少条、按什么维度聚类、用什么比对（标题相似度只是初筛，最终按"操作+断言"人工确认）。2.判定难点：数据不同但验证点相同的算冗余；前置不同导致覆盖不同的不算。3.处置：合并保留最严的一条，保留编号映射，避免历史缺陷关联断链。4.结果：条数下降比例、覆盖点是否减少、回归工时变化。追问链：●追问1：你怎么证明合并后覆盖点没减少？●追问2：合并后原用例编号对应的历史缺陷怎么办？●追问3：有没有合并错的？怎么发现的？●追问4：如果让你再做一次，哪一步会改？评分要点：5分能说清"覆盖点守恒"的验证方法；3分只说按标题去重；1分说不出合并规则。红旗：直接批量删除；无法回答覆盖点是否减少；把去重等同于删用例。Q27.讲一次你判定"需求不可测"并推动修改的经历。参考答案要点：1.不可测的具体形态：缺阈值、缺时点、缺状态定义、缺异常约定、缺角色说明。2.推动方式：不是笼统说"需求不清楚"，而是列出"这条需求缺什么、导致哪几条用例写不出预期、影响哪个测试节点"。3.结果：需求补充了什么、用例补了几条、是否影响了排期。4.反思：如果需求方始终不补，你的兜底方案是什么（标阻塞、列入风险、按最保守假设并注明）。追问链：●追问1：需求方当时的反应是什么？●追问2：你怎么说服他这不是"测试挑刺"？●追问3：如果他不改，你敢不敢让这个需求带着风险上线？●追问4：这件事之后，需求模板有变化吗？评分要点：5分能把"不可测"翻译成需求方听得懂的业务问题；3分只会说"需求不清晰"；1分选择自行脑补。红旗：自行假设一个业务规则并据此写用例；把问题归为"需求方不配合"。Q28.讲一次你和自动化团队协作，把手工用例转成自动化用例的经历。参考答案要点：1.可自动化性评审：步骤是否原子、断言是否可编程、数据是否可参数化、前置是否可脚本化。2.改造动作：拆步骤、把"观察页面"改成接口或数据库断言、把硬编码数据改成参数集。3.分工：审核方保证用例可编程，自动化方负责脚本与稳定性；返工责任按"用例不可编程"与"脚本实现问题"区分。4.结果：自动化覆盖率、脚本稳定率、维护成本。追问链：●追问1：哪些用例你判定为"只能手工"？依据是什么？●追问2：自动化方退回你的用例，最常见的原因是什么？●追问3：你怎么改自己的写法来减少退回？●追问4：脚本不稳定时，怎么区分是用例问题还是脚本问题？评分要点：5分能说清"可编程断言"的具体写法；3分只知道要"写清楚一点"；1分认为自动化是自动化团队的事。红旗：把所有用例都判为可自动化；说不出退回原因；把不稳定归为环境问题不再深究。Q29.讲一次你在多个团队之间统一用例判定尺度的经历。参考答案要点：1.问题形态：同一种写法A组能过、B组要改，作者认为审核是玄学。2.手段：判定基准文档+样例库（合格与不合格各20条）+双人独立判定校准（一致率低于80%就重新对齐）。3.机制：争议升级路径、裁定结果回写规则、季度复核尺度漂移。4.结果：一致率、返工率、跨组评审的争议数量变化。追问链：●追问1：一致率怎么测的？样本怎么取？●追问2：两个组的标准冲突时，以谁为准？●追问3：尺度会不会随时间漂移？怎么发现？●追问4：新人多久能达到85%一致率？评分要点：5分能给出可执行的校准机制；3分只说"开了会对齐"；1分认为尺度靠个人经验。红旗：说不出一致率的测法；用"大家商量着来"作为机制。Q30.讲一次你的审核结论被推翻的经历。参考答案要点：1.事情经过：驳回了什么、依据是什么、被谁以什么理由推翻。2.复盘：是判定标准有漏洞、还是自己判断错了、还是流程上不该由你定。3.动作：标准补了哪一条、样例库加了哪一条、后续同类问题怎么处理。4.态度：能承认判错，也能说清"如果重来会怎么做"。追问链：●追问1：当时你依据的是哪条标准？●追问2：被推翻后，这条标准改了吗？●追问3：如果现在再遇到同类用例，你的结论会不同吗？●追问4：这件事影响你和对方后续的协作吗？评分要点：5分能区分"我判错"与"标准缺失"两种情况；3分只描述委屈；1分否认有任何问题。红旗：把责任全推给对方或流程；说不出标准是否修订；表现出强烈对抗情绪。四、风险与避坑题（10题）Q31.开发说"这个入口我已经校验了，不用测反向"。你怎么回应？参考答案要点：1.校验的是他以为的入口。实际入口通常有多个：页面、接口直调、批量导入、历史数据迁移、定时任务。2.反向用例测的不是"他有没有写校验"，是"所有入口是否都挡住了"。这是一致性问题，不是能力问题。3.折中方案：如果他坚持，可先测接口直调与批量导入两个高风险入口，用结果说话。4.底线：涉及金额与权限的反向用例不能免。追问：如果他拿出代码给你看，确实每个入口都校验了，你还测吗？Q32.需求方一直不回复澄清，用例卡在那里，你怎么推进？参考答案要点：1.不自行假设业务规则。假设一旦错，用例全错，且上线后责任无法界定。2.升级路径：书面列出"缺什么、影响哪几条用例、影响哪个测试节点、最晚回复时间"，抄送测试经理与项目经理。3.兜底：该条目用例标"阻塞"，在测试报告中列为风险项，不写预期结果。4.变通：若业务上可从既有系统或历史数据推断，也要写明"按现有系统行为假设，待确认"，并标注风险。追问：如果这个需求是本期核心功能，不澄清就没法测，你敢不敢建议延期？Q33.领导要求"这批用例全部通过，别卡进度"。你怎么做？参考答案要点：1.区分"入库"与"标已审"。可以入库但标"草稿"，不能标"已审"，后者是记录失真。2.给优先级方案：先审P0（通常20%），其余按风险排序续审。3.给书面风险说明：未审部分的覆盖缺口、可能漏测的场景，让决策者在知情下决定。4.留痕：把沟通记录、风险说明存档，不是为甩锅，是为后续复盘有依据。追问：领导说"我签字，责任我担"，你怎么留这个痕？Q34.接手一个两万条的用例库，从哪下手？参考答案要点：1.先做画像：按模块分布、按优先级分布、按断言质量抽样（抽200条看模糊断言占比）、按最近执行记录看僵尸用例。2.三个优先动作：模糊断言改写（影响执行有效性）、连续零缺陷用例出集（影响执行工时）、跨批次重复合并（影响维护成本）。3.不要一上来大改结构或换工具，会引发执行团队反弹。4.定基线：先测一次全量回归的实际工时与缺陷发现数，作为改进对照。追问：如果只有两周时间，你只做哪一件事？Q35.执行方反馈"你的用例跑不通"，你怎么处理？参考答案要点：1.先分清三类：前置不可构造（用例问题）、环境或数据问题（环境问题）、步骤描述有歧义（用例问题）。2.用例问题的，改写并回写规则；环境问题的，补环境说明或数据脚本。3.跑不通的用例本身是资产缺陷，要记录、统计比例，不能直接删。4.机制：建立"执行反馈单"，把跑不通的原因分类统计，季度看哪类最多。追问：如果同一个执行人反复反馈跑不通，但别人能跑通，你怎么查？Q36.你在用例里发现直接引用了生产客户的手机号和身份证，怎么办？参考答案要点：1.立即处置：该批次停止入库，定位来源（谁贴的、从哪导的、涉及多少条）。2.清理：替换为虚构合规值，删除含真实信息的截图与报文附件。3.上报：按公司数据合规流程上报，评估是否构成个人信息泄露事件。4.机制：把"无生产数据"加入首轮筛查规则，加入入库强制检查项。追问：如果这批用例已经入库三个月了，你怎么排查影响范围？Q37.团队成员把未公开的需求文档贴进公网大模型工具生成用例，你怎么处理？参考答案要点：1.先止损：停止使用，确认贴了什么内容、是否含客户信息或商业机密。2.上报：走信息安全或合规流程，评估是否需要对外通报。3.替代方案：改用企业版或私有化部署工具，或对需求做脱敏摘要后再输入。4.机制：在团队内明确"哪些内容不能出内网"，并写入工具使用规范。追问：如果团队只有公网工具可用，你怎么在合规前提下继续用AI生成？Q38.一条用例昨天能过、今天过不了，环境没变，你怎么排查？参考答案要点：1.先查数据：是否被前一条用例污染、是否依赖了共享数据、是否被其他批次改动。2.再查依赖：第三方桩是否变更、配置是否被人改、时间相关逻辑是否跨日。3.再查用例本身：是否隐含依赖执行顺序、是否用了当前时间做断言。4.结论落到用例质量：不能独立执行的用例是缺陷，要改成自带数据构造与清理。追问：如果查出来是用例依赖执行顺序，你怎么批量找出同类问题？Q39.覆盖率报表显示98%，但线上还是漏了。可能的原因有哪些？参考答案要点：1.口径问题：一条用例挂多个需求ID；需求拆得过细；覆盖率按"条目"算但条目本身没覆盖关键分支。2.质量问题：有覆盖但断言模糊，执行等于走过场；覆盖的是正向，反向与组合缺失。3.组合问题：单因子都覆盖了，三因子交叉没覆盖。4.执行问题：用例存在但被跳过、被标已知问题、回归集里没有它。5.排查方法：拿漏测场景回查矩阵对应格子，看是"空"还是"有但断言无效"。追问：怎么设计一个指标，能同时反映"覆盖了"和"覆盖有效"？Q40.生成工具升级了模型版本，用例质量突然下降，你怎么定位？参考答案要点：1.控制变量：同一份输入、同一套模板，分别用新旧版本各生成一批，比对同一批需求的产出。2.看分布：八类缺陷的占比变化（正向偏多、断言变模糊、格式变化导致解析失败）。3.分输入与模板：换一份最简单、约束最全的需求试，若仍差，说明是模型能力问题；若正常，说明是复杂输入的解析问题。4.处置：锁定版本、建立版本变更的回归验证（每次升级跑固定20条基准需求）。追问：如果新版本整体更好但某类场景变差，你用哪个？五、开放思辨题（8题）Q41.模型能力越来越强，这个岗位三年后还需要吗？评分要点：●高分：承认"逐条改写"的工作量会下降，但指出三件事仍需要人——判定标准由谁定、风险分布由谁判断、出问题谁签字。岗位会从"审条目"转向"定规则、做抽检、管资产"。●中分：只说"需要，因为AI不可靠"，给不出岗位形态的变化。●低分：认为岗位会消失，或认为完全不受影响。●关键区分：是否理解"审核的本质是把关资产质量，不是改文字"。Q42.管理层只看"用例条数"，你怎么解释质量比数量重要？评分要点：●高分：用可比的数字说话——回归执行工时、单位工时发现的缺陷数、返工率。举具体例子：8000条跑5天发现42个缺陷，瘦身到2100条跑1.5天发现51个。●中分：能讲道理但给不出对照数据。●低分：抱怨管理层不懂技术。●关键区分：是否能把质量问题翻译成成本与工时。Q43.应该追求100%需求覆盖吗？评分要点：●高分：不追求绝对100%，但要求P0100%；覆盖的成本随边际递减，且"覆盖"不等于"有效覆盖"；应把资源放在组合与断言质量上。●中分：说"尽量高"，但说不出取舍依据。●低分：认为100%必须达到，或认为覆盖率不重要。●关键区分：是否理解覆盖率的边际成本与"有效覆盖"的差别。Q44.审核员应该有权直接改用例，还是只提意见？评分要点：●高分：有权改，但改完必须由原作者确认。理由：只提意见会导致同一问题反复出现；直接改而不确认会导致责任不清、作者不认。●中分：选一边，能说出理由但看不到风险。●低分：认为审核员就该全权修改，或认为只能提意见不能动。●关键区分：是否意识到"改"与"认"