中國有句老話：過猶不及。軟件開發中也有一個概念：“過度設計”，說的是為了實現一些簡單的功能需求，設計出非常臃腫的結構，代碼間的繼承、依賴、調用非常復雜，開發工作量大并且難以維護。在軟件測試工作中，也存在類似“過度設計”的問題，特別是大中型的軟件企業，人數比較多，各方面工作流程趨于穩定和規范，問題更容易發生。
出現“過度測試”的原因非常簡單：忽視了軟件測試工作的終極目標與核心價值，而過于關注測試活動過程。這里我列出一些“過度測試”的案例，我們一起分析一下。
測試工作必須依賴完整規范的需求文檔
回憶一下公司創業初期，那時做項目也沒有特別規范的文檔，一般就是幾個Excel表格、一些Word說明，不過項目也都順利完成了�？墒乾F在好像如果沒有規范的文檔，測試工作就寸步難行了，為什么呢?我們經�？吹�測試工程師整天催PD和DEV把文檔補全，催得很辛苦也很郁悶，看起來就像是測試團隊要為文檔的質量負責一樣。有時甚至出現了，測試團隊自己動手維護需求文檔的現象。是不是測試團隊不拿著一份完善的文檔，就寢食難安呢?
對于測試團隊來說，需求文檔確實很重要，但是我們真正的目標是，弄清用戶的需求和開發的實現方案，然后便可以設計測試方案。閱讀文檔是方法之一，交流和討論其實更重要，期待文檔中能說明一切信息，是有點不實際的，特別是互聯網公司，需求信息爆炸，創新層出不窮，文檔更像是字典，只記錄重要的原子信息，而要把它們串聯起來，更多是靠人與人的溝通。
過分糾纏于文檔的細節，會消耗測試工程師很多工作量，而且心情也搞壞了。如果你加入一個文檔很完善很規范的項目組，那么恭喜你。如果你遇到一個文檔不全的項目，也不用懊惱，想辦法把需求弄清楚，把關鍵的邏輯搞明白，找出需求中的重要漏洞，就可以了。有的人會問：文檔不全，以后怎么傳承給測試的新人呢?在這篇文章里，“傳承給測試新人”這個概念會經常出現，并且成為“過度測試”的主要原因之一了。這里請大家思考一下，新人培訓到底應該怎么做，是不是非要投入這么大，做得面面俱到。況且，互聯網的需求變化極快，即使要傳承，又能傳多久呢?
每個測試用例都要讓一個完全不懂業務的新人看懂
這個觀點跟測試用例(TC)的編寫詳細程度有關。在這個觀點的指引下，每個TC都寫成了一個小型的說明書，閱讀起來確實很詳細，不過測試工作量陡然增加，不禁懷念以前用Excel寫TC的年代。
要分析這個問題，首先要看一下設計TC、執行TC的實際場景。在設計TC時，往往都是針對一個功能模塊，設計一組TC，也就是測試集(TestSuite)。這一組TC有著相似的操作過程，前置條件，校驗手段，它們不同的是輸入數據、輸出結果。在執行TC的時候，測試集的概念更加明顯。熟練的測試人員肯定不是看一個TC執行一個TC，而是把一組TC放在一起，一口氣執行。所以設計TC的時候，應該是以測試集為對象，而不是把一個TC作為一個對象。
再說說如何讓新人看懂TC。請大家思考一下，TC的作用究竟是為了指導測試執行，還是為了讓新人熟悉業務?一組TC每個月可能會被新人閱讀1～2次，但是會被測試執行人員閱讀20-30次，我們寫TC是不是更應該方便執行人員而不是新人。TC不是培訓資料，我們不能靠把每個TC都寫得無比詳細，來對新人進行“培訓”。新人要學習業務和測試技巧，需要依靠的是師傅指導，是知識沉淀文檔。
互聯網的產品，需求變化非�？�，基本上1年就會發生一次很大的變化，所以一般的TC壽命也只有1年，何苦為了TC這么糾結呢?只要TC寫出來能發揮它本來的作用，就可以了。
測試用例的目錄結構要進行嚴格的分類
現在很多測試團隊都使用商業軟件來管理TC，一般都是用一個“目錄樹”來對TC進行分類，類似于windows的文件夾，目錄的主要作用是讓TC的讀者清楚的了解TC設計邏輯。TC目錄怎么組織，也是有一些講究的，并不是分類越細越好。我曾經看到過，TC目錄超過10級，分類非常嚴謹，可是展開目錄，閱讀的時候，就很不方便了。
看一個例子：比如我們測試windows的復制文件功能，需要考慮文件大小、文件類型、磁盤分區這3個維度，每個維度有很多數據，比如磁盤分區有FAT、FAT32、NTFS，這些數據組合起來，就形成了一組TC，如果我們把目錄結構設計很嚴謹的話，會產生下面這種目錄：
其實我們用一個Matrix就足以把這一組TC說清楚了，根本不用分這么多目錄結構，如下圖：
商業工具給我們提供目錄功能，是想幫助我們整理設計思路，不過如果我們設計過度，就會把自己搞暈，所以目錄結構的設計，盡量扁平，多使用Matrix來描述TC。
對頁面控件的靜態校驗TC要設計得很完整
我在參與一些項目的TC評審的時候，經常能看到大量的WEB控件靜態校驗TC，比如文本框的“不填任何字符”、“填數字”、“填漢字”、“填超過20個字符”，再比如Grid控件的“上一頁”、“下一頁”、“最后一頁”等等。其實這些TC模樣都差不多，不同的只是控件的名稱，還有控件屬性(例如最大字符數)。編寫這些TC無疑要花費大量的人力，有的甚至為了寫一個“不填任何字符”這樣的簡單TC，要寫出上百個漢字來。
對于這些非常成熟的WEB控件，一般每個開發團隊都會有一套成熟的框架，出錯的可能性不是很大。另一方面，成熟的測試團隊也必然會沉淀出一些對控件進行靜態測試的方法和規范。即使我們不寫這些TC，只要我們搞清楚每個控件的屬性，明確每個控件的標準測試方法，是完全可以很好的覆蓋這些靜態TC的，實在沒有必要讓“等價類”、“邊界值”這些測試理論在靜態校驗上發揮的淋漓盡致。我們關注的重點應該是業務邏輯，還有程序的內部結構。
自動化覆蓋率越高越好
關于自動化覆蓋率的問題，爭論一直沒有停止。大家也都同意，自動化腳本多了不好，少了也不行，至于到底多少才是最好，誰也說不清。其實我也說不清，所以這里也不多羅嗦了，只想說一點，互聯網軟件的特點是創新多，變化快，因此相應文檔(比如需求、TC、自動腳本)的壽命都是短暫的，測試團隊如果花費大量的成本來維護這些文檔，很容易造成“測試過度”，疲憊不堪。不同于傳統軟件行業，互聯網軟件的測試團隊，更注重于靈活輕便，善于應對頻繁的軟件變化，對自己的產品有著透徹的了解，不管是業務需求還是程序結構，這一點非常重要。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
