一、为什么需要测试

1.1、软件的重要性

软件无处不在，为人们的生活带来了各种各样的便利，同时也承担着软件缺陷所带来的各种不良后果

什么是缺陷？

• 以客户为中心，遵循软件测试的规范、流程、标准和要求；
• 当且仅当规格说明书存在的并且正确，程序与规格说明书不匹配才叫错误；
• 当没有需求规格说明书时，判断标准最终由用户决定。

1.2、引起缺陷的原因

软件是由人设计和开发的，在这个过程中会引入各种各样的缺陷。

• 经验不足
• 粗心大意
• 理解偏差
• 技术限制等等

缺陷的特性

• 缺陷存在于软件开发的各个阶段
• 缺陷具有雪崩现象
• 发现缺陷越晚，修改成本越高
  因此，在软件开发的过程中，测试应该尽早介入

1.3、测试的角色

• 软件测试是软件开发过程中关键的质量保证活动之一。
• 对软件系统和文档进行严格的测试，可以减少软件系统在运行过程中的风险，保证软件质量
• 软件测试作为软件开发过程的一个重要组成部分，通过软件测试的过程中得到的数据和结果可以不断改进软件开发的过程和测试过程

1.4、测试的目的

• 验证软件的正确性
• 发现软件中的缺陷

二、软件测试的基本过程

2.1、软件开发模型

1）瀑布模型

如图所示是一个传统的瀑布模型，他将软件开发生命周期划分为问题的定义及规划，需求分析，程序设计，程序编码，软件测试和运行维护7个基本阶段，并且规定了他们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来说，他是一个软件开发框架，开发过程是通过一系列阶段顺序展开的，只有当一个开发阶段完成后，下一个开发阶段才会开始。

image.png

瀑布模型的缺点：
测试是软件开发过程中的一个阶段，测试被看作是对软件产品的最终检查，类似于制造业中将产品交付给客户之前的检查。

2）V模型

V模型是瀑布模型的变种，它体现的主要思想是：开发任务和测试任务是相互对等的活动且同等重要

在这种模型的测试过程中，首先，进行可行性研究需求定义，然后以书面的形式对需求进行描述，产生需求规格说明书。之后，开发人员根据需求规格说明书来对软件进行概要设计，测试人员根据需求规格说明书设计出系统测试用例。概要设计之后，开发人员根据概要设计对软件进行详细设计，测试人员根据概要设计设计出集成测试用例。详细设计之后，开发人员根据详细设计进行编码，测试人员根据详细设计设计出单元测试用例。编码完成之后，测试人员根据单元测试用例对设定的软件的测试单元进行测试，单元测试完成之后，进行集成测试，然后进行系统测试，最后进行验收测试

image.png

3）增量迭代模型

瀑布模型和V模型是顺序模型，这类模型的一个重要特点是模型中所描述的活动是顺序的。顺序模型成功使用的一个前提是软件系统具备完善明确的需求。但是随着软件开发的不断发展，由于用户需求不断变化，开发周期越来越短等原因，顺序模型越来越无法满足需要。人们很难在项目开始的时候就进行完善的需求分析和设计，这就导致在顺序模型中要不断的返工，对以前的需求、设计或编码进行修改。为了解决顺序模型的这些不足，出现了增量迭代模型。
常见的增量迭代模型包括螺旋模型、RUP和敏捷开发模型，我们重点介绍下螺旋模型和敏捷开发模型

• 螺旋模型
  螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。在每个迭代阶段构建原型是螺旋模型用来减小风险的途径。螺旋模型更适合大型的系统及的软件应用

螺旋模型中一个典型的迭代包括以下步骤：
（1）明确本次迭代的目标，备选方案以及应用备选方案的限制
（2）对备选方案进行评估，明确并解决存在的风险，建立模型
（3）当风险得到很好的评估与解决后，应用瀑布模型进行本次迭代的开发与测试
（4）对下一迭代进行计划和部署
（5）项目利益相关者对本次迭代的交付物进行评审，同时检查下一阶段的计划

螺旋模型的优点：
（1）可以在项目前期考虑对已经存在的软件进行重用
（2）在软件产品开发过程中考虑了软件质量目标
（3）关注于缺陷预防，并能够尽早地发现缺陷
（4）更好地控制项目活动的资源和相关成本
缺点：
（1）过分依赖风险评估，一旦在风险管理过程中出现偏差将造成重大损失
（2）过于灵活的开发过程不适合开发人员和客户之间有明确合同约定的情况
（3）该模型本身的文档化和推广需要大量的工作

image.png

• 敏捷开发模型

敏捷开发的价值观声明：
（1）个体和交互胜过过程和工具
（2）可以工作的软件胜过面面俱到的文档
（3）客户合作胜过合同谈判
（4）响应变化胜过循环计划

2.2、测试类型

测试人员必须掌握的4种测试类型：
1）功能测试（黑盒测试）
2）非功能测试（性能，安全，兼容，易用）
3）基于结构的测试（白盒测试）
4）与变更相关的测试（bug确认测试，回归测试）

1）功能测试

功能测试主要考虑的是软件的外部表现行为。功能测试通常采用黑盒测试设计技术设计功能测试用力，包括验证被测对象的各种输入输出行为。功能测的主要依据是对应的功能需求，其中详细描述了被测对象的行为，即必须完成的功能。

主要从以下几个方面考虑：

• 准确性
• 互操作性
• 容错性

2）非功能测试

非功能测试就是测试系统运行的表现如何，包括不限于性能测试，负载测试，压力测试等等。

通常从以下几个方面考虑：

• 兼容
• 安全
• 性能
• 易用
• 手机专项测试

3）结构测试

是通过分析组件或系统内部结构而进行的测试，一般是由开发人员或者开发经验丰富的测试人员执行

4）与变更相关的测试

在测试过程或者使用过程中，若发现软件的缺陷，开发人员需要修改缺陷，修改完需要测试人员对修改部分进行再测试，以确保修改是正确和有效的，这成为确认测试。确认测试的目的是重新执行上次失败的测试用例，以确定开发人员是否已成功地修改了缺陷。
当软件系统发生变更时，例如修复缺陷、系统计划的功能增强、系统使用环境的变化等，可能会影响到软件系统的其他没变更的区域，造成哪里出现新的缺陷，所以要对可能会受到影响的区域进行测试，称为回归测试。回归测试的目的时测试先前测试过并修改过的程序，确保更改没有给软件其他未改变的部分带来新的缺陷，或发现以前被屏蔽的缺陷。

主要从以下几个方面考虑：

• 确认测试
• 回归测试

回归测试的用例一般会执行很多次，并且相对稳定，同时回归测试一般会要求在较短的时间内完成，因此将回归测试自动化时很好的选择。

为了有效的开展回归测试，因此测试人员还需要确定回归范围：

1. 策略一、基于影响分析的回归
   （1）只重复测试计划中高优先级的测试用例（选用最多）
   （2）只针对系统的特定配置开展测试
   （3）只针对特定子系统或测试级别的测试
2. 策略二、完全回归
   费时费力，成本很高，一般时在版本上线之前做一次或者改动较大的版本上线前做一次；

三、测试设计技术

3.1 黑盒测试技术

黑盒测试技术主要包括：

• 等价类划分
• 边界值分析
• 判定表测试
• 状态转换测试

3.1.1 等价类划分

等价类划分法把被测对象的输入数据或输出数据根据他们的处理方式或反应划分成若干个等价类。等价类指的是根据说明，输入域或输出域的一个子域内的任何值都能使组件或系统产生相同的响应结果，即针对同一个等价类内的数据，北侧系统以相同的方式处理或具有相同反应。该技术从构建的等价类中选取典型的数据进行测试，这些测试数据称为等价类代表值。原则上每个等价类中只要选择一个代表制来设计测试用例，就能覆盖所有的等价类，但有时还得考虑不同等价类的组合情况。

练习题：
第一题：
某公司圣诞节奖金计算需求

工作年限(x)	奖金（月收入百分比）
0<=x<=3	0%
3<x<=5	50%
5<x<=8	75%
8<x	100%

第二题：
一个输入框，要求只能输入长度为3-8位的数字和字母组合

ps：等价类划分适仅用于有明确的条件和限制的情况下。

3.1.2 边界值分析

边界值分析指的是通过分析输入或输出的边界值并取值进行测试用例设计的一种黑盒测试技术。在软件开发过程中，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部，因此针对各种边界情况设计测试用例，可以测试出更多的错误。

通常边界值分析是作为对等价类划分的补充，这种情况下，其测试数据来自等价类的边界

边界值分析通常分析边界值和两个次边界值，因此要以最小步长在边界值的两个不同方向上取值

练习题：

3.1.3 判定表测试

在很多情况下，不仅要考虑测试的数据数据，还要对系统的业务逻辑进行测试验证，而这些逻辑往往又是比较复杂的。另外，当系统的输入参数不独立，参数间有复杂逻辑关系时，使用等价类划分和边界值分析就会变得比较困难。在这种情况下，可以考虑利用判定表技术来设计测试用例。

判定表是通过分析说明，识别出系统可能的条件和行为，并最终设计测试用例的技术。

判定表格式示例：

image.png

其中条件桩中的条件 1、条件 2 和条件 m，表示测试对象的各种输入条件。动作桩中的动作 1、动作 2和动作 n，表示测试对象根据不同输入条件的组合需要执行的操作；规则 1、规则 2 到 规则 x中的每一个规则定义了在一组条件的组合，只有同时满足了一组条件所定义的组合，才能说满足了某个规则；当满足了某个规则后，则测试对象执行与此规则所对应的动作序列，即动作 1，动作 2和动作 n的组合。

练习题：
下面通过在ATM机中取钱的例子来描述如何设计判定表。通过阅读说明得知：如果使用的银行卡是无效的，则ATM机拒绝此卡，不提供任何服务。如果使用的银行卡有效，ATM机会要求客户输入密码，如果客户输入了错误密码，并且客户还没有达到连续三次输入错误密码，则ATM会要求客户再次输入密码。但是如果客户已经连续三次输入错误密码，则ATM机将会吞食此卡（不退卡）。如果使用的银行卡有效，客户也输入了正确密码，ATM机要求客户输入所想要取款的金额，如果客户输入的金额大于ATM机内当前所拥有的金额，或客户输人的金额大于此客户银行账户上所存的金额，则ATM机会显示提示信息，告知客户输入的金额无效，要求客户重新输入金额。只有当客户输入的金额少于或等于ATM机内当前所拥有的金额，并且也少于或等于此客户银行账户上所存的金额，则输入的金额有效，ATM机如数输出金额。

分析上述描述，可能的条件包括如下几个。
C1:银行卡有效？
C2:正确输入了PIN?
C3:已经是第三次输入PIN?
C4:金额有效？(ATM机中有足够的钱，并且此账号中也存有足够的钱）
AMT机可能的反应（动作）包括如下几种。
A1:拒绝此卡。
A2:请求再一次输入PIN。
A3:吞卡。
A4:要求重新输入金额。
A5:ATM机输出要求的现金

image.png
image.png

检查初始判定表可以发现有的动作对应一个规则，而有的动作有多个规则可以对应。因此，需要对初始的决策表进行优化，将具有相同的动作并且条件项之间存在相似关系的规则进行合并，相关条件项置为“不关心”，用一表示。例如，观察规则9规则16,当条件C1为假的时候，无论条件C2、C3和C4取什么值，对应的动作都是A1,这就意味着规则9~规则16可以合并成一条新的规则（如表4-13中的新规则5)同样，可以合并表4-12中的规则1与3到表4-13内的新规则1,合并表4-12中的规则与4到表4-13内的新规则2,合并表4-12中的规则5与6到表4-13内的新规则3,合并表4-12中的规则7与8到表4-13内的新规则4。在考虑合并过程中，不仅要考虑条件的组合，还要考虑动作的一致性。对初始决策表（如表4-12所示）中不相干或者兄余的条件组合进行优化，得到优化之后的决策表，如表4-13所示。

优化判定表

image.png

基于决策表技术设计测试用例的目的是执行让人感兴趣的输入组合，主要是指可能发现问题的输入组合。除了原因和结果外，决策表中也可能包含中间结果。至少考虑为
每一列的规则设计一个测试用例，条件作为测试用例的输入，动作则是测试用例的预期输出。然而，决策表中的条件可能存在相互影响或者相互排斥，因此并不是所有的组合都是有效的。决策表中的条件/原因和动作/结果，通常以“是/Y”和“否/N”的方式出现。因在ATM的例子中有4个条件（从“银行卡是有效的”到“金额有效（ATM机中有足够的钱，并且账户中也有足够的钱）”）,理论上可以有16种可能的组合。但是，由于决策表中有些条件的取值，会影响其他条件，例如若银行卡是无效的，那么判断其他条件就不再有意义。另外，在优化的决策表内已经删除一些无法实现或不符合逻辑的条件组合，所以优化得到的决策表不一定是所有条件的完全组合

3.1.4 状态转换测试

状态转换图（简称状态图）通过描绘系统的“状态”及引起系统“状态转换”的“事件”，来表示系统的行为。此外状态转换图还指明了作为特定事件的结果，系统将做哪些“动作”（例如处理数据）。因此状态转换图提供了行为建模机制。在状态转换图中，每一个节点代表一个状态，至少有一个开始状态。其中双圈是终结状态，在状态转换图中终结状态不是必需的。从一个状态到另一状态（也可以是同一状态）的状态转换是用连接此状态的有向边来表示的，在有向边上同时标记引起此状态转换的事件，以及由此事件引发状态转换后的动作。标记如“事件/动作”，在标记中事件是必需的，但动作可有可无。

状态转换测试指的是所设计的测试用例用来执行有效和无效的状态转换的一种黑盒测试设计技术。在很多情况下，测试对象的输出和行为方式不仅受当前输人数据的影响，同时还和测试对象之前的状态有关。状态转换图是进行相关状态转换测试设计的基础。

例题：

3.2、白盒测试技术

• 条件覆盖
• 条件组合覆盖
• 路径覆盖等等
  了解即可

3.3 基于经验的测试技术

3.3.1 错误推测技术

3.3.2 探索性测试技术

3.4 测试用例实战

3.4.1测试技术选择

有些测试技术适合于特定的环境和测试级别，而有些则适用于所有的测试级别。测试设计技术的选择应该基于一个全盘的考虑来决定。下面的经验可以有效地帮助选合适的测试技术。
（1）正确实现系统的功能是最重要的。任何情况下都必须首先保证对测试对象的功能进行充分的验证。不管采用什么技术，所有测试用例的开发都包括确定测试对象的期望结果和行为。这样就可以保证每个测试用例对系统的功能进行了验证，也可以判断系统是否存在问题或系统的功能是否被正确实现。
（2）对每个测试对象只要有合适的输入或输出时，可以考虑应用等价类划分技术，至少可以划分成有效等价类和无效等价类。应用边界值分析来对等价类进行补充并设计测试用例。在执行这些测试用例的时候，使用相应的覆盖率测量工具来确认是否达到了要求的测试覆盖率。
（3）若不同的状态会影响测试对象的运行顺序，就需要应用状态转换测试。只有状态转换测试可验证不同状态、状态转换和相应的行为之间的关系。
（4）若给出了测试中必须考虑的输入数据之间的相互依赖关系，这些依赖关系就可以通过因果图或者决策表技术进行测试设计，相应的测试用例可以从决策表中导出。
（5）显示在用例图（Use Case Diagrams)中整个系统的使用场景往往作为系统测试或验收测试的测试用例设计基础
（6）在组件测试和集成测试中，黑盒测试技术应该包含覆盖率度量。没有执行到的测试对象部分，需要在白盒测试中进行特别的考虑。可以根据测试对象的重要程度和属
性，选择相应合适的白盒测试技术。
（7）考虑具有循环结构的覆盖率时，至少需要循环一次。对于系统的重要和敏感部分，必须应用相应的测试方法来验证
（8）不能忽视基于经验的测试用例。这是对系统化测试设计的有效补充，它能通过测试人员的经验来发现更多的问题。

这里需要强调如下几点。
（1）没有一种测试技术能够考虑和覆盖到测试的方方面面，因此测试过程中经常会采用不同测试技术的组合
（2）测试技术的选择以及测试执行的强度在很大程度上取决于失效时所造成的危害程度。

3.4.2 设计测试用例

四、测试执行

4.1 软件前后端数据交互

image.png

4.2 测试用例执行

4.3 测试结果检查

4.4 测试问题处理

五、测试管理

5.1 人员组织管理

5.2 流程规范管理

流程是保证整个团队高效运转的必要保障，也是提高软件质量的重要一环
下面我们介绍几种在工作中经常遇到的流程

5.2.1 软件开发流程

参考软件生命周期

5.2.2 测试工作流程

（1）产品人员设计完原型和文档后，召开需求评审会，参会人员有开发，测试，产品。需求评审后之后，会产生一个完善之后的原型和需求文档。
（2）测试组负责人需要依据需求文档，项目周期、项目特点、工具、人员安排制定测试计划。
（3）测试人员就开始写测试用例（需要有冒烟测试用例和普通的测试用例），在写用例过程中会产生一些疑问，要及时和产品人员确认清楚，并要求他们回归需求文档。（开发就开始概要设计和编码）。
（4）测试人员完成用例后，组织测试用例评审。参与人员有开发，测试，产品。
（5）等待开发提交测试版本，提交后优先执行冒烟测试。冒烟测试的结果，需要邮件周知相关人，开发，测试，产品，其中重要的是开发领导，测试领导和产品。冒烟不通过等待开发重新提交版本，冒烟通过了进入执行用例进行测试阶段。
（6）测试阶段会发现一些问题，比如需求定义不明确，业务逻辑有冲突，要和相关人员沟通并定义清晰，得到结论后必须要求产品人员更新文档。
（7）每个人负责的模块测试结束后，小组内部要进行交叉测试（此时会进行一些性能测试）。
（8）测试通过后提交产品验收。产品验收期间协助产品验收。
（9）产品验收完毕后，项目部署仿真环境。此时需要线上的账号，所以一般也是产品和业务人员验收为主，各个公司情况不同，有些会给测试人员分配账号，进行基本流程的测试（细节视公司情况而定）。
（10）仿真环境ok了，部署线上。
（11）有些公司从测试环境提交验收的时间点开始，会要求写一些操作手册之类的文档，一些测试的报告，比如bug统计，bug的覆盖

5.2.3 bug管理流程

image.png

5.2.4 生产发现bug应急处理流程

image.png

5.2.5 文档模板

5.2.5.1 测试用例

5.2.5.2 测试计划

5.2.5.3 测试报告

5.2.5.4 缺陷报告

5.3测试管理工具

常见的测试管理工具有如下几种：

• 禅道
• jira
• redmine
• tapd 等等

他们都可以对下列内容进行管理
用例
项目
需求
缺陷