●黑盒验证
● 白盒验证
● 灰盒验证
接下来，我们逐个解释这三种不同透明度的验证特征。
黑盒验证
如果验证人员对于设计的细节缺乏认识，那么黑盒验证是一种合适的方式。因为验证环境只需要将激励给入设计的外部接口，而检查设计的另一侧输出就够了。而测试的成功与否只是根据一个输入是否得到一个正确的输出，验证环境本身不会关注设计的内部。
从上面这张图可以看到，激励生成器（stimulator）只负责给设计灌入激励，监视器（monitor）和检查器（checker）也只查看和比较输出信号。
黑盒验证的一个缺点是它缺少设计的透明度和激励的可控度，而由此带来的一些问题包括：
1.当测试失败以后，无法更深层次地定位问题。对于验证人员而言，他只能判断是测试是否成功，但无法将报告进一步定位到缺陷所在的位置，与设计人员完成深度协作。当一些设计的接口采用标准接口时，图中的激励生成器或者总线功能模型可以使用复用性高的验证IP。这些验证IP一般由第三方公司提供，有时候公司内部也有这样的IP，它们的特点是像标准接口一样易于在验证环境中插拔，易于控制且接口时序严格按照总线文档定义。同时对于监测器而言，它也来自于验证IP，这也减少了验证人员的工作量。所以当模块的接口标准化时，验证环境也可以复用一些验证IP。
2.这种方式对于发现一些较深的缺陷比较困难，因为验证人员无法根据设计本身给出更窄的随机约束来定向生成一些激励。同时，这也对设计内部功能点的功能覆盖率收敛没有太多的帮助。
由于黑盒验证本身不包含设计的内部逻辑信息，所以当设计由于缺陷做了更新或者添加新的特性之后，原有的测试列表仍然较稳定，验证人员只需要对新添加的特性考虑新的测试场景。黑盒验证有利于保持测试环境的稳定，在后续项目中一旦更新了设计，新的验证人员也只需要很少的力气来维护继承的验证环境。
白盒验证
相比黑盒验证，白盒验证可以弥补一些不足。由于验证人员了解设计的内部工作逻辑、层次、信号等，他就可以对更底层的设计细节进行测试。由于对于设计中各种组件和逻辑细节都了如指掌，这种验证方式可以验证设计是否更严格地遵循功能描述文档，而且一旦测试发生失败也可以更快速地定位到缺陷。
对于白盒验证的环境，我们的参考模型逻辑非常简略，甚至不需要参考模型，而只需要植入监视器和断言来检查各个内部逻辑。这种环境配置背后的原则是说，当我们充分检查各个逻辑驱动和结构以后，就不需要测试它的整体功能，因为白盒验证是穷举逻辑路径的方法。
使用白盒验证也面临一些方法学上的缺陷：
1.由于本身专注于设计内部逻辑检查而忽略整体功能的测试，在设计本身违反规范的情况下，白盒验证难以发现缺陷。灰盒验证
2.在数据一致性检查的方面，白盒验证难以从整体入手给出实际测试用例。
3.由于白盒验证的测试用例很多都是从设计的细节入手，所以一旦设计发生更新，那么对于验证环境的维护成本就偏高。这一点在项目间复用方面带来的影响更多，甚至新接手验证环境的人要付出很大的成本去理解设计细节和验证环境的细节。这时候白盒验证环境的低复用性缺点就暴露出来了。
从黑盒验证和白盒验证来看，他们各自都有着优势和劣势。在实际验证中，我们更倾向于将黑盒和白盒两种方法掺杂在一起，让监视器、断言、参考模型一同来完善验证。这种糅合的方式带来的好处包括：
1.监视器和断言可以有着更好的透明度来着重检查设计的一些重要内部逻辑。
2.参考模型由于已经有了断言检查局部逻辑的帮助，会减少很大一部分精确度，而主要专注在输入和输出的数据比较上。
而从复用性角度考虑，灰盒验证也有着灵活地变动方式：
1.对于新的设计，我们的验证人员需要更深入地理解设计本身，而采用灰盒验证一开始通过监视器和断言来进行局部验证。待设计初步完善和趋向稳定时，验证人员此时也有了对设计更全局的理解来构建参考模型。又因为前期监视器和断言保证局部逻辑的正确，那么参考模型的构建不需要完全精确，只需要较少的精力来实现。
2.如果该设计移植到别的项目，尽管难免设计需要进行局部修改，对于验证环境而言，灰盒验证的复用性优势就体现出来了。即便是新的验证人员接手这个验证环境，好的灰盒环境也可以清晰地将黑盒和白盒的部分划分开来。在设计本身复用的项目中，我们首先建议打开黑盒开关，这对于新的验证人员来讲是较低的测试成本，也无需对设计和验证环境了解太多。同时，这么做也可以第一时间保证原有功能的稳定性，并反馈给设计人员新的改动造成的影响。紧接着，应该验证人员可以针对新的特性创建特定的黑盒测试序列，由于设计本身的稳定，新的黑盒测试序列不需要关注与设计内部太多。
当黑盒环节进行完毕以后，我们可以在时间允许的情况下，有序引入白盒的开关。首先，我们应该考虑先创建新的白盒断言点或者是功能检查点，来专注在新的功能部分。其次，在完成了新的功能点白盒覆盖以后，我们再考虑逐个打开原有的白盒功能检查开关，逐次打开白盒检查开关的方式我们也遵循着每次添加尽可能少的开关来跑递归测试，这便于发现问题以后可以快速定位到新打开的开关一侧；并且，白盒检查点的开关也有逻辑重要性的优先级，如果之前验证人员足够专业的话，在他的代码或者文档中也应该对这些不同白盒开关给出说明和重要性的排列，这种说明会有助于新的验证人员先开高优先级的开关，而依次按照优先级的降序来打开不同的开关。
所以灰盒验证不但可以继承黑盒验证和白盒验证的优势，同时也对于验证环境在新项目中的复用有着明显优势。
最后，我们列出一个信息比较表来量化总结黑盒验证、白盒验证和灰盒验证的特点。从上面的语言描述和下面列表的归纳我们可以一致得出，灰盒验证方式可以最好平衡新设计验证和稳定设计验证复用的工作量。如果在新设计验证阶段，验证人员有着充分的经验来实现灰盒验证环境，将黑盒部分和白盒部分清晰划分，考虑到日后其它验证人员的接手和环境复用，那么这样的稳定设计伴随着复用性高的环境，在今后更多的项目中也能证明该设计包的复用度。在高度集成化的今天，我们衡量一个设计复用性的优良，是从整个设计交付包（design delivery package）衡量的，这包括了我们之前提到过的设计包、验证包、文档包、递归测试包和覆盖率包等等。
所以无论对于设计人员还是验证人员也都需要从各自的角度考虑复用性，将设计的整个流程全盘考虑，也只有可以让使用设计交付包的项目可以有更好的“用户体验”，缩短集成时间（设计和验证），才是好的设计和验证环境。
来源：Robei
/3 
