面试题一:功能测试用例设计
场景与问题
在某电商公司面试中,面试官问:“请你设计一个购物车结算功能的测试用例。功能包括:添加商品、修改数量、选择优惠券、提交订单。”

核心考察点
这道题考察的是测试用例设计的系统性和边界思维。
解析与答案
首选步:拆解功能点
- ►正常流程:用户选择商品 → 添加购物车 → 修改数量 → 选择优惠券 → 提交订单 → 支付成功
- ►异常流程:商品库存不足、优惠券过期、网络中断、提交后服务端返回错误
第二步:设计测试用例(示例)
| 用例编号 | 场景描述 | 前置条件 | 操作步骤 | 预期结果 |
|---|---|---|---|---|
| TC-001 | 正常添加商品 | 用户已登录,商品库存充足 | 点击“加入购物车” | 购物车中显示该商品,数量为1 |
| TC-002 | 修改商品数量为0 | 购物车中有1件商品 | 将数量改为0 | 提示“数量不能为0”,或自动删除该商品 |
| TC-003 | 使用满减优惠券 | 订单金额满足满减条件 | 选择优惠券 → 提交订单 | 订单总价扣减优惠金额 |
| TC-004 | 使用已过期优惠券 | 优惠券已过期 | 选择该优惠券 | 优惠券不可用,或提示已过期 |
| TC-005 | 提交时库存不足 | 商品被其他用户抢购,库存变为0 | 点击“提交订单” | 提示“商品库存不足”,订单未生成 |
| TC-006 | 网络断开后提交 | 模拟网络中断 | 点击“提交订单” | 提示“网络异常,请重试” |
第三步:方法论提炼
- ►等价类划分:将输入数据划分为有效等价类和无效等价类。例如,商品数量为1是有效类,数量为0或负数则是无效类。
- ►边界值分析:重点关注边界值,如数量为1、0、最大值等。
- ►错误推测法:基于经验,猜测可能出错的地方,如优惠券过期、库存不足。
效果验证
执行上述用例,发现TC-002在数量改为0时,系统直接删除商品而未给出提示,这属于一个交互缺陷。通过这个用例,可以确保功能在边界情况下行为正确。
---
面试题二:接口测试关注点
场景与问题
在一家金融科技公司面试中,面试官问:“你如何对一个转账接口进行测试?接口参数包括:fromAccount(转出账号)、toAccount(转入账号)、amount(金额)。”
核心考察点
这道题考察的是对接口测试的理解深度,包括参数校验、业务逻辑和安全性。
解析与答案
首选步:明确测试维度
1. 参数校验
- ►fromAccount 和 toAccount 必须为有效账号,且格式正确(如16位数字)。
- ►amount 必须为正数,且不超过账户余额。
- ►参数类型:amount 应为数值类型,传入字符串应被拒绝。
2. 业务逻辑
- ►转出账户余额扣减,转入账户余额增加,两者金额一致。
- ►同一账户不能给自己转账。
- ►转账后,交易记录应正确生成。
3. 安全性
- ►接口需要鉴权,未登录或token过期应返回401。
- ►转账操作应有幂等性校验,防止重复提交导致重复扣款。
第二步:设计测试用例(代码示例)
方法论提炼
- ►参数校验:用边界值和非法值覆盖所有参数。
- ►业务逻辑:通过数据库验证余额变化和交易记录。
- ►安全测试:测试鉴权、防重放、防篡改。
---
面试题三:性能测试指标与工具
场景与问题
在一家社交平台公司面试中,面试官问:“你们公司之前做过性能测试吗?说说你关注的性能指标,以及如何用JMeter进行一个简单的压测?”
核心考察点
考察对性能测试的理解和工具的实际使用能力。
解析与答案
首选步:核心性能指标
| 指标 | 含义 | 关注点 |
|---|---|---|
| TPS(每秒事务数) | 系统每秒能处理的事务数量 | 衡量系统处理能力 |
| 响应时间 | 从发送请求到收到响应的时间 | 用户体验 |
| 错误率 | 请求失败的比例 | 系统稳定性 |
| CPU/内存使用率 | 服务器资源占用情况 | 资源瓶颈判断 |
第二步:JMeter压测示例
场景:对一个登录接口进行压测,模拟100个用户并发。
1. 创建测试计划
- ►添加线程组:设置线程数=100,Ramp-Up Period=10秒,循环次数=1。
- ►添加HTTP请求默认值:设置服务器地址和端口。
- ►添加HTTP请求:设置路径为
/login,参数为username和password。 - ►添加监听器:查看结果树、聚合报告。
2. 运行与结果分析
- ►运行测试后,查看聚合报告中的“Average”(平均响应时间)、“Throughput”(吞吐量,即TPS)、“Error%”(错误率)。
- ►如果平均响应时间超过2秒,或错误率超过5%,则说明系统性能不达标。
第三步:常见问题与对策
- ►TPS上不去:可能原因有数据库连接池不足、代码中锁竞争、网络带宽限制。
- ►对策:增加数据库连接数、优化SQL、增加带宽。
- ►响应时间突增:可能原因有缓存失效、垃圾回收频繁。
- ►对策:预热缓存、调整JVM参数。
---
面试题四:自动化测试框架设计
场景与问题
在一家教育科技公司面试中,面试官问:“如果让你设计一个Web自动化测试框架,你会如何设计?需要考虑哪些方面?”
核心考察点
考察框架设计能力、可维护性和可扩展性。
解析与答案
首选步:框架层次划分
一个成熟的自动化测试框架通常分为四层:
1. 测试用例层:使用pytest或unittest编写测试用例,使用数据驱动(如参数化)减少重复代码。
2. 页面对象层(Page Object Model, POM):将每个页面封装成一个类,页面上的元素定位和操作方法封装在类中。
3. 基础层:封装Selenium WebDriver的常用操作,如元素等待、截图、日志记录。
4. 配置层:管理测试环境配置(如URL、浏览器类型)、测试数据(如Excel、YAML文件)。
第二步:代码示例(POM模式)
第三步:框架设计要点
- ►可维护性:页面元素变更时,只需修改页面对象层,无需修改用例。
- ►可扩展性:支持添加新浏览器(如Chrome、Firefox)和新环境(如测试、预发布)。
- ►报告与日志:集成Allure报告和日志框架,便于定位问题。
---
面试题五:Bug的生命周期与管理
场景与问题
在一家游戏公司面试中,面试官问:“你在工作中如何管理Bug?描述一个Bug从发现到关闭的完整流程。”
核心考察点
考察对Bug管理流程的理解和团队协作能力。
解析与答案
首选步:Bug生命周期
1. 发现:测试人员执行测试,发现软件缺陷。
2. 提交:在Bug管理工具(如Jira、禅道)中提交Bug,填写标题、严重程度、优先级、环境、复现步骤、预期结果、实际结果、截图/日志。
3. 分配:测试经理或项目经理将Bug分配给对应的开发人员。
4. 修复:开发人员定位问题并修复代码。
5. 验证:测试人员在修复后的版本中验证Bug是否修复。
6. 关闭:验证通过后,关闭Bug。
7. 重开:如果验证不通过,或修复引入了新问题,则重新打开Bug。
第二步:Bug提交示例(Jira格式)
- ►标题:登录页面输入正确用户名密码后,点击登录无反应
- ►严重程度:严重(功能无法使用)
- ►优先级:高
- ►环境:Chrome 120.0.6099.109,Windows 11,测试环境
- ►复现步骤:
1. 打开登录页面
2. 输入用户名 admin,密码 123456
3. 点击“登录”按钮
- ►预期结果:跳转到首页
- ►实际结果:页面无响应,控制台无报错
- ►附件:截图、录屏、日志文件
第三步:Bug管理要点
- ►区分严重程度与优先级:严重程度指对系统的影响程度,优先级指修复的紧急程度。一个界面错位的Bug可能严重程度低,但优先级高(因为影响用户体验)。
- ►闭环管理:确保每个Bug都有明确的处理结果,避免Bug“石沉大海”。
---
自测清单
1. 你能独立设计一个中等复杂功能的测试用例吗?
2. 你了解接口测试中参数校验、业务逻辑、安全性的常见测试点吗?
3. 你能否用JMeter完成一个简单的压测并分析结果?
4. 你理解Page Object Model,并能用它编写自动化测试用例吗?
5. 你清楚Bug从提交到关闭的完整流程吗?
如果以上问题的答案都是肯定的,那么你已经具备了扎实的软件测试面试准备。如果还有模糊的地方,建议针对性地练习和复习。
京公网安备 11010802030320号