注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

世界的瞭望哨

认识自己 认识世界

 
 
 

日志

 
 

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

2012-03-20 20:00:32|  分类: 测试理念 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
原文传送门:http://sdet.org/?p=130

这是谷歌如何测试系列文章的第一篇。

Tuesday, January 25, 2011 9:08 AM

By James Whittaker
在所有我被问及的问题中,最多的就是关于谷歌是如何测试的。尽管在博客中【google testing blog】中有过零碎的解释说明,但还是需要更多的系统阐述。虽然谷歌的技术路线在执行的过程中不断地进化,但公司的测试策略却从来没有变化过。谷歌现在 是一家拥有搜索、应用、广告、移动、操作系统等产品的公司,我们在这些涉及到的产品领域里发挥着非常有意义的作用。当我们涉及到一些新的领域或者在旧领域 里快速成长的时候,必须要求我们的测试也在同步的扩张和改进。在这个系列文章中提及的测试技术,多数是我们当前正在使用的,还有一些是希望以后在不久的将 来可以用到。

首先先介绍一下组织结构,这一部分也可能会让你感到惊奇。其实在谷歌没有真正的测试部门,测试依托在各个产品领域部门里,我们称之为“工程生产力” 【原文, Engineering Productivity】。工程生产力部门拥有数量不等的水平或者垂直的工程学科,测试是其中的大头。简单地说,工程生产力部门由以下几部分构成:

1. 一个工具产品团队【a product team】,负责内部和外部开源的促进生产力的工具开发与维护,这些工具会被公司范围内的各种工程师使用。这些工具包括代码分析工具、IDE、测试用例管 理系统、自动化测试工具、Build系统、源码管理系统、代码审核调度系统、缺陷管理系统等等。 这些工具的都是为了提高工程师效率的,并且这些工具在策略上的目标多数是为了防止问题的发生,而不是发现问题本身。

2. 一个服务团队【a services team】,给产品部门【注:这里的产品部门团队是和工程生产力部门平级的,例如Search、Gamil、Chrome等产品部门】提供一些专业的建 议,包括一系列工具、文档、测试、发布管理、培训等方面,这些专家建议涵盖可靠性、安全、国际化等,甚至包括产品团队面对的功能问题。所有的其他产品领域 也都会得到这样的建议指导。

3. 嵌入式的工程师【Embedded engineers】,在需要的时候被产品部门高效地“借”去使用,这些工程师有些会和产品部门的团队坐在一起工作数年,另外一些当他们被需要的时候会被 借调到其他的产品团队。谷歌鼓励所有他们的工程师更换产品团队,用以保持团队忙绿且不断有新面孔,并如实地不带有任何偏见与政治。测试人员也是这样,但是 可以有节奏地选择更换产品团队的频率。我的下属里,有测试人员已经在Chrome团队工作了好几年,也有一些待了一年半后就换到了其他团队。对于测试经理 来说,必须在团队的产品经验和新鲜度上做出很好的平衡。

 

所以这意味着测试同学向工程生产力部门的经理汇报,但是他们会把自己看成产品部门团队的一员,像搜索、邮箱、和Chrome部门。从组织架构上看, 测试都是两个团队的一部分。测试和产品团队坐在一起,参与计划,一起吃饭,共享奖金,享受像全职的产品团队成员一样的待遇。这种单独的组织汇报关系的好处 是可以给测试人员之间提供良好的共享信息的讨论机会,好的测试思路可以很容易的在工程生产力部门内部蔓延,无论公司内的哪条产品线,都可以很快地使用这些 最好的测试技术。

测试人员的这种项目分离和汇报组织结构也有它的缺点,目前来看,最大的问题是测试人员被看做外部资源。产品部门团队不能对测试人员有太多的依赖,他 们自己必须要合理地控制产品质量。是的,没错,

在谷歌,是产品部门团队对产品质量负责,而不是测试人员。

每个产品部门的开发人员都需要做测试工作,测试人 员的任务是为产品部门团队搭建自动化测试基础设施和流程,测试人员让开发可以自给自足地、独立地做完成测试工作。

在这种模式下,我比较喜欢的是,开发和测试将有相同的地位。在质量方面,开发和测试成为了真正的伙伴,最大的质量重担交给本应属于的开发人员,开发 的职责就是正确地实现产品功能。另外这样可以保持多对一的开发测试比率,开发人员在数量上远超测试人员,并且测试工作做的越多,开发测试比率就会越大。产 品部门团队也会对这样的高开发测试比率而感到骄傲。

好,现在好像大家都是好朋友了,对吧? 相信你已经看到这种模式的一个问题,开发人员不能很好地驱动缺陷【Bug】的运转,开发不会测试。难道我要否认这一点么?不管怎样,我都不会否认,特别是 去年在GTAC talk 【GTAC 2010: Turning Quality on its Head,link http://www.youtube.com/watch?v=cqwXUTjcabs】 上做了一个开发和测试对抗的游戏后。(友情提示:测试赢了游戏)【这里感觉翻译的不好,原文是: No amount of corporate kool-aid could get me to deny it, especially coming off my GTAC talk last year where I pretty much made a game of developer vs. tester (spoiler alert: the tester wins).】

在谷歌,解决这个问题的办法是将角色再细分,我们通过设立不同的测试角色来解决这两种不同的测试问题。在下一篇文章里,我将详细阐述这些测试角色和谷歌是怎样将测试问题分成两部分来分别解决的。

 

公直 2012/3/8

  评论这张
 
阅读(216)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017