其实在开始听谷歌的张南和潘岩开始演讲前，了解下 Google Test Certified 会有所帮助。
甚至，我们从此次的演讲中依然能感受到，谷歌对建立测试认证标准的努力。下面我们仔细聊聊这次的演讲。
产品由简到繁需不同的测试体系来支持，如何在开发效能和测试效能之前寻找平衡点是每个发展中的公司痛苦的事情。谷歌经历了小城镇式的开发模式到大都市模式，测试策略也从1.0到测试策略3.0。每个阶段的痛点都不一样，所采用的对策也不一样。测试模型从大体上，是从bug驱动到测试驱动，到3.0的数据驱动。对于测试的技术要求也是越来越高。从ppt上来看，谷歌在2.0阶段已经实现了测试全自动化，这在业内还是属于领先的。这个有可能和谷歌的业务有关。至少到目前为止，我经历的项目中，手工测试的比例还是占了大头（我记得7年前在谷歌做vender的时候，DE项目其实手动比例也有50%左右，但是其他项目，比如谷歌的image啊，据我所知好像都自动化了）。
测试能放心地交给自动化，我想很大一部分应该得益于谷歌工程师的高素质和完善的 code review 机制。Ron Patton 的《软件测试》中反复强调一点：问题发现的越早，成本越低。需求阶段发现问题，就可以避免浪费开发资源，开发阶段发现问题，就可以避免浪费测试资源，测试阶段发现问题，就可以避免发布之后的打patch啊，回滚啊，紧急发布啊，从而避免线上故障带来的直接损失。需求阶段一般就依赖于强大的pd，但是pd一般都坑，
所以开发就非常关键，而pre-submit 和 post-submit 这两个阶段就变得至关重要，提交前的code review 和提交后的冒烟测试和持续集成就是这两个阶段的利器。
谷歌的CR做的非常好，LGTM已经深入人心。我记得我那个时候，提交代码之后，CR个个把礼拜是正常的事情。遇见一次，搞了半个月，许多开发轮流CR。我还记得有一会测试提交代码，然后国外的一个耿直boy直接CR后打回，totally useless，全部重写。反观我们目前的情况，CR大多数情况是一种流程上的摆设，是开发重新把自己写的讲一遍，不会深入细节，也不会举一反三。很多线上问题，如果有细致的CR，就不会出现。
再来看持续集成，现在国内公司都爱持续集成，但是侧重点在解决开发发布或者出包效率，对于持续集成中的测试工作投入偏少。这可能和我们的测试类型有关：
从我们一直推崇的测试金字塔来看，本末倒置的很厉害。这样也就把产品质量往后压了很多，导致很多事情在集成测试阶段之后才发现，而测试也疲于奔命。这也是老生常谈的问题了。这么多年了，似乎也没有解决的也很好。也似乎只有谷歌这样的公司，搞得不错，但我还是那句话，和业务有关。
从演讲和PPT上不难看出，谷歌也在摸索移动测试。谷歌缔造了安卓帝国，但是Android测试未必做的最好。从大会整天的topic来看，国内的移动测试其实是领先的，有的甚至是超越谷歌的。比如，华为对标谷歌的实验室，比如腾讯的专项专题。不过由于毕竟Android是谷歌亲儿子，所以有些内部的能提升效能的工具还是领先业界一大截，我记得谷歌就有一个内部adb，比正常adb好非常多。然后这次演讲讲到的 image diffing service，谷歌的移动lab等。
但是我觉得技术都不是问题，我们看后半程潘岩的演讲，可以明显感受到，他们是在从整个研发测试流程上来提升移动测试的效率，提高自动化比例，解耦普适性和移动特特性，提高可测性，而且也只有这样，潘岩后面讲的工具和测试平台才能用的上。
2013年的时候，James Whittaker的《Google软件测试之道》的书揭开了谷歌测试的神秘面纱，一度被国内捧为测试圣经。这一次，张南和潘岩带我们再次走进谷歌测试，了解了谷歌的移动测试。其实可以感受到作为先行者，谷歌做的很好，但是也没有到赶超我们一大截的地步。大道同归，国内公司在移动上的实践，方向和策略上也是类似的。我记得我一个老板曾经说过，整个技术圈，80%都是差不多的，差别在20%的执行者。
这一次，大家了解了谷歌的移动测试，再看看自己公司做的，找到一些共鸣，找到一些认同，然后继续探索和研究，这也是一种收获。这大概也是在外面参加会议的意义。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。