渔舟唱晚的天空
——welkinwalker的遐想
摘要: 《How Google Tests Software》这本书在4月初已经在Amazon.com上开卖了。据一位看了这本书的一位曾经在Google工作的朋友说,这本书所写的内容和James在博客http://googletesting.blogspot.com上的连载文章内容基本是一致的,只不过书上的内容更系统化,内容更充实一些。这几天抽了3天时间把他们都翻译出来了,以飨那些在测试工作中迷茫的读者们。这个博客连载国内我之前也看到过翻译,但我看到的版本貌似是机器翻译的,或者说机器翻译+人工校对的,比较晦涩,我这里翻译的文章都是通读后的意译,加入了一些结合我自己工作经验的理解,对于拿不准的地方也贴上 阅读全文
posted @ 2012-04-18 11:26 welkinwalker 阅读(3202) 评论(1) 推荐(0) 编辑
摘要: (一)google在公司的大层面组织上有很多的Focus Area,search, apps, ads, mobile, operating system这些都是不同的FA。测试隶属于其中的一个FA,这个FA的名字叫Engineering Productivity。这个FA由很多纵向的横向的学科构成... 阅读全文
posted @ 2012-04-18 11:23 welkinwalker 阅读(14368) 评论(1) 推荐(2) 编辑
摘要: SET是专注于测试的软件工程师。他们是乐于编写测试功能的软件工程师。首先说,SET是开发者,在招聘的时候我们就会说这个工作是100%的编码工作,晋升阶梯中的描述也是如此。当我们面试SET的时候,对于写代码能力的要求跟SWE几近相同,之外我们还会强调SET要懂得如何测试他们自己的代码。换句话说,SWE和SET都要回答编码问题,但是SET要面对更多的测试问题。你应该猜到了,这个角色很难做,而且造成Google的SET数量很少的原因,可能完全不是因为我们有针对生产率的一套魔法公式,而在于:把我们的工程实践应用到SET技能的人真的很难找。我们优化这项重要的工作并且围绕这些人建立流程。SET不会参加到前 阅读全文
posted @ 2012-04-18 11:08 welkinwalker 阅读(1875) 评论(0) 推荐(0) 编辑
摘要: 相比SWE和SET,TE在Google是一类新职位。因此,这个职位的角色定义还在进行中。当前Google的这代TE正在为这个职位开辟一条道路,这样就能更好的指导后面招聘进来的TE来开展工作。我们这里描述的是在Google新兴起来的一个最好过程(It is the process that is emerging as the best within Google that we present here)。并不是每个项目都需要TE。那些在产品初期的实验性尝试,没有良好定义的任务或用户场景的项目势必不会引起很TE的注意。如果一个产品看起来没什么希望(作为一个概念他不能通过审核)或者尚未能吸引用户 阅读全文
posted @ 2012-04-18 11:08 welkinwalker 阅读(1207) 评论(0) 推荐(0) 编辑
摘要: 匍匐、步行、跑步向前之所以Google的测试人员相比其他公司非常少但是却还可以保持较好的质量,一个首要的原因就是:我们很少试图一次性发布很多功能。事实上,我们做的恰恰相反:首先构建一个产品的核心部分,并在他能惠及尽量一个大群体客户的时候就发布他,然后收集反馈意见并且迭代改进。我们就是这么来开发Gmail的,以至于beta标签在这个产品上呆了4年。这个标签也让我们的用户知道这是一个在不断完善的产品。直到我们能够保证用户email数据达到99.99%的可用性的时候我们才把这个beta标签取消。看到了没,质量的改善贯穿整个工作当中。通过这个过程(确保质量)并不是一个很冒险的过程。事实上,为了能到达b 阅读全文
posted @ 2012-04-18 11:07 welkinwalker 阅读(568) 评论(0) 推荐(0) 编辑
摘要: 在测试层级的划分方面我们没有采用代码级、集成级、系统级这样的分类方式,取而代之的小测试、中测试、大测试,这样做是为了强调测试的规模而不是外在形式。小测试只会覆盖一小撮代码,然后是中、大测试。不论是SWE、SET、还是TE,都会执行这三类的测试,可能是通过自动化的方式开展也可能是手工的方式。小测试通常(但不总是)通过自动化的方式来运行,它只会运行一个函数或一个模块的代码。通常他们都是由SWE或SET来完成编写的,他们的运行可能会需要mock环境,TE通常会在需要诊断一个具体问题的时候直接拿过来运行。对于小测试来说他们关注的是些典型的问题,如数据损坏、错误条件或一个错误。一个小测试要回答的问题是: 阅读全文
posted @ 2012-04-18 11:07 welkinwalker 阅读(359) 评论(0) 推荐(0) 编辑
摘要: SWEorSoftware Engineer。写功能代码,并发布到终端用户。他们写设计文档、设计数据结构,并且花大量的时间write和review代码。他们要写大量的测试,包括测试驱动设计、单元测试、参与小、中、大的测试。他们对任何他们碰过的代码质量负责,包括写的、修复的、修改的。SETorSoftware Engineer in Test。也是一个开发者,但是他的侧重点在于可测性。他们review设计,并且审阅代码的质量、风险。他们重构代码并且使他们具备更好的可测性。他们编写单元测试框架、自动化测试框架。从写代码这个角度来看,他们是SWE的伙伴,但是他们关心的是如何从代码层面上提高质量、测试 阅读全文
posted @ 2012-04-18 11:05 welkinwalker 阅读(702) 评论(0) 推荐(0) 编辑
摘要: 首先明确,质量是测试不出来的。有个比喻很有意思:不能通过反复测试来提高质量,这就好像你不能通过反复称重来减肥一样。在Google,质量不等于测试,有些公司则不然。“质量不能通过测试而植入”这个是老生常谈了,我们不必去怀疑他的正确性。从手机到软件,如果你没有在一开始就把它构建好,那么他永远不会正确的工作。如果你不知道一开始不重视质量的代价,那么去问问陷入“召回门”的汽车厂吧。“质量不能通过测试而植入”这话本身并不通俗,它也不是一个准确的描述。可是为什么这么说?因为显然,如果没有测试你不可能开发出什么高质量的东西。对啊,如果你不测试,你怎么知道你开发出来的东西就是高质量的呢?解决这个问题的简单方法 阅读全文
posted @ 2012-04-18 11:05 welkinwalker 阅读(539) 评论(0) 推荐(0) 编辑
摘要: google在公司的大层面组织上有很多的Focus Area,search, apps, ads, mobile, operating system这些都是不同的FA。测试隶属于其中的一个FA,这个FA的名字叫Engineering Productivity。这个FA由很多纵向的横向的学科构成,测试是其中最大的一个学科。Eng Prod这个FA由下面的部分组成:product team。公司内部使用的工具还有开源工具都由它来生产,这些都是提高生产率的工具,包括代码分析工具、IDE、case管理工具、自动化测试工具、编译工具、编译系统、代码版本控制工具、code review工具、bug dat 阅读全文
posted @ 2012-04-18 11:04 welkinwalker 阅读(1470) 评论(0) 推荐(0) 编辑