README.md

# Table of Contents

* [1 软件测试目的](#1-软件测试目的)
* [2 软件测试的原则](#2-软件测试的原则)
* [3 软件测试分类](#3-软件测试分类)
  * [3.1 按测试阶段划分](#31-按测试阶段划分)
  * [3.2 按执行状态划分](#32-按执行状态划分)
  * [3.3 按照测试技术划分](#33-按照测试技术划分)
  * [3.4 按执行主体划分](#34-按执行主体划分)
* [4 软件测试模型](#4-软件测试模型)
  * [4.1 `V模型`](#41-v模型)
  * [4.2 `W模型`](#42-w模型)
  * [4.3 `H模型`](#43-h模型)
  * [4.4 `X模型`](#44-x模型)
  * [4.5 前置模型](#45-前置模型)
  * [4.6 测试模型各自特点](#46-测试模型各自特点)
* [5 测试用例](#5-测试用例)
  * [5.1 定义](#51-定义)
  * [5.2 测试用例的设计方法](#52-测试用例的设计方法)
  * [5.3 测试用例设计误区](#53-测试用例设计误区)

# 1 软件测试目的
测试的目的就是以最少的时间和人力找出软件中潜在的各种错误和缺陷，证明软件的功能和性能与需求说明相符，`Glenford J.Myers`曾提出以下观点：

- 测试是为了证明程序有错，而不是证明程序无错误
- 一个好的测试用例能发现至今未发现的错误
- 一个成功的测试是发现了至今未发现的错误

软件测试的目的往往包含以下内容：

- 测试并不仅仅是为了找出错误，通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进
- 测试帮助测试人员设计有针对性的测试方法，改善测试的效率和有效性
- 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法


# 2 软件测试的原则
- 软件测试是证伪而非证真
- 尽早地和不断地进行软件测试
- 重视无效数据和非预期的测试
- 应当对每一个测试结果做全面检查
- 测试现场保护和资料归档
- 程序员应避免检查自己的程序
- 充分注意测试中的群集现象 
- 用例要定期评审

# 3 软件测试分类
## 3.1 按测试阶段划分
可以分为：

- 单元测试：用于检验被测代码的一个很小的、明确的功能是否正确
- 集成测试：对经过单元测试的模块之间的依赖接口的关系图进行测试
- 确认测试：用于验证软件的有效性
- 系统测试：将整个软件系统与计算机硬件、外设、支持软件、数据、人员等其他系统元素结合起来进行测试
- 验收测试：最终用户参与测试的过程

## 3.2 按执行状态划分
可以分为：

- 动态测试：运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，由“构造测试实例、执行程序和分析程序的输出结果”组成
- 静态测试：对被测程序进行特性分析方法的总成，是指计算机不运行被测试的程序，而对程序和文档进行分析和检查，包括走查、符号执行、需求确认等


## 3.3 按照测试技术划分
可以分为：

- 黑盒测试：也叫功能测试或数据驱动测试，测试时把程序看做不能打开的黑盒，完全不考虑程序内部结构和特性，对程序接口测试，检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息的完整性
- 白盒测试：又叫结构测试或逻辑驱动测试，用于检测产品内部的结构及检验程序中的每条通路能够按照预定要求正确工作
- 灰盒测试：介于白盒与黑盒测试之间，主要用于测试各个组件之间的逻辑关系是否正确，采用桩驱动把各个函数按照一定的逻辑串起来，达到在产品还没有界面的情况下的结果输出

一般来说，单元测试采用白盒测试的方法，集成测试采用灰盒测试的方法，而系统测试和确认测试采用黑盒测试的方法，黑盒测试与白盒测试比较如下：

- 规划方面：黑盒测试用于功能测试，而白盒测试用于结构测试
- 性质：黑盒测试是一种确认（`Validation `）技术，而白盒测试是一种验证（`Verification`）技术
- 优点：黑盒测试的优点包括从用户的角度出发、适用于各阶段测试、从产品功能角度测试、容易入手生成测试数据，而白盒测试的优点包括针对程序内部特定部分进行覆盖测试、可构成测试数据使特定程序部分得到测试、有一定充分性的度量手段、可获得较多工具的支持
- 缺点：黑盒测试的缺点包括无法测试程序内部特定部分、某些代码得不到测试、如果规格说明错误则无法发现、不易进行充分性的测试，白盒测试的缺点包括无法测试程序外部特性、通常不易生成测试数据、无法对未实现规格说明的部分进行测试、工作量大通常只用于单元测试
- 应用范围：黑盒测试的应用范围包括边界分析法、等价类划分法、决策表测试，白盒测试的应用范围包括：语句覆盖、判定覆盖、条件覆盖、路径覆盖等

## 3.4 按执行主体划分
可以分为：

- `Alpha`测试：也叫验收测试或开发方测试，开发者和用户共同去检测与证实软件的实现是否满足软件设计说明或软件需求规格说明的要求
- `Beta`测试：通常被认为是用户测试，通过用户大量使用来评价检查软件
- 第三方测试：也叫独立测试，由第三方机构来进行的测试

# 4 软件测试模型
软件测试模型用于指导软件测试的实践，常见的有：

- `V模型`
- `W模型`
- `H模型`
- `X模型`
- `前置模型`

## 4.1 `V模型`
`V模型`反映了测试活动与开发活动间的关系，标明测试过程中存在的不同级别，并清楚描述测试的各个阶段和开发过程的各个阶段对应关系。

- 左侧是开发阶段：从定义软件需求开始，把需求转换为概要设计和详细设计，最后形成程序代码
- 右侧是测试阶段：在代码编写完成后，从单元测试开始，依次进行集成测试、系统测试和客户验收测试


![在这里插入图片描述](https://img-blog.csdnimg.cn/20210308093643375.png)


## 4.2 `W模型`
`W模型`相比起`V模型`，增加了软件各开发阶段中应同步进行的验证和确认活动。`W模型`强调：

- 测试伴随整个软件周期
- 测试对象不仅是程序，需求、设计也要测试
- 测试与开发同步进行

![在这里插入图片描述](https://img-blog.csdnimg.cn/20210308095334139.png)

## 4.3 `H模型`
`H模型`将测试活动完全独立出来，使得测试准备活动和测试执行活动清晰地体现出来，从而使得测试准备与测试执行分离，有利于资源调配，减低成本，提高效率。

![在这里插入图片描述](https://img-blog.csdnimg.cn/2021030810021469.png)

## 4.4 `X模型`
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210308110543771.png)

- 左边：描述的是针对单独程序片段进行的编码测试，此后将进行频繁的交接，通过集成最终成为可执行程序
- 右边：上方定位了已通过集成测试的成品进行封板并提交给用户，也可作为更大规模和范围内集成的一部分，下方定位了探索性测试

## 4.5 前置模型
前置模型将测试和开发紧密结合，优点如下：

- 开发和测试相结合
- 对每一个交付内容进行测试
- 让验收测试和技术测试保持相互独立
- 反复交替的开发和测试
- 引入新的测试理念

## 4.6 测试模型各自特点
- `V模型`：强调了整个软件项目开发中需要经历的若干个测试级别，每个级别都与一个开发阶段相对应，但它没有明确指出应该对需求、设计进行测试
- `W模型`：对`V模型`进行了补充，强调了测试计划等工作的先行和堆系统需求和软件设计的测试，但和`V模型`一样，没有专门针对软件测试的流程予以说明
- `H模型`：表现了测试是独立的，就每一个软件的测试细节来说，都有一个独立的操作流程，只要测试前提具备了，就可以开始进行测试
- `X模型`：体现出测试设计、测试回溯的过程，帮助有经验的测试人员在测试计划之外发现软件错误
- `前置模型`：前置模型将测试和开发紧密结合，反复交替第执行


# 5 测试用例
## 5.1 定义
测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括：

- 测试目标
- 测试环境
- 输入数据
- 预期结果
- 测试脚本

等，最终形成文档。

一个测试用例具有以下属性：

- 优先级次序
- 目标性
- 所属的范围
- 阶段性
- 状态性
- 时效性
- 所有者、日期等特性

## 5.2 测试用例的设计方法
分为有白盒和黑盒测试相对应的设计方法，比如，黑盒测试的用例设计可以采用：

- 等价类划分
- 因果图法
- 边值分析
- 用户界面测试
- 配置测试
- 安装选项验证

等，而白盒测试用例的设计方法如下：

- 采用逻辑覆盖等结构的测试用例设计方法
- 基于程序结构的域测试用例设计方法
- 根据对象状态或等待状态变化来设计测试用例
- 基于程序错误的变异来设计测试用例
- 基于代数运算符号测试的测试用例设计方法

## 5.3 测试用例设计误区
- 把测试用例设计等同于测试输入数据的设计：测试用例中输入数据的确定只是测试用例设计的一个子集，测试用例设计还包括如何根据测试需求、设计规格说明书等文档设计用例的执行策略、执行步骤、预期结构、组织管理形式等问题
- 测试用例设计得越详细越好：编写过于详细的测试用例会耗费大量的资源，必须分析被测试软件的特征，运用有效的测试用例设计手段，尽量使用较少的测试用例，同时满足合理的测试覆盖
- 追求测试用例设计“一步到位”：任何软件项目的开发过程都处于不断变化的过程中，在测试过程中可能发现设计测试用例时考虑不周的地方，需要完善，也有可能用户对软件功能提出新的需求变更，需要根据软件变化对测试用例进行调整
- 将多个测试用例混在一个用例中：一个测试用例包含许多内容很容易引起混淆，从而使得测试结果很难记录