用例技术(三)——用例在整个过程中的作用
一.用例在项目组织中的作用
用例指明了应提交给用户的系统功能,用例的标题指明了主执行者的需求,系统也必须包含这些需求,而用例描述则说明了系统需要什么功能以及提供什么服务
1.通过用例标题进行组织
项目早期可以通过以下用例表进行规划,投资方可以可以进行优先级评估,然后技术组进行技术及费用评估,这样便于后续各方评估,调整,也便于审核和操作,以及对工作跟踪等。
表 1-1.规划表示例:
|
执行者
|
任务级目标
|
业务需求
|
技术难度
|
优先级
|
UC#
|
|
买主
|
...
|
最高
|
工作量大
|
1
|
2
|
|
请求者
|
...
|
高
|
简单
|
2
|
3
|
|
授权者
|
...
|
中
|
复杂
|
3
|
5
|
|
接收者
|
...
|
低
|
中等
|
1
|
1
|
该表的好处:
(1)清晰的显示了系统对整个业务的价值。
(2)它为基于优先级的工作和时间提供了依据。
2.跨版本处理用例
如:在版本1中实现简单用例
在版本2中增加高风险处理
在版本3中增加客户推荐处理
针对上面过程,可以选择编写总用例,然后在每个版本中实现相关部分;或者编写三个用例,
3.交付完整场景
二、从用例到任务或特征列表
可用于项目评估,跟踪
例:
用例 30:获得折扣
文本目的:购物者有一个装有商品的购物车,当向其中加入折扣时,了解怎样影响车内商品价格。
范围:商业软件系统
层次:子功能级
前置条件:购物车内必须有商品
成功保证:折扣有价值,加入到购物车中,减少了车中商品价格。
最小保证:如果没完成,没获得折扣,或没加入购物车中。
主执行者:购物者(任何网上用户)
触发条件:客户选择了折扣
主成功场景:1.购物者选择了折扣。
2.通过向客户显示折扣价值信息并询问一系列问题,系统决定折扣的价值。显示的信息和问题取决于购物者对前面问题的回答,为了提高折扣业务上的可行性,问题和路径预先给定。
3.系统记载导购信息和折扣信息。
4.购物者重新查看商品及其价格,考虑是否购买。
5.购物者把折扣放入购物车。
6.系统把导购信息和折扣信息加入购物车中。
7.系统显示购物车中所有的商品和折扣,同时根据折扣重新计算总价格。购物者可以根据需要多次重复上述过程来获得不同价值的折扣,并根据意愿将其放入购物车。
扩展:
2a.在折扣放入购物车之前的任何时刻,客户都可以返回修改前面问题的答案。
5a.即使购物者没有把折扣放入购物车中,系统也保留导购信息
5b.购物者如果想让折扣用于购物车中一种特定的商品,那么购物者应该在购物车中指定一种可以打折的商品。
下面是由以上用例产生的工作列表:
表2-1:“获得折扣”任务列表
|
索引
|
特征
|
业务需求
|
版本
|
|
EC10
|
获得折扣
|
必需
|
1.0
|
|
EC10.1
|
提供让购物者把折扣放入车中的功能
|
必需
|
1.0
|
|
EC10.2
|
通过UI形式,提供显示和引导客户收集折扣信息,并确定其价值的功能。
|
必需
|
1.0
|
|
EC10.3
|
...
|
...
|
1.0
|
三、从用例到设计
从用例到设计的转变方法
-
不好的方法
-
设计不通过用例分组
-
盲目依靠用例,导致功能分解了设计
-
好的方法
-
在一些设计中利用各种场景
-
利用用例命名域建模中所需的概念
1.使用结构化分解技术,对用例功能分解可能有用,如果采用面向对象设计,则需要注意。
2.需求收集得益于功能分解,而软件设计得益于数据和行为构件化。
3.在任何情况下,用例都是按不同的组织来划分整个系统而不是对象。
4.利用场景设计,用例看作场景,特别适合于职责驱动的设计,是一种通过场景逐步式推进的设计方法。
5.利用用例命名域的概念,如以下短语:系统产生发货单,填充发货单项的价格,加上税费和运输费,计算商品总额。发货单脚注说明了交货条件,看到这些短语(发货单,发货单项,发货单脚注)以及他们的属性(价格,税费,运输费和总额),就能毫不费力的明白他们的含义.
四、用例到用户界面(UI)设计
五、用例到测试
正规的开发组,测试组应把用例分成多个测试集,并编写计划来确定触发不同路径的每个测试设置,构造用于测试这些设置的测试用例,然后设计不同的数据来测试不同的组合,最后,设计性能测试和负载测试。

浙公网安备 33010602011771号