验证的计划

 

目录

1 计划概述

1.1 概述

1.2 验证的功能

2 计划内容

2.1验证的层次

2.2验证的方法

2.3验证用例

2.4 覆盖率的要求

2.5 风险评估

3 计划实现

3.1 验证计划的模板(或者组织结构)

3.2 确定测试场景

4 计划进程评估

4.1 回归测试通过率

4.2 代码覆盖率

4.3断言覆盖率

4.4功能覆盖率

4.5 缺陷曲线

1 计划概述

1.1 概述

●
在制定验证计划的具体过程中，我们会将技术部分和项目部分都考虑进来。
●
从技术角度而言，我们需要考虑的有验证的功能点、验证的层次、测试用例、验证方法和覆盖率要求。
从项目部分来看，我们也需要考虑使用的工具、人力安排、进度安排和风险评估。

1.2 验证的功能

●
基本功能:通常包括时钟、电源、复位、寄存器访问和基本特性,这些可以在模块级完成验证。
●
互动功能:一些需要同其它模块互动的特性，需要在更高层次的子系统级或者芯片级完成验证。
●
次要功能:通常这些功能会在项目后期完成验证，例如性能验证、效能验证。即使它们没有通过验证要求，也不会对芯片造成致命影响。

2 计划内容

2.1验证的层次

●
结合验证的功能点，需要清楚该功能点是否可以在较低的层次完成验证。
从验证效率和激励自由度来看，我们应该尽量在较低的层次验证更多的功能点。在较高的层次，例如芯片级，应该侧重于系统集成测试。
 

2.2验证的方法

●
需要考虑采取何种验证方法，动态仿真、形式验证还是硬件加速?
●
采取什么样的透明度，黑盒、白盒还是灰盒?
●
采用定向测试还是随机约束激励?

2.3验证用例

●
更随机的测试方法，尽可能遍历可能的各种状态空间?
●
适中的随机约束，倾向于更贴近实际场景的随机激励?
●
采用定向测试，针对- -些边界情况可以更有效地完善覆盖率?

2.4 覆盖率的要求

●
覆盖率是衡量激励生成种类和功能点验证的量化指标。
●
无论通过何种验证方法，我们都需要采用覆盖率来确保给出了足够多的激励类型，并且设计的边界和内部穷历了可能的状态。
●
覆盖率可以分为代码覆盖率、功能覆盖率和断言覆盖率。
●
除了给出合法的激励之外，也需要考虑给出一-些错误的激励，来测试设计的稳定性和纠错能力。
 

2.5 风险评估

●
芯片结构不稳定因素。如果在项目执行后期，突然面临结构的变化，这肯定会给相关设计带来很大影响，而验证任务量和时间也需要发生改变。
●
工具的不稳定因素。在新的项目中，我们倾向于使用新的工具版本，因为它们会带来新的性能提升和特性，而在新版本工具使用中也会有适应期，并非一帆风顺。如果我们需要替换工具，那么面临的工具替