Google 软件测试之道 (1)

Posted on Wed, 25 Dec 2024 10:37:19 +0800 by LiangMingJian

质量不等于测试 #

Google是一家以创新和速度为基础的公司，快速地发布代码，迭代地增加功能，这是Google常做的。在这样的环境下，测试不得不变的异常灵活，并且在技能上要做许多前期的规划，仅仅只是简单维护并不能真正解决问题。有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离，甚至开发人员都不知道测试在做些什么。

在Google，写代码的开发人员也承担了质量的重任。质量从来就不仅仅是一些测试的问题。在Google，每个写代码的开发者本身就是测试者，质量在名义上也由这样的开发测试组合共同承担。在Google，谈论开发测试比（译注：这里指在人员数量上，开发和测试的比率）就像讨论太阳表面的空气质量一样，这本身没有任何意义。如果你是一名工程师，那么你同时也是一名测试人员。如果在你的职位头衔上有测试的字样，你的任务就是怎样使那些头衔上没有测试的人可以更好地去做测试。

质量不是被测试出来的——这句看似陈词滥调的话却包含着一定的道理。从汽车行业到软件行业，如果在最开始设计创建的时候就是错的，那它永远不会变成正确的。试问一下汽车行业的公司，大量召回事实上有质量问题的产品，代价是多么的昂贵。因此，从最初的创建阶段就要做正确，否则将会陷入混乱的万劫深渊。然而，这句话也并不像听起来那样的简单和准确。虽然质量不是被测出来的，但同样有证据可以表明，未经测试也不可能开发出有质量的软件。如果连测试都没有做，如何保证你的软件具有很高的质量呢？

有一个简单的办法可以解决这个难题，那就是停止开发与测试的隔离对立。开发和测试应该并肩齐趋。你的每一段代码写完后都要立刻测试这段代码，当完成了更多的代码时就做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分。质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。

在Google，这正是我们的目标，就是把开发过程和测试融合在一起——开发和测试必须同时开展。写一段代码就立刻测试这段代码，完成更多的代码就做更多的测试，但这里的关键是由谁来做这些测试呢？众所周知，在Google，专职测试人员的数量非常稀少，与开发相比根本不成比例，唯一可能的去做这些的就只能是开发人员。还有谁能比实际写代码的人更适合做测试呢？还有谁能比实际写代码的人更适合去寻找bug呢？是谁会为了避免受更大刺激而去想办法避免产生bug呢？Google能用如此少的专职测试人员的原因，就是开发对质量的负责。如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个bug的测试人员。

这意味着质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。我们已经成功地将测试实践融入为开发过程的一部分，并创建了一个增量上线的流程。如果一些项目在线上被证实的确是bug重重，它将会被回滚到之前的版本。在确保不出现回滚级别bug发生的前提下，预防了许多客户问题的同时，也很大程度降低了专职测试人员的数量。在Google，测试的目标就是来判断这种预防工作做的怎么样。

软件开发工程师（SWE） #

软件开发工程师（译注：software engineer，后文简称SWE）是一个传统上的开发角色，他们的工作是实现最终用户使用的功能代码。他们创建设计文档、选择最优的数据结构和整体架构，并且花费大量时间在代码实现与代码审查上。SWE需要编写与测试代码，包括测试驱动的设计、单元测试、参与构建各种规模的测试等，这些测试会在本章的后面做详细解释。SWE会对他们编写、修复以及修改的代码承担质量责任。如果一个开发者不得不修改一个函数，或者这次修改导致已有测试用例运行失败，或者需要增加一个新的测试用例，他就必须去实现这个测试用例的代码。开发工程师几乎将所有的时间都花费在了代码编写上。

软件测试开发工程师（SET） #

软件测试开发工程师（译注：software engineer in test，后文简称SET）也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。他们参与设计评审，非常近距离地观察代码质量与风险。为了增加可测试性，他们甚至会对代码进行重构，并编写单元测试框架和自动化测试框架。SET是SWE在代码库上的合作伙伴，相比较SWE是在增加功能性代码或是提高性能的代码，SET更加关注于质量提升和测试覆盖率的增加。SET同样会花费近百分之百的时间在编写代码上，他们这样做的目的是为质量服务，而SWE则更关注在客户使用功能开发的实现上。

测试工程师（TE） #

测试工程师（译注：test engineer，后文简称TE）是一个和SET关系密切的角色，有自己不同的关注点–把用户放在第一位来思考，代表用户的利益。一些Google的TE会花费大量时间在模拟用户的使用场景和自动化脚本或代码上。同时，他们会把开发工程师和SET编写的测试分门别类地组织起来，分析、解释、测试运行结果，驱动测试执行，特别是在项目的最后阶段，推进产品发布。TE是真正的产品专家、质量顾问和风险分析师。某些TE需要编写大量的代码，而另外一些TE则只用编写少量的代码。

组织架构 #

在多数组织中，开发人员和测试人员都一起隶属于同一个工程产品团队。从组织架构上讲，开发人员和测试人员汇报给同一个产品团队的管理者。这样看起来，同一个产品、同一个团队、所有参与的人都在一起，应该可以做到平等相处、患难与共。但不幸的是，我还从来没见过有团队能真正做到这样。资深管理者一般都是产品经理或开发经理，而不是来自于测试团队。在产品发布时，优先考虑的是功能是否完整和易用性方面是否足够简单，却很少考虑质量问题。作为同一个团队，测试总是在为开发让路。为何我们这个行业里总是充斥着各种有缺陷的、早产的产品，或许这就是问题所在。不行就再发布一个补丁包。

Google的组织汇报架构被划分为不同的专注领域（Focus Areas）。这些专注领域包括客户端（Chrome、Google工具栏等）、地理（地图、Google Earth等）、广告、Apps、移动，等等。所有的开发工程师汇报给这些专注领域的管理者、总监或副总裁。

但SET和TE并没有遵循这个模式。测试是独立存在的部门，是与专注领域部门平行的部门（横跨各个产品专注领域），我们称之为工程生产力团队。测试人员基本上以租借的方式进入到产品团队，去做提高质量相关的事情，寻找一些测试不足的地方，或者公开一些不可接受的缺陷率数据。由于测试人员并不是直接向产品团队进行汇报，因此我们并不是简单地被告之某个项目急需发布就可以通过测试。我们有自己选择决定的优先级，在可靠性、安全性等问题上都不会妥协，除非碰到更重要的事情。如果开发团队想要我们在测试上放他们一马，他们必须事先和我们协商，但一般情况下都会被拒绝。

这样的组织结构也可以帮助我们保持数量较少的测试人员。一个产品团队不能任意降低测试人员招聘的技术要求，从而雇佣更多的测试人员，然后再让他们做一些简单和琐碎的脏活累活。这些功能相关的脏活累活本应是开发人员的工作，不能简单地扔给倒霉的测试人员。工程生产力团队会根据不同产品团队的优先级、复杂度和其他产品的实际比较后，再来分配测试人员。显然，有时候我们可能搞错，实际上也确实出过错，但总体上来说，这样会保持实际的需求与不明确的需求之间的某种平衡。

这种测试人员在不同项目之间的借调模式，可以让SET和TE时刻保持新鲜感并且总是很忙碌，另外还能保证一个好的测试想法可以快速在公司内部蔓延。一个在Geo产品上运用很好的测试技术或工具，很有可能在Chrome产品中也得到使用。推广测试技术方面创新的最佳方式，莫过于把这个创新的发明者直接借调过来。

在Google有一个广泛被接受的做法：对于一个测试人员，如果在某个产品中工作满18个月之后，就可以无理由地自愿转岗到其他产品，当然这个转岗并不是强制的。可以想象一个产品失去优秀测试专家而带来的悲痛，但从整个公司的角度来看，需要保持对各个产品与技术都了解的测试人员的存在。Google的测试工程师在客户端、web、浏览器、移动技术等领域都有所涉猎，可以高效地使用不同的语言和平台。由于Google的产品和服务很大程度上有比较强的集成关联关系，测试人员可以很容易地保持相关的专业技能，并在公司范围内的产品之间自由穿梭。