軟體測試中過度設計的那些事兒

過猶不及，這是古代《論語》中的一個成語，做得過了就好比沒有做夠一樣。在軟體測試行業中同樣也會存在過度測試的情況，今天我就班門弄斧一下說說我對過度測試的理解。

　　很詳細的需求文件會導致維護成本劇增

　　我所經歷過的專案中有過幾種很有代表性的PRD（product requirement document的簡稱，即產品需求文件）：

　　1、很詳細的文件，詳細到會定義一個連結是新開一個tab還是在原tab開啟，告訴你你想知道的一切資訊；

　　2、包含了產品主要功能流程的文件，會以流程圖輔助說明，不會太細化，細節性的內容更多要通過交流和討論獲取；

　　3、一封郵件說明或直接幾個人討論決定。

　　特別對於網際網路專案，需求變更頻繁，需求資訊巨多，對於PM（產品經理）來說，完成一篇很詳細的文件需要的時間不說，每次的需求變更或評審後的需求漏洞都需要更新到PRD中，對於測試人員而言，需要重新閱讀PRD中改動的部分，而且詳細的需求就需要更詳細的用例來覆蓋，是否有必要這麼詳細的文件呢？對於網際網路專案能保持一年不大改都是少有的了，我們是否有必要考慮下不為文件所累呢。

　　詳細的測試用例會拖累我們

　　以前我的觀點一直都是秉承著一個基準來要求我自己和團隊其他人來寫用例：讓不懂業務的人也能順手拈來執行用例。而在後來的一段時間，用例維護起來竟是如此頭疼，每次更新詳細的測試步驟和結果都需要大量的時間，而且發現專案中很少有讓一個不熟悉業務的人來執行這些用例的時候，即便是新人來了看著用例仍然比較迷惑，仍然會多次詢問詳細的業務，發現還是PRD看著更系統更有邏輯條例，能更快的瞭解業務內容。畢竟看著用例，我們彷彿執行了40，50條用例仍然在一個功能上，根本不能跟其他功能串起來，對於業務的熟悉是多大的阻礙啊。我覺得從巨集觀到微觀再到巨集觀才是正確之道。而對於測試技能則更需要導師指導，並不能從用例中掌握太多東西，除了考慮問題的周密性外。

　　之前在維護用例的目錄時也有過度維護的情況，比如有AB兩個頁面都有一個子功能C，每次迴歸測試時需要對AB兩個頁面上功能進行迴歸，避免遺漏，就把C對於的用例都copy到AB兩個目錄下了，那麼每次更新維護時也都需要維護多份，重複的工作可想而知。

　　如何讓用例不拖累我們呢？

　　標題能說明的就無需步驟和結果，內容太多實在是放不下的時候再有詳細步驟和結果說明，可以以附件形式上傳excel表格的多條用例，不要為了規範而規範，而且用例多是給測試執行人員使用的，不是為了讓新人瞭解業務而存在的。目錄結果過於臃腫的再優化，比如C有專門的目錄存放用例，AB下建個目錄僅說明有C這項功能，好比是linux下的軟連結，原來那種方式連硬連結都不如，它不能同步更新（PS.我們使用的是QC管理用例）。

　　過度設計的用例會降低我們的效率

　　你是否遇到過這樣的情況，比如有三個輸入框，但是沒有很強的邏輯關聯，只不過他們是必填項決定著是否能成功提交，如果設計出8個case來覆蓋是必填項這個條件才夠放心的話，對於有更多的輸入框時我們是否會崩潰掉呢？

　　另外一種情況，比如需要呼叫第三方分享，就說微博吧，我們是否需要覆蓋含有特殊字元的文字內容能否成功分享，超長文字內容能否成功分享？

　　上面這兩種很顯然是過度設計，我們完全沒有必要為了這類等價類邊界值的case用判定表方式來完成，像這型別很簡單的頁面控制元件，應該編寫好統一的測試用例集，不同的也就是字元長度限制了。我們也沒有必要花心思來測試第三方軟體。當然工作中可能還有很多類似這樣過度設計的案例，工作經驗比較足的人都能從過往中總結出我們更有效的測試思路。

……

文章出處：51Testing軟體測試網http://www.51testing.com/html/10/n-848410.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1060661/，如需轉載，請註明出處，否則將追究法律責任。