原创翻译：James Whittaker系列——Google是如何测试的（2）

 原创翻译，请勿转载！！！！

     为了让“you build it,you break it”的格言成真，在传统的软件开发岗位之外，需要再设置几个必要的角色。特别地，能做开发同时又能有效且高效地做测试的这类工程师角色，是必要的。在Google，我们增加了这类角色的岗位，来帮助其他工程师提高工作效率。这类工程师通常把自己看成是测试人员，但是他们真正的使命是提高生产率。他们的存在是为了让研发人员的工作更加有效，特别是对产品质量的提升方面。这里是对这一角色的一些总结：

      软件开发工程师（SWE）是一个传统上的开发角色。他们的工作是实现产品功能的代码。他们创建设计文档、选择最优的数据结构和整体框架，并且花费大量的时间在代码的实现和代码的审核上。SWE需要编写包括测试驱动设计、单元测试、参与各种大中小规模的测试等等。SWE对自己涉及部分的产品质量负责，不论这部分代码是不是他写的、是不是他修复的的或者修改的。

    软件测试开发工程师（SET）也是一个开发角色，只是其工作的重心是在产品的可测试性和通用测试基础框架上。他们参与设计评审、密切关注产品质量和风险。为了增加代码的可测试性，他们甚至会重构代码，并编写单元测试框架和自动化框架。SET与SWE在代码构建上是合作伙伴，相比于SWE主要负责增加新功能和提升产品代码性能，SET更加关注提高产品质量和测试覆盖率上。

    测试工程师（TE）是一个和SET工作方式相反的角色，它把测试放在首位，开发放在其后。Google大部分TE的工作重点是编写模拟用户使用场景的自动化脚本、甚至有时他们就把自己当成用户。他们也组织SWE和SET的测试工作、角色测试结果、驱动测试执行、特别是在项目的后期阶段，推动产品发布。TE是产品专家、质量顾问和风险分析师。

   

      从产品质量的角度来看，SWE独立负责产品功能和其质量。他们负责错误的代码设计、错误的代码修复、TDD、单元测试，并和SET一起编写测试代码。

    SET也是开发人员，负责提供测试支持。Google有一种测试框架，通过使用桩、mock和管理代码Check in的提交队列，可以把新开发的代码隔离来。换句话说，SET编写的代码可以帮助SWE来测试他们写的功能代码。多数的实际测试由SWE来执行，SET的工作，就是确保这些功能模块的可测试性，确保SWE也参与到测试代码的编写中去。
      很明显，SET的主要关注对象是开发人员。SET的首要职责是各个模块的质量保证并保证开发人员可以很容易地测试自己写的代码。这种开发模式的缺陷，我想读者已经注意到了：那用户方面的测试呢？

        

    用户需求的测试是TE的职责。考虑到SWE和SET已经做了足够多的模块和功能级别的测试，下一步要考虑的就是验证这些可执行的代码和数据集成起来运行是否能满足用户的需求。TE扮演的是双角色，首先，它要确认开发人员测试方面的工作是否做到位，任何明显的BUG都会暴露出开发人员早期测试工作不到位甚至马虎，当这类明显的BUG变少时，TE就会把注意力转移到用户场景的验证上去，确保产品的性能、安全性、国际性等。TE在执行大量测试的同时，也负责和其他团队的TE、外包测试人员、产品原型测试的众多测试者、内部尝鲜者、Beta用户及早期用户进行合作交流，与各方讨论产品基础设计带来的风险、功能逻辑的复杂度，及产品缺陷的规避方法。一旦TE参与到项目中，他们的工作基本就停不下来。

OK，现在各种角色已经有基本了解了，我会对各角色的工作内容做更详细的说明。留到下次吧。。。感谢你的关注。

【译者注，“you build it, you break it”这句格言，后面还有一句是you fix it。“You build it, you break it，you fix it”，这句话的意思是，谁开发的代码，谁就更适合做测试，中文俗语就是“谁的屁股谁自己擦”】