2017 GTAC 取消了

一个坏消息，一个好消息。

坏消息是：2017 年的 GTAC 取消了，坚持了 10 年，今年要缺席了。原因就是下面 E 文讲的，谷歌内部测试领域已经发生了比较大的变化，他们希望可以更多的演讲主题，甚至是形式，去反映这种变化，带来更多全新角度的分享。

好消息：不是永久，2018 年会回来的，可能谷歌也想给大家一个缓冲的时间去筹备一些自己的演讲吧。

在朋友圈和公众号翻了好多分享，终于找到一篇相关的文章，mark 学习下！

关于 GTAC

Google Test Automation Conference (GTAC) 是谷歌举办的每年测试领域盛会，从 2006 年以来已经举办了 10 届。每届都会邀请各个行业测试领域的牛人来做分享，也会有很多亮眼的测试框架平台在这里走向了全世界 (包括走进阿里巴巴)。
为什么看 GTAC

这个系列是一直想去做的，来公司进入互联网的这三年时间，接触了各种各样的测试框架，从接口的 Junit 系列，到 UI 的 Selenium 系列，延伸至无线的 Appium，到性能的自有框架等。记得第一次听说 GTAC 还是 14 年第一次接触 Appium，找到个视频是作者参加 2013 年 GTAC 时的分享，然后就发现了这个融合了各种测试相关话题的会议。

可惜的是，一直没有深入去每个视频都去看看，只是走马观花的扫了几个感兴趣的视频，因为是英文的，也就跳着看了看作者的主张和想法。这没什么不好的，只是在去年年初参加了公司内部测试交流时，因为最后一个讲，所以把前面每个人的基本都听了一遍。听的过程中，脑子一直处在一个专注和高速运转的状态，这个时候会有各种想法的碰撞，也会有原来很多忽略的细节疑惑被贯通了。接受与碰撞，这种状态很好，每年来这么一两次还是很有必要。

演讲正文

今年的 Keynote 演讲是位印度 MM，负责 Google 广告部门资深 SETI(Software Engineer, Tools and Infrastructure)，题目是《Evolution of Business and Engineering Productivity》。

原始链接

原视频 Youtube 地址 (*** 可观看)

PPT 链接
https://docs.google.com/presentation/d/1iVf-TogkdoIcvs8OpRMMWx76s9Zk4_f0JJ-e1sZIxog/edit#slide=id.p6

主要内容

开始主要回顾了 GTAC 的十年变化，初心和成果，也对今年哪些有趣的主题做了些预告。对这个系列感兴趣的，可以先参考这个目录https://developers.google.com/google-test-automation-conference/2016/presentations，我会选一些自己感兴趣的演讲进行分享。
限定了前提是谷歌广告部门情况，大家可以根据自身情况理解运用她的分享。开篇是对整个广告部门测试进化的一个总览，以城市为例子，最初是小镇，然后到城市，最后到未来都市。这种进化是各个维度的，不只是业务的量级 (比如 UV)，还有复杂度，信息的传递速度。在大数据时代，怎么更高效无缝的获取处理海量数据。

1、团队最初的配置，60 个测试员工对 500 个开发，95% 都是重前端的项目。所以，有一些自动化是在单元测试和冒烟测试，大部分都是手工测试。

2、根据经典的金字塔理论，开始逐步构建自动化，感觉他们比较特殊的是塔尖部分 Log，Privacy 和 Canary(金丝雀)。这些不知道是不是他们业务特殊性导致，可能广告相关的同学理解更深，Log 和 Privacy 的确很少涉及，也没怎么听说有团队做这种类型的测试。因为看简介，这个印度 MM 是主导在做 User Privacy 测试的，所以后面也有一些部门涉及到了这块儿。

3、自动化工具需要考虑的四个方面，互相影响，重要的是找到一个平衡。这块儿的话，感觉有些时候，做着做着反而忘了最初的那个 Utility，就是工具到底是服务什么目的，干什么用的。

4、1.0 阶段，他们的测试和版本策略，缺少自动化手段，也没有什么衡量指标，追求无故障，导致每个版本周期比较长，要 1~2 个月，无法很好的随业务扩展而扩展。

** 什么是 Engineering Productivity **

因为主要是一些理论和思想的阐述，第一次看完视频，其实还是有些迷茫的，里面反复提到了 Engineering Productivity，字面看是"工程师的效率"，但这和视频里 Google 广告部门的测试策略演进什么关系？后来专门搜了一下，看到了 Google Testing Blog 上的这篇文章《From QA to Engineering Productivity》https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html 才有些明白了。相信很多人读过《How google test software》这本书，书里介绍了 Google 测试团队里的两种角色：TEs 和 SETs。有点类似有些同学偏向业务测试 (TE)，有些同学偏向测试开发 (SET)。

在此基础之上，随着 SET 已经把各种测试领域相关的基础设施做的比较完善了，测试在项目中的周期大大缩短了。但是 Google 发现很多从代码提交到真正发布到生产环境过程，总耗时并没有太多变化，因为其他部分拖慢了流程。因此，他们把 SET 扩大了范围，去提速整个软件开发过程，比如写一些 IDE 插件提高开发的代码效率，提高代码编译打包的速度，制定衡量开发效率的指标等。这个时候 title 再叫 SET(Software Engineers in Test) 就不太合适了，投票之后，大家选择了 SETI(Software Engineer, Tools & Infrastructure) 作为新名字。

拉回来，SETI 其实就是为了提高整个工程师的效率，而不仅仅是测试领域，所以也就有了 Engineering Productivity 这个名词来代替这个谷歌的内部演进。

摘自 微信公众号：测码奔跑 有喜欢的请自行关注下，搬过来篇文章样式都乱掉了。。。