驗證計畫(十)

 测试例設計上的分组

把有相似验证需求的功能分为一组
功能分组是很自然的。一些功能需要相似的配置、粒度或验证策略来进行验证。为了最大
化生产效率，这些功能应该被分到同一组，并分配给同一位验证工程师。例如，所有和CPU接
口有关的功能应该被分到一起。不論是直接或隨機的測試力設計皆需要依照測試的功能來分組，

分組的方式如下


1. 功能清单中的交叉引用
每个测试用例应该有一个标签和对目标的一小段描述。描述应该包括测试用例中已验证功
能的清单。功能的清单应该链接到验证这个功能的测试用例。如果一个功能没有指向一个测试
用例的交叉引用，那么这个功能就没有验证。

2. 定义从属关系
对测试用例的描述应该包括被认为可操作并功能正确的功能的清单。依靠它们的从属关
系，可以决定测试用例编写的顺序，并确认在测试平台开发中是否有并行的机会。

3. 指定测试用例的激励
必须描述测试用例激励的顺序和特性。例如，要描述必须进行的各种操作或总线周期。用
随机数据或随机事务来填充所有不相关数据或背景数据是个好方法。

4. 指定可接受的准则
除了期望的响应，测试规范还必须说明如何判定响应是正确的。这包括期望的值、时序和
协议。例如，路由包处理器的输出的目标地址如果和它显示的输出端口是匹配的，那就可以判
定是正确的。或者可以用一些更严格的判定方法，例如，不同来源的包以一定的顺序排列并以
一定分布交织排列。

5. 指定要查找的错误
一种更直接的描述可接受准则的方法是描述要查找什么样的错误。例如，确认一个包有正
确的 CRC 校验值。另一个例子是描述不能同时发生的事件，如FIFO 中 full 标志和 empty 标志
的置位。直接描述要查找的错误可以让一个不太熟悉设计的验证工程师实现高度可靠的测试
平台。


6. 注入错误以确定它们被检测到
永远不要相信一个不生成错误信息的测试平台。每个测试用例应该包括一些错误注入机制
来确保测试平台可以发现并且报告错误。缺乏错误信息可能会成为测试用例的一个失败条件。
比如，一个用于验证串口奇偶位生成的测试用例应该能故意错误地配置奇偶位，以确保测试平
台能够检测到一个错误的奇偶位。当然，测试平台不能一发现错误信息就退出仿真。

7. 为每個分组的测试用例分配一名工程师
不管测试用例是如何分组到测试平台的，每一分组测试用例应该分配给一名验证工程师。同
一组测试用例有相似的实现需求。它们可以在同组中前一个测试用例的实现基础上完成。第一
个测试平台要花费最长的时间来完成。但是随着负责每组测试用例的工程师的经验增长和对基
础结构验证的调试，很多工作可以被重复使用。在接下来的测试平台中，只要剪切复制就可以
完成工作。每个测试平台被分配的人员名字应该被记录在验证计划中。那个人根据验证计划的
规范文档负责完成测试平台。