规范的软件测试流程

测试环境搭建原则

搭建前

• 确定测试目的

  • 功能测试：不需要大量数据，需要覆盖率高，测试数据要求尽量真实
  • 性能测试：可能需要大量存量数据，或者与实际硬件环境尽可能相似的硬件配置

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

  • 选用合适的操作系统与软件平台
  • 了解符合测试软件运行的最低要求及用户使用的硬件配置
  • 连接用户常用软件，避免发生冲突
  • 产品化的测试需要考虑兼容性的方案

• 营造独立的测试环境

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

• 构建可复用的测试环境

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

搭建测试环境过程分析

• 环境搭建模式

  • 线下搭建：公司本地内

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

    • 测试环境配置（以 Java 为例）

      • 配置Java环境（下载 jdk 并配置环境变量）
      • 下载并安装中间件（Tomcat， jetty 及其他）
      • 安装数据库并导入初始化脚本
    • 测试项目导入
  • Docker 模式：构建属于自己 image；使用时一键 deploy 即可
  • 依赖第三方平台

环境建设思路

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

基础架构：

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

测试过程

最终输出：测试计划，测试用例，缺陷跟踪记录

过程划分：

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

在实际测试过程中，是可以重叠或者同时进行的

测试策划

1. 进行测试需求的分析
2. 确定需要测试的内容或质量特征
3. 明确测试的充分性要求
4. 提出测试的基本方法

测试策划的过程：

• 确定测试的资源和技术需求
• 进行风险分析和评估
• 根据上述分析结果制定测试计划
• 根据测试计划开展相应的测试控制活动

需求测试

好处：

• 测试工程师参与需求分析，对需求了解深刻，减少与开发人员的交互
• 早期确定测试用例的编写思路，为测试打好基础
• 可以获取易测的测试数据，为测试用例设计提供帮助
• 可以发现需求不合理的地方，降低测试成本

作用：

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

需求验证

审查需求文档：

• 对需求文档及相关模型进行仔细检查
• 在需求开发期间做非正式的评审

以需求依据编写测试用例

• 编写简单用户手册
• 起草简单易懂的用户手册，用以描述出所有用户可见的功能，并用它作为需求规格说明的参考，并辅助需求分析

确定合格标准：

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

测试策略

定义：是描述测试项目和测试任务之间的关系，用来说明要测什么，如何测，如何协调测试资源与测试时间等

测试策略是否高效，会对测试项目的进度产生很大的影响

侧重需求分析，评估风险，定义测试范围

• 确定测试方法，指定测试启动、停止、完成标准和条件

测试策略的要素（属于测试计划的一部分）：

1. 测试安排，发布计划：里程碑；明确的结束时间；规划优先级，保证核心功能
2. 测试范围：按优先级分类
3. 测试资源：分为人力和工具两部分
4. 测试环境：包括推荐环境解决方案，操作系统要求，软硬件要求
5. 测试方法：功能测试
6. 用例设计方法
7. 文档管理：包括安装，升级文档，用户指南；需要完整测试才能发布文档
8. 风险管理：来自技术，资源或者其他方面
9. 上线跟踪验证

测试计划

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

• 各阶段的任务以及时间进度安排
• 提出各项任务的风险评估与分析，可以包括测试策略

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

测试方案

侧重测试的方法，测试环境的规划

• 包括测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案

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

测试方案评审

忽略测试方案评审会导致的问题：

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

目的：

• 呈现测试的工作
• 与开发达成共识
• 不同的思维方式碰撞出火花，借鉴别人的思考方式
• 培养团队协作的能力
• 发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补

评审重点：

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