一條bug記錄最基本應包含：
bug編號；
bug嚴重級別，優先順序；
bug產生的模組；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄影…等等；
bug出現時的測試環境，產生的條件即對應操作步驟；
高質量的bug記錄：
通用ui要統
一、準確
缺陷報告的ui要與測試的軟體ui保持一致，便於查詢定位。
盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
每條缺陷報告只包括乙個缺陷
每條缺陷報告只包括乙個缺陷，可以使缺陷修正者迅速定位乙個缺陷，集中精力每次只修正乙個缺陷。校驗者每次只校驗乙個缺陷是否已經正確修正。
不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。
明確指明缺陷型別
根據缺陷的現象，總結判斷缺陷的型別。例如，即功能缺陷、介面缺陷、資料缺陷，合理化建議這是最常見的缺陷或缺陷型別，其他形式的缺陷或缺陷也從屬於其中某種形式。
明確指明缺陷嚴重等級和優先等級
時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先順序。
描述 (description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
描述要準確反映缺陷的本質內容，簡短明了。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的使用者介面（ui）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制項的名稱。
短行之間使用自動數字序號，使用相同的字型、字型大小、行間距
短行之間使用自動數字序號，使用相同的字型、字型大小、行間距，可以保證各條記錄格式一致，做到規範專業。
每乙個步驟盡量只記錄乙個操作
保證簡潔、條理井然，容易重複操作步驟。
確認步驟完整，準確，簡短
保證快速準確的重複缺陷，「完整」即沒有缺漏，「準確」即步驟正確，「簡短」即沒有多餘的步驟。
根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的介面，以的形式作為附件附著在記錄的「附件」部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全螢幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
附加必要的特殊文件和個人建議和註解
如果開啟某個特殊的文件而產生的缺陷或缺陷，則必須附加該文件，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。
檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
盡量使用短語和短句，避免複雜句型句式
軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。
以上概括了報告測試缺陷的規範要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
缺陷描述內容
缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發了解正確的結果應該是如何。
開發前你需要知道的事情
此文給自己提個醒，無論大小專案都應有良好的規範與守則，以免浪費時間在不必要的事情上 1.命名規則確認並統一，資料表，字段，類名 一般由框架決定 方法名 包括面向介面的，內部呼叫的等等 變數名，全域性變數名，輔助函式名.2.確定第三方庫存在的資料夾以及引入方式，中間輔助類所存在資料夾，同樣注意統一命名...
關於資料治理，你需要知道些什麼？
每個有效的資料庫都需要精心設計的模式 schema 以保持資料乾淨，避免衝突，滿足使用者的各種需求，適應未來的擴充套件。同樣，每個有效的企業資料計畫都離不開資料治理，也就是精心設計的政策，以明確職責 解決不同利益相關方之間的衝突，提供維護和擴充套件，保護敏感資訊。資料治理的關注點通常包括 資料管理方...
程式猿要知道的事情
程式猿是乙個奇妙的職業 我們工作的時候給公司帶來非常高的利益，我們自己也要給自己產生價值。以下一些事情能夠提高我們程式猿。所以我們要認真的看一下。不喜勿噴 1.常常和優秀的人在一起共事 和一些老鳥在一起工作，對你有非常大的提公升。比方我常常看老鳥們操作liunx系統，那命令敲的那就乙個快啊 非常羨慕...