4. 测试用例设计基础要素

测试执行，说白了就是把写好的用例跑起来，然后找到 Bug。但这里面的门道，远不止「点点点」那么简单。我个人习惯把这一阶段拆成四个步骤：搭环境、冒烟、执行策略、探索性测试。每一步都有坑，咱们一个一个说。

4.1 测试环境搭建：别让环境坑了你

我见过太多团队，花了两周写用例，结果环境搭了三天还没跑通。环境问题，往往是测试执行的第一道坎。

我的做法是：环境即代码。用 Docker Compose 或 Kubernetes 把环境定义成配置文件，一键拉起。这样能保证每次环境都一样。

# docker-compose.yml 示例
version: '3.8'
services:
  app:
    image: myapp:${TAG:-latest}
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=mysql
      - REDIS_HOST=redis
    depends_on:
      - mysql
      - redis
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: test123
      MYSQL_DATABASE: testdb
  redis:
    image: redis:7-alpine

嗯，这里要注意：环境变量里的密码不要写死，用 .env 文件管理。我曾经因为密码写死在代码里，结果被安全团队通报了。

4.2 冒烟测试：先确认「能不能跑」

冒烟测试，说白了就是「新版本来了，先看看能不能开机」。我建议把冒烟测试做成自动化，每次部署后自动跑一遍。

检查项	检查内容	通过标准
服务可用性	所有微服务是否正常启动	健康检查接口返回 200
核心流程	登录、注册、主页面加载	3 个核心用例全部通过
数据库连接	读写数据库是否正常	增删改查操作无异常
第三方依赖	支付、短信、推送等服务	Mock 或真实调用返回预期结果

4.3 用例执行策略：先跑什么，后跑什么

用例执行不是一股脑全跑。我习惯按优先级分层执行：

1. P0 用例（核心功能）：先跑，确保主流程没问题。比如电商的下单流程、支付的扣款逻辑。
2. P1 用例（重要功能）：次优先，覆盖主要异常场景。比如网络超时、库存不足。
3. P2 用例（边缘场景）：最后跑，或者放到回归测试里。比如特殊字符输入、边界值。

你想想看，如果 P0 用例都挂了，你跑 P2 有什么意义？先保证核心功能可用，再慢慢抠细节。

4.4 探索性测试：用例之外的「意外发现」

探索性测试，说白了就是「不按套路出牌」。我习惯在用例执行完后，留出 20% 的时间做探索性测试。为什么？因为用例是死的，但用户的操作是活的。

我记得有一次，测试一个文件上传功能。用例里只测了 PDF、JPG 格式。我随手试了一个文件名带中文+空格+特殊字符的文件，结果服务直接 500 了。这就是探索性测试的价值——发现用例覆盖不到的边界。

4.5 缺陷的初步定位与复现

找到 Bug 只是第一步。怎么让开发能复现，才是关键。我见过太多「这个 Bug 我复现不了」的对话了。

我的做法是：记录完整的复现步骤。包括：

• 前置条件：登录状态、数据准备、环境配置
• 操作步骤：每一步的点击、输入、等待时间
• 预期结果：应该出现什么
• 实际结果：出现了什么（附截图、日志、接口返回）
• 环境信息：浏览器版本、操作系统、设备型号

另外，日志是定位问题的关键。我习惯在测试时开启抓包工具（比如 Charles 或 Fiddler），记录接口请求和响应。这样开发一看日志，就知道是前端传参问题还是后端逻辑问题。

# 缺陷报告模板示例
标题: 【P1】用户登录后点击「我的订单」页面白屏
前置条件: 用户已登录，账号有 3 笔历史订单
操作步骤:
  1. 打开 App，进入首页
  2. 点击底部导航「我的」
  3. 点击「我的订单」
实际结果: 页面白屏，控制台报错 "Cannot read property 'length' of undefined"
预期结果: 正常显示订单列表
环境: iOS 17.2, iPhone 15 Pro, App 版本 3.2.1
日志: 见附件 network_log.txt
截图: 见附件 white_screen.png

4.6 本章知识体系

下面这张图，概括了测试执行与缺陷发现的完整流程。你可以把它贴在工位上，每次执行测试时对照着看。

这张图的核心逻辑是：环境是基础，冒烟是门槛，执行是主体，探索是补充，定位是闭环。每一步都走扎实了，缺陷才能被有效发现和修复。