第四章软件可靠性及其测度

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