luhuajcdd的专栏

多的系统阐述。虽然谷歌的技术路线在执行的过程中不断地进化，但公司的测试策略却从来没有变化过。谷歌现在是一家拥有搜索、应用、广告、移动、操作系统等产品的公司，我们在这些涉及到的产品领域里发挥着非常有意义的作用。当我们涉及到一些新的领域或者在旧领域里快速成长的时候，必须要求我们的测试也在同步的扩张和改进。在这个系列文章中提及的测试技术，多数是我们当前正在使用的，还有一些是希望以后在不久的将来可以用到。首先先介绍一下组织结构，这一部分也可能会让你感到惊奇。其实在谷歌没有真正的测试部门，测试依托在各个产品领域部

角色，在招聘和内部晋升资料中被我们奉为100%的编码角色。当在招聘面试软件测试开发工程师的时候，对于编码的要求几乎和对软件开发工程师的要求是一模一样的，而且更强调如何去测试自己写的代码。换句话说，软件开发工程师和软件测试开发工程师都需要回答编码问题，而且软件测试开发工程师会被问到一系列测试相关的问题。 正如你可能想到的，这是一个很难满足的角色。软件测试开发工程师的数量如此之少的最有可能的原因是，事实具备软件测试开发工程师所需技能的人非常难找，而不是我们刻意使用了什么神奇的生产率公式【译注，开发测试比

Steven Grimm很好地回答了这个问题，觉得还不错，这里以第一人称翻译了一下。对于PHP的代码，我们写了非常多的基于PHPUnit测试框架的测试类，这些测试类覆盖范围比较大，从简单的判读真假的单元测试到大规模的后端服务的集成测试。开发人员把运行这些基于PHPUnit的测试用例作为他们工作中的一部分，同时这些用例也在一些专用的设备上不停地被运行（注：持续集成模式）。当开发人员对一些代码做了比较大的修改时，在开发机器上的自动化工具会运行这些测试用例的同时也会生成相应的代码覆盖率数据，对于需要提交到代