需求分析——測試計畫——測試設計——測試開發——測試執行——測試評估
乙個合格的bug描述應該包括以下幾個部分：
一.發現問題的版本
開發人員需要知道出現問題的版本，才能夠獲取對應版本的**來重現故障，並且版本的標識也有利於統計和分析每個版本的質量
二.問題出現的環境三.錯誤重現的步驟
描述問題重現的最短步驟
四.預期行為的描述
需要讓開發人員知道怎樣的行為是正確的，尤其要以使用者的角度來描述程式的行為是怎麼樣的。
五.錯誤行為的描述
描述錯誤的現象，如ui問題可以截圖展示
六.不要將多個bug放在一起
在無法確認是同一段**造成的故障時，不要將bug放在一起提交
bug的定義每個公司標準不一樣，在定義級別之前需要檢視公司規範
舉個例子：
1.blocker(崩潰)
2.critical(嚴重)
3.major(一般)
4.minor(次要)
每個公司對bug生命週期的定義都是不一致的，大致為
新建-提交-分配-確認-修復-檢驗-關閉
測試人員應該跟蹤乙個bug的整個生命週期，從open到closed
例子：bug狀態轉換圖：
1.new 新發現的bug，未經評審決定是否指派給開發人員進行修改2.open 確認是bug，並且認為需要進行修改，指派給相關的開發人員
3.fixed:開發人員進行修改後標識成修改狀態，有待測試人員進行回歸測試驗證
4.rejected: 如果認為不是bug，則拒絕修改
5.delay: 如果認為暫時不需要進行修改或者暫時不能修改，則延後修改
6.closed:修改狀態的bug經過測試人員的回歸測試驗證通過，則關閉bug
7.reopen：如果驗證bug仍然存在，則需要重新開啟bug，開發人員重新進行修改
如何清晰的描述BUG BUG的基本屬性都有哪些
來自it公司面試手冊 標題使用一兩句話來描述錯誤，告訴經理 開發人員以及其他讀者為什麼應該關心該問題。好的標題應該著重於出現的bug現象。但是過於簡潔易引起誤導，使得原本重要的問題被忽視。因此必須應該採用簡潔 切中要害的概要，這樣才能引起讀者的重視。不重要的就描述比較輕微，例如 聯絡人的email沒...
軟體測試 測試過程簡單描述
敏捷開發 瀑布模型 1.確認專案時間，進行測試項規劃 2.產出測試計畫 人員時間 預計編寫測試用例時間 預計執行功能測試用例時間 預計回歸測試時間 預計相容性測試時間 預計執行介面測試時間 1.設計功能測試用例 2.設計介面測試用例 單元測試 範圍 內部邏輯 方法 白盒測試 考察 覆蓋率 介面測試 ...
軟體測試基礎 軟體測試的原則
所有的軟體測試都應該追溯到使用者需求。即應該重視需求文件，明確最初的需求才能盡可能減少後期的錯誤 盡早啟動測試工作，盡可能早地發現問題。問題越是遺留到後面修改的成本越大 pareto法則適用於軟體測試，又稱28效率法則，即早期應該能夠發現大量的問題 窮盡測試是不可能的，應當做適當的風險分析 殺蟲劑免...