迭代式軟體開發模式簡要流程如下：

        上圖綠色大框內，我們就稱之為一個迭代週期。每一個迭代，都可以形成一個可交付的小版本。事實上，每一個迭代週期內，對於編碼和測試也可以進行多次迭代。通過快速釋出測試構建的方式，驗證開發完成的新功能，再通過測試發現問題來驅動開發人員對軟體進行修改完善，迴圈往復。即：根據開發情況有針對性地組織測試，根據測試結果反作用於開發人員去完善軟體質量。以這種小步快跑的方式，經過若干測試構建後，軟體質量可以在較短時間內達到穩定狀態。

質量保證，需要系統性的方法。那麼在迭代式開發的各個階段，都需要怎樣的措施呢？

1）需求

        這個階段的主要工作是需求制定與評審。該階段的工作分三步走：收集原始需求 ->制定產品需求 -> 產品需求評審。具體說來，首先我們通過各種渠道收集原始需求，由於原始需求多半是概念性的、模糊的，不能直接用來指導開發工作，所以需要進行歸類、篩選，整合為產品需求。基本原則是，結合當前開發產品的特性，爭取以最小的改動以及最大的可擴充套件性來制定產品需求。降低風險，同時提高靈活性。經驗告訴我們，在需求沒有考慮透徹的情況下，不要貿然開始設計並實現，可能導致大量返工，費時費力。產品需求制定好後，需要進行評審，一定不要覺得浪費時間而不去評審，磨刀不誤砍柴工嘛！

2） 設計

         這個階段的主要工作是將產品需求轉化為設計需求，指導後續的編碼工作。軟體行業有一名老話是：軟體質量是設計出來的，對於迭代式開發也是如此。設計的好壞直接決定了軟體質量的高低。設計需求一般闡述了產品需求的詳細設計方案，包括頁面佈局、資料結構、演算法以及易用性、安全性、可擴充套件性、健壯性和效能等諸多方面的設計思路。即使讓不同的開發人員根據設計需求來進行編碼，開發出的功能也八九不離十。有此可見，設計需求是非常必要的。也就是說，我們在正式編碼前，必須針對需求寫出相應的設計文件來指導後續的編碼工作。這樣做有兩大好處：一是在編碼之前就充分預見到將來可能遇到的問題，可以儘早規避風險；二是為開發工作搭好框架，降低因開發人員的差異導致開發過程的不確定性，避免出現“一千個人心中有一千個對需求的理解”。

3） 編碼

         這個階段的主要工作是嚴格按照設計需求來完成編碼，並組織進行程式碼評審。每一行程式碼都是軟體大廈的一磚一瓦，我們拒絕豆腐渣工程，所以我們重視每一行程式碼。進行程式碼評審可以有效保證程式碼質量，藉助一些IT管理工具可以輕鬆進行程式碼評審和程式碼管理。筆者曾經使用過青銅器RDM軟體來做程式碼評審（CodeReview），十分方便。程式碼評審的重點應該是對程式結構的審查，發現深層次的軟體錯誤，而不要停留在表面。同時，建議大家在做程式碼評審時，以程式碼的一個“提交”為單位進行評審。這樣做的前提是，每個“提交”裡包含相對完整的功能。對於迭代式開發，我們要儘量保證，每一個編碼-測試迭代裡，都要完成相對獨立、可測試性強的功能點。

4） 測試

        測試實質上是一種鑑定性的工作，是對軟體質量的鑑定和最後一道把關。這個階段的主要工作是，在每一個測試構建中，儘可能多地覆蓋需求點，並根據輕重緩急合理安排測試優先順序，儘可能將影響較大的缺陷提前暴露出來。測試優先順序的安排應遵循以下原則：

       a、先測試經過變更的部分，然後測試沒有變更的部分

       b、先測試程式的核心功能，然後測試一般功能

       c、先測試邏輯性的功能，然後測試業務性的功能

       d、先測試常規情況，然後測試異常情況

       e、先測試功能，然後測試效能

       按照上述原則進行測試，可以更快地發現更多軟體中的嚴重錯誤，這是使軟體能儘快穩定下來的一個關鍵因素。除此以外，在每一個迭代週期結束之前還要進行系統測試。

       編碼-測試的不斷迭代，保證了每個測試構建裡的新功能沒有問題，但整個軟體系統的質量還沒有得到充分驗證，系統測試就是為此而生。在版本釋出前的最後衝刺階段，“車輪戰”是很管用的一個手段，即：調集測試人員、開發人員等全面參與測試，將這些人員分為若干個小組，每個小組分別對系統進行測試。每個測試模組由多人進行測試，可以有效降低缺陷的遺漏率。但需要注意的是，開發人員應該避免測試自己開發的功能，即進行交叉測試。

       軟體質量保證的實質是，使用一些流程、方法來管控軟體開發過程，從而使最終交付的軟體產品質量得到最大程度的保證。同時，相信大家可以看出，在整個產品開發過程中會產生很多資料，如需求、設計文件、程式碼、測試用例、缺陷等。使用IT管理工具可以有效提高工作效率，青銅器RDM全面實現CodeReview+Testlink + Mantis功能組合，可以管理需求、測試用例、缺陷、程式碼評審等，對於小規模團隊，已經足夠用了。