UML从需求到实现?用例
作者:苦涩的茶 发布时间:[ 2017/3/1 14:17:48 ] 推荐标签:需求管理 测试用例
关于用例图的概念相信不用我去说了 .能看到这篇文章的都是知道用例图概念的人.
UML 中重要的是什么图呢 ?毫无疑问应该是用例图 ,用例是后期时序图 和实际开发的重要依据.
说明一下用例图是怎么产生的.了解他的产生对我们了解它本身有很大帮助,
首先用例产生在需求分析阶段 ,这这个阶段系统分析人员对用户对系统要求的理解 .也是用户的愿望的描述.有时候我们习惯把用例说成系统的功能.
但是.用例一定是系统的功能.但是功能不一定是系统的用例
比如系统要求我在断电的时候要把数据保存起来.但是这个能写在用例里面吗?当然不能
这只不过是系统的一个限制.不能算是一个完整的愿望.
接着说明一下用例的特点.然后根据特点来说明用例的建立过程
用例特点:
一:用例是相对独立完整的.一个用例不需要其他用例来完成和它进行交互.也是说.我在实现这个用例的过程中.不能出现做完用例1,然后才能做用例2.
比如
我们去买菜
显然第一个不是一个用例.给钱只是买菜的一部分.不能单独成为一个用例
二:用例的执行结果对于参与者来说是可见的.有意义的.
这句话的意思是说.一个用例必须有一个确定的结果.这个结果是有意思的.比如到银行取钱.
显然第一个不是一个用例.因为输入密码以后到底是什么结果.密码正确?还是错误.这些结果都是未知的.一个结果未知的过程.不能算做一个用例.
三:一个用例必须是由一个参与者发起.不存在没有角色的用例.用例也不该自动启动.
这个也是我们经常遇到的一个问题.
解决这个问题的时候.我们要首先确定用例边界.我们在那个范围之外去寻找用例.不同的范围会产生不同的用例.
比如我们要以系统为边界去确定用例.那么角色应该是系统之外的东西.不应该是系统.
比如:
显然ATM不是一个角色,我们设计的用例也不应该包括ATM出钱这个用例.ATM是我们系统的一个部分.他终出现在部署图上.像是我们的一台PC 一样.不在边界之外.
四:用例一定是动宾短语
比如:喝水 取钱 买菜 做饭等
因为这样才能构成一个完整的事件.角色是主语.动宾短语是动作和动作的受体.这样主,谓,宾都有了,才是一个完整的事件.
五:一个用例是一个需求单元,分析单元,设计单元,开发单元,测试单元.
设计完一个用例.我们接下来的工作都要以单个用例为主线去开发.测试.这样印证了开篇的那句话.用例对于开发来说是相当重要的.
那么用例是如何确定的呢?
一:确定系统的边界
二:确定业务主角.这个是重要的,也是常常困扰我们的地方.业务主角是与系统交互的人和事物.
让我们常常困惑的是.有些业务人员.他明明参加了业务.但是他却是被动参加的.不好说明他有什么目的.但是又确实是在系统中做了事情.
这样的业务人员.我们把它叫做业务工人 .不是业务主角.
区别他的办法是回答下面三个问题.
1:他是主动向系统发出请求的吗?
2:他是完整的业务目标吗?
3:系统为他服务吗?
三:参与者到角色的过度.
参与者是一个具体的概念.角色是一个抽象的概念.从众多的参与者当中,抽象出相同的一部分.形成一个角色.
比如:教授,副教授都可以讲课 ,把它们抽象出来.做出老师讲课.
后.检查是否找到了所有的参与者.
通过下面这些问题来做出测试:
1:是否对系统中的所有角色都进行了建模和说明
2:每个参与者是否至少涉及到一个用例
3:你是否列出至少两名可以作为特定参与者的人员
4:是否有两个参与者担任与用力相关的角色
5:参与者是否有直观的描述性名称
后将参与者和他们的愿望结合起来.形成了用例图.记得后形成的一定是一个完整的事情.由参与者做主语.用例做谓语和宾语.
PS:
用例图只是一些符号.抽象程度较高.一百个人看了也不一定结果相同.所以用例要附加相关的用例文档加以说明.
用例形成映射基本是用户界面(UI).这一点大家要清楚.不要做了用例.再回头从新找界面.
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11