目錄

一軟件測試的生命周期

二BUG

1概念

2描述Bug

3Bug級別

4Bug的生命周期

三與開發人員發生爭執怎么辦

?編輯1先自省：是否Bug描述不清晰?

2站在用戶角度考慮并拋出問題

3Bug定級有理有據

4不僅要提出問題，還要給出解決方案

5Bug評審

5.1解決的問題

5.2三種角色

---

一軟件測試的生命周期

軟件測試貫穿軟件的整個生命周期：對于測試人員來說，不僅要具備開發能力，測試能力，還要有一定的產品分析能力來保證產品的質量；

軟件測試的生命周期指按照一個系統的流程去執行，確保軟件的質量符合需求；以下是具體內容

需求分析	測試計劃	測試設計與開發	測試執行	測試評估	上線	運行維護
從用戶角度：需求是否合理； 從開發角度：技術上是否可行，是否有優化空間； 從測試角度：需求是否符合邏輯	測試的時間要計劃多久	參考需求文檔，技術文檔編寫測試用例； 編寫測試文檔要明確標注使用到的測試方法，測試手段，測試工具等	利用測試用例與測試工具對軟件進行全方位的覆蓋測試	測試是否通過？測試是否有遺留的BUG?測試人員要結合測試實際編寫一份測試報告	上線分為四步驟：沙盒，小流量，全流量，全線上	測試人員參與項目的實施工作，收集用戶問題反饋給相關負責人

所以說：測試執行完成后不能就說軟件100%的問題被解決了，有些問題可能很難被發現，需要用戶體驗一段時間后才暴露出來；

項目測試完成后要把它推送上線，可不是像我們一樣就直接push代碼到遠程機器上就好了：因為一個項目可能是有多個團隊共同開發完成的，一同推上面可能會有沖突；再加上線下環境與線上環境的不同，可能線下環境沒問題，一上線就會出現各種報錯，所以上線分為四步：

• 沙盒：企業內部的內部的線上環境供測試人員測試；
• 小流量：先讓一小部分用戶進行體驗，測試人員除了要線上測試外，還要看是否有錯誤日志；
• 全流量：全部用戶都能使用到；
• 全線上：項目正式推送上線；

二BUG

1概念

• 當且僅當規格說明（需求）是存在并且正確時，程序與規格說明不匹配時就是Bug；
• 當規格說明沒有提到的功能，判斷以用戶為準：程序沒有實現用戶合理預期的功能也是Bug；

一切以需求出發：來驗證產品的特性是否返回用戶的需求！

2描述Bug

當出現了Bug后，測試人員也要能很好地描述清楚：

• 問題出現的版本；
• 問題出現的環境；
• 問題出現的步驟；
• 預期結果；
• 實際結果

案例：101智慧課堂-您身邊的智慧課堂?

之前（現在修復了）登錄以上網站的登錄頁面時：在ie瀏覽器上正常，在谷歌瀏覽器上發現登錄旁的二維碼被遮擋了，此時如果你是測試人員要怎么跟開發人員描述Bug呢？

直接說：在瀏覽器上出現頁面遮擋二維碼的Bug，要馬上進行修復！

開發人員此時就登上瀏覽器后發現沒有測試人員描述的情況：你是不是想找茬？

所以此時描述Bug時，我們可以應該這樣來描述：

• 問題出現的版本：?歌瀏覽器：123.0.6312.123（正式版本）（64位）
• 問題出現的環境：Windows 家庭版
• 問題出現的步驟：1.在搜索框上輸入網站；2.等待網站頁面渲染完成；
• 預期結果：二維碼沒有被遮擋，可以使用微信掃一掃二維碼進行登錄‘
• 設計結果：二維碼被登錄頁面遮擋，掃描二維碼失敗！’

盡可能詳細清楚去在線Bug出現的場景，給開發人員去復現Bug后進行能及時進行修復

3Bug級別

通過定義Bug級別來看出Bug的嚴重程度，根據Bug優先級的順序倆處理Bug；除此之外，Bug級別也決定著你的年終獎的高低：寫出幾個嚴重的Bug可能就要就要跟你的獎金說再見了~

• Bug級別一般分為：次要，一般，嚴重，崩潰；（但并不絕對，具體看公司的Bug描述文檔）

次要	一般	嚴重	崩潰
界面，性能缺陷，建議類問題：如：百度頁面的百度一下變成了百度兩下；優先度較低	功能沒有完全實現但不影響用戶正常使用；菜單功能存在缺陷但不影響系統穩定性；如：百度頁面的百度一下按鈕點擊沒反應，但可以通過回車鍵進行搜索；優先級低	系統主要功能部分喪失，數據庫保存調用錯誤，用戶數據丟失，一級菜單不能使用但不影響其它功能測試；一般出現較少	嚴重阻礙開發與測試的工作，造成系統崩潰，死機，死循環，導致數據庫數據丟失；出現極少

4Bug的生命周期

當測試人員發現Bug時，要提交到對應的Bug管理平臺，對Bug進行持續追蹤與測試，確保Bug能被順利解決掉：這就是一個Bug的生命周期

三與開發人員發生爭執怎么辦

因為年終獎的利益關系，測試人員與開發人員通常會在Bug問題上發生爭執：開發人員認為這不應該是一個Bug；Bug的級別太高了；你是不是故意找一個無效的Bug來增加自己的獎金...面對各種可能的出現情況，測試人員怎么就決定了爭執的走向~

1先自省：是否Bug描述不清晰??

• 反省是否對Bug描述不清楚或者是自己誤操作；
• 如果發現是自己的原因，在Bug提交后主動去找開發人員解釋，而不是等開發人員來找自己

2站在用戶角度考慮并拋出問題

• 功能正常只是測試的一部分，還要考慮用戶體驗感受；
• 如果開發人員不認同，我們可以反問他：如果你是用戶，你也接收這樣的體驗嗎？？

3Bug定級有理有據

• Bug定級不僅要參考Bug文檔，也要站在用戶角度上；
• 開發人員不認可Bug定級時：拿出Bug描述文檔與Bug表現進行匹配；

4不僅要提出問題，還要給出解決方案

• 在你的技術能力范圍內：可以給開發人員一個解決方案，但不能是以命令的口吻去要求

如果以上措施還得不到解決，接下來就要進行Bug評審

5Bug評審

5.1解決的問題

• 如何處理Bug；
• 分析Bug產生的原因，找出預防對策（不能犯同樣的錯誤）

5.2三種角色

• 測試代表：從Bug的具體表現，嚴重程度上提供信息，并給出意見；
• 開發代表：從修改缺陷的難度和?險等角度分析，給出初步方案；
• 產品代表：從產品計劃時間，用戶要求等方面，給出意見；

以上便是全部內容，有問題歡迎在評論區指正，感謝觀看！