【测试知识】用例与业务用例的区别

系统需求以一条条孤立的特性的方式表现出来，如果系统相对复杂，用户可能就会发出如下的疑问：“系统到底能帮我做什么，怎么帮我做的？”。用例正好回答了这个问题。以用例的方式定义需求处处关心用户到底想用系统做什么，如何做。例如，上例中网上书店系统，用户到底用它做什么呢？购书！嗯，购书就是其中的一个用例。接着，在购书这个用例中就会具体描述用户怎样和系统交互并最终完成购书过程。基本事件流示意如下：

1、用户准备在网上书店购书，用例开始。
2、用户浏览图书分类，查找图书。系统显示分类、子分类以及子分类下的图书。
3、用户选择准备购买的图书，并加入购物车。系统记录已加入购物车的图书并计算价格。
4、用户准备结账，系统提示确认购物清单，并提示输入银行账号、送货地址等关键信息。
5、用户输入以上信息，并确认。系统完成交易，并显示交易信息。用例结束。

二、用例不是功能也不是特性，用例不能被逐层分解为更小的用例。
　　用例的价值在于展现系统最终能帮用户做什么以及如何做到的。如果我们试图分解用例，那么谁去承担这个责任呢？最终结果与以特性方式定义需求相比又能有什么优越性呢。
　　在FDD方法中，提倡将基于特性的需求描述方式改进为以特性集的方式来描述需求，即将任务相关性强的特性组织在一起。在XP中，需求以用户故事的方式来描述，即以相对随意的方式描述用户怎么使用系统完成任务。可见关注用户任务的整体性并不是用例特有的。只是用例方法更为形式化一些。

五、用例不是需求的唯一定义形式，用例需要和其他需求定义形式一起定义完整的需求。
　　用例较其他需求方法具有优越性，但只使用用例是无法有效地定义完整的需求。用例主要定义的是功能性和行为性的需求，系统还有大量的非功能性需求需要定义，如易用性、性能、可支持性等等。这些需求以用例的方式定义都是不可行的，而定义他们最好的形式还应该是特性。
　　另外对于一些功能性需求，可能也不适合使用用例来定义，如系统对外提供的服务接口等。而对于一些不与参与者交互的中间件产品中的大量需求尤其不适合使用用例定义。其需求定义的方式使用特性更为合适。

以上大致描述的什么是用例，用例有什么特点。实践中总是有人分不清用例和业务用例。业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许就是一个业务参与者（如果你准备作住房公积金贷款）。那么办理住房公积金贷款就是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：
1、职工准备相关资料去住房公积金中心办理货款。业务用例开始。
2、职工向中心提交准备贷款的相关资料，中心工作人员对资料进行初审。
3、若审核通过，职工准备办理抵押合同，中心工作人员委托担保公司与职工签订抵押合同。
4、担保办理完成后，职工与中心签订理借款合同，中心工作人员要求职工办理银行卡并提供卡号。
5、借款合同签订后，中心工作人员要求贷款合同必须办理公证，职工与中心一道办理公证。
6、职工办理完公证后，中心发放贷款。业务用例结束。
　　可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。

【测试随笔】一个老测试员对软件测试理解

1、你的衣服和熟人撞衫了，你会：
继续穿→2
不穿了→6
不一定会怎样→4

2、钱紧的时候，有朋友生日聚会，你会：
勉强自己参加→7
尽量推掉→3
借钱也要应酬→5

4、你有定期存钱的习惯吗？
有→7
没有→3
不一定→11

5、其他方面你未必会省，但是在吃方面你就比较会省了吗？
是的→8
不是→13
还好→12

6、你喜欢买一些摆设，饰品吗？
喜欢→10
不喜欢→3
还好→5

7、对下面哪种书，你比较感兴趣？
历史书籍→9
社科书籍→14
小说→12

8、你很讨厌烫衣服，所以经常穿皱巴巴的衣服吗？
是的→16
不是→15
还好→19