从用例设计到缺陷复盘，一次讲透（二）

二、测试工作流可以拆成 8 个高频 Skills测试从业者真正高频使用的 Skills，不应该是花里胡哨的工具，而应该围绕真实工作链路来设计。一条完整的测试链路，大致可以拆成：一、需求澄清 Skill：别一上来就写用例很多测试同学拿到需求后，第一反应就是写测试用例。但真正有经验的测试工程师，会先问三个问题：这个需求到底解决什么业务问题？ 哪些规则是明确的，哪些规则是模糊的？ 哪些地方一旦理解错，后面测试一定会漏？所以第一个 Skill，不是用例生成，而是需求澄清。适用场景产品文档写得很粗； 需求评审时没人说清楚异常规则； 研发已经开始做了，测试才发现规则缺失； 面试被问“你如何参与需求评审”。推荐触发词使用需求澄清 Skill，帮我分析下面这个需求，找出测试前必须确认的问题。 输入示例需求：用户下单时可以使用优惠券。优惠券分为满减券、折扣券和新人券。每个订单最多使用一张优惠券，支付成功后优惠券状态变为已使用。 输出应该包含什么一个合格的需求澄清 Skill，不应该只总结需求，而应该输出这些内容：示例输出针对优惠券需求，它应该能帮你问出这些问题：满减券和折扣券是否互斥？ 新人券是否只能使用一次？ 优惠券过期后，已锁定但未支付的订单如何处理？ 支付失败后，优惠券是否释放？ 订单取消后，优惠券是否退回？ 部分退款时，优惠券是否退回？ 多端同时提交订单时，优惠券是否会被重复使用？这些问题如果不提前问，后面很容易变成缺陷。踩坑提醒很多测试同学用 AI 分析需求，只让它“总结需求”。这没什么价值。测试从业者真正需要的是：把模糊需求提前暴露出来。所以这个 Skill 的核心不是“总结”，而是“质疑”。二、用例分层 Skill：把“测全”拆成可执行结构很多测试工程师说自己会写用例，但一看用例表就知道经验深浅。常见问题有三个：只覆盖正常流程； 异常场景靠临场发挥； 边界值想起来一个写一个。这种用例不是不能用，而是不稳定。真正可复用的用例设计，应该先分层。推荐分层方式适用场景新功能测试用例设计； 面试现场设计测试用例； 新人写用例前的辅助检查； 测试负责人 Review 用例覆盖度。推荐触发词使用用例分层 Skill，基于下面需求，按核心流程、异常流程、边界场景、组合场景输出测试用例。