软件测试
什么是软件？
软件是计算机程序、程序所用的数据以及有关文档的集合。
软件 = 程序 + 数据 + 文档
软件测试就是利用人工或者测试工具按照测试方案和流程对软件进行的测试。
分类
执行阶段划分
单元测试 (执行者：开发人员) 基于代码测试(函数,模块)
集成测试 (执行者：开发人员) 基于代码测试(组装函数,组装模块)
系统测试 (执行者：测试人员) 结合软件、硬件、网络等其它元素。
验收测试 (执行者：主要以用户为主) 验证产品是否符合用户需求(Alpha 测试, Bate 测试)
是否运行程序划分
静态测试(不运行程序) 对文档和界面进行测试（审查、走查）
动态测试(运行程序) 输入数据检查实际结果是否和预期结果一致
是否查看代码划分
- 黑盒测试: 不关注内部逻辑，重点关注外部功能
- 灰盒测试: 关注内部逻辑的同时还关注外部功能
- 语句覆盖：
- 判断覆盖：
- 条件覆盖：
- 路径覆盖：
- 白盒测试: 重点关注内部逻辑（基于代码）
测试内容划分
- 功能测试: 验证系统的业务功能
- 界面测试: 验证系统的界面是否跟需求规格说明书的要求是否一致（原型图）
- 安全测试: 验证软件的安全性(XSS、CSRF 等)
- 兼容性测试: 验证系统在不同的运行环境是否正常
- 易用性测试: 检查系统各个功能是否操作方便、容易上手、容易理解
- 性能测试
- 压力测试
- 负载测试
- 恢复性测试: 当系统出错时，能否在指定的时间间隔内修正错误并重新启动
测试手段划分
- 人工测试
- 自动化测试: 通过代码或者自动化测试工具对被测系统进行测试
其它划分
- 回归测试: 开发修正发现的错误后，由测试人员再次测试
- 冒烟测试: 在正式测试之前，测试系统核心功能是否能走通
- 探索性测试: 根据测试思维和经验进行探索性测试
软件测试十大原则
- 测试应基于用户的需求
- 制定好软件测试策略是做好软件测试工作的关键
- 应尽早的开始软件测试并不断的进行软件测试
- 测试前必须明确定好产品的质量标准
- 避免测试自己的软件
- 应充分注意测试中的集群现象（二八原则）
- 穷举测试是不可能的
- 保留测试设计和说明文档，并注意测试设计的可重用性
- 杀虫剂现象
- 测试用例是设计出来的，不是写出来的
软件的生命周期
软件的生命周期是指软件产品从提出需求开始，经过开发、测试、交付使用、维护，直至被废弃的整个过程。 即需要经过 项目立项(问题的定位及规划)、需求分析、软件设计(概要设计和详细设计)、软件编码、软件测试、软件维护 等阶段。
详细说明
- 项目立项(问题的定位及规划)：主要是确定软件开发的目的，制定开发计划。
- 需求分析：在软件开发可行的前提下，对软件的功能、性能、接口、数据结构、运行环境等做出详细的需求分析，明确用户需求，输出需求规格说明书（SRS）以及原型图。
- 软件设计：把需求分析得到的结果设计成软件。分为概要设计和详细设计。
- 概要设计：对整个架构的设计，输出概要设计说明书（HLD）。
- 详细设计：深入分析，把要实现的功能全部描述出来，输出详细设计说明书（LLD）。
- 软件编码：根据系统设计进行程序编码。
- 软件测试：按照测试方案和流程对软件进行的测试。
- 软件维护：版本的升级改进。
- EOS（End of Service）：生命周期结束。
软件测试的工作流程
- 测试需求分析
- 测试计划（计划 + 方案）
- 测试设计（设计测试用例）
- 测试执行
- 质量评估
TIP
测试需求分析 与 测试计划 有时候会互换位置。
需求分析
对软件需求规格说明书(SRS)/原型图进行分析，量化测试内容，明确测试内容（输出测试点）。
什么是测试点
软件/模块/功能 的最小单元。
为什么需要需求分析
- 是设计测试用例的依据。
- 有助于保证测试的质量和进度。
- 测试覆盖率高
- bug 遗留率
影响测试覆盖率的因素
- 测试执行率越高越好
- 用例的覆盖率越高越好
- 测试点覆盖率越高越好
需求分析的工作流程
- 查阅/收集需求（需求规格说明书/原型图）
- 根据需求提取测试点
- 界面检查（错别字、字体大小、格式、位置、背景图）是否和原型图一致
- 按照顺序（上到下，左到右）分析字段
- 按照顺序（业务逻辑的先后顺序）验证按钮关联功能（条件 -> 按钮操作成功/失败 -> 验证关联功能的结果）
- 测试点评审
测试需求的特征
- 制定的测试需求项必须是可核实的。即它们必须有一个可观察、可评测的结果。
- 测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时出错的条件。
- 测试需求不涉及具体的测试数据，测试数据设计是测试设计阶段应解决的内容。
如果没有需求，怎么做分析？怎么找出测试点？
测试计划
安排什么人在什么时间完成什么事情，涉及到资源分配、开始和结束时间、存在风险。
测试设计-编写测试用例
根据测试点输出测试用例。
什么是测试用例？
测试用例是一次测试执行的最小单元。 是一份测试文档，它是描述输入、动作和一个期望结果的测试文档。
包含的要素：
- ✨ 用例编号：用例的唯一标识（模块_编号/编号）
- 系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
- 集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX
- 单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX
- 模块：一个项目存在多个模块，一个模块下存在多个功能
- 功能：一个功能存在一个或者多个测试用例
- ✨ 用例标题：描述测试的目的（条件+动作+预期结果）不重复
- ✨ 优先级（重要级别）：
- 高：核心流程的用例、冒烟用例
- 中：一般的流程、异常流程
- 低：界面、兼容性
- ✨ 预置条件：执行当前用例的前提条件（登录成功等）
- 可没有
- 如果没有预置条件，导致无法执行
- 如果没有预置条件，可执行测试用例，但无法得到明确的结果
- 输入：可以并入步骤
- ✨ 步骤：用例执行的详细步骤说明
- 路径：找到功能入口
- 输入什么数据：具体的数据
- 做什么样的操作
- ✨ 预期结果：根据操作步骤，参考需求为标准应该等到的结果
- 备注
5C 原则
- Clear: 描述清晰易懂，不要有歧义
- Correct：描述正确，不要有正确
- Concise：简洁的，不要太啰嗦
- Complete：完整的，不要有漏测
- Consistent：一致的，统一格式
问题
- 可以重复测试，冗余测试？
- 一个测试点就对应一条测试用例？
- 用例中的测试数据怎么来？
用例设计方法
等价类、边界值法、错误推断法、场景法、因果图、评定表法、正交实验法
✨ 等价类划分法
把所有的可能输入的数据分为 N 个子集，再在子集中选取最具有代表性的数据进行测试
TIP
等价类又可以分为有效等价类和无效等价类
等价类用例选取规则：
- 用最少的用例覆盖最多的有效等价类
- 用最多的用例一一覆盖无效等价类
✨ 边界值分析法
边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。 边界值分析的基本思想：正好等于、刚刚大于、刚刚小于边界的值作为测试数据
注意：0 是一个特殊值，我们在考虑边界值的时候同时也要考虑这个特殊值，以及负数。
边界值的作用：人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误！
✨ 场景法
通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑，设计用例遍历场景（路径），验证软件系统功能的正确性。
一般对项目业务流程功能用例设计，基于场景法进行设计
使用方法
画流程图：
- 矩形：表示步骤（操作、输入、输出结果）
- 菱形：判断条件(是 or 否)
- 箭头：下一个步骤
TIP
场景法重点是测试流程，因此每个流程只需要一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能点进行测试。
ATM 取款常见场景
flowchart TB
START[开始] --> INSERT_BANK_CARD[插入银行卡]
INSERT_BANK_CARD --> BANK_CARE_VERIFY{银行卡验证}
BANK_CARE_VERIFY -- Y --> 提示输入密码 --> USER_INPUT_PASSWORD_CANCEL[用户输入密码或者取消] --> CANCEL_INPUT_PASSWORD_JUDGE{取消输入?}
BANK_CARE_VERIFY -- N --> 提示银行卡不合法,退卡
CANCEL_INPUT_PASSWORD_JUDGE -- Y --> 退卡
CANCEL_INPUT_PASSWORD_JUDGE -- N --> PASSWORD_JUDGE{密码正确?}
PASSWORD_JUDGE -- Y --> TIP_INPUT_AMOUNT[提示输入金额] --> USER_INPUT_AMOUNT[用户输入金额] --> AMOUNT_JUDGE{金额合法?}
PASSWORD_JUDGE -- N --> PASSWORD_INPUT_ERROR_COUNT_JUDGE{出错 3 次?} -- Y --> 吞卡
PASSWORD_INPUT_ERROR_COUNT_JUDGE -- N --> 提示重新输入 --> USER_INPUT_PASSWORD_CANCEL
AMOUNT_JUDGE -- Y --> BALANCE_JUDGE{账户余额充足?}
AMOUNT_JUDGE -- N --> TIP_RE_INPUT_AMOUNT[提示重新输入金额] --> USER_INPUT_AMOUNT
BALANCE_JUDGE --> Y --> ATM_BALANCE_JUDGE{ATM 现金充足?} --> 取款成功
BALANCE_JUDGE -- N --> TIP_RE_INPUT_AMOUNT
ATM_BALANCE_JUDGE --> TIP_RE_INPUT_AMOUNT
✨ 错误推断法（反推法）
基于经验和直觉推测程序可能会存在的各种错误，从而有针对性的设计测试用例方法。
流程图法
因果图法
正交实验法
评定表
测试设计-用例评审
由测试人员主持，有产品经理产品、开发人员成员，评审用例是否覆盖所有的需要功能点，用例编写规范是否存在问题。
测试执行
根据用例执行测试，提交 Bug。
测试原则
- 所有的测试都应该有标准
- 测试数据在多数情况下无法穷举
- 二八原则
- 软件缺陷在软件的分布是不均匀的（80% 的 bug 分布在 20% 的代码中）
- 引起软件缺陷的原因有很多，80%的缺陷在代码照成的。
测试评估
根据测试执行结果判断测试结果是否符合预期。
软件质量
可靠性：最好不要有问题 容错性：最好可以自己恢复 易恢复性：
软件质量模型
Q & A
为什么要写测试用例？
- 测试用例是解决漏测的一个手段。
- 测试用例是提高测试效率的一个手段。
- 测试用例是评估软件质量的依据。
- 测试用例是工作安排、监控测试进度的依据。
- 测试用例是测试人员技能传承的载体。