以客戶關注為焦點看軟件測試

　　軟件測試的終極目標是給客戶提供滿意的產品和服務。因此，只有真正去理解、熟悉、分析客戶所關注的業務，才能給客戶提供高質量的產品。本文從包括客戶的使用目的、客戶的使用預期、客戶的部署環境、客戶的數據甚至客戶的使用習慣除非，講解如何才能從本質上更好的改進測試的重點與方向，抓住測試的精髓，給客戶提供高質量的產品。

　　眾所周知，在軟件測試行業，往往都是以軟件 Bug 數量來衡量軟件的質量。一個軟件被測試團隊發現有大量 Bug 時，該軟件的質量被認為處在不高的水平。當較少的 bug 被發現時，軟件則被認為是具有較高質量的。測試的目的是為了發現更多的 Bug，然而測試人員經常會為追求發現更多的 Bug 數量而忽略了軟件測試更本質的東西。軟件測試的終極目標是給客戶提供滿意的產品和服務。因此，只有真正去理解、熟悉、分析客戶所關注的業務，包括客戶的使用目的、客戶的使用預期、客戶的部署環境、客戶的數據甚至客戶的使用習慣才能從本質上更好的改進測試的重點與方向，抓住測試的精髓，給客戶提供高質量的產品。

　　當前的問題

　　軟件測試人員一般都會遇到這樣的問題。一個軟件(項目)，在測試過程中往往會發現幾百個甚至上千個 Bug，測試團隊的經理以及所有測試人員認為發現如此多的缺陷，軟件應該已經被嚴格把關，最終交付給客戶的軟件應該是比較合格，至少不會有高級別的或者嚴重影響客戶使用的缺陷被客戶發現。然而當軟件被客戶部署投入生產線后，大量的缺陷被客戶報出來，而這些缺陷是測試團隊在測試中忽略掉的。仔細分析，主要由下列原因造成。

　　測試的力度和深度不夠。

　　首先是人力資源和時間上的緊缺造成的。通常一個產品測試，往往都是一個測試人員負責好幾個模塊。項目上測試人員要負責環境搭建，測試用例的編寫，測試的執行以及最后的報告制作。測試的每一個環節都非常耗時，而且很難做到并行工作，最終導致測試在力度以及深度上很難面面俱到。有時一些項目客戶要求的交付時間緊，所以最后測試即便能夠達到通過標準，在客戶那里依然會暴露出很多我們在測試中忽略的問題。其次是遇到一些特殊情況。當一個新版本產品正在緊張的測試準備按時交付時，而客戶在使用上一版本的軟件時遇到緊急問題，需要測試團隊進入 7*24 小時解決狀態，這時候必然會連帶影響到新版軟件的測試質量。另外，需求設計的不確定以及后期的變更也會導致此類問題。

　　某項目開發與測試團隊在解決某客戶因為軟件缺陷導致的緊急問題，該緊急問題嚴重影響阻礙客戶的正常工作，因此被要求在短期內給出解決方案。由于該問題的復雜性，開發團隊用掉了大部分時間才解決了該問題。由于交付的時間已定，留給測試團隊的時間已經不可能完成一定力度和深度的測試，人力匱乏的測試團隊只能保證原軟件缺陷本身被解決，同時產品的大功能保證可用，非常重要的擴展測試由于時間問題被省略?？梢韵胂?，在客戶的環境中，解決該缺陷所引起的回歸問題被客戶發現。如果時間和人力充足的測試團隊完成了擴展測試，這個回歸缺陷就不會出現。所以只有充分的測試時間以及充足的測試人員才能保證測試的力度和深度，從而提高軟件質量。

　　環境的不同，包括硬件環境和軟件環境。

　　大部分測試團隊在測試時，模擬測試的硬件環境都非常優良?？蛻舳酥饕霉P記本電腦來模擬，服務端用臺式機或者一些虛擬機等等。這些設備往往都是比較高的配置，而且電腦之間通訊所用的網絡基本是有線網絡，速度也非常高。而在客戶現場，部署我們產品的所用的設備環境很難與測試團隊優良的測試環境相一致?？蛻舻目蛻舳擞械呐渲煤艿?，網絡也比較慢，有線網絡以及無線網絡等如圖 1：客戶測試團隊環境對比圖。另外客戶環境的一些突發事件，例如無線網絡不穩定，有線網絡突然斷網，設備斷電等都會造成一些低級但很嚴重的軟件缺陷。

　　某客戶部署軟件的環境屬于客戶端低配、網絡是慢且不穩定的無線網絡。在優良測試環境測試通過交付的產品在客戶的部署環境上，當客戶端與服務端進行上傳下載交互時，客戶端的軟件崩潰，數據不能正確傳輸到服務端。同時在服務端的日志里，記錄了大量交互的出現的錯誤。

　　還有就是模擬軟件環境，主要是數據環境。測試團隊的測試往往都是在一個干凈的系統里新建一套賬號，再手動或自動化初始一些簡單的數據，然后再分配職責進行測試。而客戶環境的情況更復雜，所用的數據也更復雜?？蛻袅晳T在原有數據的基礎上進行安裝、升級。

　　某客戶在使用先前版本的軟件時，創建了一些項目，存儲了一些數據。當升級安裝了新版的軟件時，某些功能會出現不可用，或者客戶的數據丟失，這將是很嚴重的問題?？蛻艚⒌膹碗s邏輯數據往往能發現產品的缺陷，而這是測試團隊用簡單數據無法發現的。

　　所以要模擬客戶的硬件環境和軟件環境來發現一些在測試中被忽略的問題。

　　圖 1. 客戶測試團隊環境對比圖

　　整個測試進程沒有站在客戶角度上，以客戶關注為焦點進行軟件測試。

　　測試人員在進行軟件測試之前，首先會按照被測模塊的 FDD(功能設計文檔)和 TDD(技術設計文檔)，通過自己對對該模塊的理解以及與相應開發人員的討論，最終形成一份被測模塊的測試用例文檔。測試時，按照測試用例，和測試人員自己準備的測試數據，通過菜單逐級向下進行。測試人員的經驗在這樣主觀性很大的測試中占據了很大比例。這樣的測試，可稱為功能測試，而不能完全稱為業務測試。它能夠確保所測的功能點正常，然而沒有真正的站在客戶的角度上，去理解、分析客戶所關注的業務，包括客戶的使用目的、客戶的使用預期、甚至客戶的使用習慣等。測試人員在這個模塊的某功能點測出了很多缺陷，但是在客戶的業務中，一個經常使用的功能點卻沒有被測試人員重視。某客戶的業務是使用業務分析中數據收集的產品進行某項目的電話采訪，該項目主要是獲取世界一些國家像美國、印度、馬來西亞等的市民對信用卡業務的滿意度?？蛻粼诿绹牟稍L項目，產品正常。因為軟件的默認語言為 English(UnitedStates)，所以軟件在交付前被仔細深入的測試過。然而在印度的采訪項目，由于訪員都是印度人，當軟件語言被設置為 English(India)時，客戶發現很多軟件功能不可用。如果測試團隊認真分析過客戶的業務，就會知道客戶在印度有機構分布，大量的業務在印度的機構運行。所以軟件語言被設置成印度英語后的功能的正確性將是一個非常重要的測點。

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-cn-customerperspecttesting/index.html