使用功能點估算模型評估軟件測試的工作量

　　最近有位同事問我，“天彤你搞這個功能點分析算法，主要目的是度量project的規模么，還是度量測試工程師的工作量?”我說，這兩個確實是最初的目標，不過現在，這只是功能點算法的副產品，并不是核心價值。“那是不是根據功能點分析，可以自動生成測試用例呢?”這的確是一個很誘人的功能，而且隨著進一步研究發現，先用freemind進行功能點分析，然后自動生成一部分測試用例，是完全可行的，不過這仍然是副產品，不是最核心的目標。

　　功能點分析法應用在軟件測試中，它最核心的價值究竟是什么呢?

　　讓我們先看看軟件開發，這是跟測試離得最近的工作類型。開發工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用uml/" target="_blank" >UML語言，借助類似于Rose這樣的工具，繪制一些UC圖、類圖、ER圖等等。這些設計圖決定了最終的編碼該如何實施。另外，當其他的開發工程師需要了解這個project時(例如評審)，ta會先看設計文檔，從設計文檔中掌握開發思路，然后再閱讀代碼，了解細節。

　　由于UML語言中，包含了大量的約定和規則，因此開發工程師只需要花費較少的工作量，就能表達出充足的信息。而閱讀UML設計文檔的其他人，也能很快從UML設計中了解設計人員的思路。試想一下，如果讓讀者直接看代碼，需要花費多少倍的時間，才能達到相同的目的。這就是設計模型的價值，不僅幫助設計人員自己整理思路，也幫助其他讀者快速交流信息。

　　對于軟件測試來說，也有“設計”和“編碼(實施)”兩個階段的工作。設計是我們設計測試用例的過程，也就是我們考慮如何做;實施就是我們執行測試的過程，有時是手工執行，有時是寫腳本讓計算機執行。因此，測試用例是我們的“設計文檔”，是我們交流測試方法，評審測試方案的核心。但是只依靠測試用例，我們感覺存在很多問題：

　　測試用例數量多，難以閱讀

　　測試用例結構五花八門，風格迥異，不同團隊間不好交流

　　測試用例很難清楚表達需求邏輯，每次用例評審，要花費大量時間，講解需求邏輯

　　測試用例描寫的是測試細節，較難看出測試的思路和重點

　　在這種情況下，我們需要一種測試設計模型，用來解決上面那些問題。事實上，測試設計模型不是唯一的，我們允許團隊中使用各種設計模型來設計測試用例。以前我們曾經用UML來設計，這是一種設計模型。不過UML開發工程師用起來合適，我們測試用就不是特別合適，畢竟它的優勢，是描述程序的開發實現。另外，設計模型和測試用例模式，應該是成對出現的，也就是說，用什么樣的設計模型，就應該有合適的用例模式與之對應。一成不變的用例模式，其實是不存在的，它必須要緊跟設計模型。

　　這就是我們選擇功能點分析算法的最主要目的：尋找一種新的設計模型，改善我們的測試用例設計過程，精簡測試文檔(因為模型可以包含很多信息)，讓測試團隊用一種相同的設計模型進行工作，減少溝通成本，更好的支撐我們的業務測試。

　　現在我們面對的，是互聯網軟件產品，這一類軟件的特點，不同于傳統的應用軟件，互聯網應用軟件多使用BS結構，MVC的開發模型，有龐大的數據庫作為支撐，需求和用戶界面多變，市場競爭激烈，等等。在這種條件下，測試工程師往往沒有太多時間設計用例，而是要快速的面對大量新需求和需求變更，第一時間找出程序的bug，這才是王道。

　　下面，我們講一下，怎么樣使用功能點分析的方法，來設計測試用例。

　　如part2所說，我們拿到一個project，首先需要把它拆分成邏輯事務，然后針對每個邏輯事務，討論使用何種測試方法。有些事務屬于核心事務，必須要重點測試，要設計完整的用例，有些事務只需編寫一個簡單的check list，就足夠指導測試執行了，有些事務甚至根本不用寫任何文檔，測試工程師拿到手也知道該怎么測試。在這里我不想再回答“一個完全不懂的測試新人，看不到用例，該怎么測試?”這樣的問題。測試新人正式上崗之前，必須接受測試技術培訓，和project的業務培訓。如果是跨團隊合作(其實這種場景很少)，那么PTM也要出面先做一些測試方案的講解，絕對不能把測試用例直接扔給其他工程師。

　　這里我們推薦使用freemind或者xmind這樣的思維導圖軟件，來做功能點分析。root node一般是project的名稱，比如購物車。然后下級node是各個模塊的名稱，然后就是邏輯事務的名稱。本文選了一個邏輯事務作為案例：買家在寶貝詳情頁面點擊購買。通過對這個事務的功能點分析，再推導出相應的測試用例。事實上，淘寶測試團隊的twork小組，正在開發通過freemind圖，自動生成測試用例的功能，所以在下面的講解中，我會不斷比較，freemind圖和最終生成的用例。

　　首先在邏輯事務的node下創建：輸入、輸出、實體3個node，先列出所有的實體。實體對用例設計并沒有什么影響，只是告訴讀者，這個事務跟哪些對象有關，這樣可以清楚的界定用例范圍。如下圖：

　　“01點擊立即購買”是我們今天要講的事務，02～06也是事務，但是今天不會講到。使用twork把這個設計圖導入以后，將會產生對應的目錄結構，注意，一直到邏輯事務這一層，都和設計圖相同，再往下，會根據設計的不同有所變化，而并不產生“輸入”“輸出”這樣的測試集。如下圖：

　　下面重點要講輸入，這和測試用例的設計有很大關系。這個事務的輸入比較多，不過我們如果分類來看，就會比較清楚。首先看最上面那3個實體的主鍵id，這3個輸入是必須要參與程序的邏輯運算的，但是與測試用例無關。如下圖：

　　有一類輸入，比如買家狀態，會有很多枚舉值，這些枚舉值會產生非常優先的判定，比如說，一個被處罰的買家，是不能購買寶貝的。這一個條件就可以直接產生一個確定的結果，這些結果，一般是用頁面文字的方式告知用戶，所以要算作“輸出”。注意：輸出的項，不一定都在“輸出”這個node下面，而是有很大一部分，會掛在輸入項的下面，表示和輸入的邏輯關系，這種關系也是設計圖中的重要信息，如下圖：

原文轉自：http://www.anti-gravitydesign.com