软件测试面试复盘,23 道现场真题整理

软件测试 · 面试复盘

📦 8 Parts + Conclusion

👉 滑动

在考什么：不是听你讲故事，是看你能否在 30 秒内说清“我负责什么范围、我做了什么判断”。

骨架：一句话交代产品是什么、给谁用；再说你负责的部分有多大——几个模块、多长迭代周期、大概多少条用例；最后落到你做过的两个判断，而不是两个“我执行了什么”。

会掉分的答法：从公司简介开始讲。面试官前 15 秒听不到“你”，后面就很难再集中注意力。

在考什么：自我校准能力。一个说不清自己短板的人，通常也不知道自己强在哪。

骨架：说一件具体的事，再加一个已经做完的动作。比如“上次被问到性能测试的并发数怎么定，我当时只会说按经验估，回来查了业务指标和 PV 推算的算法，自己拿一个项目的数据算了一遍”。

在考什么：稳定性，不是热情。热情问不出来，稳定性问得出来。

骨架：一个真实的原因就够了，不用拔高。测试这件事需要人愿意盯细节、愿意被质疑、愿意把话说清，能对上其中一两点就很可信。

在考什么：基本盘。这题答不完整，后面很难救。

骨架：编号、标题（或测试点）、前置条件、操作步骤、预期结果、优先级。答完补一句更有用的：真正决定用例能不能被别人执行的，是前置条件和预期结果写得够不够具体。“输入正确账号密码”不算前置条件，“使用已注册且未锁定、密码已确认的账号”才是。

在考什么：会不会从机制推用例，而不是背定义。

骨架：等价类解决“测不完”——把输入划成若干类，每类挑代表值；边界值解决“最可能出错”——错误通常堆在临界点上。例子：一个限 1 到 100 的输入框，等价类分有效（1 到 100）和无效（小于 1、大于 100）；边界值取 0、1、2、99、100、101。最后补一句：边界值是等价类的补充，不是替代。

在考什么：用业务眼光看缺陷，而不是只用技术眼光。

骨架：Severity 是技术影响程度，Priority 是修复顺序，两者由不同角色决定，也经常不一致。典型例子有两个方向——首页上的错别字，Severity 低但 Priority 高；一个冷门功能在极端条件下的崩溃，Severity 高但 Priority 低。

在考什么：是不是只会往前的正向流程。

骨架：按维度切，别按界面切。正常路径、异常输入（空、超长、特殊字符、SQL 注入类）、账号安全（连续失败锁定、验证码、多端互踢）、兼容与网络（不同浏览器、弱网、断网重连）、性能与并发（同一账号并发登录）、数据一致性（登录后状态是否同步）。动手前先问清业务规则——连续错几次锁、锁多久、能不能自己解锁。规则不清就设计用例，等于自己给自己埋返工。

在考什么：能不能从一个很小的需求里挖出真实风险。

骨架：分四层。文件本身——格式、大小上限、极端尺寸、损坏文件、伪装后缀；上传过程——弱网、中途取消、重复点击、并发上传；业务规则——审核、裁剪、替换后旧图是否残留；存储与展示——刷新后还在不在、多端是否一致、CDN 是否有缓存延迟。

在考什么：会不会主动补信息，还是被动等文档。

骨架：三层回答。需求覆盖——用需求矩阵确保每个需求点至少有一条用例；代码覆盖——结合开发给的单元测试覆盖率，看有没有分支没被走到；风险覆盖——按业务关键程度分配有限的精力。收尾一句很重要：覆盖率不等于质量，但缺少覆盖率一定有风险。

在考什么：会不会把手段用在对的场景。

骨架：需求不清、变更频繁、时间紧的时候最适合用；和脚本测试是互补关系——脚本保回归底线，探索找未知问题。顺序也有讲究：先用脚本把主流程铺住，再用探索去啃边角，反过来做会丢回归。

在考什么：不只是“一个放 URL 一个放 body”。

骨架：语义（是否幂等）、参数位置、能否被缓存、长度限制、安全性差异。真正影响测试的是幂等性——GET 重放通常无害，POST 重放可能产生重复订单。所以测支付类接口时，一定会专门验重放和重复提交。

在考什么：排查是不是有序的，还是靠试。

骨架：四步。先确认能不能稳定复现，以及是否和数据量、并发相关；再抓包加日志，定位卡在哪一环（网关、应用、数据库）；然后用对比法缩小范围——同一个请求换参数、换环境，看差异出现在哪；最后和开发一起看线程数、连接池、慢查询。能说出“用对比法缩小范围”，基本就说明你真查过线上问题。

在考什么：能不能分清“被测系统的瓶颈”和“压测机自己的瓶颈”。

骨架：先看被测服务器资源是否打满（CPU、内存、IO）；再看接口有没有报错、响应时间是否变慢；然后看压测机自己的网络 IO 和并发数够不够；最后确认压测工具是否真的支持你要的并发。

在考什么：会不会从“用户分布”里找规律。

骨架：先切人群——客户端版本、机型与系统版本、地域、灰度分组、会员等级，任何一个维度出现明显聚集，问题范围立刻就缩小了；再往接口兼容想——接口改动没做版本兼容，是老客户端集体失效最常见的原因。

在考什么：这是整组的定调题，答偏了后面全偏。

骨架：传统系统是“输入 A 得到 B，否则就是 bug”；模型系统输出是概率的，判断标准从“对或错”变成“在什么条件下、以多大概率是可接受的”。所以做 AI 测试，第一件事不是写用例，是先把“什么叫好”定义出来。定义不清楚，后面所有的断言都无处落脚。

在考什么：会不会把断言从布尔值换成多维度。

骨架：三类断言配合用。结构断言——必须是合法 JSON、必须包含规定的字段，这类是确定性的；内容断言——关键信息是否出现、是否引用了给定文档里的内容；质量断言——用规则或另一个模型打分，超过阈值算通过。阈值不能拍脑袋，要拿一批人工标注过的样本校准过才算数。

在考什么：知不知道“测一次不算测过”。

骨架：先把两类分开——直接注入来自用户输入，间接注入藏在模型会读到的东西里（检索到的文档、网页、工具返回结果），后者在生产里更危险，因为用户根本不知道攻击存在。然后同一件事要用多种说法反复打：直接要求重复上文指令、换角色套规则、让它用代码块输出前文。看它是不是稳定地拒绝——只拒一次不算拒。

在考什么：会不会分层，而不是罗列名词。

骨架：检索侧看命中与排序质量（命中率、MRR、NDCG@k）；生成侧看忠实度、答案相关性、上下文精确率、上下文召回率。关键在最后一句：端到端分数高，不代表系统没问题——检索和生成会各自独立地失败，总账好看可能是强模型掩盖了烂检索。

在考什么：用工具的人，是否也知道工具的边界。

骨架：用更强的模型给被测输出打分，好处是能把主观评价规模化。风险有三个：位置偏好（同一个答案放前面还是后面，分数会变）、篇幅偏好（更长的回答更容易拿高分）、以及自评偏差。所以必须拿人工标注校准，并且尽量不让同一个模型既当考生又当裁判。

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

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

在考什么：有没有质量门槛意识。

骨架：三个维度。缺陷——高优先级是否已关闭，遗留问题有没有规避方案；覆盖——核心链路回归是否完成，关键接口是否验过；风险——剩余问题有没有书面说明和兜底预案。只答“没有阻塞 bug 就能上”，会显得你只看到第一层。

在考什么：优先级判断，以及会不会沟通。

骨架：先按业务影响排，再按失败概率排，取两者都高的先测；然后把取舍说出来——哪些没测、风险是什么、建议谁关注。闷头测完一半却不告诉任何人，比不测更危险。

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

骨架：问团队怎么协作、自动化做到什么程度、这个岗位最容易踩的坑是什么。这三个问题都能让你判断自己要不要来。别问薪资和假期——那属于谈 offer 的环节，在这里问只会减分。

我当时说的是“用正则匹配几个关键词”。面试官接了一句：“关键词都对，但意思反了，怎么办？”我没接住。正确的补法是把断言分层——结构层用确定性规则，内容层判断关键信息是否命中，质量层用阈值打分。关键词断言只覆盖了中间那一层的下限。

我上来就怀疑被测系统，漏掉了“压测机自己会不会也是瓶颈”这一层。后来我改的做法是：先看两条资源曲线——被测服务器和压测机的，谁的资源先打满，问题就在谁那边。这一步能省掉半小时瞎猜。

我只说了它的好处，一个字的边界都没提。面试官没继续追，但我知道这题只拿了一半。后来补的方式是记住三个偏差的名字，并且加一句“所以它只能当辅助信号，不能当唯一验收依据”。

盖上答案，一题一题出声讲。脑子顺不代表嘴顺，这两件事差得很远。   

     能秒答的（基础题）不用管；要搭骨架的（设计类）反复讲三遍；只能靠真实经历的（比如“你做过的最难排查的问题”）一题都不能编，只能回去把自己项目里那件事捋清楚。   

     标出来的那三题，通常就是你这次面试真正的短板所在，跟题目本身难不难没关系。   

文中所涉及的行业标准与公开信息，均为截至 2026 年 10 月的公开内容，相关清单与认证版本会持续更新，引用前请以官方页面为准。文中的面试环节、题量与作答思路，来自一次具体面试的复盘整理与公开面经的交叉印证，用于方法演示，不代表任何具体岗位的真实考题。