期望

　　我的一个朋友在亚马逊公司是质量保证团队的管理者之一，他最近感叹道：

　　测试开发比被过份强调……我们原本要去做很多的事情来保证质量，但为了追赶进度不得不放弃很多测试，而遗漏了bug的时候又会得到埋怨。

　　因此，或许我的“亚马逊与微软：一对一”比较没有完全列出亚马逊和微软的差异，但是，我想说的是测试开发比并不重要。我最初写下上面几点是为了回答一个开发管理者的问题：为什么我们不能像亚马逊在质量保障方面消耗更少？对于质量期望和风险承受力，亚马逊是一个标准，而微软是另一个标准——这就是原因。

　　不足

　　我已经对亚马逊和微软的测试方法做了大量归纳总结，也就意味着这不能完全被其它团队照搬应用。若有不同意见，请在评论时畅所欲言。但是请牢记，这些归纳总结并非放之四海而皆准。并且，我希望大家能了解到：测试开发比并不重要。

　　正在提高？

　　除了测试开发比外，亚马逊确实提高了。我知道质量保证团队团结起来并积极沟通。亚马逊公司里第一个工程杰出论坛也是由它们组织的。因此，最终问题是：亚马逊的测试开发比需要提高么？提高后，是什么样子？微软需要改变么？改变后，是什么样子？

　　评论一：

　　Seth，这是一篇非常好的文章，为了解亚马逊和微软不同的测试方法，得先了解修复bug的代价，这是基本的。

　　我想说，亚马逊没有投入更多测试的重要原因，是“呼叫文化”。亚马逊的开发们知道，他们的寻呼机也许会在半夜就报警，他们因此不得不排查问题并发布修复。虽然这也是代价，但仍然不能与微软著名的为盒装软件产品发布补丁的代价相比，

　　盒装软件的问题修复，代价是非常巨大的。它意味着要把更新推送到所有正在运行软件的客户端。这就是为什么微软在windows操作系统上的测试耗费巨大。即使这样，windows仍每月向我的电脑发送大量的热点修复。当考虑到世界上有多少台电脑正在运行windows操作系统时，每一个修复都耗费了微软公司大量的财力，这是显而易见的。因此，聘用多少测试人员取决于使公司消耗最小的商业决策。

　　而“服务性软件”，替代了将软件安装到每一个客户的电脑上，大部分软件都能由你控制。修复一个bug，只要简单地修补服务后就完成了。这样的消耗要比向每一个客户端发送更新少多了。最终结果就是：亚马逊文化与微软文化相比，更能容忍bug。（Rob）

　　评论二：

　　Hi Seth，

　　我认为，仍有其它重要因素决定投资测试的最优方案。

　　你们之前讨论过：修复bug是多么简单，并且修复这些bug因其在产品类型方面不同而不同。

　　另一个非常重要的问题是：检测到bug有多容易？如果一个bug引起服务当机，这个是非常容易由监控系统监测和报告。如果bug从一个银行帐户中错减了金额，你能在发布前检测出么，或者能写出专门的测试用例来发现类似的bug么？

　　另一可变因素，是当这些bug出现时，系统行为如何。当用户刷新页面时，页面不能正常展现的bug与将数据库破坏掉的bug相比，前者相对更能被容忍。

　　如果一个系统从开始就能够容易某些类型的失效或bugs，那么为使系统达到需求，这点将深刻影响最终测试预算。（Ralph Case）

　　-----------------------------------------------------------------------------------------------------------

　　[1] 亚马逊总部与微软间相隔华盛湖，作者借此指将工作从亚马逊转到微软。