软件测试（三）：软件测试流程

测试环境搭建前

需求

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

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

环境搭建原则

• 测试的软件环境尽可能模拟真实环境
• 了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间
• 产品化测试要考虑兼容性的问题
• 营造独立的测试环境
• 构建可复用的测试环境

测试环境搭建

环境搭建过程分析

线下搭建，独立测试服务器或虚拟机，测试环境配置，测试项目导入

测试环境配置

• 配置Java环境
• 下载并安装中间件
• 安装数据库并导入初始化脚本
• 依赖第三方平台

环境建设思路

考虑点：用途，使用成本，维护成本

基本架构：

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

测试过程

简单的测试过程

测试过程划分

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

测试策划

• 进行测试需求的分析
• 确定需要测试的内容或质量特征
• 明确测试的充分性要求
• 提出测试的基本方法
• 确定测试的资源和技术需求
• 进行风险分析与评估
• 根据上述分析结果制定测试计划
• 根据测试计划开展相应的测试控制活动

需求测试

需求分析

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

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

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

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

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

需求测试的作用

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

需求验证

• 审查需求文档
• 对需求文档及相关模型进行仔细检查
• 在需求开发期间所做的非正式评审也是有所裨益的
• 以需求为依据编写测试用例、编写用户手册

需求规格说明书检查列表

测试策略

测试策略是什么

测试策略是描述测试项目和测试任务之间的关系。它用来说明要测什么，如何测，如何协调测试资源和测试过程等。测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。

测试策略要素

• 测试安排、发布计划，罗列测试项目本身重要的里程碑，每个里程碑都需要有明确的结束时间
• 测试范围（按优先级排列），分为 In Scope 和 Out Of Scope ，需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
• 测试资源，分为 人力 和 工具 ，人力资源主要说明参与测试的人员，当然可以包括很多的角色，如专业测试人员、客户、产品经理等，工具主要是指可能用到其他软件
• 测试环境，主要包括 推荐环境解决方案，操作系统要求，软硬件要求
• 测试方法，测试方法的罗列主要是为了针对测试项目我们要开展哪些类型的测试。功能测试是必须的，非功能测试是可选的
• 文档管理，对于一个完整的产品来说，文档是很重要的一环，一般包括安装、升级文档，用户指南等
• 风险管理，风险管理模块需要罗列出来现在已知的可能会出现不确定性的因素，这些因素可能来自技术，资源或者其他方面的

测试策略：

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

测试计划

制定项目测试过程中的测试重点，

各个阶段的任务分配以及时间进度安排，

并提出对各项任务的评估，风险分析，可以包括测试策略。

测试方案

侧重测试的方法

测试环境的规划

测试工具的设计与选择

测试用例的设计方法

测试代码的代码方案

测试方案列表

测试策略 vs 测试计划 vs 测试方案

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

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

货币基金消费测试方案分析过程

1. 分析需求：当前测试包含需求项（需求文档或wiki链接等）
2. 测试计划（里程碑）及负责人：整理当前项目各模块测试负责人、任务分配及测试时间安排
3. 测试范围、测试重点：哪些point需要测试，重点放在什么地方，优先级安排
4. 测试策略及工具：是否需要进行自动化、性能、安全测试，使用哪些工具
5. 测试用例设计方法：使用什么样的黑盒测试方法进行设计
6. 测试环境：测试环境是什么，需要哪些服务器、数据库，配置如何等
7. 联调测试：是否需要与第三方或其他部门联调，何时开展，联调包括哪些功能，例如基金公司
8. 测试限制：在测试环境中哪些内容无法测试，比如消费到账
9. 测试风险：在测试或计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量

测试评审

评审简介

目前，开发有需求说明会、设计评审会、代码复审会等各种会议，但多是站在开发等角度，从需求和代码层面进行复审和风险规避，在测试环节和测试阶段缺少以测试为主体的评审机制和沟通机制。

容易造成以下几方面的问题：

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

评审目的

• 培养这样的行为模式：愿意为团队或他人出谋划策

• 发挥团队协作，最大限度发挥个人的经验、特长，实现技能互补

• 呈现测试的工作

• 与开发达成共识

• 不同的思维方式碰撞出火花，借鉴别人的思考方式

评审重点

• 采用的测试方法
• 等价类划分的依据
• 测试数据的选取和准备方法
• 流程测试的路径组合
• 数据比对选取的对象和数据检查点
• 是否需求模拟数据及模拟数据的方法
• 基于风险的测试取舍