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