Android軟件缺陷管理有哪些

這篇文章主要介紹“Android軟件缺陷管理有哪些”，在日常操作中，相信很多人在Android軟件缺陷管理有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Android軟件缺陷管理有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

軟件缺陷-概念

? 軟件缺陷-基本概念主要分為：缺陷、故障、失效? 缺陷（Defect）：以靜態形式存在于軟件內部，相當于BUG；? 故障（Fault）：軟件運行中出現的狀態，不處理可能會失效，以動態形式存在；? 失效（Failure）：軟件運行時產生的外部異常行為結果，與用戶需求不一致。

缺陷不一定導致故障，故障也不一定會失效；缺陷導致故障，有可能導致失效，也有可能不會導致失效

軟件缺陷-定義

  軟件缺陷的定義

? 軟件未達到產品說明書中已標明的功能? 軟件未達到產品說明書中雖未指出但應達到的目標? 軟件出現產品說明書中指明不會出現的錯誤? 軟件功能超出了產品說明書中指明的范圍? 軟件測試人員認為軟件中難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好缺陷的幾種類型：? 設計不合理; ? 功能、特性沒有實現或部分實現; ? 運行出錯，包括運行中斷、系統崩潰、界面混亂等; ? 與需求不一致，在執行TestCase時則為實際結果和預期結果不一致;? 用戶不能接受的其他問題，如存取時間過長、界面不美觀; ? 軟件實現了需求未提到的功能。

軟件缺陷-產生的原因

? 人員溝通不到位，交流上有誤解或根本不交流? 文檔不完善? 需求不斷的變化? 參與人員過度自信? 程序設計有誤? 軟件復雜性? 工期短、任務重、時間壓力大? 軟件開發工具與軟硬件 

識別軟件缺陷

? 通過測試用例中的預期結果進行識別? 通過需求規格說明書進行識別

? 通過用戶手冊及其他文檔進行識別? 通過同行業相類似成熟的商業軟件識別

? 通過與開發人員的溝通進行識別? 通過與有經驗測試人員溝通進行識別

? 通過參照同行業隱式需求進行識別

軟件缺陷-組織架構

? 缺陷的標題（一句話簡單描述問題）? 缺陷的基本信息? 測試的軟件和硬件環境? 測試的軟件版本? 缺陷的類型? 缺陷的嚴重程度? 缺陷的處理優先級? 缺陷的操作步驟（測試步驟、預期結果、實測結果）? 備注/注釋文字和截圖 

軟件缺陷-相關屬性

? 缺陷相關屬性：提交人、提交日期、BUG狀態、嚴重程度、缺陷優先級、缺陷版本、修復日期。

1.缺陷發現人：最直接的是測試人員，測試人員發現的BUG數是進行個人績效考核的依據。2.缺陷發現時間：發現BUG并提交的時間。3.缺陷優先級：立即解決P1、高優先級P2、正常排隊P3、低優先級P4。立即解決是指缺陷導致系統幾乎不能使用或測試不能繼續，需立即修復；高優先級是指缺陷嚴重影響測試，需優先考慮；正常排隊是指缺陷正常排隊等待修復；而低優先級是指缺陷可最后修改。4.缺陷版本：執行測試并發現BUG的版本號。5.缺陷修復日期：開發人員修復BUG的日期。 

? 缺陷狀態

1.新建 New 缺陷的初始狀態

2.打開 Open 測試人員提交BUG

3.指派 Assigned 指派給相關開發人員進行修復

4.已修復 Fixed 開發人員已修復

5.已關閉 Closed 測試通過，關閉

6.重新打開 Reopen 回歸測試未通過，或關閉后又復現了

7.延期 Postpone 推遲修改

8.拒絕 Rejected 開發人員拒絕修改

9.重復 Duplicate 重復提交

10.已取消/終止 Abandon 被拒絕和重復提交的BUG，在確認不是問題后，置為此狀態

? 缺陷嚴重程度：致命、嚴重、一般、較小、改進建議；或A、B、C、D、E 

1.致命：軟件死機、退出或崩潰、數據丟失，主要功能完全喪失，導致本模塊以及相關模塊異常等問題。如代碼錯誤，死循環，數據庫發生死鎖、與數據庫連接錯誤或數據通訊錯誤，未考慮異常操作，功能錯誤等。2.嚴重：主要功能部分喪失、數據不能保存，系統的次要功能完全喪失。如致命的錯誤聲明，程序接口錯誤，數據庫的表、業務規則、缺省值未加完整性等約束條件。3.一般：次要功能沒有完全實現但不影響使用。如提示信息不太準確，或用戶界面差，操作時間長，模塊功能部分失效等，打印內容、格式錯誤，刪除操作未給出提示，數據庫表中有過多的空字段等。4.較小的：使操作者不方便或遇到麻煩，但它不影響功能過的操作和執行，如錯別字、界面不規范，輔助說明描述不清楚。5.改進建議：由測試人員對軟件的改進意見、建議或質疑。 

軟件缺陷-填寫要求

1.缺陷標識：必填，缺陷的標識編號。2.指派人：必填，新提交的問題分配給相應的開發人員。3.提交人：必填，問題提交者，默認為自己。4.測試版本：必填，問題最開始發現的軟件版本號，對應開發的版本號。5.測試日期：必填，問題最開始提交的時間，默認為當天。6.嚴重程度：必填，問題本身的嚴重級別，越高表示越嚴重7.缺陷發生概率：必填，出現概率為必現、概率性出現（出現幾次）、不可復現。8.優先級：必填，缺陷要求解決的優先級，越高表示開發盡快修復問題。9.缺陷狀態：必填，缺陷的狀態，新提交時默認為“新建”。10.缺陷起源：在需求、架構、設計、編碼、測試、用戶哪階段發現的。11.缺陷來源：來源于需求規格說明書、設計文檔、集成接口、代碼。12.缺陷模塊：必填，哪個功能模塊的BUG。13.問題描述：必填，詳細描述問題，描述中必須包括預期結果和實際結果，盡量附圖，如有建議，寫出修改建議。14.問題處理意見：項目人員對缺陷給出處理的建議，均可讀寫。

軟件缺陷-描述原則

缺陷描述原則：分類準確、敘述簡潔、步驟清楚、易再現、復雜問題有據可查（截圖或其它形式的附件）。具體為：

? 問題描述格式：問題描述時，建議分幾步描述：模塊或功能點=>測試步驟=>期望結果=>實? 際結果=>其它信息，可依實際情況調整； ? 敘述簡潔：單一準確，一個缺陷一個報告；每步驟的描述盡量簡潔明了。? 短小簡練：只解釋事實、演示和描述軟件缺陷必要的細節，不寫無關信息；? 再現：可以再現（個別嚴重問題復現不了也可入庫，但需標明）；? 特定條件：缺陷是否在特定條件下才會出現；? 補充完善：復雜的問題應附上截圖、LOG等信息作為補充說明； 

? 不使用抽象詞句：比如“有錯誤”“是不是”“請確認”等等； ? 不做評價：請勿在BUG描述中，評價BUG缺陷加入個人主觀思想。

軟件缺陷-生命周期

簡單周期：發現、打開、修復、關閉

? 測試員找到并登記軟件缺陷，軟件缺陷移交到程序員

? 程序員修復軟件缺陷，軟件缺陷移交到測試員    ? 測試員確定軟件缺陷被修復，測試員關閉軟件缺陷。

復雜周期：

? 發現缺陷（測試員發現并登記缺陷，軟件缺陷轉到程序員）    ? 軟件缺陷移交到項目管理員    ?（以不修復形式解決）項目管理員認為軟件缺陷不重要，軟件缺陷移交到測試員    ? 重新激活缺陷（測試員不同意，找出通用失敗案例，軟件缺陷移交到項目管理員）    ? 項目管理員同意缺陷需要修復，缺陷轉給程序員    ? 以修復形式解決（測試員確認軟件缺陷得以修復，測試員關閉軟件缺陷）    ? 缺陷關閉 

測試/開發角色職責

? 測試執行人員：缺陷發現者。對版本進行測試發現BUG，并對已修復的BUG進行驗證。? 測試組長：缺陷管理者。負責對缺陷的審核，跟蹤和匯報，針對有爭議的BUG進行各方協調。? 開發負責人：缺陷解決者。接收BUG，并指派給具體開發人員進行修復，給出解決途徑或修復建議。? 開發人員：缺陷修復者。執行開發負責人指派的BUG修復并自測是否修復通過。 

軟件缺陷管理流程

BUG跟蹤流程：1.測試人員拿到最新軟件版本，執行測試；2.發現BUG并記錄到BUG管理平臺；提交BUG報告或測試報告，郵件抄送開發人員；3.開發人員得到最新BUG并修復BUG（如復雜問題，進行專家評審如何處理）4.修復BUG后把新代碼Check in到源代碼服務器；5.Buider人員會進行版本編譯并提交到發布版本服務器；6.測試人員開始執行新的一輪測試任務。 

缺陷跟蹤目的：1.保證BUG得到有效的跟蹤和解決，使每一環節都有相對應責任人負責。2.進行缺陷分析和產品度量。

軟件缺陷分析

? 缺陷分析就是分析缺陷在與缺陷關聯關系的一個或多個參數值上的分布。缺陷分析提供了一個軟件可靠性指標 

? 主要參數? 狀態：缺陷的當前狀態（打開的、正在修復或關閉的等）。? 優先級：必須處理和解決缺陷的相對重要性。? 嚴重性：缺陷的相關影響。對最終用戶、組織或第三方的影響等等。? 起源：導致缺陷的起源故障及其位置，或排除該缺陷需要修復的構件 

? 創建缺陷趨勢圖或報告；為揭示軟件可靠性的缺陷趨勢或缺陷分布提供判斷依據。

缺陷報告

? 缺陷報告-概念：

   測試執行過程中，發現缺陷故障/失效后，提出書面的報告。

? 缺陷報告-作用：

1.記錄軟件缺陷2.進行缺陷分類3.用于缺陷分析4.跟蹤軟件缺陷5.度量軟件質量 

? 缺陷報告的5C準則：

Correct（準確）Clear（清晰）Concise（簡潔）Complete（完整）Consistent（一致）

BUG管理工具

管理BUG的工具：Excel、Bugzilla、TestDirector（TD）、ClearQuest（CQ）、Bugfree、JIRA等 

? TestDirector 商業、支持Win平臺、B/S架構、在廣泛的應用環境下自動執行軟件質量測試和管理

? ClearQuest 商業、支持Unix/Win平臺、C/S、B/S架構、提供了從開發到部署的完整的審計跟蹤，并擴展了跨生命周期的可追溯性

? Bugzilla 免費、支持Unix/Win平臺、B/S架構、Bug追蹤系統設計用來幫助管理軟件開發

? Bugfree 免費、借鑒微軟的研發流程和Bug管理理念，使用PHP+MySQL獨立寫出的一個Bug管理系統。簡單實用、免費并且開放源代碼

? JIRA 商業、是集項目計劃、任務分配、需求管理、錯誤跟蹤于一體的商業軟件

到此，關于“Android軟件缺陷管理有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！