加速收敛_单元测试加速覆盖率收敛方法

声明：该结论为公司内实践结果，对内部的许多框架有依赖，如果希望有更深入的了解，淳中科技欢迎您

个人理解验证工程师在一个项目上的一般工作流程为制定验证计划->搭建验证环境->编写验证case->运行case->收集覆盖率->其它动作，在这套惯用工作流程中有几点是一直困扰自己的。

• 如果function coverage写的有问题，那么什么时候问题才会表现出来

• 如果function coverage写的有问题，针对表现出来的问题怎么修改，如何判定修改的是正确定

• 如何降低完成100%覆盖率需要的case数量

当然有人会说可以通过regression实现收集，对于机器资源丰富的公司来说这些都还好，对于机器资源不丰富的10000个case的运行时间可能是几天，这就使得regression的代价急剧增高，而变得没有可行性。且任何transaction的修改又需要重复该动作，再加上在如此多的regression中，对覆盖率增长有贡献的case数量占比不到30%，浪费极其严重。

鉴于上面的问题，通过实践总结，发现一个使用单元测试来加速上述过程的方案

• 单元测试中只添加transaction和coverage，通过不断循环实现100%功能覆盖率收集

• 通过100%功能覆盖率收集寻找对覆盖率增长有效的配置，并将配置导出xml，用于实际case的配置

通过上述方案得到的效果

• 可以在前期通过快速验证，评估transaction和coverage的有效性，为后期coverage作为验收标准提供了有效保障，减少了在后期因为coverage变化与不合理带来的时间浪费

• 速度快，对于快速迭代分析提供了保证，且对变化的应对能力有所提高

• 通过配置的生成，保证在transaction和coverage不发生变化的情况下，需要运行用于功能覆盖率100%的case是稳定的

当然有人会说很多随机case也是需要跑的，个人将这部分case划分到探索性验证中，不同阶段、不同情境需要做不同的事情，一个稳定的最小解对增效是有帮助的。

个人认为只有当验证过程被划分为有效且相互验证的子集，才能找到效率优化的方法，提高合作的有效性，降低验证学习曲线的陡峭程度，用更快得到的成就感驱动进一步的学习。