《Google软件测试之道》读书笔记---第四章

第一章 Google软件测试介绍
第二章 软件测试开发工程师
第三章 测试工程师
第四章 测试工程经理
第五章 Google软件测试改进

 

第四章 测试工程经理

测试工程经理是作为独立贡献者的一个技术岗位，负责所有的支持团队（开发、产品管理、产品发布、文档等）之间的联络。

4.1测试工程经理的工作

1.了解 你的产品

2.知人善用

4.2获得项目和人员

4.3影响力

自己作为团队的代表，测试工程经理必须努力发现团队里的好方法、好工具，并分享给其他团队。好的方法和工具，只有在更多的产品中成功应用，才能体现出更大的影响力。

4.4Gmail测试工程经理Ankit Mehta的访谈

1.你的测试团队需要找什么样的人？

我需要寻找那些不会沉迷于信托的复杂性、遇到困难的问题时能够分解为可执行的步骤把那个能最终解决的人。我需要有执行力的人，他们会被紧迫感激发而不是吓跑。我需要能够在创新和质量中掌握平衡的人，他们不应该只满足于发现更多的bug。更重要的是激情和真正想做测试的。

2.在测试领域什么东西会引发你的激情呢？

我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。这个经典的矛盾迫使我为这两个目标不断优化，而不会伤害我自己或我的团队。创建一个产品不难，但要快速创建一个高质量的产品会有相当大的难度，而这正是使我的工作---富于挑战又充满乐趣。

4.5Android 测试工程经理Hung Dang的访谈

1.显然你很认真地对待手工测试。

我是手工测试坚定不移的支持者。坐下来自己钻研整个产品不是明智之举。我们需要仔细观察要就行测试的每日构建版本，分析里面有些什么。哪些是变化了的？有多少行新增或修改的代码？有多少新的或更改过的功能我们需要处理？提交代码更新的是哪些程序员？与昨天的版本相比，变化的代码分布有多广？这些问题都能 帮助我们抓住重点，而不是自顾自地探索整个产品。针对每日构建的版本，我们可以把重点放在发生改变的地方，来让自己的工作更有效率。这也意味着团队之间的沟通非常重要。我要求每个人都要进行探索式的测试，因此减少大家的重复工作很重要。我们有每日沟通会，来确定哪些东西是最重要的、需要测试的，保证大家可以一起来完成他们。手工测试对我来说就是抓重点和做沟通。有了这两点我就认可所付出的努力就是值得的、有价值的。

4.6Chrome 测试工程经理Joel Hynoski的访谈

1.多样性的问题确实是测试人员的痛点，讲两项你用来驯服不听话的互联网的技术或方法吧

我来谈谈应用程序的兼容性和UI自动化吧。应用程序的兼容性对浏览器来说相当重要。我们需要回答这样的问题，”Chrome浏览器能兼容互联网的站点和应用程序吗？“换句话说，Chrome能正确显示页面和运行web应用吗？很显然我们不可能进行完完全全的延展，因为那么多网页和应用我们没法一一试过。即便我们能一个一个试验，我又可以用什么东西来对比结果呢？我们解决这个问题的办法是测试哪些最流行的站点，然后和Chrome的参照版本，甚至其他浏览器进行对比。我们的自动化程序会渲染千个站点然后逐点来对比显示结果。我们每天的开发版本都会做这样的测试，所以很快能找到回归的问题。渲染测试结果任何不一致的地方，都会有人工来检验哪里出了问题。
不过检查结果只是一部分工作。我们还需要能驱动浏览器来访问站点和应用。我们是通过UI自动化来做到这一点的。你可以用Chrome的一个叫做自动化代理的API来启动浏览器，跳转到一个URL，查询浏览器状态，获取窗口和标签页的信息，等等。我们为它提供了一套Python接口，这样你就能用Python编写脚本来驱动浏览器了。通过它能开发出强大的功能知道测试。我们的开发人员和测试人员共同开发了一个庞大的测试库。 

4.7测试总监

总监负责批准招聘和转岗，全面掌控测试团队人事方面的各种问题。

4.8搜索和地理信息测试总监Shelton Mar的访谈

1.你们怎么制定这些自动化配置测试呢？

要非常小心，每当我们发现某项配置让搜索结果变差时，我们就编写一些测试检验哪些配置和类似可能引起问题的变化。

4.9工程工具总监Ashish Kumar的访谈

1.你对那些准备构建自动化流水线的公司有什么建议？从哪些工具开始？

特别重要的一件事，是要关注团队里新来的开发工程师必须使用到的开发环境。要让代码的获取、编辑、测试、运行、调试和部署都非常简单。消除开发人员这些环节的痛苦会大大提高生产力，而且能帮助团队按时交付高质量的软件，要想达到这一点，清楚地定义依赖关系非常重要。建立一套持续集成的系统，让它能够稳定运行，能够快速的向开发工程师提供反馈。如果信息反馈超过了几分钟，那就需要加入更多的机器。CPU的运行时间可要比程序员在事务间进行切换或等待要便宜多了。让执行和调试代码像输入一条命令那么简单，部署也许能够做到这一点。如果是互联网公司，还要能够支持简单的灰度发布。

4.10印度Google测试总监SujaySahni的访谈

1.你也几次提到性能和压力测试，这里有什么故事吗？我知道你们在Gmail的性能测试方面介入很深。

Google的Web应用产品范围非常广泛。保证低延迟的用户体验是非常重要的目标。因此，性能测试（重点是JavaScript的执行和页面渲染的速度）是任何产品发布前的一项关键检查。以前，性能延迟问题往往需要几天甚至几个星期的时间来定位和解决。印度工程生产力团队开发了Gmail的前端性能测试框架来覆盖重要的用户行为，保证对用户最频繁执行的操作进行细致的性能测试。性能测试使用一个定制的服务器，测试在受控的环境中部署运行，利于保持环境稳定，便于定位回归问题。这个解决方案有三个部分。

• 提交队列：允许工程师在提交代码变更之前执行测试（收集性能延时数据）。开发人员就能更快得到反馈，避免把缺陷引入代码库。
• 持续构建：把测试服务器同步成最新的代码并持续执行相关测试，发现并阻止回归问题。这使团队可以把用于检测回归问题的时间，从几天或几星期缩减到小时或分钟级别。
• 产品性能延迟检测：用于定位特定代码变更导致的产品性能延迟回归问题。我们对变化范围进行切分，在多个检查点分段运行测试。
  这个方法在我们的产品发布前帮助定位了很多关键缺陷，并推动了测试前移，因为开发人员自己就可以非常容易地启动这些测试。