WEBVTT

00:00:00.000 --> 00:00:03.877
这里是第五章，测试的概述。

00:00:03.877 --> 00:00:07.807
这是Brian Kernighan，作家，贝尔实验室英雄之一

00:00:07.807 --> 00:00:12.055
Kernighan和Ritchie的C编程，可能你们大多数人都有这本书

00:00:12.055 --> 00:00:16.410
如果你读过这本书，你会明白，调试的难度要比写代码翻倍

00:00:16.410 --> 00:00:20.606
难度加倍！因此，如果你不能一次性写出优秀的代码

00:00:20.606 --> 00:00:24.802
你将永远没有能力去调试它，因为调试将加倍困难

00:00:24.802 --> 00:00:30.067
好了，这是 Dystra, 你来对这句话填空

00:00:30.067 --> 00:00:36.088
测试永远不会证明软件没有错误，而是错误的存在

00:00:36.088 --> 00:00:41.042
这句话对吗？好的，这句话由来已久了，需要牢记在心

00:00:41.042 --> 00:00:46.700
这里是一篇一年半前的文章

00:00:46.700 --> 00:00:51.922
它讨论为什么东西这么贵。在这里你可以看到，

00:00:51.922 --> 00:00:56.825
他们的研究显示，不是设计有bug，而是糟糕的测试

00:00:56.825 --> 00:01:02.110
糟糕的测试流程是代码有如此多bug的原因

00:01:02.110 --> 00:01:07.013
文章说，完全自动化的测试环境几乎没有

00:01:07.013 --> 00:01:11.534
这是一年半前。现在，我们也刚刚有20%

00:01:11.534 --> 00:01:16.707
12%软件的组织已经完全自动化的测试系统

00:01:16.707 --> 00:01:21.023
10%的软件组织手工完成所有测试。你编写测试，看测试结果

00:01:21.023 --> 00:01:25.225
你编写测试，再看一下结果。有发现什么错误吗？

00:01:25.225 --> 00:01:29.852
哇，不敢相信，依然是对的。其实这里是不对的。[笑]

00:01:29.852 --> 00:01:35.086
你知道吗，在敏捷开发之前，首先你有独立的质量保证团队

00:01:35.086 --> 00:01:40.133
有所有这些阶段和单独的团队。这样，Marge，某种意义上，

00:01:40.133 --> 00:01:44.805
质量保证团队是要在你的代码中插入质量。[笑]

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

00:01:49.727 --> 00:01:54.260
我们不断测试。每个星期，我们产出新的代码。

00:01:54.260 --> 00:01:58.888
你负责测试你的代码，没有别人。而且这些工具高度自动化

00:01:58.888 --> 00:02:03.816
这和之前所说的做法不太一样

00:02:03.816 --> 00:02:08.444
敏捷宣言中有争议的是，

00:02:08.444 --> 00:02:13.493
是否一个好的过程就能带来软件质量

00:02:13.493 --> 00:02:20.141
而不是由特定的团队来追着你保证质量

00:02:20.141 --> 00:02:25.636
前面提到过BDD和TDD

00:02:25.636 --> 00:02:30.859
一些人明白行为驱动设计，但是不清楚测试驱动开发

00:02:30.859 --> 00:02:36.286
这里我们测试，验收测试、 集成测试，并试图捕获行为。

00:02:36.286 --> 00:02:41.849
Tdd 是一个步骤的定义，在写代码之前先写单元测试和功能测试

00:02:41.849 --> 00:02:47.208
所以，这就是定义。所以，好处是你总是使用最新的测试

00:02:47.208 --> 00:02:52.485
因为你先编写测试代码。所以这就是是他们如何一起工作的

00:02:52.485 --> 00:02:56.992
Cucumber 用于描述行为和特性

00:02:56.992 --> 00:03:01.564
你开始编写故事点。当它们失败时，调用的RSpec的测试实现

00:03:01.564 --> 00:03:06.265
如果失败，你就补充实现缺失的方法

00:03:06.265 --> 00:03:10.901
当它通过测试，继续内部迭代

00:03:10.901 --> 00:03:15.988
直到通过RSpec。

00:03:15.988 --> 00:03:20.946
一旦你完成一个特性，就会通过cucumber的绿色步骤，返回

00:03:20.946 --> 00:03:23.200
继续开发下去