在最近的文章 What Test Engineers do at Google 中，我们讨论了测试工程师们在 Google 做什么的问题。 这篇文章我会讲 Google 的测试工程师工作的另一方面： 建立和改进测试基础设施，提高工程师的生产力。
更新老旧的系统让新工具成为必要
几年前，我加入了一个致力于以一种新型工具来取代旧系统的工程师团队。构建替代系统需要花费很长的时间，在保证原有的遗留系统保持运作的同时，建造替代系统还不能影响到外部用户，所以我们不得不添加一些新功能。
原来的系统是如此的复杂和脆弱，以至于工程师们需要花费大部分时间来分类和修复各种漏洞，并做各种测试，导致只有很少的时间来实现新功能。 重写的目标是从旧系统中学习，并构建更易于维护和扩展的新系统。 作为团队的测试工程师，我的工作是理解导致高维护成本的原因，并找出改进方法。 我发现了两个主要原因：
1、紧耦合和抽象不足使得单元测试非常困难，结果，大量的端到端测试成为了对该代码的功能测试。
2、用于端到端测试的基础设施没有很好的方法来为这些服务创建和注入模拟， 结果就是，这些测试不得不为所有这些外部依赖关系运行大量服务器，从而导致了非常庞大和琐碎的测试，但我们现有的测试执行基础设施还无法妥善地处理这些问题。
解决方案探索
起初，我尝试了是不是能把大型测试分成更小的测试，从而依靠较少的外部服务测试特定的功能，但结果证明是不行的，因为结构不良的遗留代码让这种方法需要团队配合来实现，我们需要在重构整个系统及其依赖项的条件下进行，而不仅仅是我所在的团队负责的部分。
在第二种方法中，也是同样着眼于大型测试，并试图模拟不需要测试功能的服务， 结果证明这也是非常困难的，因为依赖性经常改变，并且单独的相关性很难在200多项服务里跟踪。 最终，这种方法只是把工作从维护测试代码转到了维护测试依赖性和模拟上。
我的第三个也是最后一个方法，如下图所示，让小测试更有力。 在典型的端到端测试中，该客户端通过 RPC 远程调用若干个服务，这些服务接着再让 RPC 调用其他服务。 包括客户端和所有传递闭包的后端服务一起形成了一个巨大的依赖图（不是树状图！），这些都必须在端到端测试中运行，新模型改变了测试客户端和服务集成的方式。不再是运行客户端通过输入来以某种方式触发RPC调用，我们为 PRC 存根方法调用的代码编写单元测试。存根本身是用一个常见的模拟框架（如 Java 中的 Mockito ）来模拟的。 对于每组这样的测试，第二个测试数据常常倾向于说明模拟的数据对实际服务“有意义”，这也是通过单元测试完成的，通过重启客户端，使用与 RPC 模拟相同的数据来调用 RPC 处理程序服务。
这种集成测试模式适用于任何 RPC 调用，包括从一个后端服务器到另一个后端执行的 RPC 调用以及前端客户端调用。 当一致地应用这种方法时，更小的测试以及精准的集成性能测试让我们受益很大，并确保测试的性能是“真实的”。
为了找到这个解决方案，我建立，评估和舍弃了很多原型。 虽然对这种方法的理论验证只用了一天的时间，但我和另一个工程师花了一年时间才让它变成可用的成品。
应用
当看到新框架从他们的测试中移除了大量的样板代码时，工程师们很快接受了新的解决方案。 为了进一步推动其采用，我与工程团队组织了多天的活动，专注于迁移测试用例。 将所有现有的单元测试迁移到新框架，缩小覆盖差距，并创建验证模拟的新测试，这个过程花了好几个月的时间。 一旦转换了大约80％的测试，我们就开始比较新测试和现有端到端测试的效果。
效果非常明显：
此外，新测试是单元测试，因此你可以在集成开发环境(IDE)中运行它们，并逐步运行测试代码来 debug 。 这些结果让我们很少再运行端到端测试，端到端测试现在只在检测交互服务的错误配置时运行，而不是用它来做功能测试。
构建和改进测试基础设施以帮助工程师提高工作效率是测试工程师在 Google 做的很多事情中的一件。 从需求分析收集一直到完成项目，实施这个项目让我有机会设计和实现很多原型，推动解决方案的全面实施，带领工程团队采用新框架，并把整合过的工程师的反馈和实际测量应用于工具的持续改进。
参与51Testing软件测试现状有奖调查，
为你的2016画上圆满的句号！
