授权转载自：公众号“萌新来啦”
不知道在验证中煎熬数年的你有没有遇到以下场景：
- 设计怎么又改设计方案了，我这环境刚改完啊
- 什么，这个功能不要了，为了它验证环境可是改了好多啊
- 喂喂喂，你怎么不早说啊，我还以为我们的主要功能是xxx
- 下个月TO，是在开玩笑吧，还有这么一堆case要做，项目经理是xx吧
- 大哥求求你不要加功能了，再加环境只能重写了
- 经历过N遍验证环境出同一个问题后，设计终于忍不住了把验证打了一顿
- 大哥您别改了，regression很慢的
- 这个问题都找了一个星期了，啥时候才知道问题发生在哪啊
上面的场景可以总结为以下几条：
- 花了大功夫做的环境最后却不用了，导致进度又变成初始阶段。 不停的在改环境使得应该进行的测试迟迟不能开始，影响了速度。
- 验证环境越到后期越改不动 面向对象的一些设计原则、设计模式都对进行可复用性的设计有较大的指导意义 在过程中不断的重构也可以降低代码熵增的速度
- 任何设计的变化都需要经历长时间的regression 验证分层、分治是一个比较有效的手段
- 无法保证验证的正确性，尤其是遇到大量修改时，需要花费较多时间来确认到底是验证还是设计的问题 利用完善的ut验证验证的正确性
- soc debug缓慢 复用下层模块的验证环境作为当前环境的内部check，加快问题定位
基于上面遇到的问题，结合敏捷针对VUCA的改善措施，将验证分为三大流程、四个阶段、四个评审里程碑、六大验证过程。如下图：
启动阶段
- 通过需求收集与分析，并根据历史总结checklist形成初步验证plan。 checklist越完善越能避免一些小事故的发生，有的时候一个reset验证不充分也会出现大问题。 checklist有利于经验的总结与传承，帮助牛人避免小错误，帮助新手发现大问题
- 启动阶段需要完成原型设计。 不可综合的架构性原型验证设计并不需要花费太多时间，部分也可以通过参数化类、脚本生成实现，快速达到验证想法是否可行的目的 为后续以case为基础的端到端交付提供基础环境，保证任务的顺利进行
- plan以case为基础，将覆盖率等验收标准绑定到case上，并进行初步的优先级划分。 case作为载体会比覆盖率等有更强的端到端的价值，可以防止前期花费过多时间在环境建立上而没有给出应当的反馈。 针对case较容易进行优先级的划分。
- 验证架构设计方面要做到向上可复用、向下可集成。 向上复用作用是当组成soc、subsystem的模块较多，debug难度比较大，可以使用下层的验证环境进行对应模块的check，达到更快的缩小出错范围的目的，在做底层模块时需要想到上层怎么可以更方便的使用，通过增加一些底层工作量达到降低复用工作量的目的 向上复用另一方面是进行interface agent的全局复用 向下集成是希望尽可能多的寻找可复用单元，不断分层，降低验证的复杂度，提升可靠性（模块过于复杂很容易想不清楚）
迭代阶段
- 定义迭代时间盒，假设2周
- 以优先级和价值点作为评判标准从已有plan中选取2周可以完成的case
- 进行case拆解，并将工作量精确到天，组内进行任务分配
- 确认当前环境是否可以较顺利的支持功能添加，如果不可以进行重构 重构需要以ut作为验证的保证，保证修改不会引入新的问题 满足oop设计原则、设计模式是提高可否复用性的重要手段
- 时间盒结束，case验收 通过之前定义的验收标准查看对应case是否通过 单个case的覆盖率会比整体覆盖率更精准，减少整体覆盖率互相交叉覆盖引起的功能没问题的错觉
- 回顾 发扬优秀做法 改进不足
- 如果有特别紧急任务或者特别重大的改变，可以打断当前迭代
收敛阶段
当plan中的case完成的差不多了，或者剩余的重要性很低时收敛阶段
- 覆盖率定向收敛
- 长时间的无目标随机 视机器资源、人力资源情况而定
收尾阶段
当项目完成或者被强制停止时进入收尾阶段
- 总结
- 资料整理存档
- 满意度调查
评审milestone
在进展过程中，有四次较大规模的评审，以进行团队级别的目标对齐milestone评审需将需要的点包括不仅限于plan、验证架构等进行详细评审以保证方向正确性。
新需求加入
- 启动阶段后的新需求加入，需要经过评审后加入plan，并在下次迭代参与任务选取
- 如果新需求对验证架构影响较大，需拿出专门时间以ut为基础进行大规模重构
