二、BUG的描述

開發人員需要獲取對應版本的代碼來重現BUG，版本的標識有利于統計和分析每一個版本的質量

Web系統：

硬件設備（電腦品牌，型號）

軟件設備（操作系統，瀏覽器即版本號）

APP：

硬件設備（手機品牌，分辨率）

軟件設備（操作系統及版本號）

描述問題重現的最短步驟

以用戶的角度描述程序應有的行為是怎樣的，可以的話寫明需求的來源

三、BUG的級別

以下對BUG級別的描述只是典型情況，實際中的BUG級別的劃分需看公司的定義

崩潰

嚴重阻礙到測試人員的工作，系統無法正常運行，出現崩潰，操作死鎖，死循環，黑屏，導致數據庫數據丟失，數據庫連接錯誤等（遇到這類情況應立即中止當前版本的測試）

嚴重

系統能運行，但是不穩定，繼續運行下去會造成嚴重損失，重要的功能沒有實現，或者與需求不符合，數據庫中的用戶數據存儲出現了錯誤，威脅用戶的安全

一般

系統可以穩定運行，次要的功能沒有實現，或者與需求不符合，比如加載時間過長，格式錯誤，數據庫表中字段過多等

建議

影響用戶的體驗，界面格式不規范，排版不符合大眾審美，描述不清晰，提示語丟失，文字排列不整齊等優先級較低的BUG

四、BUG的生命周期

五、當因為 BUG 和開發人員產生沖突時

檢查自身，看對BUG的描述是否清楚

一個描述清晰的BUG信息，使得解決問題的效率大大提高。當BUG的信息無法書面描述清晰時，應當主動找到開發人員進行溝通

從用戶的角度去說服開發人員修改

一個項目最后面向的對象的是用戶，引導開發人員站在用戶的角度思考問題，可以促進開發人員修改BUG

BUG的定級要嚴格按照公司的規范

不斷提升自己的業務技術水平

不僅能發現BUG，還能夠對BUG進行定位，甚至提出解決方案，建立權 威，有較高的可信度

拒絕大聲爭吵，拒絕扯頭花

進行三方會議，測試人員、開發人員、產品經理一起討論BUG的解決方案

六、菜鳥如何開始自己的第一次測試

進行第一次的測試前需要做好充分的準備

拿到一個項目，我們需要閱讀所有項目相關的文檔，需求文檔，設計文檔，用戶手冊。這些是之后寫測試用例，進行測試的根本依據所在

多多參加項目相關會議，了解項目的背景，人員組成，進一步了解項目需求和業務，針對專業性較強的項目，要了解各種相關知識

熟悉項目使用的測試管理工具，配置管理工具

閱讀已有的測試方案，測試用例以及BUG，和團隊保持一致的故障定級原則

編寫代碼前還需要了解公司的規范要求，比如用例編寫的規范，用例執行的規范，BUG 提交的規范，測試工具使用的規范等

在真正進行測試前，還需要向自己的小領導確認具體的工作內容：

測試的計劃

測試的內容

任務限制幾天完成

我要測試的內容的開發人員、需求人員

測試的內容是否需要其他特殊的測試資源

至此，就可以開始執行測試任務