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

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

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

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

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

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

6、，生命周期結束。如果驗證未修復或者新版本又發(fā)生，則重新激活，缺陷狀態(tài)重新變?yōu)榧せ睢?.1.3.0 缺陷處理過程3.1.3.1.0 正常處理過程(1)創(chuàng)建問題在測試管理系統(tǒng)中，所有用戶都可以創(chuàng)建新問題，包括需求問題和軟件缺陷等。創(chuàng)建問題時，需要描述清楚，并選擇正確的選項。(2)指派問題創(chuàng)建問題時，創(chuàng)建者通常要指派給該項目開發(fā)負責人，再由其指派任務，或直接指派給相應模塊的開發(fā)工程師。如果指派人是錯誤的，或者需要他人確認或幫助，則可以重新指派給合適的工程師，寫上相關備注。(3)確認問題通常開發(fā)工程師收到新問題后，需要分析和確認此問題是否為Bug。如果是Bug,則選擇“確認狀態(tài)”；如果認為非Bug,則

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

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

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

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

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

12、。實現(xiàn)代碼分支管理和版本的追溯、回退操作。版本管理流程崗位劃分1、代碼管理員(SourceCodeManager)負責管理版本管理系統(tǒng)使用者的權限。根據(jù)項目新建請求，創(chuàng)建新開發(fā)分支并劃分權限。負責監(jiān)督生產(chǎn)用分支代碼的集成/編譯/部署。2、項目開發(fā)負責人(ProjectLeader)全面負責管理項目所涉及到所有相關資源，包括文檔、代碼等。審核本項目中所有提交到測試和生產(chǎn)分支上的代碼，對其質量和可靠性負有責任。對項目開發(fā)進度負責。負責項目開發(fā)分支的管理工作。3、項目開發(fā)組成員(ProjectDeveloper)承擔具體代碼開發(fā)工作負責個人開發(fā)分支上代碼管理工作。負責個人開發(fā)內容的自測工作。對提交到

13、項目分支上的代碼質量控制，負有主要責任。4、測試組人員(ProjectTester)負責項目的全面測試工作，對測試報告的可靠性承擔主要責任版本樹劃分1、生產(chǎn)分支最新節(jié)點應與生產(chǎn)環(huán)境中的運行軟件保持一致，此分支上的所有節(jié)點均滿足生產(chǎn)上線要求，并根據(jù)實際生產(chǎn)環(huán)境代碼狀態(tài)進行演進。完成測試準備上線的項目代碼，必須提交到該分支上，進行獨立編譯生成部署文件。2、版本分支收集開發(fā)人員的開發(fā)成果，由項目開發(fā)負責人統(tǒng)一管理。此分支為打版分支。由代碼管理員建立此分支，在對應版本中，所有開發(fā)人員的開發(fā)成果需要匯總到此分支，版本結束后關閉該分支的提交功能，只允許進行查詢。3、個人開發(fā)分支由開發(fā)組成員自主創(chuàng)建和管理，

14、承擔日常開發(fā)過程中代碼歸集，記錄詳細開發(fā)過程。要求每日工作完成必須在該分支上產(chǎn)生節(jié)點，每一個功能點均有獨立的節(jié)點存在。流程分析1、流程圖單個功能點測試項目測試2、流程介紹成立代碼管理員收到項目成立申請，根據(jù)項目歸屬，從指定的生產(chǎn)分支節(jié)點拉出項目分支，將項目組相關人員添加到項目分支下，設定相應權限，提供分支地址等信息給項目負責人。項目負責人在項目分支上做初始化設定，做基本修改，建立初始版本后，將項目分支信息提供給開發(fā)組成員。開發(fā)項目組開發(fā)成員以項目分支為父分支，建立包含個人姓名的開發(fā)子分支（可多個），并在該分支上進行代碼修改。在完成修改后，提交代碼，在開發(fā)環(huán)境中獲取修改后的代碼，進行編譯調試和自

15、測，根據(jù)調試結果進行后續(xù)的代碼開發(fā)工作。在完成一個功能點的代碼開發(fā)并自測通過后，將個人開發(fā)分支及集成節(jié)點信息，提交給測試組成員，進行單個功能點測試。測試組完成單個功能點測試后，開發(fā)成員將個人修改代碼和項目分支最新點進行對比，并將對比結果提交給項目負責人進行代碼評審。項目負責人根據(jù)評審結果，決定是否將該代碼合并到項目分支。測試在完成所有的項目開發(fā)工作和代碼評審后，項目負責人將最終的代碼節(jié)點信息提交項目測試組，由測試組根據(jù)節(jié)點內容進行編譯、部署、測試后，根據(jù)測試結果，提交測試報告。部署代碼管理員在項目滿足進行生產(chǎn)部署的所有必備條件后，將項目分支的最終測試通過節(jié)點，合并到生產(chǎn)分支，并啟動生產(chǎn)環(huán)境的編

16、譯、部署工作。1.3.2上線版本控制系統(tǒng)上線后，需要明確版本提交/測試/發(fā)布/上線的流程與要求，明確各流程中的人員職責和配合關系等，以便所有版本的工作得到有效跟蹤，保證工作順利有序地進行。版本發(fā)布流程版本上線:包括新系統(tǒng)初始版本上線及升級版本升級上線兩類。項目負責人：項目負責人一般為項目經(jīng)理或項目經(jīng)理指定的項目負責人員.1.3.2.2流程圖版本上線和系統(tǒng)割接流程圖測試人員提交階段發(fā)起版本提交/撰寫提根據(jù)實際情況反復多次測試階段執(zhí)行版本測試/撰寫測試結果是否發(fā)布版本?實施階段好核物非配合出璜求T,上線&支撐確認階段上線&升號果通知確認結束'流程書服人員項目相關人員用服部經(jīng)

17、理確淀執(zhí)彳f時間/制定實施方案執(zhí)行at劃/完成上線&升級/撰寫報告收到上線&升級結果通知/；狗認是否二次歸檔上線&社類支撐一收到上線&升級結果通知1.3.2.3流程說明流程主要包括打版、測試、發(fā)布、上線、確認5大流程，對于存在多次的打版/測試過程不在流程中體現(xiàn)，同時針對過程中需要進行配合的事項，如人員配合安排、上線&升級方案審核確認等事宜需線下確認。項目負責人首次打版項目負責人進行版本提交時，在OA工作流中發(fā)起版本提交申請，填寫完整流程單后主送給下一階段的測試人員處理；同時將流程單抄送給項目組相關人員及質量部經(jīng)理、用服人員。.項目負責人發(fā)起版本提交申請時

18、，需完整填寫提交地址、模塊信息、版本特性；同時檢查好版本庫中對應的提交文件是否存在、提交內容是否正確無誤。.對于明確不需要發(fā)布的版本，則不需要抄送給用服人員。.用服人員根據(jù)流程單信息，可提前做好版本提交相關準備，準備上線耐級方案；并注意跟進版本的發(fā)布情況。1.3.2.3.2測試人員測試版本測試人員在收到版本提交的流程單后，根據(jù)版本的時間要求安排完成測試工作，并發(fā)布測試結果，將填寫完整的流程表單提交給項目經(jīng)理。.測試人員在收到提交的版本時，需確認工作流中版本提交信息是否完整無誤，如果存在問題需退回給提交者重新填寫。.測試人員在收到版本后及時完成版本的測試工作；測試完成后，測試人員在表單中填寫版本

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

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