数据库测试用例怎么写

数据库测试用例是保障数据库系统质量的核心手段,其本质是通过结构化设计的输入-输出组合，验证数据库的功能正确性、性能稳定性、数据完整性及安全性，以下从核心原则、设计维度、具体步骤、典型场景、避坑指南五个层面展开详述，并附完整示例与FAQ。

---

数据库测试用例的核心原则

1. 正向验证优先：先确保基础功能（增/删/改/查）在正常参数下能正确执行。
2. 反向穷举边界：重点测试非规输入（超长字符串、特殊字符、空值）、越权访问、并发冲突等场景。
3. 数据关系闭环：验证外键约束、级联操作、触发器逻辑是否按设计生效。
4. 状态一致性：检查事务提交/回滚后，相关表的数据状态是否同步更新。
5. 环境隔离：测试数据需独立于生产环境，避免被墙真实业务数据。

---

测试用例设计的七大维度

维度	说明	示例
功能测试	验证CRUD操作、存储过程、视图、索引的正确性	插入重复主键应抛出唯一性约束错误
性能测试	评估查询响应时间、锁竞争、大数据量下的吞吐量	百万级数据下分页查询耗时≤2秒
安全测试	校验权限控制（RBAC）、SQL注入防护、敏感字段脱敏	普通用户无法访问财务表的薪资字段
容错测试	模拟硬件故障、网络中断、磁盘满等异常场景下的系统表现	断电重启后事务日志能否完整恢复
兼容测试	跨数据库版本迁移、字符集转换、第三方工具对接	MySQL 8.0→5.7的版本回退数据无损
备份恢复	验证冷备/热备策略的有效性、PITR（点位恢复）精度	误删表后通过binlog恢复到指定时间点
合规审计	GDPR/HIPAA等法规要求的日志留存、加密存储、访问追溯	医疗数据查询需记录操作人+IP+时间戳

---

标准化编写步骤（含实操模板）

▶ Step 1: 需求拆解与用例分级

• 根据PRD文档提取关键实体（如订单表orders）及其关联关系（用户表users）。
• 按优先级划分：P0（核心交易链路）> P1（辅助功能）> P2（边缘场景）。

▶ Step 2: 构建测试矩阵

采用等价类划分+边界值分析法组合测试点：
| 测试对象 | 有效等价类 | 无效等价类 | 边界值 |
|—————-|————————–|——————————-|————————|
| 订单金额(price)| [0, +∞) | <0, >MAX_VALUE, NULL | 0元, 最大允许值±1 |
| 支付状态(status)| 待支付/已支付/已取消 | 未知枚举值(如”refunded”) | 状态流转顺序验证 |

▶ Step 3: 编写详细用例脚本

示例：用户注册功能测试用例
| 序号 | 测试项 | 前置条件 | 测试步骤 | 预期结果 | SQL语句/代码片段 |
|——|————————|————————|————————————————————————–|——————————————-|—————————————|
| T01 | 用户名唯一性校验 | 数据库已有用户A | 尝试注册用户名=A → 捕获异常 | 抛出Duplicate entry错误 | INSERT INTO users (username) VALUES('A') |
| T02 | 邮箱格式校验 | | 输入invalid_email作为邮箱 | 拒绝注册并提示”邮箱格式错误” | REGEXP_LIKE(email, '^[^@]+@[^@]+$') |
| T03 | 密码复杂度强制规则 | | 设置密码=123（纯数字） | 提示”密码必须包含字母和符号” | LENGTH(password)>=8 AND ... |
| T04 | 手机号段合法性 | | 输入13800138000（有效号段） vs 19900138000（无效号段） | 仅接受有效运营商号段 | phone LIKE '1[3-9]%' |
| T05 | 并发注册冲突处理 | 模拟10个线程同时注册 | 使用SELECT FOR UPDATE锁定记录 | 最终只有1条成功记录，其余报乐观锁失败 | INSERT ... ON CONFLICT DO NOTHING |

▶ Step 4: 数据准备与清理

• 造数策略：通过批量插入脚本生成测试数据（如生成1万条模拟订单）。
• 清理机制：每个测试集执行后自动回滚事务（ROLLBACK），或使用独立Schema/Database。

▶ Step 5: 结果断言设计

• 显式断言：比对返回值与预期结果（如SELECT COUNT() FROM orders WHERE status='paid'应等于1）。
• 隐式断言：检查日志文件是否记录关键操作（如审计日志中的DELETE操作）。
• 可视化验证：使用DBeaver等工具对比前后数据快照。

---

高价值测试场景深度解析

️ 场景1：复杂事务一致性验证

案例：电商瞬秒活动中扣减库存+增加积分+生成物流单。
测试要点：

• 中途中断事务（Ctrl+C）后，所有子操作必须全部回滚。
• 使用SHOW ENGINE INNODB STATUS查看锁等待情况。
• 模拟网络抖动导致部分节点超时,验证分布式事务的最终一致性。

️ 场景2：大数据量压力测试

方案：

1. 使用sysbench生成千万级测试数据。
2. 执行混合读写负载（读:写=7:3）。
3. 监控指标：TPS（每秒事务数）、QPS（每秒查询数）、锁等待时长。
4. 优化方向：添加复合索引、调整innodb_buffer_pool_size参数。

️ 场景3：SQL注入防御测试

攻击向量：

• ' OR 1=1 --（经典注入）
• UNION ALL SELECT @@version（探测版本信息）
• '; DROP TABLE users;--（反面代码拼接）
  防护验证：启用预处理语句（PreparedStatement）、参数化绑定。

---

常见误区与解决方案

误区	后果	解决方案
仅测试表面功能	遗漏事务死锁、索引失效等深层问题	引入混沌工程（Chaos Engineering）
依赖手工执行	效率低下且容易漏测	集成到CI/CD流水线（如Jenkins+Liquibase）
忽略历史数据迁移	旧数据在新系统中出现格式错误	专项测试数据迁移脚本
过度依赖GUI工具	难以复现自动化测试	编写可重复执行的Shell/Python脚本

---

相关问答FAQs

Q1: 如何高效维护数百个数据库测试用例？
A: 推荐采用标签化管理体系：①按模块打标（如[user][order]）；②按测试类型分类（功能/性能/安全）；③使用Markdown+PlantUML绘制用例流程图；④定期运行testsuite进行全量回归测试。

Q2: 遇到间歇性失败的测试用例怎么办？
A: 这是典型的”薛定谔bug”，解决方法：①开启详细日志级别（log_level=debug）；②缩小测试范围定位最小复现集；③检查资源竞争（同一时刻只有一个测试线程占用连接池）；④使用mysqldump导出失败时的数据库快照进行分析。