前言：，评论里留下许多问题。并没有逐一回复，当然不是想把这些评论置之不理，而是希望在这里和后面的文章中做详细介绍和解释这些问题。从这一篇开始，我将开始讲谷歌是如何测试软件的了。
在谷歌，质量不等于测试，是的，我确定在其他所有的公司也都是这样。“质量不是被测出来的”，这句陈词滥调是再正确不过的了。不管汽车制造还是 软件开发，如果在最初的设计建造的时候就有问题，那它永远都会有问题。试问任何一家曾经被迫大量召回汽车的公司，逃避质量问题的代价是多么的昂贵。
但是，“质量不是被测出来的”这句话本身并不像它听起来的那么简单和准确。虽然质量并不是被测出来的，但同样也有证据表明，未经过测试，也不可能开发出有质量的产品。你连测试都没有做过，又是怎么知道产品功能是否正确，并有高质量呢？
对于这种难题，最简单的办法是不要区分开发和测试，不要把他们当成对立的活动。测试和开发【译注：两种行为，不是人】最好能手牵手的并行，写一点 代码就立刻进行测试，写的越多，测的就要越多。最好是，在编码的同时，甚至在编码之前，就考虑清楚这些代码将如何被测试。测试不是一个单独的工作，测试就 是开发的一部分。所以，质量并不等同于测试，当把开发和测试混在一起，搅拌直到分不清他们彼此的时候，就得到了质量。
这就是谷歌的想法，把开发和测试工作混在一起，不分彼此。写点代码，就必须测试，多写一些就多测一些。关键的问题就是谁来做测试工作？ 由于谷歌的专职测试人员非常的少，唯一的答案就只能是开发人员。还有比实际写代码的开发人员更适合来测试这些代码的人吗？还有比程序的作者更懂得怎样去发 现程序 bug 的吗？是谁更想知道程序在第一次运行时是否有没有问题呢？谷歌之所以用这么少的专职测试人员的原因就是开发对质量负全责。实际上，如果一个团队在过于依赖 测试的时候，通常情况下这个团队在开发上一定也会有问题。如果在这个团队里，测试人员比较多，这也是一个强烈的信号，这表明开发和测试融入到一起的程度还 不够，失衡了，缺乏测试，单纯地增加测试人员并不能解决任何问题。
这意味着，对于质量来说，预防问题比发现问题本身更重要。质量是开发人员的问题，而不是测试人员的问题。通过把测试工作融入到开发过程中，我们 能降低那些富产 Bug 的人的出错机会，不仅可以避免了大量最终用户的使用问题，而且还可以极大地降低测试人员报无效 Bug 的数量。在谷歌软件测试工程师的工作目标就是检查这种预防措施是否有效，软件测试工程师不停地寻找一些证据来证明作为 bug 的作者和预防者的“软件开发工程师-软件测试开发工程师”组合是否存在问题，一旦发现任何不正常，就会拉响警笛。
这种开发和测试一体的场景随处可见，不管是在代码审核的时候问“你的测试呢？”，还是在厕所蹲坑里张贴着的最佳测试实践–臭名昭著的马桶测试指南【译者注，参见 google test blog，有关于”Testing On The Toilet“的更多介绍】。测试是开发过程中必不可少的一环，质量是开发和测试合体的产物。软件开发工程师，软件测试开发工程师，软件测试工程师，所有 的人都是测试人员。
如果你所在的公司也想要做这种开发和测试的统一，请也给大家分享一下其中经验和教训。如果没有，这将是一个帮助你公司的机会：让开发和质量划等 号。你大概知道谚语里说的，鸡和猪为了一顿有培根和鸡蛋的早餐都乐于奉献自己，但是猪却牺牲了。好吧，这就是事实，尝试跑到开发工程师那里，对他们”哼哼 “（猪叫声）两声，看他们是否也用”哼哼“来回应，如果他们”咯咯哒“（鸡叫声）来回应，那就说明有问题了。
【译者注，崩溃了，这里比较难懂。James 这里引用了一个猪和鸡的英语谚语，（参见， ），谚语的意思大概是，猪和鸡都参与制作培根鸡蛋早餐，猪变成了猪肉（培根），鸡只下了一个蛋，说明对于早餐，猪和鸡的奉献程度是不同的。并在这里把测试 工程师比喻成鸡，开发工程师比喻成猪，早餐就是质量，猪的奉献大。测试人员跑到开发人员那里，如果发现他们没有做猪的事情，早餐将做不成，那说明质量也将 会有问题。】
【四】
爬，走，跑。
在比其他公司少很多测试人员的情况下，谷歌做的还不错的一个关键原因是，很少尝试在一次发布中包含很多的功能。实际上，谷歌经常反其道而行之， 在一个产品的核心模块被开发后，如果有一定数量的受益人群就立刻发布，然后不断的得到用户反馈再迭代开发新功能。这也是我们在 Gmail 上的做法，Gmail 被贴上 Beta 版本的标签在线上运营了四年。通过这个 Beta 标签也可以来警示用户，Gmail 还并非完美的产品，有出错的可能。只有当邮件数据达到 99.99% 的时间都是可用的时候，我们目标就算达到了，这个 Beta 标签才会被去除。很明显，质量是一个不断改进的过程。
这里的这个改进过程，并不像西部牛仔那样，一下子什么都能搞出来。实际上，一个产品为了达到我们称之为 Beta 的版本，也要经历一系列的过程，并在过程中证明其价值。Chrome 是我加入谷歌前两年一直所工作的团队，它同样经历了多个版本。在每个版本里，基于对产品质量的信心和不断寻求的客户反馈才让我们进入到下一个版本。这些版 本历程大致如下：
金丝雀版本（Canary Channel），不太可靠的版本，并不适用于发布。就像一只金丝雀在煤堆里一样，如果不幸身亡，那说明还有工作要去做。只有超强容忍能力的用户才有可能使用金丝雀版本来试验运行，你不能依赖这样的应用能把实际工作完成。
开发版本（Dev Channel)，是开发工程师们日常工作中使用的版本。所有的同一产品组的工程师都需要去安装这个版本，并在真正的工作中使用他们。
测试版本（Test Channel），是给内部的狗食，如果能够有持续不错的性能表现的话，也可能会是 beta 版本的候选。【译者注，dog food，一般指自己团队的产品，给自己或者公司内部的人尝试使用的中间产品】
Beta 版本或发布版本(The Beta Channel or Release Channel)，是给外部用户使用的第一个版本。只有在之前的各种版本历程中通过了测试和真实用户的枪林弹雨般的验证后，才会成为 beta 版。
上述的这种从爬到走、走到跑的模式，让我们在运行一些测试同时又可以对我们的应用系统做一些试验调整，并从真实用户和每个版本的每日自动化测试那里得到及时的反馈。
对于这样的过程，还有一些分析角度的益处。例如，发现了一个 bug，测试人员可以根据这个 bug 创建一个测试用例，并针对所有的每一个版本都运行这个测试用例，从而可以验证这个 bug fix 是否在所有的版本中都真正得到了修复。
【译者注：关于 Chrome 与 Chrome OS 各版本的称呼，可以参见，其中也涉及到本文中各个版本的称呼，但并不是与 James 文中完全一致，实际上像金丝雀版本，一些喜欢尝鲜的外部用户也在使用】
By James Whittaker
●
●
转载自伯乐在线