软件工程导论知识点总结

教材

《软件工程导论（第6版）》张海藩 牟永敏 编著；清华大学出版

课程目标

第一讲

软件的定义

软件不是程序，而是程序、数据以及开发、使用和维护程序需要的所有文档的完整集合。

• 程序：是能够完成预定功能和性能的可执行的指令序列。
• 数据：是使程序能够适当处理信息的数据结构。
• 文档：是开发、使用和维护程序所需要的图文资料。

=软件的特点

• 逻辑产品，具有抽象性；其生产主要是开发研制；不存在磨损、消耗和老化等问题；是脑力劳动，开发效率低；成本昂贵，要进行质量控制；对硬件和环境的依赖性，提出可以执行性问题；是复杂的。

软件分类

不同的分类基准：具体介绍基于功能的不同分类。

• 系统软件：居于计算机系统中最靠近硬件的一层，例如编译程序和操作系统。
• 支撑软件：支撑软件的开发、维护与运行的软件。
• 应用软件：特定应用领域专用的软件。

=软件开发的几个时期

1. 个人程序时期

• 程序设计完全凭程序员的经验和技艺以个人或小组方式进行。

2. 软件作坊时期

• 多人分工合作开始出现，需要对项目进行管理开发。
• 软件的规模与复杂性也不断的增加。
• 软件质量差，可靠性难以保证；成本难以控制；可维护性差。

软件危机

1. 软件危机定义：通常把在计算机软件的开发与维护过程中所遇到的一系列严重问题笼统地称为软件危机概括地说，软件危机包含以下两个方面的问题。

• 如何开发软件,以满足 会对软件日益增长的需求。
• 如何更有效地维护数量不断膨胀的已有软件。

2. 软件危机典型表现

• 对软件开发成本和进度的估计不准确；用户不满意；质量不可靠；不可维护；缺文档资料；成本渐增；开发生产速度跟不上计算机应用普及深入趋势。

3. 产生软件危机的原因

• 软件本身问题有关：管理和控制软件开发过程相当困难；测试阶段没能检测出全部错误；规模庞大，程序复杂性随规模增加指数上升；对用户要求认识不够，匆忙编写；实践中部分采用了错误的方法技术；忽视软件需求分析的重要性。
• 软件开发与维护的方法不正确有关：忽视软件配置其余成分；定义时期未正确全面理解用户需求；阶段越晚进行修改付出代价越大。

4. 消除软件危机的途径

• 首先正确认识软件；各类人员协同配合完成；使用成功案例的技术和方法；开发使用更好的软件工具。

软件工程

1. 软件工程定义：软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
2. 软件工程方法学

通常把在软件生命周期全过程中使用的一整套技术方法的集合成为方法学（范型）。

• 传统方法学（结构化范型）
  • 基本概念：采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务。
  • 特点：按顺序完成每个阶段的任务；开始和结束都有严格标准。
• 面向对象方法学
  • 基本概念：与上面相反，把数据和对数据的操作紧密的结合起来的方法。
  • 基本原则：尽量模拟人类习惯的思维方式；描述问题的问题空间（问题域）与实现解法的解空间（求解域）在结构上尽可能一致。
  • 优点：降低了软件产品的复杂性；简化了软件的开发和维护工作；提高了面向对象软件的可重用性。
• 传统方法学与面向对象方法学对比
  • 传统方法学以功能划分为导向面向过程，面向对象以对象作为整个问题分析的中心展开工作。
  • 都把软件开发划分为：分析、设计、编码和测试等几个阶段，但各个阶段的具体工作不同。

软件生命周期

1. 软件定义（系统分析）

• 问题定义：要解决的问题是什么；对用户访问调查，写书面 告，讨论修改得到客户确认。
• 可行性研究：问题有解决的办法么；是否继续这项工程。
• 需求分析：确定目标系统必须具备那些功能；得出经过用户确认的系统逻辑模型；用正式文档准确记录对目标系统的需求（规格说明书）。

2. 软件开发

• 总体设计：应该怎样实现目标系统；对比得出最佳方案；设计程序的体系结构，即确定程序由哪些模块组成以及模块间的关系。
• 详细设计（模块设计）：解法具体化；可以写出实际程序代码的详细规格说明书；详细设计每个模块，确定实现模块功能所需要的算法和数据结构。
• 编码和单元测试：写出容易理解维护的程序模块；对模块仔细的单元测试。
• 综合测试：各类测试（集成和验收测试）使软件达到预定要求；正式文档记录测试计划、方案和结果。
• （前两个系统设计，后两个系统实现）

3. 软件维护

• 关键任务：各种维护活动使系统持久满足用户需求。

• 改正性维护，也就是诊断和改正在使用过程中发现的软件错误。

• 适应性维护，即修改软件以适应环境的变化。

• 完善性维护，即根据用户的要求改进或扩充软件使它更完善。

• 预防性维护，即修改软件，为将来的维护活动预先做准备。

软件过程

• 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。通常使用生命周期模型概括地描述软件过程。

• （重点）瀑布模型 Waterfall Model（传统的和带反馈环的）

  • 概念及特点
    • 阶段间具有顺序性和依赖性：必须等前一阶段工作完成后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。
    • 推迟实现的观点：编码之前设置了系统分析与系统设计的各个阶段。
    • 质量保证的观点：每个阶段都必须完成规定的文档；并进行评审。
    • 适合于需求明确变化较小的软件项目。
  • 优缺点
    • 强迫开发人员采用规范的文档；严格规定了每个阶段必须提交的文档；每个阶段产品都经过质量验证。
    • 前期的需求理解和设计缺陷错误后期才能被发现，提高了成本，易失败；开发人员与用户缺乏有效沟通。

• （重点）快速原型模型 Prototype Model

  • 概念及特点
    • 快速建立起来的可以在计算机上运行的程序，完成的功能少于最终产品的。
    • 不带反馈环，软件开发基本是线性顺序进行的。（原因有二：原型系统已经通过与用户交互而得到验证，不会进行较大的返工；建立原型系统已经学到了许多东西，发生错误的可能性小。）
    • 适合于一些需求可变、模糊不定的软件系统开发。
  • 优缺点
    • 软件开发是线性顺序进行的；通常能满足用户真实需求。
    • 追求速度而忽视了软件的总体质量和长期的可维护性；开发过程不便于管理。

• （重点）增量模型 Incremental Model（渐增模型）

  • 概念及特点
    • 把软件产品作为一系列的增量构件来设计、编码、集成和测试。
    • 第一个增量构件往往实现软件的基本需求。
    • 适合于软件要求不明确，设计方案有一定风险的软件项目。
  • 优缺点
    • 客户可以不断看到软件产品，有足够时间学习适应新产品；多个构件并行开发，缩短开发时间；软件结构可拓展性好，便于日后升级
    • 软件体系结构要做到开放；多个构件并行开发，具有无法集成的风险。

• （重点）螺旋模型 Spiral Model

  • 概念及特点
    • 使用原型及其他方法来尽量降低风险（每个阶段都增加了风险分析过程的快速原型模型，即瀑布与快速的结合）
    • 适用于内部开发的复杂大型软件项目；需要开发人员具有丰富的风险评估和知识经验。
  • 优缺点
    • 有利于已有软件的重用；专注于软件质量；减少测试带来的风险；软件开发与维护没有本质区别。
    • 开发人员知识经验不够，会带来不可估计的风险。

• =喷泉模型

  • “喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性；后期维护时间越来越短。

• 统一开发过程RUP Rational Unified Process

  • 一个面向对象软件工程的通用业务流程。

• 敏捷开发过程 Agile Model

  • 敏捷是相对于传统注重文档的“文档”软件过程而言的；高效工作和快速响应变化的能力。

第二讲

可行性分析的基本任务

• 可行性研究的目的不是解决问题，而是确定问题是否值得去解决

1. 经济可行性：成本——效益分析；确定要开发的项目是否值得投资开发。
2. 技术可行性：采用技术是否先进；当下技术能否实现系统达到的目标；技术人员的技术水平是否具备。
3. 操作可行性：系统的操作方式在这个应用范围内是否行的通。
4. 法律可行性：考虑合同的责任、专利权、版权等一系列权益方面。

• 可行性分析典型步骤

1. 复查系统规模和目标：关于规模和目标的 告进一步复查确认；确保分析员正在解决的问题确实是要求他解决的问题。
2. 研究目前正在使用的系统：新的目标系统必须也能完成现有系统的基本功能；新系统必须解决旧系统中存在的问题；分析现有系统的文档资料和使用手册；实地考察。
3. 导出新系统的高层逻辑模型：参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后构建新的物理系统。
4. 进一步定义问题：前四个步骤实质上构成一个循环。
5. 导出和评价供选择的解法:分析员从他建议的系统逻辑模型出发，导出若干个较高层次的物理解法提供比较和选择；去掉操作角度看用户不能接受的方案；考虑开发成本和运行费用；确定选择后制定实现进度表，估计生命周期每个阶段的工作量。
6. 推动行动方针：是否继续进行这项开发工程；选择一种最好解法；进行较仔细的成本/效益分析。
7. 草拟开发计划书：估计对各类开发人员和各种资源的需要情况；给出下一阶段的详细进度表和成本估计。
8. 写文档提交审查：把上述各个步骤的工作结果写成清晰的文档。

系统流程图

• 基本概念：系统流程图是概括地描绘物理系统的传统工具。表达的是数据在系统各个部件之间流动的情况，而不是对数据进行加工处理的控制过程

• 基本符

（重点）数据流图

• 基本概念：数据流图(DFD)是一种图形化技术，她描绘信息流和数据从输入移动到输出的过程中所经受的变换。

• 基本符

案例

案例

第四讲

总体设计过程

• 典型步骤
  • 设想供选择的方案
  • 选取合理的方案
  • 推荐最佳方案
  • 功能分解
  • 设计软件结构
  • 设计数据库
  • 制定测试计划
  • 书写文档
  • 审查和复审

设计原理

• 模块化

  • 概念：模块是构成程序的基本构件；模块化就是把程序划分成独立命名且可以独立访问的模块；总成本曲线；复杂问题分解成许多容易解决的小问题。

• 抽象

  • 概念：抽象就是抽出事物的本质特性而暂时不考虑他们的细节。

• 逐步求精

  • 概念：通过逐步细化处理过程的层次而设计的；抽象与求精是一对互补的概念。

• 信息隐藏和局部化

  • 概念：一个模块内包含的信息对于不需要这些信息的模块来说，是不能访问的；局部化是指把一些关系密切的软件元素物理地放得彼此近。

• 模块独立

  • 概念：这样的软件容易开发出来；容易测试和维护。
  • 耦合与内聚

耦合与内聚

• 耦合（模块之间互联程度的度量）
  • 数据耦合：通过参数交换信息，而且交换的信息权仅仅是数据；低耦合。
  • 控制耦合：传递的信息中有控制信息（控制信息又时以数据形式出现）；中等耦合。
  • 特征耦合：当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。
  • 公共环境耦合：当两个或多个模块通过一个公共数据环境互相作用时，他们之间的耦合称为公共环境耦合。
  • 内容耦合：进入另一个模块内部；模块代码重叠；多个入口模块；属于最高程度的耦合。
• 内聚（标志一个模块内各个元素彼此结合的紧密程度）
  • 偶然内聚：一组关系松散的任务；各元素之间没有实质性联系；可理解性差；不可重用。
  • 逻辑内聚：完成的任务在逻辑上属于相同的一类；接口难以理解；局部功能的修改有时也会影响全局。
  • 时间内聚：同一段时间内执行；模块内操作之间的关系很弱。
  • 通信内聚：模块中所有元素都使用同一个输入数据和产生同一个输出数据，则称为通信内聚。
  • 顺序内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为顺序内聚。
  • 功能内聚：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能模块；最高程度的内聚。
• 高内聚低耦合

总体设计的启发式规则

1. 改进软件结构提高模块独立性
2. 模块规模应该适中
3. 深度、宽度、扇出和扇入都应适当
4. 模块的作用域应该在在控制域之内
5. 力争降低模块接口的复杂程度
6. 设计单入口单出口的模块
7. 模块功能应该能够预测

描绘软件结构的图形工具

• 软件结构图：是软件系统的模块层次结构，用来表达软件的组成模块机器调用关系。
• 层次图：用来描绘软件的层次结构，很适合在自顶向下设计的软件过程中使用
• HIPO图：每个方框都加上了编 （除了顶层的）

结构化设计方法

• 基本概念：结构化设计方法是一种把在数据流图映射为软件结构图的一种基于数据流的设计方法，信息流的类型决定了映射的方法

• 信息流两种类型：

  • 变换流：数据流图基本呈线性形状的结构，由输入、变换、输出三部分组成，变换是系统的变换中心。
  • 事务流：根据输入数据的类型，选出一个来执行。

• 结构化设计方法的典型步骤

  • 复审数据流图
  • 确定数据流图类型
  • 分解上层模块，设计中下层模块结构
  • 根据软件结构设计准则对软件结构求精并改进
  • 导出接口描述和全程数据结构
  • 复审

第五讲

结构程序设计

• 基本概念：如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连接，并且每个代码块只有一个入口和出口，则称这个程序是结构化的。上述经典定义过于狭隘，结构程序设计本质上并不是无GO TO 语句的编程方法，而是一种使程序代码容易阅读、容易理解的编程方法。

人机界面设计

• 设计问题

  • 系统响应时间：长度和易变性
  • 用户帮助设施：集成和附加
  • 出错信息处理
  • 命令交互

• 设计过程

  • 用户界面设计是一个迭代的过程，通常先创建设计模型，再用原型实现这个设计模型，并由用户适用和评估。

• 设计指南

  • 一般交互指南：涉及信息显示、数据输入和系统整体控制。
  • 信息显示指南：文字、图形和声音。
  • 数据输出指南：用户的大部分时间用在选择命令、输入参数和向系统提供输入。

过程设计工具

• 程序流程图

/p>

• PAD图

/p>

• PDL（过程设计语言|伪码）

面向数据结构的设计方法

• Jackson方法简介
  • 分析并确定输入数据和输出数据的逻辑结构。
  • 找出输入数据结构和输出数据结构中有对应关系的数据单元。
  • 从描绘数据结构的Jackson图导出描绘程序结构的Jackson图。
  • 列出所有操作和条件（包括分支条件和循环结束条件），并且把他们分配到程序结构图的适当位置。
  • 用伪码表示程序。

程序复杂程度的定量度量

• 好处：
  • 估算出软件中错误的数量以及软件开发需要用的工作量。
  • 比较两个不同设计或两个不同算法的优劣。
  • 可以作为模板规模的精确限度。
• McCabe方法（流图）
  • 根据程序控制流的复杂程度定量度量程序的复杂程度，这样度量出的结果称为程序的环形复杂度。
  • V(G)=E-N+2，E是边数，N是结点数。
  • V(G)=P+1，P是流图中判定结点的数目。

第六讲

面向对象方法四个要点

• 面向对象的软件系统是由对象组成的

• 所有对象都划分成各种对象类

• 按照子类(或称为派生类)与父类(或称为基类)的关系，把若干个对象类组成一个层次结构的系统

• 对象彼此之间仅能通过传递消息互相联系

面向对象方法的优点

• 与人类习惯的思维方法一致

• 稳定性好：根据问题领域的模型建立起来的，不是基于对系统应完成的功能的分解。

• 可重用性好

• 较易开发大型软件产品

• 可维护性好

（重点）面向对象基本概念

• 对象：对象是封装了数据结构及可以施加在这些数据结构上的操作的封装体，这个封装体有可以唯一地标识它的名字，而且向外界提供一组服务(即公有的操作)。对象中的数据表示对象的状态，一个对象的状态只能由该对象的操作来改变。

  • 特点：以数据为中心；对象是主动的；实现了数据封装；本质上具有并行性；模块独立性好。

• 类：在面向对象的软件技术中，“类”就是对具有相同数据和相同操作的一组相似对象的定义，也就是说，类是对具有相同属性和行为的一个或多个对象的描述，通常在这种描述中也包括对怎样创建该类的新对象的说明。

• 实例：某个特定的类所描述的一个具体的对象

• 消息：是面向对象系统中对象之间交互的途径，是向另一个对象发出的服务请求，请求对象参与某一处理或回答某一要求的信息，是对象之间建立的一种通信机制。

• 方法：就是对象所能执行的操作。

• 属性：就是类中所定义的数据，是实体所具有的性质的抽象。

• 封装：是指把数据和实现操作的代码集中起来放在对象内部。

  • 有一个清晰的边界；有确定的接口；受保护的内部实现。

• 继承：是子类自动地共享基类中定义的数据和方法的机制。

  • 继承具有传递性；单继承和多重继承；解法具体化；方法重写。

• 多态性：是指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。增加了面向对象软件系统的灵活性。

• 重载（两种）：函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字；运算重载是指同一个运算符可以施加于不同类型的操作数上面。

统一建模语言UML

• 相关概念

  • 模型就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。
  • 建模的目的主要是为了减少复杂性。
  • 面向对象方法最基本的原则，是按照人们习惯的思维方式，用面向对象观点建立问题域的模型，开发出尽可能自然地表现求解方法的软件。
  • 面向对象方法开发软件，通常需要建立对象模型（最重要基本核心）、动态模型和功能模型。

• 概念

  • 一种标准的图形化建模语言，是面向对象分析与设计的一种标准表示。
  • 捕获系统静态结构和动态行为的信息。
  • 不是一种程序设计语言，但可以和各种编程语言相联系。

• 发展历史

  • Grady Booch，Ivar Jacobson，James Rumbaugh在1994和1995年期间发明。
  • 1996年被OMG认为标准。
  • 2005年作为ISO标准

• 特点

  • 统一标准
  • 面向对象
  • 可视化，表达能力强大
  • 独立于过程
  • 容易掌握使用
  • 与编程语言的关系

• 应用范围

  • 最广泛的应用是对软件系统进行建模，也可以用于许多非软件系统领域。
  • 需求分析阶段>>用例模型；分析和设计阶段>>静态模型；开发阶段>>转换编程语言；测试阶段>>作为测试依据。

• UML“4+1”视图

• 类图
  • 使用类描述系统的结构，展示了系统中类的静态结构。
  • 关联：一条直线表示关联关系，直线两端上的数字表示重数。
    • 聚集和组合表示整体-部分的关联
  • 依赖
  • 泛化：描述类的一般-特殊关系。
  • 实现：将一个模型连接到另一个模型，通常情况下，后者是行为的规约（如接口）。
  • 泛化与实现的区别：泛化是针对同层级元素之间的连接，而实现是针对不同语义层上的元素的连接。

• 顺序图
  • 描述了一组对象的交互方式，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。
  • 由对象、生命线、控制焦点和消息组成。

• 活动图
  • 用于表达系统动态特性的图。描述一系列具体动态过程的执行逻辑，展现活动和活动之间转移的控制流。
  • 主要组成元素包括：动作、活动、动作流、分支与合并、分叉与汇合、泳道和对象流等。

• 部署图
  • 用于显示系统中硬件和软件的物理结构，可以显示实际中的计算机和设备，以及它们之间的互联关系。

• 面向对象基本概念-主题

  • 主题是指导读者理解大型、复杂模型的一种机制。划分为不同主题。

• 面向对象分析主要活动

  • 需求获取
  • 建立对象模型
    • 确定类与对象
    • 确定关联
    • 划分若干主题
    • 确定属性
    • 识别继承关系
    • 定义服务
  • 建立功能（用例）模型
    • 确定系统范围和边界
    • 确定参与者
    • 确定用例：包含和扩展
    • 确定用例之间的关系
  • 建立动态模型（动态模型着重表示应用系统的控制逻辑）
    • 编写脚本
    • 设计用户界面
    • 画UML顺序图、活动图、事件跟踪图
    • 画状态图
  • 建立物理模型

面向对象设计（OOD）

• 设计原理：把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。是一个逐渐扩充模型的过程。

• 设计准则：模块化;抽象;信息隐藏;弱耦合;强内聚;可重用

• 启发规则

  • 设计结果应该清晰易懂
  • 一般-特殊结构的深度应该适当
  • 设计简单的类
  • 使用简单的协议
  • 使用简单的服务
  • 把设计变动减至最小

• =软件重用（同一事物不作修改或稍加修改就多次重复使用）

  • 级别：代码重用；设计结果重用；分析结果重用
  • 类构件重用方式：实例重用；继承重用；多态重用
  • 效益：质量理想下无误；生产率高；成本低

• 设计过程

  • 建立软件体系结构环境图
  • 软件体系结构设计
  • 对各个子系统进行设计
  • 对象设计及优化

• 对象设计

  • 以问题域的对象设计为核心，其结果是一个详细的对象模型。
  • 主要任务
    • 设计类中的服务
    • 设计类的关联
    • 对象设计优化

第八讲

编码

• 编程语言的选择
  • 机器语言
  • 汇编语言
  • 高级语言
• 编程风格
  • 版权和版本声明
  • 程序版式
  • 注释
  • 命名规则
  • 数据说明
  • 语句构造
  • 输入输出
  • 效率（计算机资源利用率）

测试

• 测试步骤
  • 模块测试（单元测试）：编码和详细设计错误
  • 子系统测试（集成测试）：测试接口
  • 系统测验（集成测试）：软件设计错误或需求说明错误
  • 验收测试（确认测试）：用户积极参与；需求说明错误
  • 平行运行：同时运行新开发处来的系统和将被　它取代的旧系统。

1. 单元测试

• 单元测试

  • 软件设计最小单元——模块
  • 人工测试和计算机测试
  • 主要使用白盒测试技术

• 测试重点

  • 模块接口
  • 局部数据结构
  • 重要的执行通路
  • 出错处理通路
  • 边界条件

• 驱动模块：“主程序＂

• 存根模块：”虚拟子程序“

2. 集成测试（测试和组装软件的系统化技术）

• 非渐增式测试：改正错误非常困难

• 渐增式测试

  • 自顶向下集成
    • 分类：深度优先和宽度优先
    • 优缺点:不需要测试驱动程序，早期发现上层模块的接口错误；需要存根程序，低层模块错误发现较晚，早期不能充分展开人力。
  • 自底向上集成
    • 优缺点：刚好相反

• 回归测试

  • 是指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。

3. 确认测试

• 概念及范围
  • 验证软件的有效性，确实满足用户需求。参考软件需求规格说明书。
  • 通常采用黑盒测试
  • 功能要求、安全性、可移植性、兼容性和可维护性等。
• Alpha测试
  • 由用户再开发者的场所进行；受控的环境
• Beta测试
  • 由软件的最终用户们在一个或多个客户场所进行

4. 平行运行

• 测试技术
  • 白盒测试、黑盒测试和调试

1. 白盒测试

• 概念

  • 关注内部细节和逻辑结构
  • 测试数据和预期的输出结果称为测试用例
  • 使用合适的测试数据技术和高效的测试数据

• 代码检查法：检查代码和设计的一致性

• 程序插桩技术：插入一些打印语句，打印有关信息了解程序执行时的一些动态特性。

• 逻辑覆盖

  • 语句覆盖：选择足够多的测试数据，使被测程序中每个语句至少执行一次。
  • 判定覆盖（分支覆盖）：不仅每个语句必须至少执行一次，而且每个判定的每个分支都应该至少执行一次。
  • 条件覆盖：不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。
  • 判定条件覆盖：有时不比条件覆盖强；大多数计算机不能用一条指令对多个条件作出判定。
  • 条件组合覆盖：每个判定表达式中条件的各个可能组合都至少出现一次。
  • 边覆盖和路径覆盖

2. 黑盒测试

• 概念

  • 着重测试软件功能
  • 白盒在早期，黑盒在后期；与白盒测试互补。

• 等价类划分法：把程序的输入域划分成若干个数据域，据此导出测试用例。（有效等价类和无效等价类）

• 边界值分析法：是上一种方法的补充。

• 错误推测法：很大程度上靠直觉和经验进行。

3. 调试（纠错）

• 调试是在测试发现错误之后排除错误的过程

第九讲

软件维护

• 软件维护定义：所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护

• 软件维护特点

  • 机构化维护与非结构化维护的差别巨大
  • 维护代价高昂
  • 维护的问题很多

• 软件维护过程

  • 概念：维护过程本质上是修改了和压缩了的软件定义和开发过程
  • 维护组织
  • 维护 告
  • 维护事件流
  • 保护维护记录
  • 评价维护活动

• 软件的可维护性

  • 维护人员理解、改正、改动、或进这个软件的难易程度。
  • 决定因素：可理解性；可测试性；可修改性；可移植性；可重用性。

• 软件维护的副作用

  • 修改代码的副作用；修改数据的副作用；修改文档的副作用

软件工程管理

• 软件估算

• 软件开发进度计划

  • Gantt图
  • PERT图

• 软件开发人员组织

  • 民主制程序员组
  • 主程序员组
  • 现代程序员组