• 0
  • 0
分享
  • 科技巨头们的测试之道—质量保证,法无定法
  • 恬恬圈 2019-10-24 13:26:37 字数 3092 阅读 1851 收藏 0

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

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

谷歌- 寻找最佳实践

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

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

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巨头身上我们能学到什么

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

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

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

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

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

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


版权声明:本文出自《51测试天地》原创测试文章系列(四十八)投稿。51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 1、AOP相关术语Joinpoint(连接点):所谓连接点是指那些被拦截到的点。在 spring 中,这些点指的是方法,因为 spring 只支持方法类型的连接点。(业务层接口中所有的方法)Pointcut(切入点):所谓切入点是指我们要对哪些 Joinpoint 进行拦截的定义(被增强的方法)所有的切入点都是连接点。Advice(通知/增强):所谓通知是指拦截到 Joinpoint 之后所要做的事情就是通知,通知的类型:前置通知,后置通知,异常通知,最终通知,环绕通知。Introduction(引介):引介是一种特殊的通知在不修改类代码的前提下, Introduction 可以在运行期为类动...
            0 0 1294
            分享
          • 1、引言在上一章, 我封装了http_service,  如果你不知道的话, 直接点击《Python3,接口自动化框架之封装http_service》跳转去看。 当然,也有小伙伴私下跟我说, 没想到, http_service的封装, 会这么简单。其实... 确实... 不难...今天,我们继续来封装接口自动化框架。在封装之前, 我们先想一个问题:你喜欢使用脚本来维护测试用例, 还是喜欢用excel来维护测试用例?如果你的接口参数经常改变, 使用脚本来维护,必然不是一个最高效的方式, 这个时候, excel的维护方式,就排上用场了。 让代码直接读取exc...
            1 0 1538
            分享
          •   一、关于面向系统测试(System Testing)的理解  面向系统测试(System Testing)是一种独特的测试方法论,其核心视角聚焦于系统本身,将被测系统视为一个不可分割的整体。这种测试方法强调从系统的宏观角度出发,全面考察其各项功能和性能,以确保系统作为一个整体能够稳定、高效地运行。在面向系统测试中,我们不再将系统拆分成单独的模块或组件进行逐一测试,而是将其视为一个完整的、有机的整体。这种测试方法有助于我们更全面地理解系统的结构和行为,从而发现那些可能在模块测试中难以察觉的问题和缺陷。  二、软件测试日常遇到的问题  在许多项目中,我们常常发现测试人员缺乏一个整体的测试概念。...
            0 0 378
            分享
          • 前言这段时间收到好多粉丝的留言说想求一份金融银行相关的测试面试题,所以我花了不少时间给大家整理了一份,今天分享给需要的朋友们,也希望对你们有所帮助。1、网上银行转账是怎么测的,设计一下测试用例。回答思路:宏观上可以从质量模型(万能公式)来考虑,重点需要测试转账的功能、性能与安全性。设计测试用例可以使用场景法为主,先列出转账的基本流和备选流。然后设计场景,最后根据场景设计数据。实际面试中需要举出具体的例子。先检查界面。再测试功能:验证同行转账,跨行转账。验证转账限额。验证非法账户(挂失,冻结,锁定的账户)的转账。再测试性能方面的。2、测试工作的流程?缺陷状态有什么?设计测试用例有几种方法?测试工...
            0 0 3091
            分享
          •   需求分析是开始测试工作的第一步,产品会先产出一个需求文档,然后会组织需求宣讲,在需求宣讲中分析需求中是否存在问题,然后宣讲结束后,通过需求文档分析测试点并且预估排期。所以对于需求的理解非常重要。  需求文档  产品经理在做完用户需求调查之后,会根据用户需求输出一份需求文档,在文档中会详细描述用户所需的功能和功能实现的效果。文档生成之后,产品经理会和开发测试一起开一个需求宣讲会,讲解需求中的内容,并且会对需求中可能存在的问题进行讨论。  需求评审  在需求宣讲的过程中,其实也需要对需求本身进行评审。需求评审可以从以下角度去进行考虑。  1.站在使用者的角度,考虑用户会遇到的各种情况,反观各种...
            0 0 849
            分享
      • 51testing软件测试圈微信