日志
验证的计划篇之三： 计划的实现
| ||
一份细致的验证计划会包括详细的项目动向、更新和进度，面对人员总是保持紧张的窘境，只有清晰的计划才能够合理运用人力资源，保证时间和人力的平衡。在上一篇计划的内容中，我们列举出了诸多项目中不稳定的因素，这就使得验证计划需要时常保持更新，给出合理的安排，这样的过程就蕴含着从计划到实践再到反馈，最后再进行计划修改。
计划变更的周期在不断地发生，如下图：
在对设计进行验证以后，我们需要衡量验证的完备性，这时候需要对覆盖率进行分析。当发现覆盖率无法满足要求时，我们需要针对覆盖率漏洞，更改验证计划并且相应添加测试用例，通过这样的反馈环路，我们才可以循序渐进地逼近功能验证的收敛目标。
那么如何制定验证计划呢？通常我们按照如下的步骤：
- 邀请相关人员参加会议
- 开会讨论
- 确定测试场景
- 创建验证环境
邀请相关人员
通常我们会邀请跟系统设计和功能模块相关的人员到会，共同展开讨论，参加会议的人一般包括：
- 设计人员
- 验证人员
- 硅后测试人员
- 软件开发人员
- 系统人员
- 验证经理（或项目经理）
这些人员在看待如何验证一个模块的问题上面都有着不同的角度，例如系统人员会关注功能描述是否被实现，测试场景是否可以覆盖到这些功能点，设计人员会考虑具体的设计细节是否会被测试到，软件开发人员会关心如何组合硬件的寄存器配置来完成某一项功能的正确配置和使用场景，我们将这些利益相关者对于验证某一个模块给出的不同角度列举如下：
在实际中，我们不一定可以面面俱到同时邀请到这么全的项目角色，而且，我们也要考虑这么多不同的角色一起开会，沟通起来难免存在一些障碍和分歧。所以实际的建议可以变成分阶段进行：
- 验证经理、设计人员和验证人员开会，确定大致需要验证的功能点、进度和人力安排。
- 系统人员、设计人员和验证人员沟通对于功能描述文档存在歧义的地方，确定理解一致。
- 设计人员、验证人员、轨后测试人员和软件人员在最后来为实际软件配置的场景添加测试用例，将软件配置添加到硅前验证阶段。
开会讨论
在开会讨论前，作为会议的组织者，需要搞清楚开会的目的和议题分别是什么？
- 验证计划的内容组成
- 需要确定的验证功能点
在开会之前，我们需要一份合适的验证计划的模板用来指导我们在会议上讨论的主要内容，一份验证计划的模板（或者组织结构）可以像下面这样：
- 设计功能描述
- 硬件实现框图
- 待验证的功能点
- 验证环境搭建
- 测试用例构成
- 编译脚本和递归测试
- 覆盖率分析
在上面这样的计划模板中，我们开会前需要了解的是功能描述和硬件实现方案，在开会中只需要讨论和确定哪些功能点是要验证的，而哪些事不需要验证的，至于验证环境搭建和测试用例构成则是验证工作展开以后需要更新到计划中去的。
面对着不同背景的项目人员，我们在会议中需要注意几个方面，使得会议最终可以达成我们想要的结果。这些值得注意的地方包括有：
- 由于与会人员本身具有不同的背景，在讨论中遇到分歧，试着从对方的角度看待这个问题，给予理解。
- 需要覆盖设计在实际过程中软件的使用情况和在系统中的角色扮演，探明真实运用场景。
- 弄明白哪些功能是基本核心功能，哪些功能是次要功能。
- 确定所有需要验证的功能点，以及声明哪些功能点不需要验证和哪些场景是伪场景（即不实际的运用）。
通过和不同系统层次的人沟通，充分交流不同层面上的观点，我们对于验证的功能点和它们在系统运用中的角色认识才会更加清晰。
确定测试场景
经过了细致的讨论，我们就可以确定下来哪些功能点需要测试，进而模拟实际场景给出激励进而生成测试场景。在考虑如何生成测试场景的时候，我们需要注意思考下面几个地方：
- 针对某些功能点，我们如何给出特定的测试场景。这些场景是否同实际情况一致或者类似，比如我们给出的时钟信号频率是否同设计要求的频率一致，不同时钟之间的同步异步关系是否参照系统要求。
- 需要测试的场景，会需要待验设计的哪些功能模块参与。这种情况一般在模块级测试中，往往需要较多的子模块参与进来，而随着测试的层次升高，我们需要唤醒使能的模块数量就逐渐减少了。一旦在心中有了这个习惯，这就方便与我们在构建测试用例前，大脑已经模拟出完成整个功能的序列，懂得参与进来的模块，以及如何配置寄存器、等待某些状态信号完成下一步功能设置，直到最后完成整个复杂功能的测试。
- 一些场景如果跟电源开关有关，我们需要考虑是否需要在PA（Power Aware）场景中完成测试。
- 一些场景如果跟性能有关，我们需要考虑如何发送大规模的数据量实现压力数据传输场景。
- 针对不同的功能点，我们需要考虑选择合适的验证层次，以及对应的验证方法，进而考虑怎么在验证环境中做好准备。
创建验证环境
在确定了测试场景和验证方法以后，我们构建验证环境产生激励来实现场景。那么我们需要针对设计模块的接口信号设计对应的激励发生组件，通过控制协调不同的激励组件来构建场景。在实现激励发生组件中，我们需要考虑接口信号是否是标准总线或者是系统控制信号例如时钟、复位，如果有可以复用的验证资源，那么毫无疑问会节省我们的时间。在有些时候，如果接口是标准总线，且没有现有资源可以利用的情况下，我们需要自己实现，那么从成本的角度来看，只需要实现设计中所实现的总线功能即可。例如，如果设计实现的是AHB总线协议，但是只支持单次的读写访问，那么我们在实现AHB激励组件的时候，也不必要实现AHB协议的全部，而只需要实现单次读写协议，满足设计接口的协议要求即可。
同时，我们也需要考虑收集数据和检查对比结果，这就需要有监视信号组件和检查组件的实现。监视信号组件的主要任务就是监视设计的接口信号以及内部信号，如果是总线接口，那么需要在解析总线的情况下将观察到的数据打包整理，如果是控制或者其它信号，也需要按照信号的使能定义，在特定的事件下捕捉有效信号。监视信号组件最终会将分析整理好的数据发送给检查组件，最后由检查组件进行数据比较，给出比较信息和报告，最终判定该次测试是否成功。
通过了解如何准备计划到计划的内容结构，再到创建环境和测试场景，我们就开始步入了验证日常工作的轨道。下一篇我们将讨论如何衡量验证的完备性《计划的进程评估》，感谢你对路科验证的关注。
/2 
eetop公众号
创芯大讲堂
创芯人才网