<谷歌如何测试> 翻译第四篇

 

在比其他公司少很多测试人员的情况下，谷歌做的还不错的一个关键原因是，很少尝试在一次发布中包含很多的功能。实际上，谷歌经常反其道而行之，在一个产品的核心模块被开发后，如果有一定数量的受益人群就立刻发布，然后不断的得到用户反馈再迭代开发新功能。这也是我们在Gmail 上的做法，Gmail 被贴上Beta版本的标签在线上运营了四年。通过这个Beta标签也可以来警示用户，Gmail 还并非完美的产品，有出错的可能。只有当邮件数据达到 99.99%的时间都是可用的时候，我们目标就算达到了，这个Beta标签才会被去除。很明显，质量是一个不断改进的过程。

这里的这个改进过程，并不像西部牛仔那样，一下子什么都能搞出来。实际上，一个产品为了达到我们称之为Beta的版本，也要经历一系列的过程，并在过程中证明其价值。Chrome是我加入谷歌前两年一直所工作的团队，它同样经历了多个版本。在每个版本里，基于对产品质量的信心和不断寻求的客户反馈才让我们进入到下一个版本。这些版本历程大致如下：

金丝雀版本（Canary Channel），不太可靠的版本，并不适用于发布。就像一只金丝雀在煤堆里一样，如果不幸身亡，那说明还有工作要去做。只有超强容忍能力的用户才有可能使用金丝雀版本来试验运行，你不能依赖这样的应用能把实际工作完成。

开发版本（Dev Channel)，是开发工程师们日常工作中使用的版本。所有的同一产品组的工程师都需要去安装这个版本，并在真正的工作中使用他们。

测试版本（Test Channel），是给内部的狗食【译者注，dog food，一般指自己团队的产品，给自己或者公司内部的人尝试使用的中间产品】，如果能够有持续不错的性能表现的话，也可能会是beta版本的候选。

Beta版本或发布版本(The Beta Channel or Release Channel)，是给外部用户使用的第一个版本。只有在之前的各种版本历程中通过了测试和真实用户的枪林弹雨般的验证后，才会成为beta版。

 

上述的这种从爬到走、走到跑的模式，让我们在运行一些测试同时又可以对我们的应用系统做一些试验调整，并从真实用户和每个版本的每日自动化测试那里得到及时的反馈。

对于这样的过程，还有一些分析角度的益处。例如，发现了一个bug，测试人员可以根据这个bug创建一个测试用例，并针对所有的每一个版本都运行这个测试用例，从而可以验证这个 bug fix是否在所有的版本中都真正得到了修复。

【译者注：关于Chrome 与 Chrome OS 各版本的称呼，可以参见http://www.chromi.org/chromedownload ，其中也涉及到本文中各个版本的称呼，但并不是与 James文中完全一致，实际上像金丝雀版本，一些喜欢尝鲜的外部用户也在使用】

 

公直
2012/3/20

 

英文原文，

How Google Tests Software – Part Four

http://googletesting.blogspot.com/2011/03/how-google-tests-software-part-four.html
Wednesday, March 02, 2011 10:11 AM
By James Whittaker

Crawl, walk, run.

One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to ship a large set of features at once. In fact, the exact opposite is often the goal: build the core of a product and release it the moment it is useful to as large a crowd as feasible, then get their feedback and iterate. This is what we did with Gmail, a product that kept its beta tag for four years. That tag was our warning to users that it was still being perfected. We removed the beta tag only when we reached our goal of 99.99% uptime for a real user’s email data. Obviously, quality is a work in progress!

It’s not as cowboy a process as I make it out to be. In fact, in order to make it to what we call the beta channel release, a product must go through a number of other channels and prove its worth. For Chrome, a product I spent my first two years at Google working on, multiple channels were used depending on our confidence in the product’s quality and the extent of feedback we were looking for. The sequence looked something like this:

Canary Channel is used for code we suspect isn’t fit for release. Like a canary in a coalmine, if it failed to survive then we had work to do. Canary channel builds are only for the ultra tolerant user running experiments and not depending on the application to get real work done.

Dev Channel is what developers use on their day-to-day work. All engineers on a product are expected to pick this build and use it for real work.

Test Channel is the build used for internal dog food and represents a candidate beta channel build given good sustained performance.

The Beta Channel or Release Channel builds are the first ones that get external exposure. A build only gets to the release channel after spending enough time in the prior channels that is gets a chance to prove itself against a barrage of both tests and real usage.

This crawl, walk, run approach gives us the chance to run tests and experiment on our applications early and obtain feedback from real human beings in addition to all the automation we run in each of these channels every day.

There are analytical benefits to this process as well. If a bug is found in the field a tester can create a test that reproduces it and run it against builds in each channel to determine if a fix has already been implemented.

 

from:http://sdet.org/?p=164