9.缺陷的嚴重程度（severity）
10.缺陷的優先順序（priority）
11.缺陷描述（description）
q1：是否能夠編寫測試計畫？
設計測試
分析、設計《測試用例》的過程，需要掌握測試方法（7種）
執行測試，記錄測試結果
記錄缺陷（通過缺陷報告記錄），並對缺陷進行跟蹤和管理。
測試總結（測試報告/測試總結報告）
測試人員發現缺陷後將缺陷記錄在《缺陷報告》中。
測試方通過缺陷報告將缺陷告知給開發方（提bug）。
通過缺陷報告對缺陷進行跟蹤和管理。
缺陷報告是開發人員和測試人員之間重要的溝通方式。
在企業中通過工具對缺陷進行管理，例如：禪道（中文、免費）、qc（hp,英文，付費）、bugzilla、bugfree、自製的管理工具等。
注意： 缺陷報告的管理工具不同，模板可能會有差異，但是核心部分大同小異。
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. 缺陷報告的跟蹤處理流程（步驟、生命週期）？【重點】
測試人員提交新的缺陷報告給開發方負責人。
開發方負責人驗證（確認）缺陷：
如果驗證為缺陷，開發負責人啟用該缺陷，並指派給相應的開發人員。
如果驗證未通過，開發負責人將拒絕該缺陷。 步驟3：被指派的開發人員解決該缺陷，解決完成後將缺陷設定為「已解決」狀態。（理解為：待返測的缺陷） 步驟4：測試人員返測已解決的缺陷，
如果返測通過，測試人員將缺陷關閉。
如果返測沒有通過，測試人員將缺陷重新啟用，指派回該開發人員繼續解決，直到返測通過，缺陷關閉為止。
q1：如果提交的bug被拒絕了，測試人員應如何處理？(思路）
測試人員首先自己確認，是否由於自己失誤造成假缺陷。
如果確認自己沒有失誤，接下來：分析被拒原因， 與相關人員進行溝通，討論，最終確認是否是假缺陷。
如果是假缺陷，測試方負責關閉該假缺陷。 如果是缺陷，誰拒絕的，誰負責將缺陷啟用，納入回缺陷處理流程。
最後：如果在溝通，討論過程中遇到問題，可以向直屬上級領導匯報，並請求幫助。
q2：用狀態的變化來表示缺陷報告的跟蹤處理過程：
常規處理過程 new→open→fixed→closed
帶有返測失敗的處理過程（失敗1次） new→open→fixed→reopen→fixed→closed
9.缺陷的嚴重程度（severity）
表明該缺陷有多糟糕，對程式的影響有多壞。
嚴重程度常規級別：
1--致命的--urgent
2--嚴重的--high
3--一般的（中等的）--medium （比例相對較高）
4--建議性的小問題--low
問題： 嚴重級別的定義過於籠統，在實際工作中容易產生爭論，所以企業通常會制定更為詳細的嚴重級別說明。
注意：
不同企業，不同專案組，嚴重級別的詳細說明都可能不同，要注意參考。
測試人員應該嚴格判定嚴重級別，不應受個人情緒影響，或為了引起開發方重視而擅自更改級別。
10.缺陷的優先順序（priority）
希望或建議開發方在什麼時間或什麼版本，解決該bug。
優先順序的常規級別：
1--立即解決--urgent
2--下乙個版本解決--high （常用）
3--在軟體產品發布之前解決--medium
4--盡量在軟體產品發布之前解決--low
有可能有發現的bug沒有解決，軟體產品就發布了。
個別的管理工具中，在1-urgent 和2-high 級別之間增加乙個 very high-在當前版本解決 的級別。
優先順序的定義不同企業，不同專案組可能有不同，要具體參考。
11.缺陷描述（description）
就是將發現缺陷的過程（步驟、資料）記錄下來，使開發人員能夠重現該缺陷。
目的： 讓開發人員看明白，能重現缺陷
要求： 邏輯清晰，用語專業準確，易懂，不要出現評價性的語言。（如實記錄）
隨機缺陷
也叫不可重現缺陷，按照相同的操作過程，時有時無的缺陷。
注意事項：
隨機缺陷應該要提交，並且提交時應說明該缺陷為隨機缺陷。
測試人員應盡量配合開發方關於隨機缺陷的調查，例如：短時間保留測試環境，提供隨機缺陷出現的頻率等。
測試方可以提供白盒測試手段，配合隨機bug的調查。
q1：影響優先順序的因素有哪些？
q2：嚴重程度和優先順序是嚴格的正比關係嗎？
q3：嚴重程度和優先順序確定之後能改嗎？
q4：在發布的軟體產品中，是否可能有發現但沒有解決的bug？（適當介紹）
缺陷報告編號1
標題***
發現者yn
日期2020-4-27 20:36:51
指派jh
功能模組
登入模組
版本1.0
狀態新的（new）
嚴重級別
2-嚴重
優先順序2-下乙個版本
缺陷報告示例 ↩︎
軟體測試 缺陷報告
缺陷報告是描述軟體缺陷現象和重現步驟地集合。軟體缺陷報告software bug report sbr 或軟體問題報告software problem report spr 作用 缺陷報告是軟體測試人員的工作成果之一，體現軟體測試的價值缺陷報告可以把軟體存在的缺陷準確的描述出來，當測試人員發現乙個缺...
軟體測試 缺陷報告
缺陷報告是描述軟體缺陷現象和重現步驟地集合。軟體缺陷報告software bug report sbr 或軟體問題報告software problem report spr 作用 缺陷報告是軟體測試人員的工作成果之一，體現軟體測試的價值缺陷報告可以把軟體存在的缺陷準確的描述出來，當測試人員發現乙個缺...
軟體測試之缺陷報告
今天還是個下雨天，就像乙個魔咒，感覺這幾年的今天都是在下雨，但是今天的雨讓我感覺還是蠻舒適的，可能是因為昨天太熱了，也有可能是今天的忙碌讓我在這種空氣下感覺到一種放鬆 今天是執行測試用例的一天，那麼在這個過程中就避免不了會有bug出現，我們要怎樣有效的去記錄一條缺陷呢 一條缺陷記錄基本包括 bug編...