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

1、使用功能點估算模型評估軟件測試的工作量功能點分析法應用在軟件測試中，它最核心的價值究竟是什么呢? 讓我們先看看軟件開發(fā)，這是跟測試離得最近的工作類型。開發(fā)工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用UML語言，借助類似于Rose這樣的工具，繪制一些UC圖、類圖、ER圖等 最近有位同事問我，“天彤你搞這個功能點分析算法，主要目的是度量project的規(guī)模么，還是度量測試工程師的工作量?”我說，這兩個確實是最初的目標，不過現(xiàn)在，這只是功能點算法的副產品，并不是核心價值?！澳鞘遣皇歉鶕?jù)功能點分析，可以自動生成測試用例呢?”這的確是一個很誘人的功能，而且隨著進一步研究發(fā)現(xiàn)，先用free

2、mind進行功能點分析，然后自動生成一部分測試用例，是完全可行的，不過這仍然是副產品，不是最核心的目標。 功能點分析法應用在軟件測試中，它最核心的價值究竟是什么呢?讓我們先看看軟件開發(fā)，這是跟測試離得最近的工作類型。開發(fā)工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用UML語言，借助類似于Rose這樣的工具，繪制一些UC圖、類圖、ER圖等等。這些設計圖決定了最終的編碼該如何實施。另外，當其他的開發(fā)工程師需要了解這個project時(例如評審)，ta會先看設計文檔，從設計文檔中掌握開發(fā)思路，然后再閱讀代碼，了解細節(jié)。由于UML語言中，包含了大量的約定和規(guī)則，因此開發(fā)工程師只需要花費較

3、少的工作量，就能表達出充足的信息。而閱讀UML設計文檔的其他人，也能很快從UML設計中了解設計人員的思路。試想一下，如果讓讀者直接看代碼，需要花費多少倍的時間，才能達到相同的目的。這就是設計模型的價值，不僅幫助設計人員自己整理思路，也幫助其他讀者快速交流信息。對于軟件測試來說，也有“設計”和“編碼(實施)”兩個階段的工作。設計是我們設計測試用例的過程，也就是我們考慮如何做;實施就是我們執(zhí)行測試的過程，有時是手工執(zhí)行，有時是寫腳本讓計算機執(zhí)行。因此，測試用例是我們的“設計文檔”，是我們交流測試方法，評審測試方案的核心。但是只依靠測試用例，我們感覺存在很多問題：···

4、· 測試用例數(shù)量多，難以閱讀 測試用例結構五花八門，風格迥異，不同團隊間不好交流 測試用例很難清楚表達需求邏輯，每次用例評審，要花費大量時間，講解需求邏輯 測試用例描寫的是測試細節(jié)，較難看出測試的思路和重點在這種情況下，我們需要一種測試設計模型，用來解決上面那些問題。事實上，測試設計模型不是唯一的，我們允許團隊中使用各種設計模型來設計測試用例。以前我們曾經用UML來設計，這是一種設計模型。不過UML開發(fā)工程師用起來合適，我們測試用就不是特別合適，畢竟它的優(yōu)勢，是描述程序的開發(fā)實現(xiàn)。另外，設計模型和測試用例模式，應該是成對出現(xiàn)的，也就是說，用什么樣的設計模型，就應該有合適的用例模式與之

5、對應。一成不變的用例模式，其實是不存在的，它必須要緊跟設計模型。這就是我們選擇功能點分析算法的最主要目的：尋找一種新的設計模型，改善我們的測試用例設計過程，精簡測試文檔(因為模型可以包含很多信息)，讓測試團隊用一種相同的設計模型進行工作，減少溝通成本，更好的支撐我們的業(yè)務測試。現(xiàn)在我們面對的，是互聯(lián)網軟件產品，這一類軟件的特點，不同于傳統(tǒng)的應用軟件，互聯(lián)網應用軟件多使用BS結構，MVC的開發(fā)模型，有龐大的數(shù)據(jù)庫作為支撐，需求和用戶界面多變，市場競爭激烈，等等。在這種條件下，測試工程師往往沒有太多時間設計用例，而是要快速的面對大量新需求和需求變更，第一時間找出程序的bug，這才是王道。下面，我們

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

7、不能把測試用例直接扔給其他工程師。這里我們推薦使用freemind或者xmind這樣的思維導圖軟件，來做功能點分析。root node一般是project的名稱，比如購物車。然后下級node是各個模塊的名稱，然后就是邏輯事務的名稱。本文選了一個邏輯事務作為案例：買家在寶貝詳情頁面點擊購買。通過對這個事務的功能點分析，再推導出相應的測試用例。事實上，淘寶測試團隊的twork小組，正在開發(fā)通過freemind圖，自動生成測試用例的功能，所以在下面的講解中，我會不斷比較，freemind圖和最終生成的用例。首先在邏輯事務的node下創(chuàng)建：輸入、輸出、實體3個node，先列出所有的實體。實體對用例設計

8、并沒有什么影響，只是告訴讀者，這個事務跟哪些對象有關，這樣可以清楚的界定用例范圍。如下圖：“01點擊立即購買”是我們今天要講的事務，0206也是事務，但是今天不會講到。使用twork把這個設計圖導入以后，將會產生對應的目錄結構，注意，一直到邏輯事務這一層，都和設計圖相同，再往下，會根據(jù)設計的不同有所變化，而并不產生“輸入”“輸出”這樣的測試集。如下圖：下面重點要講輸入，這和測試用例的設計有很大關系。這個事務的輸入比較多，不過我們如果分類來看，就會比較清楚。首先看最上面那3個實體的主鍵id，這3個輸入是必須要參與程序的邏輯運算的，但是與測試用例無關。如下圖：有一類輸入，比如買家狀態(tài)，會有很多枚舉

9、值，這些枚舉值會產生非常優(yōu)先的判定，比如說，一個被處罰的買家，是不能購買寶貝的。這一個條件就可以直接產生一個確定的結果，這些結果，一般是用頁面文字的方式告知用戶，所以要算作“輸出”。注意：輸出的項，不一定都在“輸出”這個node下面，而是有很大一部分，會掛在輸入項的下面，表示和輸入的邏輯關系，這種關系也是設計圖中的重要信息，如下圖：在導入twork以后，會在邏輯事務的測試集下，產生一個叫做“買家狀態(tài)”的測試集，這些枚舉值將變成輸入條件，而后面的輸出結果，將變成期望結果。如下圖：還有一種輸入項，比如頁面表單的輸入框，會產生一堆輸出：“不能為空”“不能超過20字符”等等，在設計圖中，我們可以把這一

10、堆輸出，直接掛在輸入項下面，這樣，也會產生一組用例，也就是我們常說的頁面校驗。上面所說的，是輸出和輸入緊密關聯(lián)的情況，產生的用例比較簡單。除此以外還會出現(xiàn)更復雜的情況，當多個輸入組合在一起的時候，才會產生一定的輸出。這時，就需要把這些有邏輯關系的輸入組織起來，在設計圖里單獨建一個node，注意這個node上不要標記Input，因為它不是一個輸入項，而只是一個分組。真正的輸入項在下面。如下圖：根據(jù)這一部分的設計，會生成一組比較復雜的用例，每個輸入項，會成為一列，這里有4個，就是4列，另外再加1列“期望結果”。這是twork中一種新的用例編寫模式，叫做測試數(shù)據(jù)驅動模式(TD驅動)，看起來眼熟，其實

11、就是“判定表”，我們以前用Excel寫用例的時候，就是這么寫的，現(xiàn)在在twork中，更進了一步，用戶可以隨意定義每個測試集的列，而每一行，也作為一個用例對象，保存在數(shù)據(jù)庫里。如下圖：需要說明的是，這種復雜的組合，程序是無法自動生成用例的，因為要完全排列組合的話，用例太多，不靠譜，而且具體的組合情況，跟需求有很強的關系，程序更是難以了解。程序能做的是，生成用例表格結構，同時創(chuàng)建一些空白的用例，然后我們自己在里面填一下值就可以了，寫用例速度快，而且用例非常直觀。大家注意到了，在設計圖中，輸入、輸出、實體我們都用不同的標記給標識出來，這樣導入twork時，程序便會自動算出每個邏輯事務的功能點指數(shù)分值

12、，非常方便，所以文章開頭說，這個指數(shù)計算，只是一個副產品。通過上面的分析過程我們可以看出，功能點分析圖與測試用例之間，存在非常緊密的邏輯關系，之前幾篇文章我們也講到，功能點分析是一種非常好的分解分析需求的手段。通過這張分析圖，讀者可以迅速了解設計者的思路，以及了解每個邏輯事務大致的邏輯。這時如果需要看細節(jié)，可以進入twork，很快找到這個邏輯事務的測試集，并查看下面的用例。上面的例子，列舉的是Create類的邏輯事務，以及里面兩種最常見的輸入組合。Update類和Delete類事務，跟這個差不多，這里不再細講。它們的共同點在于，輸入一般較多，并且存在一些邏輯組合，而輸出，相對比較簡單。至于Read類和List類事務，在設計圖會有一些區(qū)別，這兩種邏輯事務輸入相對較少，而輸出項很多，它們主要的測試重點在于，校驗頁面展示，比如“查看寶貝信息”，輸出項可能會有30個以上，這時，使用check list的方式會比較方便，并不用編寫復雜的用例，只需說明，需要校驗哪些點即可。如果Read類事務也有復雜的輸入，比如查看寶貝信息會有：寶貝