转自：http://news.cnblogs.com/n/135788/       

    How Google Tests Software – Part Three
    How Google Tests Software – Part Four  By James Whittaker

【三】

经过前两篇的介绍之后（一、二)

，评论里留下许多问题。并没有逐一回复，当然不是想把这些评论置之不理，而是希望在这里和后面的文章中做详细介绍和解释这些问题。从这一篇开始，我将开始讲谷歌是如何测试软件的了。  

在谷歌，质量不等于测试，是的，我确定在其他所有的公司也都是这样。“质量不是被测出来的”，这句陈词滥调是再正确不过的了。不管汽车制造还是 软件开发，如果在最初的设计建造的时候就有问题，那它永远都会有问题。试问任何一家曾经被迫大量召回汽车的公司，逃避质量问题的代价是多么的昂贵。

但是，“质量不是被测出来的”这句话本身并不像它听起来的那么简单和准确。虽然质量并不是被测出来的，但同样也有证据表明，未经过测试，也不可能开发出有质量的产品。你连测试都没有做过，又是怎么知道产品功能是否正确，并有高质量呢？

  　　对于这种难题，最简单的办法是不要区分开发和测试，不要把他们当成对立的活动。测试和开发【注，两种行为，不是人】最好能手牵手的并行，写一点 代码就立刻进行测试，写的越多，测的就要越多。最好是，在编码的同时，甚至在编码之前，就考虑清楚这些代码将如何被测试。测试不是一个单独的工作，测试就 是开发的一部分。所以，质量并不等同于测试，当把开发和测试混在一起，搅拌直到分不清他们彼此的时候，就得到了质量。

这就是谷歌的想法，把开发和测试工作混在一起，不分彼此。写点代码，就必须测试，多写一些就多测一些。关键的问题就是谁来做测试工作？ 由于谷歌的专职测试人员非常的少，唯一的答案就只能是开发人员。还有比实际写代码的开发人员更适合来测试这些代码的人吗？还有比程序的作者更懂得怎样去发 现程序 bug 的吗？是谁更想知道程序在第一次运行时是否有没有问题呢？谷歌之所以用这么少的专职测试人员的原因就是开发对质量负全责。实际上，如果一个团队在过于依赖 测试的时候，通常情况下这个团队在开发上一定也会有问题。如果在这个团队里，测试人员比较多，这也是一个强烈的信号，这表明开发和测试融入到一起的程度还 不够，失衡了，缺乏测试，单纯地增加测试人员并不能解决任何问题。

这意味着，对于质量来说，预防问题比发现问题本身更重要。质量是开发人员的问题，而不是测试人员的问题。通过把测试工作融入到开发过程中，我们 能降低那些富产 Bug 的人的出错机会，不仅可以避免了大量最终用户的使用问题，而且还可以极大地降低测试人员报无效 Bug 的数量。在谷歌软件测试工程师的工作目标就是检查这种预防措施是否有效，软件测试工程师不停地寻找一些证据来证明作为 bug 的作者和预防者的“软件开发工程师-软件测试开发工程师”组合是否存在问题，一旦发现任何不正常，就会拉响警笛。

这种开发和测试一体的场景随处可见，不管是在代码审核的时候问“你的测试呢？”，还是在厕所蹲坑里张贴着的最佳测试实践——臭名昭著的马桶测试 指南【译者注，参见 google test blog，有关于”Testing On The Toilet“的更多介绍】。测试是开发过程中必不可少的一环，质量是开发和测试合体的产物。软件开发工程师，软件测试开发工程师，软件测试工程师，所有 的人都是测试人员。

如果你所在的公司也想要做这种开发和测试的统一，请也给大家分享一下其中经验和教训。如果没有，这将是一个帮助你公司的机会：让开发和质量划等 号。你大概知道谚语里说的，鸡和猪为了一顿有培根和鸡蛋的早餐都乐于奉献自己，但是猪却牺牲了。好吧，这就是事实，尝试跑到开发工程师那里，对他们”哼哼 “（猪叫声）两声，看他们是否也用”哼哼“来回应，如果他们”咯咯哒“（鸡叫声）来回应，那就说明有问题了。【译者注，崩溃了，这里比较难懂。James 这里引用了一个猪和鸡的英语谚语，（参见，

http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig

），谚语的意思大概是，猪和鸡都参与制作培根鸡蛋早餐，猪变成了猪肉（培根），鸡只下了一个蛋，说明对于早餐，猪和鸡的奉献程度是不同的。并在这里把测试 工程师比喻成鸡，开发工程师比喻成猪，早餐就是质量，猪的奉献大。测试人员跑到开发人员那里，如果发现他们没有做猪的事情，早餐将做不成，那说明质量也将 会有问题。

【四】

爬，走，跑。

在比其他公司少很多测试人员的情况下，谷歌做的还不错的一个关键原因是，很少尝试在一次发布中包含很多的功能。实际上，谷歌经常反其道而行之， 在一个产品的核心模块被开发后，如果有一定数量的受益人群就立刻发布，然后不断的得到用户反馈再迭×××发新功能。这也是我们在 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 文中完全一致，实际上像金丝雀版本，一些喜欢尝鲜的外部用户也在使用】

转自：http://news.cnblogs.com/n/152032/

【五】

对于测试范围的形式，谷歌并没有使用通用的代码测试、集成测试、系统测试这些常用术语来做区分，而是使用小规模测试、中等规模测试、大规模测试 这样的称呼【译者注：代码测试(code testing)， 通常指单元测试和 API 级别的测试，一般使用 XUnit、Gtest 框架，但谷歌并没有使用代码级别测试这种说法】。小规模测试就是针对小量代码的测试，中等规模测试、大规模测试以此类推。所有的三种工程师角色【译者注， 软件开发工程师、软件测试开发工程师、软件测试工程师，参见本系列第二篇,都会去执行上面的三类测试，可能是自动化的测试，也可能是手动测试

小规模测试，通常（但也并非所有）是自动化的，一般是针对一个单独的函数或者模块。这种测试一般由软件开发 工程师【SWE】或者软件测试开发工程师【SET】来实现，通常在运行的时候会依赖模拟环境，当软件测试工程师【TEs】需要去诊断定位一个特定错误时， 会去筛选一些小规模测试集合并运行来验证特定问题。对于小规模测试，主要集中在常见功能问题验证上，例如数据损坏、错误边界、发生错误时如何结束等。小规 模测试尝试去解决的问题是，代码是否按照其假定的方式运行。

中等规模测试，可以是自动化的或者手动的，涉及到 2 个及以上功能模块，特别是要覆盖这些功能模块之间交互的地方。有不少软件测试开发工程师【SET】把这种测试描述成“测试一个函数，以及它最近的邻居们” 【”testing a function and its nearest neighbors.”】。软件测试开发工程师在独立的功能模块开发完毕后会驱动进行这种测试，软件开发工程师是写这些测试代码、并调试和维护这些测试的 主要力量。如果一个测试用例运行失败或者运行错误，相应的开发会自动地跳出来查看处理。在开发周期的后期，软件测试工程师会运行这些中等规模测试，可能是 手动的方式（如果很难或者需要投入比较大成本去自动化的时候）或者自动化的方式去运行。中等规模测试尝试去解决的问题是，一些相近的交互功能模块组合在一 起是否和预期一致。

大规模测试，涵盖三个及以上（通常更多）功能模块，描述最终用户的使用场景及其可能扩展。所有的功能模块集 成为一个整体的时候需要去关心许多问题，但在谷歌，对于大规模测试，更倾向于着重结果，例如，这个软件是用户期望的那样么？所有的工程师都会参与到大规模 测试中，无论是使用自动化还是探索性测试方法。大规模测试尝试去解决的问题是，这个产品运行地是否是最终用户期望的那样。

小规模测试、中等规模测试、大规模测试这些术语本身其实并不重要，你可以给它们取任何你想的名称。对于谷歌的测试人员来说，有了这样一个统一的 称谓后，就可以使用这些称谓来讨论正在进行什么样的测试以及其测试范围。有一些雄性勃勃的测试人员也会谈到第四种测试，被称为超级大规模测试，公司的其他 测试人员可以认为这样的测试是一个非常大的系统级别的测试，涵盖到几乎所有的功能而且会持续很长的时间，其他的解释都会比较多余了。

哪些需要被测试及测试范围的确定，这是一个动态变化的过程，在不同的产品之间会有比较大的差异。谷歌更倾向于频繁发布，从产品的外面用户那里得 到反馈之后再迭×××发。如果谷歌开发了一些产品，或者在已有产品上增加了新功能，会尽可能早地对外发布并让外部用户能使用并从中受益。在这个过程中需要较 早地把用户和外部开发者牵扯进来，并要有一个很好的处理规则来验证是否满足发布条件。

最后，自动化测试和手动测试，对于所有的三种类型测试【小规模、中等规模、大规模测试】来说当然更喜欢前者。如果能够被自动化，而且不需要任何 人智力和直觉判断，那就应该把它变成自动化的。只有在特别需要人为判断的时候，例如用户的界面是否漂亮、或暴漏一些涉及用户隐私的内容时，在这些情况下应 该保留手动测试。

话虽如此，对于谷歌来说非常重要的是仍然使用了大量的手动测试，不管是使用文本记录的方式还是使用探索性测试，虽然有些已经进入了自动化测试的 视线。业界使用的录制技术将手动测试转变成自动化测试，可以在每个版本后自动地重复运行，这样保证了最少的回归工作，并把手动测试的重点放在新问题上。而 且，谷歌已经将提交 BUG 的过程和一些手动测试的日常工作也自动化了，例如，如果一个自动化测试运行失败，系统会自动检测到最后一次代码变更的信息，一般来说这是引起测试失败的原 因，系统会给这次代码提交的作者发送一封通知邮件同时自动创建一个 BUG 来记录这个问题。在测试上，“人类智慧的最后一英寸”体现在测试设计上，谷歌的下一代测试工具也正在这个方向上努力尝试，将其自动化。

这些工具在以后的文章中会被提及强调。不过，下一篇文章还是会将重点放在软件测试开发工程师【SET】的工作上。希望能得到你的持续关注。


【六】

软件测试开发工程师【SET】的生命

软件测试开发工程师【Software Engineers in Test】是软件工程师，专注在测试实现。首先，软件测试开发工程师是开发角色，在招聘和内部晋升资料中被我们奉为 100% 的编码角色。当在招聘面试软件测试开发工程师的时候，对于编码的要求几乎和对软件开发工程师的要求是一模一样的，而且更强调如何去测试自己写的代码。换句 话说，软件开发工程师和软件测试开发工程师都需要回答编码问题，而且软件测试开发工程师会被问到一系列测试相关的问题。

正如你可能想到的，这是一个很难满足的角色。软件测试开发工程师的数量如此之少的最有可能的原因是，事实具备软件测试开发工程师所需技能的人非 常难找，而不是我们刻意使用了什么神奇的生产率公式【译注，开发测试比率公式】， 这也是我们适应当前工程实践的一个必然结果。我们还在优化我们的工程实践–这是一个非常重要的任务，并且为所有参与的人构建一些流程。

通常来说，软件测试开发工程师不会在早期设计阶段就介入。不是故意这样做，而是和多数谷歌的产品是如何诞生的有关。一个常见的新产品诞生的场景 是这样，已有的谷歌产品的员工会投入 20% 时间来开始新的产品。Gmail 和 Chrome OS 这 2 个产品，从一个简单的想法开始，并非正式地由谷歌授权去做的，慢慢地随着时间的推移，越来越多的开发和测试加入进来并把产品发布。在这种情况下，早期的开 发要关注的重心并不是质量，更关注提供一些理念，在解决了扩展性和性能的问题之后，再更多地关注质量。如果你创建了一个 web service，但是不具有可扩展性时，测试这时候还并不是你最大的问题。

一旦这个产品已经明确未来可以发布的时候，研发团队就开始寻求测试的介入了。

你可以想象这样一个过程，某个人有了一个好主意，他开始思考并写了一些试验性质的代码，从其他人那里获取一些建议然后对这些代码做了改进，并劝 说更多的人加入，写了越来越多的代码，然后意识到他们做的事情很重要，通过更多的代码把这个想法变成可以呈现给他人并得到反馈的模型…  这个项目在谷歌的项目库中就创建了，这个项目慢慢地变成了一个真实的项目，测试也只有在项目变成真实的项目之后才会介入进来。

所有真实的项目都有专职的测试人员么？ 默认情况下是没有的。小型项目和只有受限用户使用的项目一般是开发人员自己做测试。其他的一些对个人或者企业用户有潜在风险的项目，测试会介入。

当开发团队寻求测试团队参与并帮助他们时，他们有责任使测试人员相信他们的项目是令人兴奋并充满潜力的。开发总监会给测试总监解释他们的项目、 进度、发布计划，一起讨论测试工作如何划分，并就开发需要满足的单元测试水平及开发参与测试工作程度上达成一致，发布流程中开发与测试的责任也需要明确。 软件测试开发工程师在项目初期可能不会参与进来，一旦项目变成真实的项目后，测试人员将在软件开发过程中发挥巨大的影响力。

当我说“测试”时，并不是仅仅意味着单纯的检查验证代码路径。测试人员不是从开始就参与进来的，但“测试”却至始至终都有。实际上，一个开发尝 试去 check in 代码的时，测试人员的影响力在这个时刻可能就已经显现出来了。【译，这里指软件测试开发工程师会对开发人员的测试程度做一些要求，开发人员在 check in code 的时候需要想一下自己是否满足这些要求，这就是测试人员的影响力】。欢迎继续收听并尝试理解我所说的这些东西。