从这篇文章开始，我会用连载的方式，记录淘宝测试团队对功能点算法的研究和实践过程。
从上个世纪70年代开始，一些软件企业就开始引入“功能点分析算法”，来评估软件功能的规模，然后便可以对软件开发的成本和工期，进行精确的度量，也可以对开发团队的生产率进行考核评估。半个世纪以来，很多种不同的功能点算法模型被建立起来，Mk II功能点算法是其中一种比较常用的模型。
随着淘宝网站的高速发展，淘宝开发团队规模也不断增大，于是必然要面对管理问题。人数的增多必然带来管理层级的增多，这样很容易出现管理结构的臃肿，管理成本增高。如果我们引入一种简单而且科学的工作度量模型，让每个人每个团队的工作质量和效率用数字来说话，便可以促进管理结构的扁平，简化管理过程，每个管理者可以管理更多的人，并且对下属的工作了如指掌。
功能点算法就是为了解决如何度量工作效率的问题，而工作质量主要是依靠分析各种Bug数据，我们在别的文章里讨论。
首先我们讲一下MVC模型，这是目前WEB开发的一种非常流行的软件架构模式。它把WEB应用程序定义为3个部分，每个部分负责完成特定的任务：
- Model 模型
- View 视图
- Controller 控制器
关于MVC的更多详细说明请参考维基百科。
接下来我们介绍MkII功能点算法，淘宝测试选择MkII的主要原因是，它的算法和MVC模式非常的吻合，可以说是黄金搭档。
MkII功能点算法是这样：先要给各个功能模块划分逻辑事务，然后针对每个逻辑事务，分析输入DET（Data Element Type）和输出DET的数量，以及关联的实体类型数量，再根据一个算法公式，计算出功能点指数：
功能点＝输入DET×0.58＋实体类型×1.66＋输出DET×0.26
逻辑事务指用户在WEB应用程序中的原子操作。很多开发团队都会设计UseCase，一般来说一个UC对应一个逻辑事务。注意：逻辑事务一定是记录用户行为的，而不是程序内部的处理逻辑。不过在实际的分析中，我们发现逻辑事务的个数，往往要大于UC的个数，这是正常的，主要因为很多UC包含的信息很多。
我们用淘宝的“购买商品”来举例说明怎么划分逻辑事务，先来看购买商品的页面：
在这个页面中，左边一块是显示商品的简要信息，这是一个逻辑事务：“查看商品信息”，右边最上面一个收货地址的radio button，也是一个：“展示我所有的收货地址”，右边下面一组文本输入框加一个按钮，是一个：“为当前商品创建一个订单”。
在MVC中，逻辑事务对应Controller，每个逻辑事务都可以在Controller里面找到一个public函数。
再讲一下输入DET和输出DET。比如刚才的“为当前商品创建一个订单”这个事务，页面上输入信息的控件，都是输入DET，比如文本框、按钮，都是输入DET。这个事务大约有10个输入DET：“收货地址”、“购买数量”、“运送方式”等等。输出DET指应用程序给用户提供的所有的提示信息，以文字提示的方式知会用户。比如“购买成功”、“您没有绑定支付宝，不能购买”、“商品库存不足，无法购买”、“购买数量必须输入整数”等等。这个事务的输出DET数量大约是20个。
在MVC中，输入DET和输出DET对应View。每个输入DET和输出DET都能在View中找到对应控件。
最后讲引用实体，在创建订单事务里，引用的实体有很多。订单成功后要扣减商品库存，因此商品算1个；订单本身是1个；订单需要同步生成支付宝交易，支付宝算1个；还有物流记录算1个，等等，大约是5个实体以上。
在MVC中，引用实体对应Model。
到此为止这个逻辑事务的数据收集完整，代入公式计算得出结果：
10×0.58＋5×1.66＋20×0.26＝19.3
当然这只是一个DEMO，数字都是估算的，实际情况肯定比这个要复杂，算出的功能点指数就会多一些。需要注意的是，使用MkII算法计算出的功能点指数，只是一个数值，代表应用程序的功能规模，和我们平时听到开发说的“我修改了一个功能点”，概念上是不同的。所以我们用“功能点指数”这个概念，不过为了沟通起来方便，还是简化成“功能点”了。
MkII功能点算法是非常适合于淘宝这样的互联网公司的。不过由于WEB应用程序的交互日趋复杂，JS被大量使用，因此在实践中，如何划分逻辑事务，如何统计输入输出，还需要进一步的研究。
----------------------------------------------------------------------------
转自：http://www.cnblogs.com/powerson/archive/2010/12/01/2033493.html
