軟件缺陷管理流程

軟件缺陷管理流程

SoftwareDefectManagementProcedure1.PurposeThisdocumentdefinesthesoftwaredefectmanagementprocessandrelatedrulestoensurethesystematicandstandardizedmanagementofsoftwaredefects,therebyensuringprojectdevelopmentquality.2.ScopeThisappliestodefectmanagementinthedepartment'sprojectdevelopmentprocessandprovidesguidanceandstandardizationfordefectmanagementprocessesinallstages.3.Definitions3.1TerminologyDefect:Adeviationexistinginthesoftwarethatcanbeactivatedandexistsinastaticformwithinthesoftware.Bug:Amanifestationofadefect,anyproblemthatdisruptsthenormaloperationofasystemorprogram.3.2DefinitionofDefect(1)Thesoftwaredoesnotmeetthefunctionalrequirementsspecifiedintherequirementsspecification.(2)Thesoftwareexhibitserrorsthattherequirementsspecificationstateswillnotoccur.(3)Thesoftware'sfunctionalityexceedsthescopeoftherequirementsspecification.(4)Thesoftwaredoesnotmeetthegoalsthatshouldbeachievedbutarenotspecifiedintherequirementsspecification.(5)Thesoftwareisdifficultfortesterstounderstandoruse,runsslowly,orisdeemedunsatisfactorybyend-users.4.DefectLifecycle4.1DefectLifecycleDiagram4.2DefectStatusExplanationDefectStatusActivationStatusStatusExplanationTheinitialstateofadefect,orastatethathasbeenreactivated.Anactivateddefectcanbemodifiedbyeditingitscontentandassignedtoanappropriateengineerforprocessing.Afteradefectisresolved,itenterstheResolvedstatus.Whenanactivateddefectissuccessfullyfixed,itismarkedasResolvedbythedevelopmentengineer,andthesystemautomaticallyassignsitbacktoitscreator.ClosedStatusAdefectintheResolvedstatusisclosedafterverificationanditslifecycleends.Ifthedefectisnotfixedoranewversionisreleased,itisreactivated,andthedefectstatusreturnstoActivation.5.DefectHandlingProcess5.1NormalHandlingProcess(1)CreateaProblemInthetestmanagementsystem,alluserscancreatenewproblems,includingrequirementproblemsandsoftwaredefects.Whencreatingaproblem,itisnecessarytodescribeitclearlyandselectthecorrectoptions.Fordetails,pleasereferto5.4and5.5.(2)AssignaProblemWhencreatingaproblem,thecreatorusuallyassignsittotheprojectdevelopmentleader,whothenassignsthetasktotheappropriatemoduledevelopmentengineer.Iftheassigneeisincorrectorneedsconfirmationorassistancefromothers,itcanbereassignedtotheappropriateengineerwithrelevantremarks.(3)ConfirmtheProblemAfterreceivinganewproblem,thedevelopmentengineerusuallyneedstoanalyzeandconfirmwhetheritisabug.Ifitisabug,selectthe"Confirmed"status.Ifitisdeemednotabug,statethereasonandassignitbacktothecreator.Whenthecreatorreceivestheconfirmationassignment,timelyconfirmationisrequired.Ifitisagreedthatitisnotabug,itshouldbeclosedpromptly.Ifnot,thereasonshouldbestated,anditshouldbeassignedbacktotherelevantengineer.Iftheproblemconfirmationassignmentexceedssixtimes,itneedstoenterthe"DisputeHandling"process.Fordetails,pleasereferto5.2.(4)ResolvetheProblemThisisthemainresponsibilityofthedevelopmentengineer,includingreproducingthebug,modifyingit,andverifyingthemodification.b.提供統(tǒng)計和報告功能，幫助管理者了解缺陷情況和項目進(jìn)展。c.協(xié)同工作，讓開發(fā)、測試、項目經(jīng)理等人員能夠共同使用同一個平臺，方便溝通和協(xié)作。(2)使用規(guī)范a.每個缺陷都需要填寫完整的信息，包括標(biāo)題、描述、優(yōu)先級、狀態(tài)等。b.每個缺陷都需要指派給具體的責(zé)任人，確保問題得到及時處理。c.每個缺陷的狀態(tài)需要及時更新，以便跟蹤和統(tǒng)計。d.每個缺陷都需要經(jīng)過驗證才能關(guān)閉。(3)工具選擇選擇缺陷管理工具時，需要考慮以下因素：a.功能是否齊全，是否滿足項目需求。b.易用性和界面友好程度。c.是否支持多人協(xié)同工作和權(quán)限管理。d.是否提供統(tǒng)計和報告功能。e.是否能夠與其他工具集成。小改寫：開發(fā)工程師需要及時分析和解決確認(rèn)狀態(tài)的Bug，并進(jìn)行驗證通過，然后標(biāo)記為解決狀態(tài)。解決方案規(guī)則請參考5.4中的解決方案定義部分，并在缺陷管理系統(tǒng)中選擇相應(yīng)的選項，解決后系統(tǒng)將自動指派回給創(chuàng)建者。如果Bug無法解決或修改影響較大，可以申請進(jìn)入“延期解決”流程，請參考5.2中的延期處理部分。創(chuàng)建者需要及時驗證解決狀態(tài)的Bug在對應(yīng)版本上面是否通過。如果驗證通過，則可以關(guān)閉Bug；如果驗證不通過，則激活此Bug，系統(tǒng)將自動指派回給解決者。驗證通過的準(zhǔn)則是相同的操作步驟進(jìn)行一定次數(shù)的驗證測試沒有發(fā)生；驗證不通過的準(zhǔn)則是相同的操作步驟全部或部分實際結(jié)果還會發(fā)生。通過驗證的Bug需要注明驗證結(jié)果并進(jìn)行關(guān)閉操作，系統(tǒng)將指派給Closed。如果關(guān)閉狀態(tài)的Bug在之后版本又會發(fā)生，則激活此Bug，系統(tǒng)將自動指派回給解決者。當(dāng)客戶反饋問題時，需要在Bug標(biāo)題開頭標(biāo)記為[客戶問題]，測試組負(fù)責(zé)檢查和更正。當(dāng)開發(fā)和測試工程師對某問題有爭議并且多次溝通無果時，可以注明雙方的理由，并指派給項目經(jīng)理進(jìn)行處理。開發(fā)工程師對確認(rèn)Bug進(jìn)行解決時，如果發(fā)現(xiàn)或評估其解決時間緊或風(fēng)險比較大等，可以說明原因或理由并指派給項目經(jīng)理來確認(rèn)。缺陷管理工具在軟件測試過程中起到跟蹤和管理缺陷的作用，并提供統(tǒng)計和報告功能，方便管理者了解缺陷情況和項目進(jìn)展。每個缺陷都需要填寫完整的信息，并指派給具體的責(zé)任人，狀態(tài)需要及時更新，并經(jīng)過驗證才能關(guān)閉。在選擇缺陷管理工具時，需要考慮功能是否齊全、易用性和界面友好程度、是否支持多人協(xié)同工作和權(quán)限管理、是否提供統(tǒng)計和報告功能以及是否能夠與其他工具集成等因素。B.收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線來識別或報告測試狀態(tài)。同時，收集缺陷數(shù)據(jù)并進(jìn)行數(shù)據(jù)分析，作為測試評估的依據(jù)。C.缺陷管理系統(tǒng)主要通過指派狀態(tài)來驅(qū)動相關(guān)開發(fā)工程師、測試工程師和項目經(jīng)理盡快地處理問題，以提高研發(fā)效率。因此，會特別關(guān)注缺陷指派給誰以及停留時間，并反饋在定期報告中。因此，缺陷驅(qū)動原則是：盡量不要讓缺陷掛在你身上。5.4缺陷屬性定義(1)缺陷相關(guān)屬性缺陷屬性包括：缺陷ID、缺陷類型、嚴(yán)重程度、發(fā)生概率、解決方案、缺陷描述和說明。缺陷ID是標(biāo)記某個缺陷的一組符號，每個缺陷必須有一個唯一的ID。缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類。缺陷嚴(yán)重程度是指因缺陷引起的失效對軟件產(chǎn)品的影響程度。缺陷發(fā)生概率指缺陷按照測試操作步驟發(fā)生的概率情況。缺陷解決方案是指缺陷被解決掉的處理方案。缺陷描述是對缺陷的報告，包括標(biāo)題、操作步驟和結(jié)果等。(2)缺陷類型說明缺陷類型包括設(shè)計缺陷、界面問題、數(shù)據(jù)問題、需求問題、安裝部署、性能問題、文檔問題、常識問題、安全問題、優(yōu)化建議和其他。設(shè)計缺陷是由于軟件設(shè)計或代碼實現(xiàn)所產(chǎn)生的功能或流程的問題。界面問題是系統(tǒng)頁面展示的問題。數(shù)據(jù)問題是系統(tǒng)數(shù)據(jù)的來源、處理及處理結(jié)果的問題。需求問題是軟件需求測試發(fā)現(xiàn)的問題，也包括之后需求變更的問題。安裝部署是軟件安裝部署過程的錯誤。性能問題是軟件性能相關(guān)的缺陷。文檔問題是用戶使用手冊、軟件幫助文檔等出現(xiàn)的問題。常識問題是系統(tǒng)用戶的正常使用習(xí)慣相關(guān)問題。安全問題是系統(tǒng)漏洞安全問題。優(yōu)化建議是針對操作過程邏輯或界面顯示的優(yōu)化性建議。其他包括前面未分類的問題。(3)嚴(yán)重程度定義嚴(yán)重程度包括致命、嚴(yán)重和一般。致命是指實現(xiàn)的功能與產(chǎn)品定義或軟件需求規(guī)格嚴(yán)重不符，系統(tǒng)無法執(zhí)行、崩潰、凍結(jié)，死循環(huán)等，程序引起的死機(jī)，非法退出，主要功能模塊嚴(yán)重錯誤，數(shù)據(jù)庫鏈接錯誤，嚴(yán)重數(shù)據(jù)計算錯誤通訊錯誤等。嚴(yán)重是指模塊功能錯誤，模塊功能未實現(xiàn)，亂碼等，功能錯誤，如鏈接模塊有誤，基本按鍵使用有誤等，數(shù)據(jù)錯誤，如用戶數(shù)據(jù)丟失、破壞、計算、保存有誤等，不影響用戶使用的非嚴(yán)重問題。一般是指次要功能未實現(xiàn)或與需求不符，操作界面錯誤，如界面圖表或字符的一般性錯誤，但不影響操作，提示信息錯誤，輔助說明不清楚。測試過程中發(fā)現(xiàn)了一些數(shù)據(jù)錯誤，包括數(shù)據(jù)邊界、格式約束未實現(xiàn)或需求不一致等問題。為了優(yōu)化用戶操作體驗，建議開發(fā)團(tuán)隊對這些問題進(jìn)行修復(fù)。另外，在界面設(shè)計方面，有些字符或提示顯示不夠恰當(dāng)，建議開發(fā)團(tuán)隊對其進(jìn)行優(yōu)化。除此之外，還有一些頁面或操作習(xí)慣的優(yōu)化性建議，以及功能操作更好的實現(xiàn)方式需要改進(jìn)。在缺陷的優(yōu)先級定義方面，我們將問題分為立刻、緊急、盡快和一般四個級別。其中，立刻級別的問題需要馬上解決，包括阻礙測試工作無法進(jìn)行、影響版本上線等問題。緊急級別的問題需要在下個測試版本發(fā)版前解決，包括嚴(yán)重問題、常用模塊功能、業(yè)務(wù)邏輯或數(shù)據(jù)錯誤、明顯的性能問題等。盡快級別的問題需要盡快解決，包括大多數(shù)一般問題、頁面顯示、頁面的字符、界面圖標(biāo)、文字顯示、鏈接有誤等。一般級別的問題是非常用界面或字符的顯示錯誤或不恰當(dāng)，以及用戶使用習(xí)慣、語言表達(dá)等優(yōu)化建議。針對缺陷的發(fā)生概率，我們將其分為必現(xiàn)、經(jīng)常、偶爾和隨機(jī)四個級別。必現(xiàn)指測試5次，出現(xiàn)5次；經(jīng)常指測試5次，出現(xiàn)3~4次，或測試10次，出現(xiàn)3次及以上，或測試15次，出現(xiàn)5次及以上；偶爾指測試10次，出現(xiàn)2次，或測試15次，出現(xiàn)2~4次；隨機(jī)指測試15次，出現(xiàn)1次。在處理狀態(tài)方面，我們設(shè)立了確認(rèn)中、解決中、復(fù)現(xiàn)中、驗證中和延期解決五個狀態(tài)，用于說明缺陷處理的進(jìn)度。最后，我們定義了解決方案，包括已經(jīng)解決、重復(fù)缺陷和無效缺陷三種情況。已經(jīng)解決指缺陷被修復(fù)或更正，并通過驗收測試；重復(fù)缺陷指相同的缺陷別人已經(jīng)提交，或者開發(fā)認(rèn)為原因是相同的；無效缺陷指設(shè)計如此，不是問題，只是優(yōu)化建議。在處理缺陷時，開發(fā)工程師需要填寫相應(yīng)的解決方案，并注明Bug原因等。對于重復(fù)缺陷，開發(fā)工程師需要填寫正確的重復(fù)缺陷ID。如果缺陷被認(rèn)為是無效的，開發(fā)工程師需要與創(chuàng)建者溝通說明，直到創(chuàng)建者確認(rèn)。不采納第三方問題，只有開發(fā)工程師能夠選擇解決方案。如果開發(fā)和測試工程師嘗試無法復(fù)現(xiàn)問題，且測試工程師已經(jīng)跟蹤測試了兩個以上版本，那么才可以考慮采用此方案。項目經(jīng)理需要考慮時間、風(fēng)險和市場需求等多個方面，并向項目經(jīng)理說明原因，最終決定是否選擇此方案。無法復(fù)現(xiàn)問題將作為風(fēng)