联想 2027 届应届生招聘页面显示，面试安排已从 2026 年 8 月下旬开始；

页面还提示，能力测评成绩会保留，无需重复答题。

图源网络，如侵删

联想 2027 应届生招聘 把这条信息翻译成求职语言，大概就是：流程已经动起来了，准备不能只停在“再刷几道题”。

软件测试候选人容易停顿的时刻，常常出现在面试官提出这句追问时：“挑一个你发现过的 Bug，完整说说。”

这句看起来很日常，却能一路问到项目、思路、协作和结果。

很多人简历上的项目经历写得很满，一进入这个问题，回答却只剩一句“我提了一个缺陷，开发修复了”。

这就像把一部悬疑片只讲了片名：确实发生过，但听不出其中的判断。

Bug 为什么好问

一个真实缺陷，天然带着测试工作的时间线。

它从哪里出现？候选人当时在验证什么？为什么觉得这不是偶发现象？

复现时改过哪些条件？提交后，开发提出过什么疑问？修复后，又怎样确认没有牵出新的问题？

面试官并不需要候选人背出一串严重等级。

更有价值的，是看候选人能不能把一个混乱的现象，整理成可以被别人复查的事实。

◇   ◇   ◇

举个不需要夸张的例子。

某个下单页面偶尔出现“支付成功、订单却还停在待支付”的状态。

候选人的第一反应如果只是“接口有问题”，故事到这里就很难继续。

更完整的做法是拆开看：前端页面是否收到回调、订单服务是否更新状态、网络重试会不会制造重复请求、不同支付方式是否都有同样表现。

测试工作真正体现价值的地方，就在这种拆解里。

先画一张小地图

准备面试时，不必把每个 Bug 都背成稿子。

挑两到三个最熟悉的，分别写成一张“Bug 地图”即可。地图上保留六个格子：

场景：当时在测什么功能，用户从哪里进入；

现象：屏幕上具体出现了什么，避免只写“功能异常”；

条件：账号、版本、设备、网络、操作顺序里，哪些是关键变量；

定位：怎样缩小范围，查了日志、抓包、接口还是数据库结果；

协作：向谁同步，提供了哪些证据，是否发生过重新确认；

回归：修复后怎样验证主链路与关联链路。

这六格写完，回答自然会有顺序。

它也能防止一个常见问题：候选人把“我参与了”说成“我解决了”。

测试人员未必负责改代码，但完全可以清楚说明自己怎样发现、定位、推动确认并完成验证。

边界讲清楚，反而更可信。

追问来了，怎么接

面试官常会把问题往细处推。

比如：“为什么你认为和网络有关？”“同样的操作，换账号还会出现吗？”“开发说无法复现，你怎么办？”

这时可以先展示下一步验证动作：固定版本与账号，再调整网络条件；

如果问题消失或复现概率变化，就保留抓包与时间点，继续比对请求和服务端日志。

即使最后证明方向不对，这条验证路径仍有价值。测试工作的核心，是持续排除不确定性。

还有一种容易失分的回答是“这个问题后来就解决了”。

“怎么解决的”才是重点：修改了哪一层？回归覆盖了哪些场景？有没有留下可重复执行的用例？

说得越具体，面试官越容易判断候选人是真的做过，还是只看过项目复盘。

别把项目讲成术语表

一些候选人为了显得专业，会在一分钟里连续抛出接口、SQL、性能、自动化、CI/CD。词很多，故事却没有主线。

更适合面试的表达是“事实—判断—动作—结果”。

先交代一个看得见的现象；

接着说为什么没有把它当成偶发；

然后说做了哪些验证；最后落到修复和回归。

技术词放在真正需要解释的地方，它会成为证据，而不会变成装饰。

校招比的不是完美

校招刚开始时，候选人总会担心自己项目不够大、缺陷不够“惊险”。

其实，一个登录态失效、一个优惠叠加规则冲突、一次弱网下的重复提交，都可以成为好案例。

前提是：候选人知道它发生在什么条件下，知道自己如何推动问题从“感觉不对”变成“可复查的问题”。

联想的招聘页面提醒了一个朴素事实：流程可以保留成绩，也会不断往前走。

准备测试岗面试时，与其反复刷新状态，不如把自己最熟的两个 Bug 讲透。

到了面试现场，真正让人安心的从来不是“我没有遇到过问题”，而是“我知道怎样把问题讲清、查清、验清”。

更多软件测试相关推荐：

软件测试更多干货文章

软件测试就业培训

  文章来源：网络  版权归原作者所有

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8103)，我们将立即处理