系统用例和测试用例有关系吗

上次发表了一篇《为什么说用例设计在软件开发中很重要》，有一天有个同事找我说请教一个测试用例的问题。一开始我还奇怪，我也不是测试啊，为啥会问我这个？后来聊明白了，是他把测试用例和系统用例弄混了。我开始以为这只是个例，后来与更多的人交流发现还挺普遍的（苦笑）难道现在大家都不学UML了吗？

开个玩笑。也或许同事并不来自软件专业，anyway，今天我们来聊一聊“系统用例”和“测试用例”。

系统用例是什么

上一篇文章说过，用例分为场景用例 和系统用例。

场景用例 是站在最终用户的视角来看，某个产品给用户提供的功能或服务，举个例子：“发红包”就是微信的一个场景用例。对用户来说可能就只有发红包和抢红包这两个动作，但是其背后涉及到红包生成、抢红包的算法、关系链、用户余额加减、资金清算、账务等，设计场景用例就是在设计业务流程，不仅要关注前台功能，还要关注后台。

系统用例 则是某个单一系统对外提供的功能或服务，例如订单系统、红包系统、清算系统、物流系统。系统用例的参与者可以是最终用户，也可以是抽象的事物，一个系统用例可以看做是参与者与系统的一次交互行为的描述。比如对物流系统来说，“生成物流单”算一个用例，“分配派送员”也是一个用例。

系统用例有几个关键点：

• 参与者 Actor
• 系统边界 Boundary
• 用例间关系 Relationship
• 用例的流程描述（主流程和分支流程）

这些在《为什么说用例设计在软件开发中很重要》一文中都有提到，就不再赘述了

测试用例是什么

测试用例Test Case 是对软件测试行为的规范性描述，测试人员为了能更好地保障软件质量，管理测试计划，通常都会输出测试用例文档。

测试用例的关键点：

• 测试前置条件
• 测试步骤
• 预期结果

二者的联系

应该很容易能看出，系统用例和测试用例不是同一个事情，那二者是否有联系呢？那是当然的，并且二者的联系非常紧密！

测试人员最怕的是测试遗漏，漏测意味着某一些功能未经验证就带到了生产环境，将带来巨大风险，那么如何保证输出的测试用例是完整的？ 常见做法是输出用例文档后组织一次评审，评审当然可以，但需要所有关键人员都在场，且大家都认真参与其中。据我观察，很多开发人员对测试用例评审的参与度并不高，他们认为这是测试的事情。

那么在不依赖用例评审的情况下，测试人员有没有办法输出相对完整的测试用例？标准答案：可以在系统用例中获得。

系统用例分析和设计的过程就是在做一件事：说清楚一个系统具体包含了哪些功能，以及这些功能互相之间有什么关系。如果系统用例设计到位，甚至能直接用系统用例来推导出测试用例。

还是以上次说的用户买包子的例子说明，我把系统用例稍微再完善一下：

# 用户下单用例
主流程
1. 用户在页面上选择好要购买的包子，提交订单
2. 创建订单，校验库存是否充足，锁定库存
3. 选择支付方式，完成支付
4. 扣减库存，交易成功
5. 给用户加积分
6. 通知用户

分支流程1
2.1 如果库存不足，返回错误提示

分支流程2
3.1 如果选择用余额支付，且余额不足，返回错误提示

分支流程3
3.2 如果选择用第三方支付工具，且支付失败，返回错误提示

既然系统用例是表示参与者与系统的交互，那么测试用例的设计应该围绕着系统用例来展开，我把这句话翻译成更直白的描述：系统用例和测试用例是1：N的关系。

从上面的用例描述中应该不难看到，为了保证功能正常，测试用例应该覆盖到主流程和所有分支流程，所以这个例子中，应至少包含4个测试用例分别覆盖每一个分支流程，而且系统用例中已经包含了预期结果。Amazing！测试同学狂喜，这简直是把答案直接拍桌子上了！

另外，系统用例还有助于简化测试，比如说：

这里面多种不同的下单方式，都复用了“通知”这个扩展用例，那么就只需选择一种下单来验证通知的正确性即可。有些人说这样不够严谨，那至少可以针对“通知”的验证专门写一个验证方法，这个验证是可复用的，也是对测试效率的提升。

再次说明系统用例的重要性

关于系统用例和写代码的关系，已经在《为什么说用例设计在软件开发中很重要》中说过了，不再赘述。这里补充说明一下系统用例和单元测试(Unit Test)有什么关系？

单元测试应该按照什么维度来测试其实一直存在争议点，多数人是持这两种看法：

1. 单元测试就应该按类的维度去测，针对每个类的所有public方法都写单元测试，并且把对类外部的所有调用进行mock。这种方式的优点：单元测试很纯粹，覆盖率也很容易做到很高，缺点也很明显：要写很多测试用例，而且有些类的代码并非都有测试的价值
2. 另一种观点，单元测试按系统对外接口的维度去测，只需对系统外部的调用进行mock。优点：不用构造很多测试用例（其实这已经变成接口测试了，严格说不能算单测），缺点也相当明显：用例会很不稳定，随便改动一处就会影响一大堆用例；另外针对接口的测试粒度太粗了，无法覆盖到所有的分支

我这里提供了一种新的观点：针对系统用例去写单元测试，对本用例以外的调用进行mock。理由是：

1. 开发的时候就是按用例进行划分的，例如我开发的是“下单”用例，我就只需测下单，而不用测库存扣减、也不用测通知是否成功。从系统设计、到开发、到单测都保证交付一致性
2. 没有按类维度测试的缺点，按类维度测试不仅啰嗦，很多时候意义不大，例如对factory（工厂）做单测能保证什么呢？factory只是负责构造对象，对象构造得再完美也无法保证功能正常
3. 单测跟着系统用例走，可以保证单测相对稳定，系统用例变更了，单测就要跟着改，反之系统用例没有变更，单测就不用改。

希望这一篇文章能讲清楚系统用例的重要性，如果还是没懂，欢迎评论区交流。