軟件測試分析的重要性

　　前言：

　　之前剛從華為出來寫的一篇文章，拿出來和大家分享下，可能被測對象不同，所面臨的問題也會不同，通訊行業，測試周期長，往往一個版本測試一兩個月很正常，版本質量要求非常高，測試結束準則也非常嚴格，每輪測試必須統計bug數、以及bug收斂趨勢;而在互聯網行業，測試周期很短，因為互聯網行業發展飛速，如果一個需求從開始設計到最終上線發布很長的話，就會處于被動失利的地位。所以在互聯網行業測試分析設計體系還不是顯現的那么明顯，可能這個也做了，但是用的時間不會太多。以下文章可以參考下。

　　測試分析設計體系，一個最主要的目的就是使測試工作前移，加強測試需求分析階段的活動，在軟件分析設計階段就介入測試，使得一些設計方面的缺陷和不足被早期的發現。降低了項目的成本。

　　大家都知道，測試成本隨著產品逐步交付而放大，假如需求分析、設計階段的一些問題沒有被發現，等到編碼階段完成提交測試后才發現了一些問題，而這些問題只能通過更改設計來修復的話，那么不論是測試還是開發的成本就被無形中放大了好幾倍，項目的如期交付的風險會很大。就拿我之前的經歷來說，以前在西安的公司規模比較小，多數情況下測試工作都是在編碼階段結束或者馬上結束才介入的，存在前期投入不足的問題，沒有足夠的人力和時間做測試需求分析，有時候在測試什么都不是十分清楚的情況下才開展測試設計工作，對被測試對象都不是十分清楚的情況下就著手測試的，在測試的過程中才慢慢的了解了被測系統，導致發現的bug數不是一個正常的曲線(剛開始bug數很多，幾個版本后，bug數趨于收斂的趨勢，到最后bug數很少，沒有嚴重、致命的bug)，而是剛開始很少，到后期越來越多的趨勢，而且很多隱藏比較深的bug也是在軟件快要交付的時候才被發現，甚至在上線后暴露(發布后)，這樣的情況下，往往在規定的時間測試無法正常結束，項目也就不能按時交付。那么不論是開發還是測試的成本都很高。

　　測試分析設計體系強調的就是測試需求分析階段活動，這個階段要求有足夠的資源保證完成測試需求分析相關任務，也就是資源保證，一方面要求有經驗的人員投入，一方面要有資料的資源，這個階段投入的是測試部們里面的有經驗的專家或者骨干，或者是系統組成員，通過系統組成員的經驗，充分和開發人員、設計人員進行交流，運用一些工程方法，輸出我們測試需要的的測試內容，同時在測試需求分析過程中，會發現需求或者設計規格錯誤或者不合理的或有遺漏的地方，應及時提出問題，督促開發人員、設計人員進行修改，避免這些問題遺漏到代碼中，在測試執行階段才發現。另外，要求測試部成員投入的一個原因是在設計需求、設計規格或者客戶需求不明確的情況下，通過測試需求分析相關的活動，盡可能獲取完整的信息，現實中，經常遇到這種情況，如果直接進行用例設計，測試完備性無法保證，此時更要加強測試需求分析階段工作，只有弄懂測試的原始需求才能開展測試設計工作，清楚我們所要測試的系統是在什么環境、場景下運行的，測試設計中就能更逼真的模擬被測對象實際運行的場景，構造一些測試場景，使得測試做的更加充分，如何獲取這些需求也是測試的核心能力之一。

　　一句話：整個的測試分析階段是為后續的測試用例設計做準備的。前期準備工作不充分，后期的工作也就無法保證。

原文轉自：http://www.anti-gravitydesign.com