`

用例不是“功能”

    博客分类:
  • UML
阅读更多

用例不是“功能”

 

多数人从用例开始就走入了迷途,也许是用例图和数据流图的相似性导致人们把用例定义为简单的功能或者菜单项。不论原因是什么,这都是新手最容易犯的错误。

 

图 1 错误的方式:用例是菜单项或者功能

 

这幅图有什么错误?用最简单的定义,我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义,是不是所有的“用例”都是独立的有用的呢?

答案当然是不是,在这个例子中,用例表示了系统需要做的所有的事情,但是他们也描述了用户需要通过系统去做的一件单独的事情:定购。所有保留的元素都是这一个用例的备选支流,它们是在定购时可能发生的步骤。在只做一件有用的事情的地方,只应该有一个用例。图1就是一个功能分解的例子,或者“四轮马车”格式的例子――一个参与者在中间,周围是一圈用例。

这是一个常见的问题,为什么人们会陷入这个陷阱呢?我们有一个有对定购的内在需要,并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下,我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时,实际上会把问题复杂化。

问题在这里

用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情,它描述了系统在概念层次上做什么,使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。

再看看图1,现在问你自己,如果我从来没有定购过,我想通过系统查询定单的状态吗?这是不太可能的。或者如果我从来没有定购过,我想变更订单吗?不,也许不。通常这些东西只有当我订购过的时候才对我有用。然而,为了系统能够允许我订购,这些都是必要的。

把系统分解为越来越小的用例模糊了系统的真实目的,极端情况下,我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车,或许你会说这是辆汽车,你也知道零件们是有用的,但是你确实不能说明他们如何组装在一起。

当使用用例的时候,记住用例是考虑整个系统的一种方式,并且要组织成可管理的功能块,这些功能块完成一些有价值的事情。为了得到正确的用例集合,问你自己一个问题:“参与者实际上想使用系统做什么?”

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

File:O p2ssss.jpg

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

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

关注价值

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

这么做有什么错呢?

这些用例的价值将会被错过。用例的唯一目的是为参与者产生价值。在一定层次上能够输入订单也是某种有价值的事情,但是,如果这些订单从来不被履行,那还有价值吗?也许没有吧。
怎样输入订单、修改订单以及取消订单等等,所有这些事情都是与客户真正想要做的事情有关的,那就是接受订购的货物。这些活动对公司想要的事情是必须的,那就是收到货款。

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

举例

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

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

From:

http://isse.cqu.edu.cn/wiki/index.php/%E7%94%A8%E4%BE%8B%E4%B8%8D%E6%98%AF%E2%80%9C%E5%8A%9F%E8%83%BD%E2%80%9D

分享到:
评论

相关推荐

    测试用例以及功能点

    测试用例的编写整理的还不是太全面,请各位大侠多多指导,谢谢

    点名系统用例图及用例规约

    用例描述:本用例用于向用户提供注册功能。... 执行者 所有用户 相关用例 ...前置条件 系统中存在用户的基本信息...由于第一次设计点名系统,很多细节还不是很清楚,所以有些功能不是太完善,如注册时要求用户输入什么信息。

    系统需求分析UML用例描述模板

    但应当强调的是 实用上更重要的是专注于写出完整的可理解的事件路径 而不是按指定的模板填写每个部分 ">是一种被广泛使用的用于发现和记录需求 特别是功能需求 的机制 写出用例是一种最好的理解和描述需求的技巧 ...

    软件测试用例设计基本点(参考文件)

    从理论上讲了一些测试用例,不是一个完整的实例,可以给你一些概念和思路。

    按照业务流和数据流写测试用例

     作为一个完整的详细设计书,它应该写清楚数据的增删改查,当然很多详细设计书没有写到这种程度,可是我们换个角度想,开发人员也是在这种不是很详细的设计下进行开发的,他们要根据式样的理解,写出满足条件的SQL...

    关于自动化软件测试用例设计的几点分析

    误区:1、不编写测试用例直接投入测试脚本编写。...1、不是所有的手工用例都要转为自动化测试用例。2、考虑到脚本开发的成本,不要选择流程太复杂的用例。如果有必要,可以考虑把流程拆分多个用例来实现脚本

    设计测试用例的四条原则

    测试用例设计的最基本要求:覆盖住所要测试的功能。这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、...

    Reference-Functions:可以用于某些用例的某些功能

    参考功能可以用于某些用例的某些功能我可能想要(重新)用于项目的常规功能此处提供的基本框架和每个功能的说明。功能将根据其功能进行存储:一般功能Tensorflow特定的常规功能探索性分析常规预处理文字预处理特征...

    设计软件测试用例需要遵循的四条原则

    测试用例设计的最基本要求:覆盖住所要测试的功能。这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、...

    基于用户输入的RationalFunctionalTester测试用例自动选择和执行工具

    解决方案总结下载参考资料用户在验证缺陷修补的过程或者在回归测试的项目中,常常需要从一个自动测试用例的全集合中选取某些测试用例来执行,而不是运行自动测试用例全集合。本文针对IBMRationalFunctionalTester...

    Matlab项目实战+兼容有限元(CoFE)+结构分析和优化的有限元求解器(含源代码+用户手册+实例+测试用例)

    资源内容:源代码+用户手册+实例+测试用例 运行环境:Matlab 2019b; 功能应用:CoFE从Nastran格式的输入文件中读取输入,解决指定的分析案例,创建包含模型和解决方案数据的MATLAB工作空间变量,编写人类可读的...

    软件测试用例几个认识误区

    软件测试用例几个认识误区软件测试误区之一:测试输入数据设计方法等同于测试用例...这种表述是很片面的,这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法,而不是测试用例设计的全部内容。 这种认识

    测试用例设计与管理思路经验总结

    火龙果软件工程技术中心 已经很久没有写过case了,结合以前编写用例的一些经验,其实觉得编写用例也还是有流程可走的(当然不是按照教科书上说的那样进行用例设计,姑且不说有多少企业会有那么详细的需求书,会有...

    tasty-expected-failure:将测试用例标记为预期失败

    使用提供的模块ExpectedFailure的功能expectFail ,您可以标记您期望测试用例失败,并且不通过。 例如,这可以用于测试驱动的开发:创建测试,将它们标记为expectFail ,您仍然可以推送到主分支,而不会导致连续...

    第5章 用例和用例图.ppt

    UML用例图是软件产品外部特性描述的视图,它从用户的角度而不是开发者的角度来描述软件产品的需求,分析软件产品所需的功能和行为。用例图主要描述了系统需要实现的功能,而忽略系统是如何实现这些功能的。

    软件系统规模估算方法论介绍-功能点分析法

    本文不是泛泛的理论介绍,而是从实际应用角度出发,对功能点估算法进行介绍,加入了较多的评论和观点,具备实用价值。 章节目录如下:背景、概述、简介、基本概念、计算方法、延伸计算、优缺点、总结。 应用场景 1....

    功能测试(黑盒测试)常用的策略和方法

     采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。  黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并...

    学生成绩管理系统需求规格说明书(教学用例)

    由于时间比较短,使用计算机不方便以及对于网络编程不是很熟悉,因此本学生成绩管理系统并没有提供数据的远程访问功能。对于信息的保护手段仅限于设置用户级别,以及提供数据文件的备份,比较简单,安全性能有待...

    测试过程总结(用例,执行,沟通)

    测试过程总结(用例,执行,沟通) 软件测试 1、测试过程中...2、测试用例里没有区分用例的重要级别,输入数据及预置条件不是很准确。(建议:在写测试用例的时候,要注意分清楚测试用例的重要等级(H、M、L),在后期的

Global site tag (gtag.js) - Google Analytics