测试开发新人手册：进阶篇

测试开发新人手册分为3部分。

1、基础篇 – 如何开始你的第一个测试项目

2、进阶篇 – 做专业的测试

3、思考篇 – 稳定性保障&测试技术创新

2. 进阶篇 – 做专业的测试

2.1 如何做到测试场景不遗漏？

2.1.1 测试分析与设计

测试是一门精细的学科，新人同学很容易有的误区是认为做测试主要就是写测试用例和执行，进阶能力是做自动化或工具。而实际上，测试人员最难修炼的能力是分析设计能力，测试分析能力是衡量一位测试同学是否专业的分水岭。分析除了使用方法，还需要有对业务、经验、质量的深度理解。自动化或工具实际是对分析和设计结果的一种实现，分析和设计的有效会决定实现的效果。

2.1.1.1 分析与设计过程

测试分析要从业务需求最开始就要介入，流程覆盖业务整个生命周期。在做分析的过程会思考清晰整体后续的设计怎么做。

测试分析可总结为四步：

2.1.1.2 测试场景分析实施

测试场景和测试用例区别是什么？为什么先要设计测试场景？

上图也描述了，测试场景对应的是实际的业务场景，业务场景是业务流程中因不同的事件触发后的业务情景。比如银行取款的业务办理流程，会因为用户的身份（VIP与否）、取款金额（大额，小额）、卡内余额（足额取，不足额取）等诸多因素，导致最后取款的结果和过程分支产生不同。测试场景就是对这类事件触发时的业务情景在质量角度的描述。而测试用例是对测试场景在测试范围和测试点的详细覆盖。

第一步:根据业务的目标（价值）、类别、技术等输入，确定业务场景分析的范围。

业务分析就是需求分析的过程。这里不仅仅考虑需求的功能逻辑，还需要结合不同业务类型，根据历史业务经验沉淀和风险沉淀进行综合考虑。可以参考用下图进行前期梳理。

第二步：业务流程梳理（业务场景）

将需求说明转化为业务流程，完成事件流（基本流+备选流）以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。

事件流：同一事件不同的触发顺序和处理结果形成事件流，事件流分为基本流和备选流

基本流：程序从开始执行直到成功结束所经过的最短路径。

备选流：一个备选流可能从基本流开始，在特定条件下执行，然后重新加入基本流中；也可起源于另一个备选流，执行后加入基本流或终止用例。根结点的备选流要具备原子性。

基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流2和4）；也可能起源于另一个备选流（如备选流4），或者终止用例而不再重新加入到某个流（如备选流1和3）。

实例：

第三步：场景串联

通过第二步中拆解的场景，根据沉淀后的场景集，用组合，合并等方法梳理出所有的事件流。事件流必须100%覆盖所有的基本流+备选流组合。

例：

2.1.1.3 测试用例设计

测试用例的设计很多时候是测试数据设计的过程，根据事件流（基本流+备选流）和数据，根据不同的角色。进行用例覆盖。需要确保所有场景100%覆盖。

例：

2.1.1.4 非功能性设计扩展

测试用例在设计上除了考虑功能性质量属性，还需要对非功能性进行覆盖，推荐一个四字法进行设计。

2.1.2 测试策略

策略其实考虑两个问题，过程和方法：“测什么“，“怎么测“。

2.1.2.2 测试策略可参考模版&样例

业务整体概述

#业务背景

#产品目标

#架构目标：

#业务目标

项目整体分析

#功能性需求拆解

##核心业务模块介绍，复杂度，测试点分析对应列表（此步骤为关键分析步骤）

测试分析功能点，要从产品质量标准的角度思考。针对质量特性进行功能点覆盖。

测试覆盖范围（涉及针对哪些质量要求的测试方式）：

功能性、性能效率、兼容性、易用性、可靠性、安全性、易维护性、可移植性

##测试对设计方案覆盖范围(根据开发设计文档罗列)

#业务流程分析

##被测功能总体概述

##整体业务流程：

##业务模型图：

##风险分析

测试场景覆盖范围

##测试场景

根据上一步的业务/系统流程图，完成测试场景的设计

##测试用例设计（完善测试用例，补充测试数据）

根据测试场景细化测试用例，测试用例必须对测试场景和测试覆盖范围进行100%覆盖。

##测试数据要求

##其他测试补充

测试执行计划

人员组织

测试实施计划

交付计划

2.1.4 测试 告

2.1.4.1 测试 告

测试 告实际就是一个质量评估的过程。内容的关键在于表达清晰两点： 告的对象是谁？ 告的内容是什么？测试 告不是一个项目整体结束之后的产物，而是应该在项目整个生命周期随时同步的。

测试 告至少需要包括的信息：

2.2 成为测试多面手

2.2 成为测试多面手

2.2.1 移动应用测试

2.2.1.1 移动应用分类&特点

Web App就是用H5开发的应用，在移动端浏览 站应用。优点是开发和发布成本低，直接服务端发布，迭代速度快；缺点是性能和体验比较差，加载速度慢。

传统的原生App开发模式，有Android和iOS两大系统，需要基于各自的平台，用特殊的开发语言开发对应的应用。

混合模式移动应用，介于Web App、Native App这两者之间的App开发技术，兼具“Native App良好交互体验的优势”和“Web App跨平台开发的优势”。

WEEX：Weex 致力于使开发者能基于通用跨平台的 Web 开发语言和开发经验，来构建 Android、iOS 和 Web 应用。简单来说，在集成了 WeexSDK 之后，你可以使用 JavaScript 语言和前端开发经验来开发移动应用。

小程序：小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。

手淘作为一个航母级App，集成了H5、WEEX、Native和小程序于一身，各司其职。

2.2.1.2 移动应用测试流程

静态测试包括需求分析、需求测试、需求建模；

测试计划包括测试范围、测试策略、执行计划；

测试设计包括功能测试以及其他测试类型的方案设计；

功能测试需要在迭代中改变测试重点和风险分析。

特别强调的是对于集团要求的稳定性压倒一切，务必进行稳定性测试、性能测试、安全测试和适配测试。

2.2.1.3 移动应用测试方法&工具&平台