【软件测试从入门到放弃】熟悉阶段：软件测试流程

引言

本章讲解软件测试环境的搭建、测试过程、测试策略、测试计划、测试方案的编写与评审过程等，其中最为关键的是：测试环境的搭建，测试流程（包括：需求测试、测试计划）

一、测试环境

1.1 搭建测试环境前

1 确定测试目的

测试目的决定搭建的环境。功能测试、稳定性测试和性能测试，测试目的不同，搭建测试环境时应注意的点也不同。

1）功能测试：不需要大量的数据，需要覆盖率高，测试数据要求尽量真实。

2）性能测试：可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置

2 测试环境尽可能模拟真实环境

• 测试的软件环境尽可能的模拟真实环境；

• 尽可能的模拟用户使用环境，选用合适的操作系统和软件平台；

• 了解符合测试软件运行的最低要求及用户使用的硬件配置

• 了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间

• 产品化的测试则需要考虑兼容性的方案

3 营造独立的测试环境

• 不同的项目、不同的公司会对测试环境的独立性有不同的要求

• 测试过程中尽量保证测试环境独立，不会受到其他测试人员以及项目研发人员的影响

4 构建可复用的测试环境

• 通过备份或数据隔离的方式
• 重复运用一套测试环境进行多版本多时间段的测试

1.2 环境建设思路

1 搭建过程

• 线下搭建

• 独立测试服务器或虚拟机

• 测试环境配置

  Step1：配置Java环境（下载JDK并配置环境变量）

  Step2：下载并安装中间件（tomcat、jetty或其他）

  Step3：安装数据库并导入初始化脚本

• 测试项目导入

2 环境建设思路

1）考虑点：用途、使用成本、维护成本

2）基本架构

• 研发环境：用于研发自测、集成测试
• 测试环境：用于日常单系统或两两微服务之间测试，可同时集成自动化测试回归
• 联测环境：完备环境，用于大型联测
• 外联环境（如果有需求）：稳定版本环境，用于外部商户等联调
• 灰度/沙箱环境：用于生产数据测试，仿真测试

1.3 Docker模式

Docker类似于盒子，把想要的东西全部封装在一个盒子里，用的时候直接使用

如：装系统时，ISO镜像类比Docker下的image

二、测试过程

2.1 过程划分

1 流程图版本

2 模块化版本

策划：测试人员进行规划测试计划

设计：写测试用例

执行：执行用例

评估：评估执行结果

总结：

• 在逻辑上，测试活动是按顺序进行的

• 在实际测试过程中，这些活动是可以重叠或同时进行的

后续将主要讲解：测试策划里的各个小点

2.2 测试策划

1 测试策划构成

1）测试需求：进行测试需求的分析

2）测试计划：确定需要测试的内容或质量特征；明确测试的充分性要求

3）测试控制

可看作：需求分析测试阶段、测试方案、计划设定阶段

2 测试策划工作内容

1）确定测试的资源和技术需求

测试资源：人力、设备资源

2）进行风险分析与评估

测试风险：无法测试、其他风险（在测试规划时考虑）

3）根据上述分析结果制定测试计划

4）根据测试计划开展相应的测试控制活动

3 需求测试（测试需求）

1）测试人员加入需求分析

过往的软件生命周期中，需求分析阶段是没有测试人员参与的，但随着软件过程的优化，测试人员的加入对需求分析阶段有了更大的作用。

这些作用体现在：

• 测试工程师参与需求分析，对需求了解很深刻，减少与开发人员的交互，节省时间

• 早期确定测试用例的编写思路，为测试打好了基础

• 可以获取一些测试数据，为测试用例设计提供帮助

  向客户明确哪些需求更重要

• 可以发现需求不合理的地方，降低测试成本

  从测试人员角度发现需求不合理的，测试偏向用户的体验

2）对需求文档进行测试（重点）

需求分析后生成需求文档，测试人员可对需求文档进行测试。需求测试的作用有：

• 对需求文档进行测试可确定整个测试工作，明确测试对象以及测试工作的范围和作用，并作为测试覆盖的基础
• 需求测试时，被确定的测试需求项必须是可核实的，测试需求必须有一个可观察、可评测的结果
• 如果无法核实的需求就不是测试需求
• 需求分析测试包括与客户的交流以澄清某些混淆
• 需求测试可明确哪些需求更重要
• 需求测试可确保风险承担者尽早地对项目达成共识
• 使测试人员对将来产品有个清晰地认识
• 测试需求是制定测试计划的基本依据
• 测试需求是设计测试用例的指导
• 确定了要测什么、测哪些方面才能有效设计用例

3）需求验证

测试人员需要：

Step1：审查需求文档：对需求文档及相关模型进行仔细检查

Step2：以需求为依据编写测试用例，编写用户手册。在需求开发早期即可起草一份浅显易懂的用户手册，用以描述出所有对用户可见的功能并用它作为需求规格说明的参考并辅助需求分析。

Step3：确定合格的标准。让用户描述什么样的产品才算满足他们的要求和适合他们的使用，将确认合格的测试建立在使用情景描述或使用实例的基础之上。

4）实战：余额宝需求测试实战

材料：需求规格说明书

工作：基于需求规格说明书，生成需求规格说明书检查列表

示例：

4 测试计划

1） 测试前的思考：

• 系统哪些部分需要测试？哪些不要测试？
• 系统对性能有什么要求？
• 系统对安全性有什么要求？

2） 测试策略

定义：测试策略测试方案前的思考，测试计划的一部分。测试策略是描述测试项目和测试人物之间的关系，它用来说明要测什么，如何测，如何协调测试资源和测试时间等。测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。

测试策略要素各要素：

• 测试安排、发布计划：罗列测试项目本身重要的里程碑，每个里程碑都需要有明确的结束时间，这个时间可以指导我们后续的测试。如果测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试。这样可以最大限度的保证产品的质量。

• 测试范围（按优先级排序）：分为测试范围内（In Scope）和测试范围外（ Out Of Scope），需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的。
  对于在测试范围中的模块，需要给出优先级，以便相应测试时间不足的情况

  对于不在测试范围中的模块，需要给出原因

• 测试资源：测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分。
  人力资源主要说明参与测试的人员，当然可以包括很多的角色，如：专业测试人员、客户、产品经理等

  工具主要是指可能用到其他软件

• 测试环境：主要包括推荐环境解决方案，操作系统要求，软硬件要求；对于推荐解决方案，需要陈述的是对测试项目对其他软件的依赖，比如：测试项目对JAVA有依赖，推荐版本可能就是1.7

• 测试方法：主要为了说明针对测试项目，我们要开展哪些类型的测试。功能测试是必须的，非功能测试（自动化、性能等）是可选的。

• 文档管理：对于一个完整产品来说，文档是很重要的一环，它一般包括：安装、升级文档，用户指南等。文档不单单是一个文件，它需要经过完整的测试才能发布给客户；差的文档很可能会误导用户，从而使他们对测试项目是去信心

• 风险管理：需要罗列出来现在已知的可能会出现不确定性的因素，这些因素可能来自技术、资源或者其他方面的。

5 区别：测试策略、测试计划与测试方案

1）概念上区别

测试策略：侧重需求分析，评估风险，定义测试范围。结果：确定测试方法，制定测试启动、停止、完成标准和条件

测试计划：制定项目测试过程中的测试重点。结果：各个阶段的任务分配以及时间进度安排，并提出对各项任务的评估，风险分析，可以包括测试策略。

测试方案：偏向测试的实现，侧重测试的方法，测试环境的规划。结果：测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案

2）实际实施过程中区别

测试方案 = 测试计划 + 用例设计方案 + 工具选择 + 自动化/性能测试具体方案

测试计划 = 测试策略 + 测试任务分配 + 时间进度安排

排序：测试方案 > 测试计划 > 测试策略

3）具体示例

示例1：完整的测试方案

示例2：货币基金消费测试方案分析过程

1. 分析需求：当前测试包含需求项（需求文档或wiki链接等）

2. **测试计划（里程碑）**及负责人：整理当前项目各模块测试负责人、任务分配及测试时间安排

3. 测试范围、测试重点：那些point需要测试，重点放在什么地方，优先级安排

4. 测试策略及工具：是否需要进行自动化、性能、安全测试？使用哪些工具

5. 测试用例设计方法：使用什么样的黑盒测试方法进行设计（等价类？边界值？因果图？等等）

6. 测试环境：测试环境是什么？需要哪些服务器、数据库？配置如何等

7. 联调测试：是否需要与第三方或其它部门（例如：基金公司）联调？何时开展？联调包括哪些功能？

8. 测试限制：在测试环境中哪些内容无法测试？比如：消费到账

9. 测试风险：在测试或计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量。

6 测试方案评审

1）背景

目前，开发人员有需求说明会、设计评审会、代码复审会等各种会议，但多是站在开发人员的角度，从需求和代码层面进行复审和风险规避。

所以需要增加以测试人员为主的评审机制和沟通机制，即有了测试方案评审。若无以测试为主方案评审，容易造成以下几方面的问题：

• 仅从文档、沟通获取信息，可能会造成信息不对称，认识片面，理解错误或不深入等问题。
• 缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧，个人思维难以突破，可能会出现测试遗漏的情况。

2）评审目的

呈现测试的工作及如何开展；使测试与开发人员达成共识；使团队中不同的思维方式碰撞出火花，借鉴别的思考方式；培养出这样的模式：愿意为团队或他人出谋划策；发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补。

3）评审重点

• 采用的测试方法

• 等价类划分的依据

• 测试数据的选取和准备方法

• 流程测试的路径组合

• 数据对比选取的对象和数据检查点

• 是否需要模拟数据及模拟数据的方法

• 基于风险的测试取舍