1 軟體缺陷
- 缺陷是一種泛稱，它可以指功能的錯誤，也可以指性能低下，易用性差等
- 并不是所有的測試人員都能送出被開發認可的缺陷，也不是測試人員在任何時候都能送出被開發認可的缺陷
2 什麼是軟體缺陷
- 軟體未達到産品說明書标準的功能
- 軟體出現了産品說明書指明不會出現的錯誤
- 軟體功能超出産品說明書指明範圍
- 軟體未達到産品說明書雖未指出但應達到的目标
- 軟體測試員認為軟體難以了解，不易使用，運作速度緩慢，或者最終使用者認為不好
3 缺陷産生的原因
4 發現缺陷
- 使用者體驗不夠好
- 界面上有明顯的錯誤資訊
- 功能不完備，沒有按照需求說明編寫代碼，緻使某些功能缺失
- 功能不完善，不能正常運作或者運作的過程中出現程式崩潰、停止運作的情況
- 邏輯不正确，與需求說明書，測試用例不符
- 子產品之間的互動性不好，與其他的子產品做內建測試的時候遇到問題
- 程式的性能不夠好，不能承載壓力考驗
5 BUG處理的流程
6 缺陷報告
BUG重制
- 不要想當然的接受任何假設，要做好記錄
- 查找時間依賴和競争條件的問題
- 邊界條件軟體缺陷、記憶體洩漏和資料溢出等白盒問題可能會慢慢自己顯露出來
- 狀态缺陷僅在特定軟體狀态中顯露出來
- 考慮資源依賴性和記憶體、網絡、硬體共享的互相作用
7 無法重新的BUG
8 缺陷報告包含的資訊
1 易于搜尋軟體測試報告的缺陷
2 報告的軟體缺陷進行必要的隔離、報告的缺陷資訊具體、準确
3 軟體開發人員希望獲得缺陷的本質特征和複現步驟
4 市場和技術支援等部門希望獲得缺陷類型分布以及對市場和使用者的影響程度
9 缺陷報告的寫作準則(5C)
1 correct(準确)：每個組成部分的描述準确，不會引起誤解
2 clear（清晰）：每個組成部分的描述清晰，易于了解
3 concise（簡潔）：隻包含不可少的資訊，不包括任何多餘的内容
4 complete（完整）：包含複現該缺陷的完整步驟和其他本質資訊
5 consistent (一緻)：按照一緻的格式書寫全部缺陷報告
10 缺陷報告的組織架構
1 缺陷的标題
2 缺陷的基本資訊
3 測試的軟體和硬體的環境
4 測試的軟體版本
5 缺陷的類型
6 缺陷的嚴重程度
7 缺陷的處理優先級
8 複現缺陷的操作步驟
9 缺陷的實際結構描述
10 期望的正确結果描述
11 注釋文字和截圖的缺陷圖像
11 RART3-3缺陷報告原則
1 組織Structure：測試人員應該采用深思熟慮的，小心謹慎的方法執行測試，并且做詳盡的記錄。這樣可以促使他們對待測試系統有很好的認識。當錯誤發生的時候，一個有組織的測試人員能夠知道最早出現問題的地方
2 重制Reproduce：測試人員在編寫缺陷報告之前必須在檢查問題是否可複現。如果錯誤不可再重新，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫缺陷報告之前反複嘗試3次
3 隔離lsolate：在嘗試編寫缺陷報告之前，必須試着隔離錯誤。可以采用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的症狀。這些資訊可以為開發人員着手調試提供思路
4 歸納Generalize：發現了一個已隔離的，可重制的問題之後，應該對問題進行歸納。同一個問題是否出現在其他的子產品或其他的地方？同一個故障是否更加嚴重的問題
5 對比compare：如果測試人員以前曾經驗證過現在出錯的測試用例，那麼他就應該檢查以前的測試結果以檢查相同的條件以前的測試是否通過。如果是的話，那麼這個問題就像是一個回歸的錯誤。注意由于同一測試條件有可能出現在多個測試用例中，這個步驟就不僅僅隻是檢查一個測試用例在以前的多個結果。
6 總結Summarize:在缺陷報告的第一行寫上錯誤的總結是非常關鍵的。測試人員要花一些時間思考已發現的錯誤對客戶有什麼影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設定錯誤修複的優先級别。
7 精簡Condense：在缺陷報告的初稿完成後，測試人員應該反複閱讀它，集中剔除沒有關系的步驟或詞語。隐含的或模糊的說明和那些由于對沒有任何關系的細節。
8 消除歧義Disambiguate：測試人員在精簡空話的同時或其之後随即應該在仔細檢查報告是否會産生誤解的地方。
9 中立Neutralize：作為壞消息的傳遞人，和善地送出消息是一個挑戰。如同所有的錯誤總結一樣，獨立的缺陷報告在措辭方面應該保持公正。
10 檢查Review：一旦測試人員感覺缺陷報告是他能夠編寫的版本，他應該将報告再給一個或多個同行進行檢查，在允許的時間内，盡量送出一份最好的測試報告。