软件可靠性不好度量，不如试试软件可靠性工程测试

GJB5000B加强了对质量特性的要求，包括对质量特性的需求分析、设计以及验证与确认。但是，在具体实施过程中却很难操作。

以可靠性为例，衡量可靠性通常会用平均无故障时间、平均失效间隔、平均修复时间等指标，但是，如果测试这些指标，费时费力，不好操作。

下面的软件可靠性工程测试，流程清晰，容易操作，执行后可以大幅提高软件质量水平。所以，实施GJB5000B的可靠性要求，不妨执行这样的可靠性工程测试来提高软件的质量水平，而将那些衡量可靠性的度量指标（平均无故障时间等）留在交付系统后再去测试就好。

软件可靠性工程测试一般包括以下5个活动：定义可靠性、开发运行概况、准备测试用例、执行测试和分析实效数据。其中准备测试用例、执行测试和分析失效数据主要由测试人员完成，而定义可靠性和开发运行概况由系统工程师和架构师完成。

系统工程师根据用户需求以及项目资源情况定义软件必须的可靠性。他需要识别出系统有几种运行模式，为每种运行模式定义系统失效，并根据失效影响的范围和程度不同，将其分成不同的等级；然后为每个定义的系统失效设定失效强度目标（失效强度是单位执行时间内发生的失效次数）。

架构师依据系统运行模式，开发运行概况（一个运行是一个主要的系统逻辑任务，运行结束后将控制权返还给系统），并判断每个运行发生的可能性。

测试人员针对每个运行准备测试用例。

测试人员按照按照各个运行的发生概率来执行测试，并及时报告发现的失效。

测试人员根据失效数据计算出失效强度，并对比系统工程师定义的失效强度目标，以判断系统的可靠性是否满足要求。

示例：

某门诊病人管理系统主要有创建、查询、更新和删除4种运行，它的运行概况如下：

根据该运行概况设计测试用例，并进行48小时的可靠性测试，结果如下。

(1)测试开始时间：10:39:51 04/11/2008。
(2)合计执行操作数：57 600。
执行成功的操作数：57 598。
执行失败的操作数：2(其中创建和更新各一次)。
(3)测试结束时间：10:39:51 04/13/2008。

该系统的失效强度定义为系统每小时发生的失败操作数，实效强度目标为0.05，根据测试结果，在该运行概况下系统的失效强度为2/48=0.0417，符合小于0.05的目标。

由此可见，当软件可靠性度量不好操作时，不妨由系统工程师定义合理的失效强度指标，并通过测试来确保可靠性指标得到满足，也不失为实施可靠性这一质量特性的一种可行的实践。

这正是：

难以度量可靠性，不妨考虑新角度

失效强度有目标，可靠性能有提高

参考书目：软件测试设计，作者：马均飞，郑文强，出版社：电子工业出版社

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。