需求评审时，如何让开发主动说“这个用例写得好”？

为什么总在提测后才暴露需求漏洞？

为什么开发总觉得测试用例脱离实际？

——测试左移的瓶颈，往往卡在‘用例协作’环节。

 

本文分享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 设置门禁规则：

# 单元测试覆盖率<80%则阻塞构建  mvn verify -Dsonar.coverage.exclusions='**/test/**'              -Dsonar.qualitygate.wait=true

  

提供可复用的测试脚手架

• 创建 测试工具包 降低用例编写成本（例）：

// DatabaseTestUtils.java  public class DBValidator {    public static void assertRecordCount(String table, int expected) {      try (Connection conn = DataSource.getConnection()) {        ResultSet rs = conn.createStatement().executeQuery("SELECT COUNT(*) FROM " + table);        assertEquals(expected, rs.getInt(1)); // 自动回滚事务      }     }  }

  

用数据证明价值

• 统计报告：采用该流程的项目，生产环境缺陷率下降44%

三、缺陷预防核对单（DPC）：将用例转化为开发自查表

案例：某金融项目上线后出现金额四舍五入错误
✅ 建立机制：

1. 根据历史缺陷生成领域专用核对单

   模块	检查项	测试用例示例
   支付计算	涉及金额计算是否使用BigDecimal	验证0.1+0.2=0.3
   API接口	是否定义明确的HTTP状态码	输入非法参数应返回400而非500

2. 与开发共建知识库

• 使用 Confluence+Jira 关联：

[DEV] 提交代码 → 触发核对单检查 → [QA] 评审通过 → 关闭工单  

1. 推行奖励制度

• 开发每通过DPC拦截1个缺陷，奖励团队积分（可兑换技术书籍）

避坑指南：测试左移的3个“死亡陷阱”

1. ❌ 强推流程 → ✅ 先在小团队验证ROI（例：减少返工工时×时薪=节省成本）

2. ❌ 追求100%用例覆盖 → ✅ 优先覆盖核心资损场景（参考FMEA分析法）

3. ❌ 测试人员只做“传话者” → ✅ 培养测试工程师的架构阅读能力（推荐书单：《软件架构：Python实现》）

最后

测试左移的本质，是将质量意识编码进软件生命周期的DNA。当开发开始主动思考这个逻辑该怎么测，团队离持续交付高质量产品就不远了。

本文原创于【程序员二黑】公众号，转载请注明出处！

 

欢迎大家关注笔者的公众号：程序员二黑，专注于软件测试干活分享，全套测试资源可免费分享！

最后如果你想学习自动化测试，欢迎加入笔者的交流群：785128166，里面会有很多资源和大佬答疑解惑，我们一起交流一起学习！