功能點分析法應用在軟件測試中，它最核心的價值究竟是什么呢? 讓我們先看看軟件開發，這是跟測試離得最近的工作類型。開發工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用UML語言，借助類似於Rose這樣的工具，繪制一些UC圖、類圖、ER圖等 最近有位同事問我，“天彤你搞這個功能點分析算法，主要目的是度量project的規模么，還是度量測試工程師的工作量?”我說，這兩個確實是最初的目標，不過現在，這只是功能點算法的副產品，並不是核心價值。“那是不是根據功能點分析，可以自動生成測試用例呢?”這的確是一個很誘人的功能，而且隨着進一步研究發現，先用freemind進行功能點分析，然后自動生成一部分測試用例，是完全可行的，不過這仍然是副產品，不是最核心的目標。
功能點分析法應用在軟件測試中，它最核心的價值究竟是什么呢?
讓我們先看看軟件開發，這是跟測試離得最近的工作類型。開發工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用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下面，而是有很大一部分，會掛在輸入項的下面，表示和輸入的邏輯關系，這種關系也是設計圖中的重要信息，如下圖：
在導入twork以后，會在邏輯事務的測試集下，產生一個叫做“買家狀態”的測試集，這些枚舉值將變成輸入條件，而后面的輸出結果，將變成期望結果。如下圖：
還有一種輸入項，比如頁面表單的輸入框，會產生一堆輸出：“不能為空”“不能超過20字符”等等，在設計圖中，我們可以把這一堆輸出，直接掛在輸入項下面，這樣，也會產生一組用例，也就是我們常說的頁面校驗。
上面所說的，是輸出和輸入緊密關聯的情況，產生的用例比較簡單。除此以外還會出現更復雜的情況，當多個輸入組合在一起的時候，才會產生一定的輸出。這時，就需要把這些有邏輯關系的輸入組織起來，在設計圖里單獨建一個node，注意這個node上不要標記Input，因為它不是一個輸入項，而只是一個分組。真正的輸入項在下面。如下圖：
根據這一部分的設計，會生成一組比較復雜的用例，每個輸入項，會成為一列，這里有4個，就是4列，另外再加1列“期望結果”。這是twork中一種新的用例編寫模式，叫做測試數據驅動模式(TD驅動)，看起來眼熟，其實就是“判定表”，我們以前用Excel寫用例的時候，就是這么寫的，現在在twork中，更進了一步，用戶可以隨意定義每個測試集的列，而每一行，也作為一個用例對象，保存在數據庫里。如下圖：
需要說明的是，這種復雜的組合，程序是無法自動生成用例的，因為要完全排列組合的話，用例太多，不靠譜，而且具體的組合情況，跟需求有很強的關系，程序更是難以了解。程序能做的是，生成用例表格結構，同時創建一些空白的用例，然后我們自己在里面填一下值就可以了，寫用例速度快，而且用例非常直觀。
大家注意到了，在設計圖中，輸入、輸出、實體我們都用不同的標記給標識出來，這樣導入twork時，程序便會自動算出每個邏輯事務的功能點指數分值，非常方便，所以文章開頭說，這個指數計算，只是一個副產品。
通過上面的分析過程我們可以看出，功能點分析圖與測試用例之間，存在非常緊密的邏輯關系，之前幾篇文章我們也講到，功能點分析是一種非常好的分解分析需求的手段。通過這張分析圖，讀者可以迅速了解設計者的思路，以及了解每個邏輯事務大致的邏輯。這時如果需要看細節，可以進入twork，很快找到這個邏輯事務的測試集，並查看下面的用例。
上面的例子，列舉的是Create類的邏輯事務，以及里面兩種最常見的輸入組合。Update類和Delete類事務，跟這個差不多，這里不再細講。它們的共同點在於，輸入一般較多，並且存在一些邏輯組合，而輸出，相對比較簡單。
至於Read類和List類事務，在設計圖會有一些區別，這兩種邏輯事務輸入相對較少，而輸出項很多，它們主要的測試重點在於，校驗頁面展示，比如“查看寶貝信息”，輸出項可能會有30個以上，這時，使用check list的方式會比較方便，並不用編寫復雜的用例，只需說明，需要校驗哪些點即可。如果Read類事務也有復雜的輸入，比如查看寶貝信息會有：寶貝類型、寶貝類目、寶貝消保類型這些輸入，那么就參考剛才Create類的方式即可。
總之，設計用例重點關注業務邏輯，對於展示類的事務，盡量用簡單的方式完成測試設計，至於有些一看到頁面，就知道應該怎么測試的事務，即使不寫用例，我覺得也問題不大。只要在設計圖中把這個事務的輸入輸出實體都標識清楚，我相信測試工程師就可以很好的完成測試工作。即使交給另一位工程師，只要他也了解這種設計模式，那么也可以測得很好。