软件测试面试真题,21道高频硬核题

软件测试 · 面试真题

📦 8 Parts + Conclusion

👉 滑动

先点一个容易被忽略的事：这 5 个模块里，只有 1 个是直接考 AI 的。

接口、并发、用例设计占了接近一半。也就是说，一个标着「AI 测试」的岗位，前面大半时间问的还是传统功夫。原因不复杂——AI 测试里那些「怎么定义好的输出」「怎么拆归因」，本质还是测试思维的延伸。思维不牢，后面的题会连着塌。

下面按模块走。

1、给你一条优惠券规则：「仅限新用户且订单满 100 元可用」，你怎么设计用例？

在考什么：多条件组合还能不能理得清。

骨架：用判定表。先列条件桩——是否新用户（是/否）、金额是否满 100（是/否）；再列动作桩——可用/不可用。条件两两组合共 4 种，正好 4 条用例，每种组合的结果都要明确。判定表的价值是逼你把「我想当然的规则」写成「一张必须填满的表」，填不满的地方就是需求缺口。

别再说「用判定表」。5 个条件各 3 种取值，全组合是 243 组，判定表会直接爆炸。这时候换正交实验法——用正交表从全组合里挑有代表性的组合，工具可以用 PICT 或 AllPairs。但要说清一件事：正交法给的是降维采样，不是全组合覆盖。

2、正交实验法到底保证了什么？

在考什么：用工具的人知不知道工具的边界。这题是分水岭。

骨架：正交表保证的是「任意两个因素的每种取值组合，至少出现一次」——也就是两两组合覆盖。它不保证三因素及以上的交互，也不是全组合覆盖。所以流程是：正交表出第一版 → 再按业务风险手动补关键组合（这一步靠错误猜测法）→ 二者合并才是最终用例集。只答「正交法能减少用例」只能拿一半分，答出「它保证两两覆盖、不保证高阶交互」才算过关。

要。每个正交表能容纳的因素数和水平数是固定的，超出就得换更大的表。所以别背表的编号，要会讲清「输入因素与水平 → 生成表 → 补充高风险组合」这条链路。

3、一个订单有 6 个状态，你怎么测状态流转？

在考什么：会不会用状态迁移法，而不是只测单点。

骨架：先画状态迁移图（待支付 → 已支付 → 已发货 → 已完成，加上已取消、已退款），再分两类设计——合法迁移逐条覆盖（每个状态至少进入一次、离开一次），非法迁移重点试探（已完成后能否回退到待支付、已取消能否再支付）。资金相关的路径优先级最高。

按风险排：覆盖每个状态的进出至少一次打底；资金和库存相关的迁移提到最前；非法迁移必测——状态机的 bug 绝大多数出在「不该发生的转换居然成功了」。

4、需求文档只写了一句话「支持批量导入」，你怎么开始？

在考什么：你会主动补信息，还是等着文档喂。

骨架：不写用例，先提问。格式支持哪些、单次条数上限、部分失败怎么处理（全回滚还是跳过）、重复数据是覆盖还是忽略、导入过程能不能并发。问不清的地方，就先当成假设写进用例的前置条件，会后用书面形式确认，留痕。

那就按最保守的默认值设计，并在用例里把假设写出来。最危险的不是猜错，是猜错了没人知道——等到上线才发现和你以为的规则不一样，返工的是你。

5、为什么 PUT、DELETE 是幂等的，POST 不是？

在考什么：是不是只背了「一个放 URL 一个放 body」。

骨架：幂等的定义是「同一请求执行一次和执行 N 次，对系统状态的影响相同」。PUT 是整体覆盖同一资源，执行 N 次结果一致；DELETE 第一次删掉，之后再删状态仍是「不存在」；POST 每次都新建一个资源，重放就是重复创建。真正影响测试的是这一点：测支付、下单这类接口，必须专门验重放和重复提交。

两种都可以，取决于接口契约怎么定。这题不考标准答案，考你知不知道这是契约问题——测试要验的是「同一契约下前后一致」，而不是猜一个所谓的正确码。若第一次 404、第二次 200，那才是问题。

6、接口重放导致重复下单，你怎么测、怎么推修复？

在考什么：并发 + 幂等设计，能不能落到方案。

骨架：测试侧——同一请求体串行重发、并发重发、带同一幂等键重发、超时后客户端自动重试，四种都要覆盖。修复侧——客户端带 Idempotency-Key，服务端把「键 → 首次响应」持久化，重复键直接返回首次结果；数据库唯一索引做最后一道兜底。先有幂等键，再谈并发控制。

不要。要设窗口，常见是 24 到 72 小时，配 TTL 和定时清理，否则这张表会无限增长。幂等键本身也会变成一个存储和 GC 问题，这也是测试要覆盖的：过期后再用同一个键，行为是否符合预期。

7、「先更新数据库再删缓存」为什么比「先删缓存再更新数据库」好？

在考什么：缓存一致性的真实理解，不是背名词。

骨架：两种写法的差别在脏数据窗口有多长。先删缓存再更库——缓存删掉、库还没更新完，这一小段时间里读请求会从库里读到旧值、再回填进缓存，脏数据会一直留到缓存过期。先更库再删缓存——脏窗口只到「删缓存」那一刻为止。另外，写的时候删缓存而不是更新缓存：删除是幂等的，更新缓存会在并发写下因为执行顺序错乱而互相覆盖。

两个：删缓存失败会长期脏；极端并发下读请求仍可能把旧值回填。补救手段是——异步延迟双删（不要用业务线程 sleep，会拖长接口耗时）、订阅 binlog 兜底、再加过期时间兜底。落点在一句话：缓存一致性只能做到最终一致，谁承诺强一致谁就是在吹。

8、单发正常，10 并发就偶发超时，你怎么判断是系统瓶颈还是压测方式有问题？

在考什么：能不能分清「被测系统的锅」和「你自己的锅」。

骨架：先同时看两条资源曲线——被测服务和压测机的。再看压测工具报的并发数是不是真的并发（有些工具的并发是名不副实的）。然后检查是不是被账号、IP、数据维度限流了。

不是直接报错，而是请求排队等连接，表现成响应时间随并发线性上升。这时候要给的结论是「这个连接的容量上限在哪」，而不是「测出一个 bug」——这是容量问题，不是缺陷，把两者混为一谈会显得你没有判断力。

9、库存扣减这种并发场景，怎么测？

在考什么：并发用例设计 + 结果验证手段。

骨架：三个动作——造并发（同一商品、多个用户同时下单）、看结果（库存能否扣成负数、成功订单数是否超过库存）、看中间态（未支付订单是否占着库存、取消后是否归还）。验证不能只看接口返回，要做压测 + 对账：订单表新增数 vs 库存变化，两边必须对得上。

压力够不够有信号：是否出现失败重试、资源是否打满、失败的请求是怎么失败的。结论里必须写清并发力度（并发数、持续时长、QPS），只写「压测通过」等于没测。

10、UI 自动化为什么容易 flaky？怎么从根上减少？

在考什么：你是靠重跑掩盖问题，还是找到了根因。

骨架：flaky 三大来源——等待（元素没就绪就操作）、数据（用例之间共享状态）、环境（并发执行互相干扰）。对应的根因解法：等待问题交给框架的自动等待机制，比如 Playwright 每次操作前会自动检查元素是否存在、可见、稳定、可用、没有遮挡；数据问题靠每个用例自造数据、自清理；环境问题靠并发隔离（账号和数据分片）。再加一条：失败要留证据（截图或 trace），而不是自动重跑三次假装没发生。

固定等待写小了照样 flaky，写大了拖慢 CI，而且它把真实原因盖住了。要等的是条件，不是时间。同理，断言也要用会重试的断言（等到条件满足为止），而不是读一次就判。

11、用例之间共享数据会带来什么问题？

在考什么：独立性意识。

骨架：三个后果——顺序依赖（A 挂了 B 跟着挂，排查成本翻倍）、并发不安全（两个用例改同一条数据）、重跑不可复现。做法是每个用例自己造数据、自己清理，用工厂函数加唯一标识（时间戳或随机串）。

测试环境把验证码服务打桩成固定值，或者用测试账号池。不要用生产的验证码通道去做自动化——这是既不合规也不稳定的做法。

12、CI 里跑一遍要 40 分钟，怎么优化？

在考什么：工程效率上的取舍能力。

骨架：分层。提交门禁只跑冒烟和核心链路（几分钟内出结果），全量回归挪到夜间或发版前；用例并行分片；合并重复场景砍冗余；能下沉到接口层的 UI 用例尽量下沉。

按「挡住一次线上问题的价值 ÷ 执行成本」排，不是按模块归属排。门禁的标准只有一条：它失败了，就必须拦下这次合并。拦不下的用例，放在门禁里只会让人习惯性忽略红灯。

13、接口自动化怎么断言才不是「假通过」？

在考什么：断言深度。

骨架：三层——状态码与结构（字段是否齐全、类型对不对）、业务字段值（关键结果是否正确）、副作用（数据真的落库了吗、下游有没有被正确调用）。只断言响应里 code=0 是最大的假通过来源。

就是被测系统的 bug，异步落库或事务没提交都会造成这种情况。测试必须验「最终状态」，不能只看响应体——否则你验的是接口在说谎。

14、一样的输入，模型两次输出不一样，这算 bug 吗？

在考什么：能不能接受非确定性，并据此改断言方式。

骨架：不算。就算把 temperature 设成 0，也不能保证逐字一致——推理实现和并行计算都会带来细微差异。所以断言要从「等值」变成「约束 + 阈值」：结构断言（必须是合法 JSON、字段齐全）、内容断言（该出现的关键信息出现、引用的内容确实来自给定文档）、质量断言（规则或另一个模型打分，超过阈值算通过）。阈值不能拍脑袋，要拿一批人工标注过的样本校准过。

测一批固定案例的整体表现，看分数分布有没有下移，而不是拿单次输出对比。单次结果说明不了趋势。

15、RAG 效果差，你怎么拆是检索的锅还是生成的锅？

在考什么：归因能力。这题最能看出你是真做过还是背概念。

骨架：分开测。检索侧看命中率、MRR、NDCG@k——正确文档到底有没有被召回；生成侧看忠实度、答案相关性、上下文精确率和召回率——召回的东西有没有被用好。只有把两段拆开，才能定位问题出在哪。

不是。强模型会掩盖烂检索——检索给了一堆不相关的文档，模型凭自己的常识答对了，这种「好成绩」换一类问题立刻就崩。端到端分数要永远配合分段指标一起看。

16、幻觉怎么测？怎么区分「幻觉」和「知识过时」？

在考什么：有没有把「答错」再往下分类。

骨架：先分类型——凭空编造（无中生有）、张冠李戴（引用错来源）、过度外推（超出上下文结论）。测法是对可控知识设定问题，看答案是否忠实于给定材料；涉及事实的，要有外部权威源做基准。区分「幻觉」和「知识过时」的关键是看答案有没有依据：过时是「依据旧信息给了当时正确的答案」，幻觉是「依据不存在的信息给了答案」——前者要在提示或检索层解决，后者是模型层的可靠性问题。

复现不了单次输出，就复现这一类：固定输入、固定版本、固定提示词，跑一批看失败率。报告里要写失败率，不能写「我试了一次它错了」。

17、提示注入：直接注入和间接注入，为什么后者更危险？

在考什么：知不知道威胁模型的差别。

骨架：直接注入来自用户自己的输入，用户知道自己在攻击；间接注入藏在模型会读到的东西里——检索到的文档、抓取的网页、工具返回的结果。这种攻击用户根本不知道它存在，而且内容来自系统「信任」的来源。测的时候，同一件事要用多种说法反复打（直接要求复述上文指令、换角色套规则、让它用代码块输出前文）。

不能。要测的是「稳定拒绝」，不是「拒绝过」。换个措辞就绕过，等于没防。判定标准是同一类攻击在多种变体下的拦截率，而不是单次结果。

18、Agent 的测试为什么不能只看最终答案？

在考什么：有没有轨迹意识。

骨架：结果对不代表过程对。一个 Agent 可能绕了很远、重复调了十几次工具，最后侥幸答对，换个输入立刻崩。所以要评轨迹——每一步的工具选择、参数、顺序是否合理；同时必须设硬预算：最大步数、最长耗时、最高成本，到线即停。

不算。要看轨迹，而且预算本身就是一条验收线——一个正确但成本失控的 Agent，在生产里和错的没区别。

19、线上出了 P0，你是先止血还是先定位原因？

在考什么：出事时的第一反应。

骨架：先止血——回滚、降级、关闭开关，把影响面控制住；再定位原因。顺序反了，损失会一直扩大。止血不等于放弃现场：回滚前把日志、快照、当时的监控曲线留下来，事后才有得查。

拿影响面说话：如果还在扩大，就先止血；如果影响面已经稳定且不严重，再看日志也来得及。判断依据是「还在不在继续伤害用户」，不是「谁更想把原因搞清楚」。

20、开发说「这是设计如此」，你怎么办？

在考什么：沟通方式 + 判断力。

骨架：三步。先确认是不是真的设计如此（翻需求、原型、接口文档）；再看它会不会伤到用户——设计如此不等于用户能接受；最后落到「记录 + 升级」：把现象、影响、当前设计写清楚，让该拍板的人拍板。目标不是吵赢，是让决策留痕。

测。但用例里标清「当前设计如此」，并附上「这样做用户会怎么踩坑」的风险提示。让不合理被看见，而不是替产品做决定。这才是测试该守的边界。

21、面试官问「你有什么想问我的」，问什么？

在考什么：这是最后一道题，不是客气话。

骨架：问三个能帮你判断要不要来的问题——这个岗位最常踩的坑是什么、团队自动化做到什么程度、线上问题谁先响应。别问薪资和假期，那是谈 offer 环节的事，这里问只会减分。

太空。面试官没法答，只能给你一段套话。反问要具体到工作方式：回归多久跑一次、线上问题怎么响应、测试和开发怎么分工。这些答案你能直接用来判断要不要来。

这三个不是题目不会，是追问一来就卡住。写下来是因为它们最值得复盘。

第一题是第 2 题（正交实验法）。我答的是「能减少用例数量」，面试官接着问「那它到底保证了什么」。我停了。准确的答法是：保证两两组合覆盖，不保证高阶交互，所以后面必须补高风险组合。「能减少用例」是好处，不是它保证的东西。

第二题是第 7 题（缓存一致性）。我把延迟双删讲得挺顺，面试官问「延迟多久合适」。我又停了。实际上延迟时间要靠读请求耗时加主从同步延迟来估，而且它本质是经验值——真正可靠的兜底是订阅 binlog，延迟双删只是降低概率。

第三题是第 15 题（RAG 归因）。我说了要分开看检索和生成的指标，面试官问「那端到端分数高说明什么」。我没往下接。正确答法是：说明不了检索没问题，强模型会掩盖烂检索，端到端和分段指标必须一起看。

三个追问有个共同点：我停下的地方，都是「我知道有这个手段」和「我知道这个手段的边界」之间的那道缝。

这 21 题别背答案，当成一次体检更划算。三步：

第一步，按模块打勾。 五个模块各打分，1 到 5 分。哪块低于 3 分，就是你这次要补的地方——不要平均用力，均匀复习等于没有复习。

第二步，每个模块挑一题出声讲。 盖上答案，讲完再对。脑子顺和嘴顺是两件事，卡在哪个词上，那个词就是你没真懂的地方。

第三步，只对「追问」做记录。 每道题的追问，写一句你的答法，再写一句边界在哪。21 条边界写下来，比背 21 段答案有用得多——面试官区分人和人的地方，从来不是第一层。

回到开头那句：高频题拼的不是会不会，而是你答到第几层。

这 21 题如果只答第一层，都能答上来；而面试真正打分的地方，是第二层和第三层。第一层是知识，第二层是理解，第三层是你有没有真的碰过。

所以别把时间花在「把题目都见过一遍」。挑出你答完第一层就没词的那几道，把它们往深里想一层——那几道，才是你这次面试真正的分数所在。

文中所涉及的行业标准与公开信息，均为截至 2026 年 10 月的公开内容，相关清单与认证版本会持续更新，引用前请以官方页面为准。文中题目来自公开面经的交叉整理与个人面试追问的复盘，用于方法演示，不代表任何具体岗位的真实考题；技术方案在不同规模与架构下取舍不同，落地前请以团队实际约束为准。