對于軟體測驗程序中的缺陷報告提交，一份高質量的缺陷報告除了必要的基本資訊以外，還需要根據專案組中每個角色分工不同， 對待缺陷的定位和立場也不同，所以完善且有說服力的缺陷報告非常重要，
溫故下之前高質量的缺陷報告的幾個條件：
1、描述清楚問題產生步驟及嚴重級別
2、盡早提交缺陷報告，快速反饋開發
3、非必現的Bug也要全部提交
4、為每個缺陷單獨提交一份缺陷報告
5、仔細撰寫缺陷報告的標題
6、像撰寫測驗用例撰寫重現步驟
7、使用缺陷模板來提交缺陷
8、撰寫缺陷報告時，要考慮到日后的查詢關鍵詞
9、如有同類或已發生的缺陷 ，則進行關聯
10、注意缺陷報告的可讀性
11、客觀組織描述語言來撰寫缺陷報告
12、通過缺陷評估發現更多資訊
提交高質量的缺陷只是測驗流程的一小部分，實際作業中，同一個需求可能由多個開發人員共同完成，特別是涉及到較大專案或需求時，可能還會有外部依賴或支持系統的開發人員，各個開發人員所負責的功能模塊和業務范圍可以從專案計劃書或是從專案經理處知悉，但對于同一個問題是提給前端人員還是后端人員或是介面人時，則需要測驗人員根據自己的技能和作業經驗來判斷，這里歸納了一份關于前后端問題的區分思維導圖，當然有很大一部分問題屬于聯調，需要開發人員共同解決，而準確區分前后端問題不僅可以提高作業效率 ，也是測驗人員專業技能的一個體現，
以下是前后端典型問題區分的思維導圖：
一、前端問題
1、界面相關
常見的界面相關問題有：排版錯亂、文字錯誤、資料錯誤、兼容性問題
文字錯誤的問題又包含功能文字及提示文字 ，功能文字即對話框或彈框中的標題文字；提示文字即前端給出的文案提示
資料錯誤的問題又包含串列欄位錯誤、表單欄位錯誤等，這種情況下可以查看前端是否參與計算，或是有無進行過欄位配置管理，一般情況下可以先提交給前端
瀏覽器兼容問題比較常見，如果使用了UI框架 ，則前端問題常見于框架問題，常見的瀏覽器問題可以參考歷史推文《瀏覽器兼容性測驗學習》
2、功能相關
功能相關的又包含功能實作錯誤或不完整以及邏輯錯誤等
功能問題可以通過抓包查看請求的方式來初步判斷，如無請求，則初步判斷為前端Bug；若抓包中有請求，則可以通過不同的狀態碼來判斷，有請求的情況下可以初步判斷為后端Bug，抓包相關可以參見《基于Fiddler的APP抓包及服務端模擬》
常見的狀態碼可以參見百科中的狀態碼記錄：
邏輯錯誤問題需要與開發人員溝通確認
3、性能相關
常見的問題如頁面打開較慢，表單打開慢等，一般情況下可以通過抓包來查看請求，如果請求耗時較小，則初步斷定為前端問題；否則可以結合其他資訊排查為后端問題，
另外，性能相關的問題出現后建議通過工具來評估整體的性能，可以進一步定位是哪個部分的問題，
二、后端問題
通常后端問題常見于業務邏輯、資料問題以及安全相關的問題與性能問題
如果前端功能實作導致后端回傳的資料出錯 ，則可以初步判斷為前端問題；但如果查看后端回傳的介面資料不一致或是出現報錯資訊，則判斷為后端問題；
另外，后端問題多數可以通過查詢錯誤日志資訊來排查原因，若沒有輸出日志，則可能為前端問題；不存在互動的情況下更多偏向于前端問題，有些資訊不會展示在前臺，需要結合服務端日志資訊一起排查定位了，在定位的程序中可以記錄下相關SQL的問題，服務端的問題以及代碼問題，以便于日后查看，
記錄并總結的時間久了，漸漸也會積累一些經驗，可以通過介面分析法，日志工具，結合自己過往的專案經驗來判斷，當然這些都是在自我分析層面 ，如果遇到無法直接判斷的問題，可以直接找到相關的開發人員進行溝通， 但溝通并不是直接指給開發人員或是直接問，可以在自己充分分析的基礎上以討論的方式進行，既可以不斷提升自己的職業技能，也可以增加測驗人員的實力，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/253047.html
標籤：其他
上一篇：演算法工程師大致是做什么的
下一篇：iOS 支付知識儲備:結算周期、付款碼二維碼編碼規則、脫敏規范、銀行卡號有效性校驗、掃碼驗證密碼規則、測驗輔助工具