7. 喷泉模型在实现时,由于活动不同,可分为系统实现和对象实现,这既反映了全系统的开发过程,也反映了对象族的开发和重用过程
5)智能模型
智能模型也称为基于知识的软件开发模型,是知识工程与软件工程在开发模型上结合的产物,以瀑布模型与专家系统的综合应用为基础建立的模型,该模型通过应用系统的知识和规则帮组设计者认识一个特定的软件的需求和设计,这些专家系统已成为开发过程的伙伴,并指导开发过程。
从图中可以清楚地看到,智能模型与其他模型不同,它的维护并不在程序一级上进行,这样就把问题的复杂性大大降低了。
智能模型的主要优点有:
① 通过领域的专家系统,可使需求说明更加完整、准确和无二义性。
② 通过软件工程的专家系统,提供一个设计库支持,在开发过程中成为设计的助手。
③ 通过软件工程知识和特定应用领域的知识和规则的应用来提供开发的帮助。
但是,要建立合适于软件设计的专家系统,或建立一个既适合软件工程由适合应用领域的知识库都是非常困难的。目前,在软件开发中正在使用AI技术,并已取得局部进展;例如在CASE工具系统中使用专家系统,又如使用专家系统实现测试自动化。
单元(称为服务)通过定义良好的接口和契约联系起来。
·接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
2. 服务(service)是封装成用于业务流程的可复用构件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。
3. SOA的特点
·松耦合
①在该体系架构中,客户端不和任何服务器相关联,它只和服务相联系,所以客户端和服务器的集成不影响客户端应用程序。
②无论老的或者新的功能模块都可以被封装成服务构件被发布。
③功能构件和它们的接口分离,所以新的接口可以非常方便地插入。
④在复杂的应用程序里,业务过程的控制可以被隔离:引入一个业务规则引擎用来控制已经定义好的业务过程流。引擎根据工作流的状态调用各种不同的服务。
⑤服务可以在运行时动态地合成进来。
⑥通过配置文件进行绑定,所以可以非常容易地适应各种新的需要。
·明确定义的接口
·服务交互必须是明确定义的
· Web 服务描述语言(Webservices Description Language,WSDL)是受到广泛支持的方法,用于描述服务请求者所要求的绑定到服务提供者的细节
· 服务
·调用操作的消息
·构造这种消息的细节
· 关于向何处发送用于构造这种消息的处理细节的消息的信息
· 无状态的服务设计
· 服务应该是独立的、自包含的请求,在实现时它不需要从一个请求到另一个请求的信息或状态
· 服务不应该依赖于其他服务的上下文和状态。当需要依赖时,它们最好定义成通用业务流程、函数和数据模型
补充内容:云计算(PPT)
1. 云计算的定义
云计算(Cloud Computing ):是分布式处理(Distributed Computing)、并行处理(ParallelComputing)和网格计算(Grid Computing)的发展,或者说是这些计算机科学概念的商业实现。是指基于互联网的超级计算模式–即把存储于个人电脑、移动电话和其他设备上的大量信息和处理器资源集中在一起,协同工作。在极大规模上可扩展的信息技术能力向外部客户作为服务来提供的一种计算方式。
2. 云计算的优势:
①开发容易快速
②无多余的开支
③每月花费低
④IT人员减少,费用降低
⑤提供最新的技术和功能
⑥支持、推行IT标准
⑦系统和信息共享更容易
3. 云计算的应用模型
·云计算三种服务方式
·SAAS( Software as a Service )
·PAAS(Platform as a Service )
·IAAS(Infrastructure as a Service )
云计算的应用—IAAS(Infrastructure as a Service)
实现模式
·完全操作系统(软硬件)接入
·防火墙
·路由器
·负载平衡
优势
·节省费用/所付及所用
·即时升级
·安全
·可靠
·APIs
实例
当你想运行成批的程序组,但是没有合适的软硬件环境,可使用Amazon的EC2。
当你想在网络上发布一个短期(几天到几个月)的网站,可使用Flexiscale。
云计算的应用—PAAS( Platform as a Service )
实现模式
·平台价格昂贵
·需求估算不科学
·平台管理复杂麻烦
流行的服务
·存储
·数据库
·扩展性
优势
·节省费用/所付及所用
·即时升级
·安全
·可靠
·APIs
实例
当你想把一个大容量的文件上传到网络上,允许35000个用户使用2个月的时间,可使用Amazon的Cloud Front即时升级。
当你想在网络上存储大量的文档,但是你没有足够的存储空间,可使用Amazon的S3。可靠。
云计算的应用—SAAS( Software as a Service )
实现模式
·在中小企业盛行
·无需管理软硬件
·服务通过浏览器实现
优势
·无浪费费用
·即时扩展
·安全
·可靠
·APIs
实例
·CRM
·财务计划
·HR
·文字处理
·Email
云计算的应用
IaaS、PaaS & SaaS共性
·无浪费费用
·即时扩展
·安全
·可靠
·APIs
优势
·用户花费低
·减少底层管理职责
·允许意想不到的资源装载
·业务应用实现迅速
风险
·安全性
·宕机问题
·接入问题
·独立性
·协同互动问题
第七章 软件测试
1. 软件测试的概念
2. 软件测试的原则
· Davis 提出了一组指导软件测试的基本原则:
①所有的测试都应根据用户的需求来进行。
②应该在测试工作真正开始前的较长时间内就进行测试计划(测试规划)的编写。一般而言,测试计划可以在需求分析完成后开始,详细的测试用例定义可以在设计模型被确定后立即开始,因此,所有测试可以在任何代码被编写前进行计划和设计。
③Pareto 原则应用于软件测试。Pareto 原则意味着测试发现的80%的错误很可能集中在20%的程序模块中。
④测试应从“小规模”开始,逐步转向“大规模”。即从模块测试开始,再进行系统测试。
⑤穷举测试是不可能的,因此,在测试中不可能覆盖路径的每一个组合。然而,充分覆盖程序逻辑,确保覆盖程序设计中使用的所有条件是有可能的。
⑥为达到最佳的测试效果,提倡由第三方来进行测试。
·其他的测试原则:
①在设计测试用例时,应包括合理的输入条件和不合理的输入条件
②严格执行测试计划,排除测试的随意性
③应当对每一个测试结果做全面检查
④妥善保存测试计划、测试用例、出错统计和最终分析报告,为维护提供方便
⑤检查程序是否做了应做的事仅是成功的一半,另一半是检查程序是否做了不该做的事。
⑥在规划测试时不要设想程序中不会出错误
3. 测试用例的设计方法大体可分为两类
白盒测试/白箱测试
把测试对象看作一个透明的盒子,根据程序内部的逻辑结构及有关信息设计测试用例
黑盒测试/黑箱测试
把测试对象看做一个黑盒子,完全不考虑程序内部的逻辑结构和内部特性
4. 白盒测试
又称结构测试、逻辑驱动测试或基于程序的测试
把测试对象看作一个透明的盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按预定的要求正确地工作。
主要用于对模块的测试
白盒法常用的测试方法
①基本路径覆盖测试
根据程序或设计图画出控制流图,并计算其区域数,然后确定一组独立的程序执行路径,最后为每一条基本路径设计一个测试用例
②逻辑覆盖测试
考察使用测试数据运行被测程序时对程序逻辑的覆盖程度
通常希望选择最少的测试用例来满足所需的覆盖标准
语句覆盖:每个可执行语句都至少执行一次
判定覆盖:每个判定的每个分支至少经过一次
条件覆盖:每个判定中的每个条件的所有可能结果都至少出现一次
判定-条件覆盖:每个判定的所有可能结果都至少执行一次,并且,每个判定中的每个条件的所有可能结果都至少出现一次
条件组合覆盖:每个判定中条件结果的所有可能组合都至少出现一次
路径覆盖:每条可能执行到的路径都至少经过一次(如果程序中包含环路,则要求每条环路至少经过一次)
③数据流测试
·根据程序中变量的定义(赋值)和引用位置来选择测试用例
④循环测试
·简单循环、嵌套循环、串接循环和非结构循环
⑤检查程序是否做了应做的事仅是成功的一半,另一半是检查程序是否做了不该做的事。
⑥在规划测试时不要设想程序中不会出错误
5. 黑盒测试
黑盒法是把测试对象看做一个黑盒,测试时完全不考虑程序内部的逻辑结构与内部特性,只需根据需求规格说明书,测试程序的功能或程序的外部特性,因此黑盒发又称为功能测试或数据驱动测试。
黑盒测试法注重于测试软件的功能需求,主要试图发现下列几类错误:功能不对或遗漏;性能错误;初始化和终止错误;界面错误;数据结构或外部数据库访问错误。
黑盒法的主要测试方法:
①等价分类法
·将所有可能的输入数据划分成若干个等价类,然后在每个等价类中选取一个代表性的数据作为测试用例
②边界值分析法
·挑选那些位于边界附近的值作为测试用例
③错误推测法
·凭以往的经验和直觉推测程序中某些可能存在的各种错误,从而针对性地设计测试用例
④因果图法
·既考虑输入条件的组合关系,又考虑输出条件对输入条件的依赖关系
⑤比较测试法
分别开发二个软件版本,用相同的测试用例对二个版本的软件分别进行测试,比较其测试结果
6.软件测试的策略
·单元测试
单元测试(UnitTesting),也称模块测试(Module Testing)。测试的主要目的是检查模块内部的错误。因此,测试方法应以白盒法为主。
单元测试的内容
①模块接口
②局部数据结构
③重要的执行路径
④边界条件
⑤错误处理
·单元测试步骤:
由于被测试的模块往往不是独立的程序,它处于整个软件结构的某一层位置上,被其他模块调用或调用其他模块,其本身不能单独运行,因此在单元测试时,需要为被测试模块设计若干辅助测试模块。辅助模块有两种
一种是驱动模块(driver),用以模拟主程序或者调用模块的功能,用于向被测模块传递数据,接收、打印从被测模块返回的数据。一般只设计一个驱动模块。
另一种是桩模块(stub),用于模拟那些由被测模块所调用的下属模块的功能,可以设计一个或者多个桩模块,才能更好地对下属模块进行模拟。
·集成测试(Integrated Testing)
集成测试(IntegratedTesting)是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统而进行的测试,也称为联合测试或组装测试。重点测试模块的接口部分,需设计测试过程所使用的驱动模块或桩模块。测试方法以黑盒法为主
集成的方式
·非渐增式测试
非渐增式测试方法采用一步到位的方法来集成系统。首先对每个模块分别进行单元测试,然后再把所有的模块按设计要求组装在一起进行测试。
非渐增式是将所有的模块一次连接起来,简单、易行,节省机时,但测试过程中难于查错,发现错误也很难定位,测试效率低。
·渐增式测试
它的集成式逐步实现的,组装测试也是逐步完成的,也可以说它把单元测试与组装测试结合起来进行的。该测试是逐个把未经过测试的模块组装到已经测试过得模块上去,进行组装测试,每加入一个新模块进行一次集成的测试。重复此过程直至程序组装完毕。
在增量集成测试过程中发现的错误,往往与新加入的模块有关。
增量式集成又可分为自顶向下结合和自底向上结合
α测试和β测试
α测试是邀请某些有信誉的软件用户与软件开发人员一道在开发场地对软件系统进行测试,其测试环境要尽量模拟软件系统投入使用后的实际运行环境。在测试过程中,软件系统出现的错误或使用过程中遇到的问题,以及用户提出的修改要求,均要由开发人员完整、如实地记录下来,作为对软件系统进行修改的依据。α测试的整个过程是在受控环境下,由开发人员和用户共同参与完成的。α测试的目的是评价软件的FLURPS,其中FLURPS 表示对一下项目的测试:
①Function Testing(功能测试)
②Local Area Testing(局部化测试)
③Usability Testing(可使用性测试)
④Reliability Testing (可靠性测试)
⑤Performance Testing (性能测试)
⑥Supportability Testing(可支持性测试)
β测试是由软件产品的全部或部分用户在实际使用环境下进行的测试。整个测试活动是在用户的独立操作下完成的,没有软件开发人员的参与。β测试是投入市场前由支持软件预发行的客户对FLURPS 进行测试,主要目的是测试系统的可支持性。β测试的涉及面最广,最能反映用户的真实愿望,但花费的时间最长,不好控制。一般地,软件公司与β测试人员之间有一种互利的协议。即β测试人员无偿地为软件公司做测试,定期递交测试报告,提出批评与建议。而软件公司将向β测试人员免费赠送或以很大的优惠价格提供软件的正式版本。
综合测试策略
一般都应该先进行静态分析,再考虑动态测试。
- 单元测试
通常应该先进行“人工走查”,再以白盒法为主,辅以黑盒法进行动态测试。使用白盒法时,只需要选择一种覆盖标准,而使用黑盒法时,应该采用多种方法。
- 组装测试
关键是要按照一定的原则,选择组装模块的方案(次序),然后再使用黑盒法进行测试。在测试过程中,如果发现了问题较多的模块,需要进行回归测试时,再采用白盒法。
- 确认测试、系统测试
应该以黑盒法为主。确定测试中进行软件配置复查,主要是静态测试。
第九章 软件维护
1. 软件维护的类型
软件维护是指软件系统交付使用以后,为了改正错误或满足新的需求而修改软件的过程。按照不同的维护目的,维护工作可分成4类。
完善性维护(Perfective Maintenance)
这种扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活动称为完善性维护。
此项维护的策略是,可以使用功能强、使用方便的工具,或采用原型化方法开发的等。
适应性维护(Adaptive Maintenance)
适应性维护是为了适应计算机的飞速发展,使软件适应外部新的硬件和软件环境或者数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)发生的变化,而进行修改软件的过程。
它主要的维护策略是,对可能变化的因素进行配置管理,将因环境变化而必须修改的部分局部化,即局限于某些程序模块等。
纠错性维护(Corrective Maintenance)
对在测试阶段未能发现的,在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程称为纠错性维护。
它主要的维护策略是,开发过程中采用新技术,利用应用软件包,提高系统结构化程度,进行周期性维护审查等。
是评价软件的FLURPS,其中FLURPS 表示对一下项目的测试:
①Function Testing(功能测试)
②Local Area Testing(局部化测试)
③Usability Testing(可使用性测试)
④Reliability Testing (可靠性测试)
⑤Performance Testing (性能测试)
⑥Supportability Testing(可支持性测试)
β测试是由软件产品的全部或部分用户在实际使用环境下进行的测试。整个测试活动是在用户的独立操作下完成的,没有软件开发人员的参与。β测试是投入市场前由支持软件预发行的客户对FLURPS 进行测试,主要目的是测试系统的可支持性。β测试的涉及面最广,最能反映用户的真实愿望,但花费的时间最长,不好控制。一般地,软件公司与β测试人员之间有一种互利的协议。即β测试人员无偿地为软件公司做测试,定期递交测试报告,提出批评与建议。而软件公司将向β测试人员免费赠送或以很大的优惠价格提供软件的正式版本。
综合测试策略
一般都应该先进行静态分析,再考虑动态测试。
- 单元测试
通常应该先进行“人工走查”,再以白盒法为主,辅以黑盒法进行动态测试。使用白盒法时,只需要选择一种覆盖标准,而使用黑盒法时,应该采用多种方法。
- 组装测试
关键是要按照一定的原则,选择组装模块的方案(次序),然后再使用黑盒法进行测试。在测试过程中,如果发现了问题较多的模块,需要进行回归测试时,再采用白盒法。
- 确认测试、系统测试
应该以黑盒法为主。确定测试中进行软件配置复查,主要是静态测试。
第九章 软件维护
1. 软件维护的类型
软件维护是指软件系统交付使用以后,为了改正错误或满足新的需求而修改软件的过程。按照不同的维护目的,维护工作可分成4类。
完善性维护(Perfective Maintenance)
这种扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活动称为完善性维护。
此项维护的策略是,可以使用功能强、使用方便的工具,或采用原型化方法开发的等。
适应性维护(Adaptive Maintenance)
适应性维护是为了适应计算机的飞速发展,使软件适应外部新的硬件和软件环境或者数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)发生的变化,而进行修改软件的过程。
它主要的维护策略是,对可能变化的因素进行配置管理,将因环境变化而必须修改的部分局部化,即局限于某些程序模块等。
纠错性维护(Corrective Maintenance)
对在测试阶段未能发现的,在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程称为纠错性维护。
它主要的维护策略是,开发过程中采用新技术,利用应用软件包,提高系统结构化程度,进行周期性维护审查等。