软件测试学习 - 测试基础

此阶段学习完成后应具备的能力：

知道测试的主要工作内容

能够掌握常用用例设计方法及应用场景

能够使用缺陷管理工具对缺陷进行管理

能够对 web 项目功能进行实战

软件测试

定义：使用技术手段验证软件是否满足需求
目的：用最少的人力、物力、财力，找到软件中的问题并修复，从而降低商业风险

测试主流技能

功能测试（手工测试）：主要验证程序的功能是否符合需求
自动化测试：使用代码或工具代替人工验证项目功能
接口测试：针对模块与模块或系统与系统之间数据请求地址进行测试
性能测试：模拟多人使用软件，查找服务器缺陷

测试常用分类

按测试阶段划分

单元测试：又称白盒测试，针对程序源代码进行测试（开发）
集成测试：又称接口测试，主要针对模块与模块或系统与系统之间的接口进行验证
系统测试：针对软件全面进行验证（功能、兼容、文档）
验收测试：使用内侧、公测来实现
- 内侧：公司内部进行测试
- 公测：让玩家来进行测试

按代码可见度划分

黑盒测试：又称功能测试，看不见源代码，主要对程序功能进行测试
灰盒测试：又称接口测试，可以看见部分代码，主要对程序接口进行测试
白盒测试：又称单元测试，可以看见全部代码，主要对程序源代码进行测试

总结

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

扩展-测试策略

冒烟测试：大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性。
面试题：提测标准是什么 / 测试之前要怎么做？冒烟测试通过

模型

质量模型

质量模型提供测试设计的不同角度视野和验证方向

学习：针对任何软件或硬件，测试要覆盖的方面

重点关注：功能、兼容、性能、易用、安全

测试模型 - W 模型

W 模型简称 “双 V “ 模型，即以开发主导的一个 ” V “ 和以测试主导的另一个 ” V “ 构成

学习：软件开发流程、软件测试在开发流程中的作用

开发流程：需求分析、概要设计、详细设计、编码、集成、实施、交付

测试流程：单元测试、集成测试、系统测试、验收测试

优点
- 测试伴随整个产品开发周期，测试对象不仅是程序还有需求、设计文档
- 测试介入较早，及早发现问题，降低修复成本

缺点
- 实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计要求较高

总结
- 测试人员需要项目的功能、性能、兼容、易用、安全、可靠性、移植性来验证被测软件
- 重点：功能、性能、兼容、易用、安全

软件测试流程

需求分析

前置：阅读需求分析文档，记录不明确之处。
- 确定各部门对需求理解一致
- 站在不同角度对需求进行查漏补缺

计划编写
- 测什么：测试目标及范围
- 谁来测：人员进度安排
- 怎么测：测试策略、测试工具

用例设计

设计执行测试的文档
用例执行

执行测试的文档

缺陷管理

提交 -> 验证 -> 关闭

测试报告
- 测试目标
- 测试工程
- 缺陷统计
- 缺陷分析
- 测试总结

测试用例

用例：用户使用的案例

测试用例：是为测试项目而设计的执行文档

考虑点：质量模型（功能、性能、兼容、易用、安全）

测试用例的作用

防止漏测
实施测试的标准

用例设计编写格式

八大要素：
- 用例编号：项目 + 模块 + 编号
- 用例标题：预期结果 + 操作步骤
- 模块 / 项目：所属项目或模块
- 前置条件：要执行此条用例，有哪些前置操作
- 优先级：表示用例的重要程度或者影响力 P0 ~ P4 （ P0最高）
- 测试步骤：描述操作步骤
- 测试数据：操作的数据，没有的话可以为空
- 预期结果：期望达到的结果

示例：

规范用例标题：预期结果 + 测试点

用例标题作用：方便评审，方便执行

验证码测试用例：

为空

错误

过期

正确

如何设计用例

不同场景和需求，有不同的用例设计方法，需要学习用例的设计方法。

知识回顾

等价类划分法

在所有测试数据中，具有某种共同特征的数据集合进行划分。

用于解决穷举问题

设计用例步骤

明确需求
确定有效和无效等价类
提取数据编写测试用例

案例1

需求：验证 QQ 账号的合法性

要求：6 ~ 10 位自然数

明确需求
- 6 - 10 位自然数
确定有效和无效等价类
- 有效：8 位自然数
- 无效：
  - 4 位自然数
  - 8位非自然数
提取数据编写测试用例
- 有效数据：
  - 12345678
- 无效数据：
  - 1234
  - 1234567a
用例执行

提示：预期结果与实际结果不一致，为缺陷。

案例2

需求：验证某城市电话号码正确性

要求：

区号：空或者是三位数字

前缀码：非 “0” 且非 “1” 开头的三位数字

后缀码：四位数字

明确要求
- 区号：空或者是三位数字
- 前缀码：非 “0” 且非 “1” 开头的三位数字
- 后缀码：四位数字
确定有效和无效等价类
提取数据编写测试用例
技巧：
- 有效等价类数据覆盖组合
- 无效等价类数据不可组合
- 有效数据：
  - 区号：空前缀码：234 后缀码：1234
  - 区号：123 前缀码：234 后缀码：1234
- 无效数据：
  - 区号：1 前缀码：234 后缀码：1234
  - 区号：空前缀码：23 后缀码：1234
  - 区号：空前缀码：234 后缀码：123
  - 区号：a12 前缀码：234 后缀码：1234
  - 区号：空前缀码：23a 后缀码：1234
  - 区号：空前缀码：234 后缀码：123a
  - 区号：空前缀码：012 后缀码：1234
  - 区号：空前缀码：123 后缀码：1234

用例执行

提示：预期结果与实际结果不一致，为缺陷。

适用场景

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

边界值分析法

解决边界限制问题

说明

选取正好等于、刚好大于、刚好小于边界的值作为测试数据【最多设计 7 条用例】
- 上点：边界上的点（正好等于）
- 离点：距离上点最接近的点（刚好大于、刚好小于）
- 内点：范围内的点（区间范围内的数据）
示例：

设计用例步骤

明确需求
确定有效和无效等价类
确定边界范围值
提取数据编写测试用例

案例1

需求：通过边界值法验证标题长度的合法性

要求：标题长度大于 0 ，小于等于 30 个字符

明确需求
- 长度大于 0 个字符
- 长度小于等于 30 个字符
确定有效和无效等价类
- 有效：
  - 长度大于 0 小于 30 个字符
- 无效：
  - 长度等于 0 个字符
  - 长度大于 30 个字符
确定边界值范围
- 上点：0 30
- 离点：-1 1 29 31
- 内点：15
- 有效：
  - 1
  - 29
  - 30
- 无效
  - 0
  - 31
提取数据编写测试用例

案例2

需求：通过边界值法验证 QQ 号的合法性

要求：6 ~ 10 位自然数

明确需求
- 6 ~ 10 位自然数
确定有效和无效等价类
- 有效：
  - 大于等于 6 位自然数
  - 小于等于 10 位自然数
- 无效：
  - 小于 6 位自然数
  - 大于 10 位自然数
  - 非自然数
确定边界值范围
- 上点： 6 10
- 离点：5 7 9 11
- 内点：8
- 有效：
  - 6 位自然数
  - 7 位自然数
  - 8 位自然数
  - 9 位自然数
  - 10 位自然数
- 无效：
  - 5 位自然数
  - 11 位自然数
提取数据编写测试用例
优化
- 结论：7 个优化为 5 个点
- 上点：必选（不考虑区间开闭）
- 内点：必选（建议选择中间范围）
- 离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

适用场景

在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
典型代表：有边界范围的输入框类测试

提示：边界值可以覆盖等价类的长度，但是无法覆盖类型。所以在设计用例时，必须两者结合。

判定表法

解决多条件组合依赖测试点覆盖问题

引入

案例：验证 “若用户欠费或者关机，则不允许主被叫” 功能的测试
说明：
- 等价类边界值分析法主要关注单个输入类条件的测试。
- 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。

定义及组成部分

定义：是一种以表格形式表达多条件逻辑判断的工具
组成：
- 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
- 动作桩：列出问题中可能采取的操作，操作的顺序没有约束。
- 条件项：列出条件对应的取值，所有可能情况下的真假值。
- 动作项：列出条件项的、各种取值情况下应该采取的动作结构。
规则
- 判定表中贯穿条件项和动作项的一列就是一条规则
- 假设有 n 个条件，每个条件的取值有两个（0,1），全组合有 2 的 n 次方种规则

设计用例步骤

明确需求
画出判定表
- 列出条件桩和动作桩
- 填写条件项，对条件进行全组合
- 根据条件项的组合确定动作项
- 简化、合并想死规则（有相同的动作）
根据规则编写测试用例

案例1

订购单检查

如果订单大于 500 元，又未过期，则发出批准单和提货单

如果金额大于 500 元，但过期了，则不发批准单和提货单

如果金额小于等于 500 元，则无论是否过期都发出批准单和提货单

在过期情况下不论金额大小都需要发出通知单

明确需求
- 如果订单大于 500 元，又未过期，则发出批准单和提货单
- 如果金额大于 500 元，但过期了，则不发批准单和提货单
- 如果金额小于等于 500 元，则无论是否过期都发出批准单和提货单
- 在过期情况下不论金额大小都需要发出通知单

画出判定表
根据规则编写测试用例

案例2

文件修改规则：

输入的第一列字符必须是 A 或 B

第二列字符必须是一个数字

如果第一列字符不正确，则给出信息 L

如果第二列字符不正确，则给出信息 M

如果两列字符输入正确，则修改文件成功

明确需求
- 输入的第一列字符必须是 A 或 B
- 第二列字符必须是一个数字
- 如果第一列字符不正确，则给出信息 L
- 如果第二列字符不正确，则给出信息 M
- 如果两列字符输入正确，则修改文件成功
画出判定表
根据规则编写测试用例
适用场景
- 有多个输入条件，多个输出结果，输入条件之间有组合条件，输入条件和输出结果直接有依赖（制约）关系
- 判定表一般适用于条件组合数量较少的情况（比如 4 个条件以下）
  
  提示：如果碰到项目中多条件组合大于4 个相互依赖，可以使用 正交表和因果图来实现

场景法

场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。

主要用来解决项目业务场景测试点覆盖问题

扩展：流程图

使用标准图形和箭头来表达程序或业务的走向

提示：主要用来解决业务用例问题

流程图对测试人员有什么用？
- 能够看懂流程图，设计业务用例
- 当需求文档信息不全时，能够根据需求，梳理出流程
网页版工具：ProcessOn - 免费在线作图，思维导图，流程图，实时协作
Windows 工具：Visio

意义

用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

适用场景

根据实际的应用场景，来测试业务用力，可以使用场景法

案例1

ATM 机取款流程

测试用例

提示：一般将成功的业务线进行冒烟测试

扩展-错误推荐法

通过经验推测系统可能出现的问题

思想

根据经验列举出可能出现问题的清单，根据清单分析问题可能的原因，推测发现缺陷

适用场景

时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
时间宽裕通过该方法列出之前出现问题较多的模块再次测试

知识回顾

缺陷

软件在使用过程中存在的任何问题都叫软件的缺陷，简称 bug 。

判定标准

衡量是否为缺陷的标准

软件未实现需求（规格）说明书中明确要求的功能 - 少功能
软件出现了需求（规格）说明书中指明不应该出现的错误 - 功能错误
软件实现的功能超出需求（规格）说明书指明的范围 - 多功能
软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求 - 隐形功能错误
软件难以理解，不易使用，运行缓慢，用户体验不好 - 不易使用

产生原因

需求阶段 - 需求描述不易理解，有歧义，错误等。
设计阶段 - 设计文档存在错误或者缺陷
编码阶段 - 代码出现错误
运行阶段 - 软硬件系统本身故障导致软件缺陷

是软件就有缺陷。

生命周期

核心内容

描述缺陷使用

缺陷的标题 - 描述缺陷的核心问题
缺陷的预置条件 - 缺陷产生的前提
缺陷的复现步骤 - 复现缺陷的过程
缺陷的预期结果 - 希望得到的结果
缺陷的实际结果 - 实际得到的结果
缺陷的必要附件 - 图片、日志等信息（证据）

缺陷的必要附件可以为空

提交要素

通过缺陷管理工具与开发交流使用

缺陷类型

功能错误
界面（UI）错误
兼容性
数据
易用性
改进建议
架构

面试题：你如何区分前端 bug 和后端 bug ？

如果是界面或兼容性的错误为前端 bug

如果是功能错误区分前端和后端 bug ，需要抓包查看请求和响应

缺陷编写

缺陷报告示例

标题：操作数据描述 + 预期 + 实际
跟踪流程

面试题：发现 bug 后首先要怎么办？

确认 bug 可复现
注意事项
- 可复现 - 缺陷可以复现
- 唯一性 - 一个缺陷上报一个问题
- 规范性 - 符合公司或者项目要求
编写规范
- 准确 - 描述的信息是正确的
- 具体 - 有细节且是真实特定的
- 简洁易懂 - 描述简单容易理解
- 次序清晰 - 描述缺陷过程有条件，有先后顺序