阶段一 · Linux 基础与 MySQL 全链路测试（华为云 ECS 真机实操）

阶段一 · Linux 基础与 MySQL 全链路测试（华为云 ECS 真机实操）

系列：AI + 全能测试工程师 · 全链路真机实操 阶段：阶段一 · Linux 基础与 MySQL 全链路测试 真机：华为云 ECS（Huawei Cloud EulerOS 2.0，8vCPU/16GB） 时长：约 4 小时

目录

• 一、引言：AI 测试时代，为什么还要学 Linux 和 MySQL？
• 二、环境准备
  • 2.1 机器规格（真实）
  • 2.2 初始化采集（真实命令与输出）
  • 2.3 工具链现状（真实）
• 三、分步实操
  • 3.1 Linux 基础命令（真机逐步演示）
  • 3.2 MySQL（MariaDB）全链路测试（真机逐步演示）
• 四、AI 赋能环节：让 AI 生成功能测试用例
• 五、实操效果验证（真实终端输出）
• 六、小结与下阶段预告

一、引言：AI 测试时代，为什么还要学 Linux 和 MySQL？

现在不少人觉得：“测试用例都能让 AI 生成了，底层命令、SQL 还学来干嘛？”

我在带团队时反复强调一句话：AI 是放大镜，不是地基。 当你面对一个"下单失败"的线上缺陷，AI 不会替你：

• 登上服务器 tail 日志、用 grep/awk/sed 把异常链路捞出来；
• 进数据库 JOIN 订单表和用户表，判断是"库存没扣"还是"事务没提交"；
• 用 ps/ss/top 确认进程到底起没起来、端口到底监听没监听。

这些底层硬功夫，决定了你是从"点界面的功能测试"升级为"能定位根因的全能测试工程师"的分水岭。本篇就在真实云主机上一镜到底，把 Linux 基础和 MySQL 全链路测试跑一遍——所有输出都是真机实测，绝无编造。

二、环境准备

2.1 机器规格（真实）

2.2 初始化采集（真实命令与输出）

我用一条 info 采集脚本确认了机器画像（节选）：

== HOST ==
ecs-24f5-2db6-0002
== OS ==
NAME="Huawei Cloud EulerOS"
VERSION="2.0 (x86_64)"
== CPU ==
8
== MEM ==
Mem: 15Gi 159Mi 14Gi 11Mi 491Mi 14Gi
== DISK ==
/dev/vda1 40G 2.1G 36G 6% /
== TIME ==
Mon Aug 17 10:10:05 AM CST 2026

2.3 工具链现状（真实）

连上机器后第一件事是核对"装了什么"。实测如下（未装的标 NOT INSTALLED，后面再补）：

git git version 2.33.0
python3 Python 3.9.9
pip3 pip 21.3.1 from /usr/lib/python3.9/site-packages/pip (python 3.9)
dnf 4.10.0
docker NOT INSTALLED
podman NOT INSTALLED
mysql NOT INSTALLED
mariadb NOT INSTALLED
tar tar (GNU tar) 1.34
awk GNU Awk 5.1.1, API: 3.1
sed sed (GNU sed) 4.8
grep grep (GNU grep) 3.7

结论：Git、Python、dnf、文本三剑客已就绪；数据库（MariaDB）与容器引擎（Docker/Podman）待装。本篇先装 MariaDB，容器放到阶段六。

三、分步实操

3.1 Linux 基础命令（真机逐步演示）

工作目录统一放在 /opt/testlab，既是演练场，也是后面 Git 仓库的根。

3.1.1 目录与文件：pwd / ls -l / mkdir / touch / cp / mv

########## [1] 目录与文件基本操作 ##########
当前目录(pwd):
/opt/testlab
total 12
-rw-r–r– 1 root root 12 Aug 17 10:11 file_a.txt
-rw-r–r– 1 root root 55 Aug 17 10:11 file_b.log
drwxr-xr-x 2 root root 4096 Aug 17 10:11 sub
— cp / mv —
total 8
-rw-r–r– 1 root root 55 Aug 17 10:11 access.log
-rw-r–r– 1 root root 12 Aug 17 10:11 file_a_copy.txt

解读：mkdir -p demo/sub 递归建目录；touch 生成空文件；cp 复制到子目录、mv 把 file_b.log 改名迁移为 access.log。这是部署/备份脚本里最常见的文件搬运动作。

3.1.2 权限：chmod / chown

########## [2] 权限 chmod / chown ##########
-rw-r–r– 1 root root 12 Aug 17 10:11 demo/file_a.txt
-rwxr-xr-x 1 root root 12 Aug 17 10:11 demo/sub/file_a_copy.txt
— 用 chmod 符号方式给脚本加执行权限 —
-rwxr-xr-x 1 root root 12 Aug 17 10:11 demo/sub/file_a_copy.txt
— chown（演示改为 root:root，EulerOS 默认已是 root）—
-rw-r–r– 1 root root 12 Aug 17 10:11 demo/file_a.txt
-rw-r–r– root:root demo/file_a.txt

解读：chmod 644 是"属主可读写、其他人只读"；chmod +x 加执行位（脚本必备）；chown root:root 修正属主。测试环境里常因权限不对导致"脚本能看不能跑"，这条要烂熟。

3.1.3 进程与网络：ps aux | head / ss -tunlp

########## [3] 进程与网络 ps / ss ##########
— ps aux | head —
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.1 0.0 174928 12444 ? Ss 09:52 0:01 /usr/lib/systemd/systemd …
— ss -tunlp —
Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=2586,fd=3))
tcp LISTEN 0 10 127.0.0.1:29338 0.0.0.0:* users:(("uniagentd",pid=3106,fd=5))

解读：ps aux 看全量进程；ss -tunlp 看监听端口——这里确认了 22（SSH）在监听。等会儿装完 MariaDB，我们会再用 ss 验证 3306 是否起来。

3.1.4 资源监控：top / df -h / free -h / uptime

########## [4] 资源监控 top / df / free / uptime ##########
— top -b -n1 | head —
top – 10:11:29 up 18 min, 0 users, load average: 0.00, 0.00, 0.00
Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 si, 0.0 st
MiB Mem : 15363.0 total, 14710.5 free, 159.3 used, 493.2 buff/cache
— df -h —
/dev/vda1 40G 2.1G 36G 6% /
— free -h —
Mem: 15Gi 159Mi 14Gi 11Mi 493Mi 14Gi
— uptime —
10:11:29 up 18 min, 0 users, load average: 0.00, 0.00, 0.00

解读：top -b -n1 批处理模式适合写进监控脚本；df -h/free -h 看磁盘与内存余量；uptime 看负载。压测前先 free -h 看内存够不够，是测试工程师的基本素养。

3.1.5 备份脚本：backup.sh 用 tar 打包并演示执行

我写了一个带时间戳的备份脚本 /opt/testlab/backup.sh：

#!/bin/bash
# 简易备份脚本：把指定目录打包为带时间戳的 tar.gz
SRC="$1"
DEST_DIR="${2:-/opt/backups}"
TS=$(date +%Y%m%d_%H%M%S)
mkdir -p "$DEST_DIR"
if [ -z "$SRC" ] || [ ! -d "$SRC" ]; then
echo "用法: backup.sh <源目录> [目标目录]"
exit 1
fi
NAME=$(basename "$SRC")
OUT="$DEST_DIR/${NAME}_${TS}.tar.gz"
tar -czf "$OUT" -C "$(dirname "$SRC")" "$NAME"
echo "已备份: $OUT ($(du -h "$OUT" | cut -f1))"

执行效果（真实）：

########## [5] backup.sh 用 tar 备份并演示执行 ##########
已备份: /opt/backups/demo_20260817_101129.tar.gz (4.0K)
total 4.0K
-rw-r–r– 1 root root 284 Aug 17 10:11 demo_20260817_101129.tar.gz

解读：tar -czf = 创建 + gzip 压缩；-C 切换到源目录父级再打包，避免压缩包里带一长串绝对路径。这正是 CI 里"产物归档"的雏形。

3.1.6 文本处理：grep / awk / sed 处理日志

构造一段访问日志后做三件事：

########## [6] 文本处理 grep / awk / sed 日志示例 ##########
— grep 过滤 ERROR 行 —
2026-08-17 10:02 ERROR user=bob action=login reason=wrong_pwd
2026-08-17 10:05 ERROR user=bob action=buy reason=stock_empty
— awk 统计每个用户出现次数 —
3 alice
2 bob
1 carol
— sed 把 INFO 替换为 [信息] —
2026-08-17 10:01 [信息] user=alice action=login
2026-08-17 10:02 ERROR user=bob action=login reason=wrong_pwd
2026-08-17 10:03 [信息] user=alice action=buy item=phone

解读：

• grep "ERROR" 秒级捞出所有异常行——线上排障第一步；
• awk 提取 user= 字段并 sort | uniq -c 统计每个用户行为频次，能快速发现"bob 老在报错"；
• sed 's/INFO/\\[信息\\]/g' 演示批量改写。这三件套是"日志分析"的基石。

3.2 MySQL（MariaDB）全链路测试（真机逐步演示）

3.2.1 安装并启动 MariaDB

########## [A] 安装并启动 MariaDB ##########
Complete!
● mariadb.service – MariaDB 10.5.25 database server
Active: active (running) since Mon 2026-08-17 10:13:34 CST; 3ms ago
MariaDB 版本:
mysql Ver 15.1 Distrib 10.5.29-MariaDB, for Linux (x86_64) using EditLine wrapper

dnf install -y mariadb-server mariadb 装的是 MariaDB 10.5（MySQL 的社区分支，命令兼容）。systemctl enable –now mariadb 开机自启并立即启动。

3.2.2 安全初始化（设置 root 密码、删匿名用户）

########## [B] 安全初始化 ##########
安全初始化完成。验证密码登录:
current_user()
root@localhost

我用脚本化方式替代交互式的 mysql_secure_installation：给 root@localhost 设密码并改为密码认证、删除匿名用户、禁止 root 远程登录、删掉默认的 test 库。生产环境这一步绝不能省。

⚠️ 安全初始化要点：必须删除匿名用户、禁止 root 远程登录、移除默认 test 库——匿名用户与空密码是常见安全漏洞，生产环境切勿跳过。

3.2.3 建库与三张表

设计一套最小商城模型，把"用户—商品—订单"数据流转串起来：

########## [C] 建库 mall_demo 与三张表 ##########
Tables_in_mall_demo
orders
products
users

表结构（关键字段）：

CREATE DATABASE IF NOT EXISTS mall_demo CHARACTER SET utf8mb4;
USE mall_demo;
CREATE TABLE users(
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash CHAR(64) NOT NULL,
email VARCHAR(100),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP);
CREATE TABLE products(
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100) NOT NULL,
price DECIMAL(10,2) NOT NULL,
stock INT NOT NULL DEFAULT 0);
CREATE TABLE orders(
id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
product_id INT NOT NULL,
qty INT NOT NULL,
amount DECIMAL(10,2) NOT NULL,
status VARCHAR(20) DEFAULT 'PAID',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (product_id) REFERENCES products(id));

3.2.4 插入样例数据

########## [D] 插入样例数据 ##########
users:
id: 1 username: alice email: alice@example.com
id: 2 username: bob email: bob@example.com
products:
id name price stock
1 智能手机 X1 5999.00 10
2 保护壳 99.00 50
3 蓝牙耳机 299.00 20

"注册用户"和"上架商品"这两步，对应真实业务的用户注册与商品发布。

3.2.5 CRUD 演示

########## [E] CRUD 演示 ##########
— INSERT：新增用户 carol —
— SELECT —
id username email
1 alice alice@example.com
2 bob bob@example.com
3 carol carol@example.com
— UPDATE：商品涨价 —
id name price
1 智能手机 X1 5799.00
— DELETE：删除刚注册的 carol（演示后清理）—
user_count
2

解读：演示了 INSERT 新用户 → SELECT 查看 → UPDATE 改价格 → DELETE 清理。注意真实系统里"删除用户"应做逻辑删除（is_deleted 标记），这里仅为演示物理删除。

3.2.6 JOIN：用户 + 订单（数据流转核心）

先造两条订单，再 JOIN 把"谁买了什么"拼出来：

########## [F] JOIN：用户 + 订单 ##########
username name qty amount status
alice 智能手机 X1 2 11598.00 PAID
bob 保护壳 1 99.00 PAID

这就是"用户下单"的数据视角：订单表只存 user_id/product_id，靠 JOIN 还原成人类可读的"谁 / 买了什么 / 花了多少"。

3.2.7 事务：COMMIT（扣库存 + 插订单）

下单的核心是把"扣库存"和"写订单"放进同一个事务，要么都成、要么都不成：

########## [G] 事务 COMMIT：alice 再买 1 台手机 ##########
BEGIN;
UPDATE products SET stock=stock-1 WHERE id=1;
INSERT INTO orders(user_id,product_id,qty,amount,status) VALUES (1,1,1,5799.00,'PAID');
COMMIT;
提交后库存与订单:
name stock
智能手机 X1 9
alice_orders 2

库存从 10 → 9，订单数 +1，事务提交成功。

3.2.8 事务：ROLLBACK（库存不足整体回退）

如果 bob 想买 100 台，但库存只有 9，业务校验失败必须整体回滚：

########## [H] 事务 ROLLBACK：bob 想买 100 台，超库存 ##########
info
当前库存=9
回滚后库存应保持不变（仍为 9）:
name stock
智能手机 X1 9
bob_100_orders 0

解读：ROLLBACK 后库存仍是 9、且没有产生任何 100 台的脏订单。这正是"下单"接口必须有的原子性保障——这也是测试下单功能时最该重点覆盖的异常分支。

3.2.9 聚合统计：按用户 SUM(amount)

########## [I] 聚合统计：按用户 SUM(amount) ##########
username order_cnt total_amount
alice 2 17397.00
bob 1 99.00

GROUP BY + SUM 是典型的"报表/对账"查询。测试数据一致性时，常用它来核对"订单总额"是否和"支付流水"对得上。

四、AI 赋能环节：让 AI 生成功能测试用例

作为 AI 测试助手，我直接产出了"商城注册 / 登录 / 下单"的测试用例表，方法 = 等价类划分 + 边界值分析。

4.1 我生成的测试用例清单（节选）

A. 用户注册（username / password / email）

B. 用户登录

C. 下单（重点覆盖事务分支）

ORD-03 正是 3.2.8 在数据库里真实演示过的 ROLLBACK 场景——AI 设计用例，真人用 SQL 验证，闭环。

4.2 我是怎么让 AI 写出这份用例的（提示词示例）

你是一名资深测试工程师。请为"电商商城"的【用户注册】【用户登录】【下单】三个模块，
使用"等价类划分 + 边界值分析"方法设计功能测试用例。
要求：
1. 每个模块给出至少 5 条用例，覆盖有效等价类、无效等价类、边界值；
2. 下单模块必须包含"库存不足导致事务回滚"和"并发超卖"两条异常用例；
3. 用表格输出，列：用例编号 / 场景 / 输入 / 等价类或边界 / 预期结果。

技巧：给 AI 明确的"方法约束"（等价类+边界值）、“必含异常分支”（回滚、超卖）、“输出格式”（表格），比一句"帮我写测试用例"质量高出一大截。

五、实操效果验证（真实终端输出）

本篇所有代码块均来自华为云 ECS 真机执行，关键结论再确认一遍：

• Linux：文件操作、chmod/chown、ps/ss/top/df/free/uptime、tar 备份、grep/awk/sed 日志处理全部正常；
• MariaDB 10.5 安装启动、安全初始化、建库建表、CRUD、JOIN 正常；
• 事务 COMMIT 后库存 10→9、订单 +1；ROLLBACK 后库存保持 9、无脏订单；
• 聚合统计 SUM(amount)：alice 17397.00、bob 99.00。

无任何模拟输出，全部可复现（命令已给出，照抄即可重跑）。

小结

阶段一我们夯实了两块底层硬功夫——Linux 运维排障基础，以及以"用户下单"为主线的 MySQL 全链路（建模→增删改查→关联→事务→聚合）。更重要的是建立了"AI 出用例、真人验数据"的协作范式。

下阶段预告

• 阶段六 · 工具链：在 /opt/testlab 用 Git 做版本管理与分支协作（main/dev/feature），并用 Docker 把上面的 pytest 自动化脚本打成镜像跑起来——这部分同样是真机实测，敬请期待下一篇。
• 后续还会接入接口自动化（pytest + requests）、CI 流水线，把"底层能力"真正串成"测试工程化"。

本文所有命令与输出均来自华为云 ECS 实机操作，时间为 2026-08-17。