測試驅動的開發——概述(2)

　　第二個進行web應用自動測試的主要方法就是通過編程API。這樣你就有了測試框架，軟件庫可以檢查條件是否滿足，報告錯誤的數量和類型，你可以在測試代碼中調用這個框架。你的測試代碼就是繼承自測試框架的一套類，它們從應用代碼中初始化對象，調用方法來驗證給定輸入會得到預期的結果。采用編程API方案的包括JUnit、HttpUnit、各種單元測試和黑盒web測試的工具等等。這種方案非常靈活，大多數情況下它大大減少了測試代碼的維護時間，并且使應用中的復雜功能測試成為可能，尤其是服務器端應用。這種測試可交替的調用 programmatic testing，API-driven testing，或者programmatic API-driven testing。

　　相對于recorded macros模式來說，基于API的自動測試方法的第一個弱點是它的需要更長創建時間。當你的問題是鼠標移動和點擊時很難減少設置時間。第二個問題是絕大多數客戶不會寫測試程序的?？蛻袅私獾氖菢I務過程，而不是技術，客戶可能覺得移動鼠標和點擊鼠標容易得多，這一點非常重要，如果你想讓客戶在開發過程中就參與進來的話，客戶參與是極限編程的鼓吹者推薦的方法。

　　雖然如此，基于API的方法在許多方面存在著優越性，可以在大多數應用中使用，因為應用程序隨時間改變的程序非常大，所以花在測試程序維護上的時間比測試程序的創建時間占的比例更大。而且recorded macro方法有一個致命限制：只有在應用代碼寫完之后你才能建立測試。如果你們的開發習慣是不在程序完成前測試，那非常好。否則，如果你堅持測試先行的習慣，正如作者推薦的，那非常不幸recorded macros不適合你，因為在記錄宏進行重放之前，你必須有一個能運行的應用程序。

　　好的方案可能既有recorded macros測試，又有基于API的程序化測試。通過鼠標拖點式測試你可以讓最終用戶參與到測試中來，保證你的程序滿足業務需求。通過程序化測試則可以在技術角度確保程序組件按預計的情況工作。

　　使用程序化測試，你有兩種選擇：功能測試和單元測試。功能測試也叫做黑盒測試，是指在不知道(或者忽略)內部實現的情況下，在一個較高的層次上進行測試。功能測試用于驗證程序是否完成業務需求，它模擬采用與最終用戶一致的方式與程序進行交互。最終用戶可能是使用基于web應用的業務人員，也可能是通過你所提供的API來使用你的類庫的開發人員。如果你一定要糾纏概念，功能測試和黑盒測試還是有一些區別的，因為技術上功能測試可以在容器內進行(如果要測得是web程序的話)，但實際上絕大多數功能測試是在黑盒中做，除了公布的接口外你一無所知。相反，單元測試包括底層代碼的驗證，為了對確保內部組件沒有問題，必須了解程序的內部結構。你還需要知道那些類和方法的實現。如果要測的程序是給開發人員使用的軟件庫，你的單元測試包括所有重要的類和方法，甚至在發布給用戶的API文檔中沒有列出的內容。功能測試與程序交互的方式是通過點擊按鈕和信息入口，進入程序可見的forms。單元測試與程序的交互是通過Java方法調用來訪問。

　　對前面提到的手工測試的四個缺陷，自動測試都給出了很好的解決：

　　排除重復。用自動測試你可以把這項工作交給計算機去辦，它們將嚴格按照你每次測試的流程進行操作。

　　減少錯誤。計算機每次都用同樣的方式執行重復操作。而且，因為測試是cumulative，而且容易調用，即使某一些代碼修改在直接影響范圍之外很遠的地方造成破壞，你仍然能找到這個錯誤，因為你以前寫的檢查那些(被破壞的部分)代碼的測試會告訴你。自動測試的cumulative是一個非常有用的特點，也是相對手工測試來說一個重要的優點。用手工測試來檢查程序的其它部分是不切實際的。

　　允許組件的獨立測試。自動測試，至少其中的基于API的程序化方式，可以讓你測試程序的不可視部分，例如你認為是程序核心的業務邏輯。編程測試在其它程序(測試代碼)中調用你的代碼。粒度由你自己把握。如果不考慮程序的任何內部實現，你可以模擬一個 web瀏覽器或者使用鼠標操作桌面的用戶，進行黑盒或功能測試。你也可以調用類庫德公共API，因為你不考慮API內部的實現，這也可以算作一種黑盒或功能測試。你還可以調用隱藏類或公共類的內部方法，來驗證它們按你想的方式工作，因為針對的是獨立的方法和類，而且你會知道算法等內部實現細節，這就是單元測試。你要做什么測試，就選擇什么級別的細節。

原文轉自：http://www.uml.org.cn/Test/200911101.asp