# 1 软件工程概述

# 软件的概念

程序应该不陌生，就是编程一系列指令使能够实现预期的功能，这是软件的基础；

数据是程序的数据结构和信息，不是所有程序都需要数据库，但一定都有数据结构；

文档类似开发文档，包括软件的设计、开发、功能、维护等等。

上图是软件的结构示意图，可执行部分只有程序，而数据和文档都是支撑软件完整性的作用。

# 软件的特点

软件是逻辑的，而不是物理的。

软件是逻辑的而不是物理的，说明软件的复杂性、难以描述性、不可见性、变化性。

# 软件危机的概念和产生的原因

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

严重问题：多指效率和质量上的问题。

可以总结为： 周期长、成本高、质量差、维护难。

# 软件工程的定义、三要素、应用软件工程的原因

软件工程的定义

IEEE 计算机协会将软件工程定义为:（1) 将系统化的、科学化的、可量化的方法应用于软件的开发、运行和维护，即针对软件的工程应用。(2) 对上述应用方法的研究

三要素：方法、工具、过程

应用软件工程的原因：软件工程的应用主要是为了提高软件产品的质量和开发效率，减少维护的困难，并解决软件开发中的各种问题。它可以帮助我们更好地分解和解决复杂的软件开发问题。总的来说，应用软件工程的原因主要是为了应对所谓的 “软件危机”。

# 2 软件过程

# 软件生命周期概念

软件产品或软件系统从设计、投入使用到被淘汰的全过程

# 软件过程概念

软件过程是在工作产品构建过程中，所需完成的工作活动、动作和任务的集合

活动：主要实现宽泛的目标，与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系。
动作：包含了主要工作产品生产过程中的一系列任务。
任务：关注小而明确的目标，能够产生实际产品。

# 软件过程模型的定义

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

常见的软件过程模型
瀑布模型 (经典的生命周期模型)
演化过程模型
原型模型
并行开发模型
增量过程模型
增量模型
RAD
螺旋模型
其他过程模型
基于构件模型
智能模型
敏捷过程模型

# 软件工程的中心与三要素

软件工程的中心：质量
软件工程三要素：方法、工具、过程

方法是完成软件开发的各项任务的技术方法，为软件开发提供技术；

工具是为运用方法而提供的自动或半自动的软件工程的支撑环境；

过程是为了获得高质量软件而所需要完成的一系列任务的框架。

常见的几种软件过程模型：瀑布、增量、原型、螺旋、敏捷等，比较各自优缺点

# 软件生存期模型

# 瀑布模型

软件生命周期：软件产品或软件系统从设计、投入使用到被淘汰的全过程

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

优点
简单，过程透明性高，过程可管理性高
推迟实现，软件实现前必须进行系统分析和设计工作
以阶段评审和文档控制为手段进行质量控制，能够及时发现并纠正软件缺陷，能够达到预期质量要求
缺点
模型灵活性差，不适合需求不明确或准确的场合
模型风险控制能力弱
过多的文档增加了工作量，当技术具有不确定性情况下完全以文档来评估项目进度时会产生错误的结论
适用场合
瀑布模型适用于系统需求明确、技术成熟、工程管理较严格的场合。

# 快速原型模型

快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型是增量模型的另一种形式，在开发真实系统之前迅速建造一个可以运行的软件原型，以便理解和澄清问题，在该原型的基础上，逐渐完成整个系统的开发工作。

它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。

优点
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
适合预先不能确切定义需求的软件系统的开发
缺点
所选用的开发技术和工具不一定符合主流的发展；
快速建立起来的系统结构加上连续的修改可能会导致产品质量低下
使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新
运用方式
由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。
抛弃策略是将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的。
附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。
采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、人员素质、可供支持的原型开发工具和技术等，这要根据实际情况的特点来决定。

# 增量模型

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

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

优点
引入增量包概念，不需要提供完整的需求。只要有一个
增量包出现，开发就可以进行。
在项目的初始阶段不需要投入太多的人力资源。
增量可以有效地管理技术风险，降低系统失败风险。
有利于增加客户信心，提高系统可靠性、可维护性和稳定性。
缺点
增量粒度难以选择：每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。
确定所有的基本业务比较困难。
适用场合
进行已有产品升级或新版本开发，增量模型是非常适合的；
对完成期限严格要求的产品，可以使用增量模型；
对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。

# 螺旋模型

最早由 Boehm 提出，该模型结合了瀑布模型和原型模型的特点

螺旋模型沿着螺线旋转，在笛卡尔坐标的四个象限上分别表达了四个方面的活动

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

风险分析
- 分析所选方案，考虑如何识别和消除风险

实施工程
- 实施软件开发

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

优点
支持用户需求的动态变化
原型可看作可执行的需求规格说明书，易于用户和开发人员共同理解，可作为继续开发的基础，为用户参与关键决策提供了方便
螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力
螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险
缺点
如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；
使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高
适用场合
支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型

敏捷模型是一种软件开发模型，起源于美国，以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发 123。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征 1234。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态 1234。

敏捷模型的优点包括更快交付价值，更低的风险，拥抱变化，更好的质量，持续改进，更高的客户满意度，更高的团队满意度，以及更大的灵活性 2。然而，敏捷模型也有其缺点，如很难进行准确的资源规划，很难准确地定义 “轻量的” 或必要的文档，很难把握整体产品的一致性，很难预测有限的终点，以及很难有效地进行度量 2。总的来说，敏捷模型是一种高效的开发模式，适用于需要快速迭代和响应变化的项目 1234。

# 3 需求分析

需求分析的概念

定义
对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成下一步的需求规格说明书.
需求提炼 (需求分析) 的核心在于建立分析模型
需求提炼 (需求分析) 采用多种形式描述需求，通过建立需求的多种视图，揭
示出一些更深的问题。
需求提炼 (需求分析) 还包括与客户的交流以澄清某些易混淆的问题，并明确
哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对
将来的产品有个相同而清晰的认识。

需求分析的过程：需求确认与需求变更

需求确认的步骤：需求获取→需求提炼→需求描述→需求验证

# 需求分析的四个步骤

需求获取
软件需求的来源以及软件工程师收集这些软件需求的方法
完整定义：指的是软件需求的来源以及软件工程师收集这些软件需求的方法。它也称为需求抓取、需求发现和需求获得
需求提炼
产生操作规格参数表，指明与其他系统元件的软件接口，确定软件必须遵循的约束
完整定义：对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成需求规格说明书。
需求描述
撰写 * 需求规格说明书 *
完整定义：软件需求规格说明书 (SRS)---- 是对待开发系统的行为的完整描述，包含了描述用户与软件交互的用例的集合。用例通常描述功能性需求，除了用例之外，SRS 还包含非功能性需求。
需求验证
检查需求的 * 正确性、完整性、非二义性 *、内部和外部的 * 连贯性 *
完整定义：需求验证即检查需求的正确性、完整性、非二义性、内部和外部的连贯性。这不可避免地需要用户的参与，用户是问题的所有者，只有他们才能决定需求规格说明书是否恰当描述了他们的问题

# 需求分析三类建模：功能模型、数据模型、行为模型。

# 面向对象的需求分析过程中，三类模型各包含哪些内容？

数据模型：描述系统中数据的结构和关系，一般包括实体、属性和关系三个要素。数据模型是用来帮助开发人员在设计系统时明确数据的概念和关系，进而实现数据的存储、查询、分析和管理。
功能模型：描述系统的功能和用例，一般包括系统的输入、输出和处理过程。功能模型主要用于帮助开发人员在设计系统时明确系统的功能需求，进而实现系统的设计、开发、测试和维护。
行为模型：描述系统中各个组成部分的交互和行为，一般包括系统的活动图、状态图和序列图等。行为模型主要用于帮助开发人员在设计系统时明确各个组成部分之间的交互关系和行为规则，进而实现系统的设计、开发、测试和维护。

# UML 图类型有哪些？

用例图、类图、活动图

# 掌握用例图和活动图作法。泳道划分活动图、分支及汇合、分叉及合并

# 4 系统设计

定义
在 [IEEE610.12-90] 中，软件设计定义为软件系统或组件的架构、构件、接口和其他特性的定义过程及该过程的结果。

系统设计分为概要设计和详细设计

与设计相关的 8 个概念：抽象、信息隐藏、体系结构、功能独立、设计模式、精化、模块化、重构

抽象、

体系结构、

设计模式、

模块化、

信息隐藏、

功能独立、

细化、

重构。

系统设计从体系结构、数据、接口和组件四方面进行设计。
面向对象的系统设计，各自包含哪些设计内容？
掌握类图和顺序图作法

# 5 质量保证

# 软件质量的概念和关键点。

软件质量：明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发软件的期望的隐性特点

关键点：

符合明确规定的功能和性能要求
符合明确的开发标准
符合所有软件开发专业的共性、隐性标准，如易用性、可维护性等测试策略

# V 模型概念，测试与开发的各阶段对应关系。

# 什么是 V 模型

RAD（Rapid Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。其形状像一个字母 V，故称为 V 模型。又称软件测试的 V 模型。

V 模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终，是瀑布模型的一个变体。V 模型描述了质量保证活动和沟通、建模相关活动以及早期构键相关的活动之间的关系。随着软件团队工作沿着 V 模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着 V 模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着 V 模型左侧步骤向下推进过程中所生成的每个模型。V 模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

# V 模型主要阶段

V 模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

需求分析
即首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能，这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。
概要设计
主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
详细设计
对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。
软件编码
按照详细设计好的模块功能表，编程人员编写出实际的代码。
单元测试
按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。
集成测试
经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
系统测试
经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。
验收测试
主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到预期的效果。

# 优缺点

优点：①包含了底层测试（单元测试）和高层测试（系统测试）（底层测试：检验源代码质量的测试，如：单元测试；高层测试：检验整个系统的需要，如：系统测试）；

②清楚的标识了开发和测试的各个阶段；

③自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

缺点：①自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；

②实际工作中，需求经常变化，导致 v 模型步骤，反复执行，返工量很大，灵活度较低。

改良：每个步骤都可以进行小的迭代（更新）工作。

# 对应关系

一般来讲：单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。验收测试与用户需求对应，是非设计流程。

# 适用范围

V 模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成 V 模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

# 单元测试的内容、集成测试的分类、系统测试的分类、验收测试的分类。

# V 模型

V 模型非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段对应关系：
单元测试的主要目的是验证软件模块是否按详细设计的规格说明正确运行；
集成测试的主要目的是检查多个模块间是否按概要设计说明的方式协同工作；
系统测试的主要目的是验证整个系统是否满足需求规格说明；
验收测试从用户的角度检查系统是否满足合同中定义的需求，以及确认产品是否能符合业务上的要求

# 回归测试

有选择的重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求。
回归测试可以在所有的测试级别执行，并且应用于功能和非功能测试中。
回归测试应该尽量采用自动化测试

# 单元测试

单元：
面向过程的语言：函数 / 过程
面向对象的语言：成员函数 / 类本身
主要依据：
是详细设计，不是针对代码的测试
因为未测代码可能包含错误和缺陷，如果依照其测试，则可能无法发现一些错误
主要内容：
模块接口
局部数据结构
边界条件
独立路径
出错处理

# 集成测试

# 重要概念
桩模块：用以代替被测模块调用的子模块，可以做少量数据操作
驱动模块：相当于被测模块的主程序，接受测试数据传送给被测模块，最后输出实测结果

# 自顶向下的集成方法

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

# 自底向上的集成方法

从软件最底层模块开始，按照接口依赖关系逐层向上集成进行测试。
优点：每个底层模块都得到测试，不需要桩模块。
缺点：每个模块都需要编写驱动模块；缺陷的隔离和定位不如自顶向下。

# SMOKE 方法

系统最基本功能的测试，快速验证基本功能，在软件代码正是编译并交付测试以前先尽量消除其表面的错误，减少后期测试成本。
优点：节省测试时间，防止构造失败
缺点：覆盖率比较低

# 系统测试

主要内容有：功能性测试、性能测试、压力测试、恢复测试、安全测试、其他测试（配置测试、兼容性测试、本地化测试、文档测试、易用性测试）

# 验收测试

时间：通过系统有效性测试及软件配置审查以后，开始系统验收测试。
人员：以用户为主，开发人员和质量保证员也应参加。
内容：由用户参加设计测试用例，使用生产中的实际数据进行测试。

回归测试的概念、测试技术常见术语的概念：软件缺陷、验证和确认、测试与质量保证、质量与可靠性、调试与测试、测试用例

软件测试的定义
在某种指定的条件下对系统或组件操作，观察或记录结果，对系统或组件的某些方面进行评估的过程。分析软件各项目以检测现有的结果和应有结果之间的差异，并评估软件各项目的特征的过程。

# 软件测试

# 基本原则

穷尽测试是不可能的：决定哪些更重要
测试无法显示潜在的软件缺陷：不能保证没有错误
测试活动应该尽早进行：越早发现修改成本越低
软件缺陷具有群聚性：一个问题出错导致多个错误现象出现
注意杀虫剂现象：用异样的测试用例是不可取的（可能是少数能通过的特例）
应尽量由独立的测试团队进行测试：自己测试自己是不可取的（想不到特殊情况）

# 目标

确认系统满足其预期的使用和用户的需要
确认解决了所需解决的问题
为测试的过程建立责任和可解释性
便于及早发现软件和系统的异常
及早提供软件和系统的性能评估
为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险
鉴别出程序在功能等方面的异常聚集之处

# 测试用例

定义：是测试输入、执行条件，以及预期结果的集合
目的：为特定目的开发，如执行特定的程序路径或验证与指定的需求相符合

# 软件缺陷

满足下面条件之一即发生软件缺陷：
未完成：软件未实现产品说明书要求的功能。
有错误：软件出现了产品说明书指明不能出现的错误。
画蛇添足：软件实现了产品说明书未提到的功能
隐含需求未实现：软件未实现产品说明书虽未明确提及但应该实现的目标。
不好用：软件难以理解、不易使用、运行缓慢

# 调试与测试

相同点：都包含处理软件缺陷和查看代码的过程
不同点：测试的目标时发现软件缺陷的存在；调试的目标是定位与修复缺陷。

# 测试与质量保证

软件测试人员的目标：尽早找出软件缺陷并确保缺陷得以修复
软件质量保证人员的主要职责：创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法

# 软件测试的评估准则

覆盖率：测试集合 T / 测试需求集合 TB
故障插入：测试前有意地插入一些故障到程序中，发现率 = 发现的插入错误数 / 总错误数
变异分值：程序进行多次变异，用同样的测试用例进行测试，评估这些测试用例探测程序变异间差异的能力，如错误的标识符或运算符等。

# 白盒测试、黑盒测试、静态分析各有哪些方法？

# 黑盒测试

# 定义
黑盒测试指忽略系统或组件的内部机制，仅关注于那些特定输入响应及相应执行条件的输出测试，也称功能性测试。
把测试对象看做一个黑盒子，测试人员完全不考虑程序内部逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
分类
# 等价类划分
含义：等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少许有代表性的数据作为测试用例
步骤：对输入域进行建模、对参数进行等价类划分、对参数进行恰当的组合。
# 边界值分析
边界：对输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。
边界选取：应当选取正好等于、刚刚大于、或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值。
# 状态测试
必要性：黑盒测试阶段，程序内部的逻辑结构无从得知，因此只能通过状态测试间接验证。
含义：一种基于模型的测试，是指用状态图来描述时间序列 / 用例场景，由此产生测试用例
步骤：建立状态转换图、设计测试用例。

# 白盒测试

# 定义
白盒测试指考虑系统或组件内部机制的测试（如分支测试、路径测试、语句测试等)，也称结构性测试。
把测试对象看作一个透明的盒子，它允许测试人员利用程序的内部逻辑结构及有关信息设计或选择测试用例，对程序的所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
# 逻辑覆盖测试
含义：以程序内部的逻辑结构为基础的设计测试用例的技术，属于白盒测试。
分类：
语句覆盖：每条可执行语句至少执行一次
条件覆盖：每个条件的可能取值至少执行一次
分支覆盖：每个判断的取真分支和取假分支都经历一次
条件组合覆盖：每个判断所有可能取值条件的组合都经历一次
# 控制流图覆盖测试
含义：把代码转换为控制流图，基于其进行测试，属于白盒测试。
注意：
在选择或多分支结构中，分支的汇聚处应有一个汇聚结点
边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域
如果判断中的条件表达式是由一个或多个逻辑运算符 (OR，AND,NAND，NOR) 连接的复合条件表达式，则需要改为一系列只有单个条件的嵌套的判断
节点覆盖：等价于语句覆盖
边覆盖：包含节点覆盖且也可以实现分支覆盖
路径覆盖：覆盖程序中所有可能的路径 (基本路径测试)
# 基本路径测试
计算程序环路复杂性：
①V (G)=e-n+2，e：图中边的数目；n：节点数目；
②区域数目
确定线性独立性的基本集合：
从入口走到出口作为基线，回溯基线路径，当出度大于等于 2 时选择不同的边，重复直到路径数目等于 V (G)
为每条基本路径导出测试用例：
确保基本路径集中的每一条路径的执行，用逻辑覆盖方法保证某条路径可被测试到，最后执行测试用例与预期结果比较

# 灰盒测试

黑盒和白盒测试混合方法。
介于白盒测试和黑盒测试之间的一种测试，多用于集成测试阶段，不仅关注输入输出的正确性，同时也关注程序内部的情况。

# 静态测试

# 含义
不实际运行程序，通过检查和阅读等手段发现错误、评估代码质量的软件测试技术。
# 范围
代码检查、静态结构分析、代码质量度量
# 目的
提高代码可靠性、尽早发现缺陷、审核定位易出错模块
# 基本思想
评审
# 三种评审类型
同事审查：非正式评审，初次审查
走查：开发组内部进行，开发者讲解、回答问题、记录
审查：会议形式，制定目标流程规则结果报告等

# 掌握等价类划分测试方法。（有效等价类和无效等价类划分、对应测试用例的设计）

项目管理四要素：人员、产品、项目、过程（概念）

# 软件度量有哪些方法

# 测量软件生产率的两种方法

软件生产率测量的两种方式：
直接测量：基于 LOC（一定时间产生的代码行数）
间接测量：基于功能点（给定时间内产出的功能点目标点）

# 基于 LOC 测量

# 例题：
# 优点
LOC、KLOC 和相关度量容易计算
许多现有的软件估算模型都使用 LOC 和 KLOC 作为一项重要输入
有大量的关于 LOC 的文献和数据
# 缺点
LOC 依赖于使用的语言，这对短小精悍的程序不利
不太适用于非过程化语言
LOC 是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得，例如，项目计划人员难于在分析和设计完成之前估算 LOC

# 基于功能点测量

复杂性调整值：14 个复杂性因素之和，sum (Fi)
功能点总数：sum (数量 * 功能点个数)
功能点计算公式 (FP)：FP=(total_counts)(0.65+0.01sum(Fi))
每 FP 的错误数 / 缺陷数 / 文档页数：总的 *** 数 / FP 数
每人月的 FP 数：FP 数 / 总的人月数
# 例题：
还可根据经验度量、通过任务分解度量工作量、根据目前可用资源估算项目工作量…

成本估算的方法之一：COCOMO 模型，了解即可。

学习