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

admin

作者：刘杰

一、概述
在现代军事和商用系统中，以软件为核心的产品得到了广泛的应用。随着系统中软件成分的不断增加，使得系统对于软件的依赖性越来越强，对软件质量尤其是可靠性的要求也越来越高。
软件可靠性是指在规定的条件下和规定的时间内，软件不引起系统故障的能力。软件可靠性不但与软件中存在的缺陷有关，而且与系统输入和系统使用有关。软件可靠性是软件质量特性中重要的固有特性和关键因素。软件可靠性反映了用户的质量观点。
软件可靠性评价是软件可靠性工作的重要组成部分。软件可靠性评测是主要的软件可靠性评价技术，它包括测试与评价两个方面的内容，既适用于软件开发过程，也可针对最终软件产品。在软件开发过程中使用软件可靠性评测技术，除了可以更快速地找出对可靠性影响最大的错误，还可以结合软件可靠性增长模型,估计软件当前的可靠性，以确认是否可以终止测试和发布软件，同时还可以预计软件要达到相应的可靠性水平所需要的时间和测试量，论证在给定日期提交软件可能给可靠性带来的影响。对于最终软件产品，软件可靠性评测是一种可行的评价技术，可以对最终产品进行可靠性验证测试，确认软件的执行与需求的一致性，确定最终软件产品所达到的可靠性水平。

二、软件可靠性评测技术
本文所述的软件可靠性评测是指运用统计技术对软件可靠性测试和系统运行期间采集的软件失效数据进行处理并评估软件可靠性的过程。软件可靠性评测的主要目的是测量和验证软件的可靠性，当然实施软件可靠性评测也是对软件测试过程的一种完善，有助于软件产品本身的可靠性增长。
软件测试者可以使用很多方法进行软件测试，如按行为或结构来划分输入域的划分测试，纯粹随机选择输入的随机测试，基于功能、路径、数据流或控制流的覆盖测试，等等。对于给定的软件，每种测试方法都局限于暴露一定数量和一些类别的错误。通过这些测试能够查找、定位、改正和消除某些错误，实现一定意义上的软件可靠性增长。但是，由于它们都是面向错误的测试，测试所得到的结果数据不宜用于软件可靠性评估。
软件可靠性测试是指在软件的预期使用环境中，为进行软件可靠性评估而对软件实施的一种测试。软件可靠性测试应该是面向故障的测试，以用户将要使用的方式来测试软件，每一次测试代表用户将要完成的一组操作，使测试成为最终产品使用的预演。这就使得所获得的测试数据与软件的实际运行数据比较接近，可用于软件可靠性估计。
软件可靠性评测由可靠性目标的确定、运行剖面的开发、测试的计划与执行和测试结果的分析与反馈等四个主要的活动组成。
可靠性目标是指客户对软件性能满意程度的期望。通常用可靠度、故障强度、MTTF等指标来描述，根据不同项目的不同需要而定。建立定量的可靠性指标需要对可靠性、交付时间和成本进行平衡。为了定义系统的可靠性指标,必须确定系统的运行模式，定义故障的严重性等级，确定故障强度目标。
为了对软件可靠性进行良好的预计，必须在软件的运行域上对其进行测试，首先定义一个相应的剖面来镜像运行域，然后使用这个剖面驱动测试，这样可以使测试真实的反映软件的使用情况。由于可能的输入几乎是无限的，测试必须从中选择出一些样本，即测试用例，测试用例要能反映实际的使用情况，反映系统的运行剖面。将统计方法应用到运行剖面开发和测试用例生成，在运行剖面中的每个元素都被定量地赋予一个发生概率值和关键因子，然后根据这些因素分配测试资源、挑选和生成测试用例。在这种测试中,优先测试那些最重要或最频繁使用的功能，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障，以保证软件的按期交付。一个产品有可能需要开发多个运行剖面，这取决于它所包含的运行模式和关键操作，通常需要为关键操作单独定义运行剖面。
在软件的开发过程中使用软件可靠性测试和利用软件可靠性测试对最终产品进行评价，在测试计划的制定上有所不同。用于设计过程的可靠性测试称为可靠性增长测试，测试与故障的排除联系在一起，一般安排在开发过程的系统测试阶段执行，将测试所确定的故障提交给开发者进行修改，建立软件的一个新的版本，再进行下一次测试。在这种“测试—排错—新版本”的迭代过程中，跟踪故障强度的变化，确认测试是否可以终止及软件是否可以发布。可靠性增长测试的测试脚本将执行多次。针对最终产品的可靠性测试称为可靠性验证测试，通过验证测试可确定软件产品当前的可靠性水平。就单个软件版本而言，可靠性验证测试的测试脚本将仅执行一次。软件可靠性故障数据的收集是测试活动的一部分，在测试周期内，纪录每个故障的资料，如与时间相关的故障频度、类型、严重性和故障的根源等，并且应区分设计阶段和最终产品的故障。
可靠性增长测试和可靠性验证测试将从不同的角度理解故障数据。在可靠性增长测试中，测试以迭代的方式进行，根据测试期间跟踪到的故障，使用基于软件可靠性增长模型和统计推理的可靠性评估程序进行故障强度的估计，并用于跟踪测试的进展情况。可靠性验证测试是软件系统提交前进行的最后测试。它是最终检验而不是调试。在验证测试中,其目标是确定一个软件组件或系统在风险限度内是被接受还是被拒绝。验证测试使用可靠性示图，故障被绘制在图上。根据它落入的区域，来决定被测软件是被接受还是被拒绝，或者继续进行测试。可以根据不同的客户风险(接受一个不良程序的风险)和供应商风险(拒绝一个好程序的风险)级别构造图表。

三、软件可靠性评测在工程实践中的几个问题
1、运行剖面的定义
定义运行剖面首先需要为软件的使用行为建模，建模可以采用Markov链来完成。用Markov链将输入域编码为一个代表用户观点的软件使用的状态集。弧用来连结状态并表示由各种激励导致的转换。这些激励可能由硬件、人机接口或其它软件等产生。将转换概率分配给每个弧，用来代表一个典型用户最有可能施加给系统的激励。这种类型的Markov链是一个离散的有限状态机。这类模型可以用有向图或转换矩阵表示。
定义运行剖面的下一步是开发使用模型，明确需要测试的内容。软件系统可能会有许多用户和用户类别，每类用户都可能以不同的方式使用系统。开发使用模型涉及到将输入域分层。有两种类型的分层形式：用户级分层和用法级分层。用户级分层依赖于谁或什么能激励系统。用法级分层依赖于在测试状态下系统能做什么。换句话说，用户级分层促使你考虑各种类型的用户以及他们如何使用系统，用法级分层则要求考虑系统能够提供的所有功能。一旦用户和用法模型被开发出来，弧上的概率将被分配。这些概率估计主要是基于如下几个方面：①从现有系统收集到的数据，②与用户的交谈或对用户进行观察获得的信息，③原型使用与试验分析的结果，④相关领域专家的意见。定义使用概率的最佳方法是使用实际的用户数据，如来自系统原型、前一版本的使用数据；其次是由该软件应用领域的用户和专家提供的预期使用数据；在没有任何数据可用的情况下，只能是将每个状态现有的弧分配相同的概率，这是最差的一种方法。
软件可靠性测试假设每个操作的数据输入都有同样的发生错误的概率，这样最频繁出现的操作和输入将表现出最高的故障率。对于特定的操作环境这是正确的，但无法贯穿系统的全部操作集合。典型的例子是飞机的飞行控制软件，在正常飞行、起飞、降落、地面运动和地面等待这五个状态中，尽管起飞和降落在操作剖面上只占有很小的百分比，但是它们却占有很大的故障比例。对于高安全性要求的软件，一个看起来很少使用的代码路径也可能带来灾难性的后果。因此，对于边界、跃迁情况和关键功能不应该用简单的操作剖面来对待，应该构造专门的操作剖面，补充统计模型之外的测试用例。在覆盖率水平不够时，可根据具体空白，进行适当的补充测试，如果补充测试发现了错误，就可分析这些错误，估计其对可靠性产生的影响。
2、测试的实施
有了软件的运行剖面，就可以使用MonteCarlo仿真的形式实施测试。使用这类仿真，可保持统计的完整性。通过操作模型、弧上概率和随机数的驱动，一个通过软件的随机路径形成了一次在软件上的统计试验。有一些工具可以使用这些技术自动生成测试脚本，这些工具也生成大量的统计数据帮助测试机构建立可靠性评估和其它测试停止标准。
软件可靠性测试必须是受控试验，在运行此类测试时，为了保证统计数据的有效性，测试过程中的每个测试用例必须施加于相同的软件版本。新的软件版本意味着新试验的开始，其测试结果也必须是一致的。
在有些情况下，不能进行纯粹的可靠性测试。因为客户的要求、合同的规定或者标准的约束，需要补充其它形式的非统计测试。这时的最佳选择是既执行可靠性测试，也执行非统计测试(如覆盖测试)。如果非统计测试在可靠性测试之前完成，由统计测试产生的统计数据仍然有效。但是在可靠性测试之后执行非统计测试，可能会影响软件可靠性评估的准确性。
软件可靠性测试同样依赖于软件的可测试性。可靠性测试难点就在于判断测试用例的运行是成功还是失败。在控制系统及类似的软件中，故障有详细说明、时间(通常是CPU时间或时钟时间)来客观的定义。而在一般应用系统中，故障的定义更主观些，它不仅依赖于程序是否符合规格说明的要求，也取决于指定的性能是否达到用户的期望，但是否达到期望没有确定的标准。在一些科学计算中，计算结果只能由计算机才能给出，在这种情况下，如果软件只是输出了错误的结果而不是整个系统发生故障，错误就不可能被发觉。此时可以将测试分成两个阶段进行。第一阶段运行较少量的测试用例，并对照规范进行仔细检查。第二阶段再运行大量测试用例。第二阶段不用人工检查输出的每项内容，而是找故障现象，包括错误信息、断电、崩溃和死机。也可把输出记录到文件中，采用搜索或过滤方法进行处理。如果软件有足够的可测试性，这种方法不会漏掉很多的严重故障。如果计算的正确性无法验证，就需要对软件进行一些形式化的证明。
软件可靠性测试还必须考虑对软件开发进度和成本的影响，最好是在受控的自动测试环境下，有专业测试机构完成。
3、可靠性评价
目前有不少支持软件可靠性估计的软件工具，我们只要将可靠性测试过程中收集的故障数据分类并录入，选择合适的可靠性模型就可以获得软件可靠性的评估结果。
然而，对于那些可靠性要求很高的系统，必须进行很多测试才能预计出高置值度的可靠性，即便如此，仍然可能出现代码不断地被测试而没有出现任何故障的情况。没有故障就无法估计可靠性，你不能认为程序的可靠性是1.0。除非我们已经进行了完全的测试，否则程序不失效我们就无法做出估计，而完全的测试几乎总是不可能的。如果在测试期间没有故障发生，我们可以简单地假设测试是基于二项式分布的，这样就可以对可靠性作保守估计，也可以凭经验根据无故障运行的测试用例的数量，在一定的置信度水平上，估计可靠性的等级。

四、结束语
软件可靠性测试是一种有效的软件测试和软件可靠性评价技术。尽管软件可靠性测试也不能保证软件中残存的错误数最少，但经过软件可靠性测试可以保证软件的可靠性达到较高的要求。对于研制和开发高可靠性与高安全性软件系统很有帮助。
软件可靠性测试要在工程上获得广泛应用，还有许多实际问题需要解决。

christina_pc

软件测试难，软件可靠性测试更是难上加难，但是软件可靠性测试是软件可靠性研究中非常重要的一个环节，也是可靠性研究理论化向实践化发展的重要途径。

imm

学习。。

robert928

是的啊，我测试一个软件从今年1月测试到昨天才算通过。
总结一下主要是前期对于整个测试框架没有一个比较细致的搭建，软件测试要求你必须仔细，对于那些发现的问题尤其要重点关注。还有就是对于一些功能的取舍，必须要有明确的判决：例如，开发人员认为A老师可以控制选择C老师作为指导教师的1号学生，当C老师请假，A老师就可以替C老师代课。我测试的时候觉得1个萝卜一个坑，要是A、C老师都在，那完了，两个老师控制一个学生，随意修改1号学生的考试信息，会混乱。最终我和开发人员商议后才达成最终结果。
总体来说，这次测试是比较失败的，呵呵，是我的第一次软件测试。。。。
欢迎大家指教！
Wiley,.The.Art.of.Software.Testing,.2Ed.(2004).DDU;.BM.OCR.6.0-2.5.ShareConnector
Softwaredebugging,testing,andverificationbyB.HailpernP.Santhanam
这两本书还行

cliffcrag

呵呵，那是不是A。C老师都在的时候，要做个判断，只能由C老师作为指导教师，而A老师这个时候没有权限。

robert928

原则上是应该判断C老师是否在线，不在的话再给其他老师权限。可是我们考虑实际应用情况后，选择了开发人员的的考虑。我这个只是一个例子！呵呵。主要还是说明当初没思考周全。走了弯路

hisgrace

新手来学习了谢谢！

gyj128

顶

shysie

请问：高可靠软件可靠性验证与评估技术主要是做哪方面工作？以后好找工作吗？

刘俊远

下载下来看看！谢谢楼主！