多数人从用例开始就走入了迷途，也许是用例图和数据流图的相似性导致人们把用例定义为简单的功能或者菜单项。不论原因是什么，这都是新手最容易犯的错误。
图 1 错误的方式：用例是菜单项或者功能
这幅图有什么错误？用最简单的定义，我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义，是不是所有的“用例”都是独立的有用的呢？
答案当然是不是，在这个例子中，用例表示了系统需要做的所有的事情，但是他们也描述了用户需要通过系统去做的一件单独的事情：定购。所有保留的元素都是这一个用例的备选支流，它们是在定购时可能发生的步骤。在只做一件有用的事情的地方，只应该有一个用例。图1就是一个功能分解的例子，或者“四轮马车”格式的例子――一个参与者在中间，周围是一圈用例。
这是一个常见的问题，为什么人们会陷入这个陷阱呢？我们有一个有对定购的内在需要，并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下，我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时，实际上会把问题复杂化。
问题在这里
用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情，它描述了系统在概念层次上做什么，使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。
再看看图1，现在问你自己，如果我从来没有定购过，我想通过系统查询定单的状态吗？这是不太可能的。或者如果我从来没有定购过，我想变更订单吗？不，也许不。通常这些东西只有当我订购过的时候才对我有用。然而，为了系统能够允许我订购，这些都是必要的。
把系统分解为越来越小的用例模糊了系统的真实目的，极端情况下，我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车，或许你会说这是辆汽车，你也知道零件们是有用的，但是你确实不能说明他们如何组装在一起。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
