《Google软件测试之道》—第2章2.4节与工具开发工程师Ted Mao的访谈

本节书摘来自异步社区《Google软件测试之道》一书中的第2章2.4节与工具开发工程师Ted Mao的访谈，作者【美】James Whittaker , Jason Arbon , Jeff Carollo，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.4　与工具开发工程师Ted Mao的访谈
Ted Mao是一位Google的开发工程师，但Ted的主要工作专注于测试工具的开发方面。特别要提到的是，Ted制作的Web应用程序方面的测试工具，所有的Google内部应用上都在使用。Ted本身在SET这个圈子里也很有名气，一般情况下SET都对优秀工具有需求，否则效率就会非常低下。Ted可能是Google内部对通用Web测试基础框架最熟悉的人员。

HGTS：你是什么时候加入Google的？是什么吸引你来这里工作的？

Ted：我是2004年6月加入Google的。在那之前，我只在一些大公司里待过，像IBM和Microsoft，那个时候Google是最热门的创业型公司，吸引了大量非常有天赋的工程师加入。Google尝试去解决许多有趣且有挑战性的问题，我想参与进来，与这个世界上最优秀的工程师们一起去解决这些问题。

HGTS：你是Google缺陷管理库Buganizer（注：Buganizer是Google内部使用的缺陷管理系统，开源版本的Buganizer被称为问题跟踪工具，在Chromium项目中有使用，参见http://code.google.com/chromium/issues/list）的创建者。与之前的BugDB相比，Buganizer尝试去解决了哪些核心问题呢？

Ted：BugDB当时是在阻碍我们的开发流程的运转，而不是为之提供支持帮助。老实说，它浪费了许多宝贵的工程开发时间，这使得使用这个工具的团队负担更加沉重。它的问题表现在许多方面，像UI延迟、笨拙的工作流模式、在非结构化的文本字段中使用特殊字符串等。在设计Buganizer的时候，我们确保我们的数据模型和UI可以反应出用户的真实开发过程。在核心产品团队与集成过程中，这个系统通过使用扩展的模式，经受住了考验。

HGTS：你在Buganizer上做的非常出色。这真是我们用过最好的缺陷管理数据库了。你又怎么开始去搞Web自动化方面的测试呢？是你看到这方面有强烈的需求吗？还是有人请求你去帮助解决这方面的问题呢？

Ted：在为Buganizer、AdWords和其他Google产品工作期间，我经常发现已有的Web自动化测试工具不能满足我的实际需求，他们并不像我期望的那样快速、扩展性强、健壮且有用。当工具团队宣布去寻找这个领域的技术人才时，我抓住了这个机会。这方面的尝试就是我们知道的Matrix项目，而我是这个项目的技术负责人。

HGTS：如今有多少个测试团队在使用Matrix做测试执行？

Ted：这个取决于你如何度量测试的执行。例如，我们在使用的一个指标，我们称为“浏览器会话”。针对所有浏览器，每一次新的浏览器会话都会保证从同样的状态开始运行。这样的话，在这个浏览器上运行的测试只由测试本身、浏览器和操作系统来决定，其行为也就是可以确定的。Matrix在Google的每个Web前端团队都有实践应用，每天提供大于一百万个新浏览器会话。

HGTS：Buganizer和Matrix这两个项目，曾有多少人为之工作？

Ted：在项目开发高峰时期，Buganizer有5个工程师，Matrix有4个工程师。当时我们的团队本可以拥有更多的人，让团队存活地更长久一些。虽然这令我有些伤感，但我觉得在当时的情况下我们已经做的足够棒了。

HGTS：在你打造这些工具的时候，你面临过的最难的技术挑战是什么？

Ted：对于我而言，我认为最艰难和最有趣的挑战总是出现在设计阶段。理解一个问题领域，权衡不同的解决方案和它们的利弊，并从中选一个最优的方案。实现阶段一般按照选定的方案去做即可。这样的选择决定和功能实现一样会贯穿项目的整个生命周期，决定项目的成败。

HGTS：对于世界上其他专注于测试工具方面的工程师，你有什么一般性的建议吗？

Ted：专注于你的用户，理解他们的需求并解决他们的问题。不要忽视一些看不见的功能，如可用性和响应速度。工程师在解决他们问题方面有自己独特的能力，要允许他们使用你无法预料的方式来使用你的工具。

HGTS：在测试工具框架领域，下一个最大的问题，或者是你最感兴趣的且最想去解决的问题是什么？

Ted：有一个问题我最近一直在思索，我们的工具变的越来越强大和复杂，但相应地，在理解和使用这些工具上也变得越来越困难。例如，使用Google当前的Web测试框架，工程师可以一键运行上千个Web测试，并发地运行，针对不同的浏览器。我们抽象封装了如何运行的细节，例如这些测试是在哪里开始真正运行的，浏览器是从哪里得到的，测试环境是如何配置的等细节。从某方面上讲，这是好事儿。但是，如果测试运行失败之后，工程师又必须去做调试，这些隐藏的细节就必须要去了解。我们已经在这个领域有所举措，但仍然有很多可以去做且必须去完成的事情，它们在等待着我们去解决。