一次性使用的測試數據，讓很多同事在自動化測試執行中最頭疼的可能就是這種測試的數據准備工作了，因為只能使用一次，每次運行之前都要准備新的數據，工作量不可謂不大，而且如果數據本身比較復雜或者稀少，這個數據准備工作就更讓人懷疑這些功能用自動化的方式來測試是否價值了。那么對於這種一次性的測試數據，我們用什么方法去爭取一勞永逸的效果呢？
a) 如果數據存量較多，則考慮直接鏈接數據庫查詢滿足測試需求的數據，注意，滿足測試需求或許不是簡單的一兩個SQL語句能決定的，需要仔細了解系統業務、設計邏輯，爭取讓測試數據是絕對可用的。
b) 如果數據較少，運行存在數據不足使用的潛在隱患的話，可以考慮該業務功能的互逆操作，從系統中尋找現成的具有數據對稱性的功能，如果有這種功能的存在，那么兩個功能串聯在一起測試運行，能夠起到操作回退的作用。
c) 如果業務系統中不存在互逆的功能，考慮后台數據的回歸和刪除，例如保單狀態修改，系統中不支持保全回退。考慮在測試數據庫中建立一個JOB，對操作進行回滾，修改和刪除所有影響到該筆數據下次繼續運行的數據庫記錄，根據測試執行的頻率決定JOB對應的運行頻率，保證每次測試運行之前運行一次Rollback測試數據的JOB。
d) 不斷生成新的可用的測試數據，增加可用數據量。尋找數據最初的來源，例如我們說的這兩個操作所需要的數據，他們都可以由新契約承保生成測試數據，如果契約承保系統功能正常、自動化能夠正常運行，那么我們將會不斷得到新的數據，從而避免數據量過少又不可復用的尷尬。只不過這種方式對關聯系統功能和自動化測試程序運行的穩定性依賴性較高，很難保證。
筆者個人建議：無論是什么類型的數據，使用什么樣的方法，只要相同的數據能夠長時間反復使用，那么將這寫數據使用數據文件存儲，映射到測試程序上去。存儲數據的載體文件如EXCEL，統一保存在測試框架下指定的目錄中，降低測試運行對人工測試數據准備的要求，最好能保證在首次運行成功之后還能夠運行30次以上。對於不可復用的數據或者實時性要求很高的數據，則從被測系統數據庫從獲取，而對於完全不可復用也不可狀態回退的測試數據，如第二章結尾所述，是否要進行自動化測試是值得商榷的。