功能点算法及在软件测试中的应用.docx

1、Mk II 功能点算法与 MVC 模型从这篇文章开始，我会用连载的方式，记录淘宝测试团队对功能点算法的研究和实践过程。从上个世纪70 年代开始，一些软件企业就开始引入“功能点分析算法”，来评估软件功能的规模，然后便可以对软件开发的成本和工期，进行精确的度量，也 可以对开发团队的生产率进行考核评估。半个世纪以来，很多种不同的功能点算法模型被建立起来，Mk II 功能点算法是其中一种比较常用的模型。随着淘宝网站的高速发展，淘宝开发团队规模也不断增大，于是必然要面 对管理问题。人数的增多必然带来管理层级的增多，这样很容易出现管理结构的臃肿，管理成本增高。如果我们引入一种简单而且科学的工作度量模型，让

2、每个人每 个团队的工作质量和效率用数字来说话，便可以促进管理结构的扁平，简化管理过程，每个管理者可以管理更多的人，并且对下属的工作了如指掌。功能点算法就是为了解决如何度量工作效率的问题，而工作质量主要是依靠分析各种Bug 数据，我们在别的文章里讨论。首先我们讲一下 MVC模型，这是目前 开发的一种非常流行的 软件架构模式。它把 WEB应用程序定义为 3 个部分，每个部分负 责完成特定的任务： Model 模型 View 视图 Controller 控制器Model主要与数据库交互，把数据表转 换成对象，并且实现基 本的数据读写逻辑，比如在淘宝网，商品就是一个 Model。View 负责实现界面

3、的设计，我们浏览看 到的 WEB界面控件，比如按钮、文本框、GRID 都是在 View 中定义的，设计 View 主要是用Html 和JS。用户在 View 层进行的各种操作（比如点 击按钮） ，就会启动 Controller 里的函数，主要的业务逻辑代码，都写在 Controller 里了，其实也就是对各种 Model 进行增删改查，比如 购买一个商品。关于 MVC的更多详细说明请参考 维基百科。接下来我们介绍 MkII 功能点算 法，淘宝测试选择 MkII的主要原因是，它的算法和MVC模式非常的吻合，可以说是黄金搭档。MkII 功能点算法是这样：先要给各个 功能模块划分逻辑事务，然后针对每

4、个逻辑事务，分析输入 DET（ Data Element Type）和输出 DET 的数量，以及关联的实体类型数量，再根据一个算法公式，计算出功能点指数：功能点输入 DET0.58实体类型 1.66输出 DET0.26逻辑事务指用户在 WEB 应用程序中的原子操作。很多开发团 队都会设计UseCase，一般来说一个 UC 对应一个逻辑事 务。注意：逻辑事务一定是记录用 户行为的，而不是程序内部的处理逻辑。不过在实际的分析中，我们发现逻辑事务的个数，往往要大于UC 的个数，这是正常的，主要因为很多 UC 包含的信息很 多。我们用淘宝的“购买商品”来举例说明怎么划分逻辑事务，先来看购买商品的页面：

5、在这个页面中，左边一块是显示商品的简要信息，这是一个逻辑事务：“查看商品信息”，右边最上面一个收货地址的 radio button，也是一个：“展示我所有的收货地址” ，右边下面一组文本输入框加一个按钮，是一个：“为当前商品创建一个订 单” 。在 MVC 中 ，逻辑事务对 应 Controller，每个逻辑事务都可以在Controller里面找到一个public 函数。再讲一下输入 DET 和输出 DET。比如刚才的“为当前商品创建一个订单”这个事务，页面上输入信息的控件，都是输入 DET，比如文本框、按钮，都是输 入 DET。这个事务大约有 10 个 输入 DET：“收货地址”、 “购买数量

6、”、 “运送方式” 等等。输出 DET指应用程序给用户提供的所有的提示信息，以文字提 示的方式知会用户。比如 “购买成功”、 “您没有绑定支付宝，不能购买”、 “商品库存不足，无法购买” 、 “购买数量必须输入整数”等等。这个事务的输出 DET 数量大约是 20个。在 MVC 中 ，输入 DET和输出 DET 对应 View。每个输入 DET 和输出DET 都能在 View中找到对应控件。最后讲引用实体，在创建订单事务里，引用的实体有很多。订单成功后要扣减商品库存，因此商品算1 个；订单本身是 1 个；订单需要同步生成支付 宝交易，支付宝算 1个；还有物流记录算 1 个，等等，大约是 5 个实

7、体以上。在 MVC 中 ，引用实体对 应 Model。到此为止这个逻辑事务的数据收集完整，代入公式计算得出结果：100.5851.66200.26 19.3当然这只是一个 DEMO，数字都是估 算的，实际情况肯定比这个要复杂，算出的功能点指数就会多一些。需要注意的是，使用 MkII 算法计算出的功能点指 数，只是一个数值，代表应用程序的功能规模，和我们平时听到开发说的“我修改了一 个功能点” ，概念上是不同的。所以我们用“功能点指数”这个概念，不过为 了沟通起来方便，还是简化成“功能点”了。MkII 功能点算法是非常适合于 淘宝这样的互联网公司的。不过由于 WEB 应用程序的交互日趋复杂，JS

8、 被大量使用，因此在实践中，如何划分逻辑事务，如何统计输入输出，还需要进一步的研究。 Mk II 功能点算法与 MVC 模型从这篇文章开始，我会用连载的方式，记录淘宝测试团队对功能点算法的研究和实践过程。从上个世纪70 年代开始，一些软件企业就开始引入“功能点分析算法”，来评估软件功能的规模，然后便可以对软件开发的成本和工期，进行精确的度量，也 可以对开发团队的生产率进行考核评估。半个世纪以来，很多种不同的功能点算法模型被建立起来，Mk II 功能点算法是其中一种比较常用的模型。随着淘宝网站的高速发展，淘宝开发团队规模也不断增大，于是必然要面对管理问题。人数的增多必然带来管理层级的增多，这样很

9、容易出现管理结构的臃肿， 管理成本增高。如果我们引入一种简单而且科学的工作度量模型，让每个人每个团队的工作质量和效率用数字来说话，便可以促进管理结构的扁平，简化管理过程， 每个管理者可以管理更多的人，并且对下属的工作了如指掌。功能点算法就是为了解决如何度量工作效率的问题，而工作质量主要是依靠分析各种Bug 数据，我们在别的文章里讨论。首先我们讲一下 MVC模型，这是目前 WEB 开发的一种非常流行的软件架构模式。它把 WEB应用程序定义为 3 个部分，每个部分负责完成特定的任务： Model 模型 View 视图 Controller 控制器Model主要与数据库交互，把数据表转 换成对象，并

10、且实现基 本的数据读写逻辑，比如在淘宝网，商品就是一个 Model。View 负责实现界面的设 计，我们浏览网页看到的WEB 界面控件，比如按钮、文本框、GRID 都是在 View 中定义的，设计 View 主要是用Html和JS。用户在 View 层进行 的各种操作（比如点击按钮） ，就会启动 Controller 里的函数，主要的业务逻辑代码，都写在 Controller 里了，其实也就是 对各种 Model 进行增删改查，比如购买一个商品。关于 MVC的更多详细说明请参考 维基百科。接下来我们介绍 MkII 功能点算 法，淘宝测试选择 MkII的主要原因是，它的算法和MVC模式非常的吻合

11、，可以说是黄金搭档。MkII 功能点算法是这样：先要给各个 功能模块划分逻辑事务，然后针对每个逻辑事务，分析输入 DET（ Data Element Type）和输出 DET 的数量，以及关联的实体类型数量，再根据一个算法公式，计算出功能点指数：功能点输入 DET0.58实体类型 1.66输出 DET0.26逻辑事务指用户在 WEB 应用程序中的原子操作。很多开发团 队都会设计UseCase，一般来说一个 UC 对应一个逻辑事 务。注意：逻辑事务一定是记录用 户行为的，而不是程序内部的处理逻辑。不过在实际的分析中，我们发现逻辑事务的个数，往往要大于UC 的个数，这是正常的，主要因为很多 UC

12、包含的信息很 多。我们用淘宝的“购买商品”来举例说明怎么划分逻辑事务，先来看购买商品的页面：在这个页面中，左边一块是显示商品的简要信息，这是一个逻辑事务：“查看商品信息”，右边最上面一个收货地址的 radio button，也是一个：“展示我所有的收货地址” ，右边下面一组文本输入框加一个按钮，是一个：“为当前商品创建一个订 单” 。在 MVC 中 ，逻辑事务对 应 Controller，每个逻辑事务都可以在Controller里面找到一个public 函数。再讲一下输入 DET 和输出 DET。比如刚才的“为当前商品创建一个订单”这个事务，页面上输入信息的控件，都是输入 DET，比如文本框、

13、按钮，都是输 入 DET。这个事务大约有 10 个 输入 DET：“收货地址”、 “购买数量”、 “运送方式” 等等。输出 DET指应用程序给用户提供的所有的提示信息，以文字提 示的方式知会用户。比如 “购买成功”、 “您没有绑定支付宝，不能购买”、 “商品库存不足，无法购买” 、 “购买数量必须输入整数”等等。这个事务的输出 DET 数量大约是 20个。在 MVC 中 ，输入 DET和输出 DET 对应 View。每个输入 DET 和输出DET 都能在 View中找到对应控件。最后讲引用实体，在创建订单事务里，引用的实体有很多。订单成功后要扣减商品库存，因此商品算1 个；订单本身是 1 个；

14、订单需要同步生成支付 宝交易，支付宝算 1个；还有物流记录算 1 个，等等，大约是 5 个实体以上。在 MVC 中 ，引用实体对 应 Model。到此为止这个逻辑事务的数据收集完整，代入公式计算得出结果：100.5851.66200.26 19.3当然这只是一个 DEMO，数字都是估 算的，实际情况肯定比这个要复杂，算出的功能点指数就会多一些。需要注意的是，使用 MkII 算法计算出的功能点指 数，只是一个数值，代表应用程序的功能规模，和我们平时听到开发说的“我修改了一 个功能点” ，概念上是不同的。所以我们用“功能点指数”这个概念，不过为 了沟通起来方便，还是简化成“功能点”了。MkII 功

15、能点算法是非常适合于 淘宝这样的互联网公司的。不过由于 WEB 应用程序的交互日趋复杂，JS 被大量使用，因此在实践中，如何划分逻辑事务，如何统计输入输出，还需要进一步的研究。划分逻辑事务在前一篇文章我们讲到， “逻辑事务”是统计功能点指数的最小单元，所以进行科学的划分，对统计的正确性非常重要。另外，划分逻辑事务其实也是一个需求 分解的过程，测试工程师可以通过这个过程来分析项目需求，让需求分析工作更加标准化，同时也降低沟通成本，大家围绕逻辑事务进行讨论。逻辑事务一般描述的是用户的行为，所以命名一般都是动宾结构，例如“注册淘宝会员”、 “查看宝贝的详情” 。也有少数的逻辑事务是由一些定时程序产生

16、 的，例如“ 同步用户的最新信息”。有的项目会在需求文档里面专门描述一些“业务规则”，注意，规则不是逻辑事务，规则一定是依附与某个逻辑事务的，例如 “不准注册同名的会员”这个规则其实是属于“ 注册会员”这个逻辑事务。在以数据库为基础的 WEB 应用中，逻辑事务一定是对某项 数据进行的增删改查操作，也就是我们常说的 CRUDL 的其 中之一。CRUDL 分别代表： Create 创建新数据（注册会员） Read 读取数据的信息（查看宝贝） Update 更新数据（保存收货地址） Delete 删除数据（清空购物车） List 列出一批数据（各种 DataGrid）下面我们对这 5 种逻辑事务分别

17、进 行分析，并且结合具 体的案例来看看划分的规则。如果逻辑事务划分正确，后面的计算出现误差就不会太大。Create每个 WEB应用程序，都是从创建数据开始的，比如“发布新宝贝” 、 “注册新会员”，创建数据会在数据表中新增记录。创建数据一般由用户在页面上点击按钮触发，也可能是在请求一个 URL 的时候 触发。有时候，用户在一个页面点击“新建”，会同时新建两个数据对象，比如注册淘宝会员，会同时创建一个支付宝帐号，这里不能算做 2 个逻辑事务，而只有 1 个，这个逻辑事务的“实体 ”是 2 个。Read读取数据的逻辑事务基本都叫“查看 XXX的详情”，WEB 程序会根据主键，把某个数据对象 sel

18、ect 出来，把各个字段的值显示在页面上。在分析 Read 类逻辑事务时，要对页面进行分块分类，因为现在很多 WEB 页面，都不是单纯显示一个数据，而是用 i_f_r_a_m_e的方式，把相关对象都显示 出来，这里每个对象都是一个独立的逻辑事务。注意，在一些列表页面，比如“我购买过的商品”，是用数据列表的方式，展示出很多商品，这不属于 Read 类逻辑事务，而是属于 List，后面会讲到。Read 类一般都是展示单体。有些 Read 类逻辑事务会出现，不同身份的用户查看同一数据对象时，有不同的输出，比如 VIP用户查看商品时有价格 优惠。这里不能算作 2 个逻辑事务： “普通用户查看商品”“V

19、IP 查看 商品”，而应该算 1个。 “用户的角色”只是一个输入 DET。不过，如果普通用户和VIP用户查看商品，完全是两个 不同的 页面（View 不同） ，那就要算 2个逻辑事务了。Update这类逻辑事务是对已经存在的数据进行更新，一般叫做“保存 XXX信息”，不过在某些场景，Update 逻辑事务有很多其他的命名，例如“为订单付款”，实际上是更新了订单对象的状态，因此归于 Update类。在一些信息的保存页面，例如“保存我的收货地址”页面，用户需要先打开某个收货地址的详情页面，然后再进行保存，那么这个详情页面，要算作一个Read 类逻辑事务，用户点击按钮保存，算作一个 Update类逻

20、辑事务。Delete删除类逻辑事务出现的不多，一般都是用户点击“删除 ”按钮，把一个或者几个数据对象删除。老规矩，如果用户一次点击，删除一个对象的同时，又级联删除 了这个对象相关的另一个对象的话，只算作一个逻辑事务，实体是 2 个。删除时一般 都会弹出一个对话框，让用户确认，这个确认不算逻辑事务。List此类逻辑事务最常出现的形态是 DataGrid 数据表格，例如上文说的“ 列出我购买过的商品” 。这个控件在WEB 应用程序中被使用的非常多，它用一种 格式在一个页面展示出多个数据对象，并且把这些对象的关键属性（名称、类型）显示出来。除了 DataGrid，树型控件也是一个 List 类的逻辑

21、事务。此 外，页面中展示对象的下拉 菜单、RadioButto n，也要作为单独的逻辑事务来计算，不过前提示，它们显示的是数据对象，如果是“男/女” 这样的 RadioButton，不是逻辑事 务，而购买商品 时，选择的“ 收货地址列表”则是逻辑事务。有一些 DataGrid 控件，支持用户直接在表格里修改数据，这里的修改功能要单独作为Update 类逻辑事务计算，与上文有一点不同的是，不需要另算 Read 类逻辑事务了。到这里我们对这 5 类逻辑事务都分 析清楚了，大家划分逻 辑事务时，还要明确一个原则，每个逻辑事务的实体个数、输入 DET个数、输出 DET个数都不能是 0，否则就不算逻辑事

22、务。例如，有的页面上设计一个按钮，用户点击后，跳转到另一个页面，这种单纯的跳转，不是逻辑事务。逻辑事务都是对数据对象的操作。 大部分情况下，数据对象都在数据库中，也有一些情况，数据对象是文件对象，比如上传图片，图片本身就是实体对象。以上所列出的，都是常见的逻辑事务案例，在真实项目中，还可能会遇到一些其他的情况，大家只要根据逻辑事务的判定原则，进行推理，就可以很好的把逻辑事务划分清楚了。最后，要说一下测试用例设计。非常相似的，测试用例也是围绕逻辑事务来设计的。在组织用例分类时，基本遵循“项目功能模块逻辑事务 ”这种目录结构。每个逻辑事务的用例，都拥有类似的前置条件、操作步骤、校验方法，所以组织在

23、一起设计，是非常科学的。计算逻辑事务的实体、输入 DET、输出 DET前一篇文章（Part2）介绍了如何划分逻辑事务，文章发表后，大家提出了很多非常好的问题，我这里先简单回复一下，作为我们 Part3 的引子。Q：逻辑事务分解对于那种“增删改查”类型的功能点比较适用，但是流程类的功能点，就不合适了吧？A：就拿交易流程来说好了，我们在设计交易流程的TC 时，是把下单、付款、发货、确认等操作，分别进行设计的，这些操作，其实都是单独的逻辑事务，实际上，开发在设计程序的时候，也是分开做的，不可能全写在一个函数里面。Q：我发现有的逻辑事务，比如点击一个按钮以后，程序既做了查，又做了改，按照你 Part2

24、 里的分类，是不是应该算两个逻辑事务。A：这个怪我没说清楚，这应该是算一个逻辑事务，他可以同时包含多个 CRUD 的action。Q：我们以前设计 TC 很多都是基于一个页面的，现在按照这种方式，一个页面会分解成多个逻辑事务，这样感觉会比较零散。A：测试设计和测试执行是有区别的，测试设计的目标是把被测系统分析清楚，并不是编写出完整的执行脚本，实际上在测试执行过程中，有经验的测试工程师是会把几个逻辑事务放在一起测，效率极高。好，问题先讨论到这里，下面我们开始正题，如何计算每个逻辑事务的实体、输入和输出。这篇文章我们仍然会分别对 CRUDL 这五类逻辑事务进行分析，因为他们的输入和输出的特点，各有

25、不同。不过，对于“实体”的计算，各类逻辑事务的计算方法相同，所以先单独讲一下实体。淘宝系统里存在下面这些实体：会员、宝贝、交易记录、宝贝类目、评价记录、店铺等等。实体的英文原名是 Entity Type，也就是我们平时讨论中经常出现的“对象” ，经常接触代码的工程师会在代码里发现很多“xxxDO”，比如 UserDO、Order DO，这些和 实体是完全对应的。另外还有一个简单的办法来识别实体，就是看数据库的表，一般一个实体肯定至少对应一张表，比如会员这个实体在数据库里，必然有一张 users表。分析一个逻辑事务有哪些实体，是分析的第一步，也是最重要的一步。实体越多，开发和测试的复杂度越高。从

26、 MkII算法里也能看出，实体的系数是 1.66，远高于输入和输出。另外，分析实体可以帮助测试工程师搞清楚，这个事务的范围，对事务有一个全局的概念。分析完后，测试工程师一般会这么说： “哦，这个事务跟这几个对象有关！” 在新人学习和测试设计评审中，实体的分析也能起到非常大的帮助作用。下面开始分类讲 CRUDL 的输入和输出：Create注册会员、发布新宝贝，这都属于 Create类型逻辑事务，这类事务一般都有一个内容较多的“表单” ，里面有一些 输入框、check box、 radiobutton 和一个确认提交按钮，这里的每个控件，都要计算为1 个输入 DET。需要注意，radio控件一般会

27、有多个选项，不能算多个输入，而 只能算一个；提交按钮也要算 1 个输入。除了这些页面控件类输入，还有一类输入，是“隐含” 的。比如卖家在发布新宝贝时，卖家自己的userid 就是一个输 入，因为在发布成功后，这个宝贝会拥有卖家的userid，只是这个 id 并不需要卖家填写，而是放在系统缓存里。虽然是隐含输入，却也参与了逻辑运算，因 此要计数。这是 Create 的两类输入。Create 事务的输出一般会有以下一些信息， “注册成功” 、 “此会员名已被人注册” 、 “密码太短”。当用户试图执行这个事务，系统给用户所有可能的 提示信息，都要记为一个输出。有些输出跟某个输入，有直接的逻辑关系，比

28、如“此会员名已 被人注册” 只跟“会员名” 输入框里所填的信息有关，有的输出，则是 由好几个输入组合在一起，才能出现，分析的时候，需要弄明白，不过这点区别不影响计数。如果把逻辑事务看成一个“函数”，那么输入就可以抽象为函数的输入参数，而输出就是函数的所有可能性的返回值，以及函数抛出的各种异常。后面几类逻辑事务，也可以抽象为这种定义，大家后面自己推理试一试。ReadRead 类事务是读取一个对象的详细信息，比如我们查看一个宝贝的详细信息。它的输入个数一般比较少，其中最基本的，就是这个对象的主键 id，比如宝 贝的 id。如果不同类型的用户查看宝贝时，会有不同的显示信息，那么用户的userid 和

29、用户类型这 2 个要记为输入。如果宝贝的某些属性会影响显示，比如 鞋城宝贝会有个图标，那么输入也要+1。其实如果业务逻辑复杂，输入也不少。我们可以把这些输入抽象的称为“影响对象显示的一些属性” 。一般来说 Read 的输出都比较多，这个对象能显示在页面上的属性，都要记为输出，比如“宝贝名称” 、 “价格”、 “颜色”等等。除了文字类，图片也是输 出，比如宝贝的缩略图和表示宝贝属性的一些小图标，都算。另外，有的图片和Label有链接，这里的链接要单独算输出，因为一个纯文本，肯定没有一个附带 http 链接的文本信 息量多。UpdateUpdate 事务的输入和输出数量可多可少，关键看系统 Upd

30、ate 的规模，比如“编辑宝贝”跟“发布新宝贝” 相比，输入输出的数量都非常多。像“ 修 改我的登录密码” 这样的，数量就非常少了。Update 事务的输入输出识别，与 Create 类非常 相似，因为大部分Update 事务也是表单提交的方式。这里需要注意的是，系统中会存在一些“不起眼”的 Update 事务，分析时千万别漏了。比如大部分会员有多个收货地址，然后在列表中有一个鼠标悬停出 现的“ 设置为默认收获地址” 的按钮，当用户点击的时候，只是修改收获地址的一 个属性，非常的隐蔽。这也是一个逻辑事务，它的输入是用户 id，收货地址 id，输出只有 1个，就是点击按钮后，系统提示修改成功，非

31、常简单，但是不要遗漏。DeleteDelete 类事务的分析相对简 单一些，多数删除功能，都是直接对 数据进行删除，因此输入一般就是数据主键 id 这1 个。不过，有一些数据在删除前，需 要先做一些逻辑判断，看看能不能删，这样输入就多了，相应的实体也会增加。比如， “已经发布的宝贝不能删除” ，那么“ 宝贝发布状态” 就是 1 个输入， “已经 有交易的宝贝不能删除” ，那么实体就不仅仅是宝贝，还有交易记录，输入也要增加“交易记录 id”；如果规则更复杂“有未完成交易的宝贝不能被删除”，那么 输入还要增加“交易状态” ，依此类推。ListList 事务是一个重点，最后讲，它的输入输出计算比较复

32、杂，而且多变，所以大家不仅要理解我下面讲的东西，还要能自己推理，分析自己实际遇到的各种 List。List 事务实质上跟Read 很像，不同在于 Read 只看1 个对象，List 要看多个。首先看最常出现的 List 事务：DataGrid，这种 控件一般是一个二维表格，它的输入与Read 类似，比如我的订单列表的输入是会员 userid，我的已买到订单列表还要增加订单类型这个输入，我的近 3 个 月已买到订单再加订单时间，等等。有些列表上方，会有查询功能，比如按照名称查询，这些查询项会影响列表的显示数据，因此是输入。大家如果想象一下这个列 表对应的 sql 语句，就好理解了，where后面

33、跟的都是输入。DataGrid 里的输出比较直 观，每一列就是一个输出，对应 sql语句里的 select后面的字段，注意，有些列显示的不仅仅是文字，还有图片，颜色，这些都要单独计数。对于 DataGrid来说最纠结 的要属“ 翻页”和“排序”功能，这究竟是算输入还是输出呢？经过推理我们发现，翻页功能对显示的数据是有影响的，比如 我翻到第二页（假设每页10 个数据对象） ，很多程序会控制从数据库里读取的数据，只取出第 11 到 20 的数据，也是在 sql 的 where 后面加条件，所以， 翻页属于输入的计数，流行的翻页一般是“上一页”“下一页” 这样的按钮 或者是直接输入数字翻页，只要出现

34、 1种，输入+2 ，要是两种都有，+4。再说说排 序，排序对应的sql 标记是 order by，不是 select 也不是 where，比较另类，究竟算哪边合适呢？在 MkII的相关资料 里也没有找到答案。通过比较发现 order 的操作与 where更接近一些，相似度更大，都是影响数据的检索范 围，因此我们把排序也认定为输入。DataGrid 如果有 1 列提供排序功能，那么输入+1，多列 的话，依此类推。前文曾经提到过，显示数据对象的 radio 控件，也是 List 类的事务，它的输入，就是显示这些数据的条件。比如买家购买商品时，有个收货地址的 radio控件，因为是“我的” 地址，所

35、以 userid 是 1个输入。输出就要看这个 radio 展示了数据对象的哪些属性，有几个算几个。比如收货地址的姓 名、省、市、区、邮编，这些都是不同的字段，但是在 radio 里全部拼在一起，要算 5 个输出。还有一类控件使用也较多，就是树形控件，这也是 List 类的逻辑事务。输入算法就不说了，同上，重点说输出。树形控件里的每个节点，一般都是一个数据 对象，节点会有名称、颜色、加粗、小图标这么几种显示元素，用来表示数据对象的属性，这些都是输出，单独计数。树形控件有特殊的展开、折叠功能，这个不太 好分类，我们直接规定，输出+4，因为在折叠上我们需要投入一点测试成本。如果一棵树里展示了两种数

36、据对象，别忘了实体要+1。List 的例子我们就讲 3 个，大家还有可 能遇到各种五花八门的 List 逻辑事务，只要掌握这个原则：输入会影响显示数据的范围，而输出是展示数据的各个属性。大家只要掌握规律，细心推理，遇到问题方可迎刃而解。Part3的主要内容都讲完了，最后，讲一下功能点估算的技巧。想要算出一个项目的功能点规模，并不一定要把每个逻辑事务的分值都精确的计算出来。大 家可以先把逻辑事务进行分类，可以按照 CRUDL 分类，也可以按照你自己的经验分类，然后挑选一些重要的，典型的逻辑事务，进行仔细的计算，再给每个类型 的逻辑事务一个平均的估算值，这样总分就很快可以算出了。如果你需要尽快算出

37、总分，可以参考这种做法。使用功能点分析来设计测试用例最近有位同事问我， “天彤你搞这个功能点分析算法，主要目的是 度量 project 的规模么，还是度量测试工程师的工作量？”我说，这两个确实是最初的 目标，不过现在，这只是功能点算法的副产品，并不是核心价值。 “那是不是根据功能点分 析，可以自动生成测试用例呢？” 这的确是一个很诱人的功能，而且随着 进一步研究发现，先用 freemind进行功能点分析，然后自动生成一部分测试用例，是完全可行的，不过这仍然是副产品，不是最核心的目标。功能点分析法应用在中，它最核心的价值究竟是什么呢？让我们先看看软件开发，这是跟测试离得最近的工作类型。开发工程师

38、工作大致可以分为“ 设计 ”和“编码”两步。设计一般是 使用 UML语言，借助类似于 Rose 这样的，绘制一些UC 图、类图、ER 图等等。这些设计图决定了最终的编码该如何实施。另外，当其他的开发工程师需要了解这个proje ct 时（例如评审） ，ta 会先看 设计文档，从设计文档中掌握开发思路，然后再阅读代码，了解细节。由于 UML语言中，包含了大量 的约定和规则，因此开发工程师只需要花费较少的工作量，就能表达出充足的信息。而阅读 UML 设计文档的其他人，也能很快 从 UML 设计中了解设计人员的思路。试想一下，如果让读者直接看代码，需要花费多少倍的时间，才能达到相同的目的。这就是设计

39、模型的价值，不仅帮助设计人 员自己整理思路，也帮助其他读者快速交流信息。对于软件测试来说，也有“设计”和“ 编码（实施） ”两个阶段的工作。设计是我们设计测试用例的过程，也就是我们考虑如何做；实施就是我们执行测试的过 程，有时是手工执行，有时是写脚本让计算机执行。因此，测试用例是我们的“设计文档” ，是我们交流测试方法，评审测试方案的核心。但是只依靠测试用例，我 们感觉存在很多问题： 测试用例数 量多，难以阅读 测试用例结 构五花八门 ，风格迥异，不同团队间不好交流 测试用例很 难清楚表达 需求逻辑，每次用例评审，要花费大量 时间，讲解需求逻辑 测试用例描 写的是测试 细节，较难看出测试的思路

40、和 重点在这种情况下，我们需要一种测试设计模型，用来解决上面那些问题。事实上，测试设计模型不是唯一的，我们允许团队中使用各种设计模型来设计测试用例。 以前我们曾经用 UML来设计，这是一种设计模型。不过 UML开发工程师 用起来合适，我们测试用就不是特别合适，毕竟它的优势，是描述程序的开发实现。另 外，设计模型和测试用例模式，应该是成对出现的，也就是说，用什么样的设计模型，就应该有合适的用例模式与之对应。一成不变的用例模式，其实是不存在的， 它必须要紧跟设计模型。这就是我们选择功能点分析算法的最主要目的：寻找一种新的设计模型，改善我们的测试用例设计过程，精简测试文档（因为模型可以包含很多信息）

41、 ，让测试团队用一种相同的设计模型进行工作，减少沟通成本，更好的支撑我们的业务测试。现在我们面对的，是互联网软件产品，这一类软件的特点，不同于传统的应用软件，互联网应用软件多使用BS 结构， MVC 的开发模型，有庞大的数据库作为 支撑，需求和用户界面多变，市场竞争激烈，等等。在这种条件下，测试工程师往往没有太多时间设计用例，而是要快速的面对大量新需求和需求变更，第一时间找 出程序的 bug，这才是王道。下面，我们讲一下，怎么样使用功能点分析的方法，来设计测试用例。如 part2 所说，我们拿到一个 project，首先需要把它拆分成逻 辑事务，然后针对每个逻辑事务，讨论使用何种测试方法。有些

42、事务属于核心事务， 必须要重点测试，要设计完整的用例，有些事务只需编写一个简单的 check list，就足够指导测试执行了，有些事务甚至根本不用写任何文档，测试工程师拿到手也知道该怎么测试。在这里我不想再回答“一个完全不懂的测试新人，看 不到用例，该怎么测试？”这样的问题 。测试新人正式上岗之前，必须接受测试技术培训，和 project 的业务培训。如果是跨团 队合作（其实这种场景很 少） ，那么 PTM也要出面先 做一些测试方案的讲解，绝对不能把测试用例直接扔给其他工程师。这里我们推荐使用 freemind 或者 xmind 这样的思维导图软件，来做功能点分析。root node 一般是 project 的名称，比如购物车。然后下级 node 是各个模块的名称，然后就是逻辑事务的名称。本文选了一个逻辑事务作为案例：买家在宝 贝详情页面点击购买。通过对这个事务的功能点分析，再推导出相应的测试用例。事实上，淘宝测试团队的 twork 小组，正在开发通过 freemind 图，自 动生成测试用例的功能，所以在下面的讲解中，我会不断比较，freemind 图和最终生成的用例。首先在逻辑事务的 node 下创建：输入、输出、实体 3 个 node，先列出所有的实体。实体对用例设计并没有什么影响，只是告诉读者，这个事务跟哪些对象有关，这样可以清楚的界定用例范围