生命就像一場云游 坎坷也是一種收獲
準確報告軟件缺陷
上一篇 /
下一篇 2008-03-26 17:15:09
/ 個人分類：缺陷管理
軟件缺陷的描述是是軟件缺陷報告的基礎部分，也是測試人員就一個軟件問題與開發小組交流的最初且最好的機會。一個好的描述，需要使用簡單的、準確的、專業的語言來抓住缺陷的本質。否則，它就會使信息含糊不清，可能會誤導開發人員。準確報告軟件缺陷是非常重要的，因為：
- 清晰準確的軟件缺陷描述可以減少軟件缺陷從開發人員返回的數量
- 提高軟件缺陷修復的速度，使每一個小組能夠有效的工作
- 提高測試人員的信任度，可以得到開發人員對清晰的軟件缺陷描述有效的響應
- 加強開發人員，測試人員和管理人員的協同工作，讓他們可以更好的工作
在多年實踐的基礎上，我們積累了較多的軟件缺陷的有效描述規則，主要是：
- 單一準確。每個報告只針對一個軟件缺陷。在一個報告中報告多個軟件缺陷的弊端是常常會導致缺陷部分被注意和修復，不能得到徹底的修正。
- 可以再現。提供缺陷的精確操作步驟，使開發人員容易看懂，可以自己再現這個缺陷，通常情況下，開發人員只有再現了缺陷，才能正確地修復缺陷。
- 完整統一。提供完整、前后統一的軟件缺陷的步驟和信息，例如：圖片信息，Log文件等。
- 短小簡練。通過使用關鍵詞，可以使軟件缺陷的標題的描述短小簡練，又能準確解釋產生缺陷的現象。如“主頁的導航欄在低分辨率下顯示不整齊”中“主頁”、“導航欄”、“分辨率”等是關鍵詞。
- 特定條件。許多軟件功能在通常情況下沒有問題，而是在某種特定條件下會存在缺陷，所以軟件缺陷描述不要忽視這些看似細節的但又必要的特定條件（如特定的操作系統、瀏覽器或某種設置等），能夠提供幫助開發人員找到原因的線索。如“搜索功能在沒有找到結果返回時跳轉頁面不對”。
- 補充完善。從發現bug那一刻起，測試人員的責任就是保證它被正確的報告，并且得到應有的重視，繼續監視其修復的全過程。
- 不做評價。在軟件缺陷描述不要帶有個人觀點，對開發人員進行評價。軟件缺陷報告是針對產品、針對問題本身，將事實或現象客觀地描述出來就可以，不需要任何評價或議論。
軟件缺陷屬性MILY: 宋體">包括缺陷標識、缺陷類型、缺陷嚴重程度、缺陷產生可能性、缺陷優先級、缺陷狀態、缺陷起源、缺陷來源、缺陷原因。
1. 缺陷標識：是標記某個缺陷的唯一的表示，可以使用數字序號表示。
2. 缺陷類型：是根據缺陷的自然屬性劃分缺陷種類，如表1所示
表1軟件缺陷類型列表
|
缺陷類型 |
描述 |
|
功能 |
影響了各種系統功能、邏輯的缺陷 |
|
用戶界面 |
影響了用戶界面、人機交互特性，包括屏幕格式、用戶輸入靈活性、結果輸出格式等方面的缺陷 |
|
文檔 |
影響發布和維護，包括注釋，用戶手冊，設計文檔 |
|
軟件包 |
由于軟件配置庫、變更管理或版本控制引起的錯誤 |
|
性能 |
不滿足系統可測量的屬性值，如執行時間，事務處理速率等。 |
|
系統/模塊接口 |
與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表等不匹配、沖突。 |
<!--[if !supportLists]-->
3. 缺陷嚴重程度：是指因缺陷引起的故障對軟件產品的影響程度，所謂“嚴重性”我指的是在測試條件下，一個錯誤在系統中的絕對影響。如表2所示
<!--[endif]-->
表2軟件缺陷嚴重等級列表
|
缺陷嚴重等級 |
描述 |
|
致命 (Fatal) |
系統任何一個主要功能完全喪失、用戶數據受到破壞、系統崩潰、懸掛、死機，或者危及人身安全 |
|
嚴重 (Critical) |
系統的主要功能部分喪失、數據不能保存，系統的次要功能完全喪失，系統所提供的功能或服務受到明顯的影響 |
|
一般 (Major) |
系統的次要功能沒有完全實現，但不影響用戶的正常使用。例如：提示信息不太準確；或用戶界面差、操作時間長等一些問題。 |
|
較小 (Minor) |
使操作者不方便或遇到麻煩，但它不影響功能的操作和執行，如個別的不影響產品理解的錯別字、文字排列不對齊等一些小問題。 |
4. 缺陷產生的可能性：指缺陷在產品中發生的可能性，通�？梢杂妙l率來表示，如表3所示。
<!--[endif]-->
表3 缺陷產生可能性列表
|
缺陷產生可能性 |
描述 |
|
總是 (Always) |
總是產生這個軟件缺陷，其產生的頻率是100% |
|
通常 (Often) |
按照測試用例，通常情況下會產生這個軟件缺陷，其產生的頻率大概是80-90% |
|
有時 (Occasionally) |
按照測試用例，有的時候產生這個軟件缺陷，其產生的頻率大概是30-50% |
|
很少 (rarely) |
按照測試用例，很少產生這個軟件缺陷，其產生的頻率大概是1-5% |
<!--[if !supportLists]--> 5. 缺陷優先級：指缺陷必須被修復的緊急程度�！皟炏燃墶钡暮饬孔プ×嗽趪乐匦灾袥]有考慮的重要程度因素，如表4所示。
<!--[endif]-->
表4 軟件缺陷優先級列表
|
缺陷優先級 |
描述 |
|
立即解決(P1級) |
缺陷導致系統幾乎不能使用或測試不能繼續，需立即修復 |
|
高優先級(P2級） |
缺陷嚴重，影響測試，需要優先考慮 |
|
正常排隊(P3級） |
缺陷需要正常排隊等待修復 |
|
低優先級(P4級） |
缺陷可以在開發人員有時間的時候被糾正。 |
一般來講，缺陷嚴重等級和缺陷優先級相關性很強，但是，具有低優先級和高嚴重性的錯誤是可能的，反之亦然。例如，產品徽標是重要的，一旦它丟失了，這種缺陷是用戶界面的產品缺陷，但是它阻礙產品的形象。那么它是優先級很高的軟件缺陷。
<!--[if !supportLists]--> 6. 缺陷狀態：指缺陷通過一個跟蹤修復過程的進展情況，也就是在軟件生命周期中的狀態基本定義，如表5所示。
<!--[endif]-->
表5 軟件缺陷狀態列表
|
缺陷狀態 |
描述 |
|
激活 或打開
（Active or Open） |
問題還沒有解決，存在源代碼中，確認“提交的缺陷”，等待處理，如新報的缺陷。 |
|
已修正 或修復
(Fixed or Resolved) |
已被開發人員檢查、修復過的缺陷，通過單元測試，認為已解決但還沒有被測試人員驗證 |
|
關閉或非激活
(Close or Inactive) |
測試人員驗證后，確認缺陷不存在之后的狀態。 |
|
重新打開 |
測試人員驗證后，還依然存在的缺陷，等待開發人員進一步修復 |
|
推遲 |
這個軟件缺陷可以在下一個版本中解決 |
|
保留 |
由于技術原因或第三者軟件的缺陷，開發人員不能修復的缺陷 |
|
不能重現 |
開發不能復現這個軟件缺陷，需要測試人員檢查缺陷復現的步驟。 |
|
需要更多信息 |
開發能復現這個軟件缺陷，但開發人員需要一些信息，例如：缺陷的日志文件，圖片等。 |
<!--[if !supportLists]-->
<!--[if !supportLists]-->7. 缺陷來源：指缺陷所在的地方，如文檔、代碼等，如表6所示。
<!--[endif]-->
表6 軟件缺陷來源列表
|
缺陷來源 |
描述 |
|
需求說明書 |
需求說明書的錯誤、或不清楚引起的問題 |
|
設計文檔 |
設計文檔描述不準確、和需求說明書不一致的問題 |
|
系統集成接口 |
系統各模塊參數不匹配、開發組之間缺乏協調引起的缺陷 |
|
數據流(庫) |
由于數據字典、數據庫中的錯誤引起的缺陷 |
|
程序代碼 |
純粹在編碼中的問題所引起的缺陷 |
<!--[if !supportLists]-->8. 缺陷根源：指造成上述錯誤的根本因素，以尋求軟件開發流程的改進、管理水平的提高，如表7所示。
<!--[endif]-->
表7 軟件缺陷根源列表
|
缺陷根源 |
描述 |
|
測試策略 |
錯誤的測試范圍，誤解了測試目標，超越測試能力等 |
|
過程，工具和方法 |
無效的需求收集過程，過時的風險管理過程，不適用的項目管理方法，沒有估算規程，無效的變更控制過程等。 |
|
團隊/人 |
項目團隊職責交叉，缺乏培訓。沒有經驗的項目團隊，缺乏士氣和動機不純等。 |
|
缺乏組織和通訊 |
缺乏用戶參與，職責不明確，管理失敗等。 |
|
硬件 |
硬件配置不對、缺乏，或處理器缺陷導致算術精度丟失，內存溢出等 |
|
軟件 |
軟件設置不對、缺乏，或操作系統錯誤導致無法釋放資源，工具軟件的錯誤，編譯器的錯誤，2000 千年蟲問題等。 |
|
工作環境 |
組織機構調整，預算改變，工作環境惡劣，如噪音過大。 |
導入論壇
引用鏈接
收藏
分享給好友
推薦到圈子
管理
舉報
TAG:
