中级软件测试工程师面试题：7个高频问题_千锋教育

为什么面试官总问这7个问题？

中级软件测试工程师面试，不同于初级岗位。面试官不再满足于“你会用什么工具”，而是考察“你如何解决问题”、“你的设计思维”和“你的工程能力”。

这7个高频问题，几乎覆盖了所有中级岗位面试的核心考察点。下面，我们逐个拆解，每个问题都给出“为什么问”和“怎么答”。

---

问题1：设计一个登录功能的测试用例

为什么问：

考察测试设计能力。登录功能所有人都熟悉，但能否设计出有层次、覆盖边界和异常的用例，直接反映你的测试思维。

怎么答：

不要只罗列“输入正确用户名密码能登录”。应该按类型分层：

►功能测试：正确登录、错误密码、空用户名、密码大小写敏感、记住密码功能。
►UI测试：界面布局、错误提示文案、密码是否掩码显示。
►安全测试：SQL注入尝试、暴力破解防护（如连续失败5次后锁定）、密码传输是否加密（HTTPS）。
►兼容性测试：不同浏览器、不同分辨率、移动端适配。
►异常测试：网络中断后重试、服务端返回500错误时的表现、Session过期后的跳转。

一个关键点：不仅要列出用例，还要解释你的分类逻辑。面试官更看重你的结构化思维。

---

问题2：接口测试中，如何验证一个接口返回结果是否正确？

为什么问：

考察你对接口测试的理解深度。很多初级测试只会检查状态码200，忽略了业务逻辑验证。

怎么答：

验证需要分层，不能只靠单一维度：

1. 状态码验证：检查HTTP状态码（200表示成功，4xx表示客户端错误，5xx表示服务端错误）。

2. 响应体结构验证：确认返回的JSON/XML结构是否与接口文档一致（字段名、字段类型、是否缺失）。

3. 业务逻辑验证：这是核心。例如，查询用户信息接口，返回的user_id是否与请求参数一致；下单接口，返回的订单金额是否等于商品单价×数量。

4. 数据一致性验证：如果接口操作了数据库，需要查询数据库确认数据变更正确。例如，修改用户昵称后，调用查询接口确认昵称已更新。

5. 边界与异常验证：传入非法参数（如负数ID、超长字符串）时，接口是否返回合理的错误码和错误信息，而不是直接崩溃。

---

问题3：你如何对一个API进行性能测试？请描述流程

为什么问：

考察性能测试实战经验，而不仅仅是知道工具名称。

怎么答：

以JMeter或Locust为例，一个典型的流程：

1. 确定目标：明确性能指标，例如“支持1000用户并发，平均响应时间<2秒，错误率<1%”。

2. 设计场景：模拟真实用户行为，包含登录、浏览商品、下单等混合操作，而不是只压测一个接口。

3. 准备数据：确保测试数据真实且足够。例如，1000个并发用户需要1000个不重复的账号，避免数据冲突导致结果失真。

4. 执行测试：先做基准测试（单用户），再做负载测试（逐步增加并发），最后做压力测试（突破预期峰值，观察系统拐点）。

5. 监控资源：同时监控服务器CPU、内存、磁盘IO、网络带宽，以及数据库连接池、慢查询等。

6. 分析结果：关注响应时间分布（P50、P90、P99）、吞吐量（TPS）、错误率。找到性能瓶颈（是代码慢、数据库慢、还是网络问题）。

7. 调优与回归：针对瓶颈给出优化建议（如加索引、加缓存、优化SQL），然后重新测试验证。

---

问题4：发现一个Bug，但开发人员说“这不是Bug，是需求如此”，你怎么处理？

为什么问：

考察沟通能力和问题解决能力。中级测试需要能推动问题解决，而不是被开发一句话堵回去。

怎么答：

不争论，而是用数据和事实说服。步骤：

1. 确认需求文档：先自己重新阅读需求文档、原型图、验收标准。确认是自己理解有误，还是开发实现有偏差。

2. 复现并截图/录屏：把Bug复现的每一步和预期结果、实际结果的对比，清晰记录。

3. 引用需求：如果需求明确，直接把需求文档中对应的条款截图给开发看，指出“需求要求这里显示A，但实际显示B”。

4. 如果需求模糊：不直接对抗，而是说“这个场景下用户可能会困惑，我们是否可以和产品经理一起确认一下？” 拉上产品经理三方沟通，避免自己陷入争论。

5. 如果确实是需求问题：记录为“需求缺陷”或“改进建议”，在产品评审时提出。

核心原则：对事不对人，用文档和证据说话，拉第三方决策。

---

问题5：自动化测试脚本不稳定，经常出现元素定位失败，怎么解决？

为什么问：

考察自动化的落地能力和问题排查经验。很多团队自动化脚本跑着跑着就废了，就是因为不稳定。

怎么答：

从几个方向排查和解决：

►检查定位策略：优先使用ID、Name等稳定属性。如果动态变化，使用相对XPath或CSS选择器，避免依赖绝对路径。
►增加等待机制：不要用固定time.sleep()。使用显式等待（WebDriverWait），等待元素可见、可点击、存在。
►检查页面是否异步加载：AJAX请求后，页面元素可能延迟出现。等待某个代表加载完成的元素出现（如“加载完成”的图标消失）。
►检查浏览器/驱动版本：确保ChromeDriver版本与Chrome浏览器版本匹配。定期更新。
►检查测试数据污染：上一个用例的数据是否影响了当前用例？例如，未清理的Cookie、LocalStorage。每个用例独立准备数据。
►增加失败截图和日志：脚本失败时自动截图，并打印当前页面URL、页面标题、错误堆栈，便于排查。

---

问题6：说说你对持续集成/持续交付（CI/CD）的理解，以及测试如何融入？

为什么问：

考察工程化思维。中级测试需要了解DevOps流程，知道测试不是孤立的。

怎么答：

CI/CD的核心是自动化构建、测试、部署。测试的融入点：

►代码提交阶段：开发提交代码后，CI工具（Jenkins/GitLab CI）自动触发：
►代码静态分析（SonarQube）
►单元测试（开发负责）
►接口测试（测试团队维护的用例集，快速反馈）
►构建阶段：打包成功后，自动部署到测试环境。
►测试阶段：
►自动化回归测试（UI自动化、接口自动化）在测试环境运行。
►性能测试（可配置为定时任务，或手动触发）。
►部署阶段：测试通过后，自动部署到预发布环境，再手动验证关键功能，最后上线。

关键点：测试用例需要设计成可重复、可独立运行，并且运行时间要短（接口测试控制在几分钟内），否则会拖慢CI流水线。

---

问题7：你如何对一个“搜索功能”进行测试？

为什么问：

考察测试场景设计能力。搜索功能看似简单，但涉及面很广。

怎么答：

从多个维度展开：

►功能测试：精确搜索、模糊搜索、拼音搜索、同义词搜索、空搜索、特殊字符搜索（如%、_）、超长关键词搜索。
►性能测试：单用户搜索响应时间；高并发下搜索是否变慢；搜索结果量很大时（如10万条）的加载速度。
►兼容性测试：不同浏览器、不同移动设备、不同操作系统。
►搜索排序：搜索结果是否按相关性排序？置顶商品是否在首选位？排序是否正确（按价格升序/降序）。
►搜索建议：输入部分文字时，下拉建议是否及时出现？建议内容是否相关？
►无结果处理：搜索无结果时，是否有“未找到相关结果”的提示？是否推荐热门搜索或分类？
►搜索历史：搜索历史是否按时间倒序排列？是否支持清空历史？是否支持删除单条？

---

自测清单

面试前，用这份清单快速自我评估：

►[ ] 能否在5分钟内写出一个登录功能的测试用例（分层设计）？
►[ ] 是否清楚接口测试验证的四个层次（状态码、结构、业务、数据一致性）？
►[ ] 能否说清性能测试的执行流程（目标→场景→数据→监控→分析）？
►[ ] 是否有处理开发说“不是Bug”的实际案例经验？
►[ ] 是否知道自动化脚本不稳定的常见原因和解决方案？
►[ ] 是否能解释CI/CD中测试的融入点？
►[ ] 能否从功能、性能、兼容性等维度设计搜索功能的测试用例？

把这7个问题吃透，面试时就能从容应对。