谷歌如何做软件测试How Google Tests Software中文.docx
《谷歌如何做软件测试How Google Tests Software中文.docx》由会员分享，可在线阅读，更多相关《谷歌如何做软件测试How Google Tests Software中文.docx（15页珍藏版）》请在冰点文库上搜索。
谷歌如何做软件测试HowGoogleTestsSoftware中文
谷歌如何做软件测试第一部分Google的测试策略从来没有变过，我们执行测试的策略随着公司的演化而演化。
我们现在是一个集搜索、应用、广告、移动、操作系统等业务于一体的公司。
每一个我们关注的领域都是在该领域有意义的问题。
随着我们不断的增加新的“关注领域”（FocusAreas），延伸已经存在的领域，我们的测试也在不断的扩展和改善。
而我们当下在做的以及我们预计未来将会发展的方向，就是我将要在这系列文章中将要阐述的问题。
让我们先从组织结构的介绍开始，这个或许会让你感到惊奇。
在Google并不存在一个真正意义上的测试部门。
测试实际存在于一个关注领域，我们称它为“生产率工程”（EngineeringProductivity）。
“生产率工程”是一个拥有一定数量的横向和纵向的工程学科，测试是最大的一个。
而在这个组织中，“生产率工程”是由以下三部分组成：
1、产品团队。
他们设计的内部的和开源的工具由公司里的所有工程师完成。
他们负责构建和维护代码分析器、开发环境、测试用例管理系统、自动化测试工具、构建系统、源代码控制系统、代码回顾计划、缺陷数据库。
他们的目标就是设计一种能让工程师更有效率的工具。
工具是在检测预防的战略目标中占非常大的一部分。
2、服务团队。
他们在一个非常宽泛的领域内向产品团队提供诸如包含工具（includingtools）、文档、测试、发布管理、培训等方面的专业技能。
他们的专业技能涵盖可靠性、安全性、国际化等方面，也会处理产品团队可能遇到的关于功能细节方面的问题。
任何一个其他“关注领域”的服务团队也可以为产品团队提供专业技能服务。
3、嵌入式工程师。
他们有效的担负起了Google产品团队在有需要时的需求。
有些工程师会跟着同一个的产品团队数年，另一些则只会在一个较短的周期内为产品团队的需要提供服务。
Google鼓励所有的工程师经常更换自己服务的产品团队，以保持饱满的精神状态，并保证有效和客观的工作。
测试工程师也一样，更换团队的节奏也是因人而异的。
有些测试工程师在Chrome项目下数年，而有一些则在加入团队18个月后去了别的团队。
在产品知识与新颖的视角间保持一个良好的平衡，是一个测试管理者需要关注的。
所以这意味着测试同学向工程生产力部门的经理汇报，但是他们会把自己看成产品部门团队的一员，像搜索、邮箱、和Chrome部门。
从组织架构上看，测试都是两个团队的一部分。
测试和产品团队坐在一起，参与计划，一起吃饭，共享奖金，享受像全职的产品团队成员一样的待遇。
这种单独的组织汇报关系的好处是可以给测试人员之间提供良好的共享信息的讨论机会，好的测试思路可以很容易的在工程生产力部门内部蔓延，无论公司内的哪条产品线，都可以很快地使用这些最好的测试技术。
测试人员的这种项目分离和汇报组织结构也有它的缺点，目前来看，最大的问题是测试人员被看做外部资源。
产品部门团队不能对测试人员有太多的依赖，他们自己必须要合理地控制产品质量。
是的，没错，在谷歌，是产品部门团队对产品质量负责，而不是测试人员。
每个产品部门的开发人员都需要做测试工作，测试人员的任务是为产品部门团队搭建自动化测试基础设施和流程，测试人员让开发可以自给自足地、独立地做完成测试工作。
在这种模式下，我比较喜欢的是，开发和测试将有相同的地位。
在质量方面，开发和测试成为了真正的伙伴，最大的质量重担交给本应属于的开发人员，开发的职责就是正确地实现产品功能。
另外这样可以保持多对一的开发测试比率，开发人员在数量上远超测试人员，并且测试工作做的越多，开发测试比率就会越大。
产品部门团队也会对这样的高开发测试比率而感到骄傲。
好，现在好像大家都是好朋友了，对吧？
相信你已经看到这种模式的一个问题，开发人员不能很好地驱动缺陷【Bug】的运转，开发不会测试。
难道我要否认这一点么？
不管怎样，我都不会否认，尤其是在我去年做的一次关于开发工程师与测试工程师对比的游戏之后（告诉你：
测试工程师赢得了较量）。
在谷歌，解决这个问题的办法是将角色再细分，我们通过设立不同的测试角色来解决这两种不同的测试问题。
在下一篇文章里，我将详细阐述这些测试角色和谷歌是怎样将测试问题分成两部分来分别解决的。
第二部分本文是从HowGoogleTestsSoftware-PartTwo这篇文章翻译而来。
本文作者JamesWhittaker，前微软架构师，是“HowtoBreakSoftware”系列图书中好几部书的作者，现任Google测试工程主管，最近他写了一系列的关于谷歌如何测试软件的文章，本文为其系列的第二部分。
为了实现”谁的屁股谁自己擦”这句名言所说的那样，在传统的软件开发人员的之上，有必要增加了几个角色，特别是需要工程技术方面的特殊角色，这种角色可以让开发更高效低做测试。
在谷歌，这样角色的职责是让其他人工作的更有效率，这样的工程师通常会把自己当做测试人员，但他们真正的使命是提高生产力/生产率。
他们的存在是为了让开发人员效率提升，特别是在质量方面的提升，因为产品质量是生产率中最重要的一部分。
这里是这些角色的总结：
软件开发工程师，就是传统的开发人员。
软件工程师实现一些功能代码并把最终产品提供给用户使用，他们创建设计文档、设计数据结构和总体的架构搭建，他们大多数时间都在写代码和评审代码。
同时，他们也会写很多的测试代码，包括测试驱动设计，单元测试，并参与后面的文章会讲到的小、中、大型测试的创建工作。
软件工程师需要对他们自己写的代码、修复缺陷的代码、改进的代码，只要是他们接触过的代码的质量负责。
软件测试开发工程师，和软件开发工程师一样是开发工程师，主要负责软件的可测试性。
他们参与设计评审，近距离地关注代码质量和风险，对代码做重构为了系统有更好的可测试性，同时他们负责写单元测试框架和自动化测试的框架。
在代码级别上他们和软件开发工程师是合作伙伴，但如果和增加新功能或提升性能相比较，他们更关心产品的质量和测试覆盖率的提升。
软件测试工程师，和软件测试开发工程师恰恰相反，他得主要工作是做测试而不是开发。
许多谷歌的软件测试工程师会花很多的时间在写测试代码上，包括自动化脚本、使用场景的代码、甚至模拟最终用户的操作方面的代码。
他们对软件开发工程师和软件测试开发工程师的测试工作做一些组织安排，解释测试结果、驱动测试的执行，特别是在项目即将发布的后期将起到非常重要的作用。
软件测试工程师既是产品专家也是质量顾问更是风险分析师。
从质量的角度来看，软件开发工程师对功能开发和质量负有全责。
同时，他们还负责容错设计、故障恢复、TD
D、单元测试、和在软件测试开发工程师的帮助下写测试代码，这些测试代码会验证开发的功能。
软件测试开发工程师是提供测试支持的开发人员。
他们提供一种能够将新添加的代码通过模拟其依赖的方式做功能验证的技术框架，并应用在代码提交之前的提交队列管理之中
【注，这样可以在代码checkin的时候保证新代码的功能完备】。
可以这样说，软件测试开发工程师就是为了让软件工程师可以测试他们的功能代码，所有真正的测试都是软件开发工程师完成的，软件测试开发工程师是保证这些功能有很好的可测试性，这样可以让软件开发工程师很积极地参与到测试用例代码的编写中去。
现在所有的一切很清楚了，软件测试开发工程师就是服务人员，他们的主要职责就让开发人员很方便简单的做测试并保证模块级别的产品质量。
读者可能已经意识到一个问题，在这样的研发流程下，使用软件的最终用户会怎样？
在谷歌，软件测试工程师的职责就是最终用户级别的测试。
如果软件开发工程师和软件测试开发工程师很好地做了模块级别的功能测试，下一个工作就是看许多功能集成和数据的组合是否能够满足最终用户的使用需求。
软件测试工程师在这里就是扮演一个双重确认开发工程师测试工作的角色，任何明显的缺陷都会说明之前一轮的开发自测不够或比较草率，如果没有出现这种情况之后，软件测试工程师会将注意力转移到普通用户的使用场景测试上，保证性能、安全、国际化等方面没有问题。
软件测试工程师们需要做大量的测试工作，并在测试工程师、测试合同工、吃狗粮的尝鲜者、beta测试用户、早期最终用户之间做很多沟通交流的工作，他们会和基础设计、功能复杂度、避免错误的方法等方面遇到问题的人做确认。
一旦软件测试工程师开始介入，总是会没完没了。
好了，现在大家对这些角色应该有比较好的理解了，接下来我会在他们之间是怎么分工合作做更详尽的剖析。
下次再聊。
。
。
谢谢您的关注。
第三部分本文作者JamesWhittaker,前微软架构师，是“HowtoBreakSoftware”系列图书中好几部书的作者，现任Google测试工程主管，最近他写了一系列的关于谷歌如何测试软件的文章，本文为其系列的第三部分。
在前两部分的文章中，很多人在评论里提出了问题。
我没有忘记他们。
希望大部分的人能在余下的几部分文章里找到答案。
我现在还是开始这篇文章的主题。
在Google，质量并不等于测试。
我相信在任何一个地方都是如此。
“质量不是被测试出来的”这句老话是再正确不过了。
从汽车到软件，如果它们起初制造的就有问题，那它们永远都不会没问题。
试问任何一个曾经被迫大量召回的汽车公司，掩盖质量问题的代价有多大。
然而，事实情况并不是像这句话那样既简单又精确。
虽然质量并不是测试出来的，但我们有同样的证据表明，没有测试，你不可能开发出任何有质量的东西。
一个人怎么可能在没有测试的情况下认定你的工程具有高质量？
对于这种难题，最简单的解决办法就是：
禁止对开发工作开方便之门，以独立自由之精神进行测试。
测试和开发工作需要同步进行。
编写一点，测试一点。
再编写一点，再测试一点。
更好的方法是制定测试计划，或者你开发之前先把计划做好。
测试并不是一个独立的工作，它是开发工作的一部分，伴随着整个开发过程。
质量不等于测试；为了质量，需要你把开发工作和测试结合到一起，搅拌它们，直到分不清你我为止。
在Google，这是我们明确的目标：
把开发和测试融合，你不能单独进行任何一项工作。
做一点，测试一点。
再做一点，再测试一点。
关键就是看谁在做测试。
因为在Google，专职测试人员是出奇的少，所以唯一可行的方法就是使用开发人员。
还有比这些实际开发了这些程序的人员更合适做测试的吗？
还有比程序的作者更适合去发现bug的吗？
是谁具有更多的愿望在程序第一次写出时避免bug？
Google之所以安排这么少的专职测试人员的原因就是，开发者负责质量。
事实上，坚持使用大型测试机构的团队通常会开发出有问题的东西。
测试机构庞大，这是一个信号表明编码/测试工作的融和有问题。
增加测试人员并不能解决任何问题。
这就是说，质量措施更多的应该是一种预防行为，而不是一种发现过程。
质量属于开发问题，而不是测试问题。
通过把测试工作一定程度的融合到开发过程中，我们极大的降低了一些本来被认为会写很多有问题的代码的人的出错机会。
我们不仅避免了大量的客户方的问题，我们还非常有效的降低了测试人员提出的、其实不是bug的bug。
在Google，测试工作的目标就是检查这些预防工作是否在有效的运行。
测试工程部一直在寻找这种作为bug创造者的软件工程师和作为bug预防者的测试软件工程师之间的联合能达到的效果的证据，一旦这个方法出现问题，他们就会拉响警笛。
这种开发和测试的结合随处可见，从代码审查注释上写的“你的测试呢？
”到厕所里的给开发者的最好的测试实践方法的宣传画——这是我们臭名昭著的厕所测试指导方针。
测试是开发工作中是必不可少的，开发和测试的联姻是孕育质量的过程。
软工就是测试者，测试软工就是测试者，测试工程师就是测试者。
如果你的企业也有这种类型的结合，请分享出你们成功的经验与挑战。
如果没有，那么这是一个给你的企业带来好处的机会：
在开发人员和质量之间画上全等号。
你们都听过这样一个老故事：
小鸡很高兴能为一顿咸猪腿加鸡蛋早餐奉献自己的力量，可猪究竟做错了什么？
的确是„去对你的开发人员哼哼两声，看能不能得到他们哼哼回应。
如果他们发出的是咯咯哒的声音，那说明你们之间存在问题。
第四部分爬，走，跑。
在比其他公司少很多测试人员的情况下，谷歌做的还不错的一个关键原因是，很少尝试在一次发布中包含很多的功能。
实际上，谷歌经常反其道而行之，在一个产品的核心模块被开发后，如果有一定数量的受益人群就立刻发布，然后不断的得到用户反馈再迭代开发新功能。
这也是我们在Gmail上的做法，Gmail被贴上Beta版本的标签在线上运营了四年。
通过这个Beta标签也可以来警示用户，Gmail还并非完美的产品，有出错的可能。
只有当邮件数据达到
99.99%的时间都是可用的时候，我们目标就算达到了，这个Beta标签才会被去除。
很明显，质量是一个不断改进的过程。
这里的这个改进过程，并不像西部牛仔那样，一下子什么都能搞出来。
实际上，一个产品为了达到我们称之为Beta的版本，也要经历一系列的过程，并在过程中证明其价值。
Chrome是我加入谷歌前两年一直所工作的团队，它同样经历了多个版本。
在每个版本里，基于对产品质量的信心和不断寻求的客户反馈才让我们进入到下一个版本。
这些版本历程大致如下：
金丝雀版本（CanaryChannel），不太可靠的版本，并不适用于发布。
就像一只金丝雀在煤堆里一样，如果不幸身亡，那说明还有工作要去做。
只有超强容忍能力的用户才有可能使用金丝雀版本来试验运行，你不能依赖这样的应用能把实际工作完成。
开发版本（DevChannel），是开发工程师们日常工作中使用的版本。
所有的同一产品组的工程师都需要去安装这个版本，并在真正的工作中使用他们。
测试版本（TestChannel），是给内部的狗食【译者注，dogfood，一般指自己团队的产品，给自己或者公司内部的人尝试使用的中间产品】，如果能够有持续不错的性能表现的话，也可能会是beta版本的候选。
Beta版本或发布版本（TheBetaChannelorReleaseChannel），是给外部用户使用的第一个版本。
只有在之前的各种版本历程中通过了测试和真实用户的枪林弹雨般的验证后，才会成为beta版。
上述的这种从爬到走、走到跑的模式，让我们在运行一些测试同时又可以对我们的应用系统做一些试验调整，并从真实用户和每个版本的每日自动化测试那里得到及时的反馈。
对于这样的过程，还有一些分析角度的益处。
例如，发现了一个bug，测试人员可以根据这个bug创建一个测试用例，并针对所有的每一个版本都运行这个测试用例，从而可以验证这个bugfix是否在所有的版本中都真正得到了修复。
第五部分对于测试范围的形式，谷歌并没有使用通用的代码测试、集成测试、系统测试这些常用术语来做区分，而是使用小规模测试、中等规模测试、大规模测试这样的称呼【译者注：
代码测试（codetesting），通常指单元测试和API级别的测试，一般使用XUnit、Gtest框架，但谷歌并没有使用代码级别测试这种说法】。
小规模测试就是针对小量代码的测试，中等规模测试、大规模测试以此类推。
所有的三种工程师角色【译者注，软件开发工程师、软件测试开发工程师、软件测试工程师，参见本系列第二篇】，都会去执行上面的三类测试，可能是自动化的测试，也可能是手动测试。
小规模测试，通常（但也并非所有）是自动化的，一般是针对一个单独的函数或者模块。
这种测试一般由软件开发工程师【SWE】或者软件测试开发工程师【SET】来实现，通常在运行的时候会依赖模拟环境，当软件测试工程师【TEs】需要去诊断定位一个特定错误时，会去筛选一些小规模测试集合并运行来验证特定问题。
对于小规模测试，主要集中在常见功能问题验证上，例如数据损坏、错误边界、发生错误时如何结束等。
小规模测试尝试去解决的问题是，代码是否按照其假定的方式运行。
中等规模测试，可以是自动化的或者手动的，涉及到2个及以上功能模块，特别是要覆盖这些功能模块之间交互的地方。
有不少软件测试开发工程师【SET】把这种测试描述成“测试一个函数，以及它最近的邻居们”【”testingafunctionanditsnearestneighbors.”】。
软件测试开发工程师在独立的功能模块开发完毕后会驱动进行这种测试，软件开发工程师是写这些测试代码、并调试和维护这些测试的主要力量。
如果一个测试用例运行失败或者运行错误，相应的开发会自动地跳出来查看处理。
在开发周期的后期，软件测试工程师会运行这些中等规模测试，可能是手动的方式（如果很难或者需要投入比较大成本去自动化的时候）或者自动化的方式去运行。
中等规模测试尝试去解决的问题是，一些相近的交互功能模块组合在一起是否和预期一致。
大规模测试，涵盖三个及以上（通常更多）功能模块，描述最终用户的使用场景及其可能扩展。
所有的功能模块集成为一个整体的时候需要去关心许多问题，但在谷歌，对于大规模测试，更倾向于着重结果，例如，这个软件是用户期望的那样么？
所有的工程师都会参与到大规模测试中，无论是使用自动化还是探索性测试方法。
大规模测试尝试去解决的问题是，这个产品运行地是否是最终用户期望的那样。
小规模测试、中等规模测试、大规模测试这些术语本身其实并不重要，你可以给它们取任何你想的名称。
对于谷歌的测试人员来说，有了这样一个统一的称谓后，就可以使用这些称谓来讨论正在进行什么样的测试以及其测试范围。
有一些雄性勃勃的测试人员也会谈到第四种测试，被称为超级大规模测试，公司的其他测试人员可以认为这样的测试是一个非常大的系统级别的测试，涵盖到几乎所有的功能而且会持续很长的时间，其他的解释都会比较多余了。
哪些需要被测试及测试范围的确定，这是一个动态变化的过程，在不同的产品之间会有比较大的差异。
谷歌更倾向于频繁发布，从产品的外面用户那里得到反馈之后再迭代开发。
如果谷歌开发了一些产品，或者在已有产品上增加了新功能，会尽可能早地对外发布并让外部用户能使用并从中受益。
在这个过程中需要较早地把用户和外部开发者牵扯进来，并要有一个很好的处理规则来验证是否满足发布条件。
最后，自动化测试和手动测试，对于所有的三种类型测试【小规模、中等规模、大规模测试】来说当然更喜欢前者。
如果能够被自动化，而且不需要任何人智力和直觉判断，那就应该把它变成自动化的。
只有在特别需要人为判断的时候，例如用户的界面是否漂亮、或暴漏一些涉及用户隐私的内容时，在这些情况下应该保留手动测试。
话虽如此，对于谷歌来说非常重要的是仍然使用了大量的手动测试，不管是使用文本记录的方式还是使用探索性测试，虽然有些已经进入了自动化测试的视线。
业界使用的录制技术将手动测试转变成自动化测试，可以在每个版本后自动地重复运行，这样保证了最少的回归工作，并把手动测试的重点放在新问题上。
而且，谷歌已经将提交BUG的过程和一些手动测试的日常工作也自动化了，例如，如果一个自动化测试运行失败，系统会自动检测到最后一次代码变更的信息，一般来说这是引起测试失败的原因，系统会给这次代码提交的作者发送一封通知邮件同时自动创建一个BUG来记录这个问题。
在测试上，“人类智慧的最后一英寸”体现在测试设计上，谷歌的下一代测试工具也正在这个方向上努力尝试，将其自动化。
这些工具在以后的文章中会被提及强调。
不过，下一篇文章还是会将重点放在软件测试开发工程师【SET】的工作上。
希望能得到你的持续关注。
第六部分软件测试开发工程师【SET】的生命软件测试开发工程师【SoftwareEngineersinTest】是软件工程师，专注在测试实现。
首先，软件测试开发工程师是开发角色，在招聘和内部晋升资料中被我们奉为100%的编码角色。
当在招聘面试软件测试开发工程师的时候，对于编码的要求几乎和对软件开发工程师的要求是一模一样的，而且更强调如何去测试自己写的代码。
换句话说，软件开发工程师和软件测试开发工程师都需要回答编码问题，而且软件测试开发工程师会被问到一系列测试相关的问题。
正如你可能想到的，这是一个很难满足的角色。
软件测试开发工程师的数量如此之少的最有可能的原因是，事实具备软件测试开发工程师所需技能的人非常难找，而不是我们刻意使用了什么神奇的生产率公式【译注，开发测试比率公式】，这也是我们适应当前工程实践的一个必然结果。
我们还在优化我们的工程实践?
这是一个非常重要的任务，并且为所有参与的人构建一些流程。
通常来说，软件测试开发工程师不会在早期设计阶段就介入。
不是故意这样做，而是和多数谷歌的产品是如何诞生的有关。
一个常见的新产品诞生的场景是这样，已有的谷歌产品的员工会投入20%时间来开始新的产品。
Gmail和ChromeOS这2个产品，从一个简单的想法开始，并非正式地由谷歌授权去做的，慢慢地随着时间的推移，越来越多的开发和测试加入进来并把产品发布。
在这种情况下，早期的开发要关注的重心并不是质量，更关注提供一些理念，在解决了扩展性和性能的问题之后，再更多地关注质量。
如果你创建了一个webservice，但是不具有可扩展性时，测试这时候还并不是你最大的问题。
一旦这个产品已经明确未来可以发布的时候，研发团队就开始寻求测试的介入了。
你可以想象这样一个过程，某个人有了一个好主意，他开始思考并写了一些试验性质的代码，从其他人那里获取一些建议然后对这些代码做了改进，并劝说更多的人加入，写了越来越多的代码，然后意识到他们做的事情很重要，通过更多的代码把这个想法变成可以呈现给他人并得到反馈的模型„这个项目在谷歌的项目库中就创建了，这个项目慢慢地变成了一个真实的项目，测试也只有在项目变成真实的项目之后才会介入进来。
所有真实的项目都有专职的测试人员么？
默认情况下是没有的。
小型项目和只有受限用户使用的项目一般是开发人员自己做测试。
其他的一些对个人或者企业用户有潜在风险的项目，测试会介入。
当开发团队寻求测试团队参与并帮助他们时，他们有责任使测试人员相信他们的项目是令人兴奋并充满潜力的。
开发总监会给测试总监解释他们的项目、进度、发布计划，一起讨论测试工作如何划分，并就开发需要满足的单元测试水平及开发参与测试工作程度上达成一致，发布流程中开发与测试的责任也需要明确。
软件测试开发工程师在项目初期可能不会参与进来，一旦项目变成真实的项目后，测试人员将在软件开发过程中发挥巨大的影响力。
当我说“测试”时，并不是仅仅意味着单纯的检查验证代码路径。
测试人员不是从开始就参与进来的，但“测试”却至始至终都有。
实际上，一个开发尝试去checkin代码的时，测试人员的影响力在这个时刻可能就已经显现出来了。
【译，这里指软件测试开发工程师会对开发人员的测试程度做一些要求，开发人员在checkincode的时候需要想一下自己是否满足这些要求，这就是测试人员的影响力】。
欢迎继续收听并尝试理解我所说的这些东西。
升级会员 