目录
[3.1 软件过程模型](#3.1 软件过程模型)
[3.2 瀑布模型](#3.2 瀑布模型)
[3.3 原型模型](#3.3 原型模型)
[3.4 原型及相关模型](#3.4 原型及相关模型)
[3.5 V模型](#3.5 V模型)
[3.6 迭代与增量](#3.6 迭代与增量)
[3.7 螺旋模型](#3.7 螺旋模型)
[3.8 构件组装模型](#3.8 构件组装模型)
[3.9 基于构件的软件工程(CBSE)](#3.9 基于构件的软件工程(CBSE))
[3.10 快速应用开发模型(RAD)](#3.10 快速应用开发模型(RAD))
[3.11 统一过程（UP、RUP）](#3.11 统一过程（UP、RUP）)
[3.12 敏捷方法（XP、SCRUM）](#3.12 敏捷方法（XP、SCRUM）)
[3.13 软件重用和逆向工程](#3.13 软件重用和逆向工程)
[3.14 净室软件工程（CSE，Cleanroom Software Engineering）](#3.14 净室软件工程（CSE，Cleanroom Software Engineering）)
[3.15 需求工程-概述](#3.15 需求工程-概述)
[3.16 需求工程-需求获取](#3.16 需求工程-需求获取)
[3.17 结构化需求分析（SA）](#3.17 结构化需求分析（SA）)
[3.17.1 需求工程 -需求开发-需求分析- SA](#3.17.1 需求工程 -需求开发-需求分析- SA)
[3.17.2 需求工程-需求开发-需求分析-OOA](#3.17.2 需求工程-需求开发-需求分析-OOA)
[3.17.3 需求开发-需求分析-OOA-UML-4+1视图](#3.17.3 需求开发-需求分析-OOA-UML-4+1视图)
[3.17.4 需求工程-需求开发-需求定义](#3.17.4 需求工程-需求开发-需求定义)
[3.17.5 需求工程-需求开发-需求验证](#3.17.5 需求工程-需求开发-需求验证)
[3.17.6 需求跟踪](#3.17.6 需求跟踪)
[3.17.7 需求变更管理过程](#3.17.7 需求变更管理过程)
[3.18 软件系统建模(Software System Modeling)](#3.18 软件系统建模(Software System Modeling))
[3.19 人机界面设计(黄金三法则)](#3.19 人机界面设计(黄金三法则))
[3.20 结构化设计（SD）](#3.20 结构化设计（SD）)
[3.20.1 结构化设计(内聚)](#3.20.1 结构化设计(内聚))
[3.20.2 结构化设计(耦合)](#3.20.2 结构化设计(耦合))
[3.20.3 结构化设计(模块四要素)](#3.20.3 结构化设计(模块四要素))
[3.21 面向对象设计](#3.21 面向对象设计)
[3.21.1 面向对象设计(基本过程)](#3.21.1 面向对象设计(基本过程))
[3.21.2 面向对象设计(类的分类)](#3.21.2 面向对象设计(类的分类))
[3.21.3 系统设计-面向对象设计-设计原则](#3.21.3 系统设计-面向对象设计-设计原则)
[3.22 软件测试类型](#3.22 软件测试类型)
[3.22.1 白盒测试、黑盒测试、自动化测试](#3.22.1 白盒测试、黑盒测试、自动化测试)
[3.23 软件测试阶段](#3.23 软件测试阶段)
[3.24 集成测试策略](#3.24 集成测试策略)
[3.25 软件系统测试](#3.25 软件系统测试)
[3.26 系统转换计划](#3.26 系统转换计划)
[3.26.1 系统转换计划-遗留系统演化策略](#3.26.1 系统转换计划-遗留系统演化策略)
[3.26.2 系统转换计划-新旧系统的转换策略](#3.26.2 系统转换计划-新旧系统的转换策略)
[3.27 软件维护](#3.27 软件维护)
[3.27.1 软件维护-影响可维护性的因素](#3.27.1 软件维护-影响可维护性的因素)
[3.27.2 软件维护类型](#3.27.2 软件维护类型)
3.1 软件过程模型
软件过程模型的基本概念：软件过程是制作软件产品的一组活动以及结果，这些活动主要由软件人员来完成，软件活动主要有：
（1）软件描述。必须定义软件功能以及使用的限制。
（2）软件开发。也就是软件的设计和实现，软件工程人员制作出能满足描述的软件。
（3）软件有效性验证。软件必须经过严格的验证，以保证能够满足客户的需求。
（4）软件进化。软件随着客户需求的变化不断地改进。
瀑布模型
V模型【瀑布变种】
原型模型
螺旋模型【原型+瀑布】
构件组装模型/基于构件的开发方法
快速应用开发RAD【瀑布+构件组装】
统一过程/统一开发方法
敏捷开发方法
3.2 瀑布模型
【特点】
ü 严格区分阶段，每个阶段因果关系紧密相连
ü 只适合需求明确的项目
【缺点】
ü 软件需求完整性、正确性难确定
ü 严格串行化，很长时间才能看到结果
ü 瀑布模型要求每个阶段一次性完全解决该阶段工作，这不现实。
3.3 原型模型
适合需求不明确的项目
原型模型两个阶段：
1、原型开发阶段
2、目标软件开发阶段
原型模型分为【抛弃型原型】与【演化型原型】
3.4 原型及相关模型
水平原型主要用于界面
垂直原型主要用于复杂的算法实现上，
抛弃式原型主要用于界面设计
演化式原型主要用在必须易于升级和优化的场合，适合于web项目。
3.5 V 模型
测试贯穿于始终
测试分阶段，测试计划提前
3.6 迭代与增量
3.7 螺旋模型
以快速原型为基础+瀑布模型
考虑了风险问题
3.8 构件组装模型
构件组装 是将库中的构件经适当修改后相互连接，或者将它们与当前开发项目中的软件元素相连接，最终构成新的目标软件。构件组装技术大致可分为基于功能的组装技术、基于数据的组装技术和面向对象的组装技术。
（1）基于功能的组装技术
基于功能的组装技术采用子程序调用和参数传递的方式将构件组装起来。它要求库中的构件以子程序/过程/函数的形式出现，并且接口说明必须清晰。当使用这种组装技术进行软件开发时，开发人员首先要对新系统进行功能分解，将系统分解为强内聚、松耦合的功能模块；然后根据各模块的功能需求提取构件，进行适应性修改后，再挂接到上述功能分解框架中。
(2）基于数据的组装技术
基于数据的组装技术首先根据当前软件问题的核心数据结构设计出一个框架，然后根据框架中各结点的需求提取构件并进行适应性修改，再将构件逐个分配至框架中的适当位置。此后，构件的组装方式仍然是传统的子程序调用与参数传递。这种组装技术也要求库中构件以子程序形式出现，但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法。
（3）面向对象的组装技术
由于封装和继承特征，面向对象方法比其他软件开发方法更适合支持软件复用。在面向对象的软件开发方法中，如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。
【优点】易扩展、易重用、降低成本、安排任务更灵活
【缺点】构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其它指标(如性能)、第三方构件质量难控制。
【示例】
方舱医院
乐高积木
目前主流的构件模型是Web Services模型、Sun公司的EJB模型、微软的.NET模型。
3.9 基于构件的软件工程(CBSE)
CBSE体现了【购买而不是重新构造】的哲学。
CBSE的构件应该具备的特征
1、++可组装性++：所有外部交互必须通过公开定义的接口进行。
2、++可部署性++：构件总是二进制形式的，能作为一个独立实体在平台上运行
3、++文档化++：用户根据文档来判断构件是否满足需求。
4、++独立性++：可以在无其他特殊构件的情况下进行组装和部署。++如确实需要其他构件提供服务，则应显示声明。++
5、++标准化++：符合某种标准化的构件模型
【构件的组装】
1、++顺序组装++：按顺序调用己经存在的构件，可以用两个已经存在的构件来创造一个新的构件。
2、++层次组装++ ：被调用构件的"提供"接口必须和调用构件的"请求"接口兼容。
3、++叠加组装++ ：多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的接口。
构件的组装可能面临接口不兼容问题，常见的有**++参数不兼容、操作不兼容、操作不完备++**3种。
基于构作的软件开发 (Component-Based Software Development， CBSD)
**面向构件的编程(Component Oriented Programming, COP)**关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的COP定义如下(Szyperski:1995)：面向构件的编程需要下列基本的支持
--多态性(可替代性);
--模块封装性(高层次信息的隐藏);
--后期的绑定和装载(部署独立性);
--安全性(类型和模块安全性)。
基于构件的软件开发中，已有的构建分类方法可以归纳为三大类：
（1）++关键字分类法++。根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构。
（2）++刻面分类法++。利用Facet(刻面）描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。
（3）++超文本方法++。基于全文检索技术，使得检索者在阅读文档过程中可以按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。
3.10 快速应用开发模型(RAD)
快速应用开发模型（RAD，Rapid Application Development）
3.11 统一过程（UP、RUP）
统一过程（Rational Unified Process，RUP）是 Rational 公司（现 IBM）在 1990 年代提出的软件过程框架，后来也泛称"统一过程（Unified Process，UP）"。它把项目生命周期组织成"二维流程网 "------时间轴 （阶段 & 迭代）+工作轴（角色-活动-工件），以用例驱动、架构为中心、风险驱动、迭代增量**为四大基石，适用于中大型、需求易变、技术风险高的系统。
统一过程RUP Rational Unified Process RUP将项目管理、业务建模、分析与设计等统一起来，贯穿整个开发过程。
RUP中的软件过程在时间上分解为4个顺序阶段，分别是初始阶段、细化阶段、构建阶段和移交阶段。每个阶段安排一次技术评审，以确定这个阶段的目标是否已经满足，如果评审结果令人满意，就可以运行项目进入下一个阶段。
RUP的9个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与管
理、项目管理、环境。
RUP的4个阶段：初始、细化、构造、移交。
|--------|----------------|------------------|-------------------|-----------------|
| 工作流＼阶段 | 初始 (Inception) | 细化 (Elaboration) | 构造 (Construction) | 移交 (Transition) |
| 业务建模 | √ | √ | --- | --- |
| 需求 | √ | √ | √ | √ |
| 分析设计 | --- | √ | √ | --- |
| 实现 | --- | √ | √ | √ |
| 测试 | --- | √ | √ | √ |
| 部署 | --- | --- | √ | √ |
| 配置管理 | √ | √ | √ | √ |
| 项目管理 | √ | √ | √ | √ |
| 环境 | √ | √ | √ | √ |
3.12 敏捷方法（XP、SCRUM）
++项目团队的人数不能太多，适合于规模较小的项目。++
敏捷宣言
ü 个体和交互胜过过程和工具
ü 可工作的软件胜过大量的文档
ü 客户合作胜过合同谈判
ü 响应变化胜过遵循计划
敏捷方法-XP
4大价值观
沟通【加强面对面沟通】
简单【不过度设计】
反馈【及时反馈】
勇气【接受变更的勇气】
12条过程实践规则
简单设计
测试驱动
代码重构
结对编程
持续集成
现场客户
发行版本小型化
系统隐喻
代码集体所有制
规划策略
规范代码
40小时工作机制
敏捷方法(SCRUM)
敏捷方法分类：
◆极限编程(XP)：价值观【交流、朴素、反馈、勇气】、近螺旋式的开发方法。
◆水晶方法：提倡"机动性"的方法，拥有对不同类型项目非常有效的敏捷过程。
◆SCRUM：侧重于项目管理。
◆特征驱动开发方法(FDD)：认为有效的软件开发需要3要素【人、过程、技术】。定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。◆开放式源码（OpenUP）：程序开发人员在地域上分布很广【其他方法强调集中办公】。
◆自适应软件开发(ASD)方法：其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。
◆动态系统开发方法(DSDM)：倡导以业务为核心。
在Scrum中，使用产品Backlog来管理产品的需求，产品Backlog是一个按照**++商业价值++**排序的需求列表。根据Backlog的内容，将整个开发过程被分为若干个短的迭代周期(Sprint)
在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求组成Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。当所有Sprint 结束时，团队
提交最终的软件产品。
3.13 软件重用和逆向工程
软件重用 ：重复使用相同或相似软件元素的过程
软件元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识等
标准函数库是任何软件都能使用的通用构件，不局限于特定的垂直领域，因此属于水平式重用。
垂直式重用是指局限于某一垂直领域的重用，如电力系统专用构件
水平式重用的特点是不分行业，通用。
可复用的资产包括：需求、架构设计、元素、建模分析、测试、项目规划、过程+方法+工具，人员、样本系统、缺陷消除。
一般的复用包括：函数的复用、库的复用、面向对象开发中的类、接口和包的复用。
复用过程遵循"++构建/获取可复用的软件资产(复用前提)++ ++--->管理可复用资产 --->使用可复用资产++"的顺序。
软件架构复用的类型包括：++机会复用++ 和**++系统复用++**。
机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。
系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。
管理可复用资产阶段最重要的是构件库(Component Library)，用于对可复用构件进行存储和管理，它是支持软件复用的必要设施。
逆向工程：
逆向工程过程能够导出过程的设计模型(实现级） 、程序和数据结构信息(结构级） 、对象模型、数据和控制流模型(功能级） 以及UML状态图和部署图(领域级）。其中，结构级包括反映程序各部分之间相关依赖关系的信息；功能级包括反映程序段功能及程序段之间关系的信息。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
(1)重构/重组(Restructuring)。重构是指在【同一抽象级别】上【转换系统描述形式】
(2)设计恢复(Design recovery)。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
(3)逆向工程(Reverse engineering)：逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
(4)正向工程(Forward engineering)。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
(5)再工程/重构工程(Re-engineering)。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。
|---------------------------------------------------------|-------------|
| 逆向工程恢复信息的方法 ||
| 方法 | 导出信息 |
| 用户指导下的搜索与变换(0sers-Directed search and Transformation)万法 | 实现级、结构级 |
| 变换式方法(Transfomation Approaches) | 实现级，结构级、功能级 |
| 基于领域知识(Donain knowledge-Based)的方法 | 功能级、领域级 |
| 铅板恢复法 | 实现级、结构级 |
3.14 净室软件工程（CSE，Cleanroom Software Engineering）
ü 净室即无尘室、洁净室。也就是一个受控污染级别的环境
ü 使用盒结构规约(或形式化方法)进行分析和设计建模，并且强调将正确性验证，而不是测试，作为发现和消除错误的主要机制。
ü 使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息。
形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。形式化方法的主要优越性在于它能够数学地表述和研究应用问题及软件实现。但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难于为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。
净室软件工程(Cleanroom Software Engineering，CSE)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构规约进行分析和建模，并且将正确性验证作为发现和排除错误的主要机制，使用统计测试来获取认证软件可靠性所需要的信息。CSE强调在规约和设计上的严格性，还强调统计质量控制技术，包括基于客户对软件的预期使用测试。
【技术手段】
√ 统计过程控制下的增量式开发：控制迭代
√ 基于函数的规范和设计：盒子结构
定义3种抽象层次：行为视图(黑盒)->有限状态机视图(状态盒)->过程视图(明盒)
√ 正确性验证：净室工程的核心
√ 统计测试和软件认证:使用统计学原理，总体太大时必须采用抽样方法
【缺点】
√ 太理论化，正确性验证的步骤比较困难且耗时。
√ 开发小组不进行传统的模块测试，这是不现实的。
√ 脱胎于传统软件工程，不可避免带有传统软件工程的一些弊端。
3.15 需求工程-概述
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
3.16 需求工程-需求获取
3.17 结构化需求分析（SA）
3.17.1 需求工程 -需求开发-需求分析- SA
需求工程-需求开发-需求分析- SA(DFD)
分层数据流图（DFD）：
ER图：
3.17.2 需求工程-需求开发-需求分析-OOA
3.17.3 需求开发-需求分析-OOA-UML-4+1视图
3.17.4 需求工程-需求开发-需求定义
3.17.5 需求工程-需求开发-需求验证
3.17.6 需求跟踪
需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素包括其它需求、体系结构、设计部件、源代码模块、测试、帮助文件和文档等。
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护"需求-设计-编程-测试"之间的一致性。
需求跟踪有两种方式：
（1）++正向跟踪++ 。++检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。++
（2）++逆向跟踪++ 。++检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。++
正向跟踪和逆向跟踪合称为**"双向跟踪"**。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
3.17.7 需求变更管理过程
3.18 软件系统建模(Software System Modeling)
论软件系统建模方法及其应用
软件系统建模(Software System Modeling)是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。
说明软件系统开发中常用的建模方法有哪几类?阐述每种方法的特点及其适用范围。
1、结构化建模方法
结构化建模方法是以过程为中心 的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图(DFD)。对于流程较为稳定的系统可考虑结构化建模方法。
2、信息工程建模方法(或数据库建模方法)
信息工程建模方法是一种以数据为中心 ，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图(ERD)。主要用于数据建模。
3、面向对象建模方法
面向对象建模方法将"数据"和"过程"集成到被称为"对象"的结构中 ，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型 。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML(统一建模语言)。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统，是目前比较常用的建模方法。
3.19 人机界面设计(黄金三法则)
3.20 结构化设计（SD）
软件结构化设计包括架构设计、接口设计、数据设计和过程设计等任务。它是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模块化的过程。
概要设计【外部设计】:功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图
详细设计【内部设计】:为每个具体任务选择适当的技术手段和处理方法
3.20.1 结构化设计(内聚)
++通信内聚++：模块内的功能元素通过操作同一组数据而结合在一起。
示例：模块读取数据、处理数据并存储数据。
++时间内聚++：模块内的功能元素在同一时间段内被执行，但逻辑上可能没有直接关系。
示例：初始化模块。
++过程内聚++：模块内的功能元素按特定的次序执行，且这些功能是为完成某个过程或任务而紧密结合的。
示例：订单处理模块中的多个步骤（验证订单、扣款、生成发票）。
++逻辑内聚++：模块内的功能元素基于某种逻辑条件选择性执行。
示例：错误处理模块，根据不同的错误码执行不同的操作。
3.20.2 结构化设计(耦合)
3.20.3 结构化设计(模块四要素)
模块的四个要素
输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个块从调用者那儿取得输入，进行加工后再把输出返回调用者。
处理功能：指模块把输入转换成输出所做的工作。
内部数据：指仅供该模块本身引用的数据。
程序代码：指用来实现模块功能的程序。
3.21 面向对象设计
3.21.1 面向对象设计(基本过程)
3.21.2 面向对象设计(类的分类)
3.21.3 系统设计-面向对象设计-设计原则
<< 单一职责原则：设计目的单一的类
<< 开放-封闭原则：对扩展开放，对修改封闭
<< 李氏(Liskov)替换原则：子类可以替换父类
<< 依赖倒置原则：要依赖于抽象，而不是具体实现;针对接口编程，不要针对实现编程
<< 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
<< 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
<< 迪米特(Demeter)原则(最少知识原则)：一个对象应当对其他对象有尽可能少的了解
3.22 软件测试类型
静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段进行检测，靜态测试包括对文档的静态测试和对代码的靜态测试.对代码的静态测试包括控制流分析、数据流分析、接口分析和表达式分析。
1.控制流分析：控制分析是指使用控制流程图检测程序控制结构的过程。例如：可检查被测程序是否存在没有使用的语句或子程序，是否调用并不存在的子程序，以及是否存在无法达到的语句等。
2.数据流分析 ：数据流分析是指使用控制流程图分析数据各种异常情况的过程。包括**++数据初始化、赋值或引用过程中的异常++**。
3.接口分析：接口分析主要包括模块之间接口的一致性分析，模块与外部数据库及其他软件配置之间的一致性分析、子程序和函数之间的接口一致性分析等。
4.表达式分析：表达式分析用于检查程序代码中的表达式错误。
3.22.1 白盒测试、黑盒测试、自动化测试
白盒测试【结构测试】:主要用于单元测试阶段。
在白盒测试用例中，其中++语句覆盖是最弱的要盖准，路径覆盖则最强++
(1)语句覆盖。语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准，
(2)判定覆盖，判定覆盖也称为分支覆盖，它是指不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程字逻辑的覆盖程度仍然不高。
(3)条件覆盖，条件要盖是指不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可前的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。
(4)条件/判定覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定条件覆盖。它的含义是，选取足够的则试用例，使得判定表达式中每个条件的所有可前能吉果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。
(5)路径覆盖，路径覆盖是指选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径至少经过一次）。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准，但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。
++白盒测试包括：控制流测试、数据流测试、程序变异测试++
++黑盒测试包括：功能测试++
黑盒测试【功能测试】:主要用于集成测试、确认测试和系统测试阶段。
++灰盒测试++ 介于黑盒与白盒测试之间。++灰盒测试除了重视输出相对于输入的正确性，也看重其内部的程序逻辑。但是，它不可能像白盒测试那样详细和完整。它只是简单地靠一些象征性的现象或标志来判断其内部的运行情况++。
软件确认测试 一种针对需求的测试，是用户参与的测试。它主要验证软件功能、性能及其它特性是否与用户需求一致。
软件确认测试包括：内部确认测试、Alpha、Beta和验收测试。
自动化测试：
当前流行的自动化测试工具主要使用脚本技术来生成测试用例。脚本是一组测试工具执行的指令集合，其作用是通过回放的方式来模拟手工测试所执行的操作，生成的脚本必须是可读、可编辑的，并且应提供控制指令的支持，使工具能够复用所编写的脚本。好的脚本应该编写注释、功能独立，结构清晰、可读，文档完整。
脚本的基本结构主要有以下5种：
线性脚本 。++线性脚本是录制手工测试的测试用例时得到的脚本，这些脚本是未做修改的。++
结构化脚本。结构化脚本具有各种逻辑结构，包括选择型结构、分支结构、循环迭代结构，而且具有函数调用功能。结构化脚本具有很好的可用性和灵活性，易于维护。
共享脚本。共享脚本是指一个脚本可以被多个测试用例使用，即脚本语言允许一个脚本调用另一个脚本。
数据驱动脚本。数据驱动脚本是指将测试输入存储在独立的数据文件中，而不是脚本中。这样，脚本可以针对不同的数据输入实现多个测试用例。
关键字驱动脚本。关键字驱动脚本是数据驱动脚本的逻辑扩展，它用测试文件描述测试用例，它说明测试用例做什么，而不是如何做。关键字驱动脚本允许使用描述性的方法，只需要提供测试用例的描述，即可生成测试用例。
3.23 软件测试阶段
回归测试：测试软件变更之后，变更部分的正确性和对变更需求的符合性
测试阶段
单元测试：依据【详细设计】模块测试，模块功能、性能、接口等
集成测试：依据【概要设计】模块间的接口
系统测试：依据【需求文档】，在真实环境下，验证完整的软件配置项能否和系统正确连接
确认测试：依据【需求文档】，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试
3.24 集成测试策略
集成测试可以分为一次性组装 和增量式组装 ，增量式组装测试效果更好。集成测试计划 一般在概要设计阶段完成。
3.25 软件系统测试
3.26 系统转换计划
3.26.1 系统转换计划-遗留系统演化策略
3.26.2 系统转换计划-新旧系统的转换策略
3.26.3 系统转换计划-数据转换与迁移
3.27 软件维护
3.27.1 软件维护-影响可维护性的因素
【可理解性】是指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度。
【可修改性】是指修改软件的难易程度。
【可测试性】是指验证软件程序正确的难易程度。可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越大，测试的难度也就越大。
【可靠性】一个软件的可靠性越高，需要维护的概率就会越低。
【可移植性】是指将软件从一个环境移植到新的的环境下正确运行的难易程度。
软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率。
3.27.2 软件维护类型
<< ++正确性维护【修BUG】++ :识别和纠正软件错误/缺陷，测试不可能发现所有错误。
<< ++【适应性维护应变】++ :指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。
<< ++完善性维护【新需求】++ :扩充功能和改善性能而进行的修改。
<< ++预防性维护【针对未来】++ :为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能以使用系统适应各类变化而不被淘汰。经典实例:【专用】改【通用】