自動化測試剛 開始的時候，基于錄制回放，輸入的都是頁面上你實際輸入的數據。如果我希望測試一個合法的登錄和一個非法的登錄，同樣的腳本不一樣的數據而已，我不想有兩 個腳本，那么就需要對數據進行參數化。最好，數據與腳本分離，以便更加清晰和容易維護。因此，自動化測試中引入了“數據驅動”的概念，即用獨立于腳本的測 試數據來驅動腳本的運行。單個腳本的數據問題可以這樣處理，那么多個腳本之間的數據共享和傳遞呢？比如，一個系統有兩個模塊：上游模塊A，下游模塊B，B的輸入是A的輸出。這里有一個問題：B的數據怎么創建？有人會馬上想到數據傳遞啊，把A模塊的輸出寫到一個公共變量或者數據表中，B模塊從這里拿數據開始自己的執行。是的，這是自動化測試工具提供的功能?？墒?，如果某次運行，模塊A有新的缺陷，造不出B預期的輸入數據，會導致B的自動化腳本失敗。當我們看到失敗后，是否費力排查下來才發現A才是B失敗的罪魁禍首？而如果A是成功的（A是否失敗要看是否有關于這個缺陷的相關驗證），則更具有蒙蔽性，很難快速想到問題可能出在A。這里舉的例子還相對簡單，若系統中模塊間的交互更多、更復雜，數據的問題、腳本的問題、程序本身的缺陷就象幾個毛線團纏繞在一起，排查問題的根本原因將耗費大量的人力，并讓人沮喪。更有甚者，上游一失效，下游所有相關功能測試全部失敗，即使他們本來是沒有缺陷的。這樣的自動化也太脆弱了，簡直和天氣預報一樣經常誤報??！
如 此看來，測試數據的依賴確實給我們添了不少亂子。那我們是否可以這樣做？即使本來兩個功能之間有數據的傳遞，也為每個單獨的功能預埋其輸入數據（而非依賴 上游在執行過程中產生這樣的數據）。這樣當一個功能失效后我們能夠迅速定位到它。當然，這樣做的一個風險就是可能隱藏某模塊不能正確產生其它模塊希望的正確輸出，而這種問題對于用戶的端到端的操作是嚴重的問題。
因此，我建議在多個腳本的測試數據上綜合使用以上兩種方法。“數據獨立”適用于測試不穩定的功能（如新功能），或者容易出錯的功能（如老功能中復雜的邏輯），方便查找原因。“數據依賴”適用于測試穩定的功能/接 口或者基本業務流程，有了它的保障，我們對端到端的正確性更有信心。當“數據獨立”和“數據依賴”在一次運行中都有時，如果“數據獨立”的腳本失敗，我們 從“數據獨立”的單個腳本開始排查問題；如果“數據依賴”的腳本失敗，同時“數據獨立”的腳本也在相關處失敗，則從“數據獨立”的單個腳本開始排查問題， 否則從“數據依賴”的腳本處排查問題。