验证的计划篇之三： 计划的实现

一份细致的验证计划会包括详细的项目动向、更新和进度，面对人员总是保持紧张的窘境，只有清晰的计划才能够合理运用人力资源，保证时间和人力的平衡。在上一篇计划的内容中，我们列举出了诸多项目中不稳定的因素，这就使得验证计划需要时常保持更新，给出合理的安排，这样的过程就蕴含着从计划到实践再到反馈，最后再进行计划修改。

计划变更的周期在不断地发生，如下图：

在对设计进行验证以后，我们需要衡量验证的完备性，这时候需要对覆盖率进行分析。当发现覆盖率无法满足要求时，我们需要针对覆盖率漏洞，更改验证计划并且相应添加测试用例，通过这样的反馈环路，我们才可以循序渐进地逼近功能验证的收敛目标。
那么如何制定验证计划呢？通常我们按照如下的步骤：
【1】邀请相关人员参加会议
【2】开会讨论
【3】确定测试场景
【4】创建验证环境

邀请相关人员
通常我们会邀请跟系统设计和功能模块相关的人员到会，共同展开讨论，参加会议的人一般包括：
【1】设计人员
【2】验证人员
【3】硅后测试人员
【4】软件开发人员
【5】系统人员
【6】验证经理（或项目经理）

这些人员在看待如何验证一个模块的问题上面都有着不同的角度，例如系统人员会关注功能描述是否被实现，测试场景是否可以覆盖到这些功能点，设计人员会考虑具体的设计细节是否会被测试到，软件开发人员会关心如何组合硬件的寄存器配置来完成某一项功能的正确配置和使用场景，我们将这些利益相关者对于验证某一个模块给出的不同角度列举如下：

在实际中，我们不一定可以面面俱到同时邀请到这么全的项目角色，而且，我们也要考虑这么多不同的角色一起开会，沟通起来难免存在一些障碍和分歧。所以实际的建议可以变成分阶段进行：
【1】验证经理、设计人员和验证人员开会，确定大致需要验证的功能点、进度和人力安排。
【2】系统人员、设计人员和验证人员沟通对于功能描述文档存在歧义的地方，确定理解一致。
【3】设计人员、验证人员、轨后测试人员和软件人员在最后来为实际软件配置的场景添加测试用例，将软件配置添加到硅前验证阶段。

开会讨论
在开会讨论前，作为会议的组织者，需要搞清楚开会的目的和议题分别是什么？
【1】验证计划的内容组成
【2】需要确定的验证功能点

在开会之前，我们需要一份合适的验证计划的模板用来指导我们在会议上讨论的主要内容，一份验证计划的模板（或者组织结构）可以像下面这样：
【1】设计功能描述
【2】硬件实现框图
【3】待验证的功能点
【4】验证环境搭建
【5】测试用例构成
【6】编译脚本和递归测试
【7】覆盖率分析

创建验证环境
在确定了测试场景和验证方法以后，我们构建验证环境产生激励来实现场景。那么我们需要针对设计模块的接口信号设计对应的激励发生组件，通过控制协调不同的激励组件来构建场景。在实现激励发生组件中，我们需要考虑接口信号是否是标准总线或者是系统控制信号例如时钟、复位，如果有可以复用的验证资源，那么毫无疑问会节省我们的时间。在有些时候，如果接口是标准总线，且没有现有资源可以利用的情况下，我们需要自己实现，那么从成本的角度来看，只需要实现设计中所实现的总线功能即可。例如，如果设计实现的是AHB总线协议，但是只支持单次的读写访问，那么我们在实现AHB激励组件的时候，也不必要实现AHB协议的全部，而只需要实现单次读写协议，满足设计接口的协议要求即可。

同时，我们也需要考虑收集数据和检查对比结果，这就需要有监视信号组件和检查组件的实现。监视信号组件的主要任务就是监视设计的接口信号以及内部信号，如果是总线接口，那么需要在解析总线的情况下将观察到的数据打包整理，如果是控制或者其它信号，也需要按照信号的使能定义，在特定的事件下捕捉有效信号。监视信号组件最终会将分析整理好的数据发送给检查组件，最后由检查组件进行数据比较，给出比较信息和报告，最终判定该次测试是否成功。

参考博客：

【1】http://blog.eetop.cn/blog-1561828-513658.html