“缺陷管理工具”禪道—昇華Bug處理流程與相關屬性
“缺陷管理工具”禪道—昇華Bug處理流程與相關屬性
作為一個軟體測試工程師，對缺陷管理工具（缺陷：Bug）的認識和準確操作是有所必要的，缺陷管理工具現在行業中有很多：禪道、QC、Clear Quest、TestLink、Bugfree、Bugzilla、Jira等。本文選擇根據禪道帶大家認識Bug處理流程以及Bug的相關屬性：Bug標題、重現步驟、Bug型別、Bug嚴重程度、Bug優先順序、Bug來源、Bug根因等重大屬性。
1 BUG處理流程
開啟缺陷管理工具——禪道，軟體測試工程師選擇在“測試”檢視頁，選擇好測試專案後，點選“Bug”，會看到測試流程狀態：指派給我、由我建立、由我解決、未指派、未解決、未關閉、久未處理、被延期、需求變動等。
針對測試工程師的Bug狀態：啟用中、已解決、已關閉等。
針對開發工程師的Bug解決方案：已解決、延期處理、重複Bug、外部原因、無法重現、不予解決、設計如此等。
根據狀態，我們來熟悉下Bug處理流程（即：缺陷生命週期）。
Bug處理流程（Bug的生命週期）：
- （1）測試工程師發現Bug，查證Bug無重複提交過，然後儘可能完善Bug的相關屬性，接著再提交Bug，把缺陷的狀態置為：new；
- （2）開發工程師確認提交的Bug，進行Bug的重現與分析，如果不是Bug，拒絕Bug,把狀態置為：rejected；如果是Bug，指派給具體的開發人員解決，把狀態置為：open；
- （3）開發人員看到指派給自己解決的Bug，進行修改Bug，修改完後提交給測試工程師進行返測，開發人員自己把Bug狀態置為：fixed；
- （4）測試工程師對修改的Bug進行返測，如果返測成功，則關閉Bug,把Bug狀態置為：closed；如果返測不成功，則重新啟用Bug,讓開發工程師修改，把Bug狀態改為：reopen。
- （5）若經過多次返測後，測試工程師與開發工程師對該Bug有一定程度的爭議，則測試工程師決策是否讓專案經理來校驗下是不是Bug,如果是Bug,則開發工程師必須進行修改；如果不是Bug，則測試工程師關閉Bug。
在Bug處理過程中，專案中不同的角色應該關注的相應狀態與處理態度不一樣。
針對開發工程師，應關注測試工程師所置狀態：new、reopen、closed。new:開發工程師要對啟用狀態的Bug進行處理，根據處理過程，將其狀態置為rejected、open、fixed以及“已解決”、“延期處理”、“重複Bug”、“外部原因”、“無法重現”、“不予解決”、“設計如此”等；reopen：重新開啟的Bug是經過處理修改後的Bug通過測試工程師返測後表明沒有修改正常，進而需要繼續做相應的修改；closed：表明修改Bug成功，無缺陷。
針對測試工程師，應關注開發工程師所置狀態：rejected、open、fixed以及“已解決”、“延期處理”、“重複Bug”、“無法重現”、“外部原因”、“不予解決”、“設計如此”等，根據不同狀態做出響應反饋操作。特別說明下，對於開發工程師說明由於外部原因、設計如此，甚至不予解決的Bug，要及時決策通知到專案經理那裡，由專案經理來決定修改與否。
2 Bug相關屬性
禪道缺陷管理工具中，從測試人員介面可以很清楚的知道Bug的相關屬性：產品模組、所屬專案、影響版本、當前指派、Bug標題、重現步驟、相關需求、相關任務、缺陷型別、缺陷嚴重程度、缺陷優先順序、缺陷來源、缺陷根因、系統/瀏覽器、抄送、關鍵詞、附件。
2.1 產品模組
測試出的Bug所在的系統模組，如：職工管理系統 — 系統設定。
2.2 所屬專案
測試的軟體產品所屬的專案名稱。
2.3 影響版本
當前的測試版本。如：Trunk。
2.4 當前指派
當清楚該產品模組是哪個開發人員的情況下，直接指派到相應的開發人員；不清楚時，則直接指派給開發經理，由開發經理進一步分配指派。
2.5 Bug標題
Bug標題的確定，以產品模組 + 問題的簡要描述。如：職工登入介面——登入出現問題，錯誤賬號或密碼也能登入。
2.6 重現步驟
從重現操作步驟、操作結果以及預期期望等3個方面去重現Bug。部分Bug能夠容易的重現，但部分Bug則需要通過截圖、打斷點、日誌、抓取網路包等去捕獲有助於重現Bug的資訊，儘可能的為Bug所屬產品模組的開發工程師提供有效資訊。在重現Bug描述過程中，應該精準定位Bug、準確列出操作的所有步驟、準確解釋必須條件，甚至列舉出示例。
儘量排除無效的Bug，避免誤報Bug。考慮Bug是不是程式所引起的？Bug徵兆是不是假象？是不是網路問題導致資料不能連線？是不是應用軟體的配置錯誤而導致資料不能連線？是不是外部特殊原因引起的問題？等方面去考慮，儘可能縮小出錯的範圍。
2.7 缺陷型別
根據測試的Bug，明確其型別，便於問題型別的統計、專案的總結。點選禪道的“缺陷型別”下拉選單，可以列舉出以下的缺陷型別：
- 功能問題：功能錯誤、功能缺失、功能超越、設計二義性、演算法錯誤
- 介面問題：模組間介面、模組內介面、公共資料使用
- 邏輯問題：分支不正確、重複的邏輯、忽略極端條件、不必要的功能、誤解、條件測試錯誤、錯誤的變數檢查、計算順序錯誤、邏輯順序錯誤、公共資料使用
- 計算錯誤：等式錯誤、缺失運算子、錯誤的運算元、括號用法不正確、精度不夠、舍入錯誤、符合錯誤
- 收費問題：初始化錯誤、存取錯誤、引用錯誤的變數、陣列引用越界、不一致的子程式引數、資料單位不一致、資料維數不正確、變數型別不正確、資料範圍不正確、操作符資料錯誤、變數定位錯誤、資料覆蓋、外部資料錯誤、輸出資料錯誤、輸入資料錯誤、資料檢驗錯誤
- 使用者介面問題：介面風格不統一、螢幕上的資訊不可用、螢幕上的錯誤資訊、介面功能佈局和操作不合常規
- 文件問題：描述含糊、項描述不完整、項描述不正確、項缺少或多餘、項不能驗證、項不能完成、不符合標準、與需求不一致、文字排版錯誤、文件資訊錯誤、註釋缺陷
- 效能問題：嚴重、一般、輕微
- 配置問題：配置管理問題、編譯打包缺陷、變更缺陷、糾錯缺陷
- 標準問題：不符合編碼標準、不符合軟體標準、不符合行業標準
- 環境問題：設計與編譯環境、執行環境
- 相容問題：嚴重、一般、輕微
- 其他問題：嚴重、一般、輕微
2.8 缺陷嚴重程度
不同的公司劃分的缺陷嚴重程度不同，大致劃分為3-5個級別，具體的等級劃分可靈活調整。現在按照個人所處的環境進行5類劃分，大致如下：
| 嚴重級別：輕微 |
|---|
| 增加使用者使用體驗的建議性問題 |
| 風格不統一，例如：相近流程的頁面佈局不統一、相同問題點的提示資訊不一致，但對使用者的操作習慣或操作方法不會造成影響 |
| 對齊方式不一致，例如：文字對齊以及頁面掛列項不一致 |
| 介面錯誤，例如：顯示格式不規範、頁面描述顯示錯誤、字型錯誤等 |
| 長時間操作的功能未給使用者進度提示 |
| 按鈕或標籤上有拼寫錯誤的字元，例如：漢字、單詞、字母等錯誤拼寫 |
| 錯誤定位及資訊提示不準確，例如：出錯後前臺後臺的資訊提示錯誤、錯誤判斷的順序、錯誤出現的游標定位等 |
| 嚴重級別：一般 |
|---|
| 業務流程對應的功能未實現，但在不影響實際使用的前提下有替代方法解決 |
| 簡單業務的功能實現錯誤，例如：預設顯示內容的錯誤、輔助說明描述不清楚、查詢匹配的錯誤、查詢列表初始查詢條件的錯誤等 |
| 頁面輸入限制錯誤，例如：文字框輸入長度以及字元的限制錯誤、檔案圖片上傳格式大小的限制錯誤，以及特殊輸入要求判斷的錯誤等 |
| 日期和時間初始值錯誤，以及業務操作流程先後時間判斷的錯誤 |
| 嚴重級別：嚴重 |
|---|
| 業務流程的功能未實現，但不影響到系統穩定性 |
| 操作正確性不受影響，但影響到系統性能和響應時間 |
| 功能實現與需求不一致，但影響流程中其他模組 |
| 資料庫建庫或升級的指令碼錯誤，丟失相關表或欄位，影響系統正常執行 |
| 儲存過程不能正常執行對應的設計功能 |
| 效能測試過程中，大資料量和併發壓力大時，系統處理緩慢、網路異常以及少量資料丟失（低於0.5%）等情況 |
| 嚴重級別：非常嚴重 |
|---|
| 系統中未實現相應需求，以及密碼明文顯示 |
| 業務流程對應的功能未實現，且無任何替代方法 |
| 資料連線未釋放，以及與其它模組介面的呼叫錯誤 |
| 產生錯誤的結果，進而致使系統不穩定 |
| 頁面出現編譯錯誤，甚至404頁面 |
| 效能測試過程中，大資料量和併發壓力大時，系統停止處理，甚至大量資料丟失（大於0.5%）等情況 |
| 嚴重級別：致命 |
|---|
| 功能設計與需求設計嚴重不符 |
| 主流程無法跑通，系統無法正常執行 |
| 正常的使用者操作流程，導致系統崩潰或者嚴重資源不足 |
| 記憶體洩漏，資料洩漏的安全性問題 |
| 應用模組無法啟動或者非法退出 |
| 致使通訊中斷 |
| 迴圈報錯，使得無法正常退出 |
2.9 缺陷優先順序
缺陷嚴重程度和缺陷優先順序是2個含義不同但又密切聯絡的概念，分別從不同方面去描述軟體缺陷對軟體質量和終端使用者的影響程式和處理方式。缺陷的嚴重程度與缺陷優先順序不一定是一一對等。
- 優先級別：低
適當考慮，延遲處理，儘可能在釋出前進行修復 - 優先級別：中
在軟體開發工程師的階段性任務完成後進行修復 - 優先級別：高
任務正常排隊，但又不會影響到開發測試的工作進度 - 優先級別：非常高
軟體開發工程師如果當前開發任務不是特別緊急的情況下，應該優先修復該缺陷；如果當前開發任務相對重要，則在完成這個開發模組後，應該優先修復該缺陷 - 優先級別：緊急處理
軟體開發工程師必須先停止當前的開發任務，修復好該缺陷
2.10 缺陷來源
有需求、設計、編碼、測試、整合、使用者、其他等7個方面。
2.11 缺陷根因
有需求、設計、編碼等3個方面。
2.12 系統/瀏覽器
作業系統（OS，Operating System），基本上是所有軟體產品必須依賴的。軟體所需求的操作可能存在差異，則需要針對性的設計開發。有如下作業系統：Windows、Linux、Unix、MAC、CentOS linux以及相應的不同版本。
B/S（Browser/Server，瀏覽器/伺服器結構），在網際網路產品中，瀏覽器的相容性顯得十分重要，不同瀏覽器之間（IE、Firefox、Chrome、Opera、Safari等以及相應不同的版本）都可能存在相容性問題，所以瀏覽器環境也是Bug重現的前提條件之一。
2.13 抄送
根據專案情況，選擇抄送。
2.14 關鍵詞
提煉出該Bug的幾個重要關鍵詞，以便後期查詢、驗證。
2.15 附件
重要的日誌、檔案、截圖包等選擇性的以附件提交，有助於開發工程師重現Bug。
- 致謝
若對大家有用，感謝點贊或評論；若有不足或補充之處，也感謝大家評論進行指正，後期我將對本文進行補充完善。相信這是互相進步的開始！