App 测试流程指南

App 测试流程指南

一、前言

本指南旨在定义一个标准、高效的测试工作流程。遵循这个流程，我们可以系统地验证 App 的质量，确保新功能的稳定，并防止旧功能被破坏，最终为用户提供高质量的产品。

二、一个典型的测试周期

当开发同学交付一个新版本以供测试时，我们通常会遵循以下流程：

第1步：接收测试版本

• 从开发同学处获取测试包（.apk 或 .aab 文件）。
• 确认该版本包含的新功能、修复的 Bug 列表以及相关的需求文档。这是后续测试的主要依据。

第2步：执行冒烟测试

• 定义：这是测试开始前的“看门人”测试。它是对 App 最核心、最基础的功能进行一次快速验证，例如 App 能否正常安装和启动、能否登录、主界面是否能加载、核心页面能否进入等。
• 目标：确认这个版本是“可测的”，避免在一个有致命问题的版本上浪费大量时间。
• 产出：一个“通过 / 不通过”的结论。如果冒烟测试失败（例如启动就闪退），应立即打回给开发，无需继续测试。

第3步：主要测试阶段
如果冒烟测试通过，我们就进入正式的、详细的测试阶段。

• A. 新功能测试：

  • 定义：根据需求文档和测试用例，对本次版本中新增或修改的功能进行全面、细致的验证。
  • 方式：严格按照《测试用例规范》文档中编写的用例，逐一执行。
  • 建议流程：
    1. 先测单个功能：首先，专注于验证新功能本身是否能独立、正确地工作。
    2. 再测功能交互：然后，验证这个新功能与其他旧功能（或本次新增的其他新功能）交互时，数据和流程是否正常。
    3. 最后测整体场景：将新功能放到一个完整的用户使用场景中，从头到尾地验证整个流程是否顺畅。

• B. 回归测试：

  • 定义：在新代码加入后，重新测试已有的、未作修改的旧功能，以确保新代码没有意外地破坏它们。
  • 目标：保证产品的整体稳定性，防止“改了一个 Bug，引出三个新 Bug”的情况。
  • 方式：通常会有一组核心的“回归测试用例集”，覆盖所有主要功能的基本流程。

第4步：探索性与随机测试

• 定义：在完成所有预定用例后，测试人员可以像一个充满好奇心的真实用户一样，不受用例脚本的束缚，在 App 中进行自由探索。或者通过monkey工具机芯自动化“猴子测试”。它通过工具模拟大量无规则的随机操作，是检查 App 稳定性和发现意外闪退的有效补充手段。
• 目标：发现那些在结构化测试中容易被忽略的、隐藏较深的或在意外操作下才会出现的 Bug。

第5步：Bug 报告与验证

• 在以上所有测试阶段中，一旦发现问题，立即按照《Bug 提交指南》进行记录和提交。
• 当开发同学修复了 Bug 并发布新版本后，测试人员需要找到对应的 Bug 报告，并根据“重现路径”验证该 Bug 是否已被真正修复。

三、核心测试概念详解

为了更好地理解流程，以下是对几种主要测试类型的详细解释：

• 单元测试：对单个UI组件进行的、与业务逻辑分离的独立功能验证，如一个按钮能否正常点击，有无点击态，不可点击的情况下颜色是否变化等。
• 集成测试：将多个已经测试过的模块组合在一起，测试它们之间的接口、交互和数据流是否正确。例如：注册时点击注册按钮，会验证用户名、密码、验证码是否已经有内容。
• 系统测试：将整个 App 作为一个完整的系统，在接近真实的环境中，从最终用户的角度来验证它是否满足所有的产品需求。