需求评审时，如何让开发主动说“这个用例写得好”？
为什么总在提测后才暴露需求漏洞？为什么开发总觉得测试用例脱离实际？
——测试左移的瓶颈，往往卡在‘用例协作’环节。
本文分享3套经过BAT验证的实战方法，让开发从被动审查变为主动设计用例。”
一、需求反讲工作坊：把模糊需求变成可测用例
场景：产品PRD描述“支持用户批量导入数据”
❌ 传统做法：测试按文档写用例 → 开发实现时发现歧义
✅ 左移方案：
会前准备
[*]测试人员根据PRD 预先起草核心用例（例：验证10万行CSV导入是否触发内存溢出）
[*]使用 PlantUML生成流程图 标注风险点（附代码块）
@startuml start :上传文件; if (文件>10MB?) then (yes) :返回错误提示; else (no) :解析数据; fork :校验格式; fork again :写入数据库; end fork endif @enduml会议引导技巧
[*]开发讲解实现方案时，用测试用例反向提问：
“如果用户上传含特殊字符的CSV，你设计的解析模块会如何处理？”
[*]即时将共识更新为 Gherkin语法用例（例）：
Scenario: 上传含特殊字符的CSV Given 用户选择"工资表.csv" When 文件包含"薪资@2024"等特殊字符 Then 系统应过滤特殊字符并显示"已成功导入980条"效果：需求会耗时增加15%，但减少后期60%的歧义BUG
二、单元测试埋点工具链：让用例成为代码的一部分
问题：开发认为“写测试耽误工期”
✅ 解决方案：
在CI流水线植入自动化检查
[*]使用 Jacoco+SonarQube 设置门禁规则：
# 单元测试覆盖率
页:
[1]