【軟體測試】軟體缺陷
1.軟體缺陷的描述
1.1 軟體缺陷是什麼？
軟體缺陷指的是系統或系統部件中那些導致系統或部件不能實現其功能的缺陷。如果在執行中遇到一個缺陷，可能引起系統的失效。那麼準確有效的定義和描述軟體缺陷，可以使軟體缺陷得以快速修復，節約了軟體測試專案的成本和資源，提高產品質量。
1.2 軟體缺陷的基本描述
軟體缺陷的描述是軟體缺陷報告中測試人員對問題的陳述的一部分並且是軟體缺陷報告的基礎部分。同時，軟體缺陷的描述也是測試人員就一個軟體問題與開發小組交流的最初且最好的機會。一個好的描述，需要使用簡單的、準確的、專業的語言來抓住缺陷的本質。
以下是軟體缺陷的有效描述規則：
- 單一準確
- 可以再現
- 完整統一
- 短小簡練
- 特定條件
- 補充完善
- 不做評價
1.3 軟體缺陷標識和型別
軟體缺陷屬性包括缺陷標識、缺陷型別、缺陷嚴重程度、缺陷產生可能性、缺陷優先順序、缺陷狀態、缺陷起源、缺陷來源、缺陷原因。
- 缺陷標識：是標記某個缺陷的唯一的表示，可以使用數字序號表示。
- 缺陷型別：是根據缺陷的自然屬性劃分缺陷種類。見軟體缺陷型別列表：
1.3.1 軟體缺陷缺陷嚴重程度
缺陷嚴重程度：是指因缺陷引起的故障對軟體產品的影響程度，所謂“嚴重性”我指的是在測試條件下，一個錯誤在系統中的絕對影響。見軟體缺陷嚴重等級列表：
1.3.2 軟體缺陷缺陷產生的可能性和優先順序
缺陷產生的可能性：指缺陷在產品中發生的可能性，通常可以用頻率來表示。
缺陷優先順序：指缺陷必須被修復的緊急程度。“優先順序”的衡量抓住了在嚴重性中沒有考慮的重要程度因素。
1.3.3 軟體缺陷缺陷狀態
缺陷狀態：指缺陷通過一個跟蹤修復過程的進展情況，也就是在軟體生命週期中的狀態基本定義，如軟體缺陷狀態列表所示:
1.3.4 軟體缺陷缺陷起源和來源
缺陷起源：缺陷引起的故障或事件第一次被檢測到的階段，如軟體缺陷起源列表所示。
缺陷來源：指缺陷所在的地方，如文件、程式碼等，如軟體缺陷來源列表所示。
1.3.5 軟體缺陷缺陷根源
缺陷根源：指造成上述錯誤的根本因素，以尋求軟體開發流程的改進、管理水平的提高，如軟體缺陷根源列表所示。
2.軟體缺陷相關的資訊
2.1 軟體缺陷相關的資訊
軟體缺陷相關的資訊包括軟體缺陷的圖片、記錄資訊和如何再現和分離軟體缺陷；對於某一個軟體缺陷報告，測試人員應該給予相關的資訊，例如捕捉到軟體缺陷日誌檔案和圖片，保證開發人員和其他的測試人員可以分離和重現它。
軟體缺陷的圖片、記錄資訊
記錄軟體缺陷的相關圖片
一些涉及使用者介面(User Interface)的軟體缺陷可能很難用文字清楚地描述，因此軟體測試人員通過附上圖片比較直觀地表示缺陷發生在產品介面什麼位置、有什麼問題等。
使用Soft-ICE記錄軟體缺陷資訊
Soft-ICE 是 Compuware公司的產品NuMega DriverStudio中一個代表性的工具，用於跟蹤軟體執行時的變數、記憶體等狀態，而且可以捕捉系統崩潰時的狀態。使用它可以記錄產品發生缺陷的地方，同時生成日誌檔案。
2.1.1 如何使用Soft-ICE
當出現軟體系統崩潰的缺陷時，測試人員需要在軟體缺陷報告上附上日誌檔案，便於開發人員即時修復軟體缺陷。
當遭遇軟體崩潰時候，如何使用Soft-ICE？在開始測試之前，已經安裝了Soft-ICE並啟動了“faults on”的命令。當軟體發生崩潰現象時，可以使用下面命令去捕捉必要的資訊：
stack
u eip-80
如果資料視窗是開啟的狀態，可以輸入”wd”來關閉該視窗，然後再輸入 “dd esp-20”命令。stack 、dd esp-20是為了標註跟蹤資訊。
通過輸入"x"，退出 Soft-ICE的視窗；如果還是無法退出Soft-ICE，需要輸入faults off"，然後輸入"x"。
開啟Soft-ICE應用程式，立即儲存日誌檔案。一旦再次開啟Soft-ICE，請輸入"faults on"
2.2 分離和再現軟體缺陷
為了有效地再現軟體缺陷，除了按照軟體缺陷的有效描述規則來描述軟體缺陷，還要遵循軟體缺陷分離和再現的方法和具有較高的技巧性，雖然有時少數幾個缺陷很難再現、或者根本無法再現。以下就介紹如何分離和再現缺陷的一些常用方法和技巧。
- 確保所有的步驟都被記錄。
- 特定條件和時間。
- 壓力和負荷、記憶體和資料溢位相關的邊界條件。
- 考慮資源依賴性包括記憶體、網路和硬體共享的相互作用等。
- 不能忽視硬體。與軟體不同，硬體不按預定方式工作。
2.3 分離和除錯軟體缺陷之間的區別
討論分離和除錯軟體缺陷之間的區別，是為了劃清測試人員與開發人員的責任，增加界限的清晰度與測試資源的控制能力。面對一個軟體缺陷時，開發人員或測試人員為了修復它，會提出一系列分步驟地、處理缺陷的疑問：
- 再現軟體缺陷現象所需的最少步驟有哪些？這些步驟成功再現的可能性多大？
- 軟體缺陷是否成立存在？換句話說，測試結果是否可能起源於測試因素或者測試人員自身的錯誤，還是影響顧客需求的、系統真正的故障？
- 哪些外部因素產生軟體缺陷？
- 哪些內部因素，是程式碼、網路、還是環境引起的軟體缺陷？
- 怎樣才能在不產生新的缺陷的條件下使這個軟體缺陷得到修復？
- 這種修復是否經過除錯，單元是否經過測試？
- 問題解決了嗎？它是否通過了確認和迴歸測試，確定系統的其餘部分仍工作正常？
3.軟體缺陷的處理和跟蹤
3.1 軟體缺陷處理跟蹤 軟體缺陷跟蹤管理是測試工作的一個重要部分，測試的目的是為了儘早發現軟體系統中的缺陷，而對軟體缺陷進行跟蹤管理的目的是確保每個被發現的缺陷都能夠及時得到處理。軟體測試過程簡單說就是圍繞缺陷進行的，對缺陷的跟蹤管理，一般而言需要達到以下目標：- 確保每個被發現的缺陷都能夠被解決，“解決”的意思不一定是被修正，也可能是其他處理方式（例如，延遲到下一個版本中修正或者由於技術原因不能被修正），總之，對每個被發現的BUG的處理方式必須能夠在開發組織中達到一致；
- 收集缺陷資料並根據缺陷趨勢曲線識別測試處於測試過程中的哪個階段；
- 決定測試過程是否結束，通過缺陷趨勢曲線來確定測試過程是否結束是常用並且較為有效的一種方式。
- 收集缺陷資料並在其上進行資料分析，作為組織過程改進的財富。
3.2 簡單、優化的軟體缺陷生命週期
生命週期的概念是一個物種從誕生到消亡經歷了不同的生命階段，那麼軟體缺陷生命週期應該指的是一個軟體缺陷被發現、報告到這個缺陷被修復、驗證直至最後關閉的完整過程。在整個軟體缺陷生命週期中，通常是以改變軟體缺陷的狀態來體現不同的生命階段。因此，對於一個軟體測試人員來講，需要關注軟體缺陷在生命週期中的狀態的變化，來跟蹤專案進度和軟體質量。一個簡單、優化的軟體缺陷生命週期：
發現-開啟：測試人員找到軟體缺陷並將軟體缺陷提交給開發人員。
開啟-修復：開發人員再現、修復缺陷，然後提交給測試人員去驗證。
修復-關閉：測試人員驗證修復過的軟體，關閉已不存在的缺陷。
3.3 複雜的軟體缺陷生命週期
在實際工作中，軟體缺陷的生命週期不可能像如上那麼簡單，需要考慮其它各種情況，給出了一個複雜的軟體缺陷生命週期的例子，
如圖所示：
3.4 軟體缺陷生命週期綜述
綜上所述，軟體缺陷在生命週期中經歷了數次的審閱和狀態變化，最終測試人員關閉軟體缺陷來結束軟體缺陷的生命週期。軟體缺陷生命週期中的不同階段是測試人員、開發人員和管理人員一起參與、協同測試的過程。軟體缺陷一旦發現，便進入測試人員、開發人員、管理人員的嚴密監控之中，直至軟體缺陷生命週期終結，這樣即可保證在較短的時間內高效率地關閉所有的缺陷，縮短軟體測試的程序，提高軟體質量，同時減少開發、測試和維護成本。
3.5 軟體缺陷處理技巧
管理員、測試人員和開發人員需要掌握在軟體缺陷生命週期的不同階段處理軟體缺陷技巧，從而儘快處理軟體缺陷，縮短軟體缺陷生命週期。以下列出處理軟體缺陷基本技巧：
- 審閱。當測試人員在缺陷跟蹤資料庫中輸入了一個新的缺陷時，測試員應該提交它，以便在它能夠起作用之前進行審閱。這種審閱可以由測試管理員、專案管理員或其他人來進行，主要審閱缺陷報告的質量水平；
- 拒絕。如果審閱者決定需要對一份缺陷報告進行重大修改，例如需要新增更多的資訊或者需要改變缺陷的嚴重等級，應該和測試人員一起討論，由測試人員糾正缺陷報告，然後再次提交；
- 完善。如果測試員已經完整地描述了問題的特徵並將其分離，那麼審查者就會肯定這個報告；
- 分配。當開發組接受完整描述特徵並被分離的問題時，測試員會將它分配給適當的開發人員，如果不知道具體開發人員，應分配給專案開發組長，由開發組長再分配給對應的開發人員；
- 測試。一旦開發人員修復一個缺陷，它就將進入測試階段。缺陷的修復需要得到測試人員的驗證，同時還要進行迴歸測試，檢查這個缺陷的修復是否會引入新的問題；
- 重新開啟。如果這個修復沒有通過確認測試，那麼測試人員將重新開啟這個缺陷報告。重新開啟一個缺陷，需要加註釋說明，否則會引起“開啟-修復”多個來回，造成測試人員和開發人員不必要的矛盾
- 關閉。如果修復通過驗證測試，那麼測試人員將關閉這個缺陷。只有測試人員有關閉缺陷的許可權，開發人員沒有這個許可權。
- 暫緩。如果每個人都同意將確實存在的缺陷移到以後處理，應該指定下一個版本號或修改的日期。一旦新的版本開始時，這些暫緩的缺陷應該重新被開啟。
- 測試人員、開發人員和管理者只有緊密的合作，掌握軟體缺陷處理技巧，在專案不同階段，及時的審查、處理和跟蹤每個軟體缺陷，加速軟體缺陷狀態的變換，提高軟體質量，促進專案的發展。
3.6 軟體缺陷跟蹤系統
到目前為止所講述的一切表面上看起來很好，但是運用到實踐中還需要軟體缺陷跟蹤系統，以便描述報告所發現的缺陷，處理軟體缺陷屬性，跟蹤軟體缺陷的整個生命週期和生成軟體缺陷跟蹤圖表等。為什麼需要建立一套軟體缺陷跟蹤系統呢？因為它會讓我們受益無窮，概括起來有：
- 軟體缺陷跟蹤系統擁有軟體缺陷跟蹤資料庫，它不僅有利於軟體缺陷的清楚描述，還提供統一的、標準化報告，使所有人的理解一致；
- 缺陷跟蹤資料庫允許自動連續的軟體缺陷編號，還提供了大量供分析和統計的選項，這是手工方法無法實現的；
- 基於缺陷跟蹤資料庫，可快速生成滿足各種查詢條件的、所必要的缺陷報表、曲線圖等，開發小組乃至公司的每一個人都可以隨時掌握軟體產品質量的整體狀況、或測試/開發的進度；
- 缺陷跟蹤資料庫提供了軟體缺陷屬性並允許開發小組根據對專案的相對和絕對重要性來修復缺陷；
- 可以在軟體缺陷的生命期中管理缺陷，從最初的報告到最後的解決。確保了每一個缺陷不會被忽略，同時，它還可以使注意力保持在那些必須儘快修復的重要缺陷上；
- 當缺陷在它的生命週期中變化時，開發人員，測試人員以及管理人員將熟悉新的軟體缺陷資訊。一個設計良好的軟體缺陷跟蹤系統可以獲取歷史記錄，並在檢查缺陷的狀態時參考歷史記錄；
- 在軟體缺陷跟蹤資料庫中關閉每一份缺陷報告，它都可以被記錄下來。當產品送出去時，每一份未關閉的缺陷報告都提供了預先警告的有效技術支援，並且證明測試人員找到特殊領域突然出現的事件中的軟體缺陷。
任何一個缺陷跟蹤系統的核心都是“軟體缺陷報告”，一份軟體缺陷報告詳細資訊如表：
軟體缺陷專案列表
3.8 軟體缺陷的詳細描述
軟體缺陷的詳細描述，如上所述，由三部分組成：操作/重現步驟、期望結果、實際結果，有必要再做進一步的討論：
- “步驟”提供瞭如何重複當前缺陷的準確描述，應簡明而完備、清楚而準確。這些資訊對開發人員是關鍵的，視為修復缺陷的嚮導，開發人員有時抱怨糟糕的缺陷報告，往往集中在這裡；
- “期望結果”與測試用例標準或設計規格說明書或使用者需求等一致，達到軟體預期的功能。測試人員站在使用者的角度要對它進行描述，它提供了驗證缺陷的依據。
- “實際結果”測試人員收集的結果和資訊，以確認缺陷確實是一個問題，並標識那些影響到缺陷表現的要素。
3.9 缺陷報告的示例
一份優秀的缺陷報告記錄下最少的重複步驟，不僅包括了期望結果，實際結果和必要的附件，還提供必要的資料、測試環境或條件，以及簡單的分析。
而一份含糊而不完整的缺陷報告，缺少重建步驟，並且沒有期望結果、實際結果和必要的圖片，如下描述。
一份散漫的缺陷報告（無關的重建步驟，以及對開發人員理解這個錯誤毫無幫助的結果資訊）如下描述：
4.0 缺陷跟蹤資料庫資訊
專案中使用Microsoft Excel 電子表格或Word 文件來記錄和跟蹤軟體缺陷，但一般只限於最後的分析報告、文件的列印。為了靈活地儲存、操作、搜尋、分析以及報告大量資料，我們需要建一個數據庫。
基於已經討論過的內容，就比較容易建立一個軟體缺陷跟蹤資料庫，可以使用Microsoft Access或SQL server，也可以使用Oracle、DB2 等關係資料庫管理系統。一個缺陷跟蹤資料庫的基本表，將要包括多達幾十項的資料項，如bug的ID號、標題(Title)、狀態、嚴重程度、優先順序、重現步驟、期望結果、實際結果、專案名稱、模組、報告作者、日期等等。
所有缺陷的資料不僅要儲存在共享資料庫中，還要有相關的資料連線，如產品特性資料庫、產品配置資料庫、測試用例資料庫等的整合。因為某個缺陷是和某個產品特性、某個軟體版本、某個測試用例等相關聯的，有必要建立起這些關聯。同時為了提高缺陷處理的效率，還有和郵件伺服器整合，通過郵件傳遞，測試和開發人員隨時可以獲得由系統自動發出有關缺陷狀態變化的郵件。
4.1 軟體缺陷為何發生：根本原因圖表
分析軟體缺陷根本原因不僅有助於測試人員決定哪些功能領域需要增強測試，而且可以使開發人員的注意力集中到那些引起最嚴重，最頻繁的領域。如下圖顯示了軟體缺陷產生的3個主要來源區域——使用者介面顯示，邏輯和規格說明書——佔據發現軟體缺陷總數的75%。如果從測試風險角度看，這些區域可能是隱藏缺陷比較多的地方，需要測試更細、更深些。從開發角度來說，這些是程式碼質量提高的主要區域，假定某個產品前後發現10000個Bug，程式碼在這三個區域減少10個百分點，則總Bug數能減少750(7.5%)，程式碼質量改善效果就很顯著。
