软件测试对比擂台赛：亚马逊 VS 微软
在2005年，我作为软件开发测试工程师加入到亚马逊之前，在面试时得知：测试正处于改进提升之中。你或许会问：之前是怎样的？好吧，答案是，测试一直被冷遇：1对10（1对7，或0对无穷多）的测试开发比，证明了这点。
测试开发比
“正在提高，恩？”我应该同意么？未必，但是我快速地意识到：我之前曾经常使用亚马逊网站，并且几乎没有意识到有任何问题……看起来网站运行非常正常。即使这样，在加入亚马逊的测试团队后，我经常听到一些抱怨：整个亚马逊公司并不重视质量保证，否则它们应该为测试团队投入更多经费。不久，我向之前职过的游戏卡公司的主管抱怨这点，期望从他那里获取同情。相反地，他简单地问了一句：对亚马逊公司来说，这决策正确么？灵光一现之间，加上之前的多年经验，我意识到测试开发比并不重要，关键是你期望从开发、测试、产品专家、管理者那里得到什么，并且如何控制和降低风险。
跨越华盛顿湖[1]
2009年，我从亚马逊的西雅图总部横跨华盛顿湖，加入了微软。微软尊重测试，且认为软件质量高于一切。这在业界非常有名。我渴望看到“微软式”的质量保证——传说中的1比1测试开发比例。后来发现，那只是 office 和windows 团队的测试方式，在一些功能并没有windows和office那么多的产品中，在如何测试方面会使用一些新方法来实现，在质量流程方面也会做很多的尝试。然而，在如何保证软件质量方面，我认为亚马逊与微软仍有根本的不同。
亚马逊vs微软：一对一
在微软，我管理着一个测试开发比在1～1.5之间的测试团队。在亚马逊，一个测试对7个甚至更多的开发。这么说来，我的在微软的新工作一定会更容易么？当然不。测试开发比并不是等式的一个输入，而一个输出。你设定质量期望，并且制定流程来达到这个期望。但是，微软有10个测试而亚马逊只有一个，为什么？为了寻找答案，我们做了下面的对比：
和微软相对，亚马逊只用几个小时来做测试，他们是怎么做到的？
1、在亚马逊公司，并非所有的功能、服务、代码路径都会被测试到。原因是，它们必须精心安排、使用测试稀缺资源。但在微软，除了原型或“车库”项目之外的所有项目，都可以在每一阶段中，都经过完整的开发-测试-产品“三权对立”的团队管理模式。
不测试的代码降低了对测试人员的需求。相比较测试开发比例，或许，软件开发测试工程师们与被测代码的行数之比更有趣。如果排除亚马逊未经过测试的功能模块，它的测试开发时间比非常接近微软的水平。
2、亚马逊有“质量保证”团队，而微软拥有”测试“团队。然而，在亚马逊，质量保证除了测试外不参与任务其它事情。也是说，微软和亚马逊应该互换各自质量保证团队的名称，因为亚马逊是更倾向于只“测试”的团队，而在微软，我们似乎更接近实际意义上的质量保证。以不参加设计或可测性设计的评审来节约时间，实际上却是一点也没有节约时间。
3、在亚马逊，只做功能测试是非常普遍的，然而，性能测试也并非不做，或者由开发执行，或者优先级次之。
性能测试经常由开发团队来做，因此这些测试时间确实是有，只是不占用测试团队的时间而已。
4、使用了一个较高运营成本的方法（开发随时携带一个寻呼机），一旦在线上发现一个bug也是可以接受的，因为这个bug可以较快地被修复。对于发布，其对质量的要求并不高。亚马逊也有较好的工具和流程来编译和布署，这点能确保一些热点修复能非常快速地上线。
实质是线上测试的形式，而且，统计时间并把这些时间放到开发名下。
5、更好的自我服务分析工具。好工具能更易分析和快速确定产品中的任何争议，这些工具监控服务器和服务，并发出报警。
通过自动化（和工具）来降低消耗……这才是真正的节约。
6、廉价的人工测试。在列出这点时，我感觉很复杂，因为我曾经花费了大量精力来鼓励这些手动测试者们自动化，但是亚马逊公司在用户使用产品前，聘用了海外团队，仅通过产品的黑盒界面来点击它们，并发现了一些问题。
隐藏测试时间。当人们谈论亚马逊公司的测试开发比时，他们并没有将这些海外团队纳入在内。
期望
我的一个朋友在亚马逊公司是质量保证团队的管理者之一，他近感叹道：
测试开发比被过份强调……我们原本要去做很多的事情来保证质量，但为了追赶进度不得不放弃很多测试，而遗漏了bug的时候又会得到埋怨。
因此，或许我的“亚马逊与微软：一对一”比较没有完全列出亚马逊和微软的差异，但是，我想说的是测试开发比并不重要。我初写下上面几点是为了回答一个开发管理者的问题：为什么我们不能像亚马逊在质量保障方面消耗更少？对于质量期望和风险承受力，亚马逊是一个标准，而微软是另一个标准——这是原因。
不足
我已经对亚马逊和微软的测试方法做了大量归纳总结，也意味着这不能完全被其它团队照搬应用。若有不同意见，请在评论时畅所欲言。但是请牢记，这些归纳总结并非放之四海而皆准。并且，我希望大家能了解到：测试开发比并不重要。
正在提高？
除了测试开发比外，亚马逊确实提高了。我知道质量保证团队团结起来并积极沟通。亚马逊公司里第一个工程杰出论坛也是由它们组织的。因此，终问题是：亚马逊的测试开发比需要提高么？提高后，是什么样子？微软需要改变么？改变后，是什么样子？
评论一：
Seth，这是一篇非常好的文章，为了解亚马逊和微软不同的测试方法，得先了解修复bug的代价，这是基本的。
我想说，亚马逊没有投入更多测试的重要原因，是“呼叫文化”。亚马逊的开发们知道，他们的寻呼机也许会在半夜报警，他们因此不得不排查问题并发布修复。虽然这也是代价，但仍然不能与微软的为盒装软件产品发布补丁的代价相比，
盒装软件的问题修复，代价是非常巨大的。它意味着要把更新推送到所有正在运行软件的客户端。这是为什么微软在windows操作系统上的测试耗费巨大。即使这样，windows仍每月向我的电脑发送大量的热点修复。当考虑到世界上有多少台电脑正在运行windows操作系统时，每一个修复都耗费了微软公司大量的财力，这是显而易见的。因此，聘用多少测试人员取决于使公司消耗小的商业决策。
而“服务性软件”，替代了将软件安装到每一个客户的电脑上，大部分软件都能由你控制。修复一个bug，只要简单地修补服务后完成了。这样的消耗要比向每一个客户端发送更新少多了。终结果是：亚马逊文化与微软文化相比，更能容忍bug。（Rob）
评论二：
Hi Seth，
我认为，仍有其它重要因素决定投资测试的优方案。
你们之前讨论过：修复bug是多么简单，并且修复这些bug因其在产品类型方面不同而不同。
另一个非常重要的问题是：检测到bug有多容易？如果一个bug引起服务当机，这个是非常容易由监控系统监测和报告。如果bug从一个银行帐户中错减了金额，你能在发布前检测出么，或者能写出专门的测试用例来发现类似的bug么？
另一可变因素，是当这些bug出现时，系统行为如何。当用户刷新页面时，页面不能正常展现的bug与将数据库破坏掉的bug相比，前者相对更能被容忍。
如果一个系统从开始能够容易某些类型的失效或bugs，那么为使系统达到需求，这点将深刻影响终测试预算。（Ralph Case）
-----------------------------------------------------------------------------------------------------------
[1] 亚马逊总部与微软间相隔华盛湖，作者借此指将工作从亚马逊转到微软。
