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

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

回答要点： 面试官想考察你的测试思维是否系统化，是否具备等价类、边界值等基础设计能力。

标准回答结构：

从功能、UI、安全、性能、兼容性、异常场景六个维度展开。

1. 功能测试（核心）：

►正常输入：正确的用户名和密码，验证能否登录成功。
►异常输入：错误的密码、不存在的用户名、空输入、超长输入（边界值，如密码最长20位，测试21位）。
►状态校验：已禁用账号、已锁定账号、未激活账号。

2. UI测试：

►页面布局：输入框、按钮、提示信息是否对齐，无错位。
►交互反馈：点击登录按钮后，按钮是否变为“登录中”并禁用，防止重复提交。

3. 安全测试：

►密码保护：密码输入框是否显示为密文。
►暴力破解：连续输错N次后，账号是否被锁定或触发验证码。
►会话管理：登录成功后，关闭浏览器重开，是否需要重新登录（Cookie有效期）。

4. 性能测试：

►并发场景：模拟多人同时登录，观察响应时间。
►弱网测试：模拟2G/3G网络，登录请求是否会超时或重试。

5. 兼容性测试：

►浏览器：Chrome、Firefox、Edge、Safari。
►设备：PC端、移动端（不同分辨率）。

6. 异常场景：

►网络中断：登录过程中断网，是否有超时提示。
►多端登录：同一账号在不同设备同时登录，是否会被踢下线。

经验分享： 面试官不会让你真的列完所有用例，而是看你能否在有限时间内给出一个结构清晰、覆盖全面的答案。建议先抛出“六大维度”，再挑两三个维度展开。

---

问题二：接口测试中，如何断言一个接口返回的数据是否正确？

回答要点： 考察你对接口测试的理解深度，是否只停留在“状态码=200”的层面。

标准回答结构：

接口测试的断言不能只看HTTP状态码，必须深入到响应体（Response Body）的字段校验。

1. 状态码断言（基础）：

►成功：200、201。
►客户端错误：400、401、403、404。
►服务端错误：500、502、503。

2. 响应体字段校验（核心）：

►字段存在性：确认返回的JSON中存在预期字段（如username、token）。
►字段类型：id必须是整型，create_time必须是时间戳格式。
►字段值范围：pageSize不能超过100，status只能是0或1。
►业务逻辑校验：例如，查询订单接口，返回的total_amount必须等于所有商品价格之和。

3. 数据库校验（进阶）：

►接口返回“操作成功”后，去数据库验证数据是否真实写入。
►例如：注册接口返回{"code":0}，随后查询数据库用户表，确认该用户已存在。

代码示例（Python + requests + pytest）：

python

import requests
import pytest

def test_login_success():
    url = "https://api.example.com/login"
    payload = {"username": "test_user", "password": "correct_pass"}
    response = requests.post(url, json=payload)
    
<div style="margin:24px 0;border:1px solid #E3F2FD;border-radius:8px;background:#FAFAFA;overflow:hidden;"><div style="display:flex;align-items:center;gap:12px;padding:12px 20px;background:linear-gradient(135deg,#E3F2FD,#BBDEFB);"><span style="width:36px;height:36px;background:#2196F3;color:#fff;border-radius:50%;display:inline-flex;align-items:center;justify-content:center;font-weight:bold;font-size:16px;flex-shrink:0;">1. </span><span style="font-size:17px;font-weight:700;color:#1565C0;">状态码断言</span></div><div style="padding:16px 20px;"><p>assert response.status_code == 200</p></div></div>
<div style="margin:24px 0;border:1px solid #E3F2FD;border-radius:8px;background:#FAFAFA;overflow:hidden;"><div style="display:flex;align-items:center;gap:12px;padding:12px 20px;background:linear-gradient(135deg,#E3F2FD,#BBDEFB);"><span style="width:36px;height:36px;background:#2196F3;color:#fff;border-radius:50%;display:inline-flex;align-items:center;justify-content:center;font-weight:bold;font-size:16px;flex-shrink:0;">2. </span><span style="font-size:17px;font-weight:700;color:#1565C0;">响应体字段校验</span></div><div style="padding:16px 20px;"><p>data = response.json()</p>
<p>assert "token" in data, "token字段缺失"</p>
<p>assert isinstance(data["token"], str), "token类型错误"</p>
<p>assert len(data["token"]) > 0, "token为空字符串"</p></div></div>
<div style="margin:24px 0;border:1px solid #E3F2FD;border-radius:8px;background:#FAFAFA;overflow:hidden;"><div style="display:flex;align-items:center;gap:12px;padding:12px 20px;background:linear-gradient(135deg,#E3F2FD,#BBDEFB);"><span style="width:36px;height:36px;background:#2196F3;color:#fff;border-radius:50%;display:inline-flex;align-items:center;justify-content:center;font-weight:bold;font-size:16px;flex-shrink:0;">3. </span><span style="font-size:17px;font-weight:700;color:#1565C0;">数据库校验（假设已封装数据库查询函数）</span></div><div style="padding:16px 20px;"></div></div>
    # user = db.query("SELECT * FROM users WHERE username='test_user'")
    # assert user is not None

经验分享： 面试官通常希望听到“数据库校验”这一层，这能体现你对数据完整性的重视。

---

问题三：发现一个Bug，开发说不是Bug，你怎么处理？

回答要点： 考察你的沟通能力、问题分析能力，以及在压力下是否能坚持质量标准。

标准回答结构：

1. 先确认Bug是否真实存在：

►复现Bug：严格按照测试用例的步骤，在相同环境下再次操作，确保不是操作失误。
►查看日志：检查应用日志、服务端日志，寻找报错信息。
►排除环境差异：确认测试环境和开发环境配置是否一致（数据库版本、中间件版本等）。

2. 收集证据：

►截图/录屏：记录Bug出现的完整过程。
►抓包数据：通过Fiddler、Charles等工具抓取接口请求和响应。
►日志文件：导出相关日志片段。

3. 与开发沟通：

►摆事实：将证据（截图、日志、抓包数据）展示给开发，说明预期结果和实际结果的差异。
►讲依据：引用需求文档、原型图或PRD，证明这是不符合需求的。
►询问原因：如果开发坚持不是Bug，询问其判断依据（例如：“这个字段是后端计算的，前端只负责展示，但计算逻辑有缺陷”）。

4. 升级处理（如果无法达成一致）：

►拉产品经理或项目经理介入，由他们根据业务价值做最终裁定。
►记录Bug到缺陷管理系统，标注“与开发存在争议”，等待上级决策。

经验分享： 核心原则是“对事不对人”。不要直接说“你写错了”，而是说“我们发现了一个与需求不一致的地方，我们来看一下”。保持专业和冷静。

---

问题四：给你一个从未接触过的系统，你会如何开展测试？

回答要点： 考察你的学习能力、测试策略制定能力以及风险意识。

标准回答结构：

1. 理解业务（第一优先级）：

►阅读需求文档、产品原型、PRD。
►向产品经理或业务方请教核心业务流程（如：用户下单→支付→发货→收货）。
►画出业务流程图，明确输入、处理、输出。

2. 熟悉系统架构：

►确认系统是B/S还是C/S，前端用什么框架，后端用什么语言，数据库是什么。
►了解接口文档（Swagger、YApi）和数据库表结构。

3. 制定测试策略：

►冒烟测试（最优先）： 跑通核心业务流程，确保系统基本可用。
►功能测试： 按模块划分，先测高频功能，再测低频功能。
►接口测试： 优先测试核心接口（登录、下单、支付）。
►兼容性测试： 根据用户群体，确定需要覆盖的浏览器、操作系统、设备。

4. 风险识别：

►新系统可能存在的风险：数据迁移问题、第三方依赖（支付、短信）的稳定性。
►针对高风险模块，加大测试力度（如：金额计算、权限控制）。

5. 快速执行与反馈：

►先执行冒烟测试，通过后立即通知开发。
►每天输出测试日报，同步进度和阻塞问题。

经验分享： 面试官想看到的是“方法论”，而不是具体细节。回答时要体现出“先全局，后局部”的思路。

---

问题五：什么是回归测试？如何保证回归测试的效率和覆盖率？

回答要点： 考察你对测试流程的理解，以及自动化测试的实践经验。

标准回答结构：

定义： 当系统新增功能或修复Bug后，对已有功能进行重新测试，确保原有功能不受影响。

如何保证效率和覆盖率：

1. 自动化回归（核心）：

►将核心业务流程（登录、下单、支付）写成自动化脚本（Selenium/Appium + Pytest）。
►每次版本发布前，跑一遍自动化回归套件，耗时从人工的2天缩短到1小时。
►自动化脚本需要定期维护，确保稳定。

2. 优先级分层：

►P0（高优先级）： 核心业务流程，每次回归必须执行（支付、登录、权限）。
►P1（中优先级）： 高频功能，按周执行（搜索、列表展示）。
►P2（低优先级）： 低频功能，按月或按版本执行（帮助中心、设置页面）。

3. 精准测试（进阶）：

►分析代码变更（Git diff），只回归受影响的模块。
►例如：只修改了订单列表页，就不需要回归登录和支付模块。
►通过代码覆盖率工具（JaCoCo、Istanbul）分析自动化脚本是否覆盖了变更代码。

4. 人工抽测：

►对于无法自动化的场景（UI样式、复杂交互），安排人工进行抽查。
►重点关注新功能与旧功能的交互点。

经验分享： 面试官最想听到的是“自动化”和“精准测试”这两个词。如果团队没有自动化，可以强调“手工回归+优先级分层”的组合策略。

---

自测清单（检查你的掌握程度）

►[ ] 能否在2分钟内说出登录功能测试的6个维度？
►[ ] 能否写出一个包含状态码、字段类型、数据库校验的接口断言代码？
►[ ] 面对开发说“不是Bug”，你是否知道该收集哪些证据？
►[ ] 接手新系统时，你的第一步是看文档还是直接操作？
►[ ] 你的团队回归测试中，自动化脚本的覆盖率是否超过核心流程的70%？

总结： 这5个问题覆盖了测试思维、接口测试、沟通协作、测试策略和流程管理，是中级测试工程师面试中的核心考点。理解背后的逻辑，比背答案更重要。