小酋家水龙头坏了！怎么办？
联系物业吧，物业立马派了一个师傅过来处理，发现是水管接头年久坏了，换了一个新的搞定。
这是最理想的状况。
然而，真实场景可能是：
- 物业直接说不在他们的服务范围，直接拒绝派人；
- 小酋威胁不交物业费（这招很管用，都用过？），物业肯派人了，但师傅活满了，直接安排到明天；
- 这水哗啦哗啦的流不是办法，除非不用水。经过几番扯皮，物业终于肯派师傅从万忙中紧急上门处理，但师傅说没有适合的接头为理由打算结束工单；
- 小酋急了，直接叮叮咚咚的跑到楼下五金店买了个新接头摆在师傅的面前。好吧，终于经过反复折腾把水龙头修好了。
废话开篇，到此回到本章看点：用例设计之场景分析法。
小酋开篇说的真是废话吗？
让我们看完后再回答这个问题。
测试与现实场景息息相关。
场景分析法 当我们分析软件的应用场景时，站在用户的视角，去探索不同场景下用户会如何使用该软件，进而分析设计测试用例。场景设计是一种面向用户的测试设计方法。
首先，看看场景分析法的3个基本概念：
事件流
软件基本都是通过事件（如点击、滑动、时间到点等）来驱动的，事件触发时的上下文（情景）便成为场景。同一事件通过不同的触发顺序就形成了事件流。
基本流
软件功能按照最短的事件流实现的一条正确流程，那么我们就把这个流程称为软件的基本流（或主流程）。
备选流
凡是出现异常或缺陷或其他原因导致最终的目的不能实现或实现的流程并非最短，那么该流程就叫做备选流（或分支流程）。
下面，来一张场景分析法的经典图例：
当软件中用户操作步骤较多，而用户的不同操作导致程序的不同处理结果。这时可以用到场景法，即基于用户对事件的触发，对事件流进行分析。
场景设计流程
- 根据说明，描述出程序的基本流和备选流。
- 根据基本流和备选流生成不同的场景。
- 对每一个场景生成相应的测试用例。
- 对生成的测试用例进行审查，去重。
下面回到开篇小酋修水龙头，假如我家的物业有个APP（实际小酋家真有，不豁你~）
简单描述下需求：
用户可以通过物业APP提交报修，物业分配师傅处理或改派时间，当师傅处理完后用户确认结果后结清费用完结工单。其中：用户提交报修内容不在物业服务范围内，提交报修失败；用户可以对处理结果进行申诉，申诉后物业重新受理。
基本流：
小酋提交报修，物业受理安排师傅处理完后，结清费用后完结工单；
备选流：
小酋提交报修，但报修内容不在物业服务范围，报修失败；
小酋提交报修，但师傅安排已满工单改派到明天，小酋耐心等待后进入后续报修流程；
小酋对物业处理结果不满意，对处理工单进行了申诉，物业重新受理，小酋得偿所愿的当天修好了水龙头；
……（实际的报修系统，还有更多的备选流，按照这个思路下去就行）
后面就是用例的编写了，可以是：
注意，当场景复杂时，应该对其进行拆分，如上面CASE3。
最后，小酋想说：
我们进行测试时，一定要代入用户情景（即场景），这样才能发现更多的缺陷。通过情景联系，我们也可以在需求设计阶段，提出一些很现实的问题。就如报修，在真实情景中，可能会有子女代老人报修的情况；老人无法通过微信、支付宝线上结清费用的情况；等等。这些都是我们做一个好用的物业系统需要考虑的现实问题。也是小酋下篇谈错误猜想法中，猜想的着眼点之一。
关注小酋微信公众号 ceshibuluo （51ste软件测试部落），更多精彩内容等着你~