《第四章 软件可靠性及其测度》由会员分享，可在线阅读，更多相关《第四章 软件可靠性及其测度（28页珍藏版）》请在金锄头文库上搜索。
1、第四章 软件可靠性及其测度杨秋伟 湖南大学 计算机与通信学院4.1 软件可靠性的意义o软件可靠性n一个软件系统在给定的时间段内能正常工作，并完成其(在规格说明中规定的)所有功能而不发生故障(错误)的概率o典型的案例n一元二次方程的根与系数的关系问题nY2K问题o全美7-Eleven便利店花了880万美元改造，2001年1月1日拒绝接受信用卡o2000年12月31日，挪威16列空港特快列车和13列高速列车停止工作，直至德国制造商30天后才恢复4.2 软件开发的生命周期o软件的生命周期n启动和结束阶段n需求条件和规格说明n建立原型样本n设计n编程n测试4.2 软件开发的生命周期o启动和结束阶段n业
2、务扩展/技术改进/提高竞争力是新项目启动、旧软件结束的原因o需求条件和规格说明n需求条件o对整个系统中硬件和软件两者所需要的条件有明确的描述o例如当前和将来的系统接口、硬件类型、使用环境的说明n规格说明o硬件规格(设备级) + 软件规格(算法级)o规格说明语言(Z-语言等)4.2 软件开发的生命周期o建立原型样本n理由o可以通过样本实现来体现他们的原始设计思想o设计中遇到的难点在样本中可以立即发现o样本中发现的缺陷可以返回项目用户以检查原始的需求条件等文件中存在的不足和错误n原型样本的基本构成模块o描述一个具有明确定义的基本函数功能或过程的程序块o一个模块的最佳长度50 200行o模块重用严格
3、测试(前期修改成本远远低于后期修改成本)4.2 软件开发的生命周期o设计n在原型样本的基础上进行最后阶段的设计工作o结构式程序设计方法n自顶向下(top-down)o动机设计之初信息量很少o从系统整体功能出发向进行分解n自底向上(bottom-up)4.2 软件开发的生命周期o编程n错觉编程是我们最想做、最有成就感的部分？n工作量分配o需求分析、规格说明等(40%) + 编程(20%) + 调试、测试等(40%)o高级语言编程关键在于数据流的控制n所选择的语言与使用的操作系统是否匹配n软件可能的使用时限，同今后将要开发的软件所使用的语言是否一致n软件与已有系统和将要开发的系统的关系n程序员对所
4、选取和使用语言的熟悉和习惯程度如何等因素4.2 软件开发的生命周期o测试n执行程序过程，检查程序功能的正确性和完整性n是软件开发周期中最复杂、实施成本最高的环节之一n一个观念：面向对象的程序设计比结构式程序设计有更多的层次和接口加重了测试的负担o针对“结构式自顶向下的程序设计”的测试步骤n单元测试(unit testing)n集成测试(integration testing)n系统测试(system testing)4.2 软件开发的生命周期o单元测试(unit testing)模块测试n一般一个主程序的某个模块(M)编程结束，就开始对它进行测试n为了测试M控制及与其它模块的接口之间的连接功能
5、，n一个观念：OOP比结构式程序设计有更多的层次和接口加重了测试的负担o针对“结构式自顶向下的程序设计”的测试步骤n单元测试(unit testing)n集成测试(integration testing)n系统测试(system testing)4.2 软件开发的生命周期o测试n执行程序过程，检查程序功能的正确性和完整性n是软件开发周期中最复杂、实施成本最高的环节之一n一个观念：OOP比结构式程序设计有更多的层次和接口加重了测试的负担o针对“结构式自顶向下的程序设计”的测试步骤n单元测试(unit testing)n集成测试(integration testing)n系统测试(system t
6、esting)4.2 软件开发的生命周期o测试n执行程序过程，检查程序功能的正确性和完整性n是软件开发周期中最复杂、实施成本最高的环节之一n一个观念：OOP比结构式程序设计有更多的层次和接口加重了测试的负担o针对“结构式自顶向下的程序设计”的测试步骤n单元测试(unit testing)n集成测试(integration testing)n系统测试(system testing)4.2 软件可靠性及其测度o单元测试模块测试n目的o检验模块自身的功能是否正常n测试方法o将可能出现的数据输入到模块，并运行该模块n评估方法(运行结果检测方法)o由于模块规模较小，由人工对模块可能的输出结果进行评估或预
7、测n测试用例(test case)o模块的输入数据 + 模块输出的“期望值”4.2 软件可靠性及其测度o单元测试模块测试n故障排除o修改有关的程序代码o再次验证n单元测试实例o一个主程序的最高模块编程结束M0o利用一些假设性模块(桩模块)来代替M0的连接对象o运用测试用例测试M0控制及与其它模块的接口之间的连接功能4.2 软件可靠性及其测度o集成测试n目的o检验模块之间的接口和路径方面的故障(错误)n测试方法o将经过单元测试的模块从第0层开始逐一加入n评估方法(运行结果检测方法)o在加入新模块之后出现接口或者路径错误，一般将故障定位在新加入模块白盒测试(white box testing)：需
8、要剖析到程序的详细源代码4.2 软件可靠性及其测度o系统测试n目的o检验软件系统级功能是否正常n测试方法o以软件系统在设计前期编写的需求分析和规格说明为基础进行功能性测试n注意事项o必须按照被测软件所有应实现的功能和任务，写出详细的实施方案黑盒测试(black box testing)：无需剖析到程序的详细源代码4.2 软件可靠性及其测度o系统测试实例空中交通管理软件的系统测试n详细描述某一个机场在某段时刻中飞机到达和出发的情况n诸多细节以及各种想象得到但是不一定会发生的情况n包括软件实施现成的其它有关设备和数据交换的情况，并作为软件系统的输入数据或者是控制对象加入到系统测试中o雷达信号o显示
9、系统o计算机系统等设备和信号o注：非现场实施可以采用模拟数据4.2 软件可靠性及其测度o现场测试n目的o对软件的现场功能进行测试n测试主体o该软件的最终用户n测试方法分类o开发现场测试o用户现场o实际使用现场4.2 软件可靠性及其测度o补充测试方法n回归测试o发现故障并修正以后，采用原来的测试用例再次测试n第三方测试o“当局者迷、旁观者清”n测试和测试o测试：在软件正式发布前软件开发商组织内部专家进行测试和评估o测试：软件开发商聘请一些客户试运行4.4 软件错误及其对软件可靠性模型的影响o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模
10、型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.6 软件可靠性模型o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性模型中的常数估算o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障
11、与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性的意义o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性的意义o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑
12、模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性的意义o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性的意义o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性的意义o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF4.1 软件可靠性的意义o非串/并行系统的可靠性n硬件系统只考虑具备“0”和“1”两值的物理元件逻辑元件n硬件故障模型视为逻辑故障模型o物理问题转化为逻辑问题o故障与物理器件、物理性能、工艺技术无关o逻辑模型化后对表现形式过于复杂的物理故障能进行较为彻底的研究oMTTRoMTBF
