在前一篇文章我们讲到，“逻辑事务”是统计功能点指数的最小单元，所以进行科学的划分，对统计的正确性非常重要。另外，划分逻辑事务其实也是一个需求分解的过程，测试工程师可以通过这个过程来分析项目需求，让需求分析工作更加标准化，同时也降低沟通成本，大家围绕逻辑事务进行讨论。
逻辑事务一般描述的是用户的行为，所以命名一般都是动宾结构，例如“注册淘宝会员”、“查看宝贝的详情”。也有少数的逻辑事务是由一些定时程序产生的，例如“同步用户的最新信息”。有的项目会在需求文档里面专门描述一些“业务规则”，注意，规则不是逻辑事务，规则一定是依附与某个逻辑事务的，例如“不准注册同名的会员”这个规则其实是属于“注册会员”这个逻辑事务。
在以数据库为基础的WEB应用中，逻辑事务一定是对某项数据进行的增删改查操作，也就是我们常说的CRUDL的其中之一。CRUDL分别代表：
- Create 创建新数据（注册会员）
- Read 读取数据的信息（查看宝贝）
- Update 更新数据（保存收货地址）
- Delete 删除数据（清空购物车）
- List 列出一批数据（各种DataGrid）
Create
每个WEB应用程序，都是从创建数据开始的，比如“发布新宝贝”、“注册新会员”，创建数据会在数据表中新增记录。创建数据一般由用户在页面上点击按钮触发，也可能是在请求一个URL的时候触发。
有时候，用户在一个页面点击“新建”，会同时新建两个数据对象，比如注册淘宝会员，会同时创建一个支付宝帐号，这里不能算做2个逻辑事务，而只有1个，这个逻辑事务的“实体”是2个。
Read
读取数据的逻辑事务基本都叫“查看XXX的详情”，WEB程序会根据主键，把某个数据对象select出来，把各个字段的值显示在页面上。在分析Read类逻辑事务时，要对页面进行分块分类，因为现在很多WEB页面，都不是单纯显示一个数据，而是用i_f_r_a_m_e的方式，把相关对象都显示出来，这里每个对象都是一个独立的逻辑事务。
注意，在一些列表页面，比如“我购买过的商品”，是用数据列表的方式，展示出很多商品，这不属于Read类逻辑事务，而是属于List，后面会讲到。Read类一般都是展示单体。
有些Read类逻辑事务会出现，不同身份的用户查看同一数据对象时，有不同的输出，比如VIP用户查看商品时有价格优惠。这里不能算作2个逻辑事务：“普通用户查看商品”“VIP查看商品”，而应该算1个。“用户的角色”只是一个输入DET。不过，如果普通用户和VIP用户查看商品，完全是两个不同的页面（View不同），那就要算2个逻辑事务了。
Update
这类逻辑事务是对已经存在的数据进行更新，一般叫做“保存XXX信息”，不过在某些场景，Update逻辑事务有很多其他的命名，例如“为订单付款”，实际上是更新了订单对象的状态，因此归于Update类。
在一些信息的保存页面，例如“保存我的收货地址”页面，用户需要先打开某个收货地址的详情页面，然后再进行保存，那么这个详情页面，要算作一个Read类逻辑事务，用户点击按钮保存，算作一个Update类逻辑事务。
Delete
删除类逻辑事务出现的不多，一般都是用户点击“删除”按钮，把一个或者几个数据对象删除。老规矩，如果用户一次点击，删除一个对象的同时，又级联删除了这个对象相关的另一个对象的话，只算作一个逻辑事务，实体是2个。删除时一般都会弹出一个对话框，让用户确认，这个确认不算逻辑事务。
List
此类逻辑事务最常出现的形态是DataGrid数据表格，例如上文说的“列出我购买过的商品”。这个控件在WEB应用程序中被使用的非常多，它用一种格式在一个页面展示出多个数据对象，并且把这些对象的关键属性（名称、类型）显示出来。除了DataGrid，树型控件也是一个List类的逻辑事务。此外，页面中展示对象的下拉菜单、RadioButton，也要作为单独的逻辑事务来计算，不过前提是，它们显示的是数据对象，如果是“男/女”这样的RadioButton，不是逻辑事务，而购买商品时，选择的“收货地址列表”则是逻辑事务。
有一些DataGrid控件，支持用户直接在表格里修改数据，这里的修改功能要单独作为Update类逻辑事务计算，与上文有一点不同的是，不需要另算Read类逻辑事务了。
到这里我们对这5类逻辑事务都分析清楚了，大家划分逻辑事务时，还要明确一个原则，每个逻辑事务的实体个数、输入DET个数、输出DET个数都不能是0，否则就不算逻辑事务。例如，有的页面上设计一个按钮，用户点击后，跳转到另一个页面，这种单纯的跳转，不是逻辑事务。逻辑事务都是对数据对象的操作。大部分情况下，数据对象都在数据库中，也有一些情况，数据对象是文件对象，比如上传图片，图片本身就是实体对象。
以上所列出的，都是常见的逻辑事务案例，在真实项目中，还可能会遇到一些其他的情况，大家只要根据逻辑事务的判定原则，进行推理，就可以很好的把逻辑事务划分清楚了。
最后，要说一下测试用例设计。非常相似的，测试用例也是围绕逻辑事务来设计的。在组织用例分类时，基本遵循“项目－功能模块－逻辑事务”这种目录结构。每个逻辑事务的用例，都拥有类似的前置条件、操作步骤、校验方法，所以组织在一起设计，是非常科学的。
--------------------------------------------------------------------------------------------
转自：http://easytest.csai.cn/user1/37581/archives/2011/45629.html
