即使对于一个非常简单的IP，我们也无法验证充分，或者说无法证明芯片没有bug。一个验证人员所能够做的就是尽可能地发现更多的bug，增强流片成功的信心。
对于芯片的验证用例，在各个基本分支通路都已经覆盖了之后，还需要考虑下如何增加一些变化和随机。
本文介绍一些如何丰富我们的测试用例的策略，在原先的用例的基础上增加变化，派生出衍生场景用例，用于验证不同DUT状态和不同代码路径。
首先一个场景（scenario）是由很多个场景操作(scenario operator)构成，对场景注入变化会得到一个新的场景，我们称之为衍生场景(derived scenario)。
一、插入步骤
给场景增加额外的步骤可以使它们更加多样化，从而测试更多的功能，即增加发现芯片bug的机会。
二、增加更多数据
不同的数据可以执行不同的代码路径，导致芯片状态有所变化。如果芯片支持处理操作数op0和op1,可以
代码语言：javascript复制先发送op0，然后再发送op0
先发送op0，然后再发送op1
先发送op1，然后再发送op0
先发送op1，然后再发送op1对验证人员一个比较高的要求是，不能仅观察芯片能够正确处理上述场景，还应该问自己:“芯片如何用到这个操作数?怎样更有意义地增加tetscase输入的数据?哪些场景和我正在测试的场景具有相关性”。
还有一个很重要的考虑因素是，如果spec要求对于data0处理op0,data1处理op1。并且spec没有明说data1不支持op0,data0不支持op0，那么Testcase就要增加{data0,op1}和{data1,op0}的场景。
我们的目的是加强场景验证，而不是彻底改变场景验证的基本目标。验证人员通过增加其他输入、加大数据量或变化场景把整个场景拖长，但是并没有改变场景验证的核心目标。
三、删除步骤
我们可以去掉冗余和可选的步骤，这个操作的想法是使场景的步骤尽可能地减少，可以用来测试芯片的默认值以及模拟用户使用默认配置（不再下发配置）的行为。
验证人员可以使用递进的方式应用这个“删除步骤”，每次只删除一个步骤，直到获得一个最短的测试用例。
四、替换步骤
如果场景验证中某些步骤可以有多种方法完成，就可以用替换步骤来修改这个测试用例。替换步骤实际上是前面两个操作的组合，就是先删除步骤，然后再插入步骤。
五、重复步骤
场景验证经常包含非常明确的顺序。重复步骤操作通过重复单独的步骤或重复一组步骤来给场景验证增加变化，丰富场景验证用例。
初始化后执行某个场景和重复第二次执行某个场景所执行的代码路径是不同的，可能发现那些可能与数据初始化相关的缺陷。如果一个功能使用其他功能初始化的数据值，这两个功能之间的执行顺序就有关系，改变这种顺序可能会发现bug。
六、替换数据
很多情况下，验证场景要求和本地的其他数据库相连接，例如初始化memory hex文件。这些场景会明确配置芯片要执行的动作，验证人员需要知道与相关的数据源如何作用并创建各种各样的变化。
七、替换环境
在我们运行测试用例时，测试的结果与用例执行的环境密切相关。很多时候验证执行的环境也会带入一些人为约束。
