diff --git a/.DS_Store b/.DS_Store
index d6f7925d3dc71334773cbf73508839ab1382c98b..f164f471049cc4843ce648fc54f74f0a1c69533f 100644
Binary files a/.DS_Store and b/.DS_Store differ
diff --git a/README.md b/README.md
index 9815ab97f61ba71890f5a9830760ec4b175eccfd..7edbc23d33a9045d730d88e372d8101ea489c5f0 100644
--- a/README.md
+++ b/README.md
@@ -1,10 +1,14 @@
+
+
# 软件测试
+
## 写在最前面
### 1 课程目标
* 掌握基础的软件测试理论、测试方法和策略
-* 掌握常用工具使用
-* 根据需求和设计文档独立编写测试计划、测试方案、测试用例以及测试报告
+* 掌握常用工具的使用方法
+* 根据需求和设计文档，独立编写测试计划、测试方案、测试用例以及测试报告
### 2 主要内容
+* 软件测试概论
* 软件测试基础知识
* 软件测试通用技术
* 软件测试流程
@@ -17,7 +21,7 @@
学时安排：72课时（理论36+实践36）
教材：清华大学出版社 《软件测试》(第2版) 周元哲 编著
### 4 课程资源
-* 课程内容文档 [gitee课程地址](https://gitee.com/XiaFuXiangFei/software-testing)
+* 课程内容文档 [gitee 课程地址](https://gitee.com/XiaFuXiangFei/software-testing)
* 课程思维导图
* 测试相关文档模板
* 测试工具：[禅道](http://zentao.zrise.top/)
@@ -29,12 +33,12 @@
**软件 ≠ 程序（代码）**
软件包含如下内容：
1. 运行时，能够提供所要求功能和性能的指令或计算机程序。
-2. 程序能够处理信息的数据结构
-3. 描述程序功能需求、程序如何操作和如何使用所要求的文档
+2. 程序能够处理信息的数据结构。
+3. 用于描述程序功能需求、程序如何操作和如何使用的文档。
#### 1.1.2 文档
##### 开发文档
-开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑程序间相互关系、数据格式和存储等。
+开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述、程序逻辑、程序间相互关系、数据格式和存储等。
* 《可行性研究》
* 《项目任务书》
@@ -46,7 +50,7 @@
* 《开发计划》
##### 管理文档
-从管理的角度规定涉及软件生存的信息:
+从管理的角度规定涉及软件生存的信息：
1. 职责定义
2. 开发过程的每个阶段的进度和进度变更的记录
3. 软件变更情况的记录
@@ -60,7 +64,7 @@
* 《实施方案》
##### 产品文档
-为使用和运行软件产品的任何人规定培训和参考信息,促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员维护它。
+为使用和运行软件产品的任何人规定培训和参考信息，促进软件产品的市场流通或提高可接受性。使得那些未参加开发本软件的程序员维护它。
* 《产品手册》
* 《用户指南》
@@ -68,117 +72,171 @@
* 《软件支持手册》
#### 1.1.3 软件发展史
-1. 程序设计阶段：个体化生产，专用软件，规模小功能单一，开发者即使用者。软件 = 程序
+1. 程序设计阶段：个体化生产、专用软件、规模小、功能单一、开发者即使用者。（软件 = 程序）
2. 程序系统阶段：多用户人机交互，实时系统和数据库管理系统。
-3. 软件工程阶段：以软件的产品化，系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
-4. 多层分布结构，面向服务架构
+3. 软件工程阶段：以软件的产品化、系列化、工程化和标准化为特征的软件产业发展起来，软件开发有了可以遵循的软件工程化的设计准则、方法和标准。
+4. 多层分布结构，面向服务架构。
#### 1.1.4 软件项目
软件项目是一种特殊的项目，具有如下特点：
1. 知识密集型，技术含量高
2. 涉及多个专业领域，多种技术综合应用
-3. 项目范围和目标的灵活性
+3. 项目范围广和目标的灵活性高
4. 风险大，收益大
5. 客户化程度高
6. 过程管理重要
### 1.2 软件生命周期
-1. 需求定义
-**描述：** 定义出本次任务都需要做什么，做成什么样子
-**参与者：** 产品经理，需求分析，客户
-2. 可行性分析
-**描述：** 由项目组相关成员去研究需求是否可行，能不能做出来
-**参与者：** 产品经理，架构师，项目经理，开发
-3. 需求分析
-**描述：** 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个框每个按钮的样式，输入输出等各项值
-**参与者：** 产品经理，架构师，项目经理，测试/质量管理员(很多公司把这个统称为QA)，开发
+#### 1.2.1 需求定义
+**描述：** 定义出本次任务都需要做什么，做成什么样子。
+
+**参与者：** 产品经理、需求分析师、客户
+
+#### 1.2.2 可行性分析
+**描述：** 由项目组相关成员去研究需求是否可行，能不能做出来。
+
+**参与者：** 产品经理、架构师、项目经理、开发人员
+
+#### 1.2.3 需求分析
+**描述：** 需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个输入框、每个按钮的样式，输入输出等各项值。
+
+**参与者：** 产品经理、架构师、项目经理、测试人员/质量管理员(很多公司把这个统称为QA)、开发人员
+
**输出：**《需求规格说明书》
-4. 评审
-**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与
-**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等
-5. 设计
-**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口参数、参数等。此处设计会形成概要设计文档和详细设计文档
-**参与者：** 项目经理，架构师，开发，测试
-6. 编码
-**描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现
+
+#### 1.2.4 评审
+**描述：** 评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与。
+
+**参与者：** 每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试人员、开发人员一起评审；系统设计一般是项目经理、开发人员评审；测试策略评审一般是测试组内部评审等等
+
+#### 1.2.5 设计
+**描述：** 架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此基础上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口、参数等。此处设计会形成概要设计文档和详细设计文档。
+
+**参与者：** 项目经理、架构师、开发人员、测试人员
+
+#### 1.2.6 编码
+**描述：** 开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现。
+
**参与者：** 开发
-7. 提测
-**描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具任务流方式向测试部门通知xxx模块/功能可以测试
-**参与者：** 任务责任人(开发)、测试
-8. 测试
- - 测试需求
- - 测试计划
- - 测试设计
- - 测试执行
- - 回归测试
- - 测试评估
-9. 部署/发版
-**描述：** 经过前面的各个阶段，产品已经可以出售或者面见大众了；配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。
-**参与人：** 配置管理人员，测试
-10. 支持维护
+
+#### 1.2.7 提测
+**描述：** 开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具的任务流方式向测试部门通知xxx模块/功能可以测试。
+
+**参与者：** 任务责任人（开发）、测试人员
+
+#### 1.2.8 测试
+ - 测试需求
+ - 测试计划
+ - 测试设计
+ - 测试执行
+ - 回归测试
+ - 测试评估
+#### 1.2.9 部署/发版
+
+**描述：** 经过前面的各个阶段，产品已经可以出售或者面向大众了。配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。
+
+**参与人：** 配置管理人员、测试人员
+
+#### 1.2.10 支持维护
+
**描述：** 支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。
+
**参与人：** 支持维护人员/售后工程师
### 1.3 软件测试概述
#### 1.3.1 软件测试定义
软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
-
-IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别
+IEEE:使用人工或自动手段来运行或测定某个软件系统的过程，其目的在于检测他是否满足规定的需求或弄清预期结果和实际结果的差别。
#### 1.3.2 测试发展历程
1. 1957年之前－调试为主(Debugging Oriented)
-软件规模小，复杂度低，开发人员承担需求分析，设计，开发，测试等所有工作，等同于调试。
+
+ 软件规模小，复杂度低，开发人员承担需求分析、设计、开发、测试等所有工作，等同于调试。
+
2. 1957–1978－证明为主(Demonstration Oriented)
-与调试区分开，这是软件测试史上一个重要的里程碑，主要目是确认软件是满足需求的。
+
+ 与调试区分开，这是软件测试史上一个重要的里程碑，主要目的是确认软件是满足需求的。
+
3. 1979–1982－破坏为主(Destruction Oriented)
-1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：
+
+ 1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：
+
```
The process of executing a program with the intent of finding errors.
测试是为发现错误而执行程序的过程。
```
-这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。
+
+这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。
+
4. 1983–1987－评估为主(Evaluation Oriented)
-软件行业进入了大发展时期，软件趋向大型化、到复杂度，质量越来越重要。软件测试的基础理论和实用技术开始形成。提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。
+
+ 软件行业进入了大发展时期，软件趋向大型化、复杂化，质量越来越重要。软件测试的基础理论和实用技术开始形成。提出了在软件生命周期中使用分析、评审、测试来评估产品的理论。
+
5. 1988–至今－预防为主(Prevention Oriented)
-尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。
+
+ 尽量早地介入并发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。
#### 1.3.3 测试与开发的关系
-##### 瀑布模型
+**瀑布模型**
+
这是一种经典模型,提供了软件开发的基本框架。
+
强调开发工作（计划、设计、开发、测试、维护等）各阶段之间的先后顺序，不可以并行操作。
-瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前。如果需求和设计上存在缺陷，就会造成大量返工，增加成本。为了更早的发现问题，测试应延伸到需求评审，设计审查活动中，软件生命周期的每个阶段都应包含测试。
-**优点:**
+
+瀑布模型认为，测试是指代码完成后，处于运行维护阶段之前。如果需求和设计上存在缺陷，就会造成大量返工，增加成本。
+
+为了更早的发现问题，测试应延伸需求评审，设计审查活动中，软件生命周期的每个阶段都应包含测试。
+
+**优点:**
+
1. 各阶段划分清晰
2. 强调计划与需求分析
3. 适合需求稳定的产品开发
-**缺点:**
+**缺点:**
+
1. 单一流程，不可逆
2. 风险显露得晚，纠正机会少
3. 测试只是其中一个阶段，缺乏全过程测试思想
-##### V模型
+
+**V模型**
+
强调将测试和开发同等重要，对于开发阶段都有与之对应的测试阶段。
-**优点：**
-相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。
-**缺点：**
-虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析，系统设计的验证，时间效率上也大打折扣。
-##### W模型(双V模型)
+
+**优点：**
+
+相对于瀑布模型，V模型测试能够尽早的进入到开发阶段。
+
+**缺点：**
+
+虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析、系统设计的验证，时间效率上也大打折扣。
+
+**W模型(双V模型)**
+
-明确表示出了测试与开发的并行关系
+明确表示出了测试与开发的并行关系。
+
**优点：**
-W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。
+
+W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。
+
**缺点：**
-W 模型是顺序性的，不可逆，需求的变更和调整，依旧不方便。
-##### 螺旋模型
+
+W 模型是顺序性的、不可逆的，需求的变更和调整，依旧不方便。
+
+**螺旋模型**
+
大型软件项目通常有很多不确定性和风险，如果采用瀑布式线性过程模型，失败风险很大，因此需要采取一种渐进式的演化过程模型。将产品分解成增量版本，每个版本单独测试。
-##### 敏捷模型
+
+**敏捷模型**
+
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。专注于交付对客户有价值的软件（可以工作的)。
@@ -203,39 +261,45 @@ W 模型是顺序性的，不可逆，需求的变更和调整，依旧不方便
**解读：**
-* 个体和互动高于流程和工具
-以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。
-在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
+* 个体和互动高于流程和工具
+
+ 以人为本，没有比面对面交流更高效的沟通渠道了，基于互相信任的前提，敏捷提倡自治的全功能团队。
+
+ 在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色(能力)，团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
+
+* 工作的软件高于详尽的文档
+
+ 为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
+
+* 客户合作高于合同谈判
-* 工作的软件高于详尽的文档
-为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
+ 主动拥抱变化，及时响应，持续交付。
-* 客户合作高于合同谈判
-主动拥抱变化，及时响应，持续交付。
+* 响应变化高于遵循计划
-* 响应变化高于遵循计划
-通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费
+ 通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费。
**缺点:**
+
由于其项目周期很长，所以很难保证开发的人员不更换，而缺少文档就会造成在交接的过程中出现很大的困难。
### 1.4 软件缺陷
#### 1.4.1 缺陷定义
-IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
+IEEE729-1983 (电气和电子工程师协会标准IEEE) 对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
-符合下面4个条件之一就是缺陷
-1. 软件未达到规格说明书中规定的功能
-2. 软件出现了产品说明数中指明的不会出现的错误
-3. 软件功能超出了产品说明书中指明的范围
+符合下面4个条件之一就是缺陷：
+1. 软件未达到规格说明书中规定的功能。
+2. 软件出现了产品说明书中指明的不会出现的错误。
+3. 软件功能超出了产品说明书中指明的范围。
4. 软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
#### 1.4.2 产生原因
-1. 软件本身复杂性，产生大量不确定因素
+1. 软件本身复杂性，产生大量不确定因素。
2. 成本、时间限制，导致流程不够完善，文档缺失，缺乏严谨的评审。
-3. 人员本身技能水平，责任心，交流沟通不顺畅
-4. 不全面或者没有复审
+3. 人员本身技能水平、责任心、交流沟通不顺畅。
+4. 不全面或者没有复审。
#### 1.4.3 缺陷来源
| 缺陷来源 | 描述 |
@@ -250,14 +314,15 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| 缺陷类型 | 描述 |
| -------- | ------------------------------------------------ |
| 功能 | 未达到规格说明书中规定的功能，影响系统使用 |
- | 用户界面 | 为按照原型设计，影响交互，如：显示格式，按钮位置 |
+ | 用户界面 | 未按照原型设计，影响交互，如：显示格式，按钮位置 |
| 文档 | 文档内容不完整或不正确，影响发布和维护 |
| 软件包 | 由于软件配置库、变更管理或版本控制引发的错误 |
- | 性能 | 执行时间，处理速度，负载等方面 |
+ | 性能 | 执行时间长、处理速度慢、负载高等方面 |
| 接口 | 与其他模块参数不匹配 |
#### 1.4.5 缺陷级别
**严重性：** 表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
+
**优先级：** 表示修复缺陷的重要程度和紧迫程度。
##### 严重性
@@ -267,7 +332,7 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| S2 | 严重缺陷 | 系统出现重大问题，影响提供的主要功能使用 | 内存泄露
数据无法保存 |
| S3 | 主要错误 | 主要功能实现有问题，易用性不够好 | 某个非核心功能全部或者部分未实现、实现后流程走不通、实现的功能与需求不同、文本框未校验或者校验不全、提示不全（异常提示不合理或者没提示）、手册相关内容缺失、兼容问题、安装界面乱码 |
| S4 | 次要错误 | 次要功能实现有问题或者手册相关问题 | 个别不常用的属性不生效或实现有问题（前提：不影响主要功能使用）
次要功能实现与需求不符或实现有问题（如：日志不能轮转、预警策略不生效、搜索框不能用、快照生成格式有问题等）
错别字
手册描述不合理或样式格式有问题 |
-| S5 | 轻微缺陷 | 建议，不属于缺陷 |
+| S5 | 轻微缺陷 | 建议，不属于缺陷 | |
##### 优先级
@@ -278,7 +343,7 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| P3 | 高 | 影响整个测试的继续进行，要马上修改 |
| P4 | 急 | 系统无法继续执行下去，必须立即修改 |
-严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，有简到难。
+严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，由简到难。
综合使用重要性等级和严重性双标准的优先顺序:
@@ -291,12 +356,12 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
#### 1.4.6 跟踪流程
最优化、最简单的生命周期是：（理想情况）
-1. 测试员发现缺陷并记录缺陷报告
-2. 缺陷报告交给程序员,此时缺陷状态是打开（open state）
-3. 程序员修改缺陷,此时缺陷状态是解决（resolved state）
-4. 缺陷报告交还测试员
-5. 测试员确认已修复
-6. 测试员关闭缺陷报告，此时缺陷状态是关闭（closed state）
+1. 测试员发现缺陷并记录缺陷报告。
+2. 缺陷报告交给程序员，此时缺陷状态是打开。（open state）
+3. 程序员修改缺陷，此时缺陷状态是解决。（resolved state）
+4. 缺陷报告交还测试员。
+5. 测试员确认已修复。
+6. 测试员关闭缺陷报告，此时缺陷状态是关闭。（closed state）
一个缺陷很可能会被反复打开→关闭。在日常工作过程中，由于开发修订其他缺陷影响、需求变更等因素缺陷可能会被反复打开→关闭。
@@ -318,20 +383,22 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
3. bug严重级别，优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素。
4. bug产生的模块：记录bug所属模块，方便开发定位问题。
5. bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题。
-6. bug描述：bug的产生环境、详细步骤，期望结果、实际结果。
+6. bug描述：bug的产生环境、详细步骤、期望结果、实际结果。
7. 附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。
-以上是上报bug（创建）bug必须的，在后续我们还会对bug进行修复、复测等工作，那在为了记录后续工作，bug还应该包含：
-8. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。
-9. bug修订人：bug修订人员。
-10. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
-11. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。
-12. bug复测说明：由复测人员来写，说明复测过程，复测结果等。
-13. bug备注：备注，以便记录一些额外信息。
+
+以上是上报bug、创建bug必须要做的，在后续我们还会对bug进行修复、复测等工作，那么为了记录后续工作，bug还应该包含：
+
+1. bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。
+2. bug修订人：bug修订人员。
+3. bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。
+4. bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。
+5. bug复测说明：由复测人员来写，说明复测过程，复测结果等。
+6. bug备注：备注，以便记录一些额外信息。
#### 1.4.8 缺陷预防
-差错：人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误。（产生根源）
-错误：软件内部问题，设计错误、编码错误。（内部原因）
-失效：软件系统运行时偏离了用户需求。（外部表现）
+**差错：**人在理解和解决问题的思维和行为过程中出现的问题，沟通不当，理解错误。（产生根源）
+**错误：**软件内部问题，设计错误、编码错误。（内部原因）
+**失效：**软件系统运行时偏离了用户需求。（外部表现）
### 1.5 软件测试行业
#### 1.5.1 行业现状
@@ -339,40 +406,40 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
我国软件测试行业起步较晚，发展较慢，直到21世纪初期，我国才逐步开始重视软件测试行业。但近年来，软件行业的快速发展为软件测试行业的发展提供了良好的基础，随着我国软件测试行业的发展，行业内企业向规模化发展将获得规模效应，可以有效降低企业的单位成本;而软件测试技术的不断发展，也将淘汰那些技术实力较弱的企业，促使行业内企业向专业化方向发展。
-在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量1。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。
+在软件业较发达的国家，软件测试产业已形成规模，比较发达，软件测试不仅早已成为软件开发的一个重要组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。在微软公司内部，软件测试人员与软件开发人员的比例一般为1.5∶1到2.5∶1左右，即一个开发人员背后，有至少两位测试人员在工作，以保证软件产品的质量。国外优秀的软件开发机构把40%的工作花在软件测试上，软件测试费用占软件开发总费用的30%至50%，对于一些要求高可靠性、高安全性的软件，测试费用甚至相当于整个软件项目开发所有费用的3至5倍。
-从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单的测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”;于是，软件产品在没有经过严格测试的情况下就发布了;对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象;定制的行业软件，常出现一再返工、无限期的修改和维护的现象。
+从国内软件公司软件测试部门的独立性来看，多数软件企业没有专门的测试技术部门，软件测试程序也不太规范，多数企业也不懂测试，对测试的投入资金过少。大多数是在经过简单地测试之后，就认为是没有问题了，就交于用户了，让用户去“测试”。于是，软件产品在没有经过严格测试的情况下就发布了。对国内消费类软件而言，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的现象。定制的行业软件，常出现一再返工、无限期的修改和维护的现象。
当前国内软件测试行业主要存在以下问题：
-1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题;
-2. 面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步;
-3. 对于分布式系统整体性能还难以进行很好的测试;
-4. 对于实时系统缺乏有效的测试手段;
-5. 随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性的难题;
-6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员也缺乏较好的结合;
-7. 缺乏软件测试意识、对其重视不够;
-8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准;
+1. 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。
+2. 面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。
+3. 对于分布式系统整体性能还难以进行很好的测试。
+4. 对于实时系统缺乏有效的测试手段。
+5. 随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性的难题。
+6. 测试的自动化程度不高，手工测试过多，自动化测试工具和手工测试人员也缺乏较好的结合。
+7. 缺乏软件测试意识、对其重视不够。
+8. 在软件开发基本完成后才进行测试，也缺乏软件测试的统一标准。
9. 高校从师资储备到专业设置再到人才培养的机制薄弱。
国内外软件测试差距
-1. 测试的理解认识
-2. 测试过程的管理
-3. 测试工具的使用
-4. 测试人员的培养
-
-#### 1.5.3 未来趋势
-1. 以软件为代表的计算机行业正在以一种井喷式的发展趋势
-2. 人才缺口大
-3. 女性员工受到青睐
-4. 未来发展空间大
-5. 外包为主
-
-#### 1.5.2 软件测试职业发展
+1. 测试的理解认识；
+2. 测试过程的管理；
+3. 测试工具的使用；
+4. 测试人员的培养。
+
+#### 1.5.2 未来趋势
+1. 以软件为代表的计算机行业正在以一种井喷式的趋势发展；
+2. 人才缺口大；
+3. 女性员工受到青睐；
+4. 未来发展空间大；
+5. 外包为主。
+
+#### 1.5.3 软件测试职业发展
1. 技术方向
- 敏捷测试专家
- 高级测试开发专家
- 专项测试专家
- - QAOps专家
+ - QA-Ops 专家
2. 管理方向
- 测试组长
- 测试经理
@@ -382,7 +449,7 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
- 项目经理
- 产品经理
-#### 1.5.3 测试思维方式
+#### 1.5.4 测试思维方式
1. 逆向思维方式
2. 组合思维方式
3. 全局思维方式
@@ -391,52 +458,62 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
6. 发散思维方式
### 1.6 测试认识的误区
-1. 使用了测试工具，就进行了有效的测试
-2. 存在太多无法测试的东西
-3. 软件开发完成后才进行测试
-4. 软件发布后发现质量问题，是测试人员的问题
-5. 软件测试很简单,就是点点点,是个人就能做
-6. 软件测试是测试人员的事情和程序员无关
-7. 项目进度吃紧时少做测试，时间多时多做测试
-8. 测试要进行穷尽测试
-9. 采样是随机抽取过程
-10. 测试和开发是对头
-11. 测试少报bug开发就会高兴点，报告也会好看点
-12. 自动化测试终会取代手工测试
-13. 规范化软件测试是增加项目成本
-14. 越多测试越有效
-15. 软件测试工作只负责项目上线/产品发布之前的部分
+1. 使用了测试工具，就是进行了有效的测试；
+2. 存在太多无法测试的东西；
+3. 软件开发完成后才进行测试；
+4. 软件发布后发现质量问题，是测试人员的问题；
+5. 软件测试很简单，就是点点点，是个人就能做；
+6. 软件测试没有前途，只有程序员才是软件高手；
+7. 软件测试是测试人员的事情和程序员无关；
+8. 项目进度吃紧时少做测试，时间多时多做测试；
+9. 测试要进行穷尽测试；
+10. 采样是随机抽取过程；
+11. 测试和开发是对头；
+12. 测试少报bug开发就会高兴点，报告也会好看点；
+13. 自动化测试终会取代手工测试；
+14. 规范化软件测试是增加项目成本；
+15. 越多测试越有效；
+16. 软件测试工作只负责项目上线/产品发布之前的部分。
### 1.7 知识点总结
## 第2章 软件测试基础知识
### 2.1 概述
1. 从软件测试的目的来理解
-软件的目的是发现软件中的错误，是为了证明软件有错，而不是无错。是在软件投入运行前，对软件需求分析、设计和编码各个阶段产品的最终检查，是为了保证软件开发产品的正确性、完整性和一致性。
-2. 从软件测试的性质来理解
-在软件开发过程中，分析、设计和编码都是“建设性的”，唯有测试是“破坏性的”
-3. 从软件开发角度来理解
-软件测试以检查产品的内容和功能特性为核心，是软件质量保证的关键步骤，也是成功实现软件开发目标的重要保障
+
+ 软件的目的是发现软件中的错误，是为了证明软件有错，而不是无错。是在软件投入运行前，对软件需求分析、设计和编码各个阶段产品的最终检查，是为了保证软件开发产品的正确性、完整性和一致性。
+
+2. 从软件测试的性质来理解
+
+ 在软件开发过程中，分析、设计和编码都是“建设性的”，唯有测试是“破坏性的”。
+
+3. 从软件开发角度来理解
+
+ 软件测试以检查产品的内容和功能特性为核心，是软件质量保证的关键步骤，也是成功实现软件开发目标的重要保障。
+
4. 从软件工程角度来理解
-软件测试是软件工程的一部分，是软件工程过程中的重要阶段
+
+ 软件测试是软件工程的一部分，是软件工程过程中的重要阶段。
+
5. 从软件质量保证角度来理解
-软件测试是软件质量保证的重要措施
+
+ 软件测试是软件质量保证的重要措施。
### 2.2 测试的目的和原则
#### 2.2.1 测试的目的
-1. 测试不仅仅是找出错误，通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进
-2. 检测产品是否符合用户要求
-3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法
-4. 提升用户体验
+1. 测试不仅仅是找出错误。通过分析错误产生的原因和错误的发展趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便即时改进。
+2. 检测产品是否符合用户要求。
+3. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
+4. 提升用户体验。
#### 2.2.2 测试的原则
-1. 软件测试是证伪而非证真
-2. 尽早地、不断地进行测试
-3. 重视无效数据和非预期的测试
-4. 应当对每一个测试结果做全面的检查
-5. 测试现场保护和资料归档
-6. 程序员应避免检查自己的程序
-7. 充分注意测试中的集群现象
-8. 用例要定期评审，适时补充修改用例
+1. 软件测试是证伪而非证实。
+2. 尽早地、不断地进行测试。
+3. 重视无效数据和非预期的测试。
+4. 应当对每一个测试结果做全面的检查。
+5. 测试现场保护和资料归档。
+6. 程序员应避免检查自己的程序。
+7. 充分注意测试中的集群现象。
+8. 用例要定期评审，适时补充修改用例。
### 2.3 测试分类
#### 2.3.1 按照测试阶段划分
@@ -447,12 +524,12 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
5. 验收测试
软件测试阶段对照表:
-|测试阶段|主要依据|参与人员/测试方式|主要测试内容|
-|----|----|----|----|
-|单元测试|《详细设计》|开发小组执行白盒测试|规范、逻辑、路径|
-|集成测试|《概要设计》
《需求文档》|开发小组执行白盒测试、黑盒测试|接口、路径、功能、性能|
-|系统测试|《需求文档》|独立测试小组执行黑盒测试|功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试|
-|验收测试|《需求文档》|用户执行黑盒测试|同上|
+| 测试阶段 | 主要依据 | 参与人员/测试方式 | 主要测试内容 |
+| -------- | ---------------------------- | ------------------------------ | ---------------------------------------------------------------------------------- |
+| 单元测试 | 《详细设计》 | 开发小组执行白盒测试 | 规范、逻辑、路径 |
+| 集成测试 | 《概要设计》
《需求文档》 | 开发小组执行白盒测试、黑盒测试 | 接口、路径、功能、性能 |
+| 系统测试 | 《需求文档》 | 独立测试小组执行黑盒测试 | 功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试 |
+| 验收测试 | 《需求文档》 | 用户执行黑盒测试 | 同上 |
#### 2.3.2 按照执行状态划分
1. 静态测试
@@ -500,11 +577,11 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
**术语**
1. 测试编号：测试用例的编号
2. 测试项：测试的功能点说明
-3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345已定是注册过的
+3. 前置条件：该测试用例的前提条件，比如测试wangdachui／dachui12345（用户名／密码）账户是否能正确登录进去，那前提wangdachui／dachui12345一定是注册过的
4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果
5. 期望结果：就是希望得到的结果（正确的结果）
6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）；
-7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应
+7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（记录缺陷），bug需要与测试用例对应
8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试
9. 备注：做一些备注或者测试的说明
10. 合法用户：就是已经注册过的用户
@@ -597,7 +674,9 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
3. 设计一个新的测试用例，使其只覆盖一个无效等价类，重复这一步直到所有无效等价类均被覆盖。
#### 3.2.3 等价类举例
我们要测试学习成绩这一输入框（假设总成绩都是100），那么我们就可以如下图划分，有效的成绩是>=0且<=100的，无效的是<0和>100这两部分。
+
+
另外图中还有一个无效等价类没有表现出来--非数字字符（比如：英文字母、中文、特殊的符号等单一或者组合，如a、abc、你好、你abc、你=我、\你\a\等;以及他们分别与数字组合,比如：a123、321a、你123、12你、1你2、1\2、1=你等）。
那么根据上述分析，最终设计出来的测试用例如下：
@@ -608,7 +687,9 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
5. 无效等价类4：空字符
**等价类最终必须是分割到最小单位，只有这样才能保障测试覆盖全面。**
+
非数字字符可以是包含英文字符、中文、特殊符号的字符串或者字符，所以其实它又可以分为三个无效等价类，分别是：
+
1. 无效等价类：包含英文字符的字符串，比如：a、a123、a=、b你a；
2. 无效等价类：包含中文的字符串，比如：你、你12、1你2、你=；
3. 无效等价类：包含特殊字符的字符串，比如：\ 。
@@ -632,11 +713,13 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
1. 一般边界值分析
对于含有n个变量的程序，取值为min、min+、normal，max-、max，测试用例数目为4*N+1。
+
2. 健壮性边界值分析
健壮性边界值测试是边界值分析的一种扩展。变量除了取min、min+、normal、max-、max 5个边界值外，还要考虑略超过最大值(max+)以及略小于最小值(min-)的取值。因此，对于含有n个变量的程序，健壮性边界值分析产生6*n+1个测试用例。
+
#### 3.3.3 应用举例
-延伸上节的例子来说明：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60，优秀的分数线是80。那么这个例子中的边界值数据是哪些呢：
+延伸上节的例子来说明：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60，优秀的分数线是80。那么这个例子中的边界值数据是哪些呢?
> 选取的边界值数据应该包括：
>
@@ -653,11 +736,11 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| 位置 | 上下左右里面一点
外面一点 | 按钮，四边内四点，外四点 |
#### 3.3.4 局限性
- 如果被测程序是多个独立变量的函数，这些变量受物理量的限制，则较适合采用边界值分析。这里的关键是 **“独立”的“物理量”** 。例如，Date是3个变量(年、月、日)的函数，对其采用边界分析测试用例，就会发现测试用例是不充分的，例如，没强调2月和闰年。其存在问题是因为没有考虑月份、日期和年变量之间存在的依赖关系。由于边界值分析假设变量是完全独立的，因此边界值分析测试用例是对物理量的边界独立导出变量极值，不考虑函数的性质，也不考虑变量的语义含义。
+如果被测程序是多个独立变量的函数，这些变量受物理量的限制，则较适合采用边界值分析。这里的关键是 **“独立”的“物理量”** 。例如，Date是3个变量(年、月、日)的函数，对其采用边界分析测试用例，就会发现测试用例是不充分的，例如，没强调2月和闰年。其存在问题是因为没有考虑月份、日期和年变量之间存在的依赖关系。由于边界值分析假设变量是完全独立的，因此边界值分析测试用例是对物理量的边界独立导出变量极值，不考虑函数的性质，也不考虑变量的语义含义。
边界值分析对布尔变量和逻辑变量没有多大意义。例如，布尔变量的极值是true和false，但是其余3个值不明确。
### 3.4 决策表
-等价类划分法和边界值分析法只是孤立地考虑各个输人数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行动之间的关系。
+等价类划分法和边界值分析法只是孤立地考虑各个输人数据的测试效果，没有考虑输入数据的组合及其相互制约关系，而决策表考虑了多种条件的组合情况。决策表又称为判定表，分析多种逻辑条件(if-else、switch-case等)与执行之间的关系。
决策表由4部分组成：
1. 条件桩：列出了问题的所有条件，通常认为列出的条件次序无关紧要。
@@ -762,6 +845,7 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
原因——结果图使用了简单的逻辑符号，以直线连接左右结点，左结点表示输入状态(原因)，右结点表示输出状态(结果)。
+
* “恒等”：若原因出现，则结果出现；若原因不出现，则结果不出现。
* “非”：若原因出现，则结果不出现；若原因不出现，则结果出现。
* “或”：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
@@ -771,6 +855,7 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
输入输出状态相互之间存在的某些依赖关系，称为约束。
+
* E(互斥)：原因不会同时成立，最多1个成立,可以都不成立
* I(包含)：原因中至少一个成立,不能同时为0
* O(唯一)：原因中有且只有一个成立
@@ -820,12 +905,14 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| TC5 | E、符、% | 3 | 提示L |
| TC6 | F、特、@ | G、殊、* | 提示L和M |
#### 3.5.4 优点和缺点
-优点:
+
+**优点：**
+
1. 考虑多个输入之间的相互组合、相互制约的关系
2. 指出需求规格说明书中存在的不完整性和二义性
3. 帮助测试人员按照一定的步骤高效的开发测试用例
-缺点:
+**缺点:**
1. 作为输入条件的原因和输出结果之间的因果关系，很难从规格说明书得到
2. 此方法得到的用例数量规模大
### 3.6 场景法
@@ -839,6 +926,7 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
#### 3.6.1 ATM取款流程图
+
#### 3.6.2 ATM取款场景设计
| 场景编号 | 流程 | 结果 |
| :------: | ---------------------------------------------------------------------------------------- | -------------------- |
@@ -851,7 +939,9 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| 7 | 插入合法的卡
输入正确的密码
ATM有现金
输入不合法的金额 | 提示错误，重新输入 |
| 8 | 插入合法的卡
输入正确的密码
ATM有现金
输入正确的金额
余额不足 | 提示错误，重新输入 |
| 9 | 插入合法的卡
输入正确的密码
ATM有现金
输入正确的金额
余额充足
ATM现金不足 | 提示错误，重新输入 |
+
#### 3.6.3 测试用例
+
| 用例ID | 场景/条件 | 卡片 | 密码 | ATM内金额 | 账户余额 | 输入金额 | 预期结果 |
| :----: | ------------------------------- | ------ | ------ | --------: | -------: | -------: | ------------------------ |
| TC1 | 场景1：成功提款 | 合法卡 | 123456 | 2000.00 | 5000.00 | 100 | 成功提款，账户余额400.00 |
@@ -862,9 +952,10 @@ IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是
| TC6 | 场景6：ATM无现金 | 合法卡 | 123456 | 0.00 | 5000.00 | n/a | 提款选项不可用，用例结束 |
| TC7 | 场景7：金额错误 | 合法卡 | 123456 | 2000.00 | 5000.00 | 20 | 提示错误，重新输入 |
| TC8 | 场景8：卡内余额不足 | 合法卡 | 123456 | 2000.00 | 5000.00 | 600 | 提示错误，重新输入 |
-| TC9 | 场景9:ATM现金不足 | 合法卡 | 123456 | 2000.00 | 5000.00 | 2500 | 提示错误，重新输入 |
+| TC9 | 场景9：ATM现金不足 | 合法卡 | 123456 | 2000.00 | 5000.00 | 2500 | 提示错误，重新输入 |
### 3.7 错误推测法
+
#### 3.7.1 概念
错误推测法是利用经验和直觉推测出出错的可能类型，列举出程序中所有可能的错误和容易发生错误情况的清单，根据清单设计测试用例。所谓凭经验，是指人们对过去所作测试结果的分析，对所揭示缺陷的规律性直觉的推测来发现缺陷。