常見的軟體測試面試題：
一條軟體缺陷（或者叫bug）記錄包含了哪些內容？
標準答案是：
【標題、嚴重等級、前置條件、步驟（bug描述）、期望結果、實際結果】
實際上在我們日常軟體測試過程中，提交乙個bug，不僅僅是這6要素這麼簡單的事情。以下是個人總結了日常測試工作中常見的一些問題：
個人總結了乙個健全的缺陷，應該盡可能的包含以下內容：
作為測試人員一般會在兩個階段遇到需求未設計或需求設計不明確的問題。
測試準備階段：
這個階段主要是了解需求，設計測試用例階段，進行過程中發現需求設計不明確或者可能不合理的地方，及時向產品確認，當前階段不需要提交缺陷（bug）。
確認結果一般有2種：
1.設計如此（不需要變更需求文件）
2.優化設計（若確認結果是優化設計，則要求產品及時更新需求文件，並將資訊同步給開發，避免開發測試資訊不對稱）。
測試週期階段
這個階段是正式進入測試流程，執行測試用例+自由探索測試階段，測試人員需要提交缺陷（bug）。深入真實測試過程中會發現開發實際設計不合理或者需求文件未明確設計的問題，此時測試人員需要提交缺陷（bug）給產品人員。
這個時候缺陷內容除了6要素之外，作為思考全面的測試人員，可以在【期望結果】內寫下「建議」的期望，然後將缺陷指派給對應的產品人員，由產品人員確認後轉交給開發進行修復解決。最後開發指派給測試進行驗收。
日誌檔案的獲取方式一般常用的有以下兩種：
抓包工具：fiddler/charles
若為request（請求）錯誤，則缺陷（bug）應該指派給前端開發
若為response（響應）錯誤，則缺陷（bug）應該指派給服務端開發
公司內部的日誌系統：可要求對應的開發人員提供對應的日誌關鍵字，方便查詢過濾日誌內容
（除了以上兩種通用的外，還有其他的手法來獲取日誌）
測試人員在提交缺陷後，經常遇到開發人員需要測試人員配合造資料來復現除錯bug，此時測試人員不得不停下手上的測試內容，配合開發，浪費溝通成本。
測試人員可以在提交缺陷後，備註附上已準備好的測試資料供開發復現除錯缺陷。
測試過程中經常遇到不同頁面路徑，但是測試人員可以判斷是同乙個原因引起的缺陷時，可在提交缺陷時，提示開發一併排查，無需乙個頁面提交乙個缺陷，增加人工提交缺陷的成本。
缺陷例項：
遇到ui上的錯誤時，在提交缺陷時，除了文字描述外，可通過上傳截**件，且在截圖上顏色標註出錯誤內容，方便開發快速理解缺陷內容。
缺陷例項：
Bug報告提交規範
首先宣告，bug的測試規範應該在公司的正式文件建立。本建議非正式文件，有些內容可能不正確，有些內容可能需要繼續商榷，甚至有些內容同公司規範有衝突。如果發現問題，直接忽略本文相應內容。本帖本意僅就工作中的一些現象記錄，可以通過簡單規範讓大家工作輕鬆，高效。後續繼續補充修改，也請大家補充修改。其次，本帖...
bug管理規範
1 2 3 4級bug判定標準如下 1 緊急 致命錯誤，例如主程式不能正常執行，基本業務功能未實現，交易資料不準確或不一致，從而使得後續流程無法正常進行 作業系統崩潰 宕機 頻繁造成資料庫死鎖或資料丟失 造成交易資料不準確 收銀對賬不一致 使用者無法註冊 登陸 正常操作，從而無法進行無法正常使用 在...
bug規範初稿
一 背景 bug是開發和測試質量的重要指標，從bug數量 嚴重性等可以看出rd的開發質量，從發現問題的階段可以看出qa的測試意識和測試質量，從問題分類 問題 等可以看出產品開發 測試質量的一些固有模式，幫助rd和qa提公升開發和測試質量。總之窺一斑而見全豹，因此統計和分析bug十分有必要。各端都將b...