可量化的交付内容

定义问题：目前的研发流程中，没有可量化可评价的交付内容

  1. PRD、系分、测分、发布计划：难以标准化
  2. QA的测试流程，目前大部分手工维护
    1. 测试环境不稳定
    2. 测试数据不稳定
  3. 发布计划（事后，有点滞后）
    1. 核对：核对质量一般（需要和测试确认）
    2. 监控：没有标准化的监控策略

—— 剩下的相对可自动化可掌控的的就是开发自己维护的单元测试了
一个需求有哪些Case是明确

Pros and Cons

写高质量的测试用例需要成本，看看单元测试相对于集成测试的有点

优点 缺点
可衡量的质量交付
1. 系分时候出完成的Case
1. 开发、测试、风险评估人，越早接入评估Case，case能够越完整
2. 开发阶段，覆盖系分所有的Case
1. 测试驱动开发（推荐，但不强求）
 对于开发的成本较高：
1. 集成测试启动环境慢
1. yaml文件维护：眼瞎
2. Spock 写测试代码有成本
1. 入门门槛
2. 维护成本
1. 质量高的单测，代码量一定多，接受维护很痛苦


开发评估时间需要拉成，但能缩短测试的时间
自动化测试：磨刀不误砍柴工
1. 确保了开发交付质量，降低测试同学负担
2. 重构之后，先跑单测，能够把重构质量保持在高位
3. 测试提bug，先补单测，持续更新自动化测试用例
风险发现前移：
开发过程中尽早发现交付问题，而不是等提测之后

image.png