第一章 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的前端性能测试框架来覆盖重要的用户行为,保证对用户最频繁执行的操作进行细致的性能测试。性能测试使用一个定制的服务器,测试在受控的环境中部署运行,利于保持环境稳定,便于定位回归问题。这个解决方案有三个部分。
- 提交队列:允许工程师在提交代码变更之前执行测试(收集性能延时数据)。开发人员就能更快得到反馈,避免把缺陷引入代码库。
- 持续构建:把测试服务器同步成最新的代码并持续执行相关测试,发现并阻止回归问题。这使团队可以把用于检测回归问题的时间,从几天或几星期缩减到小时或分钟级别。
- 产品性能延迟检测:用于定位特定代码变更导致的产品性能延迟回归问题。我们对变化范围进行切分,在多个检查点分段运行测试。
这个方法在我们的产品发布前帮助定位了很多关键缺陷,并推动了测试前移,因为开发人员自己就可以非常容易地启动这些测试。