缺陷漏測分析：測試流程改善

2005.12.19  來自：51testin

漏測的定義

　　所謂漏測，是指軟體產品的缺陷沒有被測試組發現而遺漏到了使用者那裡，卻最終被使用者所發現。如果產品在使用者那裡出現問題，產生的後果是非常嚴重的。在軟體開發過程中，缺陷越早被發現，發現和解決缺陷所花的成本就越小。如果缺陷是在測試組測試中發現的而不是被使用者使用時發現的，那麼所花的成本將小得多。如果缺陷是被開發組在開發過程中發現的，那麼所花的代價將更小。因此，進行漏測分析、預防漏測、促使缺陷儘可能在開發過程的早期被發現，是非常有意義的，它有利於降低軟體產品成本、提高軟體產品品質。

漏測分析的目的

　　進行漏測分析的目的是為了促進軟體品質和開發測試過程得到持續改進。具體來講，就是通過分析開發與測試過程中漏測的缺陷，制定相應的預防措施以避免今後再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到使用者處的缺陷數和缺陷解決成本，從而提升軟體的品質、聲譽和銷售。在軟體產品開發過程中重視漏測分析並參與到漏測分析工作中的團隊越多，漏測分析的效果就越好。如果開發與測試團隊都重視漏測分析、並密切配合進行漏測分析工作的話，漏測分析將取得非常好的效果。

　　在實際工作中，漏測分析過程應該重點關注那些普遍、嚴重而解決成本高的問題。具體來講，漏測分析的目標是：

• 對漏測進行分類以便於更進一步深入的分析
• 對分類資料進行統計
• 在統計分析的基礎上進行全過程的標識和變更
• 在對一些特殊的漏測項進行分析的基礎上，對過程的一些局部進行標識和變更
• 用度量資料說明過程變更的效果
• 何進行漏測分析

　　漏測分析活動可以參照下面的建議進行。在熟悉了漏測分析流程以後，需要確定進行漏測分析活動的頻度。為了取得較好的效果，最好是遵照一個時間表來定期進行漏測分析活動，一個月進行一次是一個比較合適的頻度。

•  計劃

　　這個過程是針對多項目組聯合進行漏測分析而設定的，在聯合項目組中實行該過程最有效。如果不可能組建聯合項目組進行漏測分析，也可以修改該過程只在測試組內部實行。

　　制訂計劃如果不確定關注點的話，這個計劃將難以有效實施。漏測分析要想取得理想的效果，就需要計劃好進行漏測分析活動的確切的人員數目、啟用時間。 過程執行的效果完全取決於執行它的方式，如果不切切實實的做好計劃，你的過程將不會得到太多的改進。

　　實際進行漏測分析活動時，只選擇漏測分類的一部分子集進行分析，將有利於更有效進行漏測分析工作。進行漏測分類前，需要在計劃中確定選擇哪部分子集進行分析。例如，如果漏測的嚴重度等級分為一到四級，一級嚴重度最高，四級嚴重度最低，那麼也許只分析一、二級的漏測最合適，這樣可以避免在那些對使用者無關緊要的漏測缺陷上花太多的無用功；也可以只分析那些被關閉和修複了的漏測缺陷，因為如果分析那些沒有被關閉和修複的缺陷，可能會漏掉一些至關重要的資訊；另外，還可以在進行漏測分析之前排除掉重複缺陷和那些由於使用者錯誤操作引起的缺陷，這樣就只需要分析那些有效漏測缺陷，它們才能真正提供開發與測試過程需要改進的資訊。

漏測分類

　　接下來需要將所有的漏測缺陷按照有意義的屬性進行分類，當然，前提條件是已經有了一個包含了所有漏測缺陷詳細資料的漏測列表。然後需要確定哪些屬性分類是對分析有用的。下面給出一些漏測缺陷的屬性的例子：

•  漏測產生活動（最有可能發現該漏測缺陷的活動）
•  開發階段（原始需求評審、概念評審、設計評審、代碼檢視、單元測試、模組聯調、資訊資料開發）
•  測試階段（功能測試、系統測試、本地語言測試、裝置驅動測試、安裝測試、效能測試、異常測試）
•  產品模組（產生了漏測缺陷的代碼模組）
•  模組 A 、 B 、 C 等
•  缺陷影響（對使用者使用造成的影響）
•  系統崩潰、業務中止、資料完整性、命令失效、安裝失敗、裝置 / 驅動、效能、文檔、可用性等
•  引入版本（引入漏測缺陷的代碼版本）
•  平台
•  嚴重層級
•  發現漏測的版本

　　漏測產生活動是指在軟體開發測試過程中，某類被漏測的缺陷最應該在該活動中被發現。設定該項分類的目的是為了便於對產生了漏測的活動進行更進一步的細化分析。

　　產品模組是指被漏測的缺陷所在的代碼模組。

　　缺陷影響是指漏測缺陷給使用者使用時所帶來問題的類型。

　　引入版本是漏測缺陷被引入時的代碼版本，它應該是代碼第一次引入該缺陷的版本。

　　平台是指產生漏測的平台或作業系統。

　　嚴重層級是指缺陷的嚴重程度度量，例如：致命、嚴重、一般、提示。如果你的缺陷跟蹤過程還沒有包含缺陷的這個屬性，那麼漏測分析過程應該明確地給出每個缺陷的嚴重層級。

　　發現漏測的版本是指該漏測初次被發現並被報告時的軟體版本。

　　進行漏測分類活動時，最好將開發、測試、支援人員以及其他所有產品生命週期中相關部門的代表組織到一起對近期的漏測進行討論，特別是技術支援人員能夠提供很多非常詳細的關於漏測缺陷的資訊，這對漏測分類非常有協助。

　　在項目組進行實際漏測分析活動時，也許不需要按照上面建議的一些屬性進行分類，而需要採用其他一些分類標準，這時最好在項目組內集體討論來決定哪些分類是最適用的。

　　在漏測缺陷分類活動結束後，需要對分類結果資料進行統計分析。例如，每個漏測缺陷對應了一個漏測產生的活動，這時可以考慮對該活動進行進一步的改進。

 分析活動：跟蹤工具

　　進行漏測分析時如果沒有缺陷跟蹤工具的支援是很困難的。應該採用工具來維護所有不同分類的漏測缺陷資料。 Lotus Notes 資料庫就是一個不錯的工具，它能很方便地將資料按各種不同的方式進行分割，這樣你能夠對同樣一批資料建立各種視圖，從而能夠從各個角度進行統計分析。

分析活動：統計

　　統計分析是為了指導全流程流程改善。進行統計分析首先要確定進行統計分析的頻度，一般一個季度進行一次統計分析比較合適。進行統計分析時，需要將某個分類的各分類項的資料一一和該分類的所有其它分類項資料進行比較，並且對所有的分類都要進行這樣的操作。對那些相對總數比較大的分類項還要進行更進一步細分，進行更進一步的統計分析工作。

分析活動：全流程流程改善

　　進行統計分析的時候，漏測分析小組需要集合在一起，對統計分析結果進行討論。基於統計分析結果可以得到各種趨勢圖，分析小組可以討論全開發流程中需要改進的意見和方案，然後對那些需要改進的地方作出正式的改進建議，制定改進實施計劃，並在隨後的會議上，漏測分析小組對變更實施過程進行討論。可以通過漏測分析資料庫或者其他工具進行任務分配和跟蹤。這裡可以給出兩個根據缺陷分析進行全流程改進的例子：第一個例子，如果在系統在故障處理時發現了很多的漏測缺陷，那麼進行開發過程全流程改進時，可以考慮增加異常測試組，加強異常測試；第二個例子，如果使用者在某硬體平台上使用軟體的過程中發現了大量缺陷而測試組卻沒有該硬體平台，這時需要考慮改進硬體擷取過程，增加測試的硬體平台。全流程改進會給軟體企業帶來巨大的影響，所以一定要取得管理層的支援和同意。

分析活動：局部流程改善

　　在聯合項目組進行漏測分析時，對每個產生了漏測的活動都要選出代表（如：開發活動代表、測試活動代表、文檔寫作代表等等）。例如：針對 “ 漏測產生活動 ” 屬性進行分類時，如果某漏測缺陷被分類到 “ 單元測試 ” ，那麼該漏測缺陷應該由開發活動代表對其進行進一步的局部過程分析。所有這些缺陷都列在漏測分析資料庫裡，每個分類活動的代表應該列出歸屬該活動的所有漏測缺陷列表，然後提出這些活動的局部改進計劃。舉例來說，測試活動代表應該列出所有 “ 漏測產生活動 ” 為 “ 測試 ” 的漏測缺陷，並進行細分，然後將他們分配給測試工程師進行分析；測試工程師將針對所分配的漏測缺陷進行詳細分析，找出漏測的原因，然後提出有針對性的改進計劃來防止同類缺陷再次被漏測。這些改進計劃應該在審核通過後實施，並且整個改進過程應該在資料庫中進行跟蹤，每個改進計劃都應該能和單個缺陷漏測分析結果相對應，測試代表應該推動各改進計劃的完成、審核和實施。這裡要特彆強調的是，這些改進計劃不是用來修複缺陷的，因為這些被分析的漏測缺陷應該已經被修複好了，這些改進計劃僅僅是在基於某個缺陷漏測原因分析的基礎上重新確定測試過程（或開發過程等），它關心的是如何防止該類問題將來再次發生，而不是關心該特定的缺陷在將來是否會再出現（因為它已經被修複了）。例如，局部流程改善計劃可以是補充以前沒有考慮到的用例，也可以是在測試環境中增加特定的硬體使得測試環境更接近於使用者使用環境。在考慮改進計劃的時候應該鼓勵創造性。

? 度量

　　漏測分析過程的最後一步是對改進過程的階段性實施效果進行測量。本文後面部分將對此進行更詳細的論述。