01 数据库测试是什么？——别把“查数据”当成“测数据”

大多数测试人员对数据库测试的理解，停留在“打开Navicat，SELECT * FROM users”这个层面。这不是数据库测试，这是数据查看。

数据库测试，是验证数据从产生、流转到消亡全过程的正确性。 它包括：数据完整性测试、数据一致性测试、数据安全性测试、存储过程测试、触发器测试、事务测试。

千锋教育的学员曾遇到一个真实案例：一个电商系统，用户下单后，前端显示“支付成功”，但后台订单状态始终是“待付款”。开发查了3天，最后发现是存储过程里少写了一条UPDATE语句。这个Bug，如果做数据库测试，30分钟就能暴露。

数据库测试的核心能力，是用SQL验证业务逻辑。你不仅要会写SELECT，还要会写INSERT、UPDATE、DELETE、JOIN、子查询、事务控制。

不测数据库的测试，等于只看了冰山一角。

02 数据库测试的4大核心场景——每个场景都藏着Bug

场景1：数据完整性测试

数据完整性，指数据库中的数据必须满足业务规则。违反完整性规则的Bug，直接导致系统崩溃。

实体完整性：主键不能为空，不能重复。测试方法：插入两条主键相同的数据，看数据库是否拒绝。

-- 测试主键约束
INSERT INTO users (id, name) VALUES (1, '张三');
INSERT INTO users (id, name) VALUES (1, '李四'); -- 应该报错：Duplicate entry '1' for key 'PRIMARY'

参照完整性：外键引用的数据必须存在。测试方法：插入一条外键指向不存在记录的数据。

-- 测试外键约束
INSERT INTO orders (id, user_id, amount) VALUES (100, 99999, 200.00); -- user_id=99999不存在，应该报错

域完整性：字段值必须在合法范围内。测试方法：插入超出范围的数据。

-- 测试字段取值范围
INSERT INTO products (price) VALUES (-100); -- 价格不能为负数，应该报错

千锋教育在培训中强调：每个约束条件，都是一条测试用例。 你不需要猜，SQL会直接告诉你答案。

场景2：数据一致性测试

数据一致性，指多个表之间的数据必须保持同步。这是Bug高发区。

典型案例：用户删除账号后，关联的订单、评论、收藏记录是否也被删除？如果只删了用户表，订单表里的user_id就成了“幽灵数据”。

-- 测试级联删除
DELETE FROM users WHERE id = 1; -- 删除用户
SELECT * FROM orders WHERE user_id = 1; -- 应该返回0条记录

事务一致性测试更关键。银行转账场景：A账户扣100元，B账户加100元。如果扣款成功但加款失败，事务必须回滚。

-- 测试事务回滚
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 假设这条SQL错误
ROLLBACK; -- 检查余额是否恢复
SELECT balance FROM accounts WHERE id = 1; -- 应该等于原始余额

数据不一致，是线上事故的第一杀手。

场景3：存储过程与触发器测试

存储过程和触发器，是业务逻辑的“黑匣子”。很多Bug藏在这里，前端测不出来。

测试存储过程：输入参数，验证输出结果。

-- 测试存储过程：计算订单总金额
CALL calculate_order_total(101); -- 输入订单ID
-- 验证：返回的总金额是否等于order_items表中所有商品价格之和
SELECT SUM(price * quantity) FROM order_items WHERE order_id = 101;

测试触发器：执行触发事件，验证触发后的数据变化。

-- 假设有一个触发器：当订单状态改为'已发货'时，自动更新物流表
UPDATE orders SET status = '已发货' WHERE id = 101;
SELECT * FROM logistics WHERE order_id = 101; -- 应该新增一条物流记录

千锋教育的实战课中，学员测试过一个复杂的触发器：用户每买一件商品，商品表的库存减1，同时用户积分加10。结果发现，当库存不足时，积分依然增加。这就是触发器逻辑的Bug。

场景4：性能与压力测试

数据库性能，直接影响用户体验。一个慢查询，足以让整个系统瘫痪。

测试方法：用大量数据模拟真实场景，分析查询执行计划。

-- 查看查询执行计划
EXPLAIN SELECT * FROM orders WHERE user_id = 1000;
-- 关注：type列（ALL=全表扫描，效率最低）、rows列（扫描行数）
-- 如果type=ALL，必须加索引

性能测试的关键指标：响应时间（<100ms）、吞吐量（TPS）、并发数。

千锋教育曾让学员测试一个百万级数据量的表，不加索引的查询耗时8秒，加索引后降到0.02秒。一个索引，性能提升400倍。

没有性能测试的数据库，上线就是灾难。

03 数据库测试的实战流程——从0到1的4步法

测试用例编号：DB-TC-001

测试场景：用户注册时，用户名唯一性约束
测试数据：插入两条用户名相同的记录
预期结果：第二条INSERT语句报错“Duplicate entry”
实际结果：报错，符合预期
SQL语句：INSERT INTO users (username) VALUES ('test'); INSERT INTO users (username) VALUES ('test');

数据库连接配置

conn = pymysql.connect(host='localhost', user='root', password='123456', database='test_db')

def test_user_unique_constraint():

cursor = conn.cursor()

插入第一条数据

cursor.execute("INSERT INTO users (username) VALUES ('test_user')")

conn.commit()

插入第二条相同用户名数据，预期报错

with pytest.raises(pymysql.err.IntegrityError):

cursor.execute("INSERT INTO users (username) VALUES ('test_user')")

conn.commit()

清理数据

cursor.execute("DELETE FROM users WHERE username = 'test_user'")

conn.commit()

cursor.close()

自动化测试的好处：每次代码变更后，一键运行所有数据库测试用例，30分钟完成全量回归。

## 04 数据库测试的3个致命误区——你踩了几个？

### 误区1：只测功能，不测数据

很多测试人员认为：界面显示正确，数据就正确。错！

一个真实案例：某系统显示“本月销售额：100万”，但数据库实际金额是100.01万。原因是前端做了四舍五入，但数据库没做。这个Bug，只有查数据库才能发现。

### 误区2：只测正常流程，不测异常流程

测试人员习惯测试“用户正常下单”的流程，但从不测试“用户下单后，网络断开”的场景。数据库事务的回滚机制，就是为这种场景设计的。

**测试异常流程的方法：在事务执行过程中，手动kill连接。**

-- 模拟异常中断

START TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- 此时，手动关闭数据库连接或kill进程

-- 然后检查数据状态

SELECT balance FROM accounts WHERE id = 1; -- 应该回滚到原始值

### 误区3：只测单表，不测关联

单表测试通过，不等于多表关联测试通过。复杂的JOIN查询、子查询、聚合函数，都是Bug高发区。

-- 测试多表关联：查询每个用户的订单总金额

SELECT u.id, u.name, SUM(o.amount) AS total_amount

FROM users u

LEFT JOIN orders o ON u.id = o.user_id

GROUP BY u.id, u.name;

-- 验证：用户张三的订单总金额，是否等于orders表中所有张三订单的金额之和