网络工程师-系统开发运行与配置(第十一天)

一、系统的RAS特性

RAS特性是可靠性、可用性、可维护性的统称。

1.基本定义

系统的可靠性：是指从系统开始运行到某一时刻t能够正常运行的概率，通常用R（t）表示。
失效率:是指单位时间内失效的元件数与元件总数的比例。通常用入表示。
平均无故障时间(MTTF)也称修复前平均时间,是指某个元件预计的可运作平均时间。MTTF=1/入。
平均故障修复时间(MTTR) :是描述产品由故障状态转为工作状态时修理时间的平均值。包括确认失效发生所需的时间,以及维护所需要的时间。它用于表示计算机的可维修性。
平均故障间隔时间(MTBF) :是指相邻两次故障之间的平均时间。常与MTTF发生混淆。因为两次故障之间必然有修复行为,因此,MTBF中应包含MTTR。MTBF= MTTR+ MTTF。实际应用中,一般MTTR很小,通常认为MTBF=MTTF
可用性：是指计算机的使用效率，它以系统在执行任务的任意时刻能够正常工作的概率来表示，A=MTTF/(MTTF+MTTR)

例题：

3.模冗余系统

例题：

二、软件的生命周期模型

1.软件危机和软件工程

　　软件危机
　　软件工程：是将系统化的、阉割约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。软件工程方法学包括三个要素：方法、工具和过程。

2.软件生命周期

　　是指软件的产生知道报废的生命周期，包括：问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试、运行维护等阶段。

3.软件开发模型

常见的开发模型有：

　　（1）瀑布模型

瀑布模型优点：

为项目提供了按阶段划分的检查点。
当前一阶段完成后，只需要去关注后续阶段。
它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有个共同的指导。

瀑布模型的缺点:

(1)各个阶段之间产生大量的文档,极大地增加了工作量。
(2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
(3)不适应用户需求的变化,并且在需求分析阶段不可能完全获取。(4)在软件开发前期未发的错误传到后面的开发活动中时,可能会扩散,进而可能会导致整个软件项目开发失败。

所以,瀑布模型适用于需求明确或很少变更的项目。

　　（2）快速原型模型

快速原型是利用原型辅助软件开发的一-种新思想。
经过简单快速分析,快速建造一个可以运行的软件原型,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。

原型可以分为三类:

●探索型原型

主要用于需求分析阶段,目的是要弄清用户的需求,并探索各种方案的可行性。它主要针对开发目标模糊,用户与开发人员对项目都缺乏经验的情况,通过对原型的开发来明确用户的需求。

●实验型原型

主要用于设计阶段，考核实现方案是否合适,能否实现。对于大型系统,若对设计方案心中没有把握时,可通过这种原型来证实设计方案的正确性。

●演化型原型

主要用于及早向用户提交个原型系统 ,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到用户的认可后将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。

　　（2）演化模型

也称为变换模型，根据用户的基本需求,通过快速分析构造出一个初始可运行版本(原型) ,然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进,获得原型的新版本。重复这一过程,最终可得到令用户满意的软件产品。快速原型模型是"抛弃式”的,演化模型是"渐进式”原型方法。 演化模型特别适用于对软件需求缺乏准确认识的情况。

演化模型的优点:

(1)很早就可以验证是否符合产品需求。
(2)风险管理可以在早期就获得项目进程数据,可据此对后续的开发进度作出比较切实的估算。增加项目成功的机率。
(3)经验教训能反馈于本产品的下一个循环过程,提高质量效率。
(4)心理上,开发人员早日见到产品的雏型,是一种鼓舞。
(5)使用户可以在新的一批功能开发测试后,立即参加验证,以便提供非常有价值的反馈。

演化模型的缺点：

(1)产品需求在一开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并影响产品性能的优化。
(2)如果缺乏严格的过程管理,这个生命周期模型可能退化为一种原始的无计划的“试-错-改”模式。
(3)用户接触开发中的尚未测试稳定的功能,可能对用户都产生负面的影响。

　　（4）增量模型

融合了瀑布模型的基本成分和原型实现的迭代特征,是第三种原型化开发方法,但它不是"抛弃式"的，也不是"渐进式”的。增量模型把软件产品划分为一系列的增量构件,第一个增量往往是核心的产品，即第一个增量实现了基本的需求。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复 ,直到产生了最终的完善产品。

增量模型与原型实现模型和其他演化方法一样,本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一一个可操作产品。增量模型的特点是引|进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。

增量模型优点：

(1)人员分配灵活,初期不用太大投入。
(2)每隔一小段时间就提交用户部分功能,用户可以直观感受项目进展,及时试用产品功能。
(3)有利于风险的把控。

增量模型将功能细化、分别开发的方法适应于需求经常改变的软件开发过程。

（5）螺旋模型

将瀑布模型和演化模型相结合,综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转-圈都要经过制订计划、风险分析、实施工程及客户评价等活动,并开发原型的一个新版本。经过若干次螺旋上升的过程,得到最终的系统。

螺旋模型的优点:

(1)设计上灵活,可以在项目的各个阶段进行变更;
(2)以小的分段来构建大型系统，使成本计算变得简单容易;
(3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向;
(4)随着项目推进,客户始终掌握项目的最新信息，从而能够和管理层有效地交互。

螺旋模型的缺点:

(1)需要具有相当丰富的风险评估经验和专门]知识,如果未能够及时标识风险;势必造成重大损失;
(2)过多的迭代次数会增加开发成本,延迟提交时间。

　　（6）喷泉模型

是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程,该模型认为软件开发过程自下而上的,各阶段是相互迭代和无间隙的。无间隙是指在开发活动中,分析、设计和编码之间一Y 不存在明显的边界。

例题：

三、软件测试与维护

概念：软件测试是指在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

软件的正确性证明尚未得到根本的解决,软件测试仍是发现软件错误和缺陷的主要手段。

（1）软件测试基础（重点）

测试用例是由测试数据和预期结果构成的。

为了发现程序中的错误,应竭力设计能暴露错误的测试用例
好的测试用例是发现至今为止尚未发现的错误。
一次成功的测试是发现了至今尚未发现的错误的测试。

（2）软件测试准则

应该尽早地、不断的进行测试,软件测试贯穿于开发过程的始终。
所有测试都应该能追溯到用户需求。
应该从小规模测试开始,并逐步进行大规模测试。
应该远在测试之前就制定出测试计划。
80%的错误可能出现在20%的程序模块中。
应该由独立的第三方从事测试工作。
对非法和非预期的输入数据也要像合法数据一样编写测试用例。
检查软件是否做了应该做的事仅是成功一半，另一半是看软件是否做了不该做的事。
在规划测试时不要设想程序中不会查出错误。
测试只能证明软件中有错误,不能证明软件中没有错误。

（3）软件测试分类

从测试阶段分：单元测试、集成测试、确认测试和系统测试
从测试方法分：白盒测试、黑盒测试
回归测试是指修改了旧代码后,重新进行全部或部分以前的测试用例,以确认修改没有引入新的错误或导致其他代码产生错误。

（4）测试的阶段

单元测试

- 单元测试又称为模块测试,是针对软件设计的最小单位(模块) 进行正确性检验的测试工作。目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求,以及发现各模块内部可能存在的各种错误。
- 单元测试通常由开发人员自己负责。
- 单元测试要借助驱动模块(相当于用于测试模拟的主程序)和桩模块(子模块)来完成。
- 单元测试的计划是在软件详细设计阶段完成的。
- 单元测试一般使用白盒测试方法。

模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一-些辅助模块去模拟与被测模块相联系的其他模块。

(1)驱动模块:相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块,最后输出实测结果。
(2)桩模块:用于代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来,但不允许什么事情也不做。

　　2.集成测试

集成测试也称为组装测试、联合测试。它将已通过单元测试的模块集成在一起,主要测试模块之间的协作性。

从组装策略而言,可以分为一次性组装和增量式组装(包括自顶向下、自底向上及混合式)两种。

集成测试计划是在软件概要设计阶段完成的。
集成测试一般采用黑盒测试方法。
自顶向下进行组装,不需要驱动模块。
自底向上进行组装,不需要桩模块。
在每个版本提交时,都需要进行“冒烟"测试,即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。

　　3.确认测试

确认测试也称为有效性测试,主要包括验证软件的功能、性能及其他特性是否与用户要求(需求) 一致。确认测试计划是在需求分析阶段完成的。

根据用户的参与程度,包括以下3种类型:

(1)内部确认测试：由软件开发组织内部按软件需求说明书进行测试。
(2) Alpha测试：由用户在开发环境下进行测试。
(3) Beta测试：由用户在实际使用环境下进行测试。

　　4.系统测试

是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起,进行信息系统的各种组装测试和确认测试,系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案。

系统测试计划在系统分析阶段(需求分析阶段)完成。

例题1：

例题2：

（5）测试的类型

软件测试分为两大类:

动态测试和静态测试。

1.动态测试指通过运行程序发现错误分为：黑盒测试法、白盒测试法、灰盒测试法

（1）黑盒测试

黑盒测试又称为功能测试或数据驱动测试。把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。

常用的黑盒测试用例的设计方法: 等价类划分、边界值分析、错误推测、因果图

（2）白盒测试

又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。把测试对象看做一个打开的盒子,测试人员必须了解程序的内部结构和处理过程,以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致。

常用的白盒测试用例设计方法有: 语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、条件组合覆盖、路径覆盖等，发现错误的能力呈由弱至强的变化。

语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。

　　（3）灰盒测试

灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性,同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。灰盒测试结合了白盒测试和黑盒测试的要素,考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。

（6）软件维护

软件可维护性是指维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进软件的难易程度。

衡量程序可维护性的因素：可理解性、可测试性和可修改性等。

软件维护占整个软件生命周期的60% ~ 80%，维护的类型有:

(1)改正性维护：是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。

(2)适应性维护：是指使用软件适应信息技术变化和管理需求变化而进行的修改。

(3)完善性维护：是为扩充功能和改善性能而进行的修改,主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。

(4)预防性维护：为了改进应用软件的可靠性和可维护性,为了适应未来的软硬件环境的变化,应主动增加预防性的新的功能,以使应用系统适应各类变化而不被淘汰。