[图解]用例规约之扩展路径

1
00:00:01,710 --> 00:00:03,670
基本路径写完之后

2
00:00:04,690 --> 00:00:07,270
接下来就是扩展路径

3
00:00:08,620 --> 00:00:14,000
扩展路径就是系统要处理的意外和分支

4
00:00:14,010 --> 00:00:19,710
系统要处理的

5
00:00:20,970 --> 00:00:22,370
不处理的不算的

6
00:00:23,100 --> 00:00:28,700
也就是说，扩展路径也是系统的需求之一

7
00:00:29,860 --> 00:00:31,980
它是系统不得不这样做的

8
00:00:35,890 --> 00:00:37,500
那么扩展路径

9
00:00:38,860 --> 00:00:43,060
经常在什么地方出现，这么几个地方

1
00:00:02,200 --> 00:00:04,160
第一个是执行者的选择

2
00:00:05,680 --> 00:00:07,310
当执行者作出判断

3
00:00:07,320 --> 00:00:09,190
说有几条路要走

4
00:00:09,560 --> 00:00:11,440
那么这个判断由他来做的时候

5
00:00:12,450 --> 00:00:16,560
那么这个时候他到底选哪条路

6
00:00:17,280 --> 00:00:18,680
系统是没法判断的

7
00:00:19,340 --> 00:00:21,490
完全由执行者主动来选择

8
00:00:22,820 --> 00:00:23,700
这是第一种

9
00:00:25,440 --> 00:00:26,490
但这种要慎用

10
00:00:28,690 --> 00:00:30,080
因为很容易变成什么

11
00:00:31,090 --> 00:00:32,730
所有的可选项都是扩展了

12
00:00:32,940 --> 00:00:34,960
我们后面书上有讲

13
00:00:34,970 --> 00:00:36,760
后面幻灯片也会提到

14
00:00:37,070 --> 00:00:38,910
不过一会时间不够的话

15
00:00:38,920 --> 00:00:40,630
可能未必有时间讲

16
00:00:42,880 --> 00:00:43,990
大家可以自己看书

17
00:00:45,310 --> 00:00:49,880
很容易犯 把选项当成扩展点 的这种情况

18
00:00:51,890 --> 00:00:55,650
第二个，系统验证，这个一般都会有了

19
00:00:56,180 --> 00:00:59,240
因为你验证的目的是干嘛

20
00:00:59,250 --> 00:01:01,070
你验证肯定有结果

21
00:01:01,080 --> 00:01:03,190
结果必然有成功有失败

22
00:01:04,700 --> 00:01:05,820
那失败了怎么办呢

23
00:01:07,770 --> 00:01:10,010
你肯定得做一些不一样的事情

24
00:01:10,140 --> 00:01:10,570

25
00:01:10,970 --> 00:01:13,680
如果失败跟成功是一样的

26
00:01:15,640 --> 00:01:19,360
你验证它干什么，白搞嘛

27
00:01:21,170 --> 00:01:23,640
这是第二种

28
00:01:24,590 --> 00:01:28,420
第三种，就是步骤的失败

29
00:01:31,360 --> 00:01:32,970
而且是系统要处理的

30
00:01:35,990 --> 00:01:37,860
那么这里面我们要注意了

31
00:01:39,390 --> 00:01:41,620
系统能感知而且要处理的

32
00:01:44,380 --> 00:01:47,580
什么叫要处理的失败，就是系统能处理

33
00:01:48,690 --> 00:01:51,260
而且乐意处理的

34
00:01:52,370 --> 00:01:53,560
感兴趣去处理的

35
00:01:54,710 --> 00:01:58,750
比如说，我们做一个电子商务系统

36
00:02:00,770 --> 00:02:04,010
然后，正在下单过程中

37
00:02:07,600 --> 00:02:09,440
系统要保存订单

38
00:02:09,450 --> 00:02:11,240
有一句，系统保存订单

39
00:02:14,540 --> 00:02:15,810
保存订单失败

40
00:02:17,010 --> 00:02:18,010
算不算扩展

41
00:02:20,670 --> 00:02:21,880
保存订单会失败吗

42
00:02:23,070 --> 00:02:23,550
会的

43
00:02:25,090 --> 00:02:25,650
怎么失败

44
00:02:27,420 --> 00:02:28,680
数据库坏了

45
00:02:29,340 --> 00:02:31,330
网络断了，等等

46
00:02:31,620 --> 00:02:32,650
代码写错了

47
00:02:34,540 --> 00:02:35,780
但是这个算不算扩展

48
00:02:36,270 --> 00:02:37,320
不算，为什么

49
00:02:39,150 --> 00:02:41,150
因为这个跟需求没有关系

50
00:02:45,320 --> 00:02:48,270
我们在讲愿景的时候

51
00:02:48,280 --> 00:02:51,980
我们说过，我们做需求的时候

52
00:02:53,340 --> 00:02:54,890
要把我们的系统看作是什么

53
00:02:56,700 --> 00:02:58,020
由外星人来做的

54
00:02:59,760 --> 00:03:02,020
外星人的网络会不会出问题

55
00:03:02,810 --> 00:03:06,380
外星人的硬盘会不会出问题

56
00:03:07,070 --> 00:03:08,510
外星人的代码会不会写错

57
00:03:09,390 --> 00:03:10,050
不会的

58
00:03:13,380 --> 00:03:18,590
所以这种由于程序员的能力不足

59
00:03:19,410 --> 00:03:20,600
带来的这种错误

60
00:03:21,620 --> 00:03:22,660
它不是扩展

61
00:03:24,260 --> 00:03:25,040
扩展是什么

62
00:03:25,590 --> 00:03:29,700
即使这个系统的代码是外星人写的

63
00:03:31,390 --> 00:03:33,540
而且这个系统是外星人部署的

64
00:03:36,270 --> 00:03:39,160
依然逃脱不了这种意外

65
00:03:42,010 --> 00:03:44,460
就拿我们前面讲取款机这个来说

66
00:03:46,480 --> 00:03:48,240
取款机，你插卡输密码

67
00:03:49,380 --> 00:03:50,130
密码不对

68
00:03:51,540 --> 00:03:53,190
那就要拒绝

69
00:03:54,440 --> 00:03:55,660
这可以看做一个扩展

70
00:03:58,050 --> 00:04:01,090
假设取款机的代码是外星人写的

71
00:04:01,880 --> 00:04:04,590
按照我们需求规约去写代码

72
00:04:07,580 --> 00:04:09,390
那么这个意外能避免吗

73
00:04:09,630 --> 00:04:10,010
不能

74
00:04:12,100 --> 00:04:12,510

75
00:04:12,970 --> 00:04:14,260
因为你根本不知道

76
00:04:14,270 --> 00:04:18,080
我外面那个储户要输什么密码

77
00:04:20,410 --> 00:04:23,100
外星人写的只是取款机的代码

78
00:04:23,110 --> 00:04:25,460
他并没有写储户的代码

79
00:04:28,620 --> 00:04:30,090
他管不着外面的储户

80
00:04:31,740 --> 00:04:35,130
这属于他控制的边界范围之外

81
00:04:36,410 --> 00:04:37,830
那么这个就是扩展

82
00:04:40,010 --> 00:04:41,110
因为这属于什么

83
00:04:43,080 --> 00:04:44,640
就算你代码一点错都没有

84
00:04:44,650 --> 00:04:46,240
什么网络什么都通畅的

85
00:04:46,610 --> 00:04:49,380
这样的意外依然不能避免

86
00:04:49,860 --> 00:04:52,720
而且这个意外，系统要处理的

87
00:04:54,110 --> 00:04:54,990
其他都不是的

88
00:04:57,070 --> 00:04:59,130
刚才我们说那种什么网络断了

89
00:05:00,110 --> 00:05:02,150
数据库设计出问题了

90
00:05:03,280 --> 00:05:04,940
程序员编码编错了

91
00:05:06,560 --> 00:05:07,670
像这种问题怎么样

92
00:05:08,670 --> 00:05:13,230
它跟特定的系统，跟特定领域是没有关系的

93
00:05:15,020 --> 00:05:17,570
所有的系统，所有的用例

94
00:05:18,040 --> 00:05:20,080
只要你这个程序员能力有问题

95
00:05:20,090 --> 00:05:21,480
都会出这种问题

96
00:05:21,490 --> 00:05:22,500

97
00:05:27,940 --> 00:05:29,250
步骤失败这个，要注意

98
00:05:30,030 --> 00:05:32,070
必须是需求的这种失败

99
00:05:32,080 --> 00:05:37,310
而不是说我们设计人员能力不足带来的

100
00:05:38,430 --> 00:05:41,100
但我们很多人喜欢把这种当成需求

101
00:05:41,110 --> 00:05:41,620
为什么

102
00:05:42,700 --> 00:05:44,560
这样的话，需求规约就丰满了

103
00:05:45,370 --> 00:05:46,450
他每个用例都写

104
00:05:46,460 --> 00:05:47,770
每一步都写失败

105
00:05:48,640 --> 00:05:49,390
保存，保存失败

106
00:05:50,310 --> 00:05:53,070
显示什么，也显示失败，为什么

107
00:05:54,060 --> 00:05:54,980
为什么会显示失败

108
00:05:56,560 --> 00:05:58,450
网页切错了

109
00:05:58,460 --> 00:06:00,760
我前端程序员能力不足

110
00:06:01,800 --> 00:06:02,750
网页写错了

111
00:06:03,830 --> 00:06:05,790
但是这跟需求没关系的

112
00:06:06,820 --> 00:06:07,720
这个要注意