不斷蔓延的軟件測試基礎結構的危險[1] 軟件測試
來自于 Rational Edge：包含良好自動化測試實踐的基礎結構可以是一個幸事，也可以是一個禍根。這篇文章描述了這樣一種場景，它避免了測試小組隨著時間的推移，產生出不斷蔓延的測試基礎結構。
這是我在項目中的第一天，我把每周一次的關于自動化測試的討論作為文章的開始。我發現即使精通多種操作系統，數據庫，程序語言，并且閱讀過很多產品特性的資料，但我依然很難明白所討論的內容。而且似乎參加會議的每個人都在談論著某種程序語言，而這種語言對我來說卻是陌生的。人們不斷地談到"enabler routines"和API方法，而這些API方法在我所讀過的API文檔中從未見到過。
我花了些工夫才意識到，人們在探討測試框架中的慣例和方法，而不是測試中的產品。在過去的幾年里，測試框架已包括了許多的慣例，這些慣例封裝了實際產品的API方法。
現今這種方法的確有很多優點。它減少了冗余測試代碼，能夠強制使用標準的機制執行任務，并且可以跟蹤API方法的返回值。隨著它不斷的發展，這種特殊的框架結構已經變的如此廣泛以至于它自身已變成一種程序語言。創建整套完整用戶文檔和處理定期框架更新版本的小組成員推薦這種方法。
但是還是有不足之處的。由于測試框架是如此的廣泛，而且許多自動化的測試都基于這個框架，使得維護框架結構和測試變的十分昂貴。為了保持與測試產品的新版本的同步，框架不斷被更新，這不僅使得任務變的越來越大，而且使得像我這樣的新成員不得不花費更多時間學習測試框架。
當我第一次參加會議時，我震驚于人們對于測試框架學習的花費。他們能夠用同樣的方法討論各種"enabler routines"的程序，就像我討論JDBC的使用或者在Java中使用一個數組或矢量的優缺點一樣。
誠實地講，會議有點脅迫的感覺。這有點像身處在外國，而你卻不會講他們的語言一樣。但是我最擔心的是：對我來說似乎提供自動化測試程序框架的過程，能夠使工作變得容易并且有效率，但是我們增加了如此復雜的抽象層，使得人們更少的接觸到所測試的產品�；蛟S我有點夸大其詞了，但這確確實實是我的感受。
Infrastructure-itis
我突然記起幾年前的相似經歷。當時我正創建軟件質量評價小組來檢測Internet防火墻。我們需要一種方法來檢測某些命令行工具，并且決定在Expect中寫測試腳本。開始的兩天進行的很順利，直到Al(不是他的真名)稱他"改進"了Expect。并把他的創造叫做"RunExpect"。你可以想象，它是一串在Expect中寫的封裝好的函數。我感謝他，但是我謝絕成為第二個，最終也是最后一個加入RunExpect用戶社區的人。我選擇使用Expect并且創建我們所需要的并且可隨時使用的慣例。
因此，這里發生了什么?這是經常出現在軟件質量保證團隊中的情況：infrastructure-itis。
什么是infrastructure-itis?這是一個適應壞狀況的很好的主意。這個好主意用來創建(或調整)軟件工具使得測試更加自動化且更有效率。壞狀況就是這些工件的維護變得過于沉重。
如何開發一個infrastructure-itis實例?
它可以從一個小范圍開始。我們可以向他們說，你們正在測試一個數據庫應用程序。你的自動化測試將需要通過一些注冊或者使用者身份驗證的形式訪問數據庫。你可以在每一個測試程序中通過復制代碼來為注冊用戶編號，或者你可以使它成為一個單一的，可調用的例行程序。這是一個好方法。這個例行程序為你的測試程序提供了訪問數據庫的路徑，但它同時使測試程序設計員無法處理注冊程序的準確語義。相反，他們處理可調用例行程序提供的抽象注冊界面。最終，你將創建越來越多的可調用的例行程序來支持測試。
問題是，這些例行程序的創建可以成為它之中和它本身的一個結束，在極端情況下，實際也可以分散你對手邊實際工作的注意力——指的是自動化測試的創建和執行。但它是惡性的循環。你創建一個有用的例行程序，然后再一個，接著又一個，很快所有你所做的工作就是創建，重分解和改進測試的基礎結構。它能使人成癮。做軟件工作的眾多樂趣之一就是你可以隨意設計，創建，然后再設計，再創建。它把軟件的自然特性當作一種媒介。如果你用鋼或花崗巖來工作，重新設計或增加一些東西是很貴的。然而，在軟件工作中，你可以通過按壓鍵盤來完成工作。(是的，有很多鍵，但改變軟件仍然要比建一座吊橋容易。)
文章來源于領測軟件測試網 http://www.kjueaiud.com/