面對用戶反饋的缺陷：我們能做些什麼
窮盡測試是不可能的，這是軟件測試的一條基本原則。通過測試並不能發現和修改測試對象中的全部的缺陷和問題，因此，不可避免有一些缺陷會遺漏到客戶的使用現場，從而觸發軟件產品產生令用戶不滿意的失效或者各種問題。那麼，測試人員在面對用戶反饋的缺陷的時候，我們能夠做些什麼？本文將從幾個方面來回答該問題。
1）DDP
首先，測試人員可以根據用戶反饋的缺陷數目，來判斷和分析測試人員在測試過程中的測試有效性。通常來說，在測試過程中判斷測試人員的測試有效性是很困難的。但是通過用戶反饋的缺陷數目，卻可以直觀的說明測試人員是否遺漏了比較多的問題，從而反映測試人員的測試有效性。
缺陷檢測百分比DDP（Defect Detection Percentage）就是基於這樣的目的進行定義的，它可以用來評判軟件測試生命週期內某個階段的測試有效性，它以百分比的形式進行計算[1]。其計算公式爲：
DDP = [R1 / (R1 + R2)] * 100%
其中：
° R1指的是被評估階段發現所發現的缺陷數目；
° R2是被評估階段之後所發現的所有的缺陷數目；
注意：DDP計算公式的分母並不是發現的總的缺陷數目，而是指該階段之後所有發現的缺陷數目（包括該階段的缺陷數目）。另外，採用DDP作爲測試有效性的評估指標，存在的一個問題是需要在產品發佈一段時間之後才能進行，例如：產品發佈之後3個月。
表1是計算DDP的一個例子（主要針對動態測試而言的）：
2）過程改進
用戶反饋的缺陷，是進行過程改進的重要輸入。通過收集和分析從用戶使用現場反饋的缺陷，可以回答“爲什麼這些缺陷會遺漏到用戶現場”這樣的問題。假如測試人員可以找到這個問題的答案，那麼就可以將該分析結果應用到下個項目的測試過程中，以儘量減少此類問題再次遺漏到用戶現場，從而達到過程改進的目的。
下面是筆者在對用戶反饋的缺陷進行分析過程中，對遺漏到用戶現場的原因進行的分類。對用戶反饋的缺陷進行分類，可以更好的幫助測試人員查找遺漏該缺陷的原因，從而爲過程改進提出更加明確和直接的建議和方案。缺陷遺漏到用戶現場的主要原因可以是多樣的，例如：
（1）需求的原因
通常來說，軟件產品或者系統開發和測試的基礎是需求，因此需求定義的質量直接決定了測試對象的質量。而測試人員經常面對的需求是不全的、模糊的，甚至是不正確的。
在分析某個產品用戶反饋的缺陷過程中，發現用戶針對系統R1.0版本配置的數據庫，並不能直接在升級之後的R2.0版本中使用，用戶認爲這極大的浪費了客戶的配置時間，也對該產品的易用性產生了某些懷疑。項目利益相關者對該類型的缺陷分析之後，發現測試人員並沒有針對這樣的場景進行測試，而更深層次的原因是系統的需求中並沒有定義可移植性的非功能特性。
分析了該類用戶反饋的缺陷之後，項目團隊將可移植性非功能特性作爲評審軟件工作產品的檢查表的一個檢查點，以避免在將來的項目開發過程中遺漏該質量特性。
（2）測試設計問題
有些缺陷遺漏到用戶現場的原因，是由於測試人員在測試設計技能方面的欠缺。測試設計技術和方法是有效開展測試用例設計的基礎，測試人員掌握的技術和方法越多，就越有利於他們設計更好的測試用例。
在分析某個產品用戶反饋的缺陷過程中，發現IGMP協議在有些情況下不能和其他產品的IGMP功能協調工作，並且最後定位是由於我們產品的IGMP協議方面存在問題。後來在系統人員、開發人員和測試人員的共同努力之下，分析得知是由於IGMP的狀態轉換存在問題，特別是狀態在進行連續幾個轉換之後容易出現問題。主要的原因是測試人員在設計IGMP狀態轉換測試用例的時候，由於沒有掌握狀態轉換測試技術，導致其測試覆蓋率偏低，從而使得該類問題遺漏到用戶現場。
對於這樣的問題，測試團隊需要經常的進行合適的測試技術和方法的培訓，例如：針對上面的案例，測試團隊後來開展了狀態轉換測試的深入的學習和培訓，並在後續的類似狀態轉換測試中，每個測試人員都可以熟練的應用0-Switch和1-Switch的狀態轉換技術。
（3）測試資源問題
有些用戶反饋的問題，既不是需求定義的遺漏或者不明確，也不是測試人員沒有合適的測試用例設計，而是由於測試資源方面的問題導致的。
用戶在實際的網絡使用環境中，發現並不能達到2000個IGMP用戶同時進行視頻點播的性能要求，從而提交了一個嚴重程度比較高的缺陷。在分析該缺陷的過程中，發現該產品的需求定義中有明確的規定要求達到2000個用戶同時點播的要求，而在測試用例規格中，也有相應的測試用例存在。但是由於測試資源的限制，測試人員無法執行該測試用例，使得該產品發佈的時候，該用例還是處於block狀態。
對於此類測試資源的問題，一個解決方案是購買能夠模擬2000個IGMP用戶的測試儀表，另一個可行的方案是測試團隊自己開發IGMP用戶的模擬器。
（4）迴歸測試問題
有些用戶反饋的問題，是由於修改某些缺陷之後新引入的，或者由於修改某些缺陷觸發了其他潛在的缺陷。導致此類問題的主要原因是，在選擇迴歸測試用例的時候，其修改的影響分析和風險風險做的不仔細和不完善。
對於這些問題，也就要求測試人員更加深入的學習和理解被測對象的內部結果，以及對失效模式和影響分析、風險分析等技術提出了更高的要求。通過學習和培訓，可以逐步提高測試人員在這些方面的能力。
（5）測試環境和使用環境的不同
用戶反饋的缺陷是由於測試環境，和用戶實際的產品使用環境存在較大差距而引起的。例如：測試人員在測試產品的圖形化用戶接口GUI的時候，一直採用的瀏覽器是IE7.0。而在用戶的使用環境在有FoxZilla、IE5.0等，導致產品的兼容性出現問題。
因此，在高級別的測試執行中（比如系統測試和驗收測試），要求測試環境能夠儘量貼近用戶的使用環境。儘量模擬用戶使用環境，一方面可以在我們的測試執行過程中，發現我們的軟件產品和其他協同工作的產品之間的兼容特性，避免軟件發佈給用戶之後才發現這些問題；另一方面，也可以用來檢驗我們的產品是不是用戶真正需要的產品。
爲了達到這些目標，測試團隊必須瞭解用戶的軟件產品使用環境，比如用戶使用該軟件產品的操作系統、和我們軟件產品對接的產品是什麼、用戶使用該產品可能的網絡拓撲結構是什麼（用戶使用該軟件產品的主要用戶場景等）。因此，我們的測試團隊在瞭解和熟悉我們的系統需求和實現之外，也需要去掌握和發現用戶可能的使用場景，以及其他競爭對手產品的一些功能和特徵屬性。另外，在可能的情況下，邀請產品的潛在用戶參與我們測試環境的搭建，或者徵詢用戶在環境搭建方面的一些要求和建議，幫助我們來模擬用戶的使用環境，從而減少可能和用戶使用環境背離太多而導致的風險，提高我們的測試效率和測試質量。
（6）窮盡測試是不可能的
窮盡測試是不可能的，因此，測試團隊在有限的時間、資源的情況下，無法發現測試對象中的所有缺陷，也就是說遺留到客戶現場的缺陷是不可避免的。而我們能做的是，如何不斷完善我們的需求、背景知識、測試技術、測試環境等，從而不斷提升我們的測試能力，不斷提高我們的DDP。
上面是我們分析用戶反饋的缺陷過程中，經常採用的缺陷分類。但該缺陷分類並不是全面的，需要我們在測試過程中不斷的修改和更新，從而不斷完善我們的缺陷分類。
假如讀者有什麼好的建議，請不吝賜教。
參考資料：
[1] Dorothy Graham, Grove Consultants, www.grove.co.uk
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/Wenqiang_Zheng/archive/2010/10/17/5947299.aspx