一、測試策略
1、編寫測試計畫
2、編寫測試用例
3、執行測試，發現缺陷提交缺陷報告
4、驗證所發現的缺陷是否得到修改
5、編寫測試總結報告
二、缺陷報告的組成
即缺陷的處理流程，是乙個缺陷的生命週期
1、缺陷編號（defect id）
提交缺陷的順序
2、缺陷標題（summary）
簡明扼要的描述缺陷
3、缺陷的發現者（detected by）
測試人員
4、發現缺陷的日期（detected on date）
一般為當天
5、缺陷所屬的模組（subject）
在測試哪個功能模組的時候發現的bug（開發組可以據此決定由誰負責修改該bug）
6、發現缺陷版本（detected in release）
在測試哪個版本時候發現的bug
7、指派給誰處理（assigned to）
測試人員指派給開發經理，開發經理根據缺陷所在的模組，需要再次指派具體的開發人員
8、缺陷的狀態（status）
缺陷此時所處的處理階段或處理情況
（1）測試人員發現缺陷，提交缺陷報告，把缺陷的狀態置為：new（新發現的bug）
（2）開發經理驗證新提交的bug，如果是bug，把狀態改為open（開啟的bug，開發組接受的bug），指派給具體的開發人員解決；如果不是bug，把狀態改為rejected（拒絕的bug）
（3）開發人員看到指派給自己解決的bug，進行bug修復，修改完後，把bug狀態改為：fixed（已經修復的bug，可以返測的bug）
（4）測試人員對修復的bug進行反側，返測成功，把狀態改為closed（關閉的缺陷，歸檔的bug）；如果返測不成功，把狀態改為：reopen（重新開啟的bug）
9、缺陷的嚴重程度（severity）
bug對軟體的影響程度有多大
urgent：造成系統宕機、重啟、崩潰的缺陷
veryhigh：非常嚴重的缺陷
high：嚴重的缺陷
medium：中等程度的缺陷
low：小的缺陷
每乙個等級包括哪些缺陷，需要在文件中進行詳細說明，這樣可以使開發和測試人員達成共識
10、缺陷的優先順序（priority）
測試人員希望該缺陷程式設計師在什麼時間內或者在哪個版本解決
urgent：立刻修改（影響開發或測試的進度）
veryhigh：本版本修改
high：下版本修改
medium：發布前修改
low：允許在發布當中存在的缺陷
11、缺陷描述（description）*
把發現bug的步驟，使用的資料等記錄下來，使程式設計師通過該描述就清楚所發生的事情
要求：描述清晰，並可以重現缺陷
三、缺陷報告的用途
1、記錄bug
2、對bug進行分類（模組、bug狀態、嚴重程度、版本）
3、跟蹤bug
4、對bug進行分析統計
四、如何識別bug
1、通過測試用例的預期結果判斷-實際結果與預期結果不一致，就是bug
2、看需求（通過缺陷的5點定義識別）
3、溝通
識別和描述缺陷
什麼是缺陷？1.不滿足使用者確定需求。2.缺陷就是人們通常所說的bug。缺陷的識別 1.通過參考文件來確認缺陷 需求規格說明書，概要設計，詳細設計，使用者手冊等 2.通過了解軟體行業標準，行業背景來發現缺陷。3.通溝通來確認和識別缺陷。軟體缺陷產生的原因 再現與優化缺陷 再現又叫重現，優化缺陷不並不...
回歸測試的策略及方法
業界的 回歸測試策略基本上有兩種 全部回歸，也就是把之前的所有的測試用例，無論是手動的，還是自動的，全部跑一遍 部分回歸，定性分析 改動有哪些影響，改動的檔案 模組和其他的檔案 模組的依賴性，然後選擇被影響到的檔案 模組相應的測試用例來跑一遍 第一種的好處就是，通過大量的跑測試用例，可以盡量多的發現...
回歸測試的策略及方法
業界的回歸測試策略基本上有兩種 全部回歸，也就是把之前的所有的測試用例，無論是手動的，還是自動的，全部跑一遍 部分回歸，定性分析 改動有哪些影響，改動的檔案 模組和其他的檔案 模組的依賴性，然後選擇被影響到的檔案 模組相應的測試用例來跑一遍 第一種的好處就是，通過大量的跑測試用例，可以盡量多的發現哪...