軟件測試中保證軟件質量的關鍵要素
軟件在沒有發布之前的開發過程主要分為需求分析、設計、編碼和驗證四個階段，最終的軟件質量與這四個階段的各自質量之間的關系如果用C語言來表達的話應當是：
最終的軟件質量 = 需求分析質量 && 設計質量 && 編碼質量 && 驗證質量
即，最終的質量來自于各階段質量之“與”，只要其中一個環節質量是差，則產品的整體質量都將是差，千萬不要認為是“或”的關系。由此看來每一個階段的質量都起著決定性的作用。
以上提及的四個階段的質量將引出以下幾個軟件質量保證的關鍵要素。
完備的需求分析
需求分析的目的是讓項目組明白要做什么，是決定所開發出來的軟件應當是“長什么樣的”，顯然完備的需求分析是高質量軟件的前提。如果所開發出來的軟件與用戶所希望的并不一致，那不可能讓用戶說“這個軟件的質量很好” 。如果方向不對，軟件開發得再“好”也沒有意義。需求分析失誤所帶來的開發成本是高昂的，這一點在《軟件工程》這類書籍中都會提及，因此，整個行業對于需求分析的重要性都具有足夠的認識。當然，知道其重要性與如何獲得完備的需求分析又是兩回事，至于如何做好需求分析請讀者參考相關書籍。
需求分析如果出現失誤的話有一個特點 —— 它一定會暴露！只不過存在是暴露在軟件開發過程中還是在用戶手中之別。因此，需求分析所造成的問題盡管嚴重，但它能被發現進而能得到項目組的重視，從而也一定能被修復，只是不同階段發現這類問題所花費的成本將有所不同。
設計
設計階段是通過設計方法找出軟件實現更好的方法，注意這里是“更好”兩個字，而不是強調最好。
不良設計并不會象需求分析失誤那樣很容易暴露出其本質，相反，它所暴露出的更多是表象，比如邏輯復雜、維護時舉步為艱等等。如果參與者不具備一定的洞察力以發現隱藏在現象背后的不良設計本質，則很有可能身受其害卻不能自拔，還以為“本來就有那么復雜”。
項目的開發是一個逐步演進的過程，項目組成員對于需求的理解也是逐步加深的，一開始合適的設計到后面看來很有可能就不夠全面或顯得力不從心，如果仍沿用以前的設計則自然將暴露出它的不足，進而會出現需要更高的維護成本。重構思想的提出，就是用于幫助項目演進設計的，當然，在運用重構方法時，應盡可能保證項目有足夠的單元測試用例，以預防重構時又引入新的缺陷。重構不只是一個詞，其核心應當是一個方法論，一個用于優化設計的方法論。
編程好習慣
設計階段輸出的結果就是藍圖，但好的藍圖并不能保證最后的質量一定就好。拿造房子打個比方，圖紙設計得再好，如果建造時用的材料不過關，那最終的房子一定好不了。那軟件開發中的“建筑材料”又是什么呢？就是程序員所編寫的代碼。如何保證其質量呢？這需要通過良好的編程習慣去保證。
在現實的項目中，設計有可能與編碼會有一定的揉合，即通過進行一定的編碼來輔助設計。這種實踐方式并不影響這里將設計與編碼分為兩個質量保證關鍵要素。
驗證
驗證很容易讓人想到質量保證的常用方法之一，即測試。但驗證應當包含更多的內涵，比如求證軟件需求是用戶所希望的就是其中的一種。
對于驗證的理解仍需要拿房屋的建造作為一個比方，以便加深理解。在房屋的建造過程中，當建筑材料到了工地以后，需要對其進行檢驗，以保證它的質量是合格的，否則不能用于建造。對應于軟件開發，這個階段就是單元測試。當軟件工程師編寫了代碼以后如何保證代碼的行為是其所希望的呢？那只能通過單元測試去驗證。房子建造好了以后，還得對房子進行整體的驗收以確保其最終是合格的。比如抽查墻壁所使用的水泥與沙的配比是合適的。雖然水泥和沙在進入工地時都經過了質檢且是合格的，但在建造的過程中需要按一定的比例混合它們以作建筑粘合劑，而混合比例將確定粘合強度。在軟件開發過程中，軟件集成測試就如同房子在建造好了以后的驗收。
從上面的比方能得出幾個結論。第一，在軟件開發過程中單元測試是必不可少的。它的缺少如同將沒有檢驗過的建筑材料用于建造一樣。第二，單元測試應當在集成測試之前完成。有的項目在一開始時并沒有單元測試流程，但后來發現需要增加這個環節，于是出現了集成測試完成了以后，再進行單元測試這種情形。這種情形還是有點怪怪的，這如同房子已造好了，再將墻打掉去檢查里面的磚是否是好的一樣�！皩Υ虻魴z查磚”這種行為的勇氣雖然可佳，但是如果盡早地在項目中部署單元測試就能避免這種怪現象的發生。
集成（包括開發集成和系統集成）測試在軟件行業被廣泛采用以保證軟件質量，但單元測試對于軟件質量保證的重要性在整個行業還缺乏廣泛的、深刻的認識，其更多地被當作是負擔而不是一種有效的質量保證手段。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
