声明:该结论为公司内实践结果,对内部的许多框架有依赖,如果希望有更深入的了解,淳中科技欢迎您
个人理解验证工程师在一个项目上的一般工作流程为制定验证计划->搭建验证环境->编写验证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划分到探索性验证中,不同阶段、不同情境需要做不同的事情,一个稳定的最小解对增效是有帮助的。
个人认为只有当验证过程被划分为有效且相互验证的子集,才能找到效率优化的方法,提高合作的有效性,降低验证学习曲线的陡峭程度,用更快得到的成就感驱动进一步的学习。