Mario Matthee是一名測試員，顧問，認證Scrum大師以及非常不合的山地摩托車車手（正在學習中）。他熱衷于將年輕的IT專家引進軟件測試的世界。他還是開普敦測試自動化用戶組的創始成員之一。畢業于（南非）開普半島科技大學，他是動態可視技術公司的軟件質量

Mario Matthee是一名測試員，顧問，認證Scrum大師以及非常不合格的山地摩托車車手（正在學習中）。他熱衷于將年輕的IT專家引進軟件測試的世界。他還是開普敦測試自動化用戶組的創始成員之一。畢業于（南非）開普半島科技大學，他是動態可視技術公司的軟件質量保證部的主管。

?

　　測試數據管理可能是測試專家職業生涯中要面臨的最大挑戰之一。還沒有碰上測試數據緊缺或不完整測試數據的人算是相當幸運的。

　　我們并不孤單
　　 缺少測試數據會影響開發員。幾年前，我的一個任務里，開發員不得不猜測什么數據會進入數據庫。在把他的代碼給測試團隊前，他絕對沒有開始某種測試的環境。可以想象，測試階段也有災難。因此該項目開始后被中止近三年一點也不奇怪。或許這不是中止的主要原因，但絕對是一個成因。數據對任何系統都重要且絕對是測試一個系統的關鍵因素。數據為系統提供環境，，沒有環境，開始測試階段就值得商榷了。

　　我們真的需要它嗎？
　　 我們后退一步。我們為什么需要測試數據且我們該怎么計劃去使用它？對于初學者，沒有數據，你只測試應用程序的GUI。以典型GUI為例，我們測試屏幕上的控件：按鈕，下拉菜單，文本框等。即使這些測試會被限制，使得從前端GUI無法到達某些屏幕或功能， 因為沒有輸入正確數據。為了遵循系統中的某些流程，就需要具體數據。我們需要測試數據以確保企業規定被測且系統中不同流程被執行。想象一下沒有數據的測試報告，我們開始測試了嗎？

　　測試數據操作
　　 為了讓測試數據有效，我們需要在上面CRUD（創建，讀取，升級和刪除）。測試專家面臨的最大挑戰之一是與第三方的集成。大多數情況下，測試數據只被讀取，且數據數目被限。另一個潛在噩夢是第三方應用程序供應商不提前通知就改變測試數據。讓第三方應用程序供應商保證你能獲取他們的數據庫聞所未聞。沒什么阻止我們請求，但隨時做好你的請求被拒絕的準備吧。測試數據及其管理對手工和自動化測試都很重要。兩種情況中，測試專家旨在預測他們基于（他們在系統中輸入的）數據的預期結果。多數情況中，測試專家無法創建或操作數據進入所要求狀態。如果無法發現測試數據，就無法執行測試用例。

　　一個真實的例子
　　 讓我將我早期職業生涯中所經歷的一次真實問題為你細細道來。我們不得不測試并將顧客管理系統自動化。一個單獨的顧客賬戶上可以執行100多個不同的任務。比如鎖定賬戶，解鎖賬戶，查看余額，查看賬戶明細，激活郵箱，升級郵箱……
　　 測試數據的問題是測試團隊被賦予某些賬號范圍可以使用下游第三方相應測試數據。所以你可以創建你自己的測試數據并開始利用它，但你無法進行整個端到端的測試，因為新數據不會在下游系統上。
　　 只有有限范圍為了測試而被配置在下游系統上。所以你的測試會受限。
　　 下個問題是測試員開始分享賬號，或不請求或協調測試就使用測試數據。這就導致應該解鎖的賬戶被鎖，或擁有某些程序包的賬戶某天可以改變未來。測試同一個系統的不同功能時的不一致使一個有16名測試員的團隊受到了挫折。
　　 澄清一點，并不是所有手工測試都被影響了，但自動化確實是異常噩夢。自動化可以查詢數據并找到數據以供使用，但問題是，有時候數據就在那有時卻不在，因為另一隊成員不斷在改變數據。自動化的一個優勢是在測試執行前搜索數據。這種情況下，自動化運行就變得不可信了。我們絕對無法預測開始一次一整夜的自動化運行的測試數據是否充足。如果你無法在數據庫中找到數據，最好的辦法就是你自己創建數據。在這兒我不得不強調一下數據完整性的重要性：通過前端或通過執行，數據庫上的某些失序的儲存過程會破壞數據。
　　 這會進一步阻礙測試工作并有可能造成由測試團隊而不是開發團隊引起的缺陷。讓開發員判定缺陷原因很耗錢，最后卻發現是測試團隊自己破壞的。于是測試發布進程放緩了，自動化無法給投資滿意的回報。
　　 作為一個測試團隊，我們逐步擴大問題，并請求設計師想出一個解決方案。幾次會議后，制定出了一個計劃。因為那時候想不出一個更好的詞，我們稱這個解決方案為“香草腳本”。那么它是干什么的呢？它是一個基本消除了系統外特定顧客數的所有數據的存儲過程。我是說，所有數據，沒錯，就是所有的。主要是為了維護參照完整性且不破壞數據庫。可想而知，這要嘗試很多次才能成功，但三個月后我們想出了有效的解決方案。你們有些會覺得我們瘋了——我們怎么可能會有這樣一個腳本？如果將之投入生產呢？！這被視作發布流程和執行后測試的一部分。因為腳本是通過調用到一個存儲流程執行的，存儲流程要確保執行只在特定數據庫名字和IP地址上完成。
這些問題按以下方法解決：
　　 ??完整的終端到終端測試是可能的，因為香草腳本第一個運行，向下游系統發布命令刪除支持他們的相關數據。重新創建該賬號使得要重建一個下游，保證所有系統同步。
　　 ??測試員沒必要分享測試號。現在他們可以一遍又一遍地使用自動化去設置理想狀態的用同一個賬號的數據。
　　 ??自動化也使用分配到的賬號運行，所以我們總會有數據以供徹夜運行。
　　 ??通過運行失序腳本破壞數據庫的風險通過使用高級數據庫開發員編寫的香草腳本被消除了。

　　結果
　　 結果絕對驚人。假設你要測試一個賬戶完整生命周期，從激活到刪除，以及期間的所有任務。現在你可以做到！測試開始前，一名測試員運行香草腳本。現在，他們只需要讓賬戶進入一個他們所需的特定狀態以開始手動測試用例。這也使得我們能夠用同一個賬號為不同的軟件包產品編寫測試用例。自動化突然成功了。我們在36小時內運行300，000多個測試用例。反過來又產生了一個新需求：我們希望自動化運行地更快——但那在一般測試自動化和測試中卻是一個問題。我們該如何解決第三方測試數的共享呢？自動化用一兩個賬號，手動測試員用剩下的。他們開始通過自動化使用香草腳本將賬號設置為他們所希望的狀態。關鍵字驅動的自動化是解決方案的關鍵，因為它可以讓測試團隊自己設計測試用例組合。

　　總結
　　 測試數據管理可以創建或打破一個測試團隊的精神。創造性的解決方案是需要的。不要停止尋找解決方案，最后總會有所收獲。有時候解決方案就和在正確的時間向正確的人尋求幫助一樣簡單。

版權聲明：本文出自 SPASVO澤眾軟件測試網：http://www.spasvo.com/news/html/20141020154958.html

原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com