电子科技大学 - 软件工程期末复习提纲

教材：软件工程：共同演进的方法介绍
主编：田文洪

1 软件工程背景知识

1.1 软件工程的定义

• 将系统化的、科学化的、可量化的方法应用于软件的开发、运行和维护，即针对软件的工程应用；
• 对上述应用方法的研究。

1.2 软件定义

软件 = 程序 + 数据 + 文档

• 程序：按事先设计的功能和性能需求执行的指令序列
• 数据：是程序能正常操纵信息的数据结构
• 文档：与程序开发、维护和使用有关的图文材料

1.3 软件的特征

• 软件是逻辑的，而不是物理的
• 软件是开发的或者是工程化的，并不是制造的
• 软件开发环境对产品影响较大
• 软件开发时间和工作量难以估计
• 软件会多次修改
• 软件的开发进度几乎没有客观衡量标准
• 软件测试困难
• 软件不会磨损和老化
• 软件维护易产生新的问题
• 软件生产是简单的拷贝

1.4 软件分类

• 系统软件（操作系统）
• 应用软件(办公软件)
• 工程/科学软件 (Matlab, Maple)
• 嵌入式软件 (iPod，iphone)
• 产品线软件(Intel, Simens)
• Web 应用(Web applications)
• 普适计算—无线网络
• 网络资源—网络作为一个计算引擎
• 开放源码 (好事，也是一种潜在的祸根！)
• 云计算/边缘计算

**1.5 软件危机的定义及表现

定义：在计算机软件的开发和维护过程中所遇到的一系列严重问题

表现：

• 开发成本和进度估计不准，开发进度难以控制
• 用户对“已完成的”软件系统不满意
• 软件质量和可靠性差强人意
• 软件常常是不可维护的
• 软件通常没有适当的文档资料
• 软件成本逐年上升
• 软件开发生产率滞后于硬件和计算机应用普及

1.6 产生软件危机的原因

客观：软件本身特点(太复杂了)

• 逻辑思维产物
• 规模庞大

主观：不正确的开发方法(人类不重视)

• 忽视需求分析
• 错误认为：软件开发 = 程序编写
• 轻视软件维护

**1.7 软件工程原则

• 使用阶段性生命周期计划的管理
• 进行连续的验证
• 保证严格的产品控制
• 使用现代编程工具/工程实践
• 保持清晰的责任分配
• 用更好更少的人
• 保持过程改进

---

2 软件过程模型

1. 了解软件过程和软件过程模型概念；
2. 理解软件过程的重要性，了解不同过程模型的优缺点；
3. 掌握如何为不同的项目选择过程模型。

2.1 软件过程

软件过程定义了软件生产的一系列活动，这些活动贯穿于软件开发的整个过程。
包括以下活动：

• 沟通：包括软件设计者与客户沟通，客户提出要求，软件设计者收集材料，以及其它相关活动；
• 计划：软件开发小组讨论使用何种方法及何种工具来实现客户需求；
• 建模：软件开发小组讨论选择何种模型来满足需求。不同的需求需要不同的模型；
• 构造：编码和测试；
• 部署：软件交付给客户。客户给出建议和反馈，软件实施小组改进软件。

2.2 软件过程模型

软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。 软件过程模型也常称为：软件开发模型、软件生存周期模型、软件工程范型。

• 瀑布模型（经典的生命周期模型）

  软件开发过程与软件生命周期是一致的。规定了各项软件工程活动，以及它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。是一种使用广泛，以文档为驱动的模型。

  特点：

  • 阶段间具有顺序性和依赖性；
  • 推迟实现的观点；
  • 每个阶段必须完成规定的文档；
  • 每个阶段结束前完成文档审查,及早改正错误。

  主要问题：线性过程太理想化，包括：

  • 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
  • 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
  • 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

  适用范围：瀑布模型适用于系统需求明确、技术成熟、工程管理较严格的场合。

  优点：

  • 简单，过程透明性高，过程可管理性高
  • 推迟实现，软件实现前必须进行系统分析和设计工作
  • 以阶段评审和文档控制为手段进行质量控制，能够及时发现并纠正软件缺陷，能够达到预期质量要求

  缺点：

  • 模型灵活性差，不适合需求不明确或准确的场合
  • 模型风险控制能力弱
  • 过多的文档增加了工作量，当技术具有不确定性情况下完全以文档来评估项目进度时会产生错误的结论

• 演化过程模型

  • 原型模型

    适用范围：客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时，原型法是很好的选择。

    优点：

    • 可以得到比较良好的需求定义，容易适应需求的变化；
    • 开发费用低、开发周期短且对用户更友好。(低耗费，高适应性)

    缺点：

    • 设计者在质量和原型间有所折中
    • 客户没有意识到质量问题**(即质量上会产生影响)**
    • 不适用于开发大型系统
    • 软件可维护性差
    • 用户合作要求高，如果合作不好，反而会拖延开发进度

  • 并行开发模型

    适合于不同的工程团队共同开发的系统工程项目**(即合作型项目)**

  • 基于构件模型

    四个阶段：

    • 需求：？？？
    • 组件分析：根据需求规格搜索可满足该需求的组件。如果没有完全匹配的情况，则组件需要修改
    • 系统设计：基于重用的思想，设计者须考虑哪些是已有的可重用的组件，如果没有可重用的组件，还要设计新的软件
    • 开发和集成：在这个阶段，组件集成到系统中

    优点：

    • 充分利用软件复用，提高了软件开发的效率；
    • 允许多个项目同时开发，降低成本，提高了可维护性，可实现分步提交软件产品。

    缺点：

    • 缺乏通用的构件组装结构标准，风险较大；
    • 构件可重用和系统高效性之间不易协调；
    • 过分依赖构件会导致产品质量受构件质量影响。

• 增量过程模型

  增量过程模型是一种非整体开发的模型。是一种进化式的开发过程。它允许从部分需求定义出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善。如此反复进行，直至软件人员和用户对所设计的软件系统满意为止。(试探性的前进模型，不停添加新的组件和功能)

  • 增量模型

    增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序列，每个确定线性序列都会输出该软件的一个“增量”。

    

    特点：

    • 在前面增量的基础上开发后面的增量
    • 每个增量的开发可用瀑布或快速原型模型
    • 迭代的思路

    优点：

    1. 引入增量包概念，不需要提供完整的需求。只要有一个增量包出现，开发就可以进行。
    2. 在项目的初始阶段不需要投入太多的人力资源。
    3. 增量可以有效地管理技术风险，降低系统失败风险。
    4. 有利于增加客户信心，提高系统可靠性、可维护性和稳定性。

    缺点：

    1. 增量粒度难以选择：每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。
    2. 确定所有的基本业务比较困难。

  • RAD（快速应用开发模型）

    • 一种增量过程模型，强调短暂的开发周期；
    • 瀑布模型的“高速”变体：
      • 通过基于组件的构建方法实现快速开发
      • 如果需求以及项目范围得到明确界定，RAD 能使开发团队在很短的时间内（如60 到90 天）建立一个“全功能系统”

    缺点：

    1. 对大型项目而言，RAD 需要足够的人力资源。（人力要求多）
    2. 由于时间约束，开发者和客户都要实现承诺，沟通配合不当都会导致失败。（需要稳固的环境）
    3. **不适合：**不能合理模块化的系统、高性能需求并且要调整构件接口的、技术风险很高的系统均不适合

  • 螺旋模型**（强调风险管理，适合大型系统）**

    四个活动反复旋转进行：

    1. **制定计划：**确定软件目标，选定实施方案，弄清项目开发的限制条件。
    2. **风险分析：**分析所选方案，考虑如何识别和消除风险。
    3. **实施工程：**实施软件开发。
    4. **客户评估：**评价开发工作，提出修正建议。

    优点：

    • 支持用户需求的动态变化；
    • 原型可看作可执行的需求规格说明书，易于用户和开发人员共同理解，可作为继续开发的基础，为用户参与关键决策提供了方便；
    • 螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力；
    • 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。

    缺点：

    • 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；
    • 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。

    适用场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。

• 其他过程模型

  • 智能模型

  • 敏捷过程模型

    缺点：本身不是完整的方法论，是对生命周期过程的补充。

2.3 小结

• 软件工程是以质量为中心，过程、方法和工具为三要素
• 过程定义了谁在做什么，何时以及如何达到一定的目标。
• 软件过程决定了软件产品的质量，不同的项目需要不同的过程模型或者过程模型的组合

---

3 软件需求

1. 理解需求分析的过程。
2. 理解需求分析的主要步骤。
3. 知道如何根据需求分析来完成文档。

3.1 需求分析的定义

确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。(就是制定一个开发大纲)

需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合

3.2 需求分析综合要求

• 功能需求
• 性能需求
• 可靠性和可用性需求
• 出错处理需求
• 接口需求
• 约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件
• 逆向需求：说明软件不应该做什么
• 将来可能提出的要求

3.3 需求的类型

• 功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务
• 非功能性需求：必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等

3.4 需求分析任务

• 建立分析模型（准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么）
• 编写需求说明（<用需求规格说明书>规范的形式准确地表达用户需求）

**3.5 需求分析步骤

1. 需求获取(各种开会与用户面谈，调查问卷，各种商业观察)
2. 需求提炼（通过对问题建立模型将用户需求精确化完全化，核心在与建立分析模型）
3. 需求描述（撰写需求规格说明书）
4. 需求验证

3.6 分析模型工具（用于需求提炼）

• 数据流图、数据字典和加工规约
• CFD、控制规约和状态变迁图
• E-R图
• 用例图，对象-关系图，对象-行为图

3.7 需求规格说明书

• 软件系统的需求规格说明，是对待开发系统的行为的完整描述。他包含了功能性需求和非功能性需求。
• 完成的一个基本标志是形成了一份完整的、规范的需求规格说明书
• 为用户和开发者提供了初始的一个共同理解

3.8 需求验证

重要性：如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。

需求验证技术：

• 需求评审

2. 利用原型检验系统是否符合用户的真正需要。
3. 对每个需求编写概念性的测试用例。
4. 编写用户手册。用浅显易懂的语言描述用户可见的功能。
5. 自动的一致性分析。可用CASE工具检验需求模型的一致性。（PSL\PSA）

需求管理6大原则：

1. 建立需求基线，需求基线是需求变更的依据。
2. 制订简单、有效的变更控制流程，并形成文档
3. 成立项目变更控制委员会，负责裁定变更。
4. 需求变更一定要先申请然后在评估，最后经过与变更大小相当级别的评审确认。
5. 需求变更后，受影响的相关活动要进行相应变更，保持与更新的需求一致。
6. 妥善保存变更产生的相关文档。

---

4 软件设计工程

1. 理解软件设计和需求分析之间的相互关系
2. 掌握软件设计的主要技术、主要内容和主要方法
3. 能根据具体项目进行模块划分和软件架构设计

4.1 软件工程概要介绍

• 软件设计定义
  • 软件系统或组件的架构、构件、接口和其他特性的定义过程及该过程的结果。

• 软件设计
  • 软件工程生命周期中的一个活动
  • 进行软件编码的基础
  • 软件需求分析被转化为软件的内部结构
  • 是连接用户需求和软件技术的桥梁
• 设计含义
  • 设计=适用+艺术+质量
  • 适用性：满足用户需求，可被应用和使用
  • 艺术性：使用软件的体验应该是愉快的，赏心悦目
  • 质量：不含任何妨碍其功能的缺陷
• 软件设计含义
  • 根据需求分析结果，生成如何构造软件的相关技术文档和模型的过程，其告诉了软件构造者具体构造方法
  • 是软件生命周期的关键活的动
  • 是一种创新活动，是一种艺术

4.2 设计工程活动？？？什么鬼

• 软件架构设计（有时称为顶层设计）
  • 描述软件的顶层架构和组织，划分不同的组件
• 软件详细设计
  • 详细描述各组件以便能够编码实现
  • 软件设计主要为分解设计D-design；
  • 可以包括系列模式设计**FP-design；
  • 不包括创新设计I-design；因为创新设计被认为是需求分析和需求规格定义的一部分。

4.3设计过程与质量

好的设计应该具有如下三个特点

1. 设计必须实现在分析模型中包含的所有明确要求，必须满足客户所期望的所有隐含要求；
2. 设计必须是对编码人员、测试人员及后续的维护人员必须是可读可理解的；
3. 设计应提供该软件的完整视图，以从实现的角度解决数据、功能及行为等各领域方面的问题

设计指导原则

• 设计应该是一种架构
• 设计应该是模块化的
• 设计应该包含数据，体系结构，接口和组件各个方面
• 应该设计出系统所用的数据结构
• 应该设计出展现独立功能特性的各组件
• 应该设计出各组件与外部环境连接的各接口
• 设计由软件需求分析过程中获得信息驱动，采用可重复的方法导出
• 设计应该采用正确清楚地表示

设计质量属性

• 功能性
• 可用性
• 可靠性
• 性能
• 可支持性
  • 包含三个属性：扩展性、适应性、可维护性

4.4 设计技术

• 含义（抽象）：是感性认识世界的手段，是发现实物本质特征和方法的过程

• 抽象机制：参数化、规范化

• 规范化抽象

  • 过程抽象
  • 数据抽象
  • 控制（迭代）抽象

4.5 设计模式

• 含义
  • 通用：在给定上下文环境中一类共同问题的共同解决方案
  • 具体：一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结
• 目的
  • 为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性
• 范围
  • 由面向对象的程序构造，到(可视化的)对象框架构建

4.6 模块化

• 含义
  • 软件被划分为命名和功能相对独立的多个组件（通常称为模块），通过这些组件的集成来满足问题的需求
• 软件的模块性
  • 程序可被智能管理的单一属性
• 模块化的理论依据
  • 基于人类解决问题观测数据
• 模块化设计标准
  • 模块化分解性
  • 模块化组合性
  • 模块化可理解性
  • 模块化连续性
  • 模块化保护

4.7 模块隐藏

• 模块化基本问题
  • 如何分解软件系统以达最佳的模块划分
• 信息隐藏原则
  • 模块应该具有彼此相互隐藏的特性
  • 即：模块定义和设计时应当保证模块内的信息（过程和数据）不可以被不需要这些信息的其他模块访问
• 特点
  • 抽象有助于定义构成软件的过程（或信息）实体。
  • 信息隐藏原则定义和隐藏了模块内的过程细节和模块内的本地数据结构。

4.8 功能独立

• 含义
  • 每个模块只解决了需求中特定的子功能并从程序结构的其他部分看该模块具有简单的接口
• 好处
  • 易于开发：功能被划分，接口被简化
  • 易于维护（和测试）：次生影响有限，错误传递减少，模块重用
• 定性衡量标准
  • 内聚性：模块的功能相对强度
  • 耦合性：模块之间的相互依赖程度

4.9 细化

• 含义
  • 逐步求精的过程
• 与抽象的关系
  • 抽象使设计师确定过程和数据，但不局限于底层细节
  • 细化有助于设计者在设计过程中揭示底层细节

4.10 重构

• 含义
  • 不改变组件功能和行为条件下简化组件设计（或代码）的一种重组技术
• 方法
  • 检查现有设计的冗余情况、未使用的设计元素、无效或不必要的算法、较差的构建方式或不恰当的数据结构，或任何其他可更改并导致更好设计的错误

4.11 设计模型

• 使用者角度：软件≈功能组织+功能 设计者角度：软件≈数据设计+架构设计+接口设计+组件设计
• 模型输入
  • 软件需求的数据模型、功能模型和行为模式
• 分类
  • 数据设计
  • 架构设计
  • 接口设计
  • 组件级设计
• 分析模型转换为软件设计分析
• 数据设计（有时也被称为数据架构）构建高层抽象（客户/用户的数据视图）的数据模型、信息模型
• 相关概念
  • 数据建模
  • 数据结构
  • 数据库
  • 数据仓库

4.12 组件级别数据设计

• 设计原则
  • 功能和行为系统分析原则也适用于数据设计
  • 确定所有的数据结构即其对应的操作
  • 建立数据字典并在数据定义和程序设计中应用
  • 低层次的数据设计应该推迟到设计的后期过程
  • 数据结构的表示应该只对直接使用数据结构中数据的模块可见
  • 开发有用的数据结构及其对应操作的程序库
  • 软件设计和编程语言应该支持抽象数据类型的定义与实现

4.13 体系结构设计

• 含义及内容
  • 系统需要执行的函数功能组件集（如数据库、计算模块）
  • 组件之间通信、协同和合作的连接器
  • 组件集成构成系统的约束
  • 设计人员通过分析其组成部分的已知特性理解系统整体特性的语义模型分析
• 风格和模式简要分类
  • 数据中心架构
  • 数据流体系架构
  • 调用和返回架构
  • 面向对象架构
  • 层次架构

4.14 界面设计

• 高效用户界面设计有三条重要原则：

  • 用户控制系统 （用户为中心）
  • 减少用户记忆负担
  • 保持界面一致

• 环境分析确定了用户接口操作的物理结构和社会结构

4.15 组件设计

• 三种不同类型组件或模块
  • 控制模块
  • 问题域模块
  • 基础模块
• 面向对象的组件级设计
  • 以类设计为基础
  • 原则：开闭原则、依赖倒置原则
  • 概念：耦合、内聚
• 传统的组件级设计
• 结构化编程

4.16 面向对象设计

面向对象是一种思维

• 步骤
  • 识别对象(类)
  • 识别每一对象(类)的状态
  • 识别每一对象(类)的状态转换
  • 识别每一对象(类)的功能
• 面向对象的表达：UML
  • 类图：描述对象（类）及其关系
  • 状态图：描述对象（类）状态变化关系
  • 次序图：描述对象的函数调用关系
  • 包图：描述功能组命名空间的组织层次

4.17 部署设计

• 含义
  • 以部署环境创建开始，在整个生命周期阶段中处于逻辑设计和技术需求阶段
  • 包含整个解决方案的逻辑架构和服务质量（QoS）需求
• 影响因素
  • 逻辑体系结构
  • 服务质量要求
  • 使用情况分析
  • 用例
  • 服务水平协议
  • 总体拥有成本
  • 业务目标
• 方法
  • 一般方法
    • 估计处理器需求
    • 估计安全运输的处理器需求
    • 可用性和可扩展性的复制服务
  • 设计分析
    • 识别瓶颈
    • 优化资源
    • 管理风险

4.18 小结

• 设计是软件工程技术核心
• 数据结构、体系结构、接口和软件组件的过程细节在设计中逐步细化、开发、评审和记录
• 模块化（包括程序和数据）和抽象概念能够使设计人员简化和重用软件组件
• 细化提供了详细表示各顺序功能层的机制
• 程序和数据结构有助于建立软件架构的整体视图，而过程提供了算法实现必要的细节
• 信息隐藏和功能独立为实现有效模块化提供了启发

---

5 软件生产率和工作量度量

1. 了解软件生产率和项目工作量度量的含义
2. 掌握生产率度量和项目工作量度量的方法
3. 理解算法代价估计的原则

5.1 软件生产率和项目工作量的含义、方法

软件产品度量的定义：一种量化衡量方法，使得人们可以理解和把握软件项目的（生产）效（或者所需要的劳动量）

软件生产率测量方法：

• 直接测量：如在一个特定时间内产生的代码行数
• 间接测量：如一个给定时间内生产出的功能点和目标点

项目工作量的度量方法：

• 算法成本模型—基于经验的度量
• 通过任务分解度量
• 通过目前可用的资源

**5.2 基于功能点、代码行数的相关指标计算、优缺点

• 基于代码行数的度量方法

  • 优点

    • LOC、KLOC和相关度量容易计算
    • 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
    • 有大量的关于LOC的文献和数据

  • 缺点

    • LOC依赖于使用的语言，这对短小精悍的程序不利
    • 不太适用于非过程化语言
    • LOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得

• 基于功能点的度量方法

  代码行数和功能点之间的关系依赖于编程语言

---

7 软件测试技术

1. 理解软件测试的定义、常用术语、基本原则和代码审查。
2. 了解软件测试的目标、评估准则、软件静态分析的通用评审过程等及主要类型。
3. 掌握基本的白盒测试和黑盒测试方法。

7.1 软件测试的定义

在某种指定的条件下对系统或组件进行观察或记录结果，对系统或组件的某些方面进行评估的过程。

7.2 软件测试的常用术语

• 软件缺陷：至少满足下列一个条件才称发生了一个软件缺陷：
  • 未完成：软件未实现产品说明书要求的功能。
  2. 有错误：软件出现了产品说明书指明不能出现的错误。
  3. 画蛇添足：软件实现了产品说明书未提到的功能
  4. 隐含需求未实现：软件未实现产品说明书虽未明确提及但应该实现的目标。
  5. 不好用：软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。
• 测试与质量保证：
  • 软件测试人员的目标是尽早找出软件缺陷，并确保缺陷得以修复
  2. 软件质量保证人员的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法
  3. 人员职责上有交叉
• 质量与可靠性
  • 功能性（functionality）
  • 可靠性（reliability）
  • 可用性（usability）
  • 效率（efficiency）
  • 可维护性（maintainability）
  • 可移植性（portability）
• 软件调试与测试
  • 相同点：都包含有处理软件缺陷和查看代码的过程
  • 不同点：
    • 测试的目标是发现软件缺陷的存在**（看有没有缺陷）**
    • 调试的目标是定位与修复缺陷**（看缺陷在哪儿）**
• 测试用例（test case）：是测试输入、执行条件以及预期结果的集合，是为特定的目的开发的，例如执行特定的程序路径或验证与指定的需求相符合。

7.3 软件测试的目标

• 确认系统满足其预期的使用和用户的需要；

2. 确认解决了所需解决的问题（如实现商业规则和使用合适的系统假定）；
3. 为测试的过程建立责任和可解释性；
4. 便于及早发现软件和系统的异常；
5. 及早提供软件和系统的性能评估；
6. 为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险；
7. 鉴别出程序在功能等方面的异常集聚之处。

7.4 软件测试的基本原则

• 穷尽测试是不可能的：决定哪些更重要

2. 测试无法显示潜伏的软件缺陷：不能保证没有错误
3. 测试活动应尽早进行：越早发现修改成本越低
4. 软件缺陷具有群聚性：一个问题出错导致多个错误现象出现
5. 注意杀虫剂现象：用一样的测试用例是不可取的
6. 应尽量由独立的测试团队进行测试：自己测试自己是不可取的

7.5 软件测试的主要方法

1. 黑盒测试：黑盒测试指忽略系统或组件的内部机制，仅关注于那些特定输入响应及相应执行条件的输出测试，也称功能性测试
   • 检测目标：
     • 功能遗漏
     • 接口是否正确接受输入，能否返回正确输出
     • 数据结构错误或外部信息访问错误
     • 性能是否满足需求
     • 是否有初始化或终止错误
   • 局限性：用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。
2. 白盒测试：白盒测试指考虑系统或组件内部机制的测试（如分支测试、路径测试、语句测试等），也称结构性测试
   • 局限性：是穷举路径测试，贯穿程序独立路径数是天文数字，即使每条路径都经过了测试，仍可能有未发现错误。
3. 灰盒测试：黑盒和白盒测试混合方法

7.6 软件测试的评估准则

• 覆盖率

  覆盖率 = 测试集合T / 测试需求集合TR

• 故障插入

  • 在测试前被有意地插入一些故障到程序中
  • 发现率 = 发现的播入错误数 / 播入的总错误数

• 变异分值

  程序进行两个或更多个变异，然后用同样的测试用例执行测试，可以评估这些测试用例探测程序变异间差异的能力，如错误的标识符或运算符等

7.7 逻辑覆盖测试（白盒测试）

以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。

例题：

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

  

• 分支覆盖：选择足够多的测试数据，使被测程序中每个判断的取真分支和取假分支至少经历一次。也称判定覆盖。

  

• 条件覆盖：选择足够多的测试数据，使被测程序中每个判断的每个条件的可能取值至少执行一次。

  

• 条件组合覆盖：选择足够多的测试数据，使被测程序中每个判断的所有可能的条件取值组合至少执行一次。（同一个判断语句中的穷举）

  

7.8 控制流图覆盖测试（白盒测试）

控制流图覆盖测试是将代码转变为控制流图，基于其进行测试的技术。

• 节点覆盖：即对于图G 中每个语法上可达的节点，测试用例所执行的测试路径的集合中至少存在一条测试路径访问该节点。（与语句覆盖等价）

2. 边覆盖：即对于图G 中每一个可到达的长度小于等于1 的路径，测试用例所执行的测试路径的集合中至少存在一条测试路径游历该路径。(感觉和分支覆盖相同)
3. 路径覆盖测试就是设计足够的测试用例，覆盖程序中所有可能的路径。

7.9 基本路径测试（白盒测试）

• 基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。

• 它是在程序控制流图的基础上，

  1. 分析控制构造的环路复杂性，

     计算公式：V(G) = e − n + 2，n为节点数，e为图中边数

  2. 导出基本可执行路径集合，

  3. 设计测试用例的方法。

3. 设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次，且每个条件在执行时都将分别取真和假两种值。

7.10 等价类划分方法（黑盒测试）

把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例

步骤：

1. 对输入域进行建模
2. 对参数进行等价类划分
3. 对参数进行恰当的组合

两种划分：

• **有效等价类：**是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合
• **无效等价类：**是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合

实例：

7.11 边界值分析（黑盒测试）

简单来说，就是选边界值来测试（根据经验，这样往往能查出更多错误）

7.12 静态分析方法

不实际运行程序，通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术（非常有效，被用的越来越多）

主要内容：

• 检查需求
• 检查设计
• 检查代码

主要形式：

• 同事审查
• 走查
• 审查

---

8 软件测试策略

1. 理解单元测试、集成测试、系统测试和验收测试的基本概念及测试的主要内容
2. 了解：V 模型对测试过程的划分；测试各阶段的区别和用例设计思路；单元测试中桩函数和驱动函数；测试停止的度量方法；测试团队的组织
3. 掌握：测试各阶段的主要依据和目的；回归测试的概念和必要性；集成测试的主要集成方法；α测试和β测试的概念

8.1 软件测试策略

• 软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图，规定了测试的主要步骤。
• 测试策略必须和测试计划、测试用例设计、测试执行、还有测试结果数据的收集与分析结合在一起。
• 测试策略还应当具备足够的灵活性，这样在必要的时候它能够有足够的可塑性来应付所有的大软件系统。
• 测试策略还必须保证足够的严格，这样才能保证对项目的整个进程进行合理的计划和跟踪管理

8.2 软件测试的过程模型 - V模型

V 模型非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段应关系：

• 单元测试：验证软件模块是否按详细设计的规格说明正确运行
• 集成测试：检查多个模块间是否按概要设计说明的方式协同工作。
• 系统测试：验证整个系统是否满足需求规格说明。
• 验收测试：从用户的角度检查系统是否满足合同中定义的需求，以及确认产品是否能符合业务上的需求。

8.3 回归测试

指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求

引入原因：

• 在软件测试的各个阶段，在修正发现的软件缺陷或增加新功能时，变化的部分必须进行再测试
• 对软件修改可能引入新的软件缺陷以及其他问题

注意：

1. 回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中
2. 回归测试应该尽量采用自动化测试

范围：

• 缺陷再测试：重新运行所有发现故障的测试，而新的软件版本已经修正了这些故障。
• 功能改变的测试：测试所有修改或修正过的程序部分。
• 新功能测试：测试所有新集成的程序。
• 完全回归测试：测试整个系统。

标准：

• 只重复测试计划中的高优先级测试。
• 功能测试中，忽略特定的变化。
• 只针对特定配置进行测试。
• 只针对特定子系统或测试级别进行测试。

8.4 测试的基本步骤

单元测试、集成测试和系统测试的步骤：

• 计划与准备阶段
  • 制定计划
  • 编写与评审测试用例
  • 编写测试脚本和准备测试环境
• 执行阶段
  • 搭建环境、构造测试数据
  • 执行测试并记录问题
  • 和开发人员一起确认问题
  • 撰写测试报告
• 返工与回归测试阶段

8.5 测试的类型

• 单元测试

  又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

  进入条件：

  • 被测代码编译链接通过
  • 被测代码静态检查工具检查通过
  • 已完成至少一轮代码检视或走读
  • 单元测试用例的检视通过
  • 单元测试代码写完并通过检测

  退出条件：

  • 所用测试用例执行通过
  • 单元测试覆盖率达到预定要求
  • 单元测试未被执行的代码进行正式审查

  主要内容：

  1. 模块接口

  2. 局部数据结构

  3. 边界条件

     选择适当的测试用例，对模块中重要的执行路径进行测试。

  4. 独立路径

  5. 出错处理

• 集成测试

  主要方法：

  • 自顶向下的集成方法

    按系统程序结构，沿控制层次自顶向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。
    **优点：**选用按深度方向集成的方式，可以首先实现和验证一个完整的软件功能。
    **缺点：**桩的开发量较大

  • 自底向上的集成方法

    自底向上集成方法是从软件结构最底层的模块开始，按照接口依赖关系逐层向上集成以进行测试。

    **优点：**每个模块调用其他底层模块都已经测试，不需要桩模块

    **缺点：**每个模块都必须编写驱动模块；缺陷的隔离和定位不如自顶向下

  • SMOKE方法

    将已经转换为代码的软件构件集成为构造（build）。一个构造包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。

    这种集成方法可以是自顶向下，也可以自底向上。

• 系统测试（基本都采用黑盒测试）

  从用户使用的角度来进行的测试，主要工作是将完成了集成测试的系统放在真实的运行环境下进行测试，用于功能确认和验证。

  主要依据：需求规格说明

  主要内容：

  • **功能测试：**功能测试是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误
  • 性能测试
    • 性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。
    2. 性能测试常常需要与强度测试结合起来进行，并常常要求同时进行硬件和软件检测。
    3. 软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区
  • 强度测试：强度测试是要检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。(是不是就是压力测试= =)
  • 压力测试
  • **恢复测试：**恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后，系统能否正常地继续进行工作，并不对系统造成任何损害。(掉电测试也应该属于这一块，还有什么启停测试，个人感觉都一样)
  • **安全测试：**安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
  • 其他的系统测试还包括配置测试、兼容性测试、本地化测试、文档测试、易用性测试等

• 验收测试

  主要形式：

  • 根据合同进行的验收测试
  • 用户验收测试
  • 现场测试

  α测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

  • 目的：α测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。

  β测试：是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。（传说中的beta版么= =）

  **注意：**只有当α测试达到一定的可靠程度时，才能开始β测试。

8.6 软件测试的组织

• 测试团队的组建（5种模式）
• 各测试阶段中采用的模式
• 测试中的人员及其承担的任务
  • 测试经理
  • 测试设计人员
  • 测试自动化人员
  • 测试管理员
  • 测试人员

---

9 软件维护