一种芯片验证中确定回归测试版本异常源头的方法

摘要

本发明公开了一种芯片验证中确定回归测试版本异常源头的方法，其实现过程为：对回归测试中出现错误的原因进行分析，自动检测错误原因，通过确定出错源头的方式，使得错误原因能被明确显示，帮助设计人员及时修正错误。该芯片验证中确定回归测试版本异常源头的方法与现有技术相比，极大提高逻辑验证的效率，缩短芯片开发周期，实用性高，易于推广。

说明书

技术领域

本发明涉及芯片逻辑验证领域，具体地说是一种实用性强、芯片验证中确定回归测试版本异常源头的方法。

背景技术

伴随芯片设计复杂度的增加，芯片逻辑设计验证很大程度上借鉴了软件开发的模式以及项目管理理念。版本管理，回归测试，持续集成等方法也获得了广泛应用。这些方法能获得应用，是因为逻辑设计验证与软件开发有诸多共同点，比如源代码都是文本文件，大项目需要多人多地并行开发。但是逻辑设计验证又有自己的特点，使得普通软件项目管理的方法在这个领域需要进行相应调整。

逻辑设计验证与软件开发最大的不同之处在于，芯片逻辑设计必须保证交付前完全无缺陷，否则重新更改设计成本极大。这就导致对验证的要求很高，致使验证部分所需工作量极大，验证本身需要占用大量的开发时间和计算资源。软件开发基本可以每修改一次设计，进行一下回归测试，保证提交的版本是正确的。但是复杂的逻辑设计每次进行回归测试，可能需要几个小时甚至几天的时间。而这段时间内可能会有新的代码版本被提交，这就导致不是所有被提交的版本都是干净的。这样会引起一连串复杂的问题。另外芯片验证普遍使用受控随机测试来辅助传统的人工开发直接测试用例的方法，。受控随机测试根据输入的限定条件，在有限范围内自动产生各种随机组合，更容易发现逻辑设计的缺陷。这种方法不同于人工开发的直接测试用例，它在代码有修改后可能导致错误无法重现。这些都会导致提交的代码版本如果出现测试错误，则错误来源是不明确的。

为了有效的解决以上问题，我们需要对这些问题进行详细分析，并找出对应方法，确定真正的错误源头，方便对其作出修改。

发明内容

本发明的技术任务是针对以上不足之处，提供一种实用性强、芯片验证中确定回归测试版本异常源头的方法。

一种芯片验证中确定回归测试版本异常源头的方法，其具体实现过程为：对回归测试中出现错误的原因进行分析，自动检测错误原因，通过确定出错源头的方式，使得错误原因能被明确显示，帮助设计人员及时修正错误。

自动检测回归测试中的错误原因采用以下方式进行：

对待检测版本的产品进行冒烟测试，测试通过后将其提交到版本库；

对冒烟测试未通过的产品进行修改，修改后的产品采用并行版本测试方法，即与可通过测试的版本合并的方式进行测试，通过测试后则将其提交到版本库。

上述测试在逻辑验证平台中进行，该逻辑验证平台包括仿真用的计算集群、仿真器软件、版本管理系统、被测对象的RTL代码、验证平台与测试激励，回归测试中的错误则是由上述逻辑验证平台中的各部分出问题产生的。

所述回归测试中的错误具体分为以下三类：

一、由于硬件与网络错误、版本冲突、仿真器许可缺失导致的验证平台基本功能故障；

二、由于验证平台与测试激励的bug导致的回归测试的错误；

三、由于被测对象的RTL代码的bug导致的回归测试的错误。

所述冒烟检测所需的测试用例从总的回归测试用例集合中人工挑选出来，该挑选出的测试用例为测试产品的基本功能；

每当有需要提交的版本时，逻辑验证平台对待提交版本运行一次冒烟测试，如果测试通过，则将此版本正式提交进版本库；如果测试失败，则通知提交者修改错误，而不进行提交。

将所有修改后的版本通过运行递归测试，即顺序测试的方式判断哪个版本通过测试，并将最后一个通过测试的版本提交到版本库。

上述递归测试的具体实现过程为：

将第一个修改后的产品与能通过测试的主版本产品进行合并，测试是否能通过；

当测试通过后，再将合并后版本的产品与下一个版本的产品进行合并，测试是否能通过；

重复步骤二，直至测试完全通过或测试无法通过；

当测试完全通过时，提交最后的合并版本到版本库；当测试无法通过时，提交最后测试通过时的合并版本到版本库。

本发明的一种芯片验证中确定回归测试版本异常源头的方法，具有以下优点：

本发明通过对回归测试中出现错误的原因进行归纳分析，设定特定机制自动检测错误原因，使得错误原因能被明确显示，帮助设计人员及时修正错误，极大提高逻辑验证的效率，缩短芯片开发周期，实用性高，易于推广。

附图说明

附图1为本发明实施例中的错误示意图。

附图2为并行版本测试示意图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明。

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

本发明提供一种芯片验证中确定回归测试版本异常源头的方法，其具体实现过程为：对回归测试中出现错误的原因进行分析，自动检测错误原因，通过确定出错源头的方式，使得错误原因能被明确显示，帮助设计人员及时修正错误。

自动检测回归测试中的错误原因采用以下方式进行：

对待检测版本的产品进行冒烟测试，测试通过后将其提交到版本库；

对冒烟测试未通过的产品进行修改，修改后的产品采用并行版本测试方法，即与可通过测试的版本合并的方式进行测试，通过测试后则将其提交到版本库。

上述测试在逻辑验证平台中进行，该逻辑验证平台包括仿真用的计算集群、仿真器软件、版本管理系统、被测对象的RTL代码、验证平台与测试激励，回归测试中的错误则是由上述逻辑验证平台中的各部分出问题产生的。

所述回归测试中的错误具体分为以下三类：

一、由于硬件与网络错误、版本冲突、仿真器许可缺失导致的验证平台基本功能故障；

二、由于验证平台与测试激励的bug导致的回归测试的错误；

三、由于被测对象的RTL代码的bug导致的回归测试的错误。

以上几类错误中第二种和第三种发生的几率最大，是逻辑设计与验证人员要面对和解决的问题。

所述冒烟检测所需的测试用例从总的回归测试用例集合中人工挑选出来，该挑选出的测试用例为测试产品的基本功能；

每当有需要提交的版本时，逻辑验证平台对待提交版本运行一次冒烟测试，如果测试通过，则将此版本正式提交进版本库；如果测试失败，则通知提交者修改错误，而不进行提交。

将所有修改后的版本通过运行递归测试，即顺序测试的方式判断哪个版本通过测试，并将最后一个通过测试的版本提交到版本库。

上述递归测试的具体实现过程为：

将第一个修改后的产品与能通过测试的主版本产品进行合并，测试是否能通过；

当测试通过后，再将合并后版本的产品与下一个版本的产品进行合并，测试是否能通过；

重复步骤二，直至测试完全通过或测试无法通过；

当测试完全通过时，提交最后的合并版本到版本库；当测试无法通过时，提交最后测试通过时的合并版本到版本库。

对于某些中小型的工程，由于回归测试时间短，而且版本提交的频率低，可以做到每个版本都进行回归测试，得到每个版本的测试结果。而对于某些大型工程，则很难做到这点，原因是运行一次回归测试的时间，远大于版本提交的间隔。这就产生了一些新的问题，包括我们如果发现版本是错误的，如何判定是哪个版本的问题，以及如何确定进行回归测试的时间点等等。

我们先来分析一下提交多个版本后进行一次回归测试遇到的问题。如图1所示，第一行代表每个代码版本都测试的情况下，可以清楚知道是哪个代码版本开始出错，图中线条状代表有错，无填充代表通过，网格状代表没有测试结果。如果每3个版本进行一次测试，则中间的版本2，3是否有错误则无法知道。

对于版本2，3，可能发生之前描述的3种错误中的任何一种。我们当然可以重新恢复到版本1来查找之后出现问题的原因，但是这肯定不是最优的方法，我们可以设计一种更好的机制来解决这种问题。以下就通过实施例通过上述方法应对这个问题。

一、将待检测的版本配合冒烟测试来实现。

冒烟检测是一种形象化的测试术语，表示对产品进行最基本的功能测试，而不进行完备的测试。这种测试能保证版本基本功能通过，但是所需的测试时间非常短，能保证让每个版本都能运行完。冒烟检测所需的测试用例需要从回归测试用例集合中人工挑选出来，这些测试用例必须能够快速完成且覆盖大部分基本功能。

基本功能指一个产品最普遍基础的能力，比如一个电冰箱可以制冷，而其他的消毒，除霜这些就不是基本功能。完备测试集合指所有标定需要的功能的测试程序。比方对一个电冰箱，要测试包括制冷，保鲜，除霜等，还要测试在不同环境下的工作。

每当有需要提交的版本，系统都会对待提交版本运行一次冒烟测试，如果测试通过，则将此版本正式提交进版本库。如果测试失败，则通知提交者修改错误，而不进行提交。

通过如上方法，可以保证所有提交的版本完全避免错误因素一。大幅度的降低错误因素二中测试平台有错误的情况，并较为有效的避免错误因素三。这样如图1中的版本2，3虽然不能保证通过完备测试集的测试，但是能通过的可能性大幅度提高。这时我们每隔2个版本运行一次测试，能通过的概率大幅提高。即使未通过，回退查找原因进行的迭代次数也会减少。如当图1中版本4出错时，我们可以回退到之前版本3和2分别进行回归测试，这时这2个版本能通过回归测试的概率也有大幅提高。

二、用并行的版本测试方法来实现。

方法一降低了中间未被完全测试的版本错误的概率，但是不能完全避免错误出现。我们可以设置一种并行检测的方法来处理这个问题。

假设图如2中A，B版本分别为2个不同的工程师做改动后提交。之后需要运行递归测试判断哪个版本能通过测试，并提交到主版本。我们先将版本A与能通过测试的主版本进行合并，测试是否能通过，若能通过，则再将合并后版本与版本B合并，运行测试，若能通过，则提交版本B，不通过则提交版本A。如有更多的版本需要提交，则都通过以上方法进行比对，就能正确的选取合适的版本进行提交。

上述版本合并为本领域软件设计中常见操作步骤，比如版本A修改了文件fa，比如版本B修改了文件fb，则合并两个版本则修改这两个文件使他们都同步到最新文件。

通过以上方法，可以保证即使版本提交的频率和人数比较多，而且回归测试所需时间比较长，也能每次都明确找出哪些版本存在问题，哪些版本可以通过测试。

结合使用方法1，2能更好的管理逻辑设计验证中的代码版本，提高工作效率，加速产品上市。

上述具体实施方式仅是本发明的具体个案，本发明的专利保护范围包括但不限于上述具体实施方式，任何符合本发明的一种芯片验证中确定回归测试版本异常源头的方法的权利要求书的且任何所述技术领域的普通技术人员对其所做的适当变化或替换，皆应落入本发明的专利保护范围。