---

1. 测试介绍

• 什么是软件测试？

  使用技术手段验证软件是否满足需求
  

• 测试主流技能
  1、功能测试
  2、自动化测试
  3、接口测试
  4、性能测试

• 主流方向建议：
  1、功能测试+接口测试
  2、自动化测试+接口
  3、功能+性能

2. 测试的分类

2.1 按照测试阶段划分（4种）

阶段	描述	对应角色
单元测试	针对程序源代码进行测试（单元：最小独立功能代码段）。	开发人员/白盒测试人员
集成测试	针对单元与单元之间的接口进行测试，又称接口测试。	开发人员/白盒测试人员/功能测试
系统测试	针对系统整体功能+兼容+文档，包括功能测试、性能测试、易用性测试，安全测试，兼容性测试等。	功能测试/专项测试人员
验收测试	内测 ： 公司内部人员来完成的测试 公测 ： 是由用户来完成的测试	公司人员/用户

2.2 按照代码可见度划分（3种）

代码可见度：代码可见的程度上划分

种类	描述	分布阶段
黑盒测试	将测试对象看成一个黑色的黑子 测试人员不需要关注盒子的内部，只需站在用户角度进行，所说的功能测试其实就是黑盒测试 。	系统测试
灰盒测试	将测试对象看成一个灰色的盒子 更多测试的是接口。	集成测试
白盒测试	将测试对象看成一个透明的盒子 测试人员需要查看程序的内部代码逻辑，然后对代码进行测试。	单元测试

2.3 是否运行代码（2种）

种类	描述
静态测试	对代码的语法、逻辑、规范进行测试 ，一般情况下是不运行代码的 ，主要使用场景就是代码评审(review)。 对文档进行测试 ，比如需求文档 ，用户手册 。
动态测试	对运行代码的测试 ，包括白盒测试 ，黑盒测试 、灰盒测试 。

2.4 是否按照自动化（2种）

种类	描述
手工测试	由人工来完成的测试 ，通过执行测试用例 ，操作被测软件 ，比对测试结果的一个过程 。
自动化测试	由代码来完成测试 ，通过代码驱动软件自动执行 ，自动操作 ，自动比对结果的一个过程 ，包括app自动化、web自动化和接口自动化 。

2.5 其它测试（4种）

种类	描述
冒烟测试	从已经编写好的测试用例中选取一部分具有代表性的测试用例作为冒烟测试用例。
随机测试(发散测试)	测试时对软件功能不受限制，对测试方法不受限制 ，对测试思维不受限制 。
探索式测试	有目的性和针对性的测试，强调的是一边探索、一边学习 、一边验证的过程 。
回归测试	主要是对功能或已经修复的bug进行的再次验证 ，主要确认修改后的功能/bug被真正的修改。

2.6 总结

• 系统测试和黑盒测试重点核心是功能测试
• 集成测试和灰盒测试又称接口测试
• 单元测试和白盒测试是对代码进行测试
• 自动化测试归属功能测试
• 性能测试、安全测试归属专项测试

3. 测试的模型（俩大模型）

3.1 软件质量模型（8种）

说明：质量模型能告诉我们，测试时应该考虑的方面

质量特性	测试类型
功能性	功能测试，安全测试
性能效率	性能测试
兼容性	兼容性测试
易用性	易用性测试
可靠性	可靠性测试、性能测试
信息安全	安全测试
可维护性	/
可移植性	兼容性测试、安装测试

重点：功能、性能、易用性、安全、兼容
结论：无论测试硬件或软件，都应该从以上几点来进行分类验证

3.2 软件开发模型（4种）

3.2.1 瀑布模型

• 包含阶段：需求分析-设计-编码-测试-维护
• 特点 ：
  • 线性开发
  • 产生大量文档 、文档依赖性强
  • 开发周期长
• 导致结果 ：
  • 需求 ： 适应性差
  • 质量 ： 不高
  • 要求 ： 对各个角色要求也不高 。
• 适用公司 ： 小型的项目性公司

3.2.2 V模型

• 包含阶段 ： 需求分析 - 概要设计 -详细设计 -编码 -单元测试 -集成测试 -系统测试 -验收测试
• 特点 ：
  • 线性开发
  • 产生大量文档 ，文档依赖性强
  • 开发周期长
  • 强化了设计和测试这两个环节
• 导致结果 ：
  • 质量 ： 有保障
  • 需求 ： 适应性差
  • 角色 ： 注重了设计和测试阶段 ，对于这两个岗位要求会更高
• 适用公司 ：大型企业 、比如银行 、电信

3.2.3 迭代模型

• 包含阶段 ： 需求分析 -设计 - 编码 - 测试 -上线
• 特点 ：
  • 线性开发
  • 文档轻量化
  • 开发周期短
  • 需求拆分上线
• 导致结果 ：
  • 需求 ： 适应性较高 ，快速的接受用户的反馈。
  • 质量 ： 一般
  • 角色 ： 更注重产品 、对技术整体上要求也比较高 。
• 适用公司 ： 互联网企业 。

3.2.4 敏捷开发

• 包含阶段 ： 用户故事 - 计划会 -迭代任务 (开发-测试-上线)
• 特点 ： 小步快跑、快速迭代
• 导致结果 ：
  • 需求 ： 适应性是最好的
  • 质量 ： 高
  • 角色 ： 注重整体 、对整个团队成员要求高 。
• 实用公司 ：大厂 。

3.2.5 开发模型比对

开发模型	开发过程	适用公司	开发周期
瀑布模型	将所有需求都完成以后才会进入到下一阶段，依次类推	小公司	长
V模型	将所有需求都完成以后才会进入到下一阶段，依次类推	外包	较长
迭代模型	将20个需求拆分成若干迭代，每次只做部分需求 ，依次进行迭代。	互联网企业	短
敏捷模型	以用户故事为单位进行拆分，依次迭代 。	大厂	较短

4. 测试流程（八大步骤）

主要包含事项	所处阶段	主导角色	主要工作
1.需求评审	需求分析阶段的尾声	产品经理主导，其它角色参与	理解需求。
2.编写测试计划	开发阶段的早期	测试经理主导，测试人员参与	输出计划并同步给团队。
3.编写测试用例以及评审	开发阶段的早、中、后期	测试人员	编写测试用例，参与用例评审。
4.搭建测试环境	开发结算的尾部	测试人员	搭建测试环境。
5.执行测试用例	测试阶段	测试人员	执行测试用例，提交bug。
6.缺陷管理	测试阶段	测试人员	发现bug，跟踪bug ，回归bug。
7.编写测试报告	测试阶段的尾部	测试人员	输出测试报告并同步给团队。
8.上线测试	上线	运维，测试，开发	上线测试。

5. 测试用例

5.1 用例概念

• 用例：用户使用的案例

• 生活中的用例：
  

• 用例的作用

  1、验证软件功能是否满足需求
  2、保证需求的覆盖率，从而提升测试覆盖率，减少问题漏测 。
  3、衡量测试的工作量

5.2 用例的八大要素

5.3 设计用例的流程

需求分析 - 提取测试点 - 设计测试用例 - 用例评审 -修改和完善测试用例

5.4 测试方法

5.4.1 等价类划分法—穷举场景

• 介绍：
  

等价类划分 ：

• 有效等价类 ：使得该功能能正常完成 ，有效等价类设计出来的用例叫正向用例 。
• 无效等价类 ：操作的功能无法完成 ，输入的数据是错误或者异常导致无法完成 。无效等价类设计出来的用例反向用例 。

如何使用等价类进行分类(设计测试用例)：

1. 先将输入数据划分成有效等价类和无效等价类 。
2. 对有效等价类继续细分 ，首先分析构成功能的元素 ，将这些元素列出来 。
3. 再对每个元素找对应的属性，要划分到原子层级 ，进行组合 ，去掉一些冗余和逻辑不成立的情况 ，最终正向用例。
4. 无效等价类是对有效等价类的条件取反，确保每个条件至少有一个反向用例 。

应用场景：

• 需要有大量数据测试输入，但是没法穷举测试的地方。
  输入框
  下拉列表
  单选复选框
• 典型代表：页面的输入框类测试。

5.4.2 边界值法—限定边界场景

说明：使用边界值解决边界位数限制问题。

边界值说明:

边界值法优化：

重点：

离点开内闭外（开区间选包含的点，闭区选不包含的点）。

上点，内点必选。

应用场景：

典型代表:有边界范围的输入框类测试

5.4.3 判定表法—多条件依赖场景

• 介绍：
  

提示：
1、多条件之间有依赖关系，使用判定表来进行测试覆盖。
2、判定表一般适合4个以内条件依赖关系
3、如果条件超过4个，就不适合覆盖所有条件，应采用（正交法）来解决。

5.4.4 错误推测法—项目尾声场景

• 概念 ： 主要基于自己的经验 ，直觉或自己的判断 ，来推测某个功能可能存在错误 。

输入数据 ：

• 默认值
• 不输入(空值)
• 输入较长/短的值 。
• 输入特殊字符 。
• 输入数据和业务相关的数据

应用场景：当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能。

5.4.5 场景法—项目业务场景

• 概念 ： 站在用户角度考虑 ，将几个功能组合起来构成用户具体的使用场景 ，可以理解为 ：功能组合 + 操作顺序 ，比如购物流程 。

基本流 ：考虑用户正常的操作流程 ，往往选取基本流都是用户高频操作的功能，满足用户某方面的价值需求 。

备选流： 在操作基本流路径上出现了错误或异常 ，它导致的结果是要么结束了流程 ，要么重新回到了基本流 。

说明 ：

• 对于一个系统来说 ，会存在很多的基本流 。
• 一旦确定了某条基本流 ，就开始考虑基本流中的备选流 。

5.4.6 测试方法总结

测试方法	使用场景	特点	使用关键
等价类划分法	针对穷举场景设计测试点	特别适合于颗粒度细	1.合理的划分 2.取数
边界值法	针对限定边界规则设计测试点	发现的bug几率是特别高的	确定范围，取边界上的值
判定表法	针对多条件依赖关系进行设计测试点
错误推测法	针对单功能设计测试用例的方法	更多的发现bug。	基于经验 ，直觉 ，判断
场景法	针对于项目业务进行设计测试点	执行次数会比较多 。	站在用户角度去考虑

6. 缺陷

6.1 缺陷的定义

• 软件缺陷 ，称为bug ，它是指程序在运行过程中出现的错误或异常，导致此功能不能满足用户需求 。

6.2 缺陷的分类

种类	描述
功能性缺陷	1.功能未实现或实现错误 2.页面数据显示错误 3.业务逻辑错误
性能性缺陷	1.响应时间太长 2.页面崩溃
易用性缺陷	1.页面体验不太好 2.使用起来不方便
安全性缺陷	1.数据被暴露 2.权限设置
兼容性缺陷	1.手机不兼容 2.屏幕不兼容 3.版本不兼容

6.3 缺陷的描述要素

字段	字段描述
缺陷id	系统自动生成 ，代表唯一性。
缺陷标题	描述产生的缺陷 ，主要给开发人员查看
模块	此缺陷所涉及的项目模块 。
缺陷的预置条件	产生缺陷的预置条件。
缺陷复现的步骤	使缺陷复现的操作步骤。
实际结果	实际的运行结果
预期结果	预期的运行结果

6.4 缺陷的提交元素

字段	字段描述
缺陷类型	功能缺陷，性能缺陷，易用性缺陷，安全缺陷，兼容性缺陷。
严重程度	产生缺陷后，它对系统的严重程度 。一般分为4个级别，包括P0，P1，P2,P3
优先级	缺陷被修改的优先级 ，修改的优先级有两个字段决定，首先修改严重程度高的 ，严重级别相同的，再选取优先级高的修改 。
指派人	产生的缺陷交给谁去解决。

7. 需求评审

7.1 定义

• 产品经理将已经设计好的需求文档(PRD)在需求评审会同步给团队成员，使得团队成员理解上保持一致，以便展开后续的工作 。

7.2 参与角色

• 产品经理
• 项目经理
• 开发人员
  • 前端开发
  • 后端开发
• 测试人员
• UI人员

7.3 目的

• 确保需求的完整性和准确性 ，
• 确保团队成员能对需求理解一致 。
• 给出各团队的实现周期 ，包括开发团队 ，测试团队 ，UI团队 。

8. 测试计划

8.1 目的

• 高指定性 ，减少因为没有去考虑而导致各种的问题 。
• 合理的安排资源(人力资源 ，时间资源、环境资源、工具资源、数据资源) ，从而减少测试浪费 。

8.2 测试计划的七大要素

• 测试目标 ： 要达成具体的质量目标 ，而且要将质量目标进行量化 。
• 测试范围 ： 我们要测试什么 ？ 本次迭代新增了哪些功能 ？ 影响了哪些模块 ？需要进行测试其它的类型 ？
• 测试策略 ： 我们要如何进行测试 ？ 在本次迭代中 ，如何安排测试时间以及测试资源 。
• 测试资源 ：是由谁来测试 ？ 所花费的时间 ，以及需要用到的测试环境 ，测试数据 ，测试方法等。
• 测试标准 ： 测试过程中，需要统一标准 ，比如 ： 准入准出标准 、设计测试用例的标准 。
• 测试风险和应对措施 ： 在测试过程中可能遇到那些风险 ？必须需求变更，开发提测不通过 。

9. 测试报告

9.1 定义

• 主要是提供测试过程，测试结果以及测试分析的一份文档，主要为后续产品质量提供依据 。一旦输出测试报告，就意味着测试阶段的结束 。

9.2 测试报告的五大要素

• 测试结果 ：一般情况就是测试通过或测试终止 。
• 测试依据 ： 给出测试准出的标准
• 测试过程的回顾 ：准备阶段的过程 ，执行结果的过程 。 比对差异 ，找出原因 ，从而找解决方案 。
• bug统计回顾 ：按照不同的维度进行统计 ，比如bug的激活率 ，bug的有效率 ，bug关闭率等
• 问题和建议 ：在测试过程中发现问题的总结 ，写出具体的解决方案 。