软件可靠性评测及其应用探讨(2)

　　可靠性增长测试和可靠性验证测试将从不同的角度理解故障数据。在可靠性增长测试中，测试以迭代的方式进行，根据测试期间跟踪到的故障，使用基于软件可靠性增长模型和统计推理的可靠性评估程序进行故障强度的估计，并用于跟踪测试的进展情况。可靠性验证测试是软件系统提交前进行的最后测试。它是最终检验而不是调试。在验证测试中,其目标是确定一个软件组件或系统在风险限度内是被接受还是被拒绝。验证测试使用可靠性示图，故障被绘制在图上。根据它落入的区域，来决定被测软件是被接受还是被拒绝，或者继续进行测试。可以根据不同的客户风险(接受一个不良程序的风险)和供应商风险(拒绝一个好程序的风险)级别构造图表。

　　三、软件可靠性评测在工程实践中的几个问题

　　1、运行剖面的定义

　　定义运行剖面首先需要为软件的使用行为建模，建模可以采用Markov链来完成。用Markov链将输入域编码为一个代表用户观点的软件使用的状态集。弧用来连结状态并表示由各种激励导致的转换。这些激励可能由硬件、人机接口或其它软件等产生。将转换概率分配给每个弧，用来代表一个典型用户最有可能施加给系统的激励。这种类型的Markov链是一个离散的有限状态机。这类模型可以用有向图或转换矩阵表示。

　　定义运行剖面的下一步是开发使用模型，明确需要测试的内容。软件系统可能会有许多用户和用户类别，每类用户都可能以不同的方式使用系统。开发使用模型涉及到将输入域分层。有两种类型的分层形式：用户级分层和用法级分层。 用户级分层依赖于谁或什么能激励系统。用法级分层依赖于在测试状态下系统能做什么。换句话说，用户级分层促使你考虑各种类型的用户以及他们如何使用系统，用法级分层则要求考虑系统能够提供的所有功能。一旦用户和用法模型被开发出来，弧上的概率将被分配。这些概率估计主要是基于如下几个方面： ① 从现有系统收集到的数据， ② 与用户的交谈或对用户进行观察获得的信息， ③ 原型使用与试验分析的结果， ④ 相关领域专家的意见。定义使用概率的最佳方法是使用实际的用户数据，如来自系统原型、前一版本的使用数据;其次是由该软件应用领域的用户和专家提供的预期使用数据;在没有任何数据可用的情况下，只能是将每个状态现有的弧分配相同的概率，这是最差的一种方法。

　　软件可靠性测试假设每个操作的数据输入都有同样的发生错误的概率，这样最频繁出现的操作和输入将表现出最高的故障率。对于特定的操作环境这是正确的，但无法贯穿系统的全部操作集合。典型的例子是飞机的飞行控制软件，在正常飞行、起飞、降落、地面运动和地面等待这五个状态中，尽管起飞和降落在操作剖面上只占有很小的百分比，但是它们却占有很大的故障比例。对于高安全性要求的软件，一个看起来很少使用的代码路径也可能带来灾难性的后果。因此，对于边界、跃迁情况和关键功能不应该用简单的操作剖面来对待，应该构造专门的操作剖面，补充统计模型之外的测试用例。在覆盖率水平不够时，可根据具体空白，进行适当的补充测试，如果补充测试发现了错误，就可分析这些错误，估计其对可靠性产生的影响。

　　2、测试的实施

　　有了软件的运行剖面，就可以使用Monte Carlo仿真的形式实施测试。使用这类仿真，可保持统计的完整性。通过操作模型、弧上概率和随机数的驱动，一个通过软件的随机路径形成了一次在软件上的统计试验。有一些工具可以使用这些技术自动生成测试脚本，这些工具也生成大量的统计数据帮助测试机构建立可靠性评估和其它测试停止标准。

　　软件可靠性测试必须是受控试验，在运行此类测试时，为了保证统计数据的有效性，测试过程中的每个测试用例必须施加于相同的软件版本。新的软件版本意味着新试验的开始，其测试结果也必须是一致的。

　　在有些情况下，不能进行纯粹的可靠性测试。因为客户的要求、合同的规定或者标准的约束，需要补充其它形式的非统计测试。这时的最佳选择是既执行可靠性测试，也执行非统计测试(如覆盖测试)。如果非统计测试在可靠性测试之前完成，由统计测试产生的统计数据仍然有效。但是在可靠性测试之后执行非统计测试，可能会影响软件可靠性评估的准确性。

　　软件可靠性测试同样依赖于软件的可测试性。可靠性测试难点就在于判断测试用例的运行是成功还是失败。在控制系统及类似的软件中，故障有详细说明、时间(通常是CPU时间或时钟时间)来客观的定义。而在一般应用系统中，故障的定义更主观些，它不仅依赖于程序是否符合规格说明的要求，也取决于指定的性能是否达到用户的期望，但是否达到期望没有确定的标准。在一些科学计算中，计算结果只能由计算机才能给出，在这种情况下，如果软件只是输出了错误的结果而不是整个系统发生故障，错误就不可能被发觉。此时可以将测试分成两个阶段进行。第一阶段运行较少量的测试用例，并对照规范进行仔细检查。第二阶段再运行大量测试用例。第二阶段不用人工检查输出的每项内容，而是找故障现象，包括错误信息、断电、崩溃和死机。也可把输出记录到文件中，采用搜索或过滤方法进行处理。如果软件有足够的可测试性，这种方法不会漏掉很多的严重故障。如果计算的正确性无法验证，就需要对软件进行一些形式化的证明。

原文转自：http://www.uml.org.cn/Test/200903234.asp