1、 概念介紹
首先隆重介紹下FPA（Function Point Analysis）
FPA是一種相對抽象的方法,是一種”人爲設計”出的度量方式,主要解決如何客觀,公正,可重複地對軟件地規模進行度量的問題。不管它有什麼用，反正它可以度量軟件規模，知道這一點就可以了。具體來講它可以用於“需求文檔”、“設計文檔”、“源代碼”、“測試用例”等的度量。
FPA首先由IBM工程師艾倫 · 艾爾布策 (Allan Albrech) 於 20 世紀 70 年代提出，隨後被國際功能點用戶協會(IFPUG：The International Function Point Users' Group) 提出的 IFPUG 方法繼承。經由ISO組織已經有多種功能點估算成爲國際標準，如① 加拿大人艾倫 · 艾布恩 (Alain Abran) 等人提出的全面功能點法 (full function points) ； ②英國軟件度量協會 (UKSMA ： United Kingdom Software Metrics Association) 提出的 IFPUG 功能點法 (IFPUG function points) ； ③ 英國軟件度量協會提出的 Mark II FPA 功能點法 (Mark II function points) ； ④ 荷蘭功能點用戶協會 (NEFPUG：Netherlands Function Point Users Group) 提出的 NESMA 功能點法，以及軟件度量共同協會(COSMIC：the Common Software Metrics Consortium) 提出的 COSMIC-FFP 方法，這些方法都屬於艾爾布策功能點方法的發展和細化。
其次讓我更隆重的介紹下Mark II FPA
Mark II是一種FPA，這個我們已經介紹過了。
它的算法是這樣的：先要給各個功能模塊劃分邏輯事務，然後針對每個邏輯事務，分析輸入DET（Data Element Type）和輸出DET的數量，以及關聯的實體類型數量，再根據一個算法公式，計算出功能點指數：
功能點＝輸入DET×0.58＋實體類型×1.66＋輸出DET×0.26
下面從Web應用程序的角度簡單介紹下這裏面的相關概念
邏輯事務：指用戶在web應用程序中的原子操作，它一定要記錄用戶行爲的，而不是程序內部的處理邏輯。在以數據庫爲基礎的的web應用程序中，邏輯事務一定是對某項數據進行的增刪改查操作。
輸入DET：MVC模型中，頁面上的輸入信息的控件都是輸入DET，如文本框、按鈕等。
輸出DET：指應用程序給用戶提供的所有的提示信息。
實體：大家應該都很熟悉，跟我們程序設計中的實體一個概念，不做解釋了。
大家可能好奇計算公式中的數字是如何來的，其實這不重要，只要標準統一了，使計算出來的軟件規模具有可比性就行了。我們一定要明白，度量不是目的，單個的度量結果也沒有意義，度量軟件規模是爲了估算工作量。維基百科上也只是說，推薦用這個數字。可見，這並不重要。http://en.wikipedia.org/wiki/MK_II_FPA ，但是爲了使我們估算的測試工作量在行業中比較的時候省去不必要的麻煩（因爲不一致還要轉換），還是用推薦的好點。
想了解更多有關MK II FPA的信息，請下載：
http://www.eee.metu.edu.tr/~bilgen/MARK%20II%20FP%20Guide.pdf
2、 Mk II功能點算法在測試中的應用
咱們在工作中可能會碰到如下問題：
測試XX模塊需要多長時間？
測試用例到底該如何編寫？
我認爲應用MK II功能點分析法可以估算測試工作量，在組織和編寫指導測試用例的時候可以作爲一種參考。
估算測試工作量
a、 用MK II分析、計算某個模塊的功能點指數值，記錄測試時間。將這個功能點指數和測試時間作爲標準。S=模塊測試時間/模塊功能點指數值
b、 對需要測試的模塊應用MK II分析、計算功能點指數值，假設爲V，則測試時間T=V*S。
例如：
我對動易商城後臺“促銷方案管理”功能粗略計算，功能點=輸入DET*0.58+實體類型*1.66+輸出DET*026=26*0.58+2*1.66+39*0.26=17.51，全面測試一下，測試時間大概爲5個小時。包括測試用例編寫和執行測試用例一次。
如果要測試後臺添加商品功能我們能大概估算出測試時間，首先計算功能
點=73*0.58+4*1.66+73*2*0.26=42.34+6.64+37.96=86.94，測試時間大約爲24小時。
不要對這個估算時間懷疑，我們可能會想，這個商品與其他模塊關聯的地方很多，這點時間不夠！這裏就涉及一個估算範圍問題，如果要測試與之關聯的模塊，那要把其他模塊的測試時間也估算出來。我們已經站在對數據的存取角度估算了，只要保證在這個模塊中存入的數據是正確的，那麼引用的時候不正確，也不會是這個模塊的問題。
在編寫測試用例中的應用
測試用例一直在寫，說實話剛開始寫得不怎樣，但是一直在改進。剛開始是整個頁面考慮，一個步驟實際上包含了若干步驟，實用性很差。測試用例要儘可能細，每一操作對應一個步驟，這是我研究自動化測試的時候得出來的結論。
有人總結設計測試用例有四條基本原則：
單個用例覆蓋最小化原則
測試用例替代產品文檔功能原則
執行成本最小原則
使測試結果分析和調試最簡單化原則
總結的非常好，也很有用。
具體參見：http://blog.csdn.net/quicknet/archive/2011/01/01/6111882.aspx
但是還是缺少點什麼，寫測試用例還是不順手。如果我們從邏輯事務角度考慮測試用例的編寫，一切都迎刃而解，什麼原則都覆蓋到。邏輯事務是原子操作，記錄用戶行爲，我們做功能測試就是模擬用戶行爲，在以數據庫爲基礎的web應用程序中，本質就是對數據的增刪改查。如此，我們要寫測試用例，先分析邏輯事務，一個邏輯事務可以簡單的對應一個測試用例，即一個用例包含一次對數據庫的操作。
MK II應用很重要、很有用的參考資料：
http://qa.taobao.com/?s=%E5%8A%9F%E8%83%BD%E7%82%B9%E7%AE%97%E6%B3%95
有興趣的可以看一下
