第100贴【2004－9－13】：故障插入
故障插入（Fault Seeding）是一个统计的方法，用于评价遗留在一个程序中的故障的数量和种类。首先，故障被插入到一个程序中，然后，程序被测试，并且发现故障的数量被用于估计还没有被发现故障的数量。计算公式如下：原本错误总数 =（播入的错误总数/发现的播入错误数）×发现的原本错误数
残留错误数 = 原本错误总数 - 发现的原本错误数
故障插入技术在软件可靠性方面应用的比较广泛，尤其在硬件的测试当中。例如一些汽车公司不惜花大价钱进行的汽车碰撞试验，为的就是发现汽车在碰撞过程中的潜在隐患，通过消除、改进这些隐患从而达到更高的性能。
借鉴了硬件可靠性测试的方法，在软件测试中引入故障插入技术，其主要目的是为了评价系统的哪些模块，哪些代码是危险模块，危险代码，容易出问题，从而评价系统的容错能力。在该技术中使用了故障加速技术，通过有意的插入故障来调用系统的故障容错能力，从而在一个可控制的环境和期望的时间段内获得完整的测试。它和现有的测试方法相比，最大的不同在于测试开始时的系统状态不同，现有的测试都是从系统的正确状态开始，测试系统如何转入故障状态，而故障注入测试则是从系统的故障状态开始，测试系统在发生故障后的运行规律。这里要重点指出的是，故障插入不关注为什么出现这样的故障，它关注的是出现了这样的故障后系统如何处理。
故障插入也被用于验证测试用例的有效性。其原理就是为了检查设计的测试用例是否能发现某一类型的故障，人为在被测系统中引入该类型的故障，如果在测试过程中能发现这个故障的话，则应该也可以测试出系统原来就存在的该类故障。
故障插入技术的一个难点是插入的故障在程序中是否能够代表还没有发现的故障。实际上，由于软件的复杂性，故障的暴露往往和当时的运行环境、执行的路径有很大的关系，能测试出故障插入的故障并不一定总是能测试出被测系统原本存在的该类型故障，所以，在上述的最后一步推论不一定总是成立。但是就从验证测试用例的有效性角度来看，故障插入确实可以作为一种手段。 很好的方法啊。 好像可用在很多地方啊 是个好方法，具体怎么使用还要慢慢做。做什么样测试的会适用呢
如何获得
这些参数如何获得：播入的错误总数
发现的播入错误数
发现的原本错误数 有用~ 1.播入的错误总数 :有相关的设计人员来设计插入的错误，其数量当然知道
2。发现的播入错误数：发现的错误有可能有插入的错误（对比设计的错误），也有可能不是插入的错误，那么就是原来的错误。
3。发现的原本错误数：做这个“故障插入测试”前的Bug总数肯定是知道的（bug纪录），再加上做“故障插入测试”中发现的“原来的错误”
当然，应该找那些强的人来设计插入的错误，否则引起其他的错误，或者发现的错误只是某些，太片面等。
个人看法 我们现在好像没有用过这样的测试方法 理论上没问题但是不适用 就算你知道软件里有多少个BUG但是找不到有什么用
测试是为了找出软件中的BUG不是计算软件里有多少个BUG或者还剩下多少个BUG 这是一种工程性的方法，实践中如何运用还要结合被测对象的具体情况，总之这是一个不错的思路。虽然测试是为了找BUG，但测试是不能无休止的进行下去的，那么如何评价当前被测对象的质量状况是很重要的。这时候故障插入技术也许能发挥一定作用了。 这种方法的思路不错，可是实际运用时，如何避免“由插入错误引发的原本错误”？ 理论上确实不错,也是一个很好的思路,但如果要实际操作的话,要求太高.有待努力啊.希望将来有这个能力来实现. 是啊，要求太高
to:ginkgo
为什么要避免“由插入错误引发的原本错误”？发现错误不是更好吗，这些原本错误也是系统的原本错误。 to: jody“由插入错误引发的原本错误”意思是：
1. 如果没有‘插入错误’，这些‘原本错误’是不存在的，也就是说在实际的运行情况下（没有‘插入错误’）不存在的错误。
2. 这种错误是由‘插入错误’本身引起的，与‘原本错误’无关。
3. 为了保证故障插入的正确有效，我们是否还要建一套专门对‘插入错误’进行管理的跟踪库？ 这种方法原来是用来统计野生动物种群数量的，称为“Capture-Recapture”方法，对于软件工程，主要用于计算软件的可靠性指标，难点在于植入缺陷是否和软件的原有缺陷在位置、难度和类型的分布上一致。并且现在国内软件很少提可靠性的指标，所以用的应该很有限。 呵呵，你把两个概念搅在一起了：需求描述的可验证性、软件的可测试性。 小顶一下~~~~~~~~~~ 高手~~~~~ 在书上看过
页:
[1]
2
