一、軟件項目的測試流程（重點）

1. 需求分析（閱讀、分析、整理業務）
2. 制定測試計劃
   由測試組長或測試經理完成測試計劃的制定，測試人員閱讀并按要求執行。
   拓展：
   Q1：是否能夠編寫測試計劃？
   Q2：測試計劃的主要組成部分（在測試項目時，會閱讀測試計劃，要注意將測試計劃組成部分整理出來）
3. 設計測試
   分析、設計《測試用例》的過程，需要掌握測試方法（7種）
4. 執行測試，記錄測試結果
5. 記錄缺陷（通過缺陷報告記錄），并對缺陷進行跟蹤和管理。
6. 測試總結（測試報告/測試總結報告）

二、缺陷報告（Defect-bug）

1.簡介缺陷報告

1. 測試人員發現缺陷后將缺陷記錄在《缺陷報告》中。
2. 測試方通過缺陷報告將缺陷告知給開發方（提bug）。
3. 通過缺陷報告對缺陷進行跟蹤和管理。
4. 缺陷報告是開發人員和測試人員之間重要的溝通方式。

2.如何編寫缺陷報告¹

缺陷報告的主要組成：

1.缺陷編號（Defect ID）

編號可以唯一標識這條缺陷。
按照發現缺陷的順序記錄編號 （通常是由工具自動生成的編號）
注意： 缺陷編號是項目中的缺陷統一管理。而不是只記錄你自己的。

2.缺陷標題（summary）

簡明扼要的將缺陷概括出來。
注意： 標題沒有標準答案，能夠將缺陷概括準確即可。

3.缺陷發現者/創建者（detected by）

由測試人員發現缺陷，創建缺陷報告
填測試人員的賬號/真實姓名

4.提交缺陷的日期（detected on date

注意： 缺陷報告應及時提交。
缺陷報告既不應該人為延誤，也不應該立即提交，而是應該“確認”，確定不是由于測試人員人為失誤造成的假缺陷，再提交。

5.缺陷指派給誰處理（assigned to）

首先：測試人員將bug指派給開發方負責人
接下來：再由開發方負責人將缺陷指派給具體負責的開發人員。

6. 缺陷所屬的功能模塊（subject）

說明： 可以實現對bug的基本定位。
開發方負責人可以通過功能模塊，快速確定負責解決該bug 的開發人員。

7. 發現缺陷的版本（detected in release/version）

說明： 這里所指的版本，不僅指最終發布的版本，也包括在研發過程中出現過的臨時版本。
拓展：
回歸測試：
在當前版本中，對上一個版本的所有功能要重新再測試一遍，叫回歸測試。
為什么做回歸測試：
1. 新增加的功能可能會對原有功能造成影響。
2. 解決的bug，有可能會對原有功能造成影響。
在企業中，對于回歸測試，可以采用自動化測試的方式進行，這樣可以提高回歸測試效率。

8. 狀態 （status）

缺陷處于怎樣的處理情況

1. 常用狀態

新的–new
激活的–open
已解決的–fixed
關閉的 --closed
被拒絕的–rejected
重新激活的–reopen

2. 缺陷報告的跟蹤處理流程（步驟、生命周期）？【重點】

1. 測試人員提交新的缺陷報告給開發方負責人。
2. 開發方負責人驗證（確認）缺陷：
3. 如果驗證為缺陷，開發負責人激活該缺陷，并指派給相應的開發人員。
4. 如果驗證未通過，開發負責人將拒絕該缺陷。 步驟3：被指派的開發人員解決該缺陷，解決完成后將缺陷設置為“已解決”狀態。（理解為：待返測的缺陷） 步驟4：測試人員返測已解決的缺陷，
5. 如果返測通過，測試人員將缺陷關閉。
6. 如果返測沒有通過，測試人員將缺陷重新激活，指派回該開發人員繼續解決，直到返測通過，缺陷關閉為止。

Q1：如果提交的bug被拒絕了，測試人員應如何處理？(思路）

1. 測試人員首先自己確認，是否由于自己失誤造成假缺陷。
2. 如果確認自己沒有失誤，接下來：分析被拒原因， 與相關人員進行溝通，討論，最終確認是否是假缺陷。
   如果是假缺陷，測試方負責關閉該假缺陷。 如果是缺陷，誰拒絕的，誰負責將缺陷激活，納入回缺陷處理流程。
   最后：如果在溝通，討論過程中遇到問題，可以向直屬上級領導匯報，并請求幫助。

Q2：用狀態的變化來表示缺陷報告的跟蹤處理過程：

1. 常規處理過程 new→open→fixed→closed
2. 帶有返測失敗的處理過程（失敗1次） new→open→fixed→reopen→fixed→closed

9.缺陷的嚴重程度（severity）

表明該缺陷有多糟糕，對程序的影響有多壞。
嚴重程度常規級別：

 1--致命的--urgent2--嚴重的--high3--一般的（中等的）--medium （比例相對較高）4--建議性的小問題--low

說明： 個別的缺陷管理工具中，在致命和嚴重之間增加了“非常嚴重–very high”這個級別。（不常用）
問題： 嚴重級別的定義過于籠統，在實際工作中容易產生爭論，所以企業通常會制定更為詳細的嚴重級別說明。
注意：

1. 不同企業，不同項目組，嚴重級別的詳細說明都可能不同，要注意參考。
2. 測試人員應該嚴格判定嚴重級別，不應受個人情緒影響，或為了引起開發方重視而擅自更改級別。

10.缺陷的優先級（priority）

希望或建議開發方在什么時間或什么版本，解決該bug。
優先級的常規級別：

1--立即解決--urgent
2--下一個版本解決--high （常用）
3--在軟件產品發布之前解決--medium
4--盡量在軟件產品發布之前解決--low有可能有發現的bug沒有解決，軟件產品就發布了。

說明：

1. 個別的管理工具中，在1-urgent 和2-high 級別之間增加一個 very high-在當前版本解決 的級別。
2. 優先級的定義不同企業，不同項目組可能有不同，要具體參考。

11.缺陷描述（description）

就是將發現缺陷的過程（步驟、數據）記錄下來，使開發人員能夠重現該缺陷。
目的： 讓開發人員看明白，能重現缺陷
要求： 邏輯清晰，用語專業準確，易懂，不要出現評價性的語言。（如實記錄）

隨機缺陷

也叫不可重現缺陷，按照相同的操作過程，時有時無的缺陷。
注意事項：

1. 隨機缺陷應該要提交，并且提交時應說明該缺陷為隨機缺陷。
2. 對于隨機缺陷，測試人員應盡量詳細描述，最好能夠提供證跡（截圖、視頻）。
   提示：測試人員應養成隨手截證跡的習慣。
3. 測試人員應盡量配合開發方關于隨機缺陷的調查，例如：短時間保留測試環境，提供隨機缺陷出現的頻率等。
4. 測試方可以提供白盒測試手段，配合隨機bug的調查。

Q1：影響優先級的因素有哪些？
Q2：嚴重程度和優先級是嚴格的正比關系嗎？
Q3：嚴重程度和優先級確定之后能改嗎？
Q4：在發布的軟件產品中，是否可能有發現但沒有解決的bug？（適當介紹）