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 用於解釋已知條件。最小化必須保留失敗，不能誤刪原因。
虛構名稱信箱不代表真實行為或分布。效能容量測試可能需要特定長度、值種類和重複度，應另行定義。簡單型別不夠時記錄限制，不能用產生列數證明測試充分。