软件工程知识重点

知识重点（软件工程部分）

2023/1/311一、软件工程基本原理1.1软件危机1.2软件工程1.3软件生命周期1.4软件过程2023/1/312软件及软件工程为什么要讲软件和软件工程只有对软件和软件的开发过程有充分的认识，才能更好的开发出过程受控、质量受控的软件产品。对于软件和软件开发过程的认识是困难的，存在很多困惑，需要对此有深刻的认识。2023/1/313一些对软件的偏见或误解软件就是程序，软件开发就是编写程序。编完了程序，就一切OK了。掌握了最新的语言和工具，就能写程序了。软件是灵活的，软件的修改很容易。只要会编程，就能写软件，就是程序员；一个公司，只要召些程序员，就能开发好的软件产品。只要有几个有经验的程序员，再找些兼职的大学生，就能组成一个软件公司。2023/1/314什么是软件软件的定义—软件是计算机系统中与硬件相互依存的另一部分，软件由三部分组成：程序：在运行时，能提供所希望的功能和性能的指令集数据：使程序能够正确运行的数据文档：描述程序研制过程、方法及使用的文档软件的开发，绝不仅仅是编写程序软件可看做一个信息交换器，产生、管理、获取、修改、显示或传送信息2023/1/315软件≠程序软件的特征软件是一种逻辑实体，而不是具体的物理实体。因此它具有抽象性。人们可以使用软件，但是无法看到软件本身的形态。必须通过观察、分析、思考、判断，才能了解其功能、性能等特性。软件的生产与硬件不同，在它的开发过程中没有明显的制造过程。生产螺钉，随时可以监控其质量是否满足要求生产软件，不可控，导致项目延期、失败2023/1/316软件的特征在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。重装故障修复更加困难软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性Windows->linuxOralce->sqlserver微机->手机2023/1/317软件的特征软件的开发至今尚未完全摆脱手工作坊的开发方式。小作坊大作坊依赖核心程序员的手工生产软件本身是复杂的不可预见实际问题的复杂性（需求改变）不可预见外界环境的复杂性（断电、硬盘满、网络故障、病毒）程序逻辑结构的复杂性（看别人程序难）软件是人类有史以来生产的复杂度最高的工业产品2023/1/318软件的特征软件成本相当昂贵人工费宣传费运营费税收……2023/1/319软件的分类按软件的功能进行划分系统软件操作系统数据库管理系统设备驱动程序通信处理程序等2023/1/3110软件的分类按软件的功能进行划分支撑软件文本编辑程序文件格式化程序程序库系统支持需求分析、设计、实现、测试和支持管理的软件2023/1/3111软件的分类按软件的功能进行划分应用软件商业数据处理软件（股票）工程与科学计算软件（matlab）计算机辅助设计/制造软件(autocad)系统仿真软件（科学研究用）智能产品嵌入软件（智能手机，智能住宅）医疗、制药软件（医院管理信息系统）事务管理、办公自动化软件（政府工作流）计算机辅助教学软件（PPT）2023/1/3112软件的分类按软件的工作方式划分实时处理软件（对实时性要求高的场合）分时软件（windows操作系统）交互式软件（等待用户输入）批处理软件（无需用户干预）按软件服务对象的范围划分项目软件（委托开发，知识产权属于委托方）产品软件（知识产权属于开发方）2023/1/31131.1软件危机软件危机的介绍随着计算机应用的日益普及，软件数量急剧膨胀软件开发和维护成本越来越大，令人吃惊地高失败的软件开发项目屡见不鲜什么是软件危机、软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题2023/1/31141.1软件危机典型案例IBM公司1963年-1966年IBM360机的操作系统5000人工作一年100万行源程序每次发行的新版本都是从前一版本中修正1000个程序错误项目负责人F.D.Brooks事后总结：“……正像一只逃亡的野兽落到泥潭中垂死地挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。”“……程序设计工作正像这样一个泥潭，……一批批程序员被迫在泥潭中拼命挣扎，……谁也没有料到问题竟会陷入这样的困境……”。2023/1/31151.1软件危机软件危机的表现对软件开发成本和进度的估计常常很不准确用户对“已完成的”软件系统不满意的现象经常发生软件产品的质量往往靠不住软件常常是不可维护的软件通常没有适当的文档资料软件成本在计算机系统总成本中所占的比例逐年上升软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势2023/1/31161.1软件危机软件危机的原因软件规模越来越大，软件复杂度越来越高软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性没有充分的文档资料（软件配置主要包括程序、文档和数据等）软件可靠性缺少度量的标准，质量无法保证轻视软件维护（维护费用占软件总费用的55%-70%）用户需求没有完整准确的认识，就匆忙着手编写程序（主要原因）2023/1/31172023/1/31181.1软件危机软件开发后期引入一个变动比早期引入相同变动所需付出的代价高2-3个数量级只有早期发现问题，才会尽量减少损失。2023/1/31191.1软件危机软件危机的原因软件本身的特点软件开发与维护的方法不正确如何克服软件危机：软件工程概念：软件生命周期2023/1/31201.1软件危机消除软件危机的途径对计算机软件正确认识。(软件不仅仅是程序)推广使用开发软件成功的技术和方法，研究探索更好更有效的技术和方法，消除错误概念和做法。开发和使用更好的软件工具。需要组织管理措施。软件工程正是从技术和管理两方面研究如何更好地开发和维护计算机软件的一门新兴学科。2023/1/3121无章法（个人英雄主义）工程项目管理模式（团队合作开发）1.2软件工程软件工程1968年秋，提出软件工程IEEE1993年给出定义：1)将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护。2)对1)中方法的理论研究。2023/1/31221.2软件工程概括地说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，经济地开发出高质量的软件并有效地维护它。软件工程基本原理(开发与维护的指导)用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性2023/1/31231.2软件工程把在软件生命周期全过程中使用的一整套技术的集合称为方法学(methodology)，也称范型(paradigm)。软件工程方法学三个要素：方法、工具和过程。方法是完成软件开发各项任务的技术，回答“如何做”；工具是为方法的运用提供自动或半自动软件支撑环境，回答“用什么做”；过程是为获得高质量的软件要完成的一系列任务的框架，规定完成各项任务步骤，回答“如何控制、协调、保证质量”。目前使用得最广泛的软件工程方法学传统方法学:也称为生命周期方法学或结构化范型。

面向对象方法学2023/1/31241.2软件工程传统方法的特点生命周期模型软件过程划分为若干个阶段每个阶段有各自的任务阶段之间有某种顺序性传统方法的缺点当软件规模较大，或对软件的需求是模糊的或随时间变化的时候，使用结构化范型开发软件往往不成功；此外，使用传统方法学开发出的软件，维护起来通常都很困难。2023/1/31251.2软件工程面向对象方法：对象作为融合数据及在数据之上的操作行为的统一的软件构件。把所有对象都划分成类(Class)。每个类都定义了一组数据和一组操作。按照父类(或称为基类)与子类(或称为派生类)的关系，把若干个相关类组成一个层次结构的系统(也称为类等级)。在类等级中，下层派生类自动拥有上层基类中定义的数据和操作，称为继承。对象彼此间仅能通过发送消息互相联系－封装性。2023/1/31261.2软件工程面向对象的特点面向对象方法学的出发点和基本原则，是尽可能模拟人类习惯的思维方式。用面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。概念和表示方法上的一致性，阶段间平滑（无缝）过渡。特殊到一般的归纳思维过程；一般到特殊的演绎思维过程。（继承的思想）最终产品中的对象与现实世界中的实体相对应，降低了复杂性，提高了可理解性，简化了软件的开发和维护工作。对象是相对独立的实体，容易在软件产品中重复使用，促进了软件重用。面用对象方法特有的继承性，也进一步提高了面向对象软件的可重用性。2023/1/31271.3软件生命周期

软件生命周期由软件定义、软件开发和运行维护三个时期组成，每个时期又可进一步划分成若干个阶段，每个阶段有各自的任务。2023/1/31281软件定义2软件开发3运行维护问题定义（领域分析1）确定要开发软件系统的总目标2023/1/3129必须回答的关键问题是：“要解决的问题是什么”。2023/1/31大连理工大学软件学院302023/1/31302.可行性研究（领域分析2，问题背景）给出功能、性能、可靠性以及接口等方面的要求估计可利用的资源（计算机硬件、软件、人力等）、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查回答的关键问题是：“上一个阶段所确定的问题是否有行得通的解决办法”。2023/1/31312023/1/31313.需求分析对待开发软件提出的需求进行分析并给出详细的定义用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明(specification)。提交管理机构评审仍然不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”。2023/1/3132了解问题，不能准确表达，不知道怎样利用计算机实现了解软件实现，不清楚用户要求与用户配合，充分交流，得出系统需求需求分析概要设计概括地回答“怎样实现目标系统?”这个问题。概要设计又称为初步设计、逻辑设计、高层设计或总体设计。可以给出实现目标系统的几种可能的方案。另一项主要任务是设计程序的体系结构，即确定程序由哪些模块组成以及模块间的关系。详细设计任务是把解法具体化，回答“应该怎样具体地实现这个系统”这个关键问题。还不是编写程序，而是设计出程序的详细规格说明。又称为模块设计、物理设计或低层设计。2023/1/3133编码和单元测试关键任务是写出正确的容易理解、容易维护的程序模块，并测试。综合测试关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。主要包括：集成测试和验收测试分析系统的可靠性记录测试计划、详细测试方案及实际测试结果，作为软件配置的一部分。2023/1/3134软件维护维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有四类维护活动改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。2023/1/31351.4软件过程在实际软件开发时，软件规模、种类、开发环境及开发时使用的技术方法等因素，影响阶段的划分。2023/1/3136软件开发软件维护软件定义生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。瀑布模型

在20世纪80年代之前，唯一被广泛采用的生命周期模型现在仍然是软件工程中应用得最广泛的过程模型。2023/1/3137瀑布模型传统的瀑布模型开发软件特点：阶段间具有顺序性和依赖性前一阶段完成后开始后一阶段前一阶段输出作为后一阶段输入2023/1/3138瀑布模型传统的瀑布模型开发软件特点：推迟实现不可急于求成清楚地区分逻辑设计与物理实现尽可能推迟程序的物理实现2023/1/3139瀑布模型传统的瀑布模型开发软件特点：质量保证每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审2023/1/3140瀑布模型不希望有“变化”变化来的越晚，付出的代价越高。设计阶段过多的假设，导致理想化、一厢情愿的东西过多。2023/1/3141瀑布模型2023/1/3142传统的瀑布模型实际的瀑布模型瀑布模型2023/1/3143带“反馈环”(实线箭头表示开发过程，虚线箭头表示维护过程)发现错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再继续完成后面阶段的任务。瀑布模型2023/1/3144优点：一定程度解决“变化”的问题。缺点：文档驱动，完全依赖书面文字。快速原型模型快速建立起可以在计算机上运行的程序，其功能往往是最终产品功能的子集。模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户试用，通过实践来了解目标系统的概貌。(实线箭头表示开发过程，虚线箭头表示维护过程)。2023/1/3145快速原型模型用户试用提出修改意见快速地修改原型系统用户再次试用…一旦用户认为原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。2023/1/3146快速原型模型快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。（原型通常没有严格的规范化，缺少文档，难以维护）2023/1/31472023/1/3148快速原型模型增量模型每个构件由多个相互作用的模块构成，并且能够完成特定的功能。第一个增量构件往往实现软件的基本需求，提供最核心的功能。(滚雪球方式)2023/1/3149增量模型，也称渐增模型。把软件产品作为一系列的增量构件来设计、编码、集成和测试。增量模型增量模型：逐步增加系统功能。较短时间内提交可以工作的产品。减少全新产品带给客户的冲击。困难：需要开放的架构设计。2023/1/3150瀑布、快速原型：力求一次性给用户完整的系统。2023/1/3151逐个构件进行分析、设计。风险更大。实现各个构件之前完成全部需求分析、规格说明、概要设计。螺旋模型应采取适当措施消除或减少开发软件时的风险。螺旋模型的基本思想：使用原型及其他方法来尽量降低风险。可以理解为在每个阶段之前都增加了风险分析过程的快速原型模型。2023/1/3152简化的螺旋模型螺旋模型2023/1/3153带箭头的点划线的长度代表当前累计的开发费用。螺线旋过的角度值代表开发进度。每周期对应一个开发阶段完整的螺旋模型螺旋模型优点：对可选方案和约束条件的强调有利于软件的重用，也有助于把软件质量作为软件开发的目标减少过多测试或测试不足带来的风险维护作为开发的一个周期，与开发没有本质区别风险驱动：及时终止项目适用于内部开发的大规模软件项目弱点：风险驱动：需要专业的风险评估人员，花费风险分析的费用2023/1/3154喷泉模型迭代是软件开发过程中普遍存在的一种内在属性。软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代，在面向对象范型中比在结构化范型中更常见。喷泉模型是典型的面向对象生命周期模型。2023/1/3155喷泉模型面向对象方法：围绕面向问题的“对象”展开，分析、设计、编码不存在明显的边界。圆圈重叠：开发活动之间存在交迭。向下箭头：阶段内的迭代（求精）。概念和表示方法的一致性：保证无缝过渡。体现了面向对象软件开发过程迭代和无缝的特性。2023/1/3156喷泉模型把一个线性过程作为总目标——避免开发过程过分无序。快速原型模型图中的中心垂线2023/1/3157思考题假设要你开发一个软件，该软件的功能是把读入的浮点数开平发，所得结果应该精确到小数点后4位。一旦实现并测试完之后，该产品将被抛弃。你打算选用哪种软件生命周期模型？请说明理由。2023/1/3158思考题答案：瀑布模型。需求明确、算法成熟，无需通过原型来分析需求。实现之后即被抛弃，无需使用有助于提高软件可维护性的增量模型或螺旋模型。2023/1/31592023/1/31602023/1/3160思考题假设你被任命为一家软件公司的项目负责人，你的工作是管理该公司已被广泛应用的字处理软件的新版本开发。由于市场竞争激烈，公司规定了严格的完成期限并且已对外公布。你打算采用哪种软件生命周期模型？请说明理由。2023/1/31612023/1/3161思考题2、增量模型。时间紧，需要选择能够加速产品开发的模型，增量模型可以实现任务并行。开发软件的新版本，旧版本即相当于原型。已经被广泛应用，以后可能扩充，体系结构设计成开放式。二、可行性研究2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2023/1/3162许多问题不可能在预定的系统规模或时间期限内解决目的：使用最小的代价，尽可能在短的时间内，确定问题是否能够解决2023/1/31632.1可行性研究的任务确定问题是否值得去解分析可能的解法判定系统规模和目标是否能够实现效益是否可观较高层次的系统分析和设计过程2023/1/31642.1可行性研究的任务进一步分析和澄清“问题定义”是否正确如有错误加以改正如有约束和限制必须清楚的列出导出系统逻辑模型探索实现方案（若干种）每种方案分别研究可行性2023/1/31652.1可行性研究的任务可行性的4个方面技术可行性经济可行性操作可行性法律可行性预期工程总成本的5%~10%2023/1/31662.2可行性研究过程1.复查系统规模和目标改正含糊或不确切的叙述清晰地描述限制和约束——解决正确的问题2023/1/31672.2可行性研究过程2.研究目前正在使用的系统完成现有系统的基本功能解决现有系统的问题分析系统运行费用绘制高层系统流程图掌握与其他系统的接口2023/1/31682.2可行性研究过程3.导出新系统的高层逻辑模型现有物理系统现有系统的逻辑模型目标系统逻辑模型新的目标物理系统目标系统逻辑模型高层数据流图初步的数据字典2023/1/31692.2可行性研究过程4.进一步定义问题分析员和用户沟通以数据流图和数据字典为基础复查问题定义、工程规模和目标重复1~4步，直至提出的逻辑模型完全符合系统目标2023/1/31702.2可行性研究过程5.导出和评价供选择的解法从技术角度出发，考虑解决问题的不同方案技术可行性，排除不现实的系统操作可行性，排除用户不能接受的方案经济可行性，排除利润低的方案(成本/效益分析)制定进度表(估算生命周期每个阶段的工作量)2023/1/31712.2可行性研究过程6.推荐行动方针如果值得开发，则选择最好的解法成本/效益分析7.草拟开发计划工程进度表各类开发人员、各种资源需求情况生命周期每个阶段的成本下一个阶段详细进度表和成本估计2023/1/31722.2可行性研究过程8.书写文档提交审查用户、客户组织的负责人及评审组审查见《可行性报告格式.doc》2023/1/31732.3系统流程图系统流程图概括描绘物理系统的传统工具用图形符号，以黑盒子形式描述组成系统的每个部件（程序、文档、数据库、人工过程）数据在各部件之间的流动情况（不是对数据进行加工处理的控制过程）区分系统流程图和程序流程图2023/1/31742.3系统流程图2.3.1符号基本符号2023/1/31752.3系统流程图系统符号（符号具体化）2023/1/31762.3系统流程图系统符号（符号具体化）2023/1/3177系统流程图例子例子2023/1/3178

部件类型事务

显示库存清单程序处理定货信息

磁带报告生成程序处理定货报告文档库存清单主文件磁盘2023/1/31大连理工大学软件学院792023/1/3179系统流程图例子例子每个符号用黑盒子形式定义了组成系统的一个部件。没有部件内部的具体工作过程箭头确定信息通过系统的逻辑路径（信息流动路径）2.3系统流程图分层(逐层细化的思想)高层次系统流程图描绘总体概貌分别描绘每个关键功能2023/1/31802023/1/31大连理工大学软件学院812023/1/3181思考题系统流程图用于可行性分析中的_____的描述A．当前运行系统B．当前逻辑模型C．目标系统D．新系统2023/1/31大连理工大学软件学院822023/1/3182思考题答案：A可行性研究中为了了解和分析现有系统，通过绘制系统流程图，与有关人员一起审查该系统流程图是否正确。描述的对象是当前正在运行的系统，因此选择A。2023/1/31大连理工大学软件学院832023/1/3183思考题系统流程图是描述_____的工具。A．逻辑系统B．程序系统C．体系结构D．物理系统2023/1/31大连理工大学软件学院842023/1/3184思考题答案：D系统流程图表达了系统中各个元素之间的信息流动情况。是描绘物理系统的传统工具。2.4数据流图当数据在软件系统中移动时，它将被一系列“变换”所修改。数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。数据流图只需要考虑做什么，不需要考虑怎么做2023/1/31852.4.1符号数据流图有四种基本符号：数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。2023/1/31862023/1/3187附加符号*号----与+号----或○号表示互斥+2023/1/31882023/1/31882.4.1符号注意：数据流与程序流程图中用箭头表示的控制流有本质不同（没有分支条件或循环）。处理并不一定是一个程序数据存储不一定是一个文件数据存储和数据流都是数据，一个静态，一个动态为保证图的清晰，可以复制某个符号2.4.2示例假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务。通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。2023/1/31892.4.2示例2023/1/31902.4.2示例（定货系统）一旦把数据流图的四种成分都分离出来以后，就可以着手画数据流图。任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。2023/1/3191定货系统的基本系统模型(突出表明了数据的源点和终点)2.4.2示例（定货系统）2023/1/3192定货系统的功能级数据流图2.4.2示例（定货系统）2023/1/3193把处理事务的功能进一步分解后的数据流图2.4.2示例（定货系统）注意：当进一步分解将涉及如何具体实现一个功能时，就不应该再分解了。当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。对处理进行分层编号。2023/1/31942023/1/3195工资计算系统的顶层(0层)数据流图2.4.2示例（工资计算系统）2023/1/3196工资计算系统第一层数据流图2.4.2示例（工资计算系统）2023/1/3197工资计算系统的第二层数据流图“计算工资”子数据流图“工资转存”子数据流图2023/1/3198工资计算系统的第三层数据流图2023/1/31982023/1/31992023/1/3199数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。命名时应注意的问题：为数据流(或数据存储)命名名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。2.4.3命名2023/1/311002023/1/31100为处理命名通常先为数据流命名，然后再为与之相关联的处理命名。名字应该反映整个处理的功能，而不是一部分功能。名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。2.4.3命名101/1302023/1/31101检查和修改数据流图的原则所有图形符号只限于前述四种基本图形元素1级以上数据流图必须包括前述四种基本原色，缺一不可数据流图的顶层图上的数据流必须封闭在外部实体之间每个处理至少有一个输入数据流和一个输出数据流2023/1/31102/1302023/1/31102检查和修改数据流图的原则在数据流图中，需按层给处理框编号。任何一个数据流图子图必须与它上一层的一个处理对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡图上每个元素都必须有名字数据流图中不可夹带控制流初画时可以忽略琐碎的细节，以集中精力于主要数据流2023/1/31分层数据流图的审查检查图中是否存在错误或不合理(不理想)的部分一致性：分层DFD中不存在矛盾和冲突完整性：分层DFD本身的完整性，即是否有遗漏的数据流、处理等元素2023/1/31103/130分层数据流图的一致性父图与子图平衡任何一张DFD子图边界上的输入/输出数据流必须与其父图中对应的处理的输入/输出数据流保持一致数据守恒一个处理所有输出数据流中的数据，必须能从该处理的输入数据流中直接获得，或者能通过该处理而产生一个处理的输出数据流不能与该处理的输入数据流同名2023/1/31104/130父图与子图不平衡的实例处理2的输入数据流有M和N，输出数据流是T而子图(右图)边界上的输入数据流是N，输出数据流是S和T2023/1/31105/130123ABCMNT2.12.22.3NPSTQ数据不守恒的实例由于“正式成绩清单”中缺少“考生通知单”中的姓名、通信地址等数据，这些数据也无法由加工2.3自己产生，因此，加工2.3不满足数据守恒的条件2023/1/31106/130考生名册2.5分析试题难度难度分析表2.4分类统计成绩分类统计表2.3制作通知单考生通知单2.2审定合格者正式成绩清单合格标准试题得分清单2.1检查成绩清单成绩清单正确成绩清单错误成绩清单同名的实例同一个数据处理的输出数据流和输入数据流即使组成成份相同，仍应对它们取不同的名字，以表示它们是不同数据流例如，“报名单”和“合格报名单”允许一个处理有两个相同的数据流分别流向两个不同的处理2023/1/31107/130分层数据流图的完整性每个数据处理至少有一个输入数据流和一个输出数据流在整套分层数据流中，每个数据存储应至少有一个处理读该文件，有另一个处理写该文件分层数据流图中的每个数据流和数据存储都必须命名(除了流入或流出数据存储的数据流)，并保持与数据字典的一致2023/1/31108/130其它需注意的问题避免一个加工有过多的数据流当一个加工存在许多数据流时往往意味着分解不合理解决办法：重新分解1)把需要重新分解的某张图(含有该复杂加工的图)的所有子图连接成一张图2)把连接后的图重新划分成几个部分，使各部分之间的联系最小3)重新定义父图，即第2)步中的每个部分作为父图中的一个加工4)重新建立各子图，即第2)步中的每个部分都是一张子图5)为所有的加工重新命名和编号2023/1/31109/130其它需注意的问题分解尽可能均匀理想目标：任何两个加工的分解层数之差不超过1应尽可能使分解均匀，对于分解不均匀的情况应重新分解先考虑稳定状态，忽略琐碎的枝节先考虑稳定状态下的各种问题，暂时不考虑系统如何启动、如何结束、出错处理以及性能等问题随时准备重画对于一个复杂的软件系统，往往要经过反复多次的重画和修改才能构造出完整、合理、满足用户需求的分层DFD分析阶段遗漏下来的一个错误，到开发后期要化费几百倍代价来纠正这个错误2023/1/31110/1302.4数据流图系统流程图（SystemFlowchart）：反应主体框架，无细节处理。数据流图（DataFlowDiagram，DFD）：反应数据走向，仅描述数据在系统中如何流动，如何处理和存储，它不考虑时序关系。图中的有向线段表示了数据流。程序流程图（Progranflowchart）：描述程序中控制流的情况，即程序中处理的执行顺序和执行序列所依赖的条件，图中的有向线段表示的是控制流,从一个处理走到下一个处理。人们对解决问题的方法、思路或算法的一种描述。

2023/1/31111三、需求分析3.1需求分析的任务2023/1/311123.1需求分析的任务分析系统的数据要求建立概念模型（概念性的数据模型）E-R图形象描绘数据结构层次方框图Warnier图IPO图数据结构规范化2023/1/311133.1需求分析的任务导出系统的逻辑模型数据流图、E-R图、状态转换图、数据字典、算法描述修正系统的开发计划重估成本进度变化2023/1/311143.1需求分析的任务需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。2023/1/31115软件需求分析阶段的工作，可以分为以下4个方面：对问题的识别分析与综合编写需求分析文档需求分析评审

2023/1/31116四、系统设计2023/1/311172023/1/31118结构化设计传统的软件工程方法学采用结构化设计(StructuredDesign,SD)技术完成软件设计工作，分为两阶段。总体设计（概要设计、初步设计）详细设计总体设计基本目的：概括地说，系统应该如何实现。划分系统的物理元素——程序、文件、数据库、人工过程、文档。设计软件的结构——每个程序由哪些模块组成，这些模块相互间的关系2023/1/31119结构化设计与结构化分析关系软件设计必须依据对软件的需求来进行，结构化分析的结果为结构化设计提供了最基本的输入信息。2023/1/31120分析模型的每个元素都提供了创建设计模型时所需要的信息。下图描绘了软件设计过程中的信息流。由数据模型、功能模型和行为模型清楚地表示的软件需求被传送给软件设计者，他们使用适当的设计方法完成数据设计、体系结构设计、接口设计和过程设计。结构化设计与结构化分析关系2023/1/31121在软件设计期间所做出的决策，将最终决定软件开发能否成功，更重要的是，这些设计决策将决定软件维护的难易程度。设计是软件开发过程中决定产品质量的关键阶段：提供了可以进行质量评估的软件表示把用户需求准确转变为最终产品是后续所有软件开发与维护步骤的基础设计的重要性设计过程总体设计的两个阶段系统设计阶段，确定系统的具体实现方案结构设计阶段，确定软件结构1、设想供选择的方案2、选取合理的方案系统流程图组成系统的物理元素清单成本/效益分析实现这个系统的进度计划2023/1/31122

设计过程3、推荐最佳方案对比各种合理方案，推荐一个最佳方案制定详细的实现计划4、功能分解设计所有程序和文件（或数据库）结构设计——程序由哪些模块组成、模块间的关系过程设计——确定每个模块的处理过程（详细设计阶段任务）2023/1/31123

设计过程从实现角度把复杂功能进一步分解将数据流图细化使用IPO图描述每个算法5、设计软件结构把模块组织成良好的层次（层次图、结构图）6、设计数据库7、制定测试计划2023/1/311242023/1/31125

设计原理5.2.1模块化模块是由边界元素限定的相邻的程序元素(例如，数据说明，可执行的语句)的序列，而且有一个总体标识符来代表它。像Pascal或Ada这样的块结构语言中的Begin…end对，或者C,C++和Java语言中的{…}对，都是边界元素的例子。过程、函数、子程序和宏等，都可作为模块。面向对象范型中的对象(见第9章)是模块，对象内的方法也是模块。模块是构成程序的基本构件。2023/1/31126模块化和软件成本模块化——各个击破，复杂问题简单化。接口成本：不能无限制的分割问题。适当模块数：总成本最低。——如何确定：适当模块数？模块大小？

模块化2023/1/31127模块化Meyer提出了五条标准，可以用这五条标准来评价一种设计方法定义有效的模块系统的能力。下面列出这五条标准。模块可分解性 如果一种设计方法提供了把问题分解为子问题的系统化机制，它就能降低整个问题的复杂性，从而可以实现一种有效的模块化解决方案。2023/1/31128模块可组装性 如果一种设计方法能把现有的(可重用的)设计构件组装成新系统，它就能提供一种并非一切都从头开始做的模块化解决方案。模块可理解性 如果可以把一个模块作为一种独立单元(无需参考其他模块)来理解，那么，这样的模块是易于构造和易于修改的。模块化2023/1/31129模块连续性 如果对系统需求的微小修改只导致对个别模块，而不是对整个系统的修改，则修改所引起的副作用将最小。模块保护性 如果在一个模块内出现异常情况时，它的影响局限在该模块内部，则由错误引起的副作用将最小。模块化2023/1/31130模块化优点采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。因为程序错误通常局限在有关的模块及它们之间的接口中，所以模块化使软件容易测试和调试，因而有助于提高软件的可靠性。因为变动往往只涉及少数几个模块，所以模块化能够提高软件的可修改性。模块化也有助于软件开发工程的组织管理。模块化2023/1/31131人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。5.2.2抽象人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。2023/1/31132软件系统进行模块设计时，可用层次的方式构造和分析复杂系统，即有不同的抽象层次。在最高的抽象层次上，可以使用问题所处环境的语言概括地描述问题的解法。在较低的抽象层次上，则采用过程化的方法。复杂的动态系统：高级的抽象概念构造和理解较低的层次…最低层次、具体元素。抽象2023/1/31133过程的抽象（软件工程每一步都可以看做是对软件解决方法的抽象化过程的一次细化）可行性研究：完整部件需求分析：使用熟悉方式描述软件解法设计：越来越具体实现：抽象的最低层。数据的抽象（在不同层次上描述数据对象的细节，定义与数据对象相关的操作）抽象2023/1/31134逐步求精是人类解决复杂问题时采用的基本技术，也是许多软件工程技术的基础。逐步求精：“为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。”求精实际上是细化过程。从在高抽象级别定义的功能陈述(或信息描述)开始。该陈述仅仅概念性地描述了功能或信息，但是并没有提供功能的内部工作情况或信息的内部结构。求精要求设计者细化原始陈述，随着每个后续求精(细化)步骤的完成而提供越来越多的细节。逐步求精2023/1/31135逐步求精：帮助软件工程师把精力集中在与当前开发阶段最相关的方面目前不需要考虑的细节留到以后考虑把一个时期内必须解决的问题按照优先级排序自顶向下的策略逐步求精2023/1/31136抽象与求精是一对互补的概念。抽象使得设计者能够说明过程和数据，同时却忽略低层细节。事实上，可以把抽象看作是一种通过忽略多余的细节同时强调有关的细节，而实现逐步求精的方法。求精则帮助设计者在设计过程中揭示出低层细节。这两个概念都有助于设计者在设计演化过程中创造出完整的设计模型。逐步求精2023/1/31137应用模块化原理时，自然会产生的一个问题是：“为了得到最好的一组模块，应该怎样分解软件”。信息隐藏原理指出：应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。信息隐藏和局部化

2023/1/31138隐藏模块的实现细节模块之间只交换那些为了完成软件功能而必须交换的信息对模块内部实现细节的访问限制修改期间由于疏忽而引入的错误很少可能传播到其他模块信息隐藏和局部化

2023/1/31139模块独立“模块独立”概念是模块化、抽象、逐步求精和信息隐藏等概念的直接结果，也是完成有效的模块设计的基本标准。希望设计这样的软件结构：每个模块完成一定相对独立的子功能与其他模块之间的关系简单2023/1/31140模块独立“模块独立化”原因：易于开发易于测试和维护模块的独立程度可以由两个定性标准来度量，这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间互相依赖(连接)紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。2023/1/31141耦合是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。在软件设计中应该追求尽可能松散耦合的系统。在这样的系统中可以研究、测试或维护任何一个模块，而不需要对系统的其他模块有很多了解。此外，由于模块间联系简单，发生在一处的错误传播到整个系统的可能性就很小。因此，模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。耦合2023/1/31142常见的耦合程度：无耦合：任何一个模块都独立工作，现实系统中不存在数据耦合：模块间交换的信息只有数据（例如：函数参数传递）控制耦合：模块间传递控制信息（例如：传递参数flag，用于控制不同功能）特征耦合：把整个数据结构作为参数传递，而被调用的模块只需要使用其中一部分数据（例如：日期结构）公共环境耦合：多个模块通过公共数据环境相互作用（公共环境包括：全局变量、共享的通信区、内存的公共覆盖区、文件、物理设备等）松散的公共环境耦合（一个读数据，一个取数据）紧密的公共环境耦合（两个既读数据又取数据）内容耦合：一个模块访问另一个模块的内部数据一个模块不通过正常入口而转到另一个模块的内部两个模块有一部分程序代码重迭一个模块有多个入口耦合2023/1/31143总之，耦合是影响软件复杂程度的一个重要因素。应该采取下述设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。高耦合：一个程序员完成一个大任务低耦合：两个程序员各完成一个小任务耦合思考题确定模块之间的耦合类型。

假设模块P、T、U更新同一个数据库2023/1/31144数据耦合控制耦合数据or特征P、T、U公共环境耦合2023/1/31145内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。力求高内聚；通常中等程度的内聚也是可以采用的，而且效果和高内聚相差不多；低内聚很不好，不要使用。内聚2023/1/31146内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。内聚和耦合都是进行模块化设计的有力工具，但是实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。低内聚：偶然内聚：一个模块任务间关系松散或者没有关系逻辑内聚：一个模块完成的任务在逻辑上属于相同或者相似的一类时间内聚：模块包含的任务必须在同一段时间内执行内聚2023/1/31147中内聚过程内聚：一个模块内的处理元素相关，并且以特定的次序执行通信内聚：模块中所有元素都使用同一个输入数据、产生同一个输出数据高内聚顺序内聚：一个模块内的处理元素和同一个功能密切相关，并且必须顺序执行功能内聚：模块内所有处理元素属于一个整体，完成一个单一的功能内聚2023/1/31148事实上，没有必要精确确定内聚的级别。重要的是设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过修改设计提高模块的内聚程度，降低模块间的耦合程度，从而获得较高的模块独立性。内聚思考题确定每个模块的内聚类型。2023/1/31149功能内聚偶然内聚2023/1/31150启发规则软件工程师们在开发计算机软件的长期实践中积累了丰富的经验，总结这些经验得出了一些启发规则。启发规则虽然不像前两节讲述的基本原理那样普遍适用，但是在许多场合仍然能给软件工程师有益的启示，往往能帮助他们找到改进软件设计提高软件质量的途径，因此有助于实现有效的模块化。2023/1/311511改进软件结构提高模块独立性2模块规模应该适中3深度、宽度、扇出和扇入都应适当4模块的作用域应该在控制域之内5力争降低模块接口的复杂程度6设计单入口单出口的模块7模块功能应该可以预测启发规则2023/1/311521改进软件结构提高模块独立性软件初步结构审查分析模块分解或合并降低耦合提高内聚比如：多个模块共有的子功能可以独立成一个模块2模块规模应该适中规模过大：理解不充分，进行分解规模过小：系统接口复杂启发规则2023/1/311533深度、宽度、扇出和扇入都应适当深度：软件结构中控制的层数宽度：软件结构中同一个层次上的模块总数最大值扇出：一个模块直接控制（调用）的模块数目扇入：有多少个上级模块直接调用它启发规则启发规则2023/1/311542023/1/311554模块的作用域应该在控制域之内启发规则作用域：受该模块内一个判定影响的所有模块的集合。控制域：这个模块本身以及所有直接或者间接从属于它的模块的集合。2023/1/311564模块的作用域应该在控制域之内启发规则例：模块A做出的判定影响模块G。模块G在模块A的控制域中模块G不在模块A的作用域中出现控制耦合,如何调整？方案1：模块A移到模块M中方案2：模块G移动模块A底下2023/1/311575力争降低模块接口的复杂程度仔细设计模块接口——信息传递简单、和模块的功能一致例：求一元二次方程的根模块QUAD_ROOT(TBL,X)，其中TBL为系数数组，X为根数组。参数含义不清晰，容易引起混淆产生错误，改为： QUAD_ROOT(A，B，C，ROOT1，ROOT2)，其中A、B、C为系数，ROOT1和ROOT2为根。启发规则2023/1/311585力争降低模块接口的复杂程度接口复杂接口不一致（即看起来传递的数据之间没有联系）是紧耦合或低内聚的征兆。启发规则2023/1/311596设计单入口单出口的模块避免内容耦合7模块功能应该可以预测模块可预测：相同的输入产生相同的输出启发规则五、系统实现1、实现2、白盒测试3、黑盒测试2023/1/31160通常把编码和测试统称为实现。所谓编码就是把软件设计翻译成计算机可以理解的形式——用某种程序设计语言书写的程序。作为软件工程过程的一个阶段，编码是设计的自然结果，因此，程序的质量主要取决于软件设计的质量。但是，所选用的程序设计语言的特点和编码风格也会对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。2023/1/31161无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分人的主观认识不可能完全符合客观现实与工程密切相关的各类人员之间的通信和配合也不可能完美无缺在软件生命周期的每个阶段都不可避免地会产生差错阶段审查，尽可能早地发现并纠正差错经验表明阶段审查并不能发现所有差错此外在编码过程中还不可避免地会引入新的错误2023/1/311622023/1/311632023/1/31163测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。在编写出每个模块之后就对它做必要的测试，称为单元测试，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。2023/1/311642023/1/311652023/1/31165大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40%以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他步骤总成本的3～5倍。测试目标是发现软件中的错误，但是，发现错误并不是最终目的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件，因此，通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的。调试是测试阶段最困难的工作。在对测试结果进行收集和评价的时候，软件所达到的可靠性也开始明朗了。软件可靠性模型使用故障率数据，估计软件将来出现故障的情况并预测软件的可靠性。2023/1/311667.6白盒测试技术测试方案包括：具体的测试目的（具体测试什么功能）应该输入的测试数据（难点）预期的结果要求：选用少量“最有效的”测试数据（不可能穷尽）设计测试方案的基本目标是，确定一组最可能发现某个错误或某类错误的测试数据。典型白盒测试技术：逻辑覆盖；控制结构测试2023/1/31167测试用例7.6.1逻辑覆盖有选择地执行程序中某些最有代表性的通路是对穷尽测试的唯一可行的替代办法。所谓逻辑覆盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。测试数据执行(或叫覆盖)程序逻辑的程度可以划分成不同的等级2023/1/311682023/1/311692023/1/31169从覆盖源程序语句的详尽程度分析语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖7.6.1逻辑覆盖1.语句覆盖2023/1/311701.语句覆盖选择足够多的测试数据，使被测程序中每个语句至少执行一次。测试用例的设计格式如下【输入的(A,B,X)，输出的(A,B,X)】为图例设计满足语句覆盖的测试用例是:

【(2,0,4)，(2,0,3)】

覆盖sacbed2023/1/311712023/1/311711.语句覆盖1.语句覆盖缺点：逻辑覆盖少AND错写为ORX>1错写为X<1错误检查不出来2.判定覆盖2.判定覆盖（分支覆盖）不仅每个语句必须至少执行一次而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。2023/1/311722判定覆盖【(2,0,4)，(2,0,3)】覆盖sacbed

【(1,1,1)，(1,1,1)】覆盖sabd（只覆盖一半路径）另一组可用的测试用例:

【(2,1,1)，(2,1,2)】覆盖sabed

【(3,0,0)，(3,0,0)】覆盖sacbd（只覆盖一半路径）2023/1/311733条件覆盖3.条件覆盖不仅每个语句至少执行一次而且使判定表达式中的每个条件都取到各种可能的结果。2023/1/311743条件覆盖为了做到条件覆盖，应该选取测试数据使得:在a点有下述各种结果出现：A>1,A<=1,B=0,B!=0;在b点有下述各种结果出现：A=2,A!=2,X>1,X<=1。2023/1/311752023/1/311762023/1/31176使用下面两组测试数据就可以达到上述覆盖标准：A=2，B=0，X=4（满足A>1，B=0，A=2，X>1的条件，执行路径sacbed）A=1，B=1，X=1（满足A<=1，B!=0，A!=2，X<=1的条件，执行路径abd）3条件覆盖3条件覆盖尽管条件覆盖通常比判定覆盖强，因为它是判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值。但是，有些情况下，满足条件覆盖不一定满足判定覆盖A=2，B=0，X=1（满足A>1，B=0，A=2，X<=1的条件，执行路径sacbed）A=1，B=1，X=2（满足A<=1，B!=0，A!=2，X>1的条件，执行路径sabed）条件b始终为true2023/1/311774.判定/条件覆盖4.判定/条件覆盖既然判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，自然会提出一种能同时满足这两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖。它的含义是，选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。2023/1/311785.条件组合覆盖5.条件组合覆盖条件组合覆盖是更强的逻辑覆盖标准，它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。2023/1/311795.条件组合覆盖共有8中可能的条件组合：（1）A>1，B=0（2）A>1，B!=0（3）A<=1，B=0（4）A<=1，B!=0（5）A=2，X>1（6）A=2，X<=1（7）A!=2，X>1（8）A!=2，X<=12023/1/311805.条件组合覆盖【2，0，4】，针对（1）（5）两种组合，执行路径sacbed【2，1，1】，针对（2）（6）两种组合，执行路径sabed【1，0，2】，针对（3）（7）两种组合，执行路径sabed【1，1，1】，针对（4）（8）两种组合，执行路径sabd前述几种覆盖标准中最强的，但是并不一定能使程序中的每条路径都执行到（sacbd）2023/1/311812023/1/311822023/1/311825.条件组合覆盖满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准前述几种覆盖标准中最强的但是并不一定能使程序中的每条路径都执行到（sacbd）2023/1/311832023/1/311837.6.1逻辑覆盖从对程序路径的覆盖程度分析：点覆盖边覆盖路径覆盖2023/1/311842023/1/311847.6.1逻辑覆盖6.点覆盖连通图G的子图G‘是连通的，而且包含G的所有节点，则称G‘是G的点覆盖。使得程序执行路径至少经过流图的每个结点一次符合语句覆盖标准（流图中每个结点与一条或多条语句对应）2023/1/311852023/1/311857.6.1逻辑覆盖7.边覆盖连通图G的子图G‘‘是连通的，而且包含G的所有边，则称G‘‘是G的边覆盖。使得程序执行路径至少经过流图的每条边一次符合判定覆盖标准2023/1/311862023/1/311867.6.1逻辑覆盖8.路径覆盖使程序的每条可能路径都至少执行一次如果程序图中有环，则要求每个环至少经过一次2023/1/311872023/1/31187思考题1(1,1,1)(20,40,60)同时符合判定覆盖2023/1/311882023/1/31188思考题22023/1/311892023/1/31189思考题2答案判定覆盖用例(1,1,2,3)(-1,-1,-2,0)判定真假各走一次条件覆盖用例(1,1,2,2)(-1,-1,-2,-2)判定中每个条件真假各走一次第二个判断不符合判定覆盖判定/条件覆盖(1,1,2,0)(-1,-1,-2,0)同时满足判定覆盖和条件覆盖2023/1/311902023/1/31190思考题2答案条件组合覆盖用例①A>0,B>0②A>0,B<=0③A<=0,B>0④A<=0,B<=0⑤C>A,D<B⑥C>A,D>=B⑦C<=A,D<B⑧C<=A,D>=B2023/1/311912023/1/31191思考题2答案条件组合覆盖用例①A>0,B>0②A>0,B<=0③A<=0,B>0④A<=0,B<=0⑤C>A,D<B⑥C>A,D>=B⑦C<=A,D<B⑧C<=A,D>=B条件组合覆盖用例

(1,1,2,0)实现①⑤

(1,0,2,1)实现②⑥

(0,1,-1,0)实现③⑦(0,0,-1,1)实现④⑧提醒：设计测试用例的时候别忘了预期输出7.6.2控制结构测试根据程序的控制结构设计测试数据的技术基本路径测试条件测试循环测试2023/1/311922023/1/311932023/1/311931基本路径测试TomMcCabe提出的一种白盒测试技术。使用这种技术设计测试用例时，首先计算程序的逻辑复杂度，并以该复杂度为指南定义执行路径的基本集合。从该基本集合导出的测试用例可以保证程序中每条语句至少执行一次，而且每个条件在执行时都将分别取true(真)和false(假)值。7.6.2控制结构测试2023/1/311942023/1/31194基本路径测试技术设计测试用例的步骤：1.根据过程设计结果画出相应的流图2.计算流图的环形复杂度3.确定线性独立路径的基本集合7.6.2控制结构测试1.基本路径测试2023/1/311952023/1/311961.绘制流图复合条件必须分解为简单条件，每个条件对应一个结点2.计算流图的环形复杂度流图的环形复杂度为6。2023/1/31197图7.6求平均值过程的流图1.基本路径测试3.确定线性独立路径的基本集合所谓独立路径是指至少引入程序的一个新处理语句集合或一个新条件的路径，用流图术语描述，独立路径至少包含一条在定义该路径之前不曾用过的边。使用基本路径测试法设计测试用例时，程序的环形复杂度决定了程序中独立路径的数量，而且这个数是确保程序中所有语句至少被执行一次所需的测试数量的上界。2023/1/311981.基本路径测试路径1：1-2-10-11-13路径2：1-2-10-12-13路径3：1-2-3-10-11-13路径4：1-2-3-4-5-8-9-2-...路径5：1-2-3-4-5-6-8-9-2-...路径6：1-2-3-4-5-6-7-8-9-2-...路径4、5、6后面的省略号(...)表示，可以后接通过控制结构其余部分的任意路径(例如，10-11-13)。通常在导出测试用例时，识别出判定节点是很有必要的。本例中节点2、3、5、6和10是判定节点。2023/1/31199求平均值过程来说，由于环形复杂度为6，因此共有6条独立路径。1.基本路径测试4.设计可强制执行基本集合中每条路径的测试用例应该选取数据使得在测试每条路径时都适当地设置好了各个判定节点的条件。路径1的测试用例：value[k]＝有效输入值，其中k＜i(i的定义在下)value[i]＝-999，其中2≤i≤100预期结果：基于k的正确平均值和总数注意，路径1无法独立测试，必须作为路径4、5和6的一部分来测试。路径2的测试用例：

value[1]＝-999

预期结果：average＝-999，其他都保持初始值2023/1/312001.基本路径测试路径3的测试用例：试图处理101个或者更多个值前100个数值为有效输入预期结果：与测试用例相同注意：路径3也无法独立测试，必须作为路径4、5、6的一部分。路径4的测试用例：value[i]＝有效输入值，其中i＜100value[k]<minimum，其中k＜i预期结果：其于k的正确平均值和总数2023/1/312011.基本路径测试路径5的测试用例：

value[i]＝有效输入值，其中i＜100 value[k]＞maximum，其中k＜i

预期结果：其于k的正确平均值和总数路径6的测试用例：

value[i]=有效输入值，其中i＜100

预期结果：正确的平均值和总数2023/1/312022023/1/312032023/1/31203思考题32023/1/312042023/1/31204思考题3答案环形复杂度：V(G)=5独立路径上限为51-2-3-4-6-7-9-11-121-2-5-6-7-9-11-121-2-3-5-6-7-9-11-121-2-3-4-6-7-8-9-11-121-2-3-4-6-7-8-10-11-122023/1/312052023/1/31205思考题3答案①1-2-3-4-6-7-9-11-12 (1,1,2,2),(2,0)②1-2-5-6-7-9-11-12 (0,1,2,0),(-1,2)③1-2-3-5-6-7-9-11-12 (1,0,2,0),(1,2)

④1-2-3-4-6-7-8-9-11-12 (1,1,0,-1),(2,1)⑤1-2-3-4-6-7-8-10-11-12 (1,1,0,2),(2,2)2.条件测试用条件测试技术设计出的测试用例，能够检查程序模块中包含的逻辑条件。