使用失效数据来引导决定

1、使用失效数据来引导决定赵建华南京大学计算机系失效数据的用途 失效数据可以帮助你作出以下决定 接受/拒绝一个采办组件 引导你开发产品或者其变体的软件开发过程 接受或者拒绝一个超系统 发布一个产品 其中，决定1和3是在确认测试的时候做出的。引导过程 引导你开发一个产品或者其变体的软件开发过程的决定包括两个子决定 通过估算当前的失效强度和它的趋势来引导软件过程的改变。 根据失效的影响（包括频率和严重程度类）来确定需要解决的失效的优先次序。确认测试 主要的任务是确定某个软件的FI是否达到要求。 使用的主要工具是Reliability demonstration chart。 需要使用的数据：每个失效发

2、生的具体时刻。Reliability Demonstration Chart 使用失效发生的具体时刻,在图中绘制各个失效对应的点。根据点所在的区域决定接受/否决一个产品，或者继续测试。 纵轴：错误个数 横轴：标准化后的失效时刻Reliability Demonstration Chart 给图表总共有3个参数： 区分比率：你所能够接受的在估算FI的时候出现的误差的因子。 客户风险水平 ：你接受的将不符合FIO的产品说成符合FIO的可能性。 供应商风险水平 ：你所能够接受的将符合FIO的产品说成不符合要求的可能性。 当风险水平和/或区分比率降低时，CONTINUE区域变大。这意味着需要更加多的测

3、试来确定是否接受这个产品。对于RDC的解释 可能有10%的机会错误地接受一个其实际FI高于FIO两倍的产品 有10%风险错误地拒绝了一个其实际FI低于FIO一半的产品。区分比率2 客户风险水平：10%供应商风险水平：10%确认测试中使用RDC的例子 例子Failure numberMeasure(million calls)Normalized measure (MTTF)10.18760.7520.31251.2531.255一些具体问题 当失效数据一直不离开continue区域时? 不大可能发生,因为这需要FI不断增加,这和确认测试中,软件保持稳定相矛盾. 不一定要等到有一个点出现在ACC

4、区域才可以接受/拒绝。 当没有失效出现的时候，可以认为曲线水平延伸。当曲线进入ACC区域的时候就可以接受该软件。 所有的RDC的形状是类似的，但是不同区域之间的分界线不一样。分界线的方程如下：(表示区分度，n为失效个数） 在拒绝区域和继续区域 在继续区域和接受区域不同风险和区分度的RDCln1Anln1BnTN=TN=A,B的意义 当客户风险改变的时候， A的值改变很快， B的值改变比较慢 供应商风险改变的时候 A的值基本稳定。 B的值改变比较快。1lnln1AB不同设置时的RDC 当，参数不同的时候，RDC的两个分界线也各自不同。RDC的例子 Consumer risk = 5% Suppl

5、ier risk = 5% Discrimination ratio = 2可靠性增长测试 可靠性测试中，我们可以定期使用失效数据来估算FI/FIO的比值。 估算的间隔可以根据你需要评估当前的FI并根据需要采取行动的频率决定。Length of test remainingFreq. Of application of data 3 monthWeeklySMERFS和CASRE 可以使用SMERFS程序来估算当前的FI的情况。该程序的理论基础是软件可靠性模型和统计推论。 CASRE是另外一个工具，它的核心还是SMERFS程序，但是提供了比较方便的图形界面。CASRE(1) 接受的输入： 每个

6、错误发生的时候的累计的单元（时间）数目 或者：在一个间隔内发生的错误数量。这个间隔总是起始于某个错误发生的时刻或者测试开始的时刻。 如果使用自然时间或单元，需要首先规范化这些时间或者单元（乘以FIO，得到MTTF）。CASRE(2) CASRE使用两种模型来估算但前的状态和预测将来的趋势 对数模型（Musa-Okumoto）：假设软件在无限多的时间内出现无限多个失效。对FI的估算趋于悲观。 指数模型（Musa Basic）：假设软件在无限多时间内出现有限多的失效。对FI的估算趋于乐观。 在实际使用中，这两个模型中总有一个很好地符合实际情况。CASRE(3) CASRE的输出是“Next ste

7、p prediction”。 如果我们将输入数据如前面所讲的规范化了，那么Next step prediction就将是MTTF。我们可以对MTTF取倒数得到FI/FIO的比率。 如果失效数据显示测试对FI的提高作用很小，CASRE将不能输出“Next step prediction”。此时可以使用其他的方式得到FI/FIO的值。CASRE(4) CASRE对FI/FIO的估算的准确性依赖于 具体有多少个失效数据。 被测系统的规模5000行代码时，估算的效果比较好。FI/FIO不变的时候 当测试发现FI/FIO很大且基本不变的时候，可以考虑下面的三个方法 增加更多的资源进行测试 重新调整FIO

8、，开发时间和开发费用之间的关系。 推迟实现某些功能。 当FI/FIO2时，分析最近的5个数据，看是否FI/FIO有增大的趋势。分析原因并找出解决方法。终止测试 当规范化的失效强度(FI/FIO)的值低于0.5的时候，可以考虑停止测试。 不是在FI/FIO等于1的时候发布是因为失效数据具有不确定性，估算具有误差。为了保证一定的可信度，需要使得实效强度更加小一点。发布产品 当下面的情况成立的时候，可以考虑发布产品 对产品的测试圆满结束。 对于产品的所有变体的测试圆满结束。 在预先准备好的验收测试中，产品被接受了。 所有的系统都被接受了。 当有一些情况发生的时候，需要考虑推迟发布：比如有非常严重的缺

9、陷。 一般来说，当系统发布的时候，所有的严重程度为1级或2级的失效都得到了纠正。特殊情况 正在发展变化中的程序 在测试的过程中，程序本身可能正在被改变。 没有被报告的失效 系统的测试过程中，有些测试可能没有被观察到。 不同风险水平和区分度下的确认测试正在发展变化中的程序 在可靠性增长测试过程中，可靠性模型是被用来估算稳定的系统的（除了修正错误，不对系统作出改变） 但是，系统在开发的过程中很有可能会因为软件需求的改变，技术的发展等而发生改变。 修改操作的实现，改变软件/硬件， 这样的变化会引入新的错误。当程序变化缓慢的时候 如果程序的进化很慢，比如每周小于5%的代码被修改。你可以忽略这样的程序变

10、化 此时，使用理论模型估算模型参数或FI/FIO的时候会偏离实际情况。但是，模型本身就是有误差的。由于忽略变化而产生的误差是可以接受的。 当你不停地估算参数或者FI/FIO的时候，最新的数据对结果的影响最大。因此，随着测试过程的进展，估算得到的值将比较接近新的程序。 在实际的实践中，多达21%的程序的改变引起的估算值也只是仅仅引起了估算值的一小段时间的不连续跳跃。 这样做的好处在于可以避免收集新的数据。当出现了大的改动时 可以放弃前面得到的全部数据，但是你可能需要等待很长时间才可以得到足够的数据来进行估算预测。 可以考虑结合老的数据来进行估算/预测，这样得到的结果要比没有数据时更不坏。 当有了

11、足够的数据的时候，可以考虑放弃全部数据。两种更加显著的变化 你可能需要处理两种更加显著的变化 一个组件一个组件的变化 一个操作组一个操作组的变化 书中提供的方式假设各个元素之间的失效强度相互独立。处理方法（逐个组件演化） 首先估算每个组件的FI。 如果程序逐个组件地演化，并且程序正常工作需要所有的组件都正常地工作，那么你每加入一个组件，就将其FI加入到系统的FI中去。 比如：假设组件A,B的FI分别是：15/100H和20/100H，那么系统地的FI为35/100H。 如果系统的组合方式有所不同，那么计算方式也应该可以改变。处理方法（逐个操作组演化） 首先估算每个操作组的FI。 将这些操作组的

12、FI的带权重的和作为整个系统的FI。 比如：操作组A的失效强度为5/1000H，而B的失效强度为10/1000H。A中的操作出现的概率为0.6，B中的操作出现的概率为0.4。那么系统的FI为:(0.6*5+0。4*10)/100H。处理方法的局限性 这样的方法只能处理元素个数比较少的情况： 当元素个数过多，对每个元素的数据样本规模很小，估算误差增大。 元素个数比较大的时候，错误很可能出现在元素的组合过程中。 因此，这样的方法适合于：变化量大，但是变化次数比较少的情况。其它适用情况 前面的方法可以用于一些其他的情况： 一个程序完全由其他的组件集成而来，并且测试的时候使用逐步进行的方式。 程序充分

13、集成，但是观察失效的时候是按照渐进的方式进行的。 开始的时候专注于某个组建（操作组），然后逐步拓宽视野。没有被报告的失效（1） 在很多情况下，有些失效可能没有被报告，特别是在使用现场发生的。 这些情况主要发生在严重程度不高，没有引起程序执行中断的失效上。 通过训练和激励人员，以及投入更多的精力检查程序输出，你可以降低没有被报告的失效的比例，但是不可能完全消除遗漏的失效。没有被报告的失效（2） 一般来说，在负载测试中会有更加多的失效被忽略掉。 在功能测试和回归测试中，用户一般可以知道程序的标准输出。 在负载测试中，由于间接输入变量的影响，往往难以预先知道确切的标准输出。 你可以通过基于系统需求，

14、直到某些变量的某些值是不可接受的。就是说，在某些情况下可以肯定系统失效了。没有被报告的失效（3） 有些失效没有被报告意味着，总的来说，我们将低估系统的FI。 但是，被用户忽略的失效更加多。也就是说，相对于测试者而言，用户会认为这个系统更加可靠。 也有可能在实际使用的时候，用户感觉到的FI高于测试时估算。主要原因在于系统测试没有计划好，测试时的模拟环境和实际使用的不同。没有被报告的失效（4） 可以通过某些手段对估算到的FI进行调整。具体的方法是： 通过对类似项目的分析，看到底有多少失效被遗漏了。（这样的活动非常费时费力） 通过这些历史数据，你可以逆向估算出有多少失效被遗漏了。中对FI估算的影响(1) 假设第i个失效被遗漏的概率的表示方式如图: 1212is the probability that theth failure goes unnoticediP iPppiaaP iPiaP ii对于FI估算的影响(2) 对于基本执行时间模型: 模型假设: 000e 解释 如果P(I)不变，那么估算得到的FI比较小。 如果P(I)随时间增加，那么估算得到的FI就比较低，而且越来越低。 如果P(I)随时间降低，那么对于FI的估计开始的时候比较低，但是逐渐