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

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

谷歌测试

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

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

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

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

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

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

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

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

[英文原文:How Google Tests Software - Part Three ]
分享这篇文章:

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

  1. casilin says:

    我觉得,如果每次开发写一点代码测试人员就测一点是很难实现的,没有哪一个开发愿意在自己整个写代码的过程中都让测试人员介入其中,现在很多的都是开发人员写好了,测试人员再去测。如果让开发人员同时担当测试的责任的话,那么他就会知道自己怎样写会有问题,怎样写更好,会写出更好质量的代码,这样就从开发流程的一开始将错误遏止住,提高了开发人员的素质,降低了开发成本。不过我觉得很多开发还是不愿意去测试自己的代码,也很难从自己一开始的代码逻辑中跳出来看这部分代码是否有问题,如果他觉得这么设计是合理的,那他就很难看到不合理的部分,让开发人员担当测试的责任还需要很大的努力啊~

  2. 傲世狂少 says:

    开发人员测试主要是系统本身的质量,便于改进,而大多专职测试人员测试出结果,融合的确是不错的。。。

  3. Sweet says:

    总的来说,两者还是需要结合的,让开发人员自己进行测试,在一定程度上可以避免逻辑上的错误,而让专业的测试人员去测试业务上的错误。两者结合以后,可以有效提高双方的工作效率与工作质量,从而提高软件质量。

    • huangdetian says:

      楼上说的对,其实很多大公司里,开发人员一般是做单元测试和模块测试。而对系统级的业务和性能测试,是测试人员来做。

  4. Chen1990 says:

    这么说就不怎么需要专门的软件测试人员了?.我才刚学啊。。。

  5. 时刻不得闲 says:

    确实,这篇文章和我的思路很吻合。
    我觉得软件测试的本质工作就是使用一套测试方法来检测出开发环节中出现了哪些问题。
    开发就能根据检测结果来分析原因,改进开发过程,最终保证软件质量的提高。
    至于由测试人员来保证软件质量,那是几乎不可能的。除非测试人员拥有比开发人员更丰富的开发经验。就算如此,开发进度也会因为测试而被拖慢。

  6. phil says:

    开发做白盒测试,QA 做黑盒测试。

  7. 陈绪 says:

    开发与测试之间的配合,另一方面也需要看开发人员的素质与测试人员的素质。完美的组合早就优秀的团队。

  8. open_source says:

    原来是这样的。

  9. 冯立彬 says:

    任何开发人员都想把自己写的东西写的最好,没有哪个开发人员会愿意看到测试从他们的代码或者结果中找到BUG,如果可以我愿意为每个方法写一个测试用例。
    可是往往遇到的是这种结果:这个东西明天能不能够开发完成!作为开发如何办,除了整理思路写代码,还能够做得更多吗?

  10. 忧郁 says:

    开发人员只能保证他的代码没有明显的实现上的错误,无法保证代码逻辑上没错误

  11. ghost says:

    我一向认为测试是公司派来验货的。

    测试无bug,说明程序员生产的货物质量好;测试bug很多,打回,不合格的产品公司是不会采购的。

  12. tivon says:

    文末那个笑话的翻译是错误滴,这是我朋友的版本
    大巫师:从中文也知道不对吧。应该是:“你知道,老话说小鸡很愿意为一顿咸猪肉+鸡蛋出点力,但是猪付出的可是全部呀!”

  13. leizisdu says:

    是啊,谁能比程序的作者更了解那段程序呢?

  14. anonymous says:

    如果说开发真的能保证质量,那如此多的bug是怎么出来的?大多开发自视甚高,觉得自己能编写出完善的代码。因为对自己的代码熟,才哪儿看哪儿顺眼,结果错误百出还不自知。程序员会的那点编码大家都知道,现在写程序和编书一样,大部分粘粘贴贴就弄好了。写完后运行一下,没报错就觉得没问题。根本没有时间在整个系统内测试和长时间运行,怎么保证质量?

    • anonymous says:

      也不能这么说,国内做开发,很多时候时间都是被压缩了,哪有多少时间去折腾代码的优美和完整?能按时交货就不错了

  15. 欧成 says:

    1:编写一点,测试一点。再编写一点,再测试一点
    2:还有比这些实际开发了这些程序的人员更合适做测试的吗?还有比程序的作者更适合去发现bug的吗?
    对上述两个观点,还是有些疑问,可能不同公司有不同的策略吧,比如第一个,应该是单元测试的测试方法吧,毕竟测试也需要固化版本进行测试,不然——就是个无底洞嘛。第二个也可能会这么说,开发人员十分熟知软件的操作流程,因此由于熟知带来的惯性操作方式,很难发现异常流程出现的问题。所以,软件工程,是门学问,要好好研究,学到不少,谢谢

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据