软件工程-实践者的研究方法-内容浓缩--厦大软院

原创 2006年06月05日 22:33:00

期末考了,我们班其他同学整理的一些资料,(自己有作过一些修改),对复习大有好处哇。。。感谢ING......

内容很概括,但都说出了最重要的部分,拿出来和大家分享。。。。^_^

_______________________________________________________________

                                                        问答题

1.软件产品的特征是什么?

          软件是与计算机系统运行和操作有关的程序、规程、规则及任何与之有关的文档和数据。软件产品的特征是:

         软件是被开发和设计的,而不是传统意义 上被制造的;

         软件是逻辑产品:它没有明显的物理形态,无需对实体进行制造和加工,但需要设计、实施和维护的生产过程。软件一旦开发成功,就可以大量进行复制。软件不会磨损”,不过它会退化;虽然软件产业正在向基于构件的组装前进,大多数软件仍是定制的;

2.什么是软件危机?其产生的原因是什么?

          软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题表现在以下几个方面:用户对开发出的软件很难满意。软件产品的质量往往靠不住。一般软件很难维护。软件生产效率很低。软件开发成本越来越大。软件成本与开发进度难以估计。软件技术的发展远远满足不了计算机应用的普及与深入的需要。

          造成软件危机的主要原因:  用户的需求描述不精确;软件人员对用户需求的理解与用户的原意不一致;对大型的软件项目缺乏有力的组织和管理;  容易产生疏漏和错误;  缺乏有力的方法学和工具的支持,过分依赖开发人员的技巧和经验; 软件的复杂性和人类智力的局限性。

3. 软件过程是为开发高质量软件所需要完成的任务的框架.

软件工程是一种层次化的技术。支持软件工程的根基就在于对质量的关注。软件工程的基础是过程层。软件工程过程是将技术层结合在一起的凝聚力,使得计算机软件能够合理和及时地开发。过程定义了一组关键过程区域的框架。软件工程方法为软件开发提供了 如何做的技术,软件工具为软件工程方法提供了自动的或半自动的软件支撑环境

 

4. 软件生存期模型(也称软件开发模型、软件过程模型、软件工程范型)是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。

线性顺序模型

优点:1、它提供了一个摸板,这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。

缺点:开发初期需要清楚全部需求;开发周期长、风险大。

原型实现模型

          初始阶段人们对软件的需求认识常常不够清晰,第一次只是试验开发,其目标只是在于探索可行性,弄清软件需求。

          由客户评估并进一步精化待开发软件的需求。

          逐步调整原型使其满足客户的需求,这个过程是迭代的。

          优点1、如果客户和开发者达成一致协议:原型被建造仅为了定义需求,之后就被抛弃或者部分抛弃, 那么这种模型很合适了。2、迷惑客户抢占市场,这是一个首选的模型。

          瀑布方法假设当线性序列完成之后就能够交付一个完善的系统。

          原型实现模型设计成帮助客户(或开发者)理解需求,它并不是交付一个最终的产品。

          演化模型是迭代的,它的特征是使软件工程师逐渐地开发逐步完善的软件版本。

增量模型

增量模型融合了线性顺序模型的基本成分(重复地应用)和原型实现的迭代特征。

每一个线性序列产生软件的一个可发布的增量。第一个增量往往是核心的产品。客户对每一个增量的使用和评估,都做为下一个增量发布的新特征和功能

优点不能在设定的期限内完成产品时可以先开发核心产品,先发布部分功能给用户,起镇静剂的作用。

螺旋模型

与增量模型差不多,但是螺旋模型被划分为若干框架活动,也称为任务区域

         优点:1、对于大型系统及软件的开发,这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险增加了风险分析,需要相当的风险分析评估的专门技术,且成功依赖于这种技术。当没有发现,就惨了。

没有最有效的,只有最适合的,只能根据具体的项目特点和自身人力物力等资源情况来选择合适的工程范型,才能发挥项目范型的作用。

 

第四章  软件过程和项目的度量

量化是管理的一个重要手段和基础。只有通过量化,才能深刻了解所研究的对象。软件度量是对收集到的原始数据,采用一些数学函数来计算,以测量过程、项目、产品的性能。度量方法分为:直接度量(代码行)和间接度量(功能点);

度量范围分为:过程度量(改进过程)和项目度量。

 

功能点:

面向功能度量用一种称为功能点的测量。

功能点是基于软件信息领域的可计算的(直接的)测量及软件复杂性的评估而导出的。

     生产率=功能点数(或千代码行数)/每人月

     成本=总费用/功能点数(或千代码行数)

 

一些概念:

检查点(Check Point): 指在规定的时间间隔内对项目进行的检查与复审工作,通过比较实际进展与计划进度的差距,并根据差距进行调整。

里程碑(Mile Stone): 完成阶段性工作的标志,往往是一些重要活动的完工,或重要文档的交付,或阶段评审的通过。

基线(Base Line): 指一个(或一组)配置项在项目生命期的不同时间点上通过正式评审而进入正式受控的一种状态。基线其实是一些重要的里程碑。基线一旦建立后,以后的任何更改都需要受到控制。

 

第五章 软件项目计划

工作量:用PM来度量,接着计算LOCFP的期望值 EE a4mb)/6

成本:元。

COCOMO模型构造性成本模型),是一种自顶向下项目成本估算模型,估算公式为:

E=A(KDSI)b  E:开发成本(PMMM)DSI:源指令条数,不包括注释,KDSI=1000DSI

TDEV(度量单位为月)表示开发进度

初级COCOMO模型是一个静态单变量模型,它用源代码行数(LOC)为自变量的(经验)函数来计算软件开发工作量。复杂度:组织型(小型),半独立型(中等),嵌入型

 

7 项目进度安排与跟踪

项目管理者的目标是定义所有项目任务,识别关键任务,然后跟踪关键任务的进展。管理者必须建立一个具有一定详细程度的进度表,使得项目管理者能够监督进度,并控制整个项目。

进度安排的准确程度常常比成本估算的准确程度更重要。但如果进度安排落空,会导致市场机会丧失,用户不满意,其损失将更大。

 

 

定义任务网络

多个开发活动和任务并行进行的可能性,计划者必须确定任务之间的依赖关系,

应该注意那些位于关键路径之上的任务,为了保证整个项目的如期完成,就必须保证这些任务能够如期完成.

任务网络是一个项目的任务流程的图形表示。输入任务序列和依赖关系

     网络图和甘特图是项目时间管理中常用的两种图示。

     利用网络图和甘特图,可以清楚地表示出项目中所有活动的先后顺序、依赖关系以及每个活动的持续时间。条形图(甘特图)描述了由谁具体负责某个模块及该模块的开始时间和结束时间;

     一般地,把网络图中最长的路径称为项目的关键路径。

      找出项目关键路径的意义在于,关键路径上的所有活动在项目中持续时间最长。如果要压缩整个项目的执行时间,那么,就必须首先缩短关键路径上某个活动的持续时间。当改变了关键路径的持续时间后,网络图中其他的路径有可能会变成新的关键路径。关键路径上的每个任务出现延迟都会导致整个项目的延迟,而不在关键路径上的活动,则存在一定的可延迟时间,但超出许可范围后,也会导致项目的延迟.

 

工作分解结构(Work Breakdown StructureWBS)是项目范围管理中常用的范围分析技术之一。

编制工作分解结构的主要目的是将项目的可交付成果分解成较小的、更易管理的单元,直到每个单元的可交付成果足够具体,易于管理,并足以支持未来的项目活动(如计划编制、执行、控制和收尾等)。并依据工作任务的划分制定详细的进度和费用计划

关键路径(CPM):任何项目都会有一条总的关键路径。关键路径是为确保项目按所需日期完成而必须密切跟踪的路径

 

挣值分析是项目费用管理中常用的一种费用控制方法。

挣值(Earned Value,也译为盈余值)可以较为客观地显示出项目计划工作量和实际工作量之间的偏差,确定项目费用是否按计划执行。

计划工作预算成本,记作BCWS我们把BCWS曲线作为费用控制和分析的基准。

我们定期记录项目到当前时间为止的总费用、我们把后一费用称为己完成工作实际成本,记作ACWP

BCWS曲线和ACWP曲线的偏离反映了项目预算费用和实际费用的偏差。但这一偏差不能完全说明项目的费用和进展情况。(不知道实际完成的工作量)

找出在项目预算中,要完成这些工作量,需要多少费用。已完成工作预算成本通常被记为BCWPEV,这个数值也就是我们在前面所说的挣值(盈余值)了。(我实际中完成了这么多,按照预算我需要多少费用呢???但是实际是多少呢?)

 

项目的费用偏差CVBCWPACWP

  费用偏差考虑到了工作量的因素,客观地反映了项目在某一时刻预算费用与实际费用的偏差情况。费用偏差为正,表示项目目前的费用比较节省,在预算之内;费用偏差为负,表明项目在费用控制上超出了预算。

     项目的进度偏差SVBCWPBCWS (为负,则有所延误,为正,提前)

     费用执行情况指数 CPIBCWP/ACWP

进度执行情况指数SPIBCWP/BCWS

     预测完工费用=总预算费用/CPI

利用挣值分析法,可以在项目的执行过程中随时监控项目的实际费用是否存在节约或超支的情况,也可以预测项目完工时的总费用。根据挣值分析的结果,可以适时调整项目的费用和进度计划,以保证项目的总费用不超出预算。

 

9  软件配置管理

软件配置管理Software Configuration Management, SCM)是指通过执行版本控制、变更控制等规程,以及使用合适的配置管理软件,来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。(保护性活动)

软件研发和管理过程中会产生许许多多的工作成果,例如文档、程序和数据等,它们都应当被妥善地保管起来,以便查阅和修改。凡是纳入配置管理范畴的工作成果统称为配置项(Configuration ItemCI)。软件配置项(Software Configuration ItemsSCI)

 

由正式技术评审而得到的软件配置项的正式文本构成了基线。基线Baseline由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结了,不能再被任何人随意修改(见变更控制规程)。其作用是使连续的工作在这些点上断开,以便于检查和肯定阶段成果。基线需要定期审核,以验证与文档的一致性。

 

第十三章  软件设计基础

软件系统的模块化是指整个软件被划分成若干单独命名和可编址的部分,称之为模块。这些模块可以被组装起来以满足整个问题的需求。

把问题/子问题的分解与软件开发中的系统/子系统或系统/模块对应起来,就能够把一个大而复杂的软件系统划分成易于理解的比较单纯的模块结构。

 

parnas 方法提倡的信息隐蔽是指,每个模块的实现细节对于其它模块来说是隐蔽的。也就是说,模块中所包含的信息(包括数据和过程)不允许其它不需要这些信息的模块使用。独立的模块间仅仅交换为完成系统功能而必须交换的信息。信息隐蔽的目的

提高模块的独立性,减少修改或维护时的影响面。

 

模块独立性, 是指软件系统中每个模块只涉及软件要求的具体的子功能, 而与软件系统中其它的模块的接口是简单的.例如, 若一个模块只具有单一的功能且与其它模块没有太多的联系, 则称此模块具有模块独立性。一般采用两个准则度量模块独立性。即模块间耦合和模块内聚。耦合是模块之间的互相连接的紧密程度的度量。 内聚是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量。

模块独立性比较强的模块应是高内聚低耦合的模块。

 

调用返回的结构:相对容易修改和扩张的程序结构。

主程序/子程序体系结构:将功能分解为一个控制层次,其中“主”程序调用一组程序构件,这些程序构件又去调用别的程序构件。也可以是远程过程调用体系结构。

 

第十七章  软件测试

测试用例设计

黑盒测试:黑盒测试又叫做功能测试或数据驱动测试。

等价类划分:等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。划分为有效等价类和无效等价类。(知道怎么划分吗,看案例)

 范围,输入不同的值,输入规则(一个有效类,无效类若干),

边界值分析:是对等价类划分方法的补充。大量的错误是发生在输入或输出范围的边界上,而不是在输入范围的内部。(案例)

  白盒测试:对程序所有逻辑路径进行测试,白盒测试又称为结构测试或逻辑驱动测试

对程序模块的所有独立的执行路径至少测试一次

对所有的逻辑判定,取与取的两种情况都至少测试一次

在循环的边界和运行界限内执行循环体

(哪种覆盖更强,哪个包含哪个)

 语句覆盖,判定-条件覆盖,判定覆盖,条件组合覆盖,条件覆盖,路径覆盖(看下)

(一个比一个严格)

测试策略:(设计测试用例)

单元测试,集成测试(组装测试),确认测试,系统测试。

单元测试又称模块测试,是针对软件设计的最小单位 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例。主要测试:模块接口,局部数据结构,对执行路径的选择性测试是最主要的任务。边界测试。

 

集成测试(组装测试)在单元测试的基础上,需要将所有模块按照设计要求组装成为系统

自顶向下:将模块按系统程序结构,沿控制层次自顶向下进行组装。在测试过程中较早地验证了主要的控制和判断点。选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。

自底向上:从程序模块结构的最底层的模块开始组装和测试。它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

 

22      面向对象设计

抽象;信息隐蔽;功能独立性;模块性

子系统层:通过实例,包含每个子系统的表示,这些子系统使得软件能够满足客户定义的需求,并实现支持客户需求的技术基础设施。

类和对象层:通过CRC,包含类层次,它们使得系统能够以通用化方式创建并不断逼近特殊需求,这层也包含了每个对象的设计表示。

消息层:通过对象-消息模型,包含使得每个对象能够和其协作者通信的细节,本层建立了系统的外部和内部接口。

责任层:通过CRC,包含针对每个对象的所有属性和操作的数据结构和算法的设计。

 

系统设计:着重于构造一个完全的产品或系统所需的构件的布局.,如何把系统拆解成子系统

对象设计:强调个体对象的详细布局。

 

类库:库复用的问题是库通常以一组可复用的子例程的形式存在,而不是可复用的设计.

工具包通常也只是促进代码复用,而不是设计复用.

库和工具包复用的关键特征是设计者负责整个产品的控制逻辑.

框架: 构成软件的一个特定类的可复用设计的一组协同类.

应用框架与库或工具包相反,它提供控制逻辑,开发者负责特定操作的设计.

特定应用操作插入的地方通常称为热点”.在本质上是总体软件设计的复用

复用一个框架比复用工具包更能使产品开发得更快. 因为:多数设计随着框架一起被复用;框架的控制逻辑比操作更难设计;框架的控制逻辑已得到测试.Eclipse

设计者不用为系统的总体设计操心,只要一心一意地开发扩展功能.

动态框架自动地在特定的目录下搜寻符合规则的插入件文件,验证接口后,就登记连接进来,和框架动态地焊接在一起.

使用平台,编写的代码是主体,会主动地调用平台提供的服务;

使用框架,框架是主动的主体,编写的代码是被动的,要被框架去调用.

 

设计模式是普通设计问题的解决方案,这类问题以一组交互类的形式出现,需要由用户根据需要定制这些交互类以形成专门的设计.带阴影的方框通过线连接起来代表交互类.

阴影的方框内白色方框代表为专门的设计定制的类.

在软件业中设计模式是面向对象系统使用的一些可重用的已经得到了很好证明的巧妙通用的简单的设计解决方案.

分为:创建模式,结构模式,行为模式。

模式包括:名字,问题,解决方案,效果。

 

抽象工厂

     --把各种抽象零件组合起来称为抽象产品

     --所谓抽象的是指不考虑具体实现,只 注意接口API”

抽象工厂的基本概念是把类实例的创建虚拟化,不用具体说明究竟用哪一个具体类,而由抽象工厂的子类来控制。这个模式非常适合隐藏多平台的差异。

意图:提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类。

客户仅与抽象类定义的接口交互,而不使用特定的具体类的接口。

效果:它隔离了具体的类,它使得易于交换产品系列。

 

 

 

框架与设计模式的关系

框架与设计模式是分不开的.在好的框架中,多种设计模式得到广泛的应用.设计模式帮助框架取得高层次的复用,而无需改变代码.比如:

   --观察者模式可以让扩展部分的代码连接到框架中,接收来自框架的各种消息,以便作出相应的处理.

框架:一组实现类的集合,实现和设计的重用,针对特定的问题领域而特别设计的。

设计模式:未实现类的小集合,仅仅设计的重用,没有特定问题域,通用性。

1. 设计模式比框架更抽象;2. 设计模式是比框架更小的体系元素;3. 框架比设计模式更加特例化;

 

对象设计(OOAàOOD

设计模型建立在分析模型的基础上,可以看成是分析模型的精化和细化。

设计模型添加了详细信息和特定技术的解决方案。设计模型必须包括实现的详细信息。

分析类来自于问题域,是系统中类的高级概念视图,其属性集和操作可能不完整。

设计类是已经完成了规格说明并且达到能够被实现的程度的类。

每个设计类是一些能真正做好一两件事情的小的、高内聚的单元。

 

23 面向对象测试

但并不能减少繁重的测试量。因为每次复用是一个新的使用语境,要谨慎地重新测试。

为了获得面向对象系统的高可靠性,将需要更多、而不是更少的测试。

OO 分析和设计模型的复审是特别有用的:

相同的语义结构,如,类、属性、操作、消息,出现在分析、设计和代码阶段;

在分析阶段发现的类属性定义中的问题将遏制问题传播到设计和编码阶段。

分析和设计模型不能进行传统意义上的测试,因为它们不能被执行。

正式的技术复审可用于检查分析和设计模型的正确性、完整性和一致性

 

测试策略:

     传统的测试计算机软件的策略是从小型测试开始,逐步走向大型测试

     即,从单元测试开始,然后逐步进入集成测试,最后是确认测试和系统测试。

 

23 面向对象测试

为了充分地测试OO 系统,必须做好三件事:

(1) 测试的定义必须扩大到包括用于OOA OOD 模型的错误发现技术;

(2)单元和集成测试策略必须有很大的改变;

(3)测试用例的设计必须考虑OO 软件的独特特征。

 

         OO 模型从对系统需求的表示开始,逐步演化为详细的类模型、类连接和关系、系统设计和分配、以及对象设计。

         在每个阶段,测试模型,以试图在错误传播到下一次迭代前发现错误。

 

传统软件测试与面向对象测试的区别与联系:

   测试策略:

  相同点:测试的策略是一样的,传统的测试计算机软件的策略是从小型测试开始,逐步走向大型测试。即,从单元测试开始,然后逐步进入集成测试,最后是确认测试和系统测试。

不同点:单元测试的概念不同,在传统应用中,单元测试集中在最小的可编译程序单位——子程序(如,模块、子例程、进程),而在面向对象软件时,最小的可测试单位是封装的类或对象。OO 软件的类测试等价于传统软件的单元测试,和传统软件的单元测试不一样,它往往关注模块的算法细节和模块接口间流动的数据,OO 软件的类测试是由封装在类中的操作和类的状态行为所驱动的。如果类的实现正确,则类的每个实例的行为也应该是正确的。

集成测试也不一样:因为面向对象软件没有层次的控制结构,传统的自顶向下和自底向上集成策略就没有意义,线程的测试:集成响应系统的一个输入或事件所需的一组类,每个线程被集成并分别测试,应用回归测试以保证没有产生副作用。使用的测试

:(1)通过测试那些几乎不使用服务器类的类(称为独立类)来开始系统的构造,

   2)在独立类测试完成后,下一层的使用独立类的类,称为依赖类,被测试。

   3)这个依赖类层次的测试序列一直持续到构造完整个系统。

与传统集成不同,尽可能避免使用驱动程序和桩(stubs)作为替代操作。

 

测试用例设计:

OO 类是测试用例设计的目标。因为属性和操作是被封装的,对类之外操作的测试通常是徒劳的。

构建独立类的测试用例:对其实例化,根据前置条件盒后置条件构建(OCL),根据状态转换图构建,构建测试驱动程序,

测试驱动程序是一个运行测试用例并收集运行结果的程序。测试驱动程序的设计应该尽量简单。测试驱动程序应该易于维护。

交互测试:这些对象之间相互协作以解决某些问题,确保对象的消息传送能够正确进行。测试类的层次结构,子类测试(语境可能不一样了),分布式对象测试。

 

测试用例设计的区别:

   相同点:测试用例设计方法:白盒测试,黑盒测试,use cases

和传统测试用例设计不同,传统测试是由软件的输入加工输出视图或个体模块的算法细节驱动的;

面向对象测试关注于设计合适的操作序列以测试类的状态。

 

OOD与传统的金字塔的区别:

 数据设计侧重于数据结构的定义。

系统结构设计,包括接口设计和体系结构设计,定义软件系统各主要成份之间的关系。

过程设计则是把结构成份转换成软件的过程性描述。在编码步骤,根据这种过程性描述,生成源程序代码,然后通过测试最终得到完整有效的软件。

子系统层。包含每个子系统的表示,这些子系统使得软件能够满足客户定义的需求,并实现支持客户需求的技术基础设施。

类和对象层。包含类层次,它们使得系统能够以通用化方式创建并不断逼近特殊需求,这层也包含了每个对象的设计表示。

消息层。包含使得每个对象能够和其协作者通信的细节,本层建立了系统的外部和内部接口。

责任层。包含针对每个对象的所有属性和操作的数据结构和算法的设计。

OOD和结构化设计异同

结构化设计方法:程序被划分成许多个模块,这些模块被组织成一个树型结构。这棵树的根就是主模块,叶子就是工具模块和最低级的功能模块。同时,这棵树也表示调用结构:每个模块都调用自己的直接下级模块,并被自己的直接上级模块调用。

OOD就是根据需求决定所需的类、类的操作以及类之间关联的过程 OOD的目标是管理程序内部各部分的相互依赖。为了达到这个目标,OOD要求将程序分成块,每个块的规模应该小到可以管理的程度,然后分别将各个块隐藏在接口(interface)的后面,让它们只通过接口相互交流。

传统方法应用清楚的符号和一组启发规则将分析模型映射到设计模型。与传统设计方法一样,OOD应用数据设计(当属性被表示时)接口设计(当消息模型被开发时)以及构件级设计(在过程设计中)。但OO更多关心对象间协作而不是系统构建间的控制流。

结构化设计方法中上方的模块需要调用下方的模块,所以这些上方的模块就依赖于下方的细节。换句话说,与问题领域相关的抽象要依赖于与问题领域无关的细节!这也就是说,当实现细节发生变化时,抽象也会受到影响。而且,如果我们想复用某一个抽象的话,就必须把它依赖的细节都一起拖过去。

而在OOD中,我们希望倒转这种依赖关系:我们创建的抽象不依赖于任何细节,而细节则高度依赖于上面的抽象。这种依赖关系的倒转正是OOD和传统技术之间根本的差异,也正是OOD思想的精华所在。

 

类是最小的测试单位

         考虑面向对象软件时,单元的概念发生了变化。

         封装驱动了类和对象的定义,这意味着每个类和类的实例(对象)包装了属性(数据)和操纵这些数据的操作(方法或服务),而不是个体的模块。

         最小的可测试单位是封装的类或对象,

         类包含一组不同的操作,并且某特殊操作可能作为一组不同类的一部分存在;

         不再孤立地测试单个操作(传统的单元测试观点),而是将操作作为类的一部分。

 

子类重用父类的测试用例

即使现存类已经被完全测试过我们还是必须重测试从某现存类导出的子类,原因是:子类在继承父类的过程中,可能添加了属性或行为,或者进行了方法的重写等,这些扩展部分并没有在超类中被测试过。

我们可以有选择的使用为现存类设计的测试案例。若从现存类导出的子类被用于相同的问题域,则可以参考为现存类设计的测试案例,但并不是完全不变的照搬使用;若导出的子类被用于完全不同的问题域,则原先测试案例的参考价值就比较小。

 

白盒测试与黑盒测试

白盒测试:遍历所有逻辑路径,从理论上可以彻底检查程序的正确性。

黑盒测试:穷举输入数据来测试输出,此时的输入很可能是无穷的以致无法穷举。

  论:穷举测试是一种简单的测试方法但不可行。

单元测试:值得但有时很难执行。元测试是集成测试、用户测试的基础,只要有单元模块的代码就应该进行单元测试。但是对于耦合很紧的多个模块,单元测试也许就变得成本太大也很难执行。

 

结构的划分

           程序结构分为水平和垂直划分

         水平划分使软件的主要功能相互分离,从而使变更变得简单,同时也能使对系统的扩展变得容易完成且无副作用。

         垂直划分要去在程序体系结构中控制和工作应该自顶向下分布。顶层模块应执行控制功能而尽量少作实际处理工作;底层的模块应是工作者,负责完成所有的输入、计算和输出任务。这样一来,在变更时互相之间不会受影响而产生副作用,从而使软件易于维护。

 

功能的独立性

  功能独立性是通过开发具有“单一”功能和“反对”同其他模块的过分交互的模块而实现的,换句话说,我们希望将软件设计成每个模块完成需求的特定子功能并且从程序结构的其他部分观察时具有简单的接口。独立性的模块可以将功能划分并且接口被简化了,有效模块化的软件更易于开发。这样由设计/编码修改引起的副作用受到限制,错误传播被减小,而且模块复用成为可能,因此,独立的模块更易于维护及测试。

 

 

 

 

 

 

 

 

 

 

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

索骥馆-编程语言之 《C++精髓:软件工程方法》扫描版[PDF]

内容简介:   C++是一种大型而复杂的语言,其设计目标是作为一种通用的工程语言。   本书分4个部分共19章,不仅详细介绍了C++语言的基本语法,而且讲解了C++的高级应用(如虚函数、模板...

【读书笔记】软件工程·实践者的研究方法第7版 第一部分 软件过程(第3章 敏捷开发)

敏捷方法:有时也成为轻量级方法或精简方法,敏捷过程 敏捷方法是为了克服传统软件工程中认识和实践的弱点而形成的。能够带来多方面的好处,但非万能,也不完全跟传统的软件工程实践对立。 敏捷过程:很容易适...

微软防盗版新方法-将在软件中加水印技术

来源:中国软件资讯网   据悉,Microsoft 近日申请了一项专利,描述了一种可用于下载版软件中的水印技术,以此来防止盗版。提交到美国专利和商标局的这份专利为一种将数字水印嵌入到通过因特网下载的软...
  • fsqcy
  • fsqcy
  • 2011-05-31 23:06
  • 1025
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)