用例不是“功能”
多数人从用例开始就走入了迷途,也许是用例图和数据流图的相似性导致人们把用例定义为简单的功能或者菜单项。不论原因是什么,这都是新手最容易犯的错误。
图 1 错误的方式:用例是菜单项或者功能
这幅图有什么错误?用最简单的定义,我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义,是不是所有的“用例”都是独立的有用的呢?
答案当然是不是,在这个例子中,用例表示了系统需要做的所有的事情,但是他们也描述了用户需要通过系统去做的一件单独的事情:定购。所有保留的元素都是这一个用例的备选支流,它们是在定购时可能发生的步骤。在只做一件有用的事情的地方,只应该有一个用例。图1就是一个功能分解的例子,或者“四轮马车”格式的例子――一个参与者在中间,周围是一圈用例。
这是一个常见的问题,为什么人们会陷入这个陷阱呢?我们有一个有对定购的内在需要,并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下,我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时,实际上会把问题复杂化。
问题在这里
用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情,它描述了系统在概念层次上做什么,使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。
再看看图1,现在问你自己,如果我从来没有定购过,我想通过系统查询定单的状态吗?这是不太可能的。或者如果我从来没有定购过,我想变更订单吗?不,也许不。通常这些东西只有当我订购过的时候才对我有用。然而,为了系统能够允许我订购,这些都是必要的。
把系统分解为越来越小的用例模糊了系统的真实目的,极端情况下,我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车,或许你会说这是辆汽车,你也知道零件们是有用的,但是你确实不能说明他们如何组装在一起。
当使用用例的时候,记住用例是考虑整个系统的一种方式,并且要组织成可管理的功能块,这些功能块完成一些有价值的事情。为了得到正确的用例集合,问你自己一个问题:“参与者实际上想使用系统做什么?”
如果你在想图1的改进后的版本是什么样的,图2展示了改进后的版本。
图 2一种更好,更加简单的方法: 合并功能以反映对参与者的真正价值
这一个用例包含了以前的图中所分解为用例的所有“功能”。你也许会问为什么这样做比较好,答案很简单:它关注于客户想要系统提供的价值,而不是我们在系统内部如何细分和构造的。如果把所有的功能分解成单独的用例,你将迫使客户(为系统付钱的人)把分解过的用例装配成一件对他们有意义的东西,以便理解系统所描述的是不是他们所想要的(即他们想为之付钱的)。
关注价值
很多小用例是常见的问题,尤其是在一个习惯于功能分解的团队中,他们的用例名称读起来就象是一个系统所执行的功能的列表,如“输入订单”、“审查订单”、“取消订单”、“履行订单”,这起先听起来也不是很坏,但不仅仅这些。即使对于一个小规模的订购系统,用例列表也很容易达到上百个,如果谁走到了这一步,他们不久就会淹死在用例的海洋中,尤其是当系统规模确实比较大时,在这种情况下,你最终也许会有几百个,甚至上前个用例。
这么做有什么错呢?
这些用例的价值将会被错过。用例的唯一目的是为参与者产生价值。在一定层次上能够输入订单也是某种有价值的事情,但是,如果这些订单从来不被履行,那还有价值吗?也许没有吧。
怎样输入订单、修改订单以及取消订单等等,所有这些事情都是与客户真正想要做的事情有关的,那就是接受订购的货物。这些活动对公司想要的事情是必须的,那就是收到货款。
这种看起来是支离破碎的没有任何明显关系的功能集合的另一个问题是导致难以使用的系统。很多系统跟这个很类似,它们只是一堆杂乱的特性。记住,用例帮助我们关注与什么是真正重要的,也就是具有真正价值的事物,并且使我们能够围绕那些元素来定义系统。用例不要是系统按照功能分解的蓝图。
举例
考虑一个你在互联网上用过的一个电子商务系统,当你登录这个站点的时候,你的目标可能是查找产品相关的信息、选择要购买的产品、安排支付及送货约定。在做这些事的过程当中,你可能会改变主意、输入错误的信息以至不得不修改它、改变邮递或送货地址,以及其他的一些东西。如果这个网站不允许你通过一种吸引人的方式来找到并订购产品,你也许不会完成你的订购,更不用说再次来到这个网站。
当建造一个系统时,始终要记住用例的核心定义:关于采用某种方式使用系统来做有价值的事情的故事。如果你能够实施这个定义,展示用户希望通过系统获得的价值,然后创建反映这些价值的用例的时候,你的系统将会更好地满足用户的期望。
From:
相关推荐
测试用例的编写整理的还不是太全面,请各位大侠多多指导,谢谢
测试用例不是每个人都可以编写的,测试用例的设计者需要需要对产品的设计、功能规格说明书、用户场景以及程序/模块的结构都有比较透彻的了解。 测试用例的种类 测试用例可以分为边界测试用例、功能测试用例、设置...
测试用例不是一次性的,随着软件迭代和需求变化,测试用例必须相应地更新和完善。新的功能需要添加对应的测试用例,已有的测试用例可能需要根据实际测试和用户反馈进行调整。每次修改都应有记录,以跟踪测试用例的...
- 用例图关注于系统的“做什么”而不是“怎么做”,即它关注于系统功能,而不是实现细节。 - 用例可以重用,不同的用例可以通过包含关系被复用。 - 泛化关系使得特殊化的用例可以继承一般用例的行为,增加系统的灵活...
5. **用例维护与更新**:测试用例不是静态的,随着产品的迭代和需求的变化,应及时更新和维护用例,确保其持续有效。 #### 三、测试用例管理与优化 - **重复与错误处理**:发现重复或错误的测试用例时,应通知相关...
10. **持续优化**:测试用例不是一成不变的,随着软件的发展,应定期评估并更新测试用例,确保其始终与软件的最新状态保持一致。 以上是关于“测试用例编写技巧”的核心要点,通过理解和实践这些技巧,可以提升测试...
5. **持续优化**:优先级划分不是一次性的工作,随着项目的进展、需求变更、用户反馈的积累,需要不断调整和优化测试用例的优先级。 6. **文档记录**:确保所有划分的优先级都清晰记录在测试计划或相关文档中,便于...
测试用例的目的是提示自己不要忘记了要测试哪些项,而不是为了让别人看懂。 刚开始做测试的时候如何学习写测试用例 刚开始做测试的时候,需要学习测试流程、文档和测试用例的编写。可以通过上网搜索测试资料,学习...
1. 需要评审的原因:测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同,所以用例的质量难免会有不同程度的差异。 2. 进行评审的时机:一般会有...
3. **测试用例所测试的代码**:使用被测单元的功能和测试用例设计中使用的分析来说明,比如哪些决策条件被测试。 4. **期望的输出结果**:这些结果应该在测试开始前在测试文档中定义清楚。 接下来是测试用例设计的...
店铺管理是卖家的重要功能之一,但对于普通用户来说不是必须的。 6. **预置条件:** - 用户已经登录并进入了店铺管理界面。 7. **操作步骤:** - 启动系统; - 登录进入系统; - 点击进入店铺管理界面; - ...
**用例模型**是UML中非常重要的概念之一,它描述了系统具备的功能即“做什么”,通常由用户(执行者)和用例构成。 - **执行者**:系统的直接使用者,也可以是与系统有交互作用的外界系统。 - **用例**:定义了用户...
“LLT”可能是指轻量级低级测试,这是一种专注于底层功能和性能的测试方法,它关注于代码的内部结构和行为,而不是用户界面或业务逻辑。在Java测试用例工具中,可能集成了对LLT的支持,使得开发者可以更轻松地进行这...
该工具提供了XML和Excel文件之间的转换功能,使得用户能够更灵活地导入和导出测试用例,提高工作效率。 首先,我们要理解XML文件和Excel文件在测试用例管理中的作用。XML是一种可扩展标记语言,通常用于存储和传输...
这一步并不是直接编写测试用例,而是制定一套总的测试策略。例如,针对软件升级功能的测试思路可以包括: - **正常情况测试**:如正常网络条件下的升级过程、最新版本的升级提示机制等。 - **异常情况测试**:如在...