——计算逻辑事务的实体、输入DET、输出DET
前一篇文章（Part2）介绍了如何划分逻辑事务，文章发表后，大家提出了很多非常好的问题，我这里先简单回复一下，作为我们Part3的引子。
Q：逻辑事务分解对于那种“增删改查”类型的功能点比较适用，但是流程类的功能点，就不合适了吧？
A：就拿交易流程来说好了，我们在设计交易流程的TC时，是把下单、付款、发货、确认等操作，分别进行设计的，这些操作，其实都是单独的逻辑事务，实际上，开发在设计程序的时候，也是分开做的，不可能全写在一个函数里面。
Q：我发现有的逻辑事务，比如点击一个按钮以后，程序既做了查，又做了改，按照你Part2里的分类，是不是应该算两个逻辑事务。
A：这个怪我没说清楚，这应该是算一个逻辑事务，他可以同时包含多个CRUD的action。
Q：我们以前设计TC很多都是基于一个页面的，现在按照这种方式，一个页面会分解成多个逻辑事务，这样感觉会比较零散。
A：测试设计和测试执行是有区别的，测试设计的目标是把被测系统分析清楚，并不是编写出完整的执行脚本，实际上在测试执行过程中，有经验的测试工程师是会把几个逻辑事务放在一起测，效率极高。
好，问题先讨论到这里，下面我们开始正题，如何计算每个逻辑事务的实体、输入和输出。这篇文章我们仍然会分别对CRUDL这五类逻辑事务进行分析，因为他们的输入和输出的特点，各有不同。不过，对于“实体”的计算，各类逻辑事务的计算方法相同，所以先单独讲一下实体。
淘宝系统里存在下面这些实体：会员、宝贝、交易记录、宝贝类目、评价记录、店铺等等。实体的英文原名是Entity Type，也就是我们平时讨论中经常出现的“对象”，经常接触代码的工程师会在代码里发现很多“xxxDO”，比如UserDO、OrderDO，这些和实体是完全对应的。另外还有一个简单的办法来识别实体，就是看数据库的表，一般一个实体肯定至少对应一张表，比如会员这个实体在数据库里，必然有一张users表。
分析一个逻辑事务有哪些实体，是分析的第一步，也是最重要的一步。实体越多，开发和测试的复杂度越高。从MkII算法里也能看出，实体的系数是1.66，远高于输入和输出。另外，分析实体可以帮助测试工程师搞清楚，这个事务的范围，对事务有一个全局的概念。分析完后，测试工程师一般会这么说：“哦，这个事务跟这几个对象有关！”在新人学习和测试设计评审中，实体的分析也能起到非常大的帮助作用。
下面开始分类讲CRUDL的输入和输出：
Create
注册会员、发布新宝贝，这都属于Create类型逻辑事务，这类事务一般都有一个内容较多的“表单”，里面有一些输入框、checkbox、radiobutton和一个确认提交按钮，这里的每个控件，都要计算为1个输入DET。需要注意，radio控件一般会有多个选项，不能算多个输入，而只能算一个；提交按钮也要算1个输入。除了这些页面控件类输入，还有一类输入，是“隐含”的。比如卖家在发布新宝贝时，卖家自己的userid就是一个输入，因为在发布成功后，这个宝贝会拥有卖家的userid，只是这个id并不需要卖家填写，而是放在系统缓存里。虽然是隐含输入，却也参与了逻辑运算，因此要计数。这是Create的两类输入。
Create事务的输出一般会有以下一些信息，“注册成功”、“此会员名已被人注册”、“密码太短”。当用户试图执行这个事务，系统给用户所有可能的提示信息，都要记为一个输出。有些输出跟某个输入，有直接的逻辑关系，比如“此会员名已被人注册”只跟“会员名”输入框里所填的信息有关，有的输出，则是由好几个输入组合在一起，才能出现，分析的时候，需要弄明白，不过这点区别不影响计数。
如果把逻辑事务看成一个“函数”，那么输入就可以抽象为函数的输入参数，而输出就是函数的所有可能性的返回值，以及函数抛出的各种异常。后面几类逻辑事务，也可以抽象为这种定义，大家后面自己推理试一试。
Read
Read类事务是读取一个对象的详细信息，比如我们查看一个宝贝的详细信息。它的输入个数一般比较少，其中最基本的，就是这个对象的主键id，比如宝贝的id。如果不同类型的用户查看宝贝时，会有不同的显示信息，那么用户的userid和用户类型这2个要记为输入。如果宝贝的某些属性会影响显示，比如鞋城宝贝会有个图标，那么输入也要+1。其实如果业务逻辑复杂，输入也不少。我们可以把这些输入抽象的称为“影响对象显示的一些属性”。
一般来说Read的输出都比较多，这个对象能显示在页面上的属性，都要记为输出，比如“宝贝名称”、“价格”、“颜色”等等。除了文字类，图片也是输出，比如宝贝的缩略图和表示宝贝属性的一些小图标，都算。另外，有的图片和Label有链接，这里的链接要单独算输出，因为一个纯文本，肯定没有一个附带http链接的文本信息量多。
Update
Update事务的输入和输出数量可多可少，关键看系统Update的规模，比如“编辑宝贝”跟“发布新宝贝”相比，输入输出的数量都非常多。像“修改我的登录密码”这样的，数量就非常少了。Update事务的输入输出识别，与Create类非常相似，因为大部分Update事务也是表单提交的方式。
这里需要注意的是，系统中会存在一些“不起眼”的Update事务，分析时千万别漏了。比如大部分会员有多个收货地址，然后在列表中有一个鼠标悬停出现的“设置为默认收获地址”的按钮，当用户点击的时候，只是修改收获地址的一个属性，非常的隐蔽。这也是一个逻辑事务，它的输入是用户id，收货地址id，输出只有1个，就是点击按钮后，系统提示修改成功，非常简单，但是不要遗漏。
Delete
Delete类事务的分析相对简单一些，多数删除功能，都是直接对数据进行删除，因此输入一般就是数据主键id这1个。不过，有一些数据在删除前，需要先做一些逻辑判断，看看能不能删，这样输入就多了，相应的实体也会增加。比如，“已经发布的宝贝不能删除”，那么“宝贝发布状态”就是1个输入，“已经有交易的宝贝不能删除”，那么实体就不仅仅是宝贝，还有交易记录，输入也要增加“交易记录id”；如果规则更复杂“有未完成交易的宝贝不能被删除”，那么输入还要增加“交易状态”，依此类推。
List
List事务是一个重点，最后讲，它的输入输出计算比较复杂，而且多变，所以大家不仅要理解我下面讲的东西，还要能自己推理，分析自己实际遇到的各种List。List事务实质上跟Read很像，不同在于Read只看1个对象，List要看多个。首先看最常出现的List事务：DataGrid，这种控件一般是一个二维表格，它的输入与Read类似，比如我的订单列表的输入是会员userid，我的已买到订单列表还要增加订单类型这个输入，我的近3个月已买到订单再加订单时间，等等。有些列表上方，会有查询功能，比如按照名称查询，这些查询项会影响列表的显示数据，因此是输入。大家如果想象一下这个列表对应的sql语句，就好理解了，where后面跟的都是输入。
DataGrid里的输出比较直观，每一列就是一个输出，对应sql语句里的select后面的字段，注意，有些列显示的不仅仅是文字，还有图片，颜色，这些都要单独计数。
对于DataGrid来说最纠结的要属“翻页”和“排序”功能，这究竟是算输入还是输出呢？经过推理我们发现，翻页功能对显示的数据是有影响的，比如我翻到第二页（假设每页10个数据对象），很多程序会控制从数据库里读取的数据，只取出第11到20的数据，也是在sql的where后面加条件，所以，翻页属于输入的计数，流行的翻页一般是“上一页”“下一页”这样的按钮或者是直接输入数字翻页，只要出现1种，输入+2，要是两种都有，+4。再说说排序，排序对应的sql标记是order by，不是select也不是where，比较另类，究竟算哪边合适呢？在MkII的相关资料里也没有找到答案。通过比较发现order的操作与where更接近一些，相似度更大，都是影响数据的检索范围，因此我们把排序也认定为输入。DataGrid如果有1列提供排序功能，那么输入+1，多列的话，依此类推。
前文曾经提到过，显示数据对象的radio控件，也是List类的事务，它的输入，就是显示这些数据的条件。比如买家购买商品时，有个收货地址的radio控件，因为是“我的”地址，所以userid是1个输入。输出就要看这个radio展示了数据对象的哪些属性，有几个算几个。比如收货地址的姓名、省、市、区、邮编，这些都是不同的字段，但是在radio里全部拼在一起，要算5个输出。
还有一类控件使用也较多，就是树形控件，这也是List类的逻辑事务。输入算法就不说了，同上，重点说输出。树形控件里的每个节点，一般都是一个数据对象，节点会有名称、颜色、加粗、小图标这么几种显示元素，用来表示数据对象的属性，这些都是输出，单独计数。树形控件有特殊的展开、折叠功能，这个不太好分类，我们直接规定，输出+4，因为在折叠上我们需要投入一点测试成本。如果一棵树里展示了两种数据对象，别忘了实体要+1。
List的例子我们就讲3个，大家还有可能遇到各种五花八门的List逻辑事务，只要掌握这个原则：输入会影响显示数据的范围，而输出是展示数据的各个属性。大家只要掌握规律，细心推理，遇到问题方可迎刃而解。
Part3的主要内容都讲完了，最后，讲一下功能点估算的技巧。想要算出一个项目的功能点规模，并不一定要把每个逻辑事务的分值都精确的计算出来。大家可以先把逻辑事务进行分类，可以按照CRUDL分类，也可以按照你自己的经验分类，然后挑选一些重要的，典型的逻辑事务，进行仔细的计算，再给每个类型的逻辑事务一个平均的估算值，这样总分就很快可以算出了。如果你需要尽快算出总分，可以参考这种做法。
