軟件測試中的過度設計

　　中國有句老話：過猶不及。軟件開發中也有一個概念：“過度設計”，說的是為了實現一些簡單的功能需求，設計出非常臃腫的結構，代碼間的繼承、依賴、調用非常復雜，開發工作量大并且難以維護。在軟件測試工作中，也存在類似“過度設計”的問題，特別是大中型的軟件企業，人數比較多，各方面工作流程趨于穩定和規范，問題更容易發生。

　　出現“過度測試”的原因非常簡單：忽視了軟件測試工作的終極目標與核心價值，而過于關注測試活動過程。這里我列出一些“過度測試”的案例，我們一起分析一下。

　　測試工作必須依賴完整規范的需求文檔

　　回憶一下公司創業初期，那時做項目也沒有特別規范的文檔，一般就是幾個Excel表格、一些Word說明，不過項目也都順利完成了?？墒乾F在好像如果沒有規范的文檔，測試工作就寸步難行了，為什么呢?我們經?？吹綔y試工程師整天催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，如果我們把目錄結構設計很嚴謹的話，會產生下面這種目錄：

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