写在前面：原书中包含白盒测试、黑盒测试、错误猜测、测试策略四个小节，涵盖内容较多，因此按章节拆分叙述。
《软件测试的艺术》：
-
白盒测试--语句覆盖
语句覆盖的用例设计原则：将程序中的每条语句至少执行一次。
-
白盒测试--判定覆盖
判定覆盖的用例设计原则：使得每一个判断都至少有一个为真和为假的输出结果。换句话说，也就是每条分支路径都必须至少遍历一次。
-
白盒测试--条件覆盖
条件覆盖的用例设计原则：确保将一个判断中的每个条件的所有可能的结果至少执行一次。
-
白盒测试--判定/条件覆盖
判定/条件覆盖的用例设计原则：将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。
-
白盒测试--多重条件覆盖
多重条件覆盖的用例设计原则：将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。
-
覆盖准则的强度
语句覆盖<判定覆盖<条件覆盖<判定/条件覆盖<多重条件覆盖
为了理解上述不同覆盖原则的区别，使用下面的例子加以说明。
对于上述的例子，不同覆盖原则的用例设计可以描述为：
语句覆盖：
节点1~5都需要至少执行一次；
判定覆盖：
节点3的if()语句Yes和No的结果都需要至少执行一次；
条件覆盖：
节点3的if条件中，b>a和b<=a，a==3和a!=3都需要至少执行一次；
判定/条件覆盖：
节点3的if条件中，b>a和b<=a，a==3和a!=3都需要至少执行一次；节点4和5至少执行一次；
多重条件覆盖：
把节点3的if条件中的每个判断和整个if语句Yes/No结果进行组合:
(1) b>a，a==3，执行节点4；
(2) b<=a，a==3，执行节点5；
(3) b<=a，a!=3，执行节点5；
(4) b>a，a!=3，执行节点5；
总的来说，判定覆盖需要保证每个分支都要执行一次，条件覆盖需要把判断条件中的每个逻辑判断条件为真和假执行一次。
《验证芯发现》：
-
芯片验证中的随机测试
《软件测试的艺术》本章节之初，提出如下的观点：一般而言，在所有的方法中效率最低的是随机输入测试，即在所有可能的输入值中随机选取某个子集来对程序进行测试的过程。就发现最多错误的可能性而言，随机选取而产生的测试用例集很少有可能是理想的或接近理想的子集。
对于上述的观点，笔者很是赞同。首先不能否认芯片随机用例验证的重要性，随机测试能够通过大量的随机，发现很多RTL的代码问题，包括一些极限边界的corner。一些边界corner通过正向的分析很难预见。而且通过随机验证，可以较快达到验证覆盖率收敛，这也正是芯片验证中CDV的魅力所在。
来自：《SystemVerilog验证 测试平台编写指南》
但不能仅仅依靠随机用例验证，会有"偷懒"的嫌疑。随机验证在解决一些非边界corner的组合覆盖场景，具有较大的优势。在应对某些边界场景的覆盖时，依靠不受约束的完全随机则需要大量的随机用例数量，此时则需要验证人员构造一些定向随机用例，可以加快场景的覆盖，节省验证成本。
-
芯片验证中的白盒测试
芯片验证也会存在所谓的白盒验证，但芯片里的"白盒"级别验证，一般来说，并不会通过分析RTL代码的逻辑路径来正向构造用例，至少在验证前中期不会。RTL代码的白盒路径，对验证人员的作用是通过灰盒式的CDV流程体现出来，可以参见下图。
一般我们会根据模块的业务功能和约束构造黑盒用例，通过随机回归验证，进行覆盖率收集。其中在覆盖率收集和确认时，会体现RTL代码的“白盒逻辑路径”，比如芯片验证的代码覆盖率有：代码行覆盖率（line coverage）；条件覆盖率（condition coverage）；跳转覆盖率（toggle coverage）；分支/路径覆盖率（branch coverage）；状态机覆盖率（FSM coverage）。其中代码行覆盖率、条件覆盖率以及分支覆盖率则可以认为和软件测试中的判定覆盖和条件覆盖类似。比如synopsis工具的分支覆盖率如下所示：
参考：https://zhuanlan.zhihu.com/p/240126362
覆盖率分析中，如果发现某些条件分支没有被覆盖，则需要进行用例增补。在实际的芯片模块中，其中的一条分支或条件，往往并不是直接映射到模块的输入。此时则需要设计验证人员一起（代码覆盖率应该由设计人员确认，还是验证人员，后续可以单独介绍讨论），分析当前未覆盖的逻辑路径对应的业务或者时序场景，进而构造对应的定向随机用例。
如果上述的这种白盒逻辑路径和业务时序场景的映射非常复杂时，增补一条“白盒”用例，准确的说应该是增补一类“白盒用例”后，并不能保证一定能够覆盖当前的逻辑路径，但可以提高覆盖的概率，再对该条定向随机用例，加以大量随机回归测试，可以大大提高验证覆盖率。需要注意的是本节提到的覆盖率是指代码覆盖率，而不是验证中的功能覆盖率，二者有比较大的差别，后续可以单独介绍。
