缺陷漏测分析：测试过程改进
一、漏測的定義
所謂漏測，是指軟件產品的缺陷沒有被測試組發現而遺漏到了用戶那里，卻最終被用戶所發現。如果產品在用戶那里出現問題，產生的后果是非常嚴重的。在軟件開發過程中，缺陷越早被發現，發現和解決缺陷所花的成本就越小。如果缺陷是在測試組測試中發現的而不是被用戶使用時發現的，那么所花的成本將小得多。如果缺陷是被開發組在開發過程中發現的，那么所花的代價將更小。因此，進行漏測分析、預防漏測、促使缺陷盡可能在開發過程的早期被發現，是非常有意義的，它有利于降低軟件產品成本、提高軟件產品質量。
二、漏測分析的目的
進行漏測分析的目的是為了促進軟件質量和開發測試過程得到持續改進。具體來講，就是通過分析開發和測試過程中漏測的缺陷，制定相應的預防措施以避免今后再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到用戶處的缺陷數和缺陷解決成本，從而提升軟件的質量、聲譽和銷售。在軟件產品開發過程中重視漏測分析并參與到漏測分析工作中的團隊越多，漏測分析的效果就越好。如果開發和測試團隊都重視漏測分析、并密切配合進行漏測分析工作的話，漏測分析將取得非常好的效果。
在實際工作中，漏測分析過程應該重點關注那些普遍、嚴重而解決成本高的問題。具體來講，漏測分析的目標是：
● 對漏測進行分類以便于更進一步深入的分析
● 對分類數據進行統計
● 在統計分析的基礎上進行全過程的標識和變更
● 在對一些特殊的漏測項進行分析的基礎上，對過程的一些局部進行標識和變更
● 運用度量數據說明過程變更的效果
三、如何進行漏測分析
漏測分析活動可以參照下面的建議進行。在熟悉了漏測分析流程以后，需要確定進行漏測分析活動的頻度。為了取得較好的效果，最好是遵照一個時間表來定期進行漏測分析活動，一個月進行一次是一個比較合適的頻度。
◆ 計劃
這個過程是針對多項目組聯合進行漏測分析而設置的，在聯合項目組中實行該過程最有效。如果不可能組建聯合項目組進行漏測分析，也可以修改該過程只在測試組內部實行。
制訂計劃如果不確定關注點的話，這個計劃將難以有效實施。漏測分析要想取得理想的效果，就需要計劃好進行漏測分析活動的確切的人員數目、活動時間。 過程執行的效果完全取決于執行它的方式，如果不切切實實的做好計劃，你的過程將不會得到太多的改進。
實際進行漏測分析活動時，只選擇漏測分類的一部分子集進行分析，將有利于更有效的進行漏測分析工作。進行漏測分類前，需要在計劃中確定選擇哪部分子集進行分析。例如，如果漏測的嚴重度等級分為一到四級，一級嚴重度最高，四級嚴重度最低，那么也許只分析一、二級的漏測最合適，這樣可以避免在那些對用戶無關緊要的漏測缺陷上花太多的無用功;也可以只分析那些被關閉和修復了的漏測缺陷，因為如果分析那些沒有被關閉和修復的缺陷，可能會漏掉一些至關重要的信息;另外，還可以在進行漏測分析之前排除掉重復缺陷和那些由于用戶錯誤操作引起的缺陷，這樣就只需要分析那些有效的漏測缺陷，它們才能真正提供開發和測試過程需要改進的信息。
◆ 漏測分類
接下來需要將所有的漏測缺陷按照有意義的屬性進行分類，當然，前提條件是已經有了一個包含了所有漏測缺陷詳細信息的漏測列表。然后需要確定哪些屬性分類是對分析有用的。下面給出一些漏測缺陷的屬性的例子：
● 漏測產生活動（最有可能發現該漏測缺陷的活動）
● 開發階段（原始需求評審、概念評審、設計評審、代碼檢視、單元測試、模塊聯調、信息資料開發）
● 測試階段（功能測試、系統測試、本地語言測試、設備驅動測試、安裝測試、性能測試、異常測試）
● 產品模塊（產生了漏測缺陷的代碼模塊）
● 模塊 A 、 B 、 C 等
● 缺陷影響（對用戶使用造成的影響）
● 系統崩潰、業務中止、數據完整性、命令失效、安裝失敗、設備 / 驅動、性能、文檔、可用性等
● 引入版本（引入漏測缺陷的代碼版本）
● 平臺
● 嚴重級別
● 發現漏測的版本
漏測產生活動是指在軟件開發測試過程中，某類被漏測的缺陷最應該在該活動中被發現。設置該項分類的目的是為了便于對產生了漏測的活動進行更進一步的細化分析。
產品模塊是指被漏測的缺陷所在的代碼模塊。
缺陷影響是指漏測缺陷給用戶使用時所帶來問題的類型。
引入版本是漏測缺陷被引入時的代碼版本，它應該是代碼第一次引入該缺陷的版本。
平臺是指產生漏測的平臺或操作系統。
嚴重級別是指缺陷的嚴重程度度量，例如：致命、嚴重、一般、提示。如果你的缺陷跟蹤過程還沒有包含缺陷的這個屬性，那么漏測分析過程應該明確地給出每個缺陷的嚴重級別。
發現漏測的版本是指該漏測初次被發現并被報告時的軟件版本。
進行漏測分類活動時，最好將開發、測試、技術支持以及其他所有產品生命周期中相關部門的代表組織到一起對近期的漏測進行討論，特別是技術支持人員能夠提供很多非常詳細的關于漏測缺陷的信息，這對漏測分類非常有幫助。
在項目組進行實際漏測分析活動時，也許不需要按照上面建議的一些屬性進行分類，而需要采用其他一些分類標準，這時最好在項目組內集體討論來決定哪些分類是最適用的。
在漏測缺陷分類活動結束后，需要對分類結果數據進行統計分析。例如，每個漏測缺陷對應了一個漏測產生的活動，這時可以考慮對該活動進行進一步的改進。
◆ 分析活動：跟蹤工具
進行漏測分析時如果沒有缺陷跟蹤工具的支持是很困難的。應該采用工具來維護所有不同分類的漏測缺陷數據。 Lotus Notes 數據庫就是一個不錯的工具，它能很方便地將數據按各種不同的方式進行分割，這樣你能夠對同樣一批數據創建各種視圖，從而能夠從各個角度進行統計分析。
◆ 分析活動：統計
統計分析是為了指導全流程過程改進。進行統計分析首先要確定進行統計分析的頻度，一般一個季度進行一次統計分析比較合適。進行統計分析時，需要將某個分類的各分類項的數據一一和該分類的所有其它分類項數據進行比較，并且對所有的分類都要進行這樣的操作。對那些相對總數比較大的分類項還要進行更進一步細分，進行更進一步的統計分析工作。
◆ 分析活動：全流程過程改進
進行統計分析的時候，漏測分析小組需要集合在一起，對統計分析結果進行討論。基于統計分析結果可以得到各種趨勢圖，分析小組可以討論全開發流程中需要改進的意見和方案，然后對那些需要改進的地方作出正式的改進建議，制定改進實施計劃，并在隨后的會議上，漏測分析小組對變更實施過程進行討論。可以通過漏測分析數據庫或者其他工具進行任務分配和跟蹤。這里可以給出兩個根據缺陷分析進行全流程改進的例子：第一個例子，如果在系統在故障處理時發現了很多的漏測缺陷，那么進行開發過程全流程改進時，可以考慮增加異常測試組，加強異常測試；第二個例子，如果用戶在某硬件平臺上使用軟件的過程中發現了大量缺陷而測試組卻沒有該硬件平臺，這時需要考慮改進硬件獲取過程，增加測試的硬件平臺。全流程改進會給軟件企業帶來巨大的影響，所以一定要取得管理層的支持和同意。
◆ 分析活動：局部過程改進
在聯合項目組進行漏測分析時，對每個產生了漏測的活動都要選出代表（如：開發活動代表、測試活動代表、文檔寫作代表等等）。例如：針對 “ 漏測產生活動 ” 屬性進行分類時，如果某漏測缺陷被分類到 “ 單元測試 ” ，那么該漏測缺陷應該由開發活動代表對其進行進一步的局部過程分析。所有這些缺陷都列在漏測分析數據庫里，每個分類活動的代表應該列出歸屬該活動的所有漏測缺陷列表，然后提出這些活動的局部改進計劃。舉例來說，測試活動代表應該列出所有 “ 漏測產生活動 ” 為 “ 測試 ” 的漏測缺陷，并進行細分，然后將他們分配給測試工程師進行分析；測試工程師將針對所分配的漏測缺陷進行詳細分析，找出漏測的原因，然后提出有針對性的改進計劃來防止同類缺陷再次被漏測。這些改進計劃應該在審核通過后實施，并且整個改進過程應該在數據庫中進行跟蹤，每個改進計劃都應該能和單個缺陷漏測分析結果相對應，測試代表應該推動各改進計劃的完成、審核和實施。這里要特別強調的是，這些改進計劃不是用來修復缺陷的，因為這些被分析的漏測缺陷應該已經被修復好了，這些改進計劃僅僅是在基于某個缺陷漏測原因分析的基礎上重新確定測試過程（或開發過程等），它關心的是如何防止該類問題將來再次發生，而不是關心該特定的缺陷在將來是否會再出現（因為它已經被修復了）。例如，局部過程改進計劃可以是補充以前沒有考慮到的用例，也可以是在測試環境中增加特定的硬件使得測試環境更接近于用戶使用環境。在考慮改進計劃的時候應該鼓勵創造性。
◆ 度量
漏測分析過程的最后一步是對改進過程的階段性實施效果進行測量。本文后面部分將對此進行更詳細的論述。
● 漏測分析舉例
圖 -1
* APAR 是描述缺陷屬性的一個術語。
圖 -1 以一個虛擬產品的 Lotus Notes 漏測缺陷數據庫作為示例。在本例中，對一個漏測缺陷采用三個標簽項來跟蹤其特征數據。第一個標簽項用于描述缺陷的詳細數據，這些數據來自于缺陷跟蹤工具，它們從缺陷跟蹤工具到漏測分析工具的輸入和轉換最好是自動完成。此外，還有一個較大的屬性域用來描述缺陷的歷史和概要，本圖中沒有顯示出來該域。
圖 -2
圖 -2 演示的是 “ 開發分析 ” 標簽項。針對開發過程，可以對漏測缺陷進行各種不同的分類。在本例中所示例的漏測缺陷被歸類為 “ 設計評審過程 ” 遺漏。這個例子演示了對產品的開發過程變更創建 “ 概念評審 ” 的過程。 “ 捕獲概率 ” 項用來評估變更實施后可能產生的效果，它能回答 “ 如果在開發過程中已經實施了該變更計劃，這個缺陷被捕獲到的可能性有多大？ ” ，對此本文將在后面的 “ 測量 ” 小節進行詳細探討。這個表格還設計了變更計劃制訂的預期日期項和實施該變更計劃的預期日期項， Lotus Notes 系統會在該日期自動發送提示信息給變更計劃的受理者。
圖 -3
圖 -3 演示的是 “ 測試分析 ” 標簽項。在這里可以分析用戶報告的缺陷是否真的是漏測，換句話說，確定測試過程中是否真的存在漏洞或者該缺陷是否真的值得解決。這是非常重要的。有一些用戶發現問題的環境是非常特殊的或生僻的，還有些缺陷解決起來代價很大，并且很難被發現，漏測分析組需要確定是否有必要針對該漏測缺陷進行測試過程改進。如果發現問題的用戶是非常重要的客戶，并且該用戶會經常使用該環境，那么即使發現問題的環境非常特殊，也需要改進測試環境，來盡量符合用戶的使用環境。在上面的例子中，缺陷被歸類到 “ 未執行的測試類型 ” ，該測試類型發生了漏測。在對數百個漏測缺陷進行統計分析后，如果發現 “ 未執行的測試類型 ” 比例很高，那么可能需要在整個開發過程中增加該類測試類型。這里 “ 捕獲概率 ” 項和上面小節描述的含義一樣。
◆ 測量
本節將給出關于測量的一些建議。首先，對于需要改進點，將給出能指導漏測分析組制訂合適的改進計劃的測量點；接下來，將給出一些評價漏測分析過程效果的方法。您可以采用其中部分或全部建議來建立自己的測量體系。
1、測量驅動改進
將前面各分類數據和總數比較，得到各分類的比例。下面是一些例子：
圖 -4 顯示的是各代碼模塊（模塊 A - Z ）漏測數占總的漏測數的比例。從該餅圖上可以清楚地看出超過 50 %的漏測來自于 B 、 C 、 D 、 E 四個模塊，這個測量結果可以幫助漏測分析組決定是否對這四個模塊的開發過程實施改進。
圖 -4
圖 -5
圖 -5 分析了漏測缺陷對用戶造成的不同影響，如業務中斷、系統崩潰、或設備相關問題等。例如，如果 “ 影響 1” 是設備相關問題，那么被測軟件所在的硬件平臺可能需要進行改進；同樣，如果藍色部分是高嚴重等級的影響類型，那么可以看出漏測是高嚴重等級影響類型的具體比例是多少。
通過前面示例的數據庫工具，還可以輸出大量其他圖表，上面所舉的兩個例子只是最常用的兩種分析圖。
2、評價漏測分析效果
評價改進的效果需要有精確的數據和一致的分析報告，以下幾個數據會被用到：
TFVUD 是用戶發現缺陷數（Total Field Valid Unique Defects），即由用戶發現的經過了確認的、非重復的、非用戶錯誤操作的、非建議類型的所有缺陷；
PDD 是測試發現缺陷數（Post Development Defects），即在開發完成后的測試周期中發現的缺陷數，但它不包括那些向用戶發布后發現的缺陷；
KLOC 表示千行代碼。
利用上面數據可以得到以下分析數據：
● TFVUD
-------------------
千行變更代碼 & 新代碼
應當在產品全生命周期中測量上面的值，用作一個版本和另一個版本在相同時間檢查點上進行比較的評價指標。例如，一個季度中， 2.0 版本的該測量值應該比 1.0 版本低。進行該項測量的目的是減少單位代碼規模中用戶發現的的有效問題數。
● PDD
-------------------
PDD+TFVUD
在產品全生命周期中同樣應當測量上面的值，作為一個版本和另一個版本在相同時間檢查點上進行比較的評價指標。例如，一個季度中， 2.0 版本的該測量值應該比 1.0 版本高。進行該項測量的目的是推動盡早地在開發過程中發現缺陷，從而降低缺陷的修復成本。
◆ 捕獲概率
在數據庫中有 “ 捕獲概率 ” 的屬性項（在前面小節進行了詳細解釋），這是對實施過程變更后防止同類問題再次漏測的效果的一項估計指標。該估計是計劃預期效果的基礎。通過對各變更的捕獲概率取總后求平均，可以得到過程變更后的整體預期效果，這樣就能對產品發布后用戶問題數的降低程度進行合理的預期。
圖 -6
上圖中，模塊 B 的開發過程的捕獲概率為 35 %，測試過程的捕獲概率為 30 %。如果開發過程在代碼里產生了 100 個缺陷，那么根據捕獲概率在開發階段可能會發現 35 個缺陷，還有 65 個缺陷可能會遺漏到測試階段，根據測試過程 30 %的捕獲概率，在測試階段將可能發現 65*30 %= 19.5 個缺陷，那么開發測試階段總共大概能發現 55 個缺陷。這 55 %的概率就是開發測試過程變更后的綜合效果估計。用方程式表示上面的過程就是（ .35 ） +（1-.35）（.30） 或者 D+（1-D）（T） ，這里 D 是開發過程的捕獲概率， T 是測試過程捕獲概率。本圖是基于代碼模塊的例子，其他分類也可以進行同樣的評估工作，如下面圖 7 。
圖 -7
最后一步是通過對所有綜合捕獲概率取總后求平均，來預計有效用戶缺陷數的減少。首先，選擇一組和預期效果相關的重點漏測組。在本例中，假設重點漏測組包含 76 個漏測缺陷，如果針對這 76 個缺陷的綜合捕獲概率為 52.5% ，那么將能預防約 40 個缺陷漏測。假設一年的時間里會有 250 個漏測缺陷，前面 52.5% 的捕獲概率是一個比較準的數據，那么將能預防 250 個漏測的 16 % ―― 約 40 個漏測缺陷，這是對下個版本將會減少的漏測數的最終預測，并且這是最小預測，因為我們只是對重點漏測組進行了預測，這對其他類型的問題可能不適用。如果我們沒有作那樣的假設，那么預測的漏測數的降低可能是不現實的 52.5% 。
四、總結
進行漏測缺陷分析的主要目的就是提高產品質量和用戶滿意度、降低修復用戶發現缺陷的成本。這是通過推動盡可能在軟件開發過程的早期發現缺陷來實現的。進行漏測分析活動的軟件測試組將會幫助軟件開發組改進質量，他們的測試過程將更加完善，測試環境也將更加符合用戶實際環境。從漏測分析過程中收集的數據能為測試環境補充硬件等改進活動提供充分的理由。此外，漏測分析過程鼓勵項目組間的交流和合作，開發更高質量的軟件產品。它還能預測未來的漏測缺陷數，評價自身的效果，來證明所投入的資源是值得的。
轉載于:https://www.cnblogs.com/zhangyublogs/p/4991225.html
總結
以上是生活随笔為你收集整理的缺陷漏测分析：测试过程改进的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： PowerDesign的简单使用方法
- 下一篇： 深入剖析.NET运行机制