報告軟體測試錯誤的目的是為了保證修復錯誤的人員可以重複報告的錯誤，從而有利於分析錯誤產生的原因，定位錯誤，然後修正之。因此，報告軟體測試錯誤的基本要求是準確、簡潔、完整、規範。需要掌握的報告技術歸納如下。
1. 描述 (description)，簡潔、準確，完整，揭示錯誤實質，記錄缺陷或錯誤出現的位置
描述要準確反映錯誤的本質內容，簡短明了。為了便於在軟體錯誤管理資料庫中尋找制定的測試錯誤，包含錯誤發生時的使用者介面（ui）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制項的名稱。
2. 明確指明錯誤型別：布局、翻譯、功能、雙位元組
根據錯誤的現象，總結判斷錯誤的型別。例如，即布局錯誤、翻譯錯誤、功能錯誤、雙位元組錯誤，這是最常見的缺陷或錯誤型別，其他形式的缺陷或錯誤也從屬於其中某種形式。
3. 短行之間使用自動數字序號，使用相同的字型、字型大小、行間距
短行之間使用自動數字序號，使用相同的字型、字型大小、行間距，可以保證各條記錄格式一致，做到規範專業。
4. ui要加引號，可以單引號，推薦使用雙引號
ui加引號，可以容易區分ui與普通文字，便於分辨、定位缺陷或錯誤。
5. 每乙個步驟盡量只記錄乙個操作
保證簡潔、條理井然，容易重複操作步驟。
6. 確認步驟完整，準確，簡短
保證快速準確的重複錯誤，「完整」即沒有缺漏，「準確」即步驟正確，「簡短」即沒有多餘的步驟。
7. 根據缺陷或錯誤型別，選擇圖象捕捉的方式
為了直觀的觀察缺陷或錯誤現象，通常需要附加缺陷或錯誤出現的介面，以位圖的形式作為附件附著在記錄的「附件」部分。為了節省空間，又能真實反映缺陷或錯誤本質，可以捕捉缺陷或錯誤產生時的全螢幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或錯誤位置，通常要求附加中英文對照圖。
8. 附加必要的特殊文件和個人建議和註解
如果開啟某個特殊的文件而產生的缺陷或錯誤，則必須附加該文件，從而可以迅速再現缺陷或錯誤。有時，為了使缺陷或錯誤修正者進一步明確缺陷或錯誤的表現，可以附加個人的修改建議或註解。
9. 檢查拼寫和語法錯誤
在提交每條缺陷或錯誤之前，檢查拼寫和語法，確保內容正確，正確的描述錯誤。
10. 盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
11. 通用ui要統
一、準確
錯誤報告的ui要與測試的軟體ui保持一致，便於查詢定位。
12. 盡量使用短語和短句，避免複雜句型句式
軟體錯誤管理資料庫的目的是便於定位錯誤，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。
13. 每條錯誤報告只包括乙個錯誤
每條錯誤報告只包括乙個錯誤，可以使錯誤修正者迅速定位乙個錯誤，集中精力每次只修正乙個錯誤。校驗者每次只校驗乙個錯誤是否已經正確修正。
以上概括了報告測試錯誤的規範要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習高階測試工程師的測試錯誤報告，結合自己以前的測試錯誤報告進行對比和思考，可以不斷提高技巧。
布局錯誤屬於介面錯誤，是gui測試的範疇，但不屬於頁面錯誤。
打個比方，在a頁面中有乙個小模組，但是卻被放到了b頁面中。頁面本身沒問題，但是邏輯上，布局不對。
至於雙位元組錯誤，舉個例子，在pl/sql developer裡，你加注釋時，刪除乙個漢字的時候不是你想象的那樣把這個字刪除，而是刪除了一半。這就是這個工具的乙個bug，沒有考慮到乙個字母佔1個位元組而乙個漢字佔兩個位元組，所以刪除的時候把乙個漢字「砍掉一半」。
報告軟體測試錯誤的目的是為了保證修復錯誤的人員可以重複報告的錯誤，從而有利於分析錯誤產生的原因，定位錯誤，然後修正之。因此，報告軟體測試錯誤的基本要求是準確、簡潔、完整、規範。需要掌握的報告技術歸納如下：
1、描述 (description)，簡潔、準確，完整，揭示錯誤實質，記錄缺陷或錯誤出現的位置。描述要準確反映錯誤的本質內容，簡短明了。為了便於在軟體錯誤管理資料庫中尋找制定的測試錯誤，包含錯誤發生時的使用者介面（ui）是個良好的習慣。
例如記錄對話方塊的標題、選單、按鈕等控制項的名稱。
2、明確指明錯誤表現型別：功能、介面、效能、其它。
3、ui要加引號，可以單引號，推薦使用雙引號。
4、每乙個步驟盡量只記錄乙個操作，保證簡潔、條理井然，容易重複操作步驟。
5、確認步驟完整，準確，簡短，保證快速準確的重複錯誤，「完整」即沒有缺漏，「準確」即步驟正確，「簡短」即沒有多餘的步驟。
6、根據缺陷或錯誤型別，選擇圖象捕捉的方式。為了直觀的觀察缺陷或錯誤現象，通常需要附加缺陷或錯誤出現的介面，以位圖的形式作為附件附著在記錄的「附件」部分。為了節省空間，又能真實反映缺陷或錯誤本質，可以捕捉缺陷或錯誤產生時的全螢幕，活動視窗和區域性區域。
7、附加必要的特殊文件和個人建議和註解。如果開啟某個特殊的文件而產生的缺陷或錯誤，則必須附加該文件，從而可以迅速再現缺陷或錯誤。有時，為了使缺陷或錯誤修正者進一步明確缺陷或錯誤的表現，可以附加個人的修改建議或註解。
8、檢查拼寫和語法錯誤。在提交每條缺陷或錯誤之前，檢查拼寫和語法，確保內容正確，正確的描述錯誤。
9、盡量使用業界慣用的表達術語和表達方法。使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
10、通用ui要統
一、準確。錯誤報告的ui要與測試的軟體ui保持一致，便於查詢定位。
11、盡量使用短語和短句，避免複雜句型句式。軟體錯誤管理資料庫的目的是便於定位錯誤，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。
12、每條錯誤報告只包括乙個錯誤。每條錯誤報告只包括乙個錯誤，可以使錯誤修正者迅速定位乙個錯誤，集中精力每次只修正乙個錯誤。校驗者每次只校驗乙個錯誤是否已經正確修正。
軟體bug管理流程和規範
深圳市鼎智時代通訊技術 版權所有 2010 2011 修訂歷史 一 軟體錯誤的常用狀態 新問題 new 測試中新報告的軟體缺陷 已分配 assigned 被確認並分配給相關開發人員處理 已解決 resolved 開發人員已完成修正，等待測試人員驗證 不處理 wontfix 拒絕修改缺陷或擱置不改 再...
我自己總結的現存BUG
一 輔料庫 1.絲束退料後led無顯示 上同一時間要料後timms裡不會報錯且材料會出，造成撞翻 3.任務維護 請求維護 沒有匯出功能 4.擋車反映現在紙箱條碼越來越多，希望用藍芽槍或者pda掃瞄代替手動輸入 5.擋車反映以後開外銷後能否進行工單裡繫結外銷材料？6.鑑於會有擋車誤刪托盤的情況發生，是...
不能修復的bug如何解決
多年的測試經驗中，經常發現有這麼一種現象 總有些提了的bug不能順利的被修復。這些bug往往有4個走向 1.在被發現的版本中最終被解決，但中途花費較多周折。2.有計畫的在後續的版本中被解決。3.決定永遠不修復，卻變成潛在的炸彈，在後續版本中被迫修復。4.決定永遠不修復，至今為止也一直沒有被修復。之前...