软件测试

收藏 / 订阅

用例分析技术小结

  前言

  现在RUP如日中天,需求分析是第一步,可以看作是高级系统分析员的必备知识,那么,如果用面向对象的分析技术来描述需求呢?

  在一个需求分析过程中,主要有项目描述,风险分析,用例图以及描述,项目建议这几部分。

  其中最重要的,也是最需要学习的就是用例的描述。那么用例的描述关键点在哪里呢?

  确定系统边界

  确定清晰的系统边界,就是要确定系统中有什么?系统外有什么?通过执行者和用例来确定系统边界。

  那么,我们第一步就是要找出执行者,执行者是一个角色,我们可以根据以下几个问题来思考决定一下:谁在使用系统?谁在维护?谁在启动?谁在关闭?谁从这个系统获得信息?谁为这个系统提供信息?是否有自动的事情在预计时间发生?等等方式,来确定执行者。

  找出了执行者,那就要确定用例,用例是系统的一个行为,为执行者产生可以估量的价值结果。

  用例的描述一般都是动名词结构。

  需要构建一张表,清楚的以名词解释的形式,把用例和执行者进行简单的定义。

  如果用例图过于大,那就分开,也可以采用包的形式。

  其中用例图的中的箭头表示是单向还是双向,要根据交付的信息看。

  如果是外部定时发生的事情,可以把时间也作为执行者。

  需求在系统之内,无法被执行者看到,那么这个需求就不用在用例图中体现。

  归档用例

  归档用例就是把用例用文档的方式表示。基本用例主要包括:前置条件(前置条件就是用例开始时候,必须要处在一个什么状态) 后置条件(用例结束,系统处在什么状态)事件流。(事件流是一系列的陈述句)。

  事件流中包含一些循环语句。可以采用for ,while循环。

  用例是一个传达工具,只有向读者传达系统如何工作的时候才有效。

  用例要从执行者的观点来写。

  对于非事件流的需求,可以在用例的特殊需求中描述。

  事件流分为两部分:基本路径和可选路径。

  一切正常运转就是基本路径。

  不同于基本路径而允许选择不同的事件序列的路径,就是可选路径,也可以说各种异常情况的处理也是可选路径。

  可选路径,最好用不同的段落编号来标示。

  什么是场景? 场景就是一种贯穿用例的特定路径。

  用例的包含:如果你发现在写各种用例的时候,要经常copy同一部分的内容,那么就说明你有了一部分通用的行为,那么就可以用一种包含关系来抽象这种通用行为。包含用例一定要有被包含用例,这个用例才算完整。

  用例的扩展:在不改变原始用例的情况下,增加用例的行为。重要关注的一个概念是扩展点,当到达这个扩展点,如果条件为真,就是这个扩展条件的前置条件为真的话,这个扩展的步骤将被执行。

  用例的继承:用例的继承代表一个用例(子)是另外一个用例(父)的特殊实现,执行者的继承意味着一个执行者(子)可以完成另外一个执行者(父)的任务。

  接口:接口不是执行者和用例的一部分。接口是执行者和用例相互作用的一种描述。

  文档中的文字可以简洁的描述系统,那么有些文字分支很多的时候,采用图就是一个非常好的方式,图形化用例也是一个不错的手段。我们可以用三种图来细化和具体化用例。

  活动图:描述用例的步骤。活动图描述满足用例需求而进行的活动以及活动之间的关系。(有些书把活动图定义为状态图的子集)

  时序图:描述执行者和系统的相互作用。时序图中,每个实体下面有虚线,代表对象生命周期。确认的返回值,是采用虚线箭头来表示。

  在学会写用例以后,那就有一个问题,用例写到什么程度好呢? 就是用例细化到什么程度为好。要回答这个问题,需要考虑三个问题: 谁需要阅读并审批这个文档?谁需要使用这个文档?我们要这个文档做什么?用例可能是给最终用户和开发者的,或者管理者的,决定多少细节放到用例中是一个很重要的事情。可以对同一个用例做不同细节程度的版本,交给不同的人看,要注意维护这种对应关联关系。

  用例文档模板:

  包括系统简介,风险因素,系统级用例(一个或者多个反映系统中所有用例和执行者的图,没必要包含用例之间的关系,例如包含,扩展和泛化),体系结构,子用例,非功能性的需求包括可用性,系统,安全,持久性,冗余性,性能,规模,标准化等。

  可以通过活动图来描述和表现用例之间的关系和流程。

喜欢 (88) or分享 (0)
首页  上一页  12345678910  下一页 尾页 共73条记录 7/10

网友评论:7

  1. 小编 1年前 (2015-03-22) #5

    软件测试入门 :mrgreen:

留言主题 *

您的姓名 *

电子信箱:

电话号码:

请你留言: