一、首先我們從項目測試的基本的流程開始瞭解
1、熟悉需求
2、編寫、閱讀《測試計劃》
說明：編寫《測試計劃》一般由測試組長或經理完成
3、設計測試（編寫《測試用例》）
4、執行測試（執行測試用例），並且還要記錄執行結果
5、記錄缺陷結果（缺陷報告），跟蹤、管理缺陷
6、測試結果(總結報告
二、缺陷報告（每個公司的要求不一樣，我寫的是大多數公司缺陷報告的情況）
1、什麼是缺陷報告？
測試人員發現缺陷，通過缺陷報告記錄缺陷—>將缺陷報告提交給開發，並跟蹤管理缺陷。
缺陷報告是測試人員和開發人員之間重要的溝通工具。
2、缺陷報告如何編寫？
說明：在企業中爲了提高缺陷的管理效率和質量通常會使用管理工具，例如：QC，禪道，bugzilia等，不同
企業使用的工具不同。缺陷管理可能會有差異，打算大同小異。
1）缺陷報告的主要組成：
（1）缺陷編號（defect id）記錄發現缺陷的順序，可以通過編號唯一標識每條缺陷。
缺陷編號是一項目爲單位進行的。
在測試管理中，缺陷編號通常是自動生成的。
（2）缺陷標題（summary）
簡單的描述該缺陷。（概括）
（3）缺陷發現者（detected by）
就是發現缺陷的測試人員自己。
通常在測試管理工具中默認當前系統的登錄用戶
（4）指派給誰（assigned to）
首先測試人員將缺陷報給指派給開發方的負責人
（5）提交缺陷的日期（detected on date）
發現缺陷及時的提交給開發人員。
在測試管理工具中通常會將系統時間默認填入
（6）發現缺陷的功能模塊（subject）
方便開發經理確認該模塊缺陷有哪個開發人員負責
可以協助開發人員定位缺陷
（7）缺陷所屬的版本（detected in release/version）
說明：這裏所指的版本不僅是最終發佈的版本，也包括在軟件開發過程中 形成的臨時版本。
迴歸測試：在新版本中對上一個版本中測過的功能重新再測試一遍。
爲什麼要做迴歸測試：
1）修改的缺陷有可能會對原有的功能帶來新的問題
2）新增加的功能有可能會給原有功能到來新的缺陷
在企業中，往往會使用自動化工具來完成迴歸測試，提高測試效率。
（8）缺陷的狀態（status）
描述缺陷當前的情況。
缺陷的處理過程
步驟1：測試人員填寫報告，提交給開發經理，此時狀態爲：new （新的缺陷）
步驟2：開發經理要驗證缺陷
情況1：缺陷驗證通過，開發經理會激活缺陷，並將缺陷指派給相應的開
發人員。此時狀態爲:open
情況2：缺陷驗證不通過，開發經理會拒絕該缺陷。此時狀態爲:rejected
擴展：被拒絕後測試人員首先要確認是否是有操作或配置錯誤造成的假缺陷，
然後如果是由於對於需求理解不同造成的可以跟產品部門溝通確認，
最後，如果雙方不能重現該缺陷，要儘量溝通，配合重現。如果還不能
確定再去跟測試部門領導溝通反饋問題。經過上述過程如果最終確認是
假缺陷，那麼有測試人員關閉該缺陷。如果是缺陷，就有誰關閉的誰激
活，繼續完成缺陷處理流程。
步驟3：開發人員負責解決指派給他缺陷。解決之後將缺陷狀態設置爲：fixed（解決缺陷，等待返測的缺陷）
步驟4：測試人員負責返測這個缺陷
情況1：如果返測通過，測試人員將缺陷關閉。此時狀態爲：close（關閉的缺陷，可歸檔的缺陷）
情況2：如果返測沒有通過，測試人員要將缺陷重新激活，此時設置缺陷狀態爲：reopen
（重新激活缺陷），開發人員繼續修改缺陷，修改後再次將缺陷狀態設置爲：fixed，測試人員
再次返測，直到缺陷解決被關閉爲止。
1、缺陷的基本處理過程
new->open->fixed->close
2、帶返測失敗（1次）的缺陷處理過程
new->open->fixed->reopen->fixed->close
3、被拒絕的缺陷的處理過程
new->rejected->close
new ->rejected->open->fixed->close
(9)缺陷的嚴重程度（severity）
指明缺陷有多糟糕或對程序的影響有多大
缺陷的嚴重級別的分級定義（以qc爲例）：
Urgent：致命的缺陷 （造成計算機死機，系統崩潰等）
Very high：非常嚴重的缺陷
High： 嚴重缺陷
Medium：一般的缺陷
Low：提示、建議類的缺陷
（10）缺陷的優先級（priority）
希望或建議開發方在什麼時候或什麼版本解決該缺陷
優先級的級別定義：
Urgent：需要開發人員放下手頭的開發任務立即解決的缺陷（通常不解決會影響整個開發和測試的進度）
Very high：在當前版本內解決
High：在下個版本中解決（常用）
Medium：在軟件發佈之前解決
Low:儘量在軟件發佈之前解決（有可能在軟件發佈時帶有沒有解決的bug）
(11) 缺陷描述（description）
說明：將發現缺陷的過程、數據記錄下來，讓開發人員能夠再現該缺陷（就是讓開發人員能知道並再現這個缺陷）
擴展：在缺陷報告中要附帶證跡（截圖，視頻）
關於缺陷的嚴重程度和優先級
1）影響缺項優先級定義的因素有哪些？
（1）缺陷的嚴重程度，一般情況下越嚴重的缺陷的優先級越高
（2）缺陷影響的範圍，影響範圍越大，優先級越高
（3）開發人員的開發壓力，開發壓力越小，優先級越高
（4）解決缺陷的成本，（時間）--成本越低，優先級越高
2）缺陷的嚴重程度和優先級是嚴格的正比關係嗎？
不是 例如：界面錯別字
3）缺陷的嚴重程度和優先級確定後可以修改嗎？
缺陷的嚴重程度確定後一般不改，優先級可以修改。
4）是否有爲解決的缺陷在軟件發佈版本中存在？
存在 企業可以通過打補丁或者升級版本。
擴展:
不可重現的缺陷：也叫隨機缺陷，按照相同的操作過程時有時無得缺陷。
如何處理：
1、首先在提交缺陷時要說明這是一個不可重現的缺陷。
2、儘量詳盡的描述發現不可重現的過程，儘量配合附加證跡（截圖、視頻）
3、如果需要，要將發現的測試環境和配置保留，配合開發人員定位缺陷。
4、如果必要還可以配合白合測試，從程序內部定位不可重現的缺陷。