CMMI5在小型項目中的成本過(guò)高，對CMMI5的實(shí)施體會(huì )與在實(shí)際項目中的應用分析，在項目實(shí)施的過(guò)程中精簡(jiǎn)了CMMI5的實(shí)施流程和部分文檔，這個(gè)精簡(jiǎn)的流程在項目實(shí)施的過(guò)程中既可以確保流程規范與質(zhì)量信賴(lài)又可以節約項目成本： 

一、需求與規范的管理 

1、 由測試負責人（或專(zhuān)門(mén)的需求分析負責人）統一接收來(lái)自移動(dòng)總的行業(yè)網(wǎng)關(guān)相關(guān)規范和新需求，測試負責人瀏覽規范獲知大意后回復郵件，將規范和新需求轉發(fā)給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)的開(kāi)發(fā)人員和測試人員，同時(shí)commit到CVS； 

2、 測試負責人（或專(zhuān)門(mén)的需求分析負責人）、項目經(jīng)理仔細閱讀規范與需求后，對規范和新需求進(jìn)行研究，并就難點(diǎn)和疑點(diǎn)進(jìn)行討論，整理出重點(diǎn)內容，并將重點(diǎn)內容發(fā)給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)的開(kāi)發(fā)人員和測試人員，同時(shí)commit到CVS； 

3、 開(kāi)發(fā)經(jīng)理、項目經(jīng)理、測試負責人、需求分析負責人、相關(guān)的開(kāi)發(fā)人員與測試人員開(kāi)會(huì )對規范、需求和重點(diǎn)內容進(jìn)行討論，確定需求的具體含義以及最終實(shí)現的需求和功能點(diǎn)； 

4、 項目經(jīng)理根據規范、需求和開(kāi)會(huì )討論結果編寫(xiě)《需求規格說(shuō)明書(shū)》與《功能列表》，測試負責人（或專(zhuān)門(mén)的需求分析負責人）對文檔進(jìn)行檢查并修改完善，然后commit到CVS； 

5、 測試負責人（或專(zhuān)門(mén)的PPQA）確認所有相關(guān)文檔經(jīng)過(guò)了評審并都已經(jīng)commit到CVS。 

二、項目計劃與測試計劃 

1、 由開(kāi)發(fā)經(jīng)理組織項目計劃討論會(huì )，在討論會(huì )上各開(kāi)發(fā)負責人對自己所負責的模塊所需要的工作量進(jìn)行評估，根據工作量和工程需求初步確定總體開(kāi)發(fā)計劃、測試計劃和發(fā)布時(shí)間； 

2、項目經(jīng)理根據估算工作量和工程需求編寫(xiě)項目計劃，使用CMMI5總體測試計劃模板并對其進(jìn)行適當的裁剪和補充，編寫(xiě)適合本項目的項目計劃； 

3、測試負責人根據項目計劃與發(fā)布時(shí)間編寫(xiě)測試計劃，使用CMMI5總體測試計劃模板并對其進(jìn)行適當的裁剪和補充，編寫(xiě)適合本項目的測試計劃； 

4、項目計劃與測試計劃編寫(xiě)完成后發(fā)送給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)的開(kāi)發(fā)人員和測試人員，開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)的開(kāi)發(fā)人員和測試人員閱讀項目計劃、測試計劃后將建議和意見(jiàn)以郵件的形式反饋給項目經(jīng)理與測試負責人，項目經(jīng)理與測試負責人收集大家的郵件分別對項目計劃與測試計劃進(jìn)行修改完善，同時(shí)回復郵件說(shuō)明項目計劃與測試計劃修改情況，如果存在爭議則召開(kāi)一個(gè)小型會(huì )議對異議進(jìn)行討論，修改后的項目計劃、測試計劃commit到CVS； 

5、測試負責人（或專(zhuān)門(mén)的PPQA）確認所有相關(guān)文檔經(jīng)過(guò)了評審并都已經(jīng)commit到CVS。 

三、開(kāi)發(fā)設計與評審 

1、 項目經(jīng)理構思系統設計，項目組開(kāi)發(fā)成員一起討論系統的設計，對設計形成較為清晰的思路； 

2、 項目經(jīng)理負責編寫(xiě)概要設計文檔，與開(kāi)發(fā)經(jīng)理、開(kāi)發(fā)團隊成員與測試負責人一起討論概要設計； 

3、 概要設計完成后，項目經(jīng)理編寫(xiě)詳細設計文檔、數據庫設計文檔和編碼規范，各模塊負責人負責編寫(xiě)所負責的模塊進(jìn)行詳細設計； 

4、 設計文檔編寫(xiě)完成后，發(fā)郵件通知開(kāi)發(fā)經(jīng)理、項目經(jīng)理、測試負責人、相關(guān)開(kāi)發(fā)人員和測試人員； 

5、 開(kāi)發(fā)經(jīng)理、項目經(jīng)理、測試負責人、相關(guān)開(kāi)發(fā)人員和測試人員對所提交的概要設計文檔、詳細設計文檔進(jìn)行審查，將建議和意見(jiàn)以郵件的形式反饋給模塊負責人； 

6、 模塊負責人收集郵件中的修改建議并對設計文檔進(jìn)行修改，同時(shí)回復郵件說(shuō)明詳細設計修改情況，修改后的詳細設計commit到CVS； 

7、 如果對設計存在爭議或出現明顯不合理的設計，召開(kāi)一個(gè)小型會(huì )議對異議進(jìn)行討論，有效解決設計所出現的分歧 

8、 測試負責人（或專(zhuān)門(mén)的PPQA）對開(kāi)發(fā)最終修改的詳細設計計劃進(jìn)行檢查，并確認所有文檔都已經(jīng)commit到CVS。 

注：在大型的項目中，必須先完成概要設計后再完成詳細設計，在小項目或需求中可做適當剪裁概要設計與詳細設計合在一起完成。 

四、測試方案與評審 

1、在項目的設計階段，測試負責人根據規范文檔、功能列表和概要文檔編寫(xiě)總體測試方案與性能測試方案； 

2、測試方案編寫(xiě)完成后，發(fā)郵件通知開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)開(kāi)發(fā)人員和測試人員； 

3、開(kāi)發(fā)經(jīng)理、項目經(jīng)理、測試負責人、相關(guān)開(kāi)發(fā)人員和測試人員對所提交的測試方案進(jìn)行審查，開(kāi)發(fā)經(jīng)理和項目經(jīng)理對測試方案進(jìn)行總體性的審查，而各模塊負責人則負責相關(guān)模塊或功能的測試方案的審查，將建議和意見(jiàn)以郵件的形式反饋給測試負責人； 

4、測試負責人收集郵件中的修改建議并對測試方案進(jìn)行修改，同時(shí)回復郵件說(shuō)明測試方案修改情況，修改后的測試方案commit到CVS； 

5、測試負責人（或專(zhuān)門(mén)的PPQA）對最終修改的測試方案進(jìn)行檢查，并確認所有文檔都已經(jīng)commit到CVS。 

五、編碼實(shí)現與單元測試 

1、在產(chǎn)品詳細設計完成后，開(kāi)發(fā)工程師依據設計進(jìn)行編碼工作； 

2、編碼完成后，開(kāi)發(fā)工程師編寫(xiě)單元測試案例并進(jìn)行單元測試，單元測試完成后提交單元測試報告； 

3、項目經(jīng)理根據項目實(shí)際情況對開(kāi)發(fā)工程師編寫(xiě)的代碼組織Code Review，記錄相關(guān)問(wèn)題； 

4、產(chǎn)品模塊單元測試完成后，開(kāi)發(fā)之間進(jìn)行產(chǎn)品聯(lián)調測試，并修改所發(fā)現問(wèn)題以及提交聯(lián)調測試報告； 

5、產(chǎn)品初步完成后，在提交測試前進(jìn)行一次產(chǎn)品演示，參加人員包括開(kāi)發(fā)經(jīng)理、項目經(jīng)理、測試負責人、開(kāi)發(fā)工程師、測試工程師、售前工程師與售后工程師，在演示的過(guò)程中對產(chǎn)品提出改進(jìn)建議； 

6、各模塊負責人對Code Review以及產(chǎn)品展示所發(fā)現的問(wèn)題進(jìn)行修改，相關(guān)的代碼與文檔commit到CVS； 

7、項目經(jīng)理對編碼完成后的系統進(jìn)行確認，確保提交測試的系統是可運行的，測試負責人（或專(zhuān)門(mén)的PPQA）確認所有文檔和代碼都已經(jīng)commit到CVS。 

六、測試設計與評審 

1、 在項目編碼階段，測試方案編寫(xiě)完成后，測試負責人或相關(guān)測試人員根據測試方案、規范文檔、功能列表和詳細設計進(jìn)行測試用例設計； 

2、 測試案例設計的類(lèi)型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等，在用例設計中，除了功能測試案例外，應盡量考慮邊界、異常、性能的情況，以便發(fā)現更多的隱藏問(wèn)題； 

3、 在編寫(xiě)測試案例的過(guò)程中，對于存在疑問(wèn)的地方或測試重點(diǎn)，主動(dòng)與開(kāi)發(fā)負責人或項目經(jīng)理溝通討論，一方面有助于設計完善的測試案例，另一方面也有助于開(kāi)發(fā)進(jìn)一步清晰編碼思路； 

4、 測試用例編寫(xiě)完成后，發(fā)郵件給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)開(kāi)發(fā)人員和測試人員； 

5、 開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)開(kāi)發(fā)人員和測試人員對所提交的測試案例進(jìn)行審查，開(kāi)發(fā)經(jīng)理與項目經(jīng)理對測試案例進(jìn)行總體性的檢查，各模塊負責人則負責檢查自己所負責的測試案例，將建議和意見(jiàn)以郵件的形式反饋給測試負責人； 

6、 測試負責人收集大家的郵件對測試案例進(jìn)行修改完善，同時(shí)回復郵件說(shuō)明修改情況，如果存在爭議則召開(kāi)一個(gè)小型會(huì )議對異議進(jìn)行討論，修改后的測試案例commit到CVS； 

7、 測試用例編寫(xiě)完成之后需要不斷完善，軟件產(chǎn)品新增功能或更新需求后，測試案例必須配套修改更新；在測試過(guò)程中發(fā)現設計測試案例時(shí)考慮不周，需要對測試案例進(jìn)行修改完善；在軟件交付使用后客戶(hù)反饋的軟件缺陷，而缺陷又是因測試案例存在漏洞造成，也需要對測試案例進(jìn)行完善； 

8、 測試負責人（或專(zhuān)門(mén)的PPQA）對最終修改測試案例進(jìn)行檢查，并確認所有文檔都已經(jīng)commit到CVS。 

七、測試實(shí)施 

1、代碼提交前一天準備相關(guān)的測試環(huán)境（如服務(wù)器或數據庫等），代碼提交后測試人員向Build Master申請打包，并搭建正式測試環(huán)境，為了不做到測試以及確保產(chǎn)品可以跨平臺，每個(gè)測試人員各自搭建一個(gè)測試環(huán)境，每個(gè)平臺至少要有一個(gè)以上的測試人員負責； 

2、測試環(huán)境搭建好后進(jìn)行煙霧測試，如果煙霧測試通過(guò)則繼續詳細的功能測試，否則中斷測試并返回給開(kāi)發(fā)； 

3、測試人員按照預定的測試計劃和測試方案逐項對測試案例進(jìn)行測試，在測試過(guò)程中發(fā)現的任何與預期目標不符的現象和問(wèn)題都必須詳細記錄下來(lái)，填寫(xiě)測試記錄，在必要的時(shí)候協(xié)助開(kāi)發(fā)追蹤與修改所發(fā)現的問(wèn)題；如果在測試的過(guò)程中發(fā)現重大的bug或因為某些bug導致測試不能繼續，測試中斷并返回給開(kāi)發(fā)； 

4、每個(gè)測試階段測試結束后，由測試負責人總結測試情況，對測試結果進(jìn)行分析和下一階段測試測試計劃與可能引進(jìn)的bug數量進(jìn)行預測，并提交“測試階段分析報告”，并發(fā)送給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)測試人員和開(kāi)發(fā)人員； 

5、開(kāi)發(fā)經(jīng)理對測試階段分析報告中存在的問(wèn)題采取恰當的措施和調整相關(guān)資源，確保下一階段的開(kāi)發(fā)與測試計劃順利進(jìn)行； 

6、開(kāi)發(fā)對bug進(jìn)行修改； 

7、開(kāi)發(fā)對bug修改后測試人員進(jìn)行回歸測試，經(jīng)過(guò)修改的軟件可能仍然包含著(zhù)錯誤，甚至引入了新的錯誤，因此，對于修改以后的程序和文檔，按照修改的方法和影響的范圍，必須重新進(jìn)行有關(guān)的測試； 

8、產(chǎn)品的功能比較完善后，進(jìn)行產(chǎn)品的性能壓力測試，并根據測試結果進(jìn)行性能調優(yōu)； 

9、確認測試，在軟件發(fā)布前，對產(chǎn)品進(jìn)行確認測試； 

10、當測試產(chǎn)品達到測試計劃所制定的產(chǎn)品質(zhì)量目標和測試質(zhì)量目標，整理產(chǎn)品發(fā)布包和編寫(xiě)相關(guān)文檔，確認發(fā)布包和文檔完整后進(jìn)行產(chǎn)品發(fā)布。 

八、產(chǎn)品發(fā)布 

當測試產(chǎn)品達到測試計劃所制定的產(chǎn)品質(zhì)量目標和測試質(zhì)量目標，整理產(chǎn)品發(fā)布包和編寫(xiě)相關(guān)文檔，在發(fā)布前對照功能列表進(jìn)行一次全面的確認測試，確認發(fā)布包和文檔完整后進(jìn)行產(chǎn)品發(fā)布。對于新產(chǎn)品來(lái)說(shuō)，必要的文檔必須包括：（1） 產(chǎn)品安裝操作手冊；（2） 產(chǎn)品白皮書(shū)；（3） 產(chǎn)品管理維護手冊；（4） 用戶(hù)操作手冊；（5） 總體測試報告（6）性能測試報告。 

九、版本控制 

在測試過(guò)程中，軟件的打包統一由Build Master完成。新版本軟件發(fā)布之后，馬上對代碼進(jìn)行質(zhì)量控制：

（1） Build Master給新版本的源代碼打一個(gè)cvs tag，方便代碼回滾check out。比如，發(fā)布版本為IAGW1.0.0，則給該軟件源代碼也打一個(gè)與發(fā)布版本相同名字的tag IAGW1.0.0。這樣做的一個(gè)好處是，在目前的軟件的基礎上做了修改并發(fā)布新的版本后，如果需要check out某個(gè)版本的源代碼，則可以通過(guò)這個(gè)版本的tag來(lái)check out，代碼的修改可以在該版本上進(jìn)行。

（2） Build Master對新發(fā)布的軟件源代碼進(jìn)行cvs lock，不允許開(kāi)發(fā)人員在軟件發(fā)布之后commit源代碼，直到有新版本需求修改再給開(kāi)發(fā)人員開(kāi)放commit權限。這樣做的好處是避免開(kāi)發(fā)人員隨意修改和commit源代碼，確保源代碼服務(wù)器上的源代碼版本與當前最新的發(fā)布版本一致。 

十、自動(dòng)測試 

產(chǎn)品穩定后，進(jìn)行自動(dòng)測試工具開(kāi)發(fā)，對于穩定的功能使用自動(dòng)測試工具進(jìn)行測試，新增的功能使用手工測試，使用自動(dòng)測試+手工測試的模式，可以大大提供測試效率。