软件工程期末复习汇总（非常详细）

期末复习

第1章 概论

软件的定义 软件=程序+数据+文档
软件危机的定义：在计算机软件开发和维护过程中所遇到的一系列严重问题 特点：周期长、成本高、质量差、维护难
软件生存周期：计算机系统工程、需求分析、设计、编码、测试、运行、维护

软件过程模型

瀑布模型

​

特征

• 接受上一阶段的结果作为本阶段的输入。
• 利用这一输入实施本阶段应完成的活动。
• 对本阶段的工作进行评审。
• 将本阶段的结果作为输出，传递给下一阶段

缺点

• 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发。
• 开发早期存在的问题往往要到交付使用时才发现，维护代价大

演化模型

可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓**原型**
演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程

增量模型

每个线性序列产生软件的一个可发布的增量版本，后一个版本是对前一版本的修改和补充

增量模型融合了瀑布模型的基本成分和演化模型的迭代特征。

增量模型特别适用于：

• 需求经常变化的软件开发。
• 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发。

增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术。

原型模型

原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型。

被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。

• 探索型
• 实验型
• 演化型

螺旋模型

是瀑布模型和演化模型的结合，并增加了风险分析

四个象限:

• 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。

• 风险分析：评价所选的方案，识别风险，消除风险。

• 工程实施：实施软件开发，验证工作产品。

• 客户评估：评价开发工作，提出修正建议。

  

  螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。

喷泉模型

喷泉模型是一种支持面向对象开发的模型。

体现迭代和无间隙特征。

• 迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中，不断加入演进的内容。
• 无间隙：开发活动之间不存在明显的边界。

基于构件的开发模型

利用预先包装好的软件构件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统。

形式方法模型

形式化方法（formal methods）是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法

第2章 系统工程

所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合。

组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程

可行性分析

开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。

经济可行性

• 成本
  • 购置硬件、软件（如数据库管理系统、第三方开发的构件等）和设备（如传感器等）的费用。
  • 系统的开发费用。
  • 系统安装、运行和维护费用。
  • 人员培训费用。
• 效益
  • 经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用（如操作人员数、工作时间、消耗的物资等）。在进行成本效益分析时通常只统计五年内的经济效益。
  • 社会效益指使用基于计算机的系统后对社会产生的影响（如提高办事效益，提高用户满意度等），通常社会效益只能定性地估计。
• 货币的时间价值
• 投资回收期
• 纯收入

技术可行性

• 风险分析：分析在给定的约束条件下设计和实现系统的风险。风险分析的目的是找出风险，评价风险的大小，并有效地控制和缓解风险。
• 资源分析：论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境。
• 技术分析：分析当前的科学技术是否支持系统开发的各项活动。

法律可行性

研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题

第3章 需求工程

本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。

需求获取

软件需求包括

• 功能需求
• 性能需求
• 用户或人的需求
• 环境需求
• 界面需求
• 文档需求
• 数据需求
• 资源使用需求
• 安全保密要求
• 可靠性需求
• 软件成本消耗与开发进度需求
• 其他非功能性要求

获取需求的方法与策略

• 建立顺畅的通信途径

  、

• 访谈与调查

• 观察用户操作流程

• 组成联合小组

• 用况（Use Case）

  是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用况提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

  • 确定谁会直接使用该系统，即执行者（Actor） 。
  • 选取其中一个执行者 。
  • 定义该执行者希望系统做什么，参与者希望系统作的每件事将成为一个用况¹。
  • 对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程 。
  • 描述该用况的基本过程。
  

需求分析、协商与建模

需求规约与验证

需求管理

第4章 设计工程

软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题

软件设计的任务

• 数据/类设计
• 体系结构设计
• 接口设计
• 部件级设计

软件设计原则

抽象与逐步求精

模块化

信息隐藏

功能独立

高内聚低耦合

内聚：

​

耦合：

​

软件体系结构设计

软件体系结构的风格

• 数据为中心的体系结构
• 数据流风格的体系结构
• 调用和返回风格的体系结构
• 面向对象风格的体系结构
• 层次式风格的体系结构

部件级设计技术

结构化程序设计方法

图形表示法

程序流程图

​

N-S图

​

PAD

第5章 结构化分析与设计

实体-关系图

状态转换图

数据流图

数据流图（重点！）

Data Flow Diagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工)过程，用于对系统的功能建模，基本元素包括：

数据流图的图形表示

源与宿

存在于软件系统之外的人员或组织，表示软件系统输入数据的来源和输出数据的去向，因此也称为源点和终点。

• 例如，对一个考务处理系统而言：
  考生向系统提供报名单(输入数据流)，所以考生是考试系统(软件)的一个源。
  考务处理系统要将考试成绩的统计分析表(输出数据流)传递给考试中心，所以考试中心是该系统的一个宿。

• 源或宿用相同的图形符号表示：
  当数据流从该符号流出时表示是源。
  当数据流流向该符号时表示是宿。
  当两者皆有时表示既是源又是宿。

加工与文件

• 加工：描述输入数据流到输出数据流的变换：
  每个加工用一个定义明确的名字标识。
  至少有一个输入数据流和一个输出流。
  可以有多个输入数据流和多个输出数据流。

• 文件：保存数据信息的外部单元。
  每个文件用一个定义明确的名字标识。
  由加工进行读写。
  DFD中称为文件，在具体实现时可以用文件系统实现，也可以用数据库系统实现。

数据流

• 每个数据流用由一组固定成分的数据组成,并拥有一个定义明确的名字标识。
  如：运动会管理系统中，报名单(数据流)由队名、姓名、性别、参赛项目等数据组成。

• 数据流的流向：
  从一个加工流向另一个加工。
  从加工流向文件(写文件)。
  从文件流向加工(读文件)。
  从源流向加工。
  从加工流向宿。

数据流图的扩充符号

描述一个加工的多个数据流之间的关系：

• 星号(＊)：表示数据流之间存在“与”关系。
  所有输入数据流同时存在时，才能进行加工处理。
  或者加工处理的结果是同时产生所有输出数据流。

• 加号(＋)：表示数据流之间存在“或”关系。
  至少存在一个输入数据流时，才能进行加工处理。
  或者加工处理的结果至少产生一个输出数据流。

• 异或(⊕)：表示数据流之间存在“异或”(互斥)关系。
  必须存在且仅存在一个输入数据流时，才能进行加工处理。
  或者加工处理的结果产生且仅产生一个输出数据流。

数据流图的层次结构

根据自顶向下逐层分解的思想将数据流图画成层次结构。
每个层次画在独立的数据流图中，加工个数可大致控制在“7加减2”的范围中。

数据流图的层次结构

• 顶层图只有代表整个软件系统的1个加工，描述了软件系统与外界(源或宿)之间的数据流。P73图5.5
• 顶层图中的加工经分解后的图称为0层图(只有1张)。P75图5.8
• 中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图。
• 处于最底层的图称为底层图，其中所有的加工不再分解成新的子图。

图和加工的编号

• 顶层图只有一个代表整个软件系统的加工，该加工不必编号。
• 0层图中的加工编号分别为1，2，3，…。
• 子图号：若父图中的加工号x分解成某一子图，则该子图号记为“图x”。
• 子图中加工的编号：若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为x.1、x.2、x.3…。P76图5.9和图5.10

分层数据流图的画法

示例——资格和水平考试的考务处理系统

• 简化的资格和水平考试的考务处理系统。
• 分成多个级别，如初级程序员、程序员、高级程序员、系统分析员等，凡满足一定条件的考生都可参加某一级别的考试。
• 考试的合格标准将根据每年的考试成绩由考试中心确定。
• 考试的阅卷由阅卷站进行，因此，阅卷工作不包含在软件系统中。

功能需求

1. 对考生送来的报名单进行检查。
2. 对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站。
3. 对阅卷站送来的成绩清单进行检查，并根据考试中心制订的合格标准审定合格者。
4. 制作考生通知单送给考生。
5. 进行成绩分类统计(按地区、年龄、文化程度、职业、考试级别等分类)和试题难度分析，产生统计分析表。

部分数据流的组成

• 报名单＝地区＋序号＋姓名＋文化程度＋职业＋考试级别＋通信地址。
• 正式报名单＝准考证号＋报名单。
• 准考证＝地区＋序号＋姓名＋准考证号＋考试级别＋考场。
• 考生名单＝｛准考证号＋考试级别｝。
• 考生名册＝正式报名单。
• 统计分析表＝分类统计表＋难度分析表。
• 考生通知单＝准考证号＋姓名＋通信地址＋考试级别＋考试成绩＋合格标志。

1. 画出系统的输入与输出

1. 确定源或宿：考生、阅卷站和考试中心。

   • 它们都既是源又是宿

2. 顶层图唯一的加工：软件系统(考务处理系统)。

3. 确定数据流：系统的输入/输出信息：

   • 输入数据流²：报名单(来自考生)、成绩清单(来自阅卷站)、合格标准(来自考试中心)。

   • 输出数据流：准考证(送往考生)、考生名单(送往阅卷站)、考生通知书(送往考生)、统计分析表(送往考试中心)。

   • 额外的输出流(考虑系统的健壮性)³：不合格报名单(返回给考生)，错误成绩清单(返回给阅卷站)。

4. 顶层图通常没有文件。

   

2. 画出系统内部

1. 确定加工：确定父图中某加工分解而成的子加工。

   • 根据功能分解来确定加工：将一个复杂的功能分解成若干个较小的功能，较多应用于高层DFD中的分解。

   • 根据业务处理流程确定加工：分析父图中待分解加工的业务处理流程，业务流程中的每一步都可能是一个子加工。

   • 特别要注意在业务流程中**数据流发生变化或数据流的值发生变化的地方**，应该存在一个加工，例如：

     

2. 确定数据流

   • 在父图中某加工分解而成的子图中，父图中相应加工的输入/输出数据流都是且仅是子图边界上的输入/输出数据流。

   • 分解后的子加工之间应增添相应的新数据流表示加工过程中的中间数据。如：图5.8中考试报名与统计成绩间。

   • 如果某些中间数据需要保存以备后用，那么可以成为流向文件的数据流。如：图5.8中“考生名册”。

   • 同一个源或加工可以有多个数据流流向一个加工，如果它们不是一起到达和一起加工的，那么可以将它们分成若干个数据流，例如：

     

3. 确定文件

   • 如果父图中该加工存在读写文件的数据流，则相应的文件和数据流都应画在子图中。如：图5.8中“考生名册”。
   • 在分解子图中，如果需要保存某些中间数据以备后用，则可以将这些数据组成一个新的文件。如：图5.8中“考生名册”。
   • 新文件(首次出现的文件)至少应有一个加工为其写入记录，同时至少存在另一个加工来读该文件的记录。
   • 注意：从父图中继承下来的文件在子图中可能只对其进行读，或只进行写。

4. 确定源和宿

   • 0层图和其它子图中通常不必画出源和宿。参考图5.8，5.9

   • 有时为了提高可读性，可以将顶层图中的源和宿画在0层图中。

     

     注意：这里的加工进行功能的分类，之后又要继承顶层图中的输入和输出流，最后定义分出来的加工之间的数据流或者文件

3. 画出加工内部

• 复杂的加工可以继续分解成1张DFD子图。
• 分解方法：
  • 将该加工看作一个小系统，该加工的输入/输出数据流就是这个假设的小系统的输入/输出数据流。
  • 然后采用画0层图的方法，画出该加工的子图。

​

​

总结：画分层数据流图的步骤

1. 画系统的输入和输出。

2. 画系统内部。

3. 画加工内部。

4. 重复第3步，直至每个尚未分解的加工都足够简单(即不必再分解)。

个人画法总结

1. 识别源宿、数据流、系统进而画出顶层图
2. 系统（加工）分解成不同的加工、继承顶层图的数据流、源与宿不用画出来、文件可以画出，画出0层图
3. 加工细分小加工，继承父图的数据流，画出子图
4. 注意命名规范、源宿为了便于展示观看可以画出相同的多个

示例1 考务处理系统

示例2 课程评价系统

示例3 销售管理系统

数据字典

数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型(分析模型)。
数据字典由字典条目组成，每个条目描述DFD中的一个元素。
数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、源或宿。
加工逻辑的详细说明可以用“小说明”来描述。

数据流条目的描述内容

• 名称：数据流名(可以是中文名或英文名)。
• 别名：名称的另一个名字。
• 简述：对数据流的简单说明。
• 数据流组成：描述数据流由哪些数据项组成。
• 数据流来源：描述数据流从哪个加工或源流出。
• 数据流去向：描述数据流流入哪个加工或宿。
• 数据量：系统中该数据流的总量。
• 如考务处理系统中“报名单”的总量是100000张。
• 或者单位时间处理的数据流数量，如80000张/天。
• 峰值：某时段处理的最大数量。
• 如每天上午9：00至11：00处理60000张表单。
• 注解：对该数据流的其它补充说明。

• 数据流组成是数据流条目的核心，它列出组成该数据流的各数据项，例如：
  培训报名单＝姓名＋单位＋课程
  运动员报名单＝队名＋姓名＋性别＋｛参赛项目｝
• 当一个数据流的组成比较复杂时，可以将其分解成几个数据流，例如：
  课程＝课程名＋任课教师＋教材＋时间地点
  时间地点＝｛星期几＋第几节＋教室｝

示例

数据字典

注册请求=用户名+密码

注册结果=[注册成功|用户名已被使用|密码长度不足]

登录结果=[登录成功|用户不存在|密码错误]

登录信息=用户名+密码

报名课程 = 用户id号+课程id号

修改个人信息 = 用户id号+个人信息的各个字段

查询课程信息 = 课程名称

查询课程信息结果 = 课程的相关信息

课程增删信息 = 课程名称 + [增加课程信息|删除课程信息|修改课程信息]

增删课程 = 课程名称 + 管理员id号

课程评价 = 课程名称 + 用户名称 + 用户评价信息

加工小说明

• ‏加工编号：1‎

加工名：处理登录请求

输入流：登录信息

输出流：登录结果

加工逻辑：根据输入的登录信息，访问用户信息文件，与存储的用户信息进行比对，然后返回登录是否成功。

• ‏加工编号：2

加工名：处理注册请求

输入流：注册请求

输出流：注册结果

加工逻辑：根据输入的注册信息，访问用户信息文件，与存储的用户信息进行比对，然后返回注册是否成功。

第7章 面向对象方法基础

面向对象的基本概念

面向对象 = 对象(object) + 分类(classification) + 继承(inheritance) + 通过消息的通信(communication with messages)

面向对象的分析和设计过程

面向对象分析的一般步骤如下：

• 获取客户对系统的需求（用况建模）：包括标识场景（scenario）和用况（use case，也称用例），以及建造需求模型。

  • 分析出执行者

• 用基本的需求为指南，来选择类和对象（静态建模）（包括属性和操作）。

• 定义类的结构和层次。

  • 类的结构主要有两种：1、一般-特殊结构 2、整体-部分结构

    

• 建造对象—关系模型。

  ​

• 建造对象—行为模型（动态建模）。

• 利用用况/场景来复审分析模型。

UML概述

基本概念：

1. 每个视图(View)是整个系统描述的一个投影，说明了系统的一个特殊侧面。
2. 若干个不同的视图就可以完整描述所建造的系统。
3. 视图是由若干幅图(Diagram)组成的一种抽象。
4. 一幅图包含了系统某个特殊方面的信息，阐明了系统的一个特定部分或方面。
5. 一幅图由若干个模型元素组成，模型元素表示图中的概念，如：类、对象、用况、节点、接口、包、注释、构件等。
6. 用于表示模型元素之间相互连接的关系也是模型元素，如：关联、泛化、依赖、实现等。

第8章 面向对象建模

用况建模

创建用况模型的步骤包括：

• 1．定义系统
  • 用况图中的**矩形框代表系统**
• 2．确定执行者
  • 执行者是指与系统交互的人或其他系统。
    执行者代表一种角色，而不是具体的某个人 。
    执行者可分成主执行者和副执行者
• 3．确定用况
  • 用况总是被执行者启动的（initiated），用况是一个类型，而不是实例，用况的实例称为场景（scenario）
• 4．描述用况
• 5．定义用况间的关系
  • 
  • 
• 6．确认模型

示例1

示例2

1. 识别执行者

• 学生
• 管理员

2. 识别用况

• 学生
  • 注册
  • 登录
  • 更新个人信息
  • 课程信息查询
  • 选课
  • 课程评价
• 管理员
  • 注册
  • 登录
  • 修改课程信息
  • 增删课程
  • 课程信息查询

3. 需求描述：

‍

‍

4. 针对登录用况给出执行规约如下：

用况名	登录
用况描述	学生（管理员)输入用户名（邮箱）和密码进行登录 系统返回登录的结果
执行者	学生或者管理员
基本路径 （用户行为左 对齐，系统动作 向右缩进）	提交登录请求 展示登录界面 填写登录的信息(邮箱，密码等); if 信息不符合填写的基本要求 then 要求用户重新输入; else 等待用户确认登录; end if; 确认登录; 获取用户名、密码; 根据用户名查询数据库; if 无法查到用户名 then 返回用户不存在; else 比较查到的密码与输入是否相符; if 密码相符 then 返回登录成功; else 返回密码错误; end if end if; 接收反馈信息，查看是否登录成功

示例3

静态建模

类图和对象图

类和对象模型的基本模型元素有类、对象以及它们之间的关系。系统中的类和对象模型描述了系统的静态结构，在UML中用类图和对象图来表示。

类图由系统中使用的类以及它们之间的关系组成。类之间的关系有关联、依赖、泛化、实现等。类图是一种静态模型，它是其他图的基础。一个系统可以有多张类图，一个类也可出现在几张类图中。

对象图是类图的一个实例，它描述某一时刻类图中类的特定实例以及这些实例之间的特定链接。对象图使用了与类图相同的符号，只是在对象名下附加下划线，对象名后可接以冒号和类名，即：

object-name:class-name

类之间的关系

关联

聚类、组合

泛化

实现

依赖

静态建模步骤

标识候选对象

筛选候选对象

删除外部执行者，没有出现在用况图中，没有属性的对象

标识属性和操作

确定类之间的关系

示例1

示例2

动态建模

UML中用状态机图、活动图、顺序图、通信图和协作图来建立动态模型

状态机图

状态机图通常是对类描述的补充，它说明该类的对象所有可能的状态，以及哪些事件将导致状态的改变。状态机图描述了对象的动态行为，是一种对象生存周期的模型。

画状态机图的步骤

1）列出对象具有的所有状态。

状态分为起始状态、结束状态和中间状态。一张状态机图可以有一个起始状态和若干个（可以为0）结束状态。

2）标识导致状态转换的事件。

当一个对象接收到某个事件时，会导致从一个状态转换到另一个状态，称为状态迁移（transition）。

3）为状态和迁移定义状态变量和动作。

在状态迁移和/或处于某个状态中时，都可能需要执行一些相应的动作，综合这些动作，使得对象完成相应的功能。

状态：

一个状态由状态名、状态变量和活动三部分组成。
状态变量是状态机图所显示的类的属性，也可以是临时变量。
活动部分列出了处于该状态时要执行的事件和动作。

有三个标准事件：entry，exit和do

Entry和exit事件用于指明进入和退出该状态时的特定动作。

do事件用于指明处于该状态中时执行的动作。

状态迁移：

1. 标在迁移箭头上的事件出现（被动触发，根据接收的事件进行触发）
2. 未指明事件（该状态的事件执行完之后自动触发）

示例1

示例2

示例3

活动图

• 活动图可看作一种特殊形式的状态机，用于对计算流程和工作流建模。活动图的状态表示计算过程中所处的各种状态。
• 活动图用来描述完成一个操作所需要的活动，或者是一个用况实例（场景）的活动。
• 活动图使用状态机图的符号表示，活动图中的状态称为动作状态，用圆角矩形表示，动作状态之间的迁移用箭头表示，迁移上可以附加警戒条件、发送子句和动作表达式。
• 与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发。

1. 一张活动图可划分成若干个矩形区，每个矩形区为一个泳道，泳道名放在矩形区的顶端。通常根据责任把活动组织到不同的泳道中，它能清楚地表明动作在哪里执行（在哪个对象中），或者表明一个组织的哪部分工作（一个动作）被执行。
2. 一个动作迁移可以分解成二个或多个导致并行动作的迁移，若干个来自并行活动的迁移也可以合并成一个迁移。值得注意的是，在合并之前并行迁移上的活动必须全部完成。在活动图中用黑体线来表示迁移的分解和合并。
3. 活动图中可以表示对象，对象用对象符号（矩形）表示，它可作为活动的输入或输出（用虚线箭头连接），也可展示一个对象受一特定动作的影响（用动作和对象之间的虚线表示）。

示例1

示例2

顺序图

示例1

第12章 程序设计语言和编码

程序设计风格

编程风格主要包括：

• 源程序中的内部文档
  • 标识符的命名
  • 注解
  • 程序的视觉组织
• 数据说明
  • 数据说明的次序应当规范化
  • 说明语句中变量安排有序化
  • 使用注解说明复杂数据结构
• 语句构造
• 输入／输出

第13章 软件测试

软件测试基础

软件测试的目的

• 测试是一个为了发现错误而执行程序的过程。
• 一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试用例。
• 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

软件测试的基本原则

1. 所有的测试都应可追溯到客户需求。
2. 应该在测试工作真正开始前的较长时间就进行测试计划。
3. Pareto原则：测试中发现的80%的错误可能来自于20%的程序代码。
4. 测试应从“小规模”开始，逐步转向“大规模”。
5. 穷举测试是不可能的。
6. 为了达到最有效的测试，应由独立的第三方来承担测试。
7. 其他原则

白盒测试和黑盒测试

• 测试用例的设计是软件测试的关键所在。
• 设计尽可能少的测试用例来发现尽可能多的错误。
• 设计最有可能发现软件错误的测试用例，同时避免使用发现错误效果相同的测试用例。
• 测试用例的设计方法大体可分为两类：白盒测试和黑盒测试，也称白箱测试和黑箱测试。

白盒测试

• 白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。
• 白盒测试主要用于对模块的测试，包括：
  • 程序模块中的所有独立路径至少执行一次。
  • 对所有逻辑判定的取值（“真”与“假”）都至少测试一次。
  • 在上下边界及可操作范围内运行所有循环。
  • 测试内部数据结构的有效性等。

逻辑覆盖测试

• 语句覆盖
• 判定覆盖
• 条件覆盖
• 判定/条件覆盖
• 条件组合覆盖
• 路径覆盖

示例1

示例2

示例3

黑盒测试

等价类划分

示例1

示例2

测试策略

一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试。
单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。
集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。
确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。
对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误。

V模型

描述软件开发各阶段与测试策略之间的对应关系

单元测试

• 单元测试又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行测试。
• 单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误。
• 单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试。
• 这里将构件或模块统一称为模块。

单元测试的内容：

• 模块接口
• 局部数据结构
• 边界条件
• 所有独立路径
• 所有错误处理路径

集成测试

集成测试 也称组装测试、联合测试

第15章软件维护与再工程

1. 什么是软件维护？
   是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。
2. 软件维护分类
   • 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护
   • 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程。
   • 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护。
   • 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动。

---

1. 即每一个针对执行者的功能都是一个用例（用况）如登录 ↩︎

2. 相对于我们开发的系统而言，这里是指“考务处理系统” ↩︎

3. 考虑到了出错的问题 ↩︎