一種有效的軟件測試策略(2)

　　要建立有效的皮下測試，我們可以嘗試通過常見的邏輯流程建立uniform pinch points。例如，我們可以建立一個命令消息處理系統，或一個普通的查詢界面。在最近的一個處理批處理文件項目上，批處理文件中的每一行都被轉換為一條消息。然后，我們創造一條消息，發送給這個系統，然后驗證處理該消息的所有異常情況。

　　由于皮下測試不是基于設計而是基于高級(業務)行為，它們是理想的基于場景的測試策略，如BDD或Testcase Class per Fixture模式。如果我們要進行大的重構，我們需要這些高層次的測試，為商業行為建立全面的安全保障。由于皮下測試更關注于端對端的邏輯，所以它也是標志功能點完成的一個重要的目標點。

　　雖然皮下測試使我們能夠安全地執行較大的重構，但它仍無法保證我們可以放心地將系統升級到生產環境。

　　全系統測試策略

　　起初，我們把全系統測試稱為“UI 測試”，直到我們的項目越來越多地牽涉到集成策略。這時輸入到我們系統中的不再是瀏覽器，取而代之的是消息，來自 REST 端點、FTP 或批處理文件。UI 測試只是全系統測試的一個子集。全系統測試背后的思想是，我們想按照軟件在生產環境中的使用方式來測試它們。對于一個 MVC 應用程序來說，就是基于瀏覽器的測試。對于批處理文件來說，我們會使用實際的文件。對于 REST 使用實際的 HTTP 請求。對于消息則使用實際的隊列和消息。

　　如果我們想知道，應用程序在部署到生產環境之前是否能按照預期工作，一個有效而且高效的方法是，創建一個自動化測試來測試整個系統。如果我可以讓 UI 測試登錄到應用程序中、創建一個訂單，然后我可以驗證是否產生了一個訂單請求，那么我會感覺很良好。

　　關于全系統測試的一個常見誤區是認為它就是黑盒測試。然而，全系統測試的特點在于，你必須對系統內部發生的事情了如指掌。實際上，全系統測試甚至還可以利用域模型來生成數據，而不是一個純粹為測試目的而構建的系統后門。很多團隊容易掉進去的一個大坑是，不按照與生產環境一樣的代碼路徑來測試，這將導致系統處于古怪的、無效的、很難處理的狀態。

　　在我們的項目中，全系統測試代碼是我們在聲稱一個功能/故事做完之前的所寫的最后代碼。對于描述一個功能的“已完成”特性來說，手工測試的成本太高、而且不可靠。但是，如果我能像在生產環境一樣去測試，通過完全一樣的外部界面來完成，那這樣的手工測試也算是成功的。

　　全盤考慮

　　在一個未經測試過的應用程序中，作為提高覆蓋率的手段，我們發現實際上最有價值的測試策略是從全系統測試開始，然后往下移，直至單元測試。我們先做最寬松、最簡單的斷言，然后慢慢往下移，直至單元級別的邏輯。在全新開發的應用程序中，我們傾向于不只是特別關注某一個區域，因為對于一個需要長期維護的系統來說，所有的測試都很重要。

　　這種測試策略確實需要一定的投資。我們發現，當我們知道這個應用程序對客戶的業務有決定性作用的時候，這樣的全盤考慮在特別有效。如果一個應用程序對業務有決定性作用，那它將不得不面臨變更。當變更來臨的時候，我們最好能安全地實施變更而不影響客戶的業務。

　　作者簡介

　　Jimmy Bogard是德克薩斯州Headspring公司的技術架構師,致力于研究DDD,分部式系統和其他acronym-centric design/架構/方法論的研究.同時也是AutoMapper的創始人和ASP.NET MVC in Action的作者

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