在傳統的產品研發模式中，單調從需求分析開始到測試驗收結束。開發和測試始終處于產品研發的不同階段，開發人員在產品研發的早期就介人，然后經過一段時間的開發設計，將開發的累計成果轉交給測試人員從而進入到測試階段。在測試完成并提交用戶驗收通過后，產品即可交付使用。這種產品研發模式最大的優點是產品研發的階段劃分明確，職責明確，易于管理。
但是隨著產品復雜程度的增加，操作系統日益龐大，傳統的產品研發模式會給產品質量帶來極大的風險，同時也給研發人員帶來很大的壓力。首先針對累計開發成果的集中測試使得多個測試任務在同時爆發，在測試時問一定的情況下，經常導致分配到單個測試項的時間被一再壓縮，或者優先級較低的測試項將被剔除，很難保質保量按照測試計劃執行。其次即使在規定時間內完成了測試任務，但是沒有充裕的時間針對市場需求、用戶需求、產品定位和質量達標的度量輸入進行充分和全面的測試，難以保證產品已經完全滿足設計要求和用戶需求。
眾所周知，測試作為研發過程的常規部分，最重要的作用是發現問題和及時反饋問題。理想化模型中認為只要能發現問題就能夠修改，但實際中卻要求產品設計之初就必須預留有修正錯誤的接口和方案，否則當產品研發進行到測試階段，產品已經基本定型，如果此時才發現了問題并進行修正，會導致耗費的成本十分昂貴。由此可見，傳統的產品研發模式從本質上推遲了產品風險和問題的暴露時間，可能會導致產品的研發周期延長，研發質量低下，研發成本超支等問題，同時嚴重打擊參與者的積極性和信心，甚至導致整個產品線的失敗。
因此為了在一定程度上解決上述問題，同時滿足新產品研發的需求，我們在華虹新產品的研發過程中，逐漸探索出了一套全新的產品研發模式，稱之為測試驅動開發的迭代研發過程，也稱為(3+2策略)。該研發模式強調測試與開發的齊頭并進，通過對新產品的不斷測試與修正，將設計缺陷扼殺于萌芽狀態，提供產品質量信心，實現產品價值提升。下面將著重介紹我們在實踐中如何使用該迭代研發過程。迭代的概念源自軟件測試，在本文中的定義為，迭代起始于模塊設計，結束于模塊測試通過。首先我們把一個產品研發過程劃分為3個階段(立項、研發、驗收)。各階段的]一作內容都是傳統產品研發模式的流程和工作內容的延續，但是又強調新的突破點。在立項階段，我們強調對用戶需求，投入產出和升級方案的預研，考核的階段成果將匯總為需求輸出到研發團隊;在研發階段，我們強調產品定義時采用模塊化的方式，分離，設計，開發和測試，已成型的模塊，并逐步集成，最終構成完整的系統�？己说碾A段成果將體現為把需求轉化為系統實現;而在驗收階段 ， 就注重技術指標和研發成本的確認， 其階段成果表現為產品成本的控制和客戶驗收通過。其中立項階段的需求輸出和研發階段的設計實現同等重要 ， 只有實現了二者的相互補充和相互制約， 才能保證產品驗收的成功。
其次在進入研發階段后，我們會制定2 類計劃，第一是粗粒度的計劃：也稱為階段計劃。包括從用戶需求、系統設計、概要設計、詳細設計到編碼， 涵蓋了整個產品的研發目錄。主要用于控制產品開發進度和開發周期， 階段計劃制定完成后相對同定， 且必須嚴格執行。第二是細粒度的計劃： 也稱為迭代計劃。包括了任務的詳細說明， 并給每個參與者和參與團隊分配任務，覆蓋到可能的應用場景，分解出關鍵的技術指標。目的用于控制開發質量和開發回溯。迭代計劃通常會隨著開發的深入而動態變化。大家對于執行單一的階段計劃都非常熟悉， 但是在階段計劃中加入了迭代計劃， 研發過程將會發生怎樣的變化呢? 。迭代計劃可以看作是單個階段計劃中的移動窗口， 所起的作用是把階段計劃進行逐級放大。首先將階段計劃中的工作分配到小集體， 繼而分配到每個集體中更小的集體;其次將研發過程化整為零， 從最基礎的模塊開始開發并測試， 逐級累加測試模塊。最后分解出關鍵的技術指標( 模塊) ， 要求必須盡早完成， 這樣就可以在不斷迭代中對其進行徹底的測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
