功能點算法及在軟件測試中的應用

1、功能點算法及在軟件測試中的應用Mk II功能點算法與MVC模型從這篇文章開始，我會用連載的方式，記錄淘寶測試團隊對功能點算法的研究和實踐過程。從上個世紀70年代開始，一些軟件企業(yè)就開始引入“功能點分析算法”，來評估軟件功能的規(guī)模，然后便可以對軟件開發(fā)的成本和工期，進行精確的度量，也 可以對開發(fā)團隊的生產(chǎn)率進行考核評估。半個世紀以來，很多種不同的功能點算法模型被建立起來，Mk II功能點算法是其中一種比較常用的模型。隨著淘寶網(wǎng)站的高速發(fā)展，淘寶開發(fā)團隊規(guī)模也不斷增大，于是必然要面 對管理問題。人數(shù)的增多必然帶來管理層級的增多，這樣很容易出現(xiàn)管理結構的臃腫，管理成本增高。如果我們引入一種簡單而且科

2、學的工作度量模型，讓每個人每 個團隊的工作質量和效率用數(shù)字來說話，便可以促進管理結構的扁平，簡化管理過程，每個管理者可以管理更多的人，并且對下屬的工作了如指掌。功能點算法就是為了解決如何度量工作效率的問題，而工作質量主要是依靠分析各種Bug數(shù)據(jù)，我們在別的文章里討論。首先我們講一下MVC模型，這是目前web開發(fā)的一種非常流行的軟件架構模式。它把WEB應用程序定義為3個部分，每個部分負責完成特定的任務： Model 模型 View 視圖 Controller 控制器Model主要與數(shù)據(jù)庫交互，把數(shù)據(jù)表轉換成對象，并且實現(xiàn)基本的數(shù)據(jù)讀寫邏輯，比如在淘寶網(wǎng)，商品就是一個Model。View負責實現(xiàn)界

3、面的設計，我們?yōu)g覽網(wǎng)頁看 到的WEB界面控件，比如按鈕、文本框、GRID都是在View中定義的，設計View主要是用Html和JS。用戶在View層進行的各種操作（比如點 擊按鈕），就會啟動Controller里的函數(shù)，主要的業(yè)務邏輯代碼，都寫在Controller里了，其實也就是對各種Model進行增刪改查，比如 購買一個商品。關于MVC的更多詳細說明請參考維基百科。接下來我們介紹MkII功能點算法，淘寶測試選擇MkII的主要原因是，它的算法和MVC模式非常的吻合，可以說是黃金搭檔。MkII功能點算法是這樣：先要給各個功能模塊劃分邏輯事務，然后針對每個邏輯事務，分析輸入DET（Data El

4、ement Type）和輸出DET的數(shù)量，以及關聯(lián)的實體類型數(shù)量，再根據(jù)一個算法公式，計算出功能點指數(shù)：功能點輸入DET0.58實體類型1.66輸出DET0.26邏輯事務指用戶在WEB應用程序中的原子操作。很多開發(fā)團隊都會設計UseCase，一般來說一個UC對應一個邏輯事務。注意：邏輯事務一定是記錄用 戶行為的，而不是程序內部的處理邏輯。不過在實際的分析中，我們發(fā)現(xiàn)邏輯事務的個數(shù)，往往要大于UC的個數(shù)，這是正常的，主要因為很多UC包含的信息很 多。我們用淘寶的“購買商品”來舉例說明怎么劃分邏輯事務，先來看購買商品的頁面：在這個頁面中，左邊一塊是顯示商品的簡要信息，這是一個邏輯事務：“查看商品信

5、息”，右邊最上面一個收貨地址的radio button，也是一個：“展示我所有的收貨地址”，右邊下面一組文本輸入框加一個按鈕，是一個：“為當前商品創(chuàng)建一個訂單”。在MVC中，邏輯事務對應Controller，每個邏輯事務都可以在Controller里面找到一個public函數(shù)。再講一下輸入DET和輸出DET。比如剛才的“為當前商品創(chuàng)建一個訂單”這個事務，頁面上輸入信息的控件，都是輸入DET，比如文本框、按鈕，都是輸 入DET。這個事務大約有10個輸入DET：“收貨地址”、“購買數(shù)量”、“運送方式”等等。輸出DET指應用程序給用戶提供的所有的提示信息，以文字提 示的方式知會用戶。比如“購買成功”

6、、“您沒有綁定支付寶，不能購買”、“商品庫存不足，無法購買”、“購買數(shù)量必須輸入整數(shù)”等等。這個事務的輸出 DET數(shù)量大約是20個。在MVC中，輸入DET和輸出DET對應View。每個輸入DET和輸出DET都能在View中找到對應控件。最后講引用實體，在創(chuàng)建訂單事務里，引用的實體有很多。訂單成功后要扣減商品庫存，因此商品算1個；訂單本身是1個；訂單需要同步生成支付寶交易，支付寶算1個；還有物流記錄算1個，等等，大約是5個實體以上。在MVC中，引用實體對應Model。到此為止這個邏輯事務的數(shù)據(jù)收集完整，代入公式計算得出結果：100.5851.66200.2619.3當然這只是一個DEMO，數(shù)字都

7、是估算的，實際情況肯定比這個要復雜，算出的功能點指數(shù)就會多一些。需要注意的是，使用MkII算法計算出的功能點指 數(shù)，只是一個數(shù)值，代表應用程序的功能規(guī)模，和我們平時聽到開發(fā)說的“我修改了一個功能點”，概念上是不同的。所以我們用“功能點指數(shù)”這個概念，不過為 了溝通起來方便，還是簡化成“功能點”了。MkII功能點算法是非常適合于淘寶這樣的互聯(lián)網(wǎng)公司的。不過由于WEB應用程序的交互日趨復雜，JS被大量使用，因此在實踐中，如何劃分邏輯事務，如何統(tǒng)計輸入輸出，還需要進一步的研究。Mk II功能點算法與MVC模型從這篇文章開始，我會用連載的方式，記錄淘寶測試團隊對功能點算法的研究和實踐過程。從上個世紀7

8、0年代開始，一些軟件企業(yè)就開始引入“功能點分析算法”，來評估軟件功能的規(guī)模，然后便可以對軟件開發(fā)的成本和工期，進行精確的度量，也 可以對開發(fā)團隊的生產(chǎn)率進行考核評估。半個世紀以來，很多種不同的功能點算法模型被建立起來，Mk II功能點算法是其中一種比較常用的模型。隨著淘寶網(wǎng)站的高速發(fā)展，淘寶開發(fā)團隊規(guī)模也不斷增大，于是必然要面對管理問題。人數(shù)的增多必然帶來管理層級的增多，這樣很容易出現(xiàn)管理結構的臃腫， 管理成本增高。如果我們引入一種簡單而且科學的工作度量模型，讓每個人每個團隊的工作質量和效率用數(shù)字來說話，便可以促進管理結構的扁平，簡化管理過程， 每個管理者可以管理更多的人，并且對下屬的工作了如

9、指掌。功能點算法就是為了解決如何度量工作效率的問題，而工作質量主要是依靠分析各種Bug數(shù)據(jù)，我們在別的文章里討論。首先我們講一下MVC模型，這是目前WEB開發(fā)的一種非常流行的軟件架構模式。它把WEB應用程序定義為3個部分，每個部分負責完成特定的任務： Model 模型 View 視圖 Controller 控制器Model主要與數(shù)據(jù)庫交互，把數(shù)據(jù)表轉換成對象，并且實現(xiàn)基本的數(shù)據(jù)讀寫邏輯，比如在淘寶網(wǎng)，商品就是一個Model。View負責實現(xiàn)界面的設 計，我們?yōu)g覽網(wǎng)頁看到的WEB界面控件，比如按鈕、文本框、GRID都是在View中定義的，設計View主要是用Html和JS。用戶在View層進行

10、的各種操作（比如點擊按鈕），就會啟動Controller里的函數(shù)，主要的業(yè)務邏輯代碼，都寫在Controller里了，其實也就是對各種Model 進行增刪改查，比如購買一個商品。關于MVC的更多詳細說明請參考維基百科。接下來我們介紹MkII功能點算法，淘寶測試選擇MkII的主要原因是，它的算法和MVC模式非常的吻合，可以說是黃金搭檔。MkII功能點算法是這樣：先要給各個功能模塊劃分邏輯事務，然后針對每個邏輯事務，分析輸入DET（Data Element Type）和輸出DET的數(shù)量，以及關聯(lián)的實體類型數(shù)量，再根據(jù)一個算法公式，計算出功能點指數(shù)：功能點輸入DET0.58實體類型1.66輸出DET

11、0.26邏輯事務指用戶在WEB應用程序中的原子操作。很多開發(fā)團隊都會設計UseCase，一般來說一個UC對應一個邏輯事務。注意：邏輯事務一定是記錄用 戶行為的，而不是程序內部的處理邏輯。不過在實際的分析中，我們發(fā)現(xiàn)邏輯事務的個數(shù)，往往要大于UC的個數(shù)，這是正常的，主要因為很多UC包含的信息很 多。我們用淘寶的“購買商品”來舉例說明怎么劃分邏輯事務，先來看購買商品的頁面：在這個頁面中，左邊一塊是顯示商品的簡要信息，這是一個邏輯事務：“查看商品信息”，右邊最上面一個收貨地址的radio button，也是一個：“展示我所有的收貨地址”，右邊下面一組文本輸入框加一個按鈕，是一個：“為當前商品創(chuàng)建一個

12、訂單”。在MVC中，邏輯事務對應Controller，每個邏輯事務都可以在Controller里面找到一個public函數(shù)。再講一下輸入DET和輸出DET。比如剛才的“為當前商品創(chuàng)建一個訂單”這個事務，頁面上輸入信息的控件，都是輸入DET，比如文本框、按鈕，都是輸 入DET。這個事務大約有10個輸入DET：“收貨地址”、“購買數(shù)量”、“運送方式”等等。輸出DET指應用程序給用戶提供的所有的提示信息，以文字提 示的方式知會用戶。比如“購買成功”、“您沒有綁定支付寶，不能購買”、“商品庫存不足，無法購買”、“購買數(shù)量必須輸入整數(shù)”等等。這個事務的輸出 DET數(shù)量大約是20個。在MVC中，輸入DET

13、和輸出DET對應View。每個輸入DET和輸出DET都能在View中找到對應控件。最后講引用實體，在創(chuàng)建訂單事務里，引用的實體有很多。訂單成功后要扣減商品庫存，因此商品算1個；訂單本身是1個；訂單需要同步生成支付寶交易，支付寶算1個；還有物流記錄算1個，等等，大約是5個實體以上。在MVC中，引用實體對應Model。到此為止這個邏輯事務的數(shù)據(jù)收集完整，代入公式計算得出結果：100.5851.66200.2619.3當然這只是一個DEMO，數(shù)字都是估算的，實際情況肯定比這個要復雜，算出的功能點指數(shù)就會多一些。需要注意的是，使用MkII算法計算出的功能點指 數(shù)，只是一個數(shù)值，代表應用程序的功能規(guī)模，

14、和我們平時聽到開發(fā)說的“我修改了一個功能點”，概念上是不同的。所以我們用“功能點指數(shù)”這個概念，不過為 了溝通起來方便，還是簡化成“功能點”了。MkII功能點算法是非常適合于淘寶這樣的互聯(lián)網(wǎng)公司的。不過由于WEB應用程序的交互日趨復雜，JS被大量使用，因此在實踐中，如何劃分邏輯事務，如何統(tǒng)計輸入輸出，還需要進一步的研究。劃分邏輯事務在前一篇文章我們講到，“邏輯事務”是統(tǒng)計功能點指數(shù)的最小單元，所以進行科學的劃分，對統(tǒng)計的正確性非常重要。另外，劃分邏輯事務其實也是一個需求 分解的過程，測試工程師可以通過這個過程來分析項目需求，讓需求分析工作更加標準化，同時也降低溝通成本，大家圍繞邏輯事務進行討論

15、。邏輯事務一般描述的是用戶的行為，所以命名一般都是動賓結構，例如“注冊淘寶會員”、“查看寶貝的詳情”。也有少數(shù)的邏輯事務是由一些定時程序產(chǎn)生 的，例如“同步用戶的最新信息”。有的項目會在需求文檔里面專門描述一些“業(yè)務規(guī)則”，注意，規(guī)則不是邏輯事務，規(guī)則一定是依附與某個邏輯事務的，例如 “不準注冊同名的會員”這個規(guī)則其實是屬于“注冊會員”這個邏輯事務。在以數(shù)據(jù)庫為基礎的WEB應用中，邏輯事務一定是對某項數(shù)據(jù)進行的增刪改查操作，也就是我們常說的CRUDL的其中之一。CRUDL分別代表： Create 創(chuàng)建新數(shù)據(jù)（注冊會員） Read 讀取數(shù)據(jù)的信息（查看寶貝） Update 更新數(shù)據(jù)（保存收貨地址

16、） Delete 刪除數(shù)據(jù)（清空購物車） List 列出一批數(shù)據(jù)（各種DataGrid）下面我們對這5種邏輯事務分別進行分析，并且結合具體的案例來看看劃分的規(guī)則。如果邏輯事務劃分正確，后面的計算出現(xiàn)誤差就不會太大。Create每個WEB應用程序，都是從創(chuàng)建數(shù)據(jù)開始的，比如“發(fā)布新寶貝”、“注冊新會員”，創(chuàng)建數(shù)據(jù)會在數(shù)據(jù)表中新增記錄。創(chuàng)建數(shù)據(jù)一般由用戶在頁面上點擊按鈕觸發(fā)，也可能是在請求一個URL的時候觸發(fā)。有時候，用戶在一個頁面點擊“新建”，會同時新建兩個數(shù)據(jù)對象，比如注冊淘寶會員，會同時創(chuàng)建一個支付寶帳號，這里不能算做2個邏輯事務，而只有1個，這個邏輯事務的“實體”是2個。Read讀取數(shù)據(jù)的

17、邏輯事務基本都叫“查看XXX的詳情”，WEB程序會根據(jù)主鍵，把某個數(shù)據(jù)對象select出來，把各個字段的值顯示在頁面上。在分析 Read類邏輯事務時，要對頁面進行分塊分類，因為現(xiàn)在很多WEB頁面，都不是單純顯示一個數(shù)據(jù)，而是用i_f_r_a_m_e的方式，把相關對象都顯示 出來，這里每個對象都是一個獨立的邏輯事務。注意，在一些列表頁面，比如“我購買過的商品”，是用數(shù)據(jù)列表的方式，展示出很多商品，這不屬于Read類邏輯事務，而是屬于List，后面會講到。Read類一般都是展示單體。有些Read類邏輯事務會出現(xiàn)，不同身份的用戶查看同一數(shù)據(jù)對象時，有不同的輸出，比如VIP用戶查看商品時有價格優(yōu)惠。這

18、里不能算作2個邏輯事務： “普通用戶查看商品”“VIP查看商品”，而應該算1個?！坝脩舻慕巧敝皇且粋€輸入DET。不過，如果普通用戶和VIP用戶查看商品，完全是兩個不同的 頁面（View不同），那就要算2個邏輯事務了。Update這類邏輯事務是對已經(jīng)存在的數(shù)據(jù)進行更新，一般叫做“保存XXX信息”，不過在某些場景，Update邏輯事務有很多其他的命名，例如“為訂單付款”，實際上是更新了訂單對象的狀態(tài)，因此歸于Update類。在一些信息的保存頁面，例如“保存我的收貨地址”頁面，用戶需要先打開某個收貨地址的詳情頁面，然后再進行保存，那么這個詳情頁面，要算作一個Read類邏輯事務，用戶點擊按鈕保存，算

19、作一個Update類邏輯事務。Delete刪除類邏輯事務出現(xiàn)的不多，一般都是用戶點擊“刪除”按鈕，把一個或者幾個數(shù)據(jù)對象刪除。老規(guī)矩，如果用戶一次點擊，刪除一個對象的同時，又級聯(lián)刪除 了這個對象相關的另一個對象的話，只算作一個邏輯事務，實體是2個。刪除時一般都會彈出一個對話框，讓用戶確認，這個確認不算邏輯事務。List此類邏輯事務最常出現(xiàn)的形態(tài)是DataGrid數(shù)據(jù)表格，例如上文說的“列出我購買過的商品”。這個控件在WEB應用程序中被使用的非常多，它用一種 格式在一個頁面展示出多個數(shù)據(jù)對象，并且把這些對象的關鍵屬性（名稱、類型）顯示出來。除了DataGrid，樹型控件也是一個List類的邏輯事

20、務。此 外，頁面中展示對象的下拉菜單、RadioButton，也要作為單獨的邏輯事務來計算，不過前提示，它們顯示的是數(shù)據(jù)對象，如果是“男/女”這樣的 RadioButton，不是邏輯事務，而購買商品時，選擇的“收貨地址列表”則是邏輯事務。有一些DataGrid控件，支持用戶直接在表格里修改數(shù)據(jù)，這里的修改功能要單獨作為Update類邏輯事務計算，與上文有一點不同的是，不需要另算Read類邏輯事務了。到這里我們對這5類邏輯事務都分析清楚了，大家劃分邏輯事務時，還要明確一個原則，每個邏輯事務的實體個數(shù)、輸入DET個數(shù)、輸出DET個數(shù)都不能是 0，否則就不算邏輯事務。例如，有的頁面上設計一個按鈕，用

21、戶點擊后，跳轉到另一個頁面，這種單純的跳轉，不是邏輯事務。邏輯事務都是對數(shù)據(jù)對象的操作。 大部分情況下，數(shù)據(jù)對象都在數(shù)據(jù)庫中，也有一些情況，數(shù)據(jù)對象是文件對象，比如上傳圖片，圖片本身就是實體對象。以上所列出的，都是常見的邏輯事務案例，在真實項目中，還可能會遇到一些其他的情況，大家只要根據(jù)邏輯事務的判定原則，進行推理，就可以很好的把邏輯事務劃分清楚了。最后，要說一下測試用例設計。非常相似的，測試用例也是圍繞邏輯事務來設計的。在組織用例分類時，基本遵循“項目功能模塊邏輯事務”這種目錄結構。每個邏輯事務的用例，都擁有類似的前置條件、操作步驟、校驗方法，所以組織在一起設計，是非常科學的。計算邏輯事務的

22、實體、輸入DET、輸出DET前一篇文章（Part2）介紹了如何劃分邏輯事務，文章發(fā)表后，大家提出了很多非常好的問題，我這里先簡單回復一下，作為我們Part3的引子。Q：邏輯事務分解對于那種“增刪改查”類型的功能點比較適用，但是流程類的功能點，就不合適了吧？A：就拿交易流程來說好了，我們在設計交易流程的TC時，是把下單、付款、發(fā)貨、確認等操作，分別進行設計的，這些操作，其實都是單獨的邏輯事務，實際上，開發(fā)在設計程序的時候，也是分開做的，不可能全寫在一個函數(shù)里面。Q：我發(fā)現(xiàn)有的邏輯事務，比如點擊一個按鈕以后，程序既做了查，又做了改，按照你Part2里的分類，是不是應該算兩個邏輯事務。A：這個怪我沒

23、說清楚，這應該是算一個邏輯事務，他可以同時包含多個CRUD的action。Q：我們以前設計TC很多都是基于一個頁面的，現(xiàn)在按照這種方式，一個頁面會分解成多個邏輯事務，這樣感覺會比較零散。A：測試設計和測試執(zhí)行是有區(qū)別的，測試設計的目標是把被測系統(tǒng)分析清楚，并不是編寫出完整的執(zhí)行腳本，實際上在測試執(zhí)行過程中，有經(jīng)驗的測試工程師是會把幾個邏輯事務放在一起測，效率極高。好，問題先討論到這里，下面我們開始正題，如何計算每個邏輯事務的實體、輸入和輸出。這篇文章我們仍然會分別對CRUDL這五類邏輯事務進行分析，因為他們的輸入和輸出的特點，各有不同。不過，對于“實體”的計算，各類邏輯事務的計算方法相同，所以

24、先單獨講一下實體。淘寶系統(tǒng)里存在下面這些實體：會員、寶貝、交易記錄、寶貝類目、評價記錄、店鋪等等。實體的英文原名是Entity Type，也就是我們平時討論中經(jīng)常出現(xiàn)的“對象”，經(jīng)常接觸代碼的工程師會在代碼里發(fā)現(xiàn)很多“xxxDO”，比如UserDO、OrderDO，這些和 實體是完全對應的。另外還有一個簡單的辦法來識別實體，就是看數(shù)據(jù)庫的表，一般一個實體肯定至少對應一張表，比如會員這個實體在數(shù)據(jù)庫里，必然有一張 users表。分析一個邏輯事務有哪些實體，是分析的第一步，也是最重要的一步。實體越多，開發(fā)和測試的復雜度越高。從MkII算法里也能看出，實體的系數(shù)是 1.66，遠高于輸入和輸出。另外，

25、分析實體可以幫助測試工程師搞清楚，這個事務的范圍，對事務有一個全局的概念。分析完后，測試工程師一般會這么說： “哦，這個事務跟這幾個對象有關！”在新人學習和測試設計評審中，實體的分析也能起到非常大的幫助作用。下面開始分類講CRUDL的輸入和輸出：Create注冊會員、發(fā)布新寶貝，這都屬于Create類型邏輯事務，這類事務一般都有一個內容較多的“表單”，里面有一些輸入框、checkbox、 radiobutton和一個確認提交按鈕，這里的每個控件，都要計算為1個輸入DET。需要注意，radio控件一般會有多個選項，不能算多個輸入，而 只能算一個；提交按鈕也要算1個輸入。除了這些頁面控件類輸入，還

26、有一類輸入，是“隱含”的。比如賣家在發(fā)布新寶貝時，賣家自己的userid就是一個輸 入，因為在發(fā)布成功后，這個寶貝會擁有賣家的userid，只是這個id并不需要賣家填寫，而是放在系統(tǒng)緩存里。雖然是隱含輸入，卻也參與了邏輯運算，因 此要計數(shù)。這是Create的兩類輸入。Create事務的輸出一般會有以下一些信息，“注冊成功”、“此會員名已被人注冊”、“密碼太短”。當用戶試圖執(zhí)行這個事務，系統(tǒng)給用戶所有可能的 提示信息，都要記為一個輸出。有些輸出跟某個輸入，有直接的邏輯關系，比如“此會員名已被人注冊”只跟“會員名”輸入框里所填的信息有關，有的輸出，則是 由好幾個輸入組合在一起，才能出現(xiàn)，分析的時候

27、，需要弄明白，不過這點區(qū)別不影響計數(shù)。如果把邏輯事務看成一個“函數(shù)”，那么輸入就可以抽象為函數(shù)的輸入?yún)?shù)，而輸出就是函數(shù)的所有可能性的返回值，以及函數(shù)拋出的各種異常。后面幾類邏輯事務，也可以抽象為這種定義，大家后面自己推理試一試。ReadRead類事務是讀取一個對象的詳細信息，比如我們查看一個寶貝的詳細信息。它的輸入個數(shù)一般比較少，其中最基本的，就是這個對象的主鍵id，比如寶 貝的id。如果不同類型的用戶查看寶貝時，會有不同的顯示信息，那么用戶的userid和用戶類型這2個要記為輸入。如果寶貝的某些屬性會影響顯示，比如 鞋城寶貝會有個圖標，那么輸入也要+1。其實如果業(yè)務邏輯復雜，輸入也不少。我

28、們可以把這些輸入抽象的稱為“影響對象顯示的一些屬性”。一般來說Read的輸出都比較多，這個對象能顯示在頁面上的屬性，都要記為輸出，比如“寶貝名稱”、“價格”、“顏色”等等。除了文字類，圖片也是輸 出，比如寶貝的縮略圖和表示寶貝屬性的一些小圖標，都算。另外，有的圖片和Label有鏈接，這里的鏈接要單獨算輸出，因為一個純文本，肯定沒有一個附帶 http鏈接的文本信息量多。UpdateUpdate事務的輸入和輸出數(shù)量可多可少，關鍵看系統(tǒng)Update的規(guī)模，比如“編輯寶貝”跟“發(fā)布新寶貝”相比，輸入輸出的數(shù)量都非常多。像“修 改我的登錄密碼”這樣的，數(shù)量就非常少了。Update事務的輸入輸出識別，與C

29、reate類非常相似，因為大部分Update事務也是表單提交的方式。這里需要注意的是，系統(tǒng)中會存在一些“不起眼”的Update事務，分析時千萬別漏了。比如大部分會員有多個收貨地址，然后在列表中有一個鼠標懸停出 現(xiàn)的“設置為默認收獲地址”的按鈕，當用戶點擊的時候，只是修改收獲地址的一個屬性，非常的隱蔽。這也是一個邏輯事務，它的輸入是用戶id，收貨地址 id，輸出只有1個，就是點擊按鈕后，系統(tǒng)提示修改成功，非常簡單，但是不要遺漏。DeleteDelete類事務的分析相對簡單一些，多數(shù)刪除功能，都是直接對數(shù)據(jù)進行刪除，因此輸入一般就是數(shù)據(jù)主鍵id這1個。不過，有一些數(shù)據(jù)在刪除前，需 要先做一些邏輯判

30、斷，看看能不能刪，這樣輸入就多了，相應的實體也會增加。比如，“已經(jīng)發(fā)布的寶貝不能刪除”，那么“寶貝發(fā)布狀態(tài)”就是1個輸入，“已經(jīng) 有交易的寶貝不能刪除”，那么實體就不僅僅是寶貝，還有交易記錄，輸入也要增加“交易記錄id”；如果規(guī)則更復雜“有未完成交易的寶貝不能被刪除”，那么 輸入還要增加“交易狀態(tài)”，依此類推。ListList事務是一個重點，最后講，它的輸入輸出計算比較復雜，而且多變，所以大家不僅要理解我下面講的東西，還要能自己推理，分析自己實際遇到的各種 List。List事務實質上跟Read很像，不同在于Read只看1個對象，List要看多個。首先看最常出現(xiàn)的List事務：DataGrid

31、，這種 控件一般是一個二維表格，它的輸入與Read類似，比如我的訂單列表的輸入是會員userid，我的已買到訂單列表還要增加訂單類型這個輸入，我的近3個 月已買到訂單再加訂單時間，等等。有些列表上方，會有查詢功能，比如按照名稱查詢，這些查詢項會影響列表的顯示數(shù)據(jù)，因此是輸入。大家如果想象一下這個列 表對應的sql語句，就好理解了，where后面跟的都是輸入。DataGrid里的輸出比較直觀，每一列就是一個輸出，對應sql語句里的select后面的字段，注意，有些列顯示的不僅僅是文字，還有圖片，顏色，這些都要單獨計數(shù)。對于DataGrid來說最糾結的要屬“翻頁”和“排序”功能，這究竟是算輸入還是

32、輸出呢？經(jīng)過推理我們發(fā)現(xiàn)，翻頁功能對顯示的數(shù)據(jù)是有影響的，比如 我翻到第二頁（假設每頁10個數(shù)據(jù)對象），很多程序會控制從數(shù)據(jù)庫里讀取的數(shù)據(jù)，只取出第11到20的數(shù)據(jù)，也是在sql的where后面加條件，所以， 翻頁屬于輸入的計數(shù)，流行的翻頁一般是“上一頁”“下一頁”這樣的按鈕或者是直接輸入數(shù)字翻頁，只要出現(xiàn)1種，輸入+2，要是兩種都有，+4。再說說排 序，排序對應的sql標記是order by，不是select也不是where，比較另類，究竟算哪邊合適呢？在MkII的相關資料里也沒有找到答案。通過比較發(fā)現(xiàn)order的操作與 where更接近一些，相似度更大，都是影響數(shù)據(jù)的檢索范圍，因此我們把排

33、序也認定為輸入。DataGrid如果有1列提供排序功能，那么輸入+1，多列 的話，依此類推。前文曾經(jīng)提到過，顯示數(shù)據(jù)對象的radio控件，也是List類的事務，它的輸入，就是顯示這些數(shù)據(jù)的條件。比如買家購買商品時，有個收貨地址的 radio控件，因為是“我的”地址，所以userid是1個輸入。輸出就要看這個radio展示了數(shù)據(jù)對象的哪些屬性，有幾個算幾個。比如收貨地址的姓 名、省、市、區(qū)、郵編，這些都是不同的字段，但是在radio里全部拼在一起，要算5個輸出。還有一類控件使用也較多，就是樹形控件，這也是List類的邏輯事務。輸入算法就不說了，同上，重點說輸出。樹形控件里的每個節(jié)點，一般都是一個

34、數(shù)據(jù) 對象，節(jié)點會有名稱、顏色、加粗、小圖標這么幾種顯示元素，用來表示數(shù)據(jù)對象的屬性，這些都是輸出，單獨計數(shù)。樹形控件有特殊的展開、折疊功能，這個不太 好分類，我們直接規(guī)定，輸出+4，因為在折疊上我們需要投入一點測試成本。如果一棵樹里展示了兩種數(shù)據(jù)對象，別忘了實體要+1。List的例子我們就講3個，大家還有可能遇到各種五花八門的List邏輯事務，只要掌握這個原則：輸入會影響顯示數(shù)據(jù)的范圍，而輸出是展示數(shù)據(jù)的各個屬性。大家只要掌握規(guī)律，細心推理，遇到問題方可迎刃而解。Part3的主要內容都講完了，最后，講一下功能點估算的技巧。想要算出一個項目的功能點規(guī)模，并不一定要把每個邏輯事務的分值都精確的計

35、算出來。大 家可以先把邏輯事務進行分類，可以按照CRUDL分類，也可以按照你自己的經(jīng)驗分類，然后挑選一些重要的，典型的邏輯事務，進行仔細的計算，再給每個類型 的邏輯事務一個平均的估算值，這樣總分就很快可以算出了。如果你需要盡快算出總分，可以參考這種做法。使用功能點分析來設計測試用例最近有位同事問我，“天彤你搞這個功能點分析算法，主要目的是度量project的規(guī)模么，還是度量測試工程師的工作量？”我說，這兩個確實是最初的 目標，不過現(xiàn)在，這只是功能點算法的副產(chǎn)品，并不是核心價值。“那是不是根據(jù)功能點分析，可以自動生成測試用例呢？”這的確是一個很誘人的功能，而且隨著 進一步研究發(fā)現(xiàn)，先用freem

36、ind進行功能點分析，然后自動生成一部分測試用例，是完全可行的，不過這仍然是副產(chǎn)品，不是最核心的目標。功能點分析法應用在軟件測試中，它最核心的價值究竟是什么呢？讓我們先看看軟件開發(fā)，這是跟測試離得最近的工作類型。開發(fā)工程師工作大致可以分為“設計”和“編碼”兩步。設計一般是使用UML語言，借助類似于Rose這樣的工具，繪制一些UC圖、類圖、ER圖等等。這些設計圖決定了最終的編碼該如何實施。另外，當其他的開發(fā)工程師需要了解這個project時（例如評審），ta會先看設計文檔，從設計文檔中掌握開發(fā)思路，然后再閱讀代碼，了解細節(jié)。由于UML語言中，包含了大量的約定和規(guī)則，因此開發(fā)工程師只需要花費較少的工作量，就能表達出充足的信息。而閱讀UML設計文檔的其他人，也能很快 從UML設計中了解設計人員的思路。試想一下，如果讓讀者直接看代碼，需要花費多少倍的時間，才能達到相同的目的。這就是設計模型的價值，不僅幫助設計人 員自己整理思路，也幫助其他讀者快速交流信息。對于軟件測試來說，也有“設計”和“編碼（實施）”兩個階段的工作。設計是我們設計測試用例的過程，也就是我們考慮如何做；實施就是我們執(zhí)行測試的過 程，有時是手工執(zhí)行，有時是寫腳本讓計算機執(zhí)行。因此，測試用例是我們的“設計文檔”，是我們交流測試方法，評審測試方案的核心。但是只依靠測試用例，我 們感覺存在很多問題： 測試用例數(shù)量多，難以閱