FAQ-划分用例的颗粒度有啥参考标准或技巧
有的，划分用例颗粒度的技术主要是参考用例大师 Alistair Cockburn 博士在 Writing Effective Use Cases 这本名著里提出的方法。Cockburn 把大大小小的用例划分成了至少五层，从海平面（用户目标层）往上是风筝层、云层，往下是鱼层、贝壳层等等。我这里简化为三层。如下图所示，在某网店购物的三层用例：
其中，最重要的用例是海平面即用户目标层用例。用例粒度划分有一些常用的技巧和办法，其中一个基本的依据是时间，即通过人机交互，执行完成某个用例所需的时间跨度。用户目标层的用例都是能在一个较短的时间或一两次会话（one session）内完成的，短的可能只需要几分钟，十几分钟，长的也只需要一两个小时，或几个小时。这里我建议设定一个上限：执行一个用户目标层用例最好不要超过半天时间。如果执行一个用例需要经过一天的上午、下午才能完成，那么最好把这个用例拆分成两个小一点分别可在半天之内完成的用例。概要（目标）层的用例都是无法在较短的时间内一次性完成的。例如上图的“购物”，从挑选商品，下订单，付款，到收到货，再反馈评价，完成一个完整的购物流程一般至少需要一两天（以上）的时间。显然，这说明“购物”这个用例需求的粒度较大，它包含了若干更小的用户目标，所以它是概要层（目标）。除了考虑执行时间以外，控制用例粒度大小的另一个简单办法是观察用例的主体内容——动作步骤（action steps）数量。如果一个用例中的步骤数量过多（如几十个）或描述的内容过于庞杂，那说明这个用例很可能是粒度太大了，包含了过多的内容，应该把它切分成更小的用例和目标。Cockburn 曾经提到过一个经验数值，他和其他用例专家们编写过的用例文本，一个用例几乎都不超过 11 步。当然，这个值不是绝对的。如果一个用例有 15 步，可不可以呢？可能也是可以的。重点是：如果你写的用例步骤数目太多（比如超过了 11 步或 15 步），那么这提醒你，你提取的当前这个用例可能太大了，也许有必要对它进行拆分。登录界面可不可以把登录、注册、忘记密码化为一个用例？通常是提取出“登录”和“注册”两个用例，而“找回密码”不是一个独立的用例。如下图：
【FAQ-划分用例的颗粒度有啥参考标准或技巧】
需求分析里是不是查询每个列表每个详情都是单独的用例？可以倒过来想，如果我们把用户对每张数据表（实体）的查询、访问都至少提取为一个用例的话，那么恐怕很快就会出现用例数量爆炸的情况，尤其对于大中型系统。用例的颗粒度太细，往往会导致用例的数量过多，增加了需求管理与维护的难度。有 500 张数据表要查询，那么就必然有 500 个查询用例？常常不是这样的。一个常用的解决思路是，尽可能把一些语义相关、彼此有紧密联系的数据表归并起来，把它们合并到一个或几个用例的流程当中去。这样所有的数据表与用例之间就不再是一对一的关系，而是多对一的关系，从而可以减少用例的数量。。。。
推荐阅读
- 编写测试用例时参照实际项目还是需求文档
- 汽车|双电机耦合驱动电动汽车驱动模式划分与优化
- 企业组网中，子网划分过大有啥坏处
- FAQ-为啥要迭代开发
- FAQ-有没有通过UML图自动生成Java代码的工具
- 区域|部队考军校会按区域、军兵种划分出题吗？
- 谁知道银行业信息科技“一部两中心”的组织架构具体是咋样的，职责是怎样划分的 请大家帮忙
- 将数据集划分成训练集、测试集
- LoveLive SIF中歌曲的不同属性是怎么样划分的
- FAQ-交互脚本的最佳格式