軟體開發中的自動化測試

zhouhaifang5發表於2004-10-04
當前大部分的測試工具是軟體的功能性測試功能（也被稱為記錄/回放工具），如Rational的Robot和Mercury 的Winrunner等。記錄/回放工具的缺陷使我們在測試中不能過分依賴它。

缺陷：

記錄/回放工具能夠記錄下使用者和應用程式互動時的擊鍵和滑鼠的移動。擊鍵和滑鼠的移動都被記錄成一個指令碼，然後可以在測試執行期間“回放”。雖然這種方法對特定的情形是有益的，但是記錄/回放功能大約僅僅是其全部功能的1/10。記錄/回放指令碼在首次記錄生成之後必須要進行修改。對功能性測試的修改主要集中在透過GUI進行驗證的測試，也稱為黑箱測試。只是透過記錄/回放直接建立指令碼有一些嚴重的侷限和缺點。

1． 硬編碼的數值。記錄/回放工具根據使用者的互動動作來生成指令碼，其中也包含了從使用者介面輸入或者接受的任何資料。讓數值在指令碼中“硬編碼”會給以後的維護工作帶來問題。如果應用程式的使用者介面或則其他方面發生了變化，那麼硬編碼的數值會導致指令碼非法。例如：在記錄期間生成指令碼的時候，輸入值、視窗座標、視窗標題和其他值可能也被記入生成的指令碼程式碼中。如果在應用程式中，這些值中任何一個發生了變化，那麼測試執行期間這些固定的數值就成了罪魁禍首：測試指令碼與應用程式的互動是錯誤的，或者徹底失敗。另一個可能出問題的硬編碼數值是日期戳。如果測試工程師在測試過程中記錄了當前日期，那麼幾天後再次執行這個指令碼會導致失敗，因為指令碼中包含了硬編碼的數值不再和當前的日期匹配。

2． 非模組化的、不易維護的指令碼。測試工具產生的記錄/回放指令碼通常不是模組化的，維護起來非常困難。例如：可能許多測試過程都引用了一個WEB應用程式中特殊的URL，如果指令碼中使用了硬編碼的URL，那麼這個URL的改變將會導致大量的指令碼作廢。在一個模組化的開發方法中，只有一個函式中引用，或則包裝了這個URL。隨後各個是引用它的指令碼會呼叫這個函式，這樣URL的任何變化只需要改動一處就可以了。

3． 缺乏可重用性的標準。測試過程開發面臨的最重要的課題之一是可重用性。如果測試建立專門的標準，明確地要求開發可複用的自動測試過程，那麼就會極大地提高測試組的工作效率。如果把使用者介面部分的測試封裝進模組化的、可重用的指令碼檔案，供其他指令碼呼叫，那麼當使用者介面經常不斷變化的時候，指令碼的維護工作量就會大大降低。

建立一個可重用的函式庫時，最好把諸如資料讀取、寫入和確認、導航、邏輯以及錯誤檢查功能分別歸到不同的指令碼檔案中。自動測試開發的指導方針應該大量的借用高效的軟體開發工作所遵循的原則。遵循與測試工具生成指令碼的開發語言最接近的開發語言的指導方針，這是一個很好的時間。例如：如果工具生成的指令碼類似於C語言，那麼應該遵從C語言的開發標準；如果工具生成的指令碼類似於BASIC語言，那麼應該遵從BASIC語言的開發標準。

在自動測試開發中，只使用記錄/回放方法生成的測試指令碼是很難維護和重用的，這是明顯的事實。雖然也有少數的情況，可使用未經加工的指令碼，但是對於大多數情況，如果不在記錄之後修改指令碼，那麼在測試執行期間，測試工程師會由於正在測試的應用程式的變化而反覆記錄指令碼。使用記錄/回放工具可能帶來的潛在收益，一定會被不斷重建測試指令碼的無奈所抵消。這會使測試人員產生很強的挫折感，並且會對自動測試工具感到不滿。

為了避免未經加工的記錄/回放指令碼帶來的問題，應該建立可複用的測試指令碼的開發方針。未經過加工的記錄/回放指令碼並不表示有效的自動測試。


解決方法：自制開發一個測試工具


為了去除自動測試工具的侷限性和對核心元件進行更深入的測試，可以自制開發一個測試工具。這種定製的測試工具一般用健壯的程式語言編寫，例如：獨立的C++或則Java程式，定製的測試工具一般比自動測試工具生成的指令碼執行的速度更快，也更靈活，因為這些指令碼受限於測試工具的特定環境。

我們舉一個適合用定製測試工具來測試任務的例子，假設一個應用程式的用途使根據使用者提供的資訊進行計算，並且把計算的結果生成報告。計算過程可能是複雜的，並且可能對各種輸入引數的不同組合是敏感的。這可能會有數百萬種潛在變化，這些變化會產生不同的結果，因此，對計算過程進行全面的測試才能保證計算的正確性。

手工開發和驗證大量的計算性測試用例是非常浪費時間的。在大多數情況下，透過介面執行大量的測試用例也是非常緩慢的。此時一個更高效的方法是自制開發一個測試工具，它會直接針對應用程式的程式碼（一般是直接針對使用者介面層之下的核心元件）執行測試用例。

另一種使用自制測試工具的方法是：對照遺留元件或者系統來比較新元件。兩個系統通常使用的資料儲存格式是不同的，用不同的技術實現的使用者介面也是不同的。此時，為了在兩個系統上執行相同的測試用例並且生成比較報告，自動測試工具需要一種特殊的機制來複制自動測試指令碼。在最壞的情況下，單個測試工具不能同時相容兩個系統，此時兩套測試指令碼必須用兩種不同的自動測試工具來開發。一個更好的替代方案是自制生成一個定製的、自動測試工具，它把兩個系統之間的差異封裝進獨立的模組，這樣我們就能夠設計出同時適用於兩套系統的測試。自制的自動測試工具可以把遺留系統產生的測試結果作為基線，並且透過比較兩套結果和輸出它們之間的差異來自動地驗證新系統產生的結果。

達到上述目的的一種方法是使用自制工具介面卡模式。自制測試工具介面卡是一個模組，它透過轉換或者改造正在測試地每個系統使之和自制測試工具相容，這樣自制測試工具可以透過介面卡在系統種執行預定義地測試用例，並且把結果儲存為相互之見可以自動比較地標準格式。對於每個開發出來地介面卡必須能夠直接和系統進行互動和針對系統執行測試用例。用一個自制測試工具測試兩個系統需要不同地介面卡並獨立呼叫兩次自制測試工具，每個系統呼叫一次。兩次呼叫的結果應用保留起來並進行比較。圖示描述了針對遺留系統和新系統執行測試用例的定製測試工具。




透過為每個系統使用不同的介面卡，相同的測試用例可以用於多個系統。針對遺留系統的介面卡來產生一組基線結果，這個結果用於和新系統的結果比較。

為了完成他們的任務，自制的測試工具介面卡首先獲得一組測試用例，然後按照順序執行這些用例，從而直接測試每個系統的邏輯，繞過了使用者介面。繞過使用者介面使效能得到了最佳化，使得測試用例的吞吐量最大化。它還具有更高的穩定性。如果自制測試工具依賴於使用者介面，那麼使用者介面的任何變化（在開發生命週期種，使用者介面經常會經過多次修改）都可能導致自制測試工具對缺陷的漏識別。檢查這樣的結果會浪費大量寶貴的時間。

每個測試用例的執行結果被儲存在一個或者多個結果檔案中，儲存的格式使相同的。與正在測試的系統無關。儲存結果檔案是為了與隨後執行的測試產生的結果進行比較。比較可以有一個定製生成的結果工具來完成，這個工具按照一定的規則讀取和評估結果檔案，並且輸出發現的所有錯誤或者差異。如果我們把結果格式化，那麼也可以透過標準的“file diff”（比較檔案差異）工具對它們進行比較。

與所有的測試型別一樣，自制測試工具使用的測試用例可能使相當複雜的，特別是當自制測試工具所測試的元件使用於數學計算或者科學計算的時候，利用自制的測試工具就可以覆蓋大部分的測試。


更多資料請訪問http://www.universetech.net

相關文章