谷歌如何测试软件 —— 第三部分

本文是从 How Google Tests Software - Part Three 这篇文章翻译而来。 本文作者 James Whittaker, 前微软架构师，是“How to Break Software”系列图书中好几部书的作者，现任Google测试工程主管，最近他写了一系列的关于谷歌如何测试软件的文章，本文为其系列的第三部分。

在前两部分的文章中，很多人在评论里提出了问题。我没有忘记他们。希望大部分的人能在余下的几部分文章里找到答案。我现在还是开始这篇文章的主题。

在Google，质量并不等于测试。我相信在任何一个地方都是如此。“质量不是被测试出来的”这句老话是再正确不过了。从汽车到软件，如果它们起初制造的就有问题，那它们永远都不会没问题。试问任何一个曾经被迫大量召回的汽车公司，掩盖质量问题的代价有多大。

然而，事实情况并不是像这句话那样既简单又精确。虽然质量并不是测试出来的，但我们有同样的证据表明，没有测试，你不可能开发出任何有质量的东西。一个人怎么可能在没有测试的情况下认定你的工程具有高质量？

对于这种难题，最简单的解决办法就是：禁止对开发工作开方便之门，以独立自由之精神进行测试。测试和开发工作需要同步进行。编写一点，测试一点。再编写一点，再测试一点。更好的方法是制定测试计划，或者你开发之前先把计划做好。测试并不是一个独立的工作，它是开发工作的一部分，伴随着整个开发过程。质量不等于测试；为了质量，需要你把开发工作和测试结合到一起，搅拌它们，直到分不清你我为止。

在Google，这是我们明确的目标：把开发和测试融合，你不能单独进行任何一项工作。做一点，测试一点。再做一点，再测试一点。关键就是看谁在做测试。因为在Google，专职测试人员是出奇的少，所以唯一可行的方法就是使用开发人员。还有比这些实际开发了这些程序的人员更合适做测试的吗？还有比程序的作者更适合去发现bug的吗？是谁具有更多的愿望在程序第一次写出时避免bug？Google之所以安排这么少的专职测试人员的原因就是，开发者负责质量。事实上，坚持使用大型测试机构的团队通常会开发出有问题的东西。测试机构庞大，这是一个信号表明编码/测试工作的融和有问题。增加测试人员并不能解决任何问题。

这就是说，质量措施更多的应该是一种预防行为，而不是一种发现过程。质量属于开发问题，而不是测试问题。通过把测试工作一定程度的融合到开发过程中，我们极大的降低了一些本来被认为会写很多有问题的代码的人的出错机会。我们不仅避免了大量的客户方的问题，我们还非常有效的降低了测试人员提出的、其实不是bug的bug。在Google，测试工作的目标就是检查这些预防工作是否在有效的运行。测试工程部一直在寻找这种作为bug创造者的软件工程师和作为bug预防者的测试软件工程师之间的联合能达到的效果的证据，一旦这个方法出现问题，他们就会拉响警笛。

这种开发和测试的结合随处可见，从代码审查注释上写的“你的测试呢？”到厕所里的给开发者的最好的测试实践方法的宣传画——这是我们臭名昭著的厕所测试指导方针。测试是开发工作中是必不可少的，开发和测试的联姻是孕育质量的过程。软工就是测试者，测试软工就是测试者，测试工程师就是测试者。

如果你的企业也有这种类型的结合，请分享出你们成功的经验与挑战。如果没有，那么这是一个给你的企业带来好处的机会：在开发人员和质量之间画上全等号。你们都听过这样一个老故事：小鸡很高兴能为一顿咸猪腿加鸡蛋早餐奉献自己的力量，可猪究竟做错了什么？的确是 … 去对你的开发人员哼哼两声，看能不能得到他们哼哼回应。如果他们发出的是咯咯哒的声音，那说明你们之间存在问题。