軟件項目缺陷跟蹤和持續(xù)改進(jìn)

1、軟件項目質(zhì)量管理1.1 轉(zhuǎn)測質(zhì)量1.1.1 交付要求1. 產(chǎn)品開發(fā)或修改準(zhǔn)備提交測試版本在做轉(zhuǎn)測試前需要開發(fā)設(shè)計工程師完成必要的自檢并輸出自測報告或調(diào)試報告2. 產(chǎn)品開發(fā)版本必須滿足各階段測試輸入質(zhì)量要求，并在對其自檢并輸出自測報告或調(diào)試報告審核后給出結(jié)果；3. 對于產(chǎn)品設(shè)計開發(fā)驗證各階段各類型缺陷Bug要求開發(fā)設(shè)計工程師必須給出明確清晰的問題分析原因和改善解決對策，并在Buglist和缺陷回饋體現(xiàn)！并自檢其有效性！4. 對于滿足提交標(biāo)準(zhǔn)的測試版本必須在提交測試申請同時配備軟/硬件程序版本配置清單說明！5. 交付件必須完成過程審查與歸檔；1.1.2 測試標(biāo)準(zhǔn)1.1.2.1 測試開始準(zhǔn)入標(biāo)準(zhǔn)1.

2、 首次測試準(zhǔn)入標(biāo)準(zhǔn)：硬件環(huán)境可用并要求標(biāo)準(zhǔn)，軟件正確安裝且可執(zhí)行；核心和關(guān)鍵業(yè)務(wù)功能100%實現(xiàn)；提供產(chǎn)品功能調(diào)試報告或自檢報告；并配備軟硬件程序配置清單；2. 里程碑版本要滿足階段的質(zhì)量要求。里程碑版本必須提交調(diào)試報告；3. 版本測試前需提交完整的產(chǎn)品軟件包（不能是單個軟件）4. 版本軟/硬件測試申請、程序配套表和系統(tǒng)配套表（配置清單）5. 版本回歸測試標(biāo)準(zhǔn)：致命缺陷修復(fù)率必須為100%，重要缺陷修復(fù)率不低于85%，缺陷總修復(fù)率必須不低于80%的情況下，才能提交新版本測試申請。6. 版本回歸測試標(biāo)準(zhǔn)：對于提交的版本缺陷報告中的CRI、MAJ、MIN缺陷問題分析原因和改善解決對策描述不清晰或無

3、描述；7. 對于設(shè)計變更或缺陷修復(fù)后的驗證版本需要提供必要的測試申請說明和操作步驟指導(dǎo)說明，包括：環(huán)境、條件、配置、步驟、方法、達(dá)成目標(biāo)等。1.1.2.2 測試中斷標(biāo)準(zhǔn)1. 測試環(huán)境無法達(dá)到標(biāo)準(zhǔn)或無法滿足測試的一致性，安裝無法正確完成；2. 產(chǎn)品關(guān)鍵業(yè)務(wù)功能、性能、可靠性發(fā)現(xiàn)致命缺陷導(dǎo)致后續(xù)測試活動無法繼續(xù)開展或測試結(jié)果不可靠；3. 已修復(fù)致命缺陷重現(xiàn)和新發(fā)現(xiàn)的致命缺陷導(dǎo)致后續(xù)功能無法連續(xù)實現(xiàn)或后續(xù)測試用例無法實施或測試結(jié)果不可靠；4. 對于提交的版本缺陷報告中的CRI、MAJ、MIN缺陷問題分析原因和改善解決對策描述不清晰或無描述；5. 基本用例有缺陷，中斷測試打回。1.1.2.3 測試完成

4、標(biāo)準(zhǔn)1. 除因缺陷導(dǎo)致無法實施的測試用例之外，測試覆蓋率達(dá)到95%；2. 除因缺陷導(dǎo)致無法實施的測試用例之外，測試有效性和準(zhǔn)確性評審達(dá)到95%；3. 達(dá)到各階段測試質(zhì)量目標(biāo)。1.2 缺陷修復(fù)質(zhì)量和及時性軟件的缺陷是軟件開發(fā)過程中的重要屬性，它提供了許多信息。不同成熟度的軟件組織采用不同的方式管理缺陷。低成熟度的軟件組織會記錄缺陷，并跟蹤缺陷糾正過程。高成熟度的軟件組織，還會充分利用缺陷提供的信息，建立組織過程能力基線，實現(xiàn)量化過程管理，并可以此為基礎(chǔ)，通過缺陷預(yù)防實現(xiàn)過程的持續(xù)性優(yōu)化。1.2.1 缺陷定義1. 軟件未達(dá)到需求規(guī)格說明書的功能。 2. 軟件出現(xiàn)了需求規(guī)格說明書指明不會出現(xiàn)的錯誤。

5、 3. 軟件功能超出需求規(guī)格說明書的范圍。4. 軟件未達(dá)到需求規(guī)格說明書未指出但應(yīng)達(dá)到的目標(biāo)。 5. 測試工程師認(rèn)為軟件難以理解、不易使用、運行速度慢，或者最終用戶認(rèn)為不好。1.2.2 缺陷生命周期1.2.2.1 缺陷生命周期圖1.2.2.2 缺陷狀態(tài)說明缺陷狀態(tài)狀態(tài)說明激活狀態(tài)缺陷的初始狀態(tài)，或者重新被激活的狀態(tài)。激活狀態(tài)的缺陷可以通過編輯來修改缺陷內(nèi)容，并指派給合適的工程師處理。解決狀態(tài)缺陷被解決之后的狀態(tài)。 激活狀態(tài)的缺陷經(jīng)過成功修復(fù)以后，由開發(fā)工程師操作為解決狀態(tài)，系統(tǒng)將自動指派回創(chuàng)建者。關(guān)閉狀態(tài)解決狀態(tài)的缺陷在驗證通過后關(guān)閉，缺陷狀態(tài)變?yōu)殛P(guān)閉，生命周期結(jié)束。如果驗證未修復(fù)或者新版本又

6、發(fā)生，則重新激活，缺陷狀態(tài)重新變?yōu)榧せ睢?.2.3 缺陷處理過程1.2.3.1 正常處理過程（1）創(chuàng)建問題在測試管理系統(tǒng)中，所有用戶都可以創(chuàng)建新問題，包括需求問題和軟件缺陷等。創(chuàng)建問題時，需要描述清楚，并選擇正確的選項。（2）指派問題創(chuàng)建問題時，創(chuàng)建者通常要指派給該項目開發(fā)負(fù)責(zé)人，再由其指派任務(wù)，或直接指派給相應(yīng)模塊的開發(fā)工程師。如果指派人是錯誤的，或者需要他人確認(rèn)或幫助，則可以重新指派給合適的工程師，寫上相關(guān)備注。（3）確認(rèn)問題通常開發(fā)工程師收到新問題后，需要分析和確認(rèn)此問題是否為Bug。如果是Bug，則選擇“確認(rèn)狀態(tài)”；如果認(rèn)為非Bug，則注明原因并指派回創(chuàng)建者。當(dāng)創(chuàng)建者收到確認(rèn)指派時，需

7、要進(jìn)行及時確認(rèn)。如果同意為非bug，則及時關(guān)閉它；如果不同意，則需要注明理由并指派回相關(guān)工程師。（4） 解決問題此為開發(fā)工程師的主要職責(zé)，包括Bug的復(fù)現(xiàn)、修改和修改驗證。開發(fā)工程師需要及時對確認(rèn)狀態(tài)Bug進(jìn)行分析和解決，并自己驗證通過，則操作為解決狀態(tài)，解決方案規(guī)則請參考5.4中解決方案定義部分，在缺陷管理系統(tǒng)中解決方案選擇相應(yīng)的選項，解決后系統(tǒng)將自動指派回給創(chuàng)建者。如果Bug無法解決或修改影響比較大，可申請進(jìn)入“延期解決”流程，請參考5.2中延期處理部分。（5） 驗證問題創(chuàng)建者需要及時對解決狀態(tài)的Bug在對應(yīng)版本上面進(jìn)行驗證。如果驗證通過，則可關(guān)閉Bug；如果驗證不通過，則激活此Bug，系

8、統(tǒng)將自動指派回給解決者。驗證通過準(zhǔn)則：相同的操作步驟，進(jìn)行一定次數(shù)的驗證測試都沒有發(fā)生。驗證不通過準(zhǔn)則：相同的操作步驟，全部或部分實際結(jié)果還會發(fā)生，驗證不通過則激活Bug。(6) 關(guān)閉問題通過驗證的Bug，驗證者需要注明驗證結(jié)果并進(jìn)行關(guān)閉操作，系統(tǒng)將指派給Closed。如果關(guān)閉狀態(tài)的Bug在之后版本又會發(fā)生，則激活此Bug，系統(tǒng)將自動指派回給解決者。1.2.3.2 特別處理過程(1) 客戶問題客戶反饋的問題可以由客戶直接反饋或項目經(jīng)理、市場部等了解到的客戶問題，經(jīng)確認(rèn)后的Bug提交到測試管理系統(tǒng)，按照以上處理流程進(jìn)行處理，由創(chuàng)建者或測試組進(jìn)行跟蹤驗證關(guān)閉。創(chuàng)建客戶問題時，創(chuàng)建者需要在Bug標(biāo)題

9、開頭標(biāo)記為客戶問題，測試組負(fù)責(zé)檢查和更正。(2) 爭議處理當(dāng)開發(fā)和測試工程師對某問題有爭議并且多次溝通無果時，可以注明雙方的理由，并指派給項目經(jīng)理進(jìn)行處理。項目經(jīng)理可以召開評審會議，或者直接與雙方溝通了解，并根據(jù)項目情況給出專業(yè)意見和最終決定。開發(fā)和測試工程師根據(jù)項目經(jīng)理的最終決定執(zhí)行。(3) 延期解決當(dāng)開發(fā)工程師對確認(rèn)Bug進(jìn)行解決時，發(fā)現(xiàn)或評估其解決時間緊或風(fēng)險比較大等，可以說明原因或理由并指派給項目經(jīng)理來確認(rèn)。項目經(jīng)理可以召開評審會議，或者直接溝通了解，并根據(jù)項目情況給出最終決定。如果不同意，項目經(jīng)理將此Bug指派開發(fā)工程師，開發(fā)工程師繼續(xù)分析和解決。如果同意，項目經(jīng)理需要在Bug標(biāo)題開

10、頭標(biāo)記為延期解決和在處理狀態(tài)選擇“延期解決”，然后注明解決時間計劃并指派回開發(fā)工程師，開發(fā)工程師根據(jù)解決時間計劃來規(guī)劃和解決此Bug。1.2.3.3 缺陷管理工具軟件測試過程中所有缺陷要提交到測試管理系統(tǒng)進(jìn)行跟蹤管理。1.2.4 缺陷處理及時性缺陷問題處理及時性，是指要求缺陷發(fā)現(xiàn)后，項目經(jīng)理、測試人員、開發(fā)工程師在短時間內(nèi)做出快速反應(yīng)和處理。處理的及時性要求：1、 測試人員在測試出問題缺陷時，要第一時間將問題按照要求規(guī)范整理并錄入問題管理平臺；根據(jù)問題所屬模塊，將問題指派給對應(yīng)的開發(fā)人員；并根據(jù)問題的等級將問題抄送給對應(yīng)的關(guān)注人。2、 開發(fā)工程師在收到問題平臺所分配的問題，要第一時間根據(jù)問題的

11、優(yōu)先級安排問題修改計劃。如果問題優(yōu)先級高，需要立即處理。3、 項目經(jīng)理或問題關(guān)注人要及時關(guān)注問題平臺，遇到優(yōu)先級高的問題需要及時關(guān)注問題。如果問題在處理過程中遇到困難要第一時間進(jìn)行資源協(xié)調(diào)、問題討論，拒絕問題擱置。4、質(zhì)量專員要定期分析問題平臺的問題，將常見問題歸納終結(jié)別面再次出現(xiàn)。1.3 上線后代碼質(zhì)量驗證和持續(xù)改進(jìn)1.3.1 版本代碼控制規(guī)范軟件產(chǎn)品的開發(fā)、測試、發(fā)布流程，提高開發(fā)人員的代碼開發(fā)質(zhì)量，通過加強(qiáng)對編碼過程的監(jiān)控，細(xì)化工作流程，達(dá)到提升軟件開發(fā)效率，并逐步推進(jìn)敏捷開發(fā)過程，實現(xiàn)代碼管理的自動化。1.3.1.1 版本管理工具通過GIT、SVN等代碼管理工具進(jìn)行版本管理，實現(xiàn)每個本

12、都有單獨的代碼分支。實現(xiàn)代碼分支管理和版本的追溯、回退操作。1.3.1.2 版本管理流程1.3.1.2.1 崗位劃分1、 代碼管理員（Source Code Manager）l 負(fù)責(zé)管理版本管理系統(tǒng)使用者的權(quán)限。l 根據(jù)項目新建請求，創(chuàng)建新開發(fā)分支并劃分權(quán)限。l 負(fù)責(zé)監(jiān)督生產(chǎn)用分支代碼的集成/編譯/部署。2、 項目開發(fā)負(fù)責(zé)人（Project Leader）l 全面負(fù)責(zé)管理項目所涉及到所有相關(guān)資源，包括文檔、代碼等。l 審核本項目中所有提交到測試和生產(chǎn)分支上的代碼，對其質(zhì)量和可靠性負(fù)有責(zé)任。l 對項目開發(fā)進(jìn)度負(fù)責(zé)。l 負(fù)責(zé)項目開發(fā)分支的管理工作。3、 項目開發(fā)組成員（Project Develo

13、per）l 承擔(dān)具體代碼開發(fā)工作。l 負(fù)責(zé)個人開發(fā)分支上代碼管理工作。l 負(fù)責(zé)個人開發(fā)內(nèi)容的自測工作。l 對提交到項目分支上的代碼質(zhì)量控制，負(fù)有主要責(zé)任。4、 測試組人員（Project Tester）負(fù)責(zé)項目的全面測試工作，對測試報告的可靠性承擔(dān)主要責(zé)任1.3.1.2.2 版本樹劃分1、 生產(chǎn)分支最新節(jié)點應(yīng)與生產(chǎn)環(huán)境中的運行軟件保持一致，此分支上的所有節(jié)點均滿足生產(chǎn)上線要求，并根據(jù)實際生產(chǎn)環(huán)境代碼狀態(tài)進(jìn)行演進(jìn)。完成測試準(zhǔn)備上線的項目代碼，必須提交到該分支上，進(jìn)行獨立編譯生成部署文件。2、 版本分支收集開發(fā)人員的開發(fā)成果，由項目開發(fā)負(fù)責(zé)人統(tǒng)一管理。此分支為打版分支。由代碼管理員建立此分支，在對

14、應(yīng)版本中，所有開發(fā)人員的開發(fā)成果需要匯總到此分支，版本結(jié)束后關(guān)閉該分支的提交功能，只允許進(jìn)行查詢。3、 個人開發(fā)分支由開發(fā)組成員自主創(chuàng)建和管理，承擔(dān)日常開發(fā)過程中代碼歸集，記錄詳細(xì)開發(fā)過程。要求每日工作完成必須在該分支上產(chǎn)生節(jié)點，每一個功能點均有獨立的節(jié)點存在。1.3.1.2.3 流程分析1、 流程圖2、 流程介紹l 成立代碼管理員收到項目成立申請，根據(jù)項目歸屬，從指定的生產(chǎn)分支節(jié)點拉出項目分支，將項目組相關(guān)人員添加到項目分支下，設(shè)定相應(yīng)權(quán)限，提供分支地址等信息給項目負(fù)責(zé)人。項目負(fù)責(zé)人在項目分支上做初始化設(shè)定，做基本修改，建立初始版本后，將項目分支信息提供給開發(fā)組成員。l 開發(fā)項目組開發(fā)成員以

15、項目分支為父分支，建立包含個人姓名的開發(fā)子分支（可多個），并在該分支上進(jìn)行代碼修改。在完成修改后，提交代碼，在開發(fā)環(huán)境中獲取修改后的代碼，進(jìn)行編譯調(diào)試和自測，根據(jù)調(diào)試結(jié)果進(jìn)行后續(xù)的代碼開發(fā)工作。在完成一個功能點的代碼開發(fā)并自測通過后，將個人開發(fā)分支及集成節(jié)點信息，提交給測試組成員，進(jìn)行單個功能點測試。測試組完成單個功能點測試后，開發(fā)成員將個人修改代碼和項目分支最新點進(jìn)行對比，并將對比結(jié)果提交給項目負(fù)責(zé)人進(jìn)行代碼評審。項目負(fù)責(zé)人根據(jù)評審結(jié)果，決定是否將該代碼合并到項目分支。l 測試在完成所有的項目開發(fā)工作和代碼評審后，項目負(fù)責(zé)人將最終的代碼節(jié)點信息提交項目測試組，由測試組根據(jù)節(jié)點內(nèi)容進(jìn)行編譯、部

16、署、測試后，根據(jù)測試結(jié)果，提交測試報告。l 部署代碼管理員在項目滿足進(jìn)行生產(chǎn)部署的所有必備條件后，將項目分支的最終測試通過節(jié)點，合并到生產(chǎn)分支，并啟動生產(chǎn)環(huán)境的編譯、部署工作。1.3.2 上線版本控制系統(tǒng)上線后，需要明確版本提交/測試/發(fā)布/上線的流程與要求，明確各流程中的人員職責(zé)和配合關(guān)系等，以便所有版本的工作得到有效跟蹤，保證工作順利有序地進(jìn)行。1.3.2.1 版本發(fā)布流程版本上線:包括新系統(tǒng)初始版本上線及升級版本升級上線兩類。項目負(fù)責(zé)人:項目負(fù)責(zé)人一般為項目經(jīng)理或項目經(jīng)理指定的項目負(fù)責(zé)人員.3.3.1.1.3.2.2 流程圖1.3.2.3 流程說明流程主要包括打版、測試、發(fā)布、上線、確認(rèn)

17、5大流程，對于存在多次的打版/測試過程不在流程中體現(xiàn)，同時針對過程中需要進(jìn)行配合的事項，如人員配合安排、上線&升級方案審核確認(rèn)等事宜需線下確認(rèn)。1.3.2.3.1 項目負(fù)責(zé)人首次打版項目負(fù)責(zé)人進(jìn)行版本提交時，在OA工作流中發(fā)起版本提交申請，填寫完整流程單后主送給下一階段的測試人員處理；同時將流程單抄送給項目組相關(guān)人員及質(zhì)量部經(jīng)理、用服人員。1. 項目負(fù)責(zé)人發(fā)起版本提交申請時，需完整填寫提交地址、模塊信息、版本特性；同時檢查好版本庫中對應(yīng)的提交文件是否存在、提交內(nèi)容是否正確無誤。2. 對于明確不需要發(fā)布的版本，則不需要抄送給用服人員。3. 用服人員根據(jù)流程單信息，可提前做好版本提交相關(guān)準(zhǔn)

18、備，準(zhǔn)備上線&升級方案；并注意跟進(jìn)版本的發(fā)布情況。1.2.3.3.1.3.2.3.3.3.3.1.1.3.2.3.2 測試人員測試版本測試人員在收到版本提交的流程單后，根據(jù)版本的時間要求安排完成測試工作，并發(fā)布測試結(jié)果，將填寫完整的流程表單提交給項目經(jīng)理。1. 測試人員在收到提交的版本時，需確認(rèn)工作流中版本提交信息是否完整無誤，如果存在問題需退回給提交者重新填寫。2. 測試人員在收到版本后及時完成版本的測試工作；測試完成后，測試人員在表單中填寫版本測試的結(jié)果信息，提交流程單給項目經(jīng)理。1.3.2.3.3 項目負(fù)責(zé)人提交回歸版本項目負(fù)責(zé)人在收到測試完成郵件后；安排進(jìn)行版本的回歸修改，在針

19、對問題單進(jìn)行了相應(yīng)的修復(fù)或應(yīng)有處理后，則可以進(jìn)行回歸版本的提交。1. 項目負(fù)責(zé)人發(fā)起版本回歸提交前，需檢查是否完成了相應(yīng)BUG單的修復(fù),不進(jìn)行修改的BUG是否進(jìn)行了應(yīng)有的確認(rèn)，將有效信息傳遞到下一個環(huán)節(jié)處理人員。2. 項目負(fù)責(zé)人需合理控制回歸的次數(shù)，對BUG是否修改作好風(fēng)險評估，以避免回歸次數(shù)過多現(xiàn)象。1.2.3.3.1.3.2.3.3.3.3.1.3.3.2.3.3.3.3.3.4.3.3.5.1.3.2.3.4 確認(rèn)結(jié)束流程項目負(fù)責(zé)人、測試人員收到版本上線&升級結(jié)束通知后，依次根據(jù)自身職責(zé)進(jìn)行確認(rèn)并結(jié)束流程。1. 項目負(fù)責(zé)人和測試人員對版本升級報告進(jìn)行審核，對升級過程是否存在遺漏和

20、遺留問題隱患等方面確認(rèn)，并對存在的遺留問題和遺漏等進(jìn)行相應(yīng)的處理安排，并跟蹤執(zhí)行。2. 測試人員確認(rèn)是否在版本上線過程中產(chǎn)生臨時版本，并對臨時版本進(jìn)行補(bǔ)測和歸檔。3. 用服部經(jīng)理對用服人員涉及的版本上線&升級執(zhí)行情況和工作質(zhì)量等進(jìn)行必要的檢查。1.3.3 “PDCA”管理模式PDCA循環(huán)又叫戴明環(huán)，是美國質(zhì)量管理專家戴明博士首先提出的，它是企業(yè)全面質(zhì)量管理所應(yīng)遵循的科學(xué)程序。質(zhì)量管理活動的全部過程，就是質(zhì)量計劃的制訂和組織實現(xiàn)的過程，這個過程就是按照PDCA循環(huán)，不停頓地周而復(fù)始地運轉(zhuǎn)的。ISO9001:2000標(biāo)準(zhǔn)指出， PDCA方法可適用于所有過程。其模式可簡述如下：P-策劃：根據(jù)顧客的要求和組織的方針，為提供結(jié)果建立必要的目標(biāo)和過程;D-實施：實施過程;C-檢查：根據(jù)方針、目標(biāo)和產(chǎn)品要求，對過程和產(chǎn)品進(jìn)行監(jiān)視和測量，并報告結(jié)果;A-處置：采取措施，以持續(xù)改進(jìn)過程業(yè)績。PDCA循環(huán)可通過以下八個主要步驟實現(xiàn)：分析和評價現(xiàn)狀，以識別改進(jìn)的區(qū)域;確定改進(jìn)的目標(biāo);尋找可能的解決辦法，以實現(xiàn)這些目標(biāo);評價這些解決辦法并作出選擇;實施選定的解決辦法;測量、驗證、分析和評價實施的結(jié)果，以確定這些目標(biāo)已經(jīng)實現(xiàn);正式采納更改;必要時，對結(jié)果進(jìn)行評審，以確定進(jìn)一步改進(jìn)的