測試過程改進的缺陷漏測分析(1)

2019-11-17 04:47:08

字體：大中小

來源：轉載

供稿：網友

1 漏測的定義 所謂漏測，是指軟件產品的缺陷沒有被測試組發現而遺漏到了用戶那里，卻最終被用戶所發現。假如產品在用戶那里出現問題，產生的后果是非常嚴重的。在軟件開發過程中，缺陷越早被發現，發現和解決缺陷所花的成本就越小。假如缺陷是在測試組測試中發現的而不是被用戶使用時發現的，那么所花的成本將小得多。假如缺陷是被開發組在開發過程中發現的，那么所花的代價將更小。因此，進行漏測分析、預防漏測、促使缺陷盡可能在開發過程的早期被發現，是非常有意義的，它有利于降低軟件產品成本、提高軟件產品質量。2 漏測分析的目的進行漏測分析的目的是為了促進軟件質量和開發測試過程得到持續改進。具體來講，就是通過分析開發和測試過程中漏測的缺陷，制定相應的預防措施以避免今后再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到用戶處的缺陷數和缺陷解決成本，從而提升軟件的質量、聲譽和銷售。在軟件產品開發過程中重視漏測分析并參與到漏測分析工作中的團隊越多，漏測分析的效果就越好。假如開發和測試團隊都重視漏測分析、并密切配合進行漏測分析工作的話，漏測分析將取得非常好的效果。在實際工作中，漏測分析過程應該重點關注那些普遍、嚴重而解決成本高的問題。具體來講，漏測分析的目標是：1）對漏測進行分類以便于更進一步深入的分析2）對分類數據進行統計3）在統計分析的基礎上進行全過程的標識和變更4）在對一些非凡的漏測項進行分析的基礎上，對過程的一些局部進行標識和變更5）運用度量數據說明過程變更的效果6）如何進行漏測分析漏測分析活動可以參照下面的建議進行。在熟悉了漏測分析流程以后，需要確定進行漏測分析活動的頻度。為了取得較好的效果，最好是遵照一個時間表來定期進行漏測分析活動，一個月進行一次是一個比較合適的頻度。3 計劃這個過程是針對多項目組聯合進行漏測分析而設置的，在聯合項目組中實行該過程最有效。假如不可能組建聯合項目組進行漏測分析，也可以修改該過程只在測試組內部實行。制訂計劃假如不確定關注點的話，這個計劃將難以有效實施。漏測分析要想取得理想的效果，就需要計劃好進行漏測分析活動的確切的人員數目、活動時間。過程執行的效果完全取決于執行它的方式，假如不切切實實的做好計劃，你的過程將不會得到太多的改進。實際進行漏測分析活動時，只選擇漏測分類的一部分子集進行分析，將有利于更有效的進行漏測分析工作。進行漏測分類前，需要在計劃中確定選擇哪部分子集進行分析。例如，假如漏測的嚴重度等級分為一到四級，一級嚴重度最高，四級嚴重度最低，那么也許只分析一、二級的漏測最合適，這樣可以避免在那些對用戶無關緊要的漏測缺陷上花太多的無用功；也可以只分析那些被關閉和修復了的漏測缺陷，因為假如分析那些沒有被關閉和修復的缺陷，可能會漏掉一些至關重要的信息；另外，還可以在進行漏測分析之前排除掉重復缺陷和那些由于用戶錯誤操作引起的缺陷，這樣就只需要分析那些有效的漏測缺陷，它們才能真正提供開發和測試過程需要改進的信息。4 漏測分類接下來需要將所有的漏測缺陷按照有意義的屬性進行分類，當然，前提條件是已經有了一個包含了所有漏測缺陷具體信息的漏測列表。然后需要確定哪些屬性分類是對分析有用的。下面給出一些漏測缺陷的屬性的例子：漏測產生活動（最有可能發現該漏測缺陷的活動）開發階段（原始需求評審、概念評審、設計評審、代碼檢視、單元測試、模塊聯調、信息資料開發）測試階段（功能測試、系統測試、本地語言測試、設備驅動測試、安裝測試、性能測試、異常測試）產品模塊（產生了漏測缺陷的代碼模塊）模塊 A 、 B 、 C 等缺陷影響（對用戶使用造成的影響）系統崩潰、業務中止、數據完整性、命令失效、安裝失敗、設備 / 驅動、性能、文檔、可用性等引入版本（引入漏測缺陷的代碼版本）平臺嚴重級別發現漏測的版本漏測產生活動是指在軟件開發測試過程中，某類被漏測的缺陷最應該在該活動中被發現。設置該項分類的目的是為了便于對產生了漏測的活動進行更進一步的細化分析。產品模塊是指被漏測的缺陷所在的代碼模塊。缺陷影響是指漏測缺陷給用戶使用時所帶來問題的類型。引入版本是漏測缺陷被引入時的代碼版本，它應該是代碼第一次引入該缺陷的版本。平臺是指產生漏測的平臺或操作系統。嚴重級別是指缺陷的嚴重程度度量，例如：致命、嚴重、一般、提示。假如你的缺陷跟蹤過程還沒有包含缺陷的這個屬性，那么漏測分析過程應該明確地給出每個缺陷的嚴重級別。發現漏測的版本是指該漏測初次被發現并被報告時的軟件版本。進行漏測分類活動時，最好將開發、測試、技術支持以及其他所有產品生命周期中相關部門的代表組織到一起對近期的漏測進行討論，非凡是技術支持人員能夠提供很多非常具體的關于漏測缺陷的信息，這對漏測分類非常有幫助。在項目組進行實際漏測分析活動時，也許不需要按照上面建議的一些屬性進行分類，而需要采用其他一些分類標準，這時最好在項目組內集體討論來決定哪些分類是最適用的。在漏測缺陷分類活動結束后，需要對分類結果數據進行統計分析。例如，每個漏測缺陷對應了一個漏測產生的活動，這時可以考慮對該活動進行進一步的改進。5 分析活動：跟蹤工具進行漏測分析時假如沒有缺陷跟蹤工具的支持是很困難的。應該采用工具來維護所有不同分類的漏測缺陷數據。 Lotus Notes 數據庫就是一個不錯的工具，它能很方便地將數據按各種不同的方式進行分割，這樣你能夠對同樣一批數據創建各種視圖，從而能夠從各個角度進行統計分析。
6 分析活動：統計統計分析是為了指導全流程過程改進。進行統計分析首先要確定進行統計分析的頻度，一般一個季度進行一次統計分析比較合適。進行統計分析時，需要將某個分類的各分類項的數據一一和該分類的所有其它分類項數據進行比較，并且對所有的分類都要進行這樣的操作。對那些相對總數比較大的分類項還要進行更進一步細分，進行更進一步的統計分析工作。7 分析活動：全流程過程改進進行統計分析的時候，漏測分析小組需要集合在一起，對統計分析結果進行討論。基于統計分析結果可以得到各種趨勢圖，分析小組可以討論全開發流程中需要改進的意見和方案，然后對那些需要改進的地方作出正式的改進建議，制定改進實施計劃，并在隨后的會議上，漏測分析小組對變更實施過程進行討論。可以通過漏測分析數據庫或者其他工具進行任務分配和跟蹤。這里可以給出兩個根據缺陷分析進行全流程改進的例子：第一個例子，假如在系統在故障處理時發現了很多的漏測缺陷，那么進行開發過程全流程改進時，可以考慮增加異常測試組，加強異常測試；第二個例子，假如用戶在某硬件平臺上使用軟件的過程中發現了大量缺陷而測試組卻沒有該硬件平臺，這時需要考慮改進硬件獲取過程，增加測試的硬件平臺。全流程改進會給軟件企業帶來巨大的影響，所以一定要取得治理層的支持和同意。8 分析活動：局部過程改進在聯合項目組進行漏測分析時，對每個產生了漏測的活動都要選出代表（如：開發活動代表、測試活動代表、文檔寫作代表等等）。例如：針對 “ 漏測產生活動 ” 屬性進行分類時，假如某漏測缺陷被分類到 “ 單元測試 ” ，那么該漏測缺陷應該由開發活動代表對其進行進一步的局部過程分析。所有這些缺陷都列在漏測分析數據庫里，每個分類活動的代表應該列出歸屬該活動的所有漏測缺陷列表，然后提出這些活動的局部改進計劃。舉例來說，測試活動代表應該列出所有 “ 漏測產生活動 ” 為 “ 測試 ” 的漏測缺陷，并進行細分，然后將他們分配給測試工程師進行分析；測試工程師將針對所分配的漏測缺陷進行具體分析，找出漏測的原因，然后提出有針對性的改進計劃來防止同類缺陷再次被漏測。這些改進計劃應該在審核通過后實施，并且整個改進過程應該在數據庫中進行跟蹤，每個改進計劃都應該能和單個缺陷漏測分析結果相對應，測試代表應該推動各改進計劃的完成、審核和實施。這里要非凡強調的是，這些改進計劃不是用來修復缺陷的，因為這些被分析的漏測缺陷應該已經被修復好了，這些改進計劃僅僅是在基于某個缺陷漏測原因分析的基礎上重新確定測試過程（或開發過程等），它關心的是如何防止該類問題將來再次發生，而不是關心該特定的缺陷在將來是否會再出現（因為它已經被修復了）。例如，局部過程改進計劃可以是補充以前沒有考慮到的用例，也可以是在測試環境中增加特定的硬件使得測試環境更接近于用戶使用環境。在考慮改進計劃的時候應該鼓勵創造性。9 度量漏測分析過程的最后一步是對改進過程的階段性實施效果進行測量。本文后面部分將對此進行更具體的論述。10 漏測分析舉例 測試過程改進的缺陷漏測分析(1)（圖一）

圖 -1* APAR 是描述缺陷屬性的一個術語。1 漏測的定義 所謂漏測，是指軟件產品的缺陷沒有被測試組發現而遺漏到了用戶那里，卻最終被用戶所發現。假如產品在用戶那里出現問題，產生的后果是非常嚴重的。在軟件開發過程中，缺陷越早被發現，發現和解決缺陷所花的成本就越小。假如缺陷是在測試組測試中發現的而不是被用戶使用時發現的，那么所花的成本將小得多。假如缺陷是被開發組在開發過程中發現的，那么所花的代價將更小。因此，進行漏測分析、預防漏測、促使缺陷盡可能在開發過程的早期被發現，是非常有意義的，它有利于降低軟件產品成本、提高軟件產品質量。2 漏測分析的目的進行漏測分析的目的是為了促進軟件質量和開發測試過程得到持續改進。具體來講，就是通過分析開發和測試過程中漏測的缺陷，制定相應的預防措施以避免今后再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到用戶處的缺陷數和缺陷解決成本，從而提升軟件的質量、聲譽和銷售。在軟件產品開發過程中重視漏測分析并參與到漏測分析工作中的團隊越多，漏測分析的效果就越好。假如開發和測試團隊都重視漏測分析、并密切配合進行漏測分析工作的話，漏測分析將取得非常好的效果。在實際工作中，漏測分析過程應該重點關注那些普遍、嚴重而解決成本高的問題。具體來講，漏測分析的目標是：1）對漏測進行分類以便于更進一步深入的分析2）對分類數據進行統計3）在統計分析的基礎上進行全過程的標識和變更4）在對一些非凡的漏測項進行分析的基礎上，對過程的一些局部進行標識和變更5）運用度量數據說明過程變更的效果6）如何進行漏測分析漏測分析活動可以參照下面的建議進行。在熟悉了漏測分析流程以后，需要確定進行漏測分析活動的頻度。為了取得較好的效果，最好是遵照一個時間表來定期進行漏測分析活動，一個月進行一次是一個比較合適的頻度。3 計劃這個過程是針對多項目組聯合進行漏測分析而設置的，在聯合項目組中實行該過程最有效。假如不可能組建聯合項目組進行漏測分析，也可以修改該過程只在測試組內部實行。制訂計劃假如不確定關注點的話，這個計劃將難以有效實施。漏測分析要想取得理想的效果，就需要計劃好進行漏測分析活動的確切的人員數目、活動時間。過程執行的效果完全取決于執行它的方式，假如不切切實實的做好計劃，你的過程將不會得到太多的改進。實際進行漏測分析活動時，只選擇漏測分類的一部分子集進行分析，將有利于更有效的進行漏測分析工作。進行漏測分類前，需要在計劃中確定選擇哪部分子集進行分析。例如，假如漏測的嚴重度等級分為一到四級，一級嚴重度最高，四級嚴重度最低，那么也許只分析一、二級的漏測最合適，這樣可以避免在那些對用戶無關緊要的漏測缺陷上花太多的無用功；也可以只分析那些被關閉和修復了的漏測缺陷，因為假如分析那些沒有被關閉和修復的缺陷，可能會漏掉一些至關重要的信息；另外，還可以在進行漏測分析之前排除掉重復缺陷和那些由于用戶錯誤操作引起的缺陷，這樣就只需要分析那些有效的漏測缺陷，它們才能真正提供開發和測試過程需要改進的信息。
4 漏測分類接下來需要將所有的漏測缺陷按照有意義的屬性進行分類，當然，前提條件是已經有了一個包含了所有漏測缺陷具體信息的漏測列表。然后需要確定哪些屬性分類是對分析有用的。下面給出一些漏測缺陷的屬性的例子：漏測產生活動（最有可能發現該漏測缺陷的活動）開發階段（原始需求評審、概念評審、設計評審、代碼檢視、單元測試、模塊聯調、信息資料開發）測試階段（功能測試、系統測試、本地語言測試、設備驅動測試、安裝測試、性能測試、異常測試）產品模塊（產生了漏測缺陷的代碼模塊）模塊 A 、 B 、 C 等缺陷影響（對用戶使用造成的影響）系統崩潰、業務中止、數據完整性、命令失效、安裝失敗、設備 / 驅動、性能、文檔、可用性等引入版本（引入漏測缺陷的代碼版本）平臺嚴重級別發現漏測的版本漏測產生活動是指在軟件開發測試過程中，某類被漏測的缺陷最應該在該活動中被發現。設置該項分類的目的是為了便于對產生了漏測的活動進行更進一步的細化分析。產品模塊是指被漏測的缺陷所在的代碼模塊。缺陷影響是指漏測缺陷給用戶使用時所帶來問題的類型。引入版本是漏測缺陷被引入時的代碼版本，它應該是代碼第一次引入該缺陷的版本。平臺是指產生漏測的平臺或操作系統。嚴重級別是指缺陷的嚴重程度度量，例如：致命、嚴重、一般、提示。假如你的缺陷跟蹤過程還沒有包含缺陷的這個屬性，那么漏測分析過程應該明確地給出每個缺陷的嚴重級別。發現漏測的版本是指該漏測初次被發現并被報告時的軟件版本。進行漏測分類活動時，最好將開發、測試、技術支持以及其他所有產品生命周期中相關部門的代表組織到一起對近期的漏測進行討論，非凡是技術支持人員能夠提供很多非常具體的關于漏測缺陷的信息，這對漏測分類非常有幫助。在項目組進行實際漏測分析活動時，也許不需要按照上面建議的一些屬性進行分類，而需要采用其他一些分類標準，這時最好在項目組內集體討論來決定哪些分類是最適用的。在漏測缺陷分類活動結束后，需要對分類結果數據進行統計分析。例如，每個漏測缺陷對應了一個漏測產生的活動，這時可以考慮對該活動進行進一步的改進。5 分析活動：跟蹤工具進行漏測分析時假如沒有缺陷跟蹤工具的支持是很困難的。應該采用工具來維護所有不同分類的漏測缺陷數據。 Lotus Notes 數據庫就是一個不錯的工具，它能很方便地將數據按各種不同的方式進行分割，這樣你能夠對同樣一批數據創建各種視圖，從而能夠從各個角度進行統計分析。6 分析活動：統計統計分析是為了指導全流程過程改進。進行統計分析首先要確定進行統計分析的頻度，一般一個季度進行一次統計分析比較合適。進行統計分析時，需要將某個分類的各分類項的數據一一和該分類的所有其它分類項數據進行比較，并且對所有的分類都要進行這樣的操作。對那些相對總數比較大的分類項還要進行更進一步細分，進行更進一步的統計分析工作。7 分析活動：全流程過程改進進行統計分析的時候，漏測分析小組需要集合在一起，對統計分析結果進行討論。基于統計分析結果可以得到各種趨勢圖，分析小組可以討論全開發流程中需要改進的意見和方案，然后對那些需要改進的地方作出正式的改進建議，制定改進實施計劃，并在隨后的會議上，漏測分析小組對變更實施過程進行討論。可以通過漏測分析數據庫或者其他工具進行任務分配和跟蹤。這里可以給出兩個根據缺陷分析進行全流程改進的例子：第一個例子，假如在系統在故障處理時發現了很多的漏測缺陷，那么進行開發過程全流程改進時，可以考慮增加異常測試組，加強異常測試；第二個例子，假如用戶在某硬件平臺上使用軟件的過程中發現了大量缺陷而測試組卻沒有該硬件平臺，這時需要考慮改進硬件獲取過程，增加測試的硬件平臺。全流程改進會給軟件企業帶來巨大的影響，所以一定要取得治理層的支持和同意。8 分析活動：局部過程改進在聯合項目組進行漏測分析時，對每個產生了漏測的活動都要選出代表（如：開發活動代表、測試活動代表、文檔寫作代表等等）。例如：針對 “ 漏測產生活動 ” 屬性進行分類時，假如某漏測缺陷被分類到 “ 單元測試 ” ，那么該漏測缺陷應該由開發活動代表對其進行進一步的局部過程分析。所有這些缺陷都列在漏測分析數據庫里，每個分類活動的代表應該列出歸屬該活動的所有漏測缺陷列表，然后提出這些活動的局部改進計劃。舉例來說，測試活動代表應該列出所有 “ 漏測產生活動 ” 為 “ 測試 ” 的漏測缺陷，并進行細分，然后將他們分配給測試工程師進行分析；測試工程師將針對所分配的漏測缺陷進行具體分析，找出漏測的原因，然后提出有針對性的改進計劃來防止同類缺陷再次被漏測。這些改進計劃應該在審核通過后實施，并且整個改進過程應該在數據庫中進行跟蹤，每個改進計劃都應該能和單個缺陷漏測分析結果相對應，測試代表應該推動各改進計劃的完成、審核和實施。這里要非凡強調的是，這些改進計劃不是用來修復缺陷的，因為這些被分析的漏測缺陷應該已經被修復好了，這些改進計劃僅僅是在基于某個缺陷漏測原因分析的基礎上重新確定測試過程（或開發過程等），它關心的是如何防止該類問題將來再次發生，而不是關心該特定的缺陷在將來是否會再出現（因為它已經被修復了）。例如，局部過程改進計劃可以是補充以前沒有考慮到的用例，也可以是在測試環境中增加特定的硬件使得測試環境更接近于用戶使用環境。在考慮改進計劃的時候應該鼓勵創造性。9 度量漏測分析過程的最后一步是對改進過程的階段性實施效果進行測量。本文后面部分將對此進行更具體的論述。10 漏測分析舉例 測試過程改進的缺陷漏測分析(1)（圖一）

圖 -1* APAR 是描述缺陷屬性的一個術語。

上一篇：軟件開發質量管理層次模型(1)

下一篇：如何對軟件質量進行評估(1)