使用失效数据来引导决定.ppt

* * * * * * * * * * * * * * * * * * * 没有被报告的失效（1） 在很多情况下，有些失效可能没有被报告，特别是在使用现场发生的。 这些情况主要发生在严重程度不高，没有引起程序执行中断的失效上。 通过训练和激励人员，以及投入更多的精力检查程序输出，你可以降低没有被报告的失效的比例，但是不可能完全消除遗漏的失效。 没有被报告的失效（2） 一般来说，在负载测试中会有更加多的失效被忽略掉。 在功能测试和回归测试中，用户一般可以知道程序的标准输出。 在负载测试中，由于间接输入变量的影响，往往难以预先知道确切的标准输出。 你可以通过基于系统需求，直到某些变量的某些值是不可接受的。就是说，在某些情况下可以肯定系统失效了。 没有被报告的失效（3） 有些失效没有被报告意味着，总的来说，我们将低估系统的FI。 但是，被用户忽略的失效更加多。也就是说，相对于测试者而言，用户会认为这个系统更加可靠。 也有可能在实际使用的时候，用户感觉到的FI高于测试时估算。主要原因在于系统测试没有计划好，测试时的模拟环境和实际使用的不同。 没有被报告的失效（4） 可以通过某些手段对估算到的FI进行调整。具体的方法是： 通过对类似项目的分析，看到底有多少失效被遗漏了。（这样的活动非常费时费力） 通过这些历史数据，你可以逆向估算出有多少失效被遗漏了。 中对FI估算的影响(1) 假设第i个失效被遗漏的概率的表示方式如图: 对于FI估算的影响(2) 对于基本执行时间模型: 模型假设: 解释 如果P(I)不变，那么估算得到的FI比较小。 如果P(I)随时间增加，那么估算得到的FI就比较低，而且越来越低。 如果P(I)随时间降低，那么对于FI的估计开始的时候比较低，但是逐渐变好。 对FI估算的影响（3） 对于对数模型 模型假设： 操作剖面不同的时候（1） 操作剖面很大程度上反映了软件的实际使用方式。但是操作剖面和现实中的使用方式必然不同。 软件可能在不同的方式下使用，其操作剖面也会有所不同。 操作剖面不同的时候（2） 假设pDk是一个操作剖面中第k个操作的发生概率，按照这个操作剖面得到的失效强度是λD 问：另外一个操作剖面中，第k个操作的发生概率是pMk，那么系统在这个操作模式下的失效强度是： * * * * * * * * * * * * * * * * * * * * * * 使用失效数据来引导决定 失效数据的用途 失效数据可以帮助你作出以下决定 接受/拒绝一个采办组件 引导你开发产品或者其变体的软件开发过程 接受或者拒绝一个超系统 发布一个产品 其中，决定1和3是在确认测试的时候做出的。 引导过程 引导你开发一个产品或者其变体的软件开发过程的决定包括两个子决定 通过估算当前的失效强度和它的趋势来引导软件过程的改变。 根据失效的影响（包括频率和严重程度类）来确定需要解决的失效的优先次序。 确认测试 主要的任务是确定某个软件的FI是否达到要求。 使用的主要工具是Reliability demonstration chart。 需要使用的数据：每个失效发生的具体时刻。 Reliability Demonstration Chart 使用失效发生的具体时刻,在图中绘制各个失效对应的点。根据点所在的区域决定接受/否决一个产品，或者继续测试。 纵轴：错误个数 横轴：标准化后的失效时刻 Reliability Demonstration Chart 给图表总共有3个参数： 区分比率γ：你所能够接受的在估算FI的时候出现的误差的因子。 客户风险水平 β ：你接受的将不符合FIO的产品说成符合FIO的可能性。 供应商风险水平 α ：你所能够接受的将符合FIO的产品说成不符合要求的可能性。 当风险水平和/或区分比率降低时，CONTINUE区域变大。这意味着需要更加多的测试来确定是否接受这个产品。 对于RDC的解释 可能有10%的机会错误地接受一个其实际FI高于FIO两倍的产品 有10%风险错误地拒绝了一个其实际FI低于FIO一半的产品。 区分比率2 客户风险水平：10% 供应商风险水平：10% 确认测试中使用RDC的例子 例子 Failure number Measure (million calls) Normalized measure (MTTF) 1 0.1876 0.75 2 0.3125 1.25 3 1.25 5 一些具体问题 当失效数据一直不离开continue区域时? 不大可能发生,因为这需要FI不断增加,这和确认测试中,软件保持稳定相矛盾. 不一定要等到有一个点出现在ACC区域才可以接受/拒绝。 当没有失效出现的时候，可以认为曲线水平延伸。当曲线进入ACC区域的时候就可以接受该软件。 不同风险和区分度的RDC 所有的RDC的形状是类似的，