一、讨论环节

讨论1：需求频繁变化的项目适合用V模型还是敏捷模型？

参考答案：更适合敏捷模型。因为敏捷开发采用迭代方式，每个迭代都可以根据用户反馈和业务变化调整需求。测试也可以在每个迭代中持续进行，及时发现问题并回归。V模型更适合需求稳定、流程规范、变更较少的项目。如果需求频繁变化，使用V模型容易造成大量返工。

讨论2：如果开发提测延期，测试时间被压缩怎么办？

参考答案：首先要评估影响范围，明确哪些功能是本次改动的核心模块。然后调整测试优先级，先保证核心主流程、高风险模块、本次改动模块和历史Bug较多的模块。对低风险功能可以减少测试深度，但需要在测试报告中说明风险。如果上线风险较高，需要及时反馈给项目经理或产品，推动延期上线或减少上线范围。

讨论3：测试发现严重Bug，但项目马上要上线，怎么办？

参考答案：不能简单说“上线”或“不上线”，要先评估Bug的严重程度、影响范围、出现概率和是否有临时解决方案。如果问题影响支付、订单、资金、数据安全，建议阻塞上线。如果问题影响较小，可以让产品、开发、测试一起评估是否带问题上线，并明确修复时间和应急方案。

讨论4：你们团队的版本发布频率是什么样的？

参考答案：“我们项目是按敏捷迭代推进的，一般两周一个迭代。每个迭代会包含需求评审、用例设计、开发提测、测试执行、缺陷修复、回归测试和版本评审。小版本通常是两周发布一次，主要包含一些新增功能和问题修复。正式版本会根据业务节奏安排，比如一个月发布一次。上线前会做冒烟测试和核心流程回归，重点验证登录、下单、支付、退款这些主流程。”

讨论5：你们团队规模是怎么样的？

参考答案：“我们团队规模不算大，大概8到10个人左右。一般包括1名产品经理、1名项目经理、3到4名开发、1到2名测试，还有1名UI或运维同学按需参与。测试这边主要负责需求评审、测试点拆分、用例设计、测试执行、缺陷跟踪和回归测试。如果涉及接口测试或者数据库校验，也会使用Postman和MySQL辅助验证。”

二、练习

练习1：测试策略制定

题目：公司准备上线一个电商优惠券功能，请制定简单测试策略。功能说明：1.用户可以领取优惠券。2.优惠券有使用门槛。3.优惠券有有效期。4.部分商品不能使用优惠券。5.订单退款后优惠券可能返还。

参考答案：

• 测试范围：1.优惠券领取。2.优惠券使用。3.优惠券过期。4.优惠券限制商品。5.优惠券退款返还。6.优惠券与订单金额计算。
• 测试重点：1.优惠券金额计算是否正确。2.不满足门槛时是否不能使用。3.过期优惠券是否不能使用。4.限制商品是否不能使用。5.退款后优惠券状态是否正确。6.是否存在重复使用优惠券的问题。
• 测试类型：1.功能测试。2.接口测试。3.数据库测试。4.回归测试。5.异常测试。
• 高风险场景：1.优惠券重复使用。2.优惠券金额计算错误。3.退款后优惠券状态错误。4.不符合条件的商品使用了优惠券。5.优惠券和其他活动叠加规则错误。

练习2：风险控制

题目：项目明天上线，但今天测试发现以下问题：1.支付成功后，订单状态偶尔没有更新。2.商品图片在部分浏览器下显示变形。3.后台导出订单Excel时，文件名乱码。4.优惠券退款后没有返还。请判断哪些问题会影响上线，并说明原因。
参考答案：

• 影响上线的问题：1.支付成功后订单状态偶尔没有更新。2.优惠券退款后没有返还。
• 原因：这两个问题涉及订单、支付、资金和用户权益，属于高风险问题，可能直接影响用户交易和售后。
• 可以评估后延后修复的问题：1.商品图片在部分浏览器下显示变形。2.后台导出订单Excel文件名乱码。
• 原因：这两个问题影响体验或后台操作，但不一定影响核心交易流程。是否阻塞上线，需要结合影响范围和业务要求判断。

三、面试回答参考

1. 你们项目用的是什么开发模型？

参考答案：“我们项目主要是敏捷开发模式，一般两周一个迭代。每个迭代会先进行需求评审，然后测试根据需求拆测试点、写测试用例。开发完成后提测，测试先做冒烟测试，主流程通过后再进行详细测试。测试过程中发现Bug会提交到缺陷管理工具里，开发修复后我们再回归。迭代结束前会做版本评审，确认严重问题是否修复、核心流程是否通过，再决定是否发布。”

2. 你们是怎么做需求评审的？

参考答案：“需求评审时，产品会先讲本次需求的背景和业务规则。测试这边主要关注需求是否清楚、异常场景有没有说明、边界条件是否明确、是否影响已有功能。比如优惠券需求，我会重点确认使用门槛、有效期、是否限制商品、是否可以和其他活动叠加、退款后是否返还这些规则。如果需求里没写清楚，会在评审会上提出来，避免后面开发和测试理解不一致。”

3. 开发提测后你怎么开始测试？

参考答案：“开发提测后，我会先看提测说明，确认本次改动范围、影响模块、测试环境和测试数据是否准备好。然后先做冒烟测试，验证主流程能不能走通。如果冒烟测试不通过，比如系统无法登录、订单无法提交，就会先打回开发修复。冒烟通过后，再按照测试用例执行详细测试，包括正常场景、异常场景、边界值和关联模块回归。”

4. 如果测试时间不够，你怎么安排？

参考答案：“如果测试时间被压缩，我会先评估本次改动范围和风险等级。优先测试核心流程、高风险模块、本次改动模块和历史Bug较多的模块。比如电商项目，我会优先保证登录、商品浏览、购物车、下单、支付、退款这些主流程。对于低频功能、页面样式、非核心筛选条件，可以降低优先级。同时我会把未充分测试的范围和可能风险写到测试报告里，让产品、开发和项目负责人一起评估是否可以上线。”

5. 你负责的模块出过什么严重Bug？

参考答案：“之前测试订单取消功能时，发现用户取消未支付订单后，库存没有正确恢复。一开始页面上看不太明显，所以我又查了订单表和库存表。结果发现订单状态已经变成已取消，但库存数量没有加回来。后来开发确认是取消订单时只更新了订单状态，没有调用库存回滚逻辑。修复后，我补充了主动取消、超时取消、支付后退款、多用户抢购等场景，并且重点回归订单状态、库存变化、优惠券返还和积分返还。”