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

　　測試數(shù)據(jù)管理可能是測試專家職業(yè)生涯中要面臨的大挑戰(zhàn)之一。還沒有碰上測試數(shù)據(jù)緊缺或不完整測試數(shù)據(jù)的人算是相當(dāng)幸運的。

　　我們并不孤單
　　缺少測試數(shù)據(jù)會影響開發(fā)員。幾年前，我的一個任務(wù)里，開發(fā)員不得不猜測什么數(shù)據(jù)會進(jìn)入數(shù)據(jù)庫。在把他的代碼給測試團隊前，他沒有開始某種測試的環(huán)境�？梢韵胂�，測試階段也有災(zāi)難。因此該項目開始后被中止近三年一點也不奇怪�；蛟S這不是中止的主要原因，但是一個成因。數(shù)據(jù)對任何系統(tǒng)都重要且是測試一個系統(tǒng)的關(guān)鍵因素。數(shù)據(jù)為系統(tǒng)提供環(huán)境，，沒有環(huán)境，開始測試階段值得商榷了。

　　我們真的需要它嗎？
　　我們后退一步。我們?yōu)槭裁葱枰獪y試數(shù)據(jù)且我們該怎么計劃去使用它？對于初學(xué)者，沒有數(shù)據(jù)，你只測試應(yīng)用程序的GUI。以典型GUI為例，我們測試屏幕上的控件：按鈕，下拉菜單，文本框等。即使這些測試會被限制，使得從前端GUI無法到達(dá)某些屏幕或功能， 因為沒有輸入正確數(shù)據(jù)。為了遵循系統(tǒng)中的某些流程，需要具體數(shù)據(jù)。我們需要測試數(shù)據(jù)以確保企業(yè)規(guī)定被測且系統(tǒng)中不同流程被執(zhí)行。想象一下沒有數(shù)據(jù)的測試報告，我們開始測試了嗎？

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

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

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

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