如何做到测试场景不遗漏？
测试分析与设计
测试是一门精细的学科，新人同学很容易有的误区是认为做测试主要就是编写测试用例和执行测试用例，进阶能力是写自动化脚本或研发工具。而实际上，测试人员最难修炼的是测试分析能力，测试分析能力是衡量一位测试同学是否专业的分水岭。分析除了使用方法，还需要有对业务、经验、质量的深度理解。自动化或工具实际是对分析和设计结果的一种实现，分析和设计的有效会决定实现的效果。
分析与设计过程
测试分析要从业务需求最开始就要介入，流程覆盖业务整个生命周期。在做分析的过程要想清楚，整体后续的设计怎么做。
测试分析可总结为四步：
- 建模 - 输出业务/系统流程（分析：业务流程 - 系统流程）
- 设计 - 测试场景（设计：测试场景）
- 细分 - 测试用例/数据（设计：测试用例）
- 扩展 - 多类型测试（性能，安全，异常等等）（基于经验）
测试场景分析实施
测试场景和测试用例区别是什么？为什么先要设计测试场景？
上图也描述了，测试场景对应的是实际的业务场景，业务场景是业务流程中因不同的事件触发后的业务情景。比如银行取款的业务办理流程，会因为用户的身份（VIP与否）、取款金额（大额，小额）、卡内余额（足额取，不足额取）等诸多因素，导致最后取款的结果和过程分支产生不同。测试场景就是对这类事件触发时的业务情景在质量角度的描述。而测试用例是对测试场景在测试范围和测试点的详细覆盖。
第一步：根据业务的目标（价值）、类别、技术等输入，确定业务场景分析的范围。
业务分析就是需求分析的过程。这里不仅仅考虑需求的功能逻辑，还需要结合不同业务类型，根据历史业务经验沉淀和风险沉淀进行综合考虑。可以参考用下图进行前期梳理。
需求类型 | 资源&方法需求 | 必须覆盖点 |
|---|---|---|
主业务类需求 | ||
技改类需求 | ||
全链路 | ||
外部商家需求 | ||
大促&BU核心项目 |
第二步：业务流程梳理（业务场景）
将需求说明转化为业务流程，完成事件流（基本流+备选流）以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。
事件流： 同一事件不同的触发顺序和处理结果形成事件流，事件流分为基本流和备选流
- 基本流： 程序从开始执行直到成功结束所经过的最短路径。
- 备选流： 一个备选流可能从基本流开始，在特定条件下执行，然后重新加入基本流中；也可起源于另一个备选流，执行后加入基本流或终止用例。根结点的备选流要具备原子性。
基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流2和4）；也可能起源于另一个备选流（如备选流4），或者终止用例而不再重新加入到某个流（如备选流1和3）。
实例：
第三步：场景串联
通过第二步中拆解的场景，根据沉淀后的场景集，用组合，合并等方法梳理出所有的事件流。事件流必须100%覆盖所有的基本流+备选流组合。
例：
测试用例设计
测试用例的设计很多时候是测试数据设计的过程，根据事件流（基本流+备选流）、数据和根据不同的角色，进行用例覆盖。需要确保所有场景100%覆盖。
例：
非功能性设计扩展
测试用例在设计上除了考虑功能性质量属性，还需要对非功能性进行覆盖，推荐一个四字法进行设计。
- 多：针对测试用例进行大数据量覆盖测试
- 并：针对测试用例进行大数据量同时执行，验证并发下的测试结果
- 复：重复的参数对同一用例进行执行测试。验证幂等结果是否符合预期。
- 异：用非正常输入值进行用例测试。验证结果的正确性。
测试策略
策略其实考虑两个问题，过程和方法：“测什么”，“怎么测”。
- 你的测试对象是什么？
- 本次测试的目标是什么？
- 测试中重点、难点、风险是什么？
- 测试要覆盖的深度和广度
- 如何安排各种测试计划（先测什么，再测什么，时间资源安排）
- 如何准出（测试结果）
测试策略可参考模版&样例
1. 业务整体概述
1.1 业务背景
业务背景介绍若干字……
1.2 产品目标
产品目标介绍若干字……
1.3 架构目标
架构目标介绍若干字……
1.4 业务目标
业务目标介绍若干字……
2. 项目整体分析
2.1 功能性需求拆解
核心业务模块介绍，复杂度，测试点分析对应列表（此步骤为关键分析步骤）。测试分析功能点，要从产品质量标准的角度思考，针对质量特性进行功能点覆盖。
名称 | 说明 | 使用场景 |
|---|---|---|
需求名称1 | 需求说明1 | 使用场景1 |
需求名称2 | 需求说明2 | 使用场景2 |
2.2 测试覆盖范围（涉及针对哪些质量要求的测试方法）
功能性、性能效率、兼容性、易用性、可靠性、安全性、易维护性、可移植性
PRD需求 | 优先级 | 质量特性 | 测试覆盖度评估（深度和广度） | 负责测试人员 |
|---|---|---|---|---|
需求1 | P1 | 功能性 | 59 | xxx |
需求1 | P0 | 功能性，性能效率 | 33 | xxxx |
需求1 | P2 | 安全性，功能性 | 11 | yyyy |
2.3 测试对设计方案覆盖范围（根据开发设计文档罗列）
序号 | 接口/设计名称 | 接口描述 | 对应产品码/功能描述 |
|---|---|---|---|
1 | com.xxx.api.getInfo | 拿到信息 | 用户获取信息 |
2 | com.xxx.api.getInfo | 拿到信息 | 用户获取信息 |
3. 业务流程分析
3.1 被测功能总体概述
介绍若干字……
3.2 整体业务流程
介绍若干字
3.3 业务模型图
介绍若干字
3.4 风险分析
介绍若干字
4. 测试场景覆盖范围
4.1 测试场景
根据上一步的业务或者系统流程图，完成测试用例场景的设计
4.2 测试用例设计（完善测试用例，补充测试数据）
根据测试场景细化测试用例，测试用例必须对测试场景和测试覆盖范围进行100%的覆盖
4.3 测试数据要求
介绍若干
4.4 其他测试补充
介绍若干
5. 测试执行计划
这部分信息通常也会放在最前面。
5.1 人员组织
包括哪些人参与，测试边界等
5.2 测试实施计划
包括提测时间，联调时间等
5.3 交付计划
主要是里程碑和大的时间点
测试报告
测试报告
测试报告实际就是一个质量评估的过程。内容的关键在于表达清晰两点：报告的对象是谁？报告的内容是什么？测试报告不是一个项目整体结束之后的产物，而是应该在项目整个生命周期随时同步的。
测试报告至少需要包括的信息：
- 项目背景信息
- 项目人员
- 测试覆盖度（需求、功能性、非功能性）
- 测试过程分析（执行情况）
- 缺陷分析
- 质量目标是否达到
- 遗留风险以及应对措施
- To Be Continued -