軟件測試中的過度設計(2)

　　其實我們用一個Matrix就足以把這一組TC說清楚了，根本不用分這么多目錄結構，如下圖：

　　商業工具給我們提供目錄功能，是想幫助我們整理設計思路，不過如果我們設計過度，就會把自己搞暈，所以目錄結構的設計，盡量扁平，多使用Matrix來描述TC。

　　對頁面控件的靜態校驗TC要設計得很完整

　　我在參與一些項目的TC評審的時候，經常能看到大量的WEB控件靜態校驗TC，比如文本框的“不填任何字符”、“填數字”、“填漢字”、“填超過20個字符”，再比如Grid控件的“上一頁”、“下一頁”、“最后一頁”等等。其實這些TC模樣都差不多，不同的只是控件的名稱，還有控件屬性(例如最大字符數)。編寫這些TC無疑要花費大量的人力，有的甚至為了寫一個 “不填任何字符”這樣的簡單TC，要寫出上百個漢字來。

　　對于這些非常成熟的WEB控件，一般每個開發團隊都會有一套成熟的框架，出錯的可能性不是很大。另一方面，成熟的測試團隊也必然會沉淀出一些對控件進行靜態測試的方法和規范。即使我們不寫這些TC，只要我們搞清楚每個控件的屬性，明確每個控件的標準測試方法，是完全可以很好的覆蓋這些靜態TC的，實在沒有必要讓“等價類”、“邊界值”這些測試理論在靜態校驗上發揮的淋漓盡致。我們關注的重點應該是業務邏輯，還有程序的內部結構。

　　自動化覆蓋率越高越好

　　關于自動化覆蓋率的問題，爭論一直沒有停止。大家也都同意，自動化腳本多了不好，少了也不行，至于到底多少才是最好，誰也說不清。其實我也說不清，所以這里也不多羅嗦了，只想說一點，互聯網軟件的特點是創新多，變化快，因此相應文檔(比如需求、TC、自動腳本)的壽命都是短暫的，測試團隊如果花費大量的成本來維護這些文檔，很容易造成“測試過度”，疲憊不堪。不同于傳統軟件行業，互聯網軟件的測試團隊，更注重于靈活輕便，善于應對頻繁的軟件變化，對自己的產品有著透徹的了解，不管是業務需求還是程序結構，這一點非常重要。

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