日志

回归测试可以变得聪明一些吗？

已有 2414 次阅读| 2016-9-11 16:57 |个人分类:验证前沿资讯

对于我们SOC设计来讲，利用标准回归测试(如果我们改变了设计代码或者修复了一个bug，然后把所有的测试激励重新仿真，以确认两点∶解决了现有bug和没有引入新的bug，这种方法我们称为回归测试)去检验我们所改变的一些设计代码是一种很受欢迎的方法，然而在实际应用中，很多时候它并不能很好的工作，会把我们的bug检测报告发送给错误的人(并不是引入bug的人)，有着很大的局限性，接下来我们具体谈谈它的局限性和针对这些局限性我们应该采取的办法

回归测试的局限性：

首先我们需要明白一个问题，那就是回归测试为什么会有这种局限性？通常意义上是因为在标准回归测试中，它正常工作时有一个假设前提，认为对于每一个失败的测试激励都只有一个原因，而且它会被立即检测到并改正，在后面的测试激励仿真中不会再有它的影子，然而实际情况并不是这样，一个失败的测试激励可能是有好几个bug导致的，这就使得标准回归测试的假设前提不成立，导致它发出来的错误报告多达41％(统计结果)，从原理上明白回归测试的局限性后我们来看一些实际的例子

上图中列出了一些实际测试仿真中可能出现的情况，我们针对它们做一些简单的分析，看看回归测试方法的可行性，首先来看图一中的"simple scenario"，对于这个失败的测试激励，只有一个bug导致它失败，那就是在6版本上引入的bug，除此之外在没有其他的任何bug，在这种情况下，回归测试完全可以正常工作，它给出的bug分析报告可以准确的发送给6版本上的bug引入者，然而这个测试场景比较简单，实际的测试场景并不都是像它一样，我们来看第二个测试场景"Overlapping Faliers-only most recent failers is still open"，在这个测试场景中，我们的测试激励失败有两个原因，第一个是6版本上引入的bug1，第二个是7版本上引入的bug2，而bug1在8版本上被修复了，也就是说在9版本上测试激励失败的原因是由于bug2(7版本引入)引起的，然而对于回归测试分析方法却会把错误原因归咎于bug1，这时它会给出错误的分析报告，在第三个测试场景"Overlaping Failures-both are still open"中，和第二个类似，不同点在于bug1仍然存在，没有被修复，所以测试激励失败的原因有两个，是有bug1和bug2同时引起的，但回归测试的报告中只会认为由bug1引起，而忽略了bug2，这让分析报告变得不准确，即使bug1消失了，测试激励仍然会因为bug2而失败，接下来比较复杂的测试激励还有测试4，测试5，测试6，但到现在已经足以说明问题，回归测试的方法只能处理一些简单的测试场景给出正确的分析报告，对于多个bug的测试场景，我们需要利用其他更可行的方法来给出正确的分析报告

解决方法：
对于回归测试的报告不能处理若干个bug同时存在的情况，我们有两个解决办法：一是用来避免多个bug同时存在的方法，以便于让回归测试的报告分析可以正常工作，我们叫做"continuous integration"，另一个是引进一个新的可以分析多个bug同时存在场景的工具，叫做"PinDown"
接下来我们先来看第一种方法"continuous integration"，它的基本工作流程如下图，
为了防止多个bug同时引入的情况，我们建立了一个比较严格的版本控制机制，只有你的更改通过了测试，才能通过版本控制，上传为一个新的文件版本，如果测试失败，将不被允许上传，系统会给一封失败的邮件，让你来修复bug，这样就能保证我们每次上传新的版本文件都是正确的，不会引入新的bug，避免出现多个bug同时存在的情况，然而对于这个方法，由于每次改动都要仿真测试激励，我们用于检测bug的测试激励的仿真时间必须很短，而且由于随机测试每次仿真的场景都不同，不能每次都正确检测某一bug的修复情况，所以随机测试也不能被支持，但是随机测试在硬件设计项目中是很常用的手段，这也使得这种方法在软件测试中更加受欢迎
第二个方法PinDown
它并不像第一个方法一样，从源头上避免出现多个bug的情况，而是用工具去处理这种情况，处理机制是把测试激励在许多版本(由最新到最老)上进行仿真，找出测试激励失败的原因，工作原理如下图
PinDown就像一个在线的服务器一样，它有自己的数据库，并且连接着版本控制系统和LSF系统，它有一个脚本会check out最新的文件版本然后仿真测试激励，然后读取仿真结果进行分析，如果仿真失败，那么它会把文件版本切换到上一版或者很老的版本来检测测试激励是在什么时候开始失败的，值得注意的是它并不会把所有的测试激励都重新在老的版本上仿真，而是会把失败的测试激励都放入到一个组中，然后根据失败的原因和之前的一些测试结果，把失败的测试激励分成一些bug组，从每个bug组里面找出仿真速度最快的测试激励来仿真，下面是一个PinDiwn工作的例子，我们仿真了200个测试激励，其中有10个失败了，PinDown检测到这10和失败的测试激励，然后经过失败原因分析后，并行的仿真10个测试激励，然后发出了两份bug report，而这10个测试激励失败的原因正是分析报告中的两个bug，过程如下图:
对于PinDown的解决方法让我们修复bug更及时，也从一定程度上避免了多个bug同时存在的情况，至此，我们介绍了两个用于克服回归测试局限性的方法，continuous integration和PinDown，他们都能够克服标准回归测试的不稳定性，带来更准确的测试结果，显然第二种测试方法更适合硬件设计，它对于随机测试和直接测试没有选择性，可以使用于所有情况，加速我们设计bug的修复
总结:在集成电路设计中，标准的回归测试方法是能够尽可能多的去仿真我们的测试用例，在测试用例失败的时候能够尽快锁定导致测试用例的失败的bug，避免它和接下来有可能引入的bug混合在一起，增加调试的困难程度，然而在标准的回归测试流程中，给出的报告中却有高达41%的报告给出了错误的bug数据，这会极大的影响我们工程师debug的速度，鉴于此，我们给出了两种解决方法，第一种方法是尽量避免比较复杂的bug纠缠在一起的情况，让我们分析的测试激励失败原因单一化，然后利用回归测试给出bug报告，但它不能正确运用在随机激励上，第二种是利用更先进的工具PinDown来处理多个bug同时存在的复杂情况，通过在多个版本上进行测试，找出测试激励最开始失败的版本，给出分析报告，它对于测试激励随机性没有限制，作用在硬件设计中更方便。