图 1 错误的方式：用例是菜单项或者功能
这幅图有什么错误？用最简单的定义，我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义，是不是所有的“用例”都是独立的有用的呢？
答案当然是不是，在这个例子中，用例表示了系统需要做的所有的事情，但是他们也描述了用户需要通过系统去做的一件单独的事情：定购。所有保留的元素都是这一个用例的备选支流，它们是在定购时可能发生的步骤。在只做一件有用的事情的地方，只应该有一个用例。图1就是一个功能分解的例子，或者“四轮马车”格式的例子――一个参与者在中间，周围是一圈用例。
这是一个常见的问题，为什么人们会陷入这个陷阱呢？我们有一个有对定购的内在需要，并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下，我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时，实际上会把问题复杂化。
问题在这里
用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情，它描述了系统在概念层次上做什么，使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。
再看看图1，现在问你自己，如果我从来没有定购过，我想通过系统查询定单的状态吗？这是不太可能的。或者如果我从来没有定购过，我想变更订单吗？不，也许不。通常这些东西只有当我订购过的时候才对我有用。然而，为了系统能够允许我订购，这些都是必要的。
把系统分解为越来越小的用例模糊了系统的真实目的，极端情况下，我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车，或许你会说这是辆汽车，你也知道零件们是有用的，但是你确实不能说明他们如何组装在一起。
当使用用例的时候，记住用例是考虑整个系统的一种方式，并且要组织成可管理的功能块，这些功能块完成一些有价值的事情。为了得到正确的用例集合，问你自己一个问题：“参与者实际上想使用系统做什么？”
如果你在想图1的改进后的版本是什么样的，图2展示了改进后的版本。
图 2一种更好，更加简单的方法: 合并功能以反映对参与者的真正价值
这一个用例包含了以前的图中所分解为用例的所有“功能”。你也许会问为什么这样做比较好，答案很简单：它关注于客户想要系统提供的价值，而不是我们在系统内部如何细分和构造的。如果把所有的功能分解成单独的用例，你将迫使客户（为系统付钱的人）把分解过的用例装配成一件对他们有意义的东西，以便理解系统所描述的是不是他们所想要的（即他们想为之付钱的）。
文章来源于领测软件测试网 https://www.ltesting.net/
