方法一：編寫儲存過程，用SQL指令碼方式，插入測試資料

這個方式有幾個前提條件：

1-需要對該業務下所有關聯的表結構非常熟悉

2-需要對整個業務也非常熟悉

這時需要開發協助編寫測試指令碼或者向他們學習業務和關聯的表結構，自己編寫指令碼；但是資訊來源不全的情況，需要不斷嘗試，不斷除錯才能夠準備出符合要求的測試資料。

優點是非常直接有效的方法，比較靈活，量和業務需求都是可控的；

缺點就是需要搞清表間關係，精 通業務流程，指令碼也需要經常維護。

方法二：通過業務的方式去產生測試資料

當然不是手工去一個一個新增，如果量很大，勢必需要依靠自動化工具來實現。這種情況下，測試人員只需要瞭解業務的操作流程，然後採用能通過業務大量生成資料。

優點：這樣的資料一般都是合法可用的，能夠確保之後的效能測試的質量。

缺點也很明顯，需要開發額外的測試指令碼，要花費額外的時間和人力。

方法三：採用生產資料

在有現成資料並且資料保密性要求不高的情況下，可以採用這種方法，畢竟生產資料是原原本本的使用者行為所產生的資料。

缺點，量不可能控，可能某些業務的資料量少了，不符合效能測試的需求；生產資料也會有髒資料的產生，會因為系統架構的調整，表結構的變化等等諸多因素產 生髒資料，而這些資料是不具備業務意義的；多數情況下，生產資料一般不會被用於測試。

綜上所述，方法一最直接有效，但需要對測試場景下所有關聯的表結構和業務非常熟悉；方案二的資料合法可用，但需要開發額外的測試指令碼，要花費額外的時間和人力；方法三最最省時省力，但是某些測試場景下的資料量可能不滿足併發，也會有髒資料存在，一般不用採用方法三。