为什么用例不是“功能”?[2]

　　为什么用例不是“功能”?[2]   软件测试

　　如果你在想图1的改进后的版本是什么样的，图2展示了改进后的版本。

　　图 2一种更好，更加简单的方法: 合并功能以反映对参与者的真正价值

　　这一个用例包含了以前的图中所分解为用例的所有“功能”。你也许会问为什么这样做比较好，答案很简单：它关注于客户想要系统提供的价值，而不是我们在系统内部如何细分和构造的。如果把所有的功能分解成单独的用例，你将迫使客户(为系统付钱的人)把分解过的用例装配成一件对他们有意义的东西，以便理解系统所描述的是不是他们所想要的(即他们想为之付钱的)。

　　关注价值

　　很多小用例是常见的问题，尤其是在一个习惯于功能分解的团队中，他们的用例名称读起来就象是一个系统所执行的功能的列表，如“输入订单”、“审查订单”、“取消订单”、“履行订单”，这起先听起来也不是很坏，但不仅仅这些。即使对于一个小规模的订购系统，用例列表也很容易达到上百个，如果谁走到了这一步，他们不久就会淹死在用例的海洋中，尤其是当系统规模确实比较大时，在这种情况下，你最终也许会有几百个，甚至上前个用例。

　　这么做有什么错呢?

　　这些用例的价值将会被错过。用例的唯一目的是为参与者产生价值。在一定层次上能够输入订单也是某种有价值的事情，但是，如果这些订单从来不被履行，那还有价值吗?也许没有吧。

　　怎样输入订单、修改订单以及取消订单等等，所有这些事情都是与客户真正想要做的事情有关的，那就是接受订购的货物。这些活动对公司想要的事情是必须的，那就是收到货款。

　　这种看起来是支离破碎的没有任何明显关系的功能集合的另一个问题是导致难以使用的系统。很多系统跟这个很类似，它们只是一堆杂乱的特性。记住，用例帮助我们关注与什么是真正重要的，也就是具有真正价值的事物，并且使我们能够围绕那些元素来定义系统。用例不要是系统按照功能分解的蓝图。

　　举例

　　考虑一个你在互联网上用过的一个电子商务系统，当你登录这个站点的时候，你的目标可能是查找产品相关的信息、选择要购买的产品、安排支付及送货约定。在做这些事的过程当中，你可能会改变主意、输入错误的信息以至不得不修改它、改变邮递或送货地址，以及其他的一些东西。如果这个网站不允许你通过一种吸引人的方式来找到并订购产品，你也许不会完成你的订购，更不用说再次来到这个网站。

　　当建造一个系统时，始终要记住用例的核心定义：关于采用某种方式使用系统来做有价值的事情的故事。如果你能够实施这个定义，展示用户希望通过系统获得的价值，然后创建反映这些价值的用例的时候，你的系统将会更好地满足用户的期望。

原文转自：http://www.ltesting.net