第二章：环境准备——测试环境搭建、数据准备、工具链选型

大家好，我是老赵。这一章咱们聊聊测试开始前最磨人、也最关键的一步——环境准备。

很多人觉得测试就是写脚本、点按钮。其实不然。我见过太多项目，脚本写得漂亮，结果一跑就崩。为什么？环境没搭好，数据没备齐，工具选得不对路。说白了，地基没打牢，楼盖得再高也得塌。

今天我就把这块掰开了讲。你跟着走一遍，以后自己搭环境心里就有谱了。

2.1 测试环境搭建——别让环境坑了你

测试环境，说白了就是被测系统跑的那个窝。窝没搭好，测试结果就没法信。

2.1.1 环境类型与分层

我个人习惯把环境分成四层：

  • 开发环境（Dev）：开发自己用，代码最新，但最不稳定。
  • 测试环境（Test/QA）：我们测试的主战场。数据独立，配置可控。
  • 预发布环境（Staging）：跟生产环境一模一样。我建议所有回归测试都在这跑一遍。
  • 生产环境（Prod）：线上真实环境。原则上不直接测，除非做冒烟验证。

核心原则：测试环境必须与生产环境保持配置一致。 数据库版本、中间件、操作系统，差一点都不行。我在项目中遇到过测试环境用MySQL 5.7，生产环境是8.0，结果一个SQL在测试环境跑得飞快，上线后直接慢查询——这种坑，踩一次就够了。

2.1.2 环境搭建的自动化思路

手动搭环境？太慢了。我建议用Docker或Ansible这类工具。

举个例子，用Docker Compose一键拉起整套测试环境：

version: '3.8'
services:
  app:
    image: myapp:test
    ports:
      - "8080:8080"
    depends_on:
      - db
      - redis
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: test123
  redis:
    image: redis:6.2

你想想看，一条 docker-compose up -d 命令，整个环境就起来了。省下来的时间，多跑几个用例不香吗？

小技巧：每次跑完测试，记得 docker-compose down -v 清理数据。不然数据污染了，下次测试结果就不准了。

2.2 数据准备——测试的“弹药库”

环境搭好了，没数据也不行。数据准备这块，我踩过的坑比环境还多。

2.2.1 数据分类

数据类型 说明 示例
基础数据 系统运行必须的数据 用户表、配置表、字典表
测试数据 针对特定用例构造的数据 订单状态为“已支付”的数据
边界数据 临界值、异常值 金额为0、负数、超长字符串
大数据量 压测用的海量数据 100万条订单记录

2.2.2 数据准备策略

我常用的三种方式：

  1. SQL脚本预置：写一批INSERT语句，测试前执行。适合基础数据。
  2. API造数：调用业务接口生成数据。更贴近真实场景。
  3. 数据工厂工具：比如Faker库（Python）或Java的Instancio。随机生成大量数据，压测时特别好用。

举个例子，用Python Faker生成用户数据：

from faker import Faker
fake = Faker('zh_CN')

for _ in range(100):
    user = {
        'name': fake.name(),
        'phone': fake.phone_number(),
        'email': fake.email(),
        'address': fake.address()
    }
    # 插入数据库或调用API
    print(user)

注意：千万不要在生产环境造数据！我曾经见过有人直接在线上库跑造数脚本，结果把生产数据搞乱了。测试数据一定要隔离，用完就删。

2.3 工具链选型——选对工具，事半功倍

工具选型这块，我建议不要盲目追新。适合团队、适合项目，才是最好的。

2.3.1 自动化测试工具

UI自动化，我首推 Selenium。为什么？生态好、社区活跃、支持多语言。我在项目中用它做过电商、金融、ERP系统的UI自动化，基本都能搞定。

但Selenium也有短板——速度慢、依赖浏览器。如果你做的是接口测试，我建议用 Postman 或 JMeter。

2.3.2 性能测试工具

说到性能测试，JMeter 是绕不开的。开源、免费、支持分布式压测。我个人习惯用它做接口压测和数据库压测。

JMeter的基本用法：

# 命令行执行JMeter压测（无GUI模式）
jmeter -n -t test_plan.jmx -l results.jtl -e -o report/

这条命令的意思是：无界面运行测试计划，输出结果到results.jtl，并生成HTML报告。

选型建议：

  • UI自动化：Selenium + TestNG/JUnit
  • 接口自动化：Postman + Newman 或 RestAssured
  • 性能测试：JMeter 或 Gatling
  • 移动端：Appium

2.3.3 工具链整合

工具不是孤立的。我习惯把它们串成一条链：

  • 代码管理：Git
  • 持续集成：Jenkins 或 GitLab CI
  • 测试管理：TestRail 或 Xray
  • 报告展示：Allure 或 ExtentReports

你想想看，代码提交后自动触发测试，测试结果自动生成报告，报告自动推送到团队群——这才是现代化的测试流程。

2.4 本章知识体系总览

下面这张图，是我画的环境准备核心逻辑。你一看就明白了。

环境准备核心知识体系 环境搭建 数据准备 工具链选型 Dev环境 Test环境 Staging环境 Prod环境 基础数据 测试数据 边界数据 大数据量 Selenium JMeter Postman Appium 三者缺一不可，互相依赖 环境是基础 → 数据是弹药 → 工具是武器

嗯，这张图基本把环境准备的三个核心模块串起来了。你照着这个思路去搭，基本不会出大问题。

我的个人习惯：每次接手新项目，第一件事就是画一张环境拓扑图。把服务器、数据库、中间件、测试工具全标上去。哪里容易出问题，一眼就能看出来。

好了，环境准备这块就讲这么多。记住一句话：测试环境稳了，测试结果才可信；数据准备足了，测试覆盖才全面；工具选对了，测试效率才高。

可可精品资料库

← 上一章 📖 返回目录 下一章 →