SQL与测试数据
不用真实数据，重复生成相同测试数据
使用工具
刷新后错误消失，可能只是数据变了而非修好了。每次随机样本虽方便，也可能丢失复现条件。带 Seed 生成可从同样设置重建数据，用小型虚构样本共享问题，无需复制真实用户信息。
先做三行四列虚构列表
选三行、Seed42、JSON，依次定义 id=integer、name=name、active=boolean、email=email。当前实现生成如下，姓名来自固定候选，地址使用 example.test，不获取真实人物或联系人。
[{"id":1,"name":"Haru","active":false,"email":"user1@example.test"},{"id":2,"name":"Ren","active":false,"email":"user2@example.test"},{"id":3,"name":"Mina","active":false,"email":"user3@example.test"}]相同条件再生成应一致。名字不代表特定用户，应标明测试用途，别流入生产通知。虚构地址与在测试环境禁用发送是不同措施，不能互相替代。
列顺序也是复现条件
改 Seed43 后第二行 Haru，第三行 Aoi 且 active=true，第一行仍一样。改 Seed 不保证每格都变；integer 和 email 基于行号，因此不变。区分随机型与按行号生成型，才能理解变化。
新增或重排消耗随机数的列，会改变取数顺序，同 Seed 后续值也可能不同。复现记录应包含列名、类型、顺序、数量、格式。未来算法变化也可能影响输出，长期回归可直接保存所需 Fixture。
JSON、CSV、SQL 的表示不同
转 CSV 得标题与数据行，SQL 得指定表 INSERT。JSON boolean 在 CSV 中显示 true/false，不保证下游自动恢复布尔型。切换格式要检查接收工具的类型解释，不只看外观。
SQL 输出只生成文本，不检查约束、默认值或外键，同列名不意味着可投入生产。应在测试环境准备最小模式，与通知、计费等外部流程隔离。
随机几行并不覆盖边界
Seed42 三行 active 都 false，不能算测试了 true 状态。长名、空串、NULL、引号、emoji、最大值不会都偶然出现，应另用 constant 或明确 Fixture 构造。随机样本与刻意边界各有用途。
数量边界也要刻意测试。工具支持 1–1000 行，空列表应由测试空数组等构造，不是请求零行。分页可选刚好一页及多一项，不是越多覆盖越好。
可复现随机数不用于秘密
Seed 重现是测试优点，却不适合秘密。别把生成字符串或邮箱当认证令牌或真实账户。秘密随机值用密码学令牌工具，也不要再把真实秘密贴进复现 Fixture。
报告应附列定义、Seed、数量、格式、预期和实际表现，缩减到最小复现集。从随便大量随机测试变成这三行触发此问题，修复后的回归也更具体。
将随机发现的问题变成固定复现例
大量随机数据偶发崩坏，换 Seed 成功不代表修好。先保留 Seed、列定义顺序、数量和格式重现。生成器版本可能改变序列，长期回归可直接保留导致问题的虚构行作为固定 Fixture。
再减少无关行列且保持失败。千行问题可能只需两个同名，也可能必须超过数量阈值，那就固定边界前后。随机用于探索组合，短 Fixture 用于解释已知条件。最小化必须保留失败，不能误删原因。
虚构名称邮箱不代表真实行为或分布。性能容量测试可能需要特定长度、值种类和重复度，应另行定义。简单类型不够时记录局限，不能用生成行数证明测试充分。