对于那些正在认真寻求如何测试或者进一步改善测试效果的团队和组织来说，可以研究下业界大佬是如何组织测试和质保活动的，肯定能学到不少东西。显而易见的是，诸如谷歌、微软和亚马逊这样的公司，如果不是对产品质量给予了恰当的关注，不可能像现在这样成功。

　　但是对这些软件巨头们的研究表明，成功并没有放之四海而皆准的秘诀。我们可以一起来学习一下世界上最著名的五家公司是如何组织他们的质量保证工作的。

　　谷歌- 寻找最佳实践

　　谷歌，这个世界上最大的搜索引擎公司，是如何组织测试工作的呢？这要视产品和团队而定。举个例子，负责搜索引擎的团队，维护了一个庞大又严谨的测试框架。因为搜索是谷歌的核心业务，团队想要保证持续地、高质量的交付，不希望因为测试工作不到位而把产品搞砸。

　　为了达到这个目的，谷歌采用了一个四段式测试流程来处理搜索引擎的改动，包括：

　　1、由专职的、内部测试人员（谷歌员工）进行测试；

　　2、在众测平台上进行进一步的测试；

　　3、自我试用阶段，即由谷歌的员工在日常工作中来使用产品

　　4、Beta测试，即把产品释放给一小部分终端客户来使用。

　　尽管这看起来已经是一个非常完善的测试流程，但是谷歌前工程总监詹姆斯·惠特克在一段视频中仍然解释说，这里面还有可以改善的空间，这是因为负责不同阶段测试的人员之间的沟通还没达到理想状态（可能导致部分功能被多次测试或者漏测）。

　　但是，那些负责非核心产品的团队采用的测试流程则没有那么严格。在某些情况下，根本没有专职的测试人员来为产品构建安全网，个别产品的测试工作完全由开发人员来完成。

　　无论哪种情况，谷歌都很认真地对待测试工作。事实上，在谷歌，测试人员和开发人员的薪水是持平的，这种现象在其他公司并不常见。

　　更多的关于谷歌测试的细节信息可以参考谷歌测试博客-Google Testing Blog。

　　Facebook：开发驱动测试

　　Facebook根本不雇佣任何专职的测试人员。这个社交媒体巨头依赖他们的开发人员去测试自己的代码（或者做交互测试）。过去，这些测试工作都是手工完成的。现如今，Facebook已经实施了各种自动化的测试方案。他们使用各种各样的测试工具，从做后台单元测试的PHPUnit，到Jest-一款由Facebook内部开发的JavaScript测试工具，再到做端到端测试的Watir。

　　与谷歌相似，Facebook也用内部测试来保障软件的可用性。并且，Facebook有一个堪称臭名昭彰的做法：把搞砸事情的开发者当作罪犯，给他戴上小丑的鼻子，拍照，发到内部的Facebook讨论组。

　　Facebook已经意识到了他们的测试流程有明显的缺陷，但是与其花很长的时间去改善，他们选择接受这些缺陷，这印证了他们说的话-社交媒体并非刚需。此外，减少对测试的关注意味着可以释放更多的资源专注去做更有价值的工作。

　　相比反复测试软件，Facebook倾向于使用一种被称为·金丝雀·的发布方式。即使用增量部署的策略在生产环境上测试补丁、更新或者新功能。比如，一个新功能在最开始的时候只对一小部分用户开放。

　　通过跟踪新功能的使用情况和反馈，公司会决定是继续扩大试用范围还是禁止这个新功能，是进一步改进还是直接放弃。

　　亚马逊：部署先行

　　与脸书相似的是，亚马逊也没有大量的专职测试人员。甚至曾有人暗示，亚马逊的测试职位微不足道。亚马逊的测试人员与开发人员的比例是1:7，这也说明了在亚马逊，测试并不是一项重要的工作。

　　然而，亚马逊公司本身并不这么认为。对亚马逊来说，测试与开发人员的比例只是一个输出变量，并非输入变量。换句话说，一旦公司意识到收入下降或者因为网站异常而导致客户流失，公司就会追加测试的投入。

　　亚马逊给人的感觉是它的开发和部署流程相当成熟（公司因每11.6秒发布一个新版本而闻名），以至于并不需要大量的、详尽的测试。它所做的，是尽可能地把产品部署和出错回滚变的简单。这样，即使发现任何错误，可以很容易将产品回滚到一个没有问题的版本。

　　Spotify: 分队，部落和分部

　　Spotify雇佣专职的测试人员，他们隶属于一些跨职能的团队，每个团队都有自己的明确使命。在Spotify，员工是按照已经小有名声的Spotify模型来组织的。Spotify模型包括以下部分：

• 分队：一个分队基本上就是一个Scrum团队，分队注重原则胜过注重实践。Spotify有一句名言是这样的·规则是良好的开端，但是该破则破·。一些分队可能有多个测试人员，而另外一些分队则可能一个测试人员也没有，这完全取决于分队的使命。

• 部落：隶属于同一个业务领域的一组分队的集合。属于某个分队的测试人员自然就从属于相应的部落。

• 分部：为了促进员工相互之间的学习和经验分享，Spotify用分部把分散在不同分队和部落的、具有相同技能的员工组织到一起。

　　Spotify非常认真地对待测试工作。就像编程一样，Spotify认为测试过程是富有创造性的，有些事情不能（或者不能全部）自动化。与本文中提到的其它公司相反的是，Spotify非常依赖它的测试人员去考察和评估其产品，而不是试图把测试工作尽可能地自动化。

　　未来，Spotify的测试会是怎样的呢？Spotiy的测试经理，同时也是基于模型的自动化测试工具GraphWalker的创始人克里斯蒂安·卡尔说：

　　“未来，我们花在测试上的时间会和今天一样多。但是，自动化测试工具以及自动化测试中获得的信息将会使我们的测试工作变的不同”。

　　最后，一个事实是：为了最小化运转设备和维护测试环境的成本及消耗，Spotify的大量测试都是在生产环境上进行的。

　　微软：测试者就是工程师

　　微软当前的测试和开发人员的比例大致是2:3，与谷歌一样，微软付给测试人员的薪水与开发是持平的-除此之外，他们也并不被叫做测试人员，而是被称为：测试领域的软件开发工程师（或简称为SDETs）。

　　微软的测试人员比例如此之高，是因为微软的大量收益来自于那些交付给客户并安装在客户电脑上的产品，而不是网站或者线上服务。不管是因为缺陷还是新功能，更新这类产品都很困难（至少是非常令人讨厌的）。因此，微软投入了大量的时间，人力和财力去保证高质量地交付产品。

　　从IT巨头身上我们能学到什么

　　既然世界上最著名的五家科技公司在测试的文化、视角和流程上可以如此不同，这就说明了关于测试并没有所谓的唯一正确的道路。这五家公司分别制定了他们自己的测试流程，选择了最适合他们的方法。而且五家公司都非常成功，他们一定是采取了适合自己的正确方法，不是吗？

　　然而，我们还是可以从上述故事中学习到一些道理，从而应用到我们自己的测试策略中.

• 从由专职测试人员为测试工作负责到人人都为测试活动负责，测试的责任范围其实是一个连续谱，在这个区间中选择哪个模式要视团队的技能而定。

• 测试重要性的范畴也是一个连续谱，从未经测试的内容决不上生产环境到我们把所有内容直接放在生产环境上，如果有问题，直接在那里测。你的团队在这个区间的哪个位置，取决于失败带来的风险以及问题发生后回滚版本和解决问题的难易程度。

• 自动化测试在上述五家公司中都有很重要的位置。虽然自动化实现的程度不尽相同，但是五家公司都使用工具来优化他们的测试工作，你或许也应该借鉴这个经验。

　　最后，针对测试活动（或称学校，这篇文章的作者是这样称呼它们的）的连续谱理论，这里还有另一种考虑，该文章的作者是微软前首席工程师阿兰·佩奇。

作者：zjyforuok   

来源：51Testing软件测试网原创