1
00:00:00,000 --> 00:00:03,877
这里是第五章，测试的概述。

2
00:00:03,877 --> 00:00:07,807
这是Brian Kernighan，作家，贝尔实验室英雄之一

3
00:00:07,807 --> 00:00:12,055
Kernighan和Ritchie的C编程，可能你们大多数人都有这本书

4
00:00:12,055 --> 00:00:16,410
如果你读过这本书，你会明白，调试的难度要比写代码翻倍

5
00:00:16,410 --> 00:00:20,606
难度加倍！因此，如果你不能一次性写出优秀的代码

6
00:00:20,606 --> 00:00:24,802
你将永远没有能力去调试它，因为调试将加倍困难

7
00:00:24,802 --> 00:00:30,067
好了，这是 Dystra, 你来对这句话填空

8
00:00:30,067 --> 00:00:36,088
测试永远不会证明软件没有错误，而是错误的存在

9
00:00:36,088 --> 00:00:41,042
这句话对吗？好的，这句话由来已久了，需要牢记在心

10
00:00:41,042 --> 00:00:46,700
这里是一篇一年半前的文章

11
00:00:46,700 --> 00:00:51,922
它讨论为什么东西这么贵。在这里你可以看到，

12
00:00:51,922 --> 00:00:56,825
他们的研究显示，不是设计有bug，而是糟糕的测试

13
00:00:56,825 --> 00:01:02,110
糟糕的测试流程是代码有如此多bug的原因

14
00:01:02,110 --> 00:01:07,013
文章说，完全自动化的测试环境几乎没有

15
00:01:07,013 --> 00:01:11,534
这是一年半前。现在，我们也刚刚有20%

16
00:01:11,534 --> 00:01:16,707
12%软件的组织已经完全自动化的测试系统

17
00:01:16,707 --> 00:01:21,023
10%的软件组织手工完成所有测试。你编写测试，看测试结果

18
00:01:21,023 --> 00:01:25,225
你编写测试，再看一下结果。有发现什么错误吗？

19
00:01:25,225 --> 00:01:29,852
哇，不敢相信，依然是对的。其实这里是不对的。[笑]

20
00:01:29,852 --> 00:01:35,086
你知道吗，在敏捷开发之前，首先你有独立的质量保证团队

21
00:01:35,086 --> 00:01:40,133
有所有这些阶段和单独的团队。这样，Marge，某种意义上，

22
00:01:40,133 --> 00:01:44,805
质量保证团队是要在你的代码中插入质量。[笑]

23
00:01:44,805 --> 00:01:49,727
或者确保你的代码的质量。在敏捷式开发中，这是我们要做的一部分

24
00:01:49,727 --> 00:01:54,260
我们不断测试。每个星期，我们产出新的代码。

25
00:01:54,260 --> 00:01:58,888
你负责测试你的代码，没有别人。而且这些工具高度自动化

26
00:01:58,888 --> 00:02:03,816
这和之前所说的做法不太一样

27
00:02:03,816 --> 00:02:08,444
敏捷宣言中有争议的是，

28
00:02:08,444 --> 00:02:13,493
是否一个好的过程就能带来软件质量

29
00:02:13,493 --> 00:02:20,141
而不是由特定的团队来追着你保证质量

30
00:02:20,141 --> 00:02:25,636
前面提到过BDD和TDD

31
00:02:25,636 --> 00:02:30,859
一些人明白行为驱动设计，但是不清楚测试驱动开发

32
00:02:30,859 --> 00:02:36,286
这里我们测试，验收测试、 集成测试，并试图捕获行为。

33
00:02:36,286 --> 00:02:41,849
Tdd 是一个步骤的定义，在写代码之前先写单元测试和功能测试

34
00:02:41,849 --> 00:02:47,208
所以，这就是定义。所以，好处是你总是使用最新的测试

35
00:02:47,208 --> 00:02:52,485
因为你先编写测试代码。所以这就是是他们如何一起工作的

36
00:02:52,485 --> 00:02:56,992
Cucumber 用于描述行为和特性

37
00:02:56,992 --> 00:03:01,564
你开始编写故事点。当它们失败时，调用的RSpec的测试实现

38
00:03:01,564 --> 00:03:06,265
如果失败，你就补充实现缺失的方法

39
00:03:06,265 --> 00:03:10,901
当它通过测试，继续内部迭代

40
00:03:10,901 --> 00:03:15,988
直到通过RSpec。

41
00:03:15,988 --> 00:03:20,946
一旦你完成一个特性，就会通过cucumber的绿色步骤，返回

42
00:03:20,946 --> 00:03:23,200
继续开发下去