“测试同学要求我们产品写用例，然后你们照着测？”
当看到产品经理发送的这条消息时，作为测试 Leader，心里五味杂陈：
一方面是被误解的无奈——测试的价值不是简单执行用例；
另一方面是思考如何用沟通和流程，让产品明白：我们不是推责任，而是在保障产品质量、覆盖风险。
职场里的经典冲突
真实场景是这样：
- 产品经理 A：交付需求文档，认为测试应该独立覆盖所有业务
- 测试 Leader B：发现流程复杂、边界条件多，希望产品提供用例参考
- 产品经理 A：困惑，“你们不是专业测试吗？为什么还要我们写用例？”
冲突点：
- 产品认为测试可以独立覆盖业务全景
- 测试希望借助产品的业务经验降低漏测风险
这不是能力问题，而是职责边界和沟通方式不清晰。
为什么测试需要产品用例参考
测试用例不是“作业”，它是保证产品质量的工具：
- 业务复杂：权限、状态、流程组合多，容易遗漏
- 边界条件多：异常流程和负面场景通常文档里没有
- 风险控制：用例参考帮助快速锁定核心功能和高风险点
核心原则：参考用例只是辅助，核心判断和负面测试设计仍由测试主导。
测试 Leader 的应对策略
明确用例参考定位
- ✅ 辅助理解业务流程，不是替测试写作业
- ✅ 产品提供流程和核心场景，测试负责全覆盖
- ❌ 不把全部责任推给产品
建立共创机制
- 产品提供核心场景
- 测试设计用例，覆盖边界和异常
- 产品参与用例评审，理解覆盖范围和风险
可视化管理
- 用表格、mindmap 或 mermaid 流程图标记核心场景、边界条件、风险点
- 清晰展示“产品提供参考用例 vs 测试全覆盖”的边界
高效测试方法
- 边界拆解法：将产品流程拆解为正向、负向、异常用例
- 风险优先法：先测高风险核心流程，再扩展低风险边缘场景
- 自动化 + 探索测试结合：核心流程自动化覆盖，边界/异常用探索测试发现问题
记录每次用例参考与实际测试差异，形成业务知识库，减少下次迭代对产品依赖。
写在最后
产品经理问：“测试同学要求我们写用例，然后你们照着测？”
这句话反映了对测试职责的误解。
测试工程师的价值不在于简单执行用例，而在于 保证质量、覆盖风险、优化产品。
科学借力产品用例参考、共创流程、可视化管理，你的测试不仅高效，还能成为产品质量守护者。
推荐阅读
软件测试/测试开发丨Pytest测试用例生命周期管理-Fixture
软件测试/测试开发丨Python学习笔记之基本数据类型与操作
