- Bug的基本概念
- Bug的生命周期
- BUG的描述規範
- BUG的跟蹤規範
1.Bug的基本概念
1.1 BUG的含義：
BUG是一個英文單詞，本意是缺陷、損壞等意思。現在人們将在電腦系統或程式中，隐藏着的一些未被發現的缺陷或問題統稱為bug（漏洞）。
狹義的講，在手機軟體測試中，BUG是指手機的軟體所隐藏的一些未被發現的缺陷或問題。
1.2 BUG表現
現象一：功能沒有實作或與規格說明不一緻；
現象二：不能工作(當機、沒反應) ；
現象三：不相容
現象四：邊界條件未做處理
現象五：界面、提示、幫助不正确或不夠準确
現象六：尚未完成的工作
1.3 Bug報告
BUG報告是軟體測試過程中最重要的文檔。它記錄了Bug發生的環境，如各種資源的配置情況，Bug的再現步驟以及Bug性質的說明。
更重要的是它還記錄着Bug的處理過程和狀态。Bug的處理程序從一定角度反映了測試的程序和被測軟體的品質狀況以及改善過程。
1.4 判斷Bug的規則
軟體未達到産品規格說明書或需求标明的功能。
軟體出現了規格說明書指明不會出現的錯誤。
軟體功能超出規格說明書指明的範圍。
軟體未達到規格說明書雖未指出但應達到的目标（隐含需求）。
軟體測試員認為軟體難以了解、不易使用、運作速度緩慢，或者最終使用者認為不好。
需要注意的是，測試人員報告Bug時，應當保證Bug是可以重制的。對于有時不可重制的Bug，應當反複測試，直到最終确定Bug的發生場景為止。
1.5報告Bug的基本原則
盡快報告Bug;
有效描述Bug;
2.Bug的生命周期
Bug的生命周期就是指Bug從開始提出到最後完全解決，并通過複查的過程。在這個過程中Bug報告的狀态不斷發生着變化，記錄着Bug的處理程序。
3. BUG的描述規範
3.1 通用要求：
1）每條錯誤報告隻包括一個錯誤；
若同一個問題在多處菜單存在，可以在同一BUG中描述，具體做法為：先對問題進行較長的描述，在問題下面注明：“在**菜單、**菜單存在此現象，請一并修改。”
2）使用業界慣用的表達術語和表達方法，保證表達準确，展現專業化。3）不要使用感歎号或其他表現個人感情色彩的詞語或符号；
3.1 通用要求：
4）不要使用含糊的詞語（例如，好像，似乎，有問題，出現錯誤）和容易産生争執和歧義的詞來描述現象；
5）段落之間使用統一的序号、相同的字型、字号、行間距，保證各條記錄格式一緻，做到規範專業。
6）在送出每條缺陷或錯誤之前，反複閱讀BUG描述，檢查拼寫和文法，確定内容正确，正确的描述錯誤。
3.2 在JIRA中描述BUG的規範：
3. 2.1 概要（必填項），要求如下：
1）标題要簡潔、準确、完整、揭示錯誤實質、記錄缺陷或錯誤出現的位置 。若問題路徑較長，直接使用功能的名稱，在較長的描述中闡述路徑。
2） 為了便于在軟體錯誤管理資料庫中尋找制定的測試錯誤，包含錯誤發生時的使用者界面（UI）是個良好的習慣。例如記錄對話框的标題、菜單、按鈕等控件的名稱 ；
3）重新開機當機功能不能實作的bug，需表明出現機率，以免其他人員無法判斷問題的嚴重性
3. 2.2 bug severity：
BUG等級分為S/A/B/C四個等級
3. 2.5 複現概律，要求如下：
對于不穩定的問題，應盡量多驗證重制BUG，如果找不出BUG産生的原因，一般要求測試20次，比較重要的問題需要進行壓力測試來确認，根據測試的實際情況進行選擇，不允許為“無”。
無
必現
複現機率＞50%
複現機率＞10%
複現機率＞5%
複現機率＜1%
無規律複現
3. 2.6 上一版狀态（必填項），要求如下：
上一版狀态需按照實際情況進行填寫，若無法判定是本版本的問題，還是上一版的問題，且需将版本下載下傳上一版的軟體進行驗證，嚴禁不确定的情況下進行選擇“不存在”，以下是各個選項在什麼情況下進行選擇的簡單介紹：
無：此項為未選擇時的狀态，BUG送出時不允許出現該狀态；
存在：上一版軟體存在此問題，選擇“存在”；
不存在：上一版無此問題，為新版本才存在的BUG，選擇“不存在”；
無上一版軟體：首版軟體測試時，因無上一版軟體，可以選“無上一版軟體”；
上一版無此功能：新版本添加的功能，選擇“上一版無此功能”
原型版本存在：若在訂單項目上發現原型版本即存在的問題，選此項
3.2.7 子產品：選擇BUG對應的子產品。
3.2.8 影響版本：選擇BUG發生的版本号。
3.2.9 修複版本：選擇BUG在哪一版上解決，一般由開發人員選擇。
3.2.10環境，要求如下：
BUG發生時的網絡情況、手機硬體情況，SIM卡狀态、手機待機模式是卡1，卡2還是雙卡都有，單卡模式是否有問題，雙卡又如何？
3.2.11 描述，要求如下：
描述必須包含以下幾個要點，操作步驟、問題現象、期望結果和備注。
操作步驟：
1）每一個步驟盡量隻記錄一個操作；
2）保證簡潔、條理井然；
3）保證快速準确的重複錯誤，“完整”即沒有缺漏，“準确”即步驟正确，“簡短即沒有多餘的步驟；
4）BUG如果在特定條件下産生的，必須寫明BUG産生的條件。
BUG的跟蹤規範：
4.1 測試人員要不斷跟蹤Bug，直到Bug修正，問題解決為止。在最後的DCC版本需對所有已關閉的BUG進行回歸測試，驗證是否在軟體修改過程中導緻原本已修改的BUG重新出現；
4.2 在BUG跟蹤過程中，需對BUG狀态及時更新，以下為BUG狀态的說明：
建立狀态（ open ）: Bug建立後的初始狀态。
已解決待驗證狀态（RESOLVED）: 開發部門對軟體問題進行處理或修改後的狀态。
重新打開狀态（REOPENED）: 對開發部門修改後軟體問題，經過驗證，如果仍然存在，則将其狀态改為“重新打開”狀态。對于“關閉/延遲修改”狀态的軟體問題，如果時機成熟，需要重新開發，則将其狀态改為“重新打開”狀态。
關閉狀态（CLOSED）：驗證為已修改的問題，需及時進行關閉。
不解決狀态（Won’ fix）：評審為不修改的BUG，此類BUG需組長進行确認，若确認不需要修改則關閉，若需要修改則重新開啟。
4.3 對已修改問題進行驗證時，不僅應驗證該問題是否修改，還應驗證修改此問題後對本子產品或其它子產品的影響，是否有引起的新的問題，若改動較大時，應群組長征詢驗證方案。