GJB5000B加强了对质量特性的要求,包括对质量特性的需求分析、设计以及验证与确认。但是,在具体实施过程中却很难操作。
以可靠性为例,衡量可靠性通常会用平均无故障时间、平均失效间隔、平均修复时间等指标,但是,如果测试这些指标,费时费力,不好操作。
下面的软件可靠性工程测试,流程清晰,容易操作,执行后可以大幅提高软件质量水平。所以,实施GJB5000B的可靠性要求,不妨执行这样的可靠性工程测试来提高软件的质量水平,而将那些衡量可靠性的度量指标(平均无故障时间等)留在交付系统后再去测试就好。
软件可靠性工程测试一般包括以下5个活动:定义可靠性、开发运行概况、准备测试用例、执行测试和分析实效数据。其中准备测试用例、执行测试和分析失效数据主要由测试人员完成,而定义可靠性和开发运行概况由系统工程师和架构师完成。
- 定义必须的可靠性
- 开发运行概况
架构师依据系统运行模式,开发运行概况(一个运行是一个主要的系统逻辑任务,运行结束后将控制权返还给系统),并判断每个运行发生的可能性。
- 准备测试用例
测试人员针对每个运行准备测试用例。
- 执行测试
测试人员按照按照各个运行的发生概率来执行测试,并及时 告发现的失效。
- 分析失效数据
测试人员根据失效数据计算出失效强度,并对比系统工程师定义的失效强度目标,以判断系统的可靠性是否满足要求。
示例:
某门诊病人管理系统主要有创建、查询、更新和删除4种运行,它的运行概况如下:
运行 | 每小时操作数 | 可能性 |
---|---|---|
创建 | 360 | 0.3 |
查询 | 240 | 0.2 |
更新 | 240 | 0.2 |
删除 | 360 | 0.3 |
合计 | 1200 | 1 |
根据该运行概况设计测试用例,并进行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的目标。
由此可见,当软件可靠性度量不好操作时,不妨由系统工程师定义合理的失效强度指标,并通过测试来确保可靠性指标得到满足,也不失为实施可靠性这一质量特性的一种可行的实践。
这正是:
难以度量可靠性,不妨考虑新角度
失效强度有目标,可靠性能有提高
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!