新软件工程教学课件

软件工程主要内容传统软件工程方法面向对象软件工程（统一建模语言UML）软件工程中的高级课题软件过程、管理与质量参考文献«软件工程：实践者的研究方法»RogerS.Pressman著黄柏素梅宏译机械工业出版社«可视化面向对象建模技术»

刘超张莉编著北京航空航天大学出版社传统软件工程方法问题定义需求分析概要设计详细设计编码测试维护基本概念软件计算机系统中的程序及其有关文件。程序计算任务中的处理对象和处理规则的描述。文件为了便于了解程序所需的资料说明。基本概念软件的作用用户与硬件的接口计算机系统的指挥者计算机系统结构设计的重要依据基本概念软件的发展过程第一阶段：从第一台计算机上的第一个程序的出现到实用的高级程序设计语言出现之前（1946-1956）；第二阶段：从实用的高级程序设计语言出现到软件工程出现之前（1956-1968）；第三阶段：软件工程（1968-）。基本概念软件的分类：系统软件支撑软件应用软件基本概念软件危机供求关系失调开发费用失控，进度拖延可靠性差难以维护基本概念产生软件危机的原因（软件本身的特点）软件开发进展情况较难衡量软件开发质量难以评价管理和控制软件开发过程相当困难软件没有“磨损”概念，软件维护通常意味着改进或修改原来的设计基本概念

产生软件危机的原因（软件开发人员的错误观点）“有一个对目标的概括描述就足以着手编写程序了，许多细节可以在以后再补充”“所谓软件开发就是编写程序并设法使它运行”“用户对软件的要求不断变化，然而软件是柔软而灵活的，可以轻易地改动”“软件投入生产性运行以后需要的维护工作并不多，而且维护是一件很容易做的简单工作”基本概念软件工程应用计算机科学、数学及管理科学等原理，以工程化原则、方法解决软件问题的工程。其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、降低成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。基本概念软件工程的基本内容：软件设计方法论软件工具软件工程标准和规范软件工程管理软件工程理论基本概念软件工程的基本原理：严格按照计划进行管理坚持进行阶段评审实行严格的产品控制采用现代的程序技术结果要能清晰地审计开发小组人员素质要好，数量不宜多要承认不断改善软件工程实践的必要性基本概念软件生存期（过程）模型：软件生存期是软件产品或系统一系列相关活动的全周期。从形成概念开始，经过研制，交付使用，在使用中不断增补修订，直到最后被淘汰，让位于新的软件产品的过程。对软件生存期的不同划分，形成了不同的软件生存期模型。基本概念瀑布式软件生存期模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性，是一种严格线性的、按阶段顺序的、逐步细化的开发模式。定义分析设计编码测试维护基本概念

瀑布式软件生存期模型把软件开发过程划分成若干阶段，每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。在软件生存期的每个阶段都采用科学的管理技术和良好的方法与技术，而且每个阶段结束之前，都从技术和管理两个角度进行严格的审查，经确认之后才开始下一阶段的工作。基本概念瀑布式模型的特点：结构简单明了；历史较长、应用面广泛、为广大软件工作者所熟悉；已有与之配套的一组十分成熟的开发方法和丰富的支撑工具。确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常困难的；反馈信息慢。基本概念软件质量要素：正确性：软件产品准确执行软件规格说明中所规定的能力。健壮性：在异常条件下软件仍能运行的能力。可靠性：软件在给定的时间内和规定的环境条件下，按规格说明的规定成功地运行的概率。可靠性理解为正确性和健壮性之和。问题定义

问题定义的关键任务是确切地定义用户要求解决的问题，也就是确定问题的性质、工程的目标和规模。可行性研究对软件进行分析与估算确定软件作用范围问题定义可行性研究：经济可行性技术可行性法律可行性不同的方案问题定义对软件进行分析与估算：确定软件的范围估算完成软件开发任务所需的资源估算软件的成本估算和安排软件开发项目的进度问题定义确定软件的作用范围：详细描述软件的任务和具体的要求，抱括软件的功能、性能、接口和可靠性等四个方面的内容。问题定义软件计划：范围（研制的目标，主要功能，其他特性，开发概况）资源（人力资源、硬件资源、软件资源、可用性资源窗口）成本进度安排需求分析软件需求分析是软件生存期的一个重要阶段，是软件开发项目得以成功的基础。其最根本的任务是确定为了满足用户的需要软件系统必须做什么。软件需求分析是一个不断发现和决定的过程，在此过程中，软件开发者和软件申请者（用户）同样起着重要的作用。在需求分析与说明过程中，需要大量交换意见，其间充满着传错信息和发生误解的可能性：“我知道你相信你明白了你认为我所说的是什么，但是我不能肯定你是否意识到你听到的并不是我所指的意思......”。需求分析软件需求分析实现以下几个目标：给出软件系统的数据流程图与数据结构，构造一个完全的系统逻辑模型；提出详细的功能说明确定设计限定条件，规定性能要求；密切与用户的联系，使用户明确自己的任务，以便实现上述两项目标。需求分析软件需求分析包括的工作：问题的认识需求分析人员通过频繁与用户联系，充分理解用户提出的每一个功能与性能要求，从软件系统特征、软件开发全过程以及软件计划给出的资源和时间约束，来确定软件开发的总策略。评价与综合需求分析人员必须求得数据的流程和数据结构，评价优缺点；结合用户要求，修改现行的系统，提出新系统的功能，加以细化；提出软件的约束条件、响应时间、存储条件等。需求分析软件需求分析包括的工作：建立需求说明书软件需求说明书包含软件功能、性能、接口、有效性和逻辑模型的描述。为了证实软件能否被成功实现就要规定相应的检验标准，这些标准在软件开发期间将作为测试的依据。复审由软件开发人员和用户共同对需求说明书进行严格的审查。需求分析软件需求分析人员应该具备的特征：善于领会一些抽象的概念，重新整理使之成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法；善于从各种相互冲突或混淆的原始资料中吸取恰当的论据；能够理解用户的环境及领域知识；需求分析软件需求分析人员应该具备的特征：具备把系统的硬件和软件部分应用于用户环境的能力；具备良好的书面和口头形式进行讨论和交换意见的能力；具有“既能看到树木，又能看到森林”的能力。需求分析基本系统模型：软件系统的全部功能被表示成一个单一的信息变换过程：软件系统输入1输入2输入n输出n输出2输出1......需求分析需求分析信息信息流程信息结构出来的是什么进去的是什么中间如何变换单个元件是什么怎样把它们安置在一起一组元件合在一起分类各组元件之间的关系需求分析结构化分析方法（SA）SA方法采用“抽象”和“分解”两个基本手段，用抽象模型的概念，按照软件内部数据传递、变换关系，由顶向下逐层分解，直到找到满足功能需要的所有可实现的软件元素为止。SA方法采用“分解”的方式来理解一个复杂系统，“分解”需要有描述手段，数据流程图就是作为描述信息流程和分解的手段而引入的。需求分析数据流程图：表示外部实体，代表数据源和数据池。表示加工，代表接收输入，经过变换，继而产生输出的处理过程。表示数据流，代表数据的流向和路径。表示数据存储，代表系统加工的数据所存储的地方。需求分析数据流程图的特点：可以表示任何一个系统（人工的、自动的、或混合的）中的数据流程；每个表示加工的圆圈可能需要进一步分解以求得对问题的全面理解；着重强调的是数据流程而不是控制流程。需求分析例：病员监视系统病员监视系统病员护士护士病员病历基本模型病情信号报告警告信号病历数据请求提出报告需求分析本地监视中央监视报告产生更新病历护士护士病员病员病历病员的病情界限警告信号病员数据请求报告经过整理后的病员数据病情信号需求分析分解病情信号整理病员数据检查是否超出界限产生警告信号时钟整理后的病员数据日期时间病员病情界限体温血压脉搏病员数据警告信号需求分析推导数据流程图的简单准则：第一层数据流程图应当是基本的系统模型；应当仔细说明原始的输入/输出文件；所有箭头和圆圈均应当加上标注（使用有意义的名字）；必须保持信息的连续性；每次只加工一个圆圈。需求分析数据字典数据流程图中，所有的图形元素都进行了命名，所有名字的定义集中起来就构成一本数据字典。数据字典最重要的用途是作为分析阶段的工具。在数据字典中建立的一组严密一致的定义有助于改进分析员和用户之间的通信，因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员之间或者不同开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据或设计模块，则能避免许多麻烦的接口问题。需求分析信息结构信息结构是各个数据成分之间逻辑关系的一种表示方法。数据结构决定信息的组织、存取方法、结合性程度以及不同的处理方案。典型的数据结构包括标量项、顺序向量、n维空间、链接表等。需求分析分层数据结构表示法：分层框图Warnier图需求分析分层框图分层框图把信息用多层方框按照树形结构组织起来。在结构的顶层，用一个方框代表整个结构。下面各层由表示不同信息类别的方框组成，它们可以看成是上一层方框的子集。在该图的最低一层，每个框包含单独的数据实体。需求分析XX公司销售产品计算机软件计算机服务计算机硬件存储器备件处理机应用系统软件服务培训操作系统编译程序工具编辑程序测试驱动程序设计辅助工具............................需求分析Warnier图Warnier图把信息表示成一种树形数据结构。可以规定某些信息种类或信息量是重复性的，也可以说明在某一种类中信息是有条件出现的。需求分析计算机系统系统软件应用软件操作系统（P1）

编译程序（P2）工具编辑（P3）测试驱动（P4）设计辅助（P5）需求分析软件需求说明书1.概述2.信息描述(1)数据流程图(2)数据字典(3)数据结构(4)系统接口说明(5)内部接口需求分析软件需求说明书3.功能说明(1)功能(2)处理说明(3)

设计的限制4.检验标准(1)性能界限(2)测试种类(3)预期的软件响应(4)应考虑的特殊问题5.参考文献6.附录需求分析初步的用户手册当确定了人机交互作用的软件需求后，准备一份初步的用户手册是作为对所要求文件的补充往往是有用的，这种手册将起到两个作用：手册的准备迫使分析人员从用户的角度来看待软件，从而及早考虑接口方面的人机环境工程。用户可以审查一个明确描述人机接口的实际文件。需求分析软件需求说明的审查审查需求的一致性审查需求的现实性审查需求的完整性和有效性需求分析软件需求说明审查中的问题：所规定的软件目标和任务与系统的目标和任务相符合吗？与所有系统成分的重要接口都已被描述了吗？研制项目的数据流程图、数据字典、数据结构充分确定了吗？图表都清楚吗？每个图表在不加补充说明的情况下能被理解吗？主要功能在规定的范围之内吗？每一种功能被充分说明了吗？需求分析软件需求说明审查中的问题：设计的限制条件是现实的吗？开发的技术风险是什么？考虑过软件需求的其他方案吗？检验标准是否详细？他们能否确认系统是成功的？有无遗漏、重复或不一致的地方？用户是否审查了初步的用户手册？软件计划中的估算是否需要修改？需求分析用于软件需求分析的工具概要设计软件设计是把软件需求变为软件的具体方案软件设计包括两个阶段：概要设计和详细设计概要设计根据软件需求所确定的信息流程或信息结构，导出软件的总体表示----软件结构或程序过程概要设计软件结构:软件结构是一种层次化的表示，其指出了由需求分析隐含地确定的某一问题的软件解法的各个元素（称之为模块）之间的相互控制关系软件结构的演变从确定问题开始，当该问题的每个部分用一个或多个软件加以解决以后，整个问题的解也就有了概要设计P3P1P2P4P5S1S2S3S4S5概要设计软件结构的度量和术语：深度：表示控制的层数。宽度：表示控制（同一层次）总跨度。扇出数：指由一模块直接控制的其他模块的数目。扇入数：指有多少个模块直接控制一个给定的模块。上级模块下级模块概要设计程序过程：程序过程是用于描述每个模块的操作细节，是关于模块算法的详细描述，它应当包括处理的顺序、精确的判定位置、重复的操作以及数据组织和结构等。概要设计模块：模块是数据说明、可执行语句等程序对象的集合，是单独命名的并且可以通过名字来访问，例如过程、函数、子程序、宏、modula等。概要设计模块化：软件被划分成独立命名和可独立访问的被称作模块的构件，每个模块完成一个子功能，它们集成到一起满足问题需求。概要设计模块化论据：C(x)定义为问题x的感知复杂性E(x)定义为解决问题x所需要的工作量对p1和p2两个问题，若C(p1)>C(p2)，则E(p1)>E(p2)C(p1+p2)>C(p1)+C(p2)E(p1+p2)>E(p1)+E(p2)概要设计软件总成本集成成本成本/模块模块数量成本或工作量最小成本区域M概要设计实现模块化的手段：抽象：抽出事物的本质特性而暂时不考虑它们的细节。信息隐蔽：应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不可访问的。概要设计模块独立性：模块独立是指开发具有独立功能而且和其它模块之间没有过多的相互作用的模块。模块独立的意义：功能分割，简化接口，易于多人合作开发同一软件；独立的模块易于测试和维护。概要设计模块独立程度的衡量标准：耦合性：对一个软件结构内不同模块间互连程度的度量。内聚性：标志一个模块内各个处理元素彼此结合的紧密程度，理想的内聚模块只做一件事情。概要设计耦合分类：无任何连接：两个模块中的每一个都能独立地工作而不需要另一个的存在（最低耦合）。数据耦合：两个模块彼此通过参数交换信息，且交换的仅仅是数据（低耦合）。控制耦合：两个模块之间传递的信息有控制成分（中耦合）。概要设计耦合分类：公共环境耦合：两个或多个模块通过一个公共环境相互作用：

1.一个存数据，一个取数据（低耦合）；

2.都存取数据（低--中之间）。内容耦合：

1.一个模块访问另一个模块的内部数据；

2.两个模块有一部分程序代码重叠；

3.一个模块不通过正常入口而转移的另一个的内部；

4.一个模块有多个入口（意味着该模块有多个功能）。概要设计内聚分类：偶然内聚：一组任务关系松散（低）逻辑内聚：一组任务在逻辑上同属一类，例如均为输出（低）时间内聚：一组任务必须在同一段时间内执行（低）概要设计内聚分类：信息内聚：模块内所有元素都引用相同的输入或输出数据集合（中）顺序内聚：模块中的每个元素都是与同一功能紧密相关，一个元素的输出是下一个元素的输入（高）功能内聚：一个模块完成一个且仅完成一个功能（高）概要设计关于耦合性和内聚性的设计原则：力争尽可能弱的耦合性：尽量使用数据耦合，少用控制耦合，限制公共环境耦合的范围，完全不用内容耦合力争尽可能高的内聚性：力争尽可能高的内聚性，并能识别出低内聚性概要设计概要设计的启发式准则：改进软件结构，提高模块独立性模块规模应该适中（最好能写在一页纸上）大模块分解不充分；小模块使用开销大，接口复杂。尽量减少高扇出结构的数目，随着深度的增加争取更多的扇入扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块。一般来说，顶层扇出高，中间扇出少，低层高扇入。概要设计概要设计的启发式准则：模块的作用范围保持在该模块的控制范围内模块的作用范围是指该模块中一个判断所影响的所有其它模块；模块的控制范围指该模块本身以及所有直接或间接从属于它的模块。力争降低模块接口的复杂程度模块接口的复杂性是引起软件错误的一个主要原因。接口设计应该使得信息传递简单并且与模块的功能一致。概要设计概要设计的启发式准则：设计单入口单出口的模块避免内容耦合，易于理解和维护。模块的功能应该可以预测相同的输入应该有相同的输出，否则难以理解、测试和维护。概要设计设计方法：逐步精化----自顶向下设计方法结构化程序设计

结构化程序设计的基础建立在三种能够构成结构化程序的逻辑构造（顺序，选择，重复）上。面向数据的设计方法面向数据流的设计面向数据结构的设计面向对象的设计方法概要设计面向数据流的设计：面向数据流的设计方法把信息流映射成软件结构信息流的类型决定了映射的方法信息流有两种类型：变换流事务流概要设计变换流：信息沿输入通路进入系统，同时由外部形式变换成内部形式。进入系统的信息通过变换中心，经过加工处理以后再沿着输出通路变换成外部形式离开系统。概要设计信息外部表示内部表示时间输入流输出流变换中心概要设计事务流：事务流的特点是数据沿着接收通路把外部世界的信息转换成一个事务项，然后，计算该事务项的值，根据它的值激励起多条活动通路中的一条数据流。发出多条通路的信息流中枢被称为“事务中心”。概要设计T事务事务中心活动通路概要设计变换型分析第1步复查基本系统模型。第2步复查并精化数据流图。第3步确定数据流图具有变换特性还是事务特性。第4步确定输入流和输出流的边界，从而孤立出变换中心。概要设计变换型分析第5步完成“第一级分解”。

软件结构代表对控制的自顶向下的分配，所谓分解就是分配控制的过程。对于变换流，数据图将被映射成一个特殊的软件结构，这个结构控制输入、变换和输出信息等处理过程：位于软件结构最顶层的控制模块Cm协调下述从属的控制功能：（1）输入信息处理控制模块Ca，协调对所有输入数据的接收；（2）变换中心控制模块Ct，管理对内部形式的数据的所有操作；（3）输出信息控制模块Ce，协调输出信息的产生过程。概要设计CmCtCaCe概要设计变换型分析第6步完成“第二级分解”。

把数据流图中的每一个处理映射成软件结构中一个适当的模块：从变换中心的边界开始沿着输入通路向外移动，把输入通路中每个处理映射成软件结构中Ca控制下的一个低层模块；然后沿输出通路向外移动，把输出通路中每个处理映射成直接或间接受Ce控制的一个低层模块；最后把变换中心内的每个处理映射成受Ct控制的一个模块。第7步使用设计度量和启发式规则对得到的软件结构进一步精化。概要设计BCDACmCaBCAD概要设计事务型分析第1步复查基本系统模型。第2步复查并精化数据流图。第3步确定数据流图具有变换特性还是事务特性。第4步确定事务中心和每个活动通路的流程特征。概要设计事务型分析第5步把数据流图映射成一个适合于事务处理的软件结构。第6步对事务中心的结构和每个活动通路的结构进行分解、合并和改进。第7步使用设计度量和启发式规则对得到的软件结构进一步精化。概要设计DGFE总控E调度DGA-CTLB-CTLC-CTLF接收通路C通路B通路A通路概要设计面向数据结构的设计：面向数据结构的设计方法用信息结构导出程序过程面向数据结构的设计过程分为如下几步：

（1）分析数据结构的特性；（2）用一些基本类型（如：顺序，选择和重复）来描述数据；（3）把数据结构表示映射成软件的控制层次；（4）利用一组规则改进软件的层次结构；（5）最后得到软件的过程性描述。概要设计Jackson方法Jackson方法的精髓在于：应该把问题分解成仅用三种结构化形式（顺序，选择和重复）来表示的层次结构。Jackson方法包括一种数据结构符号和一组映射或转换步骤。概要设计Jackson图（数据结构符号）：AAAC#D#B*CDB#B顺序重复选择AseqdoB;doC;doD;AendAiterdoB;AendAselectdoB;AordoC;AordoD;Aend概要设计Jackson图的特点：便于表示层次结构，而且是对结构进行自顶向下分解的有力工具；形象直观，可读性好；既能表示数据结构，又能表示程序结构。概要设计建立程序结构例1：设计一个打印表格的程序。表格如下：姓名年龄类别状态这里类别可以是“教师”或“学生”两种。“状态”一项，如果是教师则印出他的“工龄”，如果是学生则印出他的年级。概要设计表格表头表体行*姓名年龄类别状态工龄#年级#概要设计产生表格产生表头产生表体产生行*产生工龄#产生年级#产生姓名产生年龄产生类别产生状态概要设计建立程序结构例2：仓库中存放了多种零件，每种零件的每次变动（收到或发出）都有一张卡片作出记录，库存管理系统每月要根据这些卡片打印一张月报表，列出各种零件在这个月中库存量的净变化。概要设计零件组*卡片*发#收#月报表表头表体行*输入文件概要设计根据输入文件产生月报表产生表头产生表体从零件组产生行*处理文件产生行处理卡片*处理发#处理收#概要设计Jackson方法的基本步骤：（1）分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描述这些数据结构；（2）找出输入数据和输出数据结构中有对应关系的数据单元。所谓对应关系是指有直接的因果关系，在程序中可以同时处理的数据单元（对于重复出现的数据单元必须重复的次数相同才可能有对应关系）；概要设计Jackson方法的基本步骤：（3）用下述三条规则从描述数据结构的Jackson图导出描述程序结构的Jackson图：第一，为每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框（注意，若这对数据单元在输入数据结构和输出数据结构中所处的层次不同，则和它们对应的处理框在程序结构图中所处的层次与它们之中在数据结构图中层次低的那个对应）；第二，根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图中的相应层次分别为它们画上对应的处理框；第三，根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图中的相应层次分别为它们画上对应的处理框。概要设计Jackson方法的基本步骤：（4）列出所有操作和条件（包括分支条件和循环结束条件），并且把它们分配到程序结构图的适当位置。（5）用伪码标示程序。概要设计例：输入一个文件FIPT，此文件只包含三种记录类型T1、T2和T3，现在要对该文件作如下处理：（1）统计出现的第一个T1类型的记录前的记录总数（计数A）；（2）显示第一个T1类型的记录；（3）显示最后一个记录，最后一个记录是在第一个T1类型的记录后的第一个T2类型的记录；（4）计算第一个T1类型的记录后的记录批数（一批记录指一串连续的T1类型的记录或一串连续的T3类型的记录（（计数B）；（5）统计在第一个T1类型的记录后出现的T1类型记录的总数（计数C）；（6）计算在第一个T1类型的记录后的T3类型记录的批数（计数D）。概要设计FIPT前缀批数部分T2非T1*批*T1批#T3批#T1*T3*第一个T1概要设计处理FIPT处理前缀处理批数部分处理T2处理非T1*处理批*处理T1批#处理T3批#处理T1*处理T3*处理第一个T1概要设计列出所有的操作：（1）CA：=0（2）CB：=0（3）CC：=0（4）CD：=0（5）CA：=CA+1（6）CB：=CB+1（7）CC：=CC+1（8）CD：=CD+1（9）显示第一个T1记录（10）显示最后一个T1记录（11）显示所有计数器的内容（12）打开FIPT文件（13）关闭FIPT文件（14）终止运行（15）读FIPT文件记录概要设计处理FIPT12151处理前缀处理非T1*处理第一个T1234批数部分处理T2111314处理批*处理批部分51015915515处理T1批#处理T3批#处理T1*处理T3体处理T3*315715概要设计设计方法比较：没有一种方法能够适用于所有的应用领域；设计“优劣程度”的评定标准，大都建立在不可证明的假设的基础之上；“设计”首先是解决问题的活动，而解决问题的过程和办法是因人而异的；方法是重要的，但只有在支撑环境中运用它们才能得到成功。详细设计详细设计是给出软件结构中各模块的内部过程描述模块的内部过程描述也就是模块内部的算法设计详细设计也既是要导出一种算法设计表示，由此可以直接而简单地导出程序代码详细设计详细设计的逻辑基础：使用结构化构造（即用顺序、选择和重复三种程序结构）表示程序过程，降低程序的复杂性，从而提高可靠性、易测试性和易维护性。详细设计详细设计工具对软件开发人员来说，提高软件开发效率对软件测试和维护人员来说，提供摆脱繁琐的程序代码，了解模块程序结构的途径详细设计详细设计工具：图形工具将过程细节用图来表示，在图中，逻辑结构用具体的图形表示列表工具利用表来表示过程细节，表列出了各种操作和相应的条件语言工具用类语言（伪码）表示过程的细节，很接近编程语言详细设计图形工具：流程图方块图PAD图详细设计流程图方框表示处理步菱形表示逻辑判断箭头表示控制流注意：用流程图表示过程细节时，要注意不要乱用箭头，否则会使结构不清晰详细设计S1C4C5C3C2C1S2S3S4S5NYNYNNNYYY详细设计流程图的主要缺点：流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。流程图不易表示数据结构。详细设计方块图（N-S图）研制方块图的目的是：既要制定一种图形工具，又不允许它违反结构化原则。方块图具有以下特点：（1）功能域（即某一具体构造的功能范围）有明确的规定，并且很只观地从图形表示中看出来；（2）想随意分支或转移是不可能的；（3）局部数据和全程数据的作用域可以很容易确定；（4）容易表示出递归结构。详细设计第一个任务第二个任务第三个任务条件FTELSE部分THEN部分CASE条件值1值2…...值nCASE1部分A循环条件Do-While

部分Do-Until

部分循环条件调用子程序A循环顺序IF-THEN-ELSE分支CASE分支详细设计C1C4C5NYS1S4S2S3S5NNYYC2C3详细设计PAD图（ProblemAnalysisDiagram）P1P2P2P1PnP2P1...X=L1L2LnC顺序选择CASE型选择详细设计WHILECUNTILCPP循环语句标号定义def详细设计P1P3P2P5P4P2P6P10P8UNTILC3P7UNTILC2P9defCC1详细设计WHILEC1UNTILC4S5S3S1S2S4C2C3C5详细设计PAD图的特点：使用表示结构化控制结构的PAD符号所设计出的程序必然是结构化程序。PAD图所描述的程序结构十分清晰，图中最左面的竖线是程序的主线，即第一层结构，随着程序层次的增加，PAD图逐渐向右延伸，每增加一个层次，图形向右扩展一条竖线，PAD图中的竖线的总条数就是程序的层次数。详细设计PAD图的特点：用PAD图表现程序逻辑，易读、易懂、易记，PAD图是二维树形结构的图形，程序从图中最左竖线上端的结点开始执行，自上而下，从左向右顺序执行，遍历所有结点。容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成。详细设计PAD图的特点：既可以用于表示程序逻辑，也可用于描述数据结构。PAD图的符号具有支持自顶向下、逐步求精方法的作用。开始时设计者可以定义一个抽象的程序，随着设计工作的深入而用def符号逐步增加细节，直至完成详细设计。详细设计语言工具--PDL(ProgramDesignLanguage)PDL具有严格的关键字外部语法，用于定义控制结构和数据结构；另一方面，PDL表示实际操作和条件的内容语法通常又是灵活自由的以便可以适应各种工程项目的需要。一般说来PDL是一种“混合”语言，它使用一种语言（通常是某种自然语言）的词汇，同时却使用另一种语言（某种结构化的程序设计语言）的语法。详细设计PDL应当具有以下特征：关键字应有固定语法，以便提供全部结构化构造、数据说明和模块化特性，并且使结构清晰和易读性好；一种自然语言的自由文法，用来描述处理特点；应有数据说明机制，应该包括既简单的数据结构（标量与数组），又包括复杂的数据结构（链表或层次结构）；应有子程序定义与调用方法，用来表示各种方式的接口描述。详细设计设计工具应具有的属性：模块性、简明性、便于编辑、机器可读性、易维护性、强行结构化、自动处理、数据表示、逻辑验证、编程能力详细设计软件设计说明书1.范围（1）系统的目标和作为系统元素的软件的作用；（2）硬件、软件与人机接口；（3）主要的软件功能；（4）外部定义的数据库；（5）主要的设计约束与限制。详细设计软件设计说明书2.参考文档（1）现有的软件文档；（2）系统文档；（3）外购产品文档（硬件或软件）；（4）技术参考资料。详细设计软件设计说明书3.设计说明（1）数据说明信息流的复审信息结构的复审（2）导出的软件结构（3）结构内的接口详细设计软件设计说明书4.模块（对每一个模块）（1）处理说明（2）接口说明（3）设计语言（或其他）的说明（4）使用的模块（5）数据的组织（6）注解详细设计软件设计说明书5.文件结构和全程数据（1）外部文件结构逻辑结构逻辑记录说明存取方法（2）全程数据（3）文件和数据的交叉引用6.需求与模块的对照表详细设计软件设计说明书7.测试的准备测试大纲组装策略专门的考虑8.装配专门的程序覆盖考虑转录考虑9.专门注解10.附录详细设计设计的复审软件的设计由管理方面的代表、技术开发方面的代表和其他有关人员（诸如用户、质量保障和软件支持者等）共同进行复审。对设计进行复审的明显好处是可以比较早地发现软件的缺陷，从而可以使每个缺陷在进行编程、测试和交付之前予以纠正，从而显著地降低随后的开发阶段和维护阶段的费用。设计复审包括正规的审查、非正规的审查和检查三种方式。详细设计设计复审的标准：易追溯性该软件设计包括了软件需求规格说明的所有要求了吗？该软件的每个部件与某个具体的软件要求有关吗？风险实现该设计会有很大风险吗？也就是说，没有技术性的突破该设计也能完成吗？实用性该软件对软件要求所确定的问题是一种实用的解决办法吗？易维护性该设计是否将导致一个便于维护的系统？质量该设计具备一个“好”的软件应有的质量特征吗？接口外部和内部的接口已经规定得足够明确了吗？技术清晰度该设计的表达方式是否使它便于转化成程序？选择方案考虑了其他设计方案了吗？采用什么标准来选择最后方案呢？限制软件限制是否现实？与要求相符合吗？某些具体的问题该软件便于人控制机器吗？便于测试吗？与其他系统部分相适应吗？有足够的文档吗？详细设计正规的复审通常是为了评价软件的结构和接口；这种类型的复审的特点在于：设计人员和复审人员都要认真的准备；有相当多的复审者参加，他们对该软件研制项目有不同程度的兴趣；管理方面和技术方面站得高，视野开阔；提供正式的设计文档；由通知到开会的时间间隔至少有两个星期。详细设计非正规的复审所谓非正规的复审指的是从临时通知的碰头会到有关同事参加的比较有组织的复审这整个范围而言的，一般由通知到开会的时间间隔只有二至三天。详细设计设计的检查检查具有正规的复审和非正规的复审两方面的特点；从复审的形式与内容上看，检查方法是相当正规的--有专门的职责、活动安排、交付的文档、核对表以及管理办法等等，一切都是事先规定好的；然而，涉及到的人员以及他们的相互联系则是比较随便的，通常都以小组进行活动。编码

程序设计语言的性能和程序的编码风格，在很大程度上影响着软件的质量和维护性能。程序设计语言性能的讨论程序设计语言的分类与选择程序编码风格编码程序设计语言性能的讨论软件心理学观点（1）一致性：表示语言使用符号的兼容程度、约束条件及语法和语义上的例外等等。（2）歧义性：歧义性导致程序员对程序理解的混乱。（3）简洁性：对用该语言编程的程序员必须记忆的信息量的衡量。（4）局部性和线性：人们的记忆和辨别能力分为联想和顺序两个方面。联想能使我们整体地记住和辨别某件东西。顺序记忆能从回忆序列中找出一个元素。局部性是语言的联想性；线性是语言的顺序性。编码程序设计语言性能的讨论工程观点（1）使设计易于代码翻译；（2）编译程序的功效；（3）源代码的可移植性；（4）开发工具的可利用性；（5）源代码的可维护性。技术性能观点（1）复杂数据结构（2）实时系统（3）特殊应用领域编码程序设计语言的分类（按语言抽象级别分类）低级语言：机器语言，汇编语言高级语言：与机器无关，实现性语言甚高级语言：高抽象级，有用以描述功能的成分编码程序设计语言的分类（按应用领域分类）通用语言专用语言编码程序设计语言的分类（按语言成分性质分类）顺序语言：只含顺序成分并发语言：含有并发成分分布式语言：考虑了分布式计算要求网络语言：考虑了网络计算要求编码程序设计语言的分类（按作用方式分类）命令式语言：不论其描述“做什么”还是“怎样做”，相应描述的组成部分是命令式的，先做什么、后做什么都规定好了明确的次序。作用式语言：从相应的描述中不能明显看出其组成部分执行的先后次序。编码程序设计语言的分类（按描述级别分类）功能性语言设计性语言实现性语言编码程序设计语言的分类（按模拟客观世界的角度分类）对象式语言（面向对象语言）非对象式语言编码程序设计语言的分类（按其它方式分类）函数式语言逻辑式语言编码

一般而言，衡量某种程序语言是否适合于特定的项目，应考虑下面一些因素：应用领域算法和计算复杂性软件运行环境用户需求中关于性能方面的需要数据结构的复杂性软件开发人员的知识水平可用的编译系统编码编码风格在很大程度上影响着程序的易读性、易测试性和易维护性，鉴于软件的绝大部分成本消耗在测试和维护阶段，提倡好的编码风格，努力提高易测试性和易维护性极其重要。好的编码风格是在不影响性能的前提下，有效地编排和组织程序，以提高易读性和易维护性。编码

为了编制出清晰、紧凑、高效的程序，一般应依次考虑下列原则：（1）编制易于修改和维护的代码（2）编制易于测试的代码（3）必须将编程和编文档的工作统一起来（4）编程中采用统一的标准和约定，降低程序复杂性（5）限定每一层的副作用，减少耦合度（6）尽可能地复用编码编码风格包括以下三个方面：代码文件数据说明语句结构编码代码文件恰当的标识符适当的注解

序言性注解功能性注解良好的程序视觉组织编码数据说明的简单原则：数据说明的次序应该标准化；当多个变量同时被说明时，应当按字母顺序排列这些变量；若设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现它的特点和方法。编码语句结构要保持尽可能的简单，应遵循以下原则：程序要清晰直观，不要过于巧妙；用一定的原则指导控制结构的使用；（1）不用空THEN语句；（2）避免THEN--IF结构形式；（3）不要嵌套太深；（4）避免不必要的转移；（5）有原则地使用GOTO；（6）采用标准的结构形式弥补语言的不足。使用括号清晰地表示逻辑表达式和算术表达式；利用加空白或易读的符号来清晰地表示语句的内容；心理换位“如果这个程序不是我写的，我能看懂它吗？”编码程序交互部分的设计指导原则：把计算机的内部特性掩盖起来不让用户看到；使程序穿上“防弹衣”，即保证程序不会被用户所破坏，用户不可能使程序走向不正常的结束；如果用户的请求会产生重大的后果，就要提醒用户；按照用户的水平设计输入要求；区别对待不同类型的用户；尽量减少用户处理出错的工作量。编码程序设计支撑环境现在编程过程大多在一组CASE工具的支持下进行，这组工具辅助完成编辑、编译、调试、项目管理等一系列任务，这组工具有机集成在一起形成程序设计支撑环境。编码程序设计支撑环境应该具备的特性：通用性：适用于不同的语言、不同的应用领域和开发方法；适应性：通过开关设置，能配制出不同需要的程序设计支撑环境实例；开放性：能方便地增加新工具；支持复用：能支持可复用模块的存储、索引和查找；自控性：保证自身操作的正确与协调；自带数据库：提供数据库机制，存储、管理已开发的软件产品；保证质量：有助于提高所开发软件的质量；吸引用户：用户愿意使用；具有市场竞争力：能真正提高软件生产力。测试软件测试的重要性和它对软件可靠性的影响无论怎样强调都不过分软件测试的工作量往往占软件开发总工作量的40%以上（极端情况是其它步骤总成本的三倍到五倍）软件测试的目的与软件工程所有其他阶段的目的都相反测试软件测试的目标或定义：测试是为了发现程序中的错误而执行程序的过程一个好的测试用例在于能发现至今未发现的错误一次成功的测试是发现了至今未发现的错误的测试测试测试与排错（调试）的区别：测试是从已知的条件出发，使用预先定义的方法，并且有预期的测试结果。排错往往是从未知的初始条件（错误的性质，位置和范围）出发；测试能够而且应该事先安排，事先设计和制定测试日程表，而排错的方法和所需的时间都不能事先确定；测试是暴露程序员的过失，相反排错是帮助程序员纠正错误；测试应该是可预测的、机械的、强制的、严格的，排错要求随机应变、联想、实验、智力和自主；测试测试与排错（调试）的区别：测试的设计和实现在很大程度上可以忽略被测试对象的详细设计，但是没有详细设计的知识，排错是不可能的；测试能由非程序员来做，而排错相反；测试已经建立了它的理论基础，在理论上人们已知道，它能做什么和不能做什么，但是到目前为止，排错还没有一个经得起检验的理论方法。测试测试原则：避免软件开发部门（人员）测试自己的程序测试用例的设计和选择，预期结果的定义要有利于错误的检测严格执行测试计划，排除测试的随意性合理进行回归测试和验证，防止排错过程中引入新的更严重的错误测试测试原则：除很小的程序外，无论功能测试（黑箱测试）或结构测试（白箱测试），“彻底”测试是不现实的妥善保存测试用例，测试计划，出错统计和最终分析报告，为维护提供方便充分注意测试中的群集性现象，根据测试后残存的错误数目与该部分已发现的错误数目成正比的特点，对错误群集的程序区段进行重点测试，提高测试投资的效益测试测试信息流测试评价排错可靠性模型软件配置测试配置测试结果错误错误率数据可靠性预测正确代码预期结果测试测试信息流输入信息

软件配置：需求说明，设计说明，源程序清单等。测试配置：测试计划和方案。输出信息

测试结果可靠性预测：可能可靠（软件可靠性是可以接受的）所进行的测试尚不足以发现严重错误不可靠测试测试方法静态测试动态测试测试静态测试静态测试的基本特性是在对软件进行分析、检查和测试时不实际运行被测试的程序；静态测试可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一；在软件开发过程的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此在这些阶段静态测试的作用尤为重要。测试静态测试方法（结构化走通）结构化走通由一组人员对一个文档从多种不同的角度进行仔细检查，以尽可能多地发现其中的错误。它以该文档的产生者为中心，由产生者向参加审阅的其他人员报告其文档，所发现的错误或怀疑是错误的问题则由召集人记录在案。审阅的中心问题是发现错误而不是纠正错误，在结构化走通的审阅后，由文档的产生者负责记录在案的错误纠正。结构化走通成功的关键是事先的准备，报告者必须在事先选择对审阅最能有所贡献的人员参加，推举最能有效地组织和执行审阅的人员担当召集人，并选择适当的时间和地点，被审阅的文档必须事先散发给审阅参加者，并留有充足的时间让审阅者在审阅会议之前进行检查，准备工作越充分，结构化审阅就会越有效率。测试静态测试方法（Fagan检查）Fagan检查是在一般的检查技术的基础上发展起来的，其总的原理与结构化走通非常相似。Fagan检查将审阅放在一个质量计划、度量和控制的更广泛的环境下，使之具有双重目的：第一，发现产品中的错误；第二，通过对错误的统计，提供今后对所发现的同类错误进行控制的数据。Fagan检查旨在发现错误，而不是改正错误；强调对错误进行分类和统计，从而发现共同的错误类型和将来避免这类错误的方法。简言之，Fagan检查强调对开发过程的反馈和从错误中吸取教训。测试静态测试内容需求定义的静态测试对需求定义的静态测试着重于测试对用户需求的描述和解释是否完整、准确。设计文档的静态测试对设计文档的静态测试着重于分析设计是否与需求定义一致。源代码的静态测试对源代码的静态测试着重于分析实现是否正确、完备。测试需求定义的静态测试兼容性界面需求是否使软件硬件系统具有兼容性？完备性需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？一致性各个需求之间是否一致？是否有冲突和矛盾？正确性需求定义是否满足标准的要求？可行性需求定义是否使软件的设计、实现、操作和维护都可行？易修改性对需求定义的描述是否易于修改（例如，是否采用良好的结构和交叉引用表等）？健壮性是否有容错的需求？易追溯性是否可以从上一阶段的文档查找到需求定义中的相应内容？易理解性是否每一个需求都只有一种解释？易测试性和可验证性需求是否可以验证？（即是否可以检验软件是否满足了需求？）测试设计文档的静态测试完备性软件设计规约是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的所有内容？一致性在设计文档中，是否始终使用标准的术语和定义？文档的风格和详细程度是否前后始终一致？正确性设计文档是否满足有关标准的要求？可行性所设计模型、算法和数值方法对于应用领域来说是否可以接受？易修改性设计是否使用了信息隐蔽技术从而方便于修改？模块性是否采用了模块化的机制？测试设计文档的静态测试健壮性设计是否覆盖了需求定义中所要求的容错和故障弱化指标？结构化设计是否使用了层次式的逻辑控制结构？易追溯性设计文档中是否包含设计与需求定义中的需求、设计限制等内容的对应关系？易理解性设计是否避免了不必要的成分和表达形式？设计文档是否不致造成歧义性解释？可验证性/易测试性设计中对每一个模块的描述是否都使用了良好的术语和符号？是否可以验证它与需求定义相一致？是否定量地说明了使用条件、限制等内容？是否可以由此产生测试数据？测试源代码的静态测试完备性代码是否完全、准确地实现了设计说明书中所规定的内容？代码是否满足设计要求？代码是否创建了所需的数据库或其他初始化数据？是否有未引用的或未定义的变量、常量或数据类型？一致性代码在逻辑上与设计说明一致吗？是否自始致终地使用了相同的格式、调用约定、结构等等？正确性代码是否符合标准？变量的定义和使用都正确吗？注释是否准确？过程调用的参数个数和类型正确吗？易修改性代码中对常数的使用是否都通过符号来进行使其便于修改？是否有交叉引用表或数据字典来表明程序对常量和变量的取接？代码是否有单入口、单出口的结构组成？代码是否避免了直接使用地址，而采用标号和符号常量？测试源代码的静态测试可预测性是否避免了使用自我修改的代码？是否避免了依赖于程序设计语言中的缺省值的代码？代码是否包含无穷循环？健壮性代码是否防止可以发现的运行时刻的错误？如下标变量越界、除数为零、变量值越界、栈溢出等等。结构化程序的每一个功能是否都可以作为一块代码而识别出？循环是否只有一个入口？易追溯性是否有一个交叉引用表，通过它可以便捷地从代码找到相应的设计？易理解性注释是否使用了简洁明了的语言对每一个过程都作了充分的描述？是否使用了便于记忆的命名约定？命名是否反映了变量的类型？变量的有效值域是否定义了？可验证性实现是否避免了使用测试难度大的技术和方法？测试动态测试所谓动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性；运行软件并非动态测试的目的，通过运行来检验软件是否正确才是动态测试的真正目的；动态测试包括三个基本要素：被测试程序；用以运行软件的数据，称为测试数据。软件需求规格说明。测试一个成熟的动态测试方法必须回答如下问题：如何选择或产生测试数据？如何组织软件的测试运行？如何考察和记录软件动态运行的行为？如何判断软件动态行为的正确性？测试过程何时结束？如何通过软件测试结果分析软件性质？测试

按照选择或产生测试数据所根据的信息的来源，动态测试方法可以分为：以程序为基础的测试以需求和功能说明为基础的测试程序与需求相结合的测试以界面为基础的测试测试

按照选择或产生测试数据以及判断测试充分性的方法，动态测试方法可以分为：结构测试（白箱测试）功能测试（黑箱测试）测试结构测试（白箱测试）：结构测试诣在充分地覆盖软件的结构，并以软件中的某类成分是否都已得到测试为准则来判断软件测试的充分性测试穷尽结构测试例：一段程序对嵌套的IF语句执行20次，共有5201014条通路，若每执行一次需1毫秒，则需3000年。测试功能测试（黑箱测试）：功能测试根据软件所需的功能和所实现的功能选择测试数据，分析测试的充分性测试穷尽功能测试例：一个程序需3个整型的输入数据，若计算机的字长为16位，则每个数据可能取的值有216个，3个数的排练组合共有

216

216

216

=248

31014

（种）若每执行一次需1毫秒，则需1万年。测试软件测试的步骤：单元测试组装测试有效性测试系统测试测试单元测试单元测试集中检验软件设计中最小单元--模块。根据详细设计的说明，应测试重要的控制路径，力求在模块范围内发现错误。由于测试范围有限，测试不会太复杂，所能发现的错误也是有限的。单元测试总是采用白箱测试方法，而且可以多个模块并行进行。测试单元测试的内容模块接口局部数据结构“重要的”运行路径出错处理路径影响以上各点的边界条件测试单元测试的过程单元测试和编码属于软件开发的同一阶段。模块并不是独立的程序，必须为每个单元测试开发驱动模块和承接模块。驱动模块：是一个“主程序”。接收测试数据，把这些数据传送给被测模块，并且打印结果。承接模块：用以代替被测试模块所调用的模块，采用被代替模块的接口，可以做很少的数据处理，打印数据，并把控制返回给被测模块。驱动模块和承接模块是一种额外的开销，也就是说，它们都是必须编写的软件，但却不作为最终的软件产品提供给用户。测试DriverModuletobetestedStubStubInterfacelocaldatastructuresBoundaryconditionsIndependentpathsErrorhandlingpathsTestcasesUnittestenvironmentRESULTS测试组装测试在把经过单元测试的模块按照设计要求组装起来的过程中进行测试，重点查找与接口有关的错误。与接口有关的错误包括：数据穿过接口时可能丢失；某个模块对另一个模块可能产生不利的影响；把子功能组合起来可能不产生预期的主功能；个别原可以接受的误差可能累计到不能接受的程度；全程数据结构可能有问题。测试组装测试方法自顶向下组装测试方法：按照控制的结构，从主控模块（主程序）开始，向下逐个把模块连接起来进行测试。把附属于主控模块的子模块孙模块等等组装起来的方式有两种，先纵深组装法和先横宽组装法。自底向上组装测试方法：按照控制结构，从最基本的模块（即在软件结构中最低层的模块）开始进行组装及测试。正是因为是从最低层进行组装，在逐步处理以上层次的模块时所需要的子模块总是可以得到的，所以不再需要承接模块了。测试自顶向下组装测试过程（1）主控模块用做为测试驱动模块，直接附属于主控模块的各个模块全部用承接模块代替；（2）按照所选的组装法（先纵深或先横宽）每次用一个真模块取代一个附属的承接模块；（3）在装入每个真模块后进行一次测试；（4）做完每一次测试后再用一个真模块代替另一个承接模块；（5）必要时进行回归测试（即重新再做过去的全部或部分测试）以保证新加的模块没有引起新的错误。测试自底向上组装测试过程（1）把低层模块组合起来形成某个特定的软件子功能簇；（2）编写一个驱动模块以安排测试数据的输入输出；（3）对簇进行测试；（4）拆去各个小簇的驱动模块，把几个小簇合并成大簇，重复（2）（3）（4）。测试组装测试方法比较自顶向下组装法：不需要驱动模块；能够在测试阶段早期验证系统的主要功能，早期发现接口错误；需要较多的承接模块，可能遇到与之相联系的测试困难；低层关键模块中的错误发现较晚。自底向上组装法：不需要承接模块；需要较多的驱动模块；在最后一个模块装入之前，软件实体并不存在。一般使用两种方法的结合，测试阶段早期采用自顶向下组装法，后期采用自底向上组装法，很多情况下二者可以同时进行。测试组装测试文件（测试说明书）1.测试范围2.测试计划测试方面（把测试划分为几个方面，分别测试软件的各种特性）进度额外软件（驱动模块和承接模块）环境与资源3.测试步骤第n测试阶段的说明：组装的次序；测试目的和应测的模块；专用的工具或技术；额外软件的说明；测试用例数据。第n测试阶段的预期结果4.实际测试结果5.参考资料6.附录

测试有效性测试（验证软件系统的有效性）软件有效性：当软件的功能和性能如同用户合理期待的那样，则软件是有效的。问题：怎样算是合理的期望（需求说明）；谁是公断人（测试人员）。方法：黑箱测试法。标准：全部的功能要求都得到满足；全部的性能要求都达到了；文档是正确的并且便于使用；其它要求也达到了（包括易维护性、易移植性、兼容性、出错自动恢复等）。可能出现的结果：功能与性能与技术要求一致；发现与技术要求不一致的地方（与用户协商）。软件系列文件复审：确认软件系列文件的各个部分都已做好，已经编目，并有必要的细节说明，作为以后维护阶段的基本资料。测试系统测试软件仅仅是基于计算机的系统的一个组成部分。系统测试是指把软件与系统的其他要素合并，并进行一系列的系统组装及有效性测试。系统测试已经落到了软件工程范畴之外，并且极少由软件开发者承担，但是在软件设计和测试阶段所进行的工作将有助于成功地把软件合并到更大的系统之中。典型的系统测试问题是“相互指责”，当发现了一个错误以后，各个系统部分的开发者都职责别人的部分有毛病。测试系统测试（软件工程师的工作）安排出错处理路径，以测试从系统的其他部分传来的全部信息；进行一系列测试，模仿在软件接口处出现的“坏的数据”或其他可能的错误；把测试结果记录下来，如果出现互相指责的情况时，就可以提出确实的根据；参与系统测试计划与设计，以保证充分地测试软件系统。测试测试用例设计：

测试用例设计的基本目标是确定一组测试数据，其发现一个或一类错误的概率极高。逻辑覆盖等价划分边界值分析测试逻辑覆盖语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖路径覆盖测试现给出如下程序，

#include(stdio.h);main(){floatA,B,X;scanf(“%f%f%f”,&A,&B,&X);if(A>1)&&(B==0)X=X/A;if(A==2)||(X>1)X=X+1;printf(“%f”,X)}

设计该程序的测试数据以分别满足语句覆盖、判定覆盖、条件覆盖、条件组合覆盖和路径覆概的逻辑覆盖标准。测试

语句覆盖：选取足够多的测试数据，使被测试程序中每个语句至少执行一次。

为使每个语句都执行一次，程序的执行路径应是sacbed：A=2,B=0,X=4问题：若把b点的判定错写为

(A==2)||(X<1)入口返回(A>1)&&(B==0）(A==2)||(X>1）X=X/AX=X+1sabdce测试

判定覆盖：选取足够多的测试数据，使被测试程序中不仅每个语句至少执行一次，而且每个判定的每种可能的结果都至少执行一次。

能够分别覆盖路径sacbed和sabd或sacbd和sabed的两组测试数据，都满足判定覆盖标准：（1）A=3,B=0,X=3(sacbd)（2）A=2,B=1,X=1(sabed)入口返回(A>1)&&(B==0）(A==2)||(X>1）X=X/AX=X+1sabced测试

条件覆盖：选取足够多的测试数据，使被测试程序中不仅每个语句至少执行一次，而且每个判定表达式中的每个条件都取到各种可能的结果。在a点：A>1,A1,B=0,B≠0；在b点：A=2,A≠2,X>1,X1。（1）A=2,B=0,X=4(sacbed)（2）A=1,B=1,X=1(sabd)入口返回(A>1)&&(B==0）(A==2)||(X>1）X=X/AX=X+1sabced测试

判定/条件覆盖：选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的结果，而且每个判定表达式也都取到各种可能的结果。（1）A=2,B=0,X=4(sacbed)（2）A=1,B=1,X=1(sabd)入口返回(A>1)&&(B==0）(A==2)||(X>1）X=X/AX=X+1sabced测试

条件组合覆盖：选取足够多的测试数据，使得判定表达式中条件的各种可能组合都至少出现一次。有八种可能的条件组合：（1）A>1,B=0；（2）A>1,B≠0；（3）A1,B=0；（4）A1,B≠0；（5）A=2,X>1；（6）A=2,X1；（7）A≠2,X