亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

BUG詳解

發現BUG僅僅是測試工作的開始

BUG的界定標準：與需求設計不符；違背常識

BUG的生命周期：發現bug；提交給開發；開發修復；測試驗證（不通過繼續指派給開發）；通過后關閉；上線前回歸

BUG的等級劃分：

P0：致命錯誤，需要立即修復，如宕機、重啟性報錯等；

P1：嚴重錯誤，需要緊急修復，如功能流程錯誤、數值錯誤等；

P2：一般錯誤，允許一段時間內修復，如功能的簡單錯誤、界面錯誤等；

P3：無關緊要的錯誤，允許延期修復，如文字錯誤、某個像素點缺失等等

bug的報錯標準

標題：[模塊名稱]+簡短描述

測試環境：標明測試用的版本，系統，服務器，賬號等

描述：BUG的詳細描述

重現步驟：重現bug的詳細流程步驟及復現概率

期望結果：希望bug修復后的結果

備注：log，截圖等

bug舉例：

標題：〔士兵〕打開士兵技能升級頁面報錯

測試環境:內網測試服，V1.1.0版本，iOS系統，賬號：ykl02

詳細描述：當我們在游戲中打開士兵升級頁面時，系統提示報錯信息

重現步驟:1、進入游戲。2、打開士兵技能升級頁面。3、系統報錯。

期望結果：能夠正常升級士兵技能，打開升級頁面不報錯

備注：報錯信息見下面截圖

BUG的驗證標準：

嚴格按照復現步驟驗證；

去除測試環境的影響，盡量使用提交BUG時的注明的環境；

驗證標注：需要注明驗證驗證的版本、服務器等

拓展：是否對其它功能有影響，做簡單回歸

注意點：驗證不能只看前端展現，更應關注后端數據

（比如購買道具，花了100，但是只扣了50；如果修復之后，前端確實顯示扣了100，但是數據庫中只扣了50，這就是“BUG的偽修復”）

BUG的跟蹤與推動：

每個人都有責任跟蹤自己的bug的修復狀態；

及時與開發溝通，了解修復狀態并提供修復過程中的支持；

久不修復的bug需要與開發和上級（需求人員）確認如何處理；

bug修復后，需要及時驗證

BUG的數據分析：

根據bug優先級看各個優先級的bug數量；

根據項目人員看各個開發人員的bug數量；

根據功能模塊看各個模塊的bug數量

測試用例編寫

格式：清晰的格式很重要

首頁內容：（用例關鍵信息）用例名稱；游戲版本；編寫人，編寫日期，備注；修改人，修改日期、修改備注；需求文檔的鏈接或地址

正文頁內容：功能邏輯圖（若有，便于理解）、用例id、模塊名稱、測試先決條件（入口）、輸入信息、輸出結果、備注信息

注意事項：用例有清晰的邏輯、一個輸入只對應一個輸出、保證每次更新用例后都有明確的記錄標注、保證格式一致

常用編寫方法

等價類：一個輸入集合內，任何輸入數據對于輸出的驗證來講都是等效的，所以選取少量代表性測試數據代表整個數據

有效等價類：是對輸出來講有意義的輸入集合，可以驗證程序的正常功能和流程

無效等價類：是對輸出來講無意義的輸入集合，驗證特殊情況

邊界值：對于輸入或輸出的邊界值進行分析

邊界值的確定：一般選取正好等于，剛剛小于和剛剛大于3種情況作為測試數據

適用：數值測試、字符串測試、數據類型測試等

因果圖：輸入與輸出之間因果關系的一種關系圖

適用于：輸入條件較為復雜，存在多種可能組合（笛卡爾積）的情況

方法：識別出因（所有輸入）、中間節點、果（所有輸出），并且根據關系連接起來

判定表：可以通過因果圖來生成的一種結果判定表格（因、中間節點、果，01表示是否存在）

因果圖常常與判定表一起使用，通過因果圖生成判定表，通過判定表來書寫測試用例

注意事項

輸入條件單一明確，不用容易引起誤解的詞，比如可能大概等

輸出要可判斷且明確，不用顯示正確這種詞匯

測試步驟要可執行

保證盡量高的覆蓋度

能抽象合并的盡量抽象合并，避免無意義的冗余

測試用例整理與維護

需求變化后及時更新并備注修改情況（修改內容、產品和開發負責人）

遇到冗余的測試用例，根據實際情況及時修改

注意測試用例的備份，在公司服務器上寫完后本地也備份一份，避免被人線上誤刪除

因果圖與判定表 舉例4

因果圖與判定表 舉例3

因果圖與判定表 舉例2

因果圖與判定表 舉例

邊界值 舉例

等價類舉例

手游測試用例正文頁內容 樣例

測試用例首頁內容樣例