How Google Test Software读书笔记(二)

第三章 The Test Engineer

这章主要介绍Google的TE，就是传统测试工程师每天到底都做些什么？罗马不是一天建成的，曾经的Google也是几乎没有测试的，但一直拥有最优秀的一批工程师，以技术为导向的这么一个公司，技术厉害的人才是一等公民。但是随着互联网时代的爆发和变迁，他们也逐渐意识到，质量的保障和测试的意识、手段、思维方式也是一门艺术，是值得尊重的一门技能。Google可以说把SE（测试工程师）这个角色的定义挖掘发挥到了极致。

毫无疑问TE角色是应该专注在系统真正的用户上的，同时他们也需要相当的技术，Google衡量一个优秀的SE提出了以下几条标准：能否评价系统存在的漏洞？能否在安全性、私密性、性能、可用易用性、兼容性、国际化全球化上给出准确的分析？能否与其他系统或者硬件轻易的集成？当问题出现了，有哪些有效的时候来诊断调试收集必要的反馈数据提供给开发工程师更迅速的定位并解决问题。Google很看中的是SE是否能成为产品的专家，能否具有很强的沟通合作能力，跨部门的利用所有Google的资源来解决各种问题。

关于Test Plan，Google里也存在一个很常见的问题。Test Plan总是创建得很早很早，然后就一直被搁置在一边，没有其他人会有意愿主动去看它。Google解决这个问题的方式是：需求会快速变更，所以Test Plan也应该时刻保持更新，它应该描述了产品的核心竞争力，包含了产品的架构和组件图，清晰的描述了产品的职责是什么。其实这也是一种Agile里提到的团队共同的愿景，当大家时刻可以看到一份同样的描述产品最重要信息的文档，树立起同样的愿景为之努力时，这就是一份优秀的Test Plan了。（不要写成散文，不要写成销售推广，它要确切的描述了测试对象和测试最终的目标）曾经Google内部尝试过一种时间叫10分钟Test Plan，目的不是为了真的逼大家只用10分钟写出一份Test Plan，而是督促大家只把必要的最重要的信息放在Test Plan中，保持大家都愿意打开来它的一种意愿。

那么Google的Test Case又是如何产生的呢？这一套流程也很有意思。他们首先会把产品的职责定义出来用一个个名词来表示，称做“Component”，然后会用一系列形容词描述产品的特点，称作”Attribute”，接着当某个Component结合了一个Attribute之时，就产生了一个能代表具体场景的”Capability”，意味着产品的某个功能可以做什么，在这个场景的基础上，就可以衍生出一个或者多个测试用例。举个例子：Google+的Profile, Stream, Circles(圈子)都是Component，Google+的Attribute包含有Social, Easy, Relevant, Private，将二者关联起来可以产生的Capability举例：

• Profile(用户档案) should be Easy，so Easy to enter and update and have it propagate. 
• People（Google+用户）should be social，so Users can connect with user’s friends, coworkers and families.

基于这样的场景Capability，每一个都可以设计数个测试用例出来。Google的测试用例就是由这种二维的Component+Attribute，关联组合出的Capability衍生出来的。

Google的TE还非常注重Risk Analysis，主要从两个方面：出现的频率和所造成的影响。测试工程师有责任去对产品的任何缺陷做风险分析，甚至将结果主动递交给最应该关心它的人。当然风险分析不只是针对Bug，还包括对产品的测试覆盖比较薄弱的没有触及的区域的描述，而不是简单的答复一个产品质量还行、不错之类的话。任何产品直到Release出去也不可能尽善尽美，不管你做再多的测试，也无法产生完美无缺，所以风险分析能对产品面世之后的质量跟踪和反馈分析提供许多参考。

由于TE更加关注可视化的东西，对人员的挑选，在面试中看中的点就跟SET不一样。一般Google会给定你一个测试场景，希望你充分发挥主观能动性，在交流中让场景模糊的部分越加清晰，设计出尽可能全面覆盖的测试用例，并提出场景直观上需要改进的部分，哪怕是字体、颜色、布局等用户体验的改进意见。当然基于Google产品的背景，面试者肯定还要在性能、国际化、云服务等方面提出对场景的看法。

最后要说的是，Google对TE的管理方式是：Pirate Leadership。也就是像海贼王里的海贼一样，自由的选择自己想上的船想去的海域。每个TE都可以追求自己觉得刺激、自由的生活，如果对本项目不感兴趣，可以主动申请加入自己最感兴趣的项目组。事实上Google也鼓励TE在各个项目之间换来换去吸取不同的经验增长见识。

第四章 The Test Engineer Manager

这章主要介绍在Google，测试团队是如何被管理的。从之前没有测试，到测试团队组建，到现在的稳定成熟，都经历了哪些变迁和产生的新的文化。

本章主要是采访了许多Google不同项目的测试主管，询问他们的经验和经历的困境等等。比如Gmail的测试经理谈到Gmail的测试过程划分为20%的探索性测试，30%由TE主导来进行定向的功能覆盖测试，还有50%是由SET研发的自动化测试覆盖。他们还会根据用户的类型建立用户模型，反馈在测试过程使用的数据中。Android测试经理谈到他们的测试很大一部分都需要TE，因为要覆盖大量的设备型号和硬件部署，他们总结出探索性测试要带着一定的目的性去做，而不是简单的漫游测试走到哪算哪，而这种目的性往往来自于对源码改动的部分和对关联部分的理解能力，所以TE也需要阅读许多代码的。

这里还想提到的是，Google的许多产品都使用到一种叫做”Free Testing”，即让真实的用户来帮助测试。这也是现在许多产品都直接发布beta版的原因，让全世界使用互联网的用户都用起来，产生反馈，发现一些难以发现的Bug，并给予一定的奖励。到目前为止，Google的许多产品并不是都还活着，像Wave、Buzz这种，都是在市场的反馈和用户的使用中逐渐消亡被Google+给取代了。试想如果当初盲目投入大量的测试到Wave和Buzz中，但真正上线后却发现并不是用户最想要的东西，损失将会是多么大。当然直接放到市场上让用户去做免费的测试还有一个前提，就是有强大的反馈系统来保障问题发生时，所有需要诊断和修复的数据全都能自动提交到开发工程师面前，而且还要避免收集用户的隐私数据。这一点，由于Google长期坚持的工具文化，已经诞生了许许多多很棒的在线智能工具，所以对于Google来说可以做得很好，其他互联网公司就不知道了！

第五章 Improving How Google Test Software

没有最好，只有更好嘛，这一章基本是一个发散思维的杂谈未来的软件行业需要怎样的Test人才，现在最优秀的Test Engineer还有哪些方面可以做得更好。

对于SET来说，其实最终的趋势是跟SWE不分彼此，因为本身对他们的技能要求也是完全一致的。让所有的工程师都带着保障质量的责任心来编程，就是一种完美的状态。当然，客观上来说，工具文化还是需要有相当一部分工程师为了提高Bug追踪，自动化流程、代码缺陷这些目的而专注在效率工具的研制上。而对于TE来说，他们必须扮演用户的角色，更好的利用探索性测试发现产品内在和外在的缺陷，他们更多的要专注的是Test Design，快速的构建出产品的function map, risk map和tours，以用户的角度来将产品最清晰的诠释出来，所以他们必然是一批Google产品的专家。

未来的世界依然是互联网的世界，Native的东西会越来越少。无论是SET还是TE，都必须明白测试的构建、未来的趋势一定是以Web为中心的，用最少的人利用Web的资源做最多的事情。

Ending 总结

看完这本书，让笔者反思了许多以往工作中所犯的错误，诚然Google聚集了许多世界上最优秀的工程师，它的模式也未必适用于国内的许多公司。国内的测试行业也是乱象丛生，老板注重的永远是结果而不是过程，但是作为在一线奋斗者的工程师们，都应该反思我们如何提高团队的工作效率，利用各自擅长的技术优势简化软件开发中可以让机器和网络来做的流程，将人思维的价值尽可能放大，并积极的分享经验交流，共同促进整个行业水平的提升。笔者只是一个不知名的小小工程师，但也会尽自己的一份微薄之力。

Resource 书中优秀资源（大部分需要翻墙）

• Google Protocol语言：https://developers.google.com/protocol-buffers/
• Google C++ Style Guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• Chromium自动化框架pyauto： http://www.chromium.org/developers/testing/pyauto
• Native Driver: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html
• Google Test Blog:http://googletesting.blogspot.com/

声明：转载请注明原文出处。