《 软件测试价值提升之路》——1.3 谷歌的软件测试

1.3 谷歌的软件测试

谷歌的软件研发特征是:典型的互联网企业,产品完全是自运营,以周或者更短的周期发布版本。有创新型、实验性质的新业务,也有平台性质的搜索引擎。需求的提出并非客户主导。
开发测试比是20∶1。这个数据从很多渠道都可以看到,曾有产品研发经理用这个数据“鞭策”测试经理,说测试应该提升能力。但是测试最应该提升的是能力吗?不是,是定位。
测试职位的名称:SDET(软件开发工程师,测试方向)。在谷歌,这些人的主要职责不是功能测试设计、执行以及自动化实现,而是以下几点:
1)帮助开发更快更好的测试。谷歌有一个“吃自己的狗粮”的文化,自己开发的功能自己测试。专职的测试工程师主要是根据软件的功能和测试内容,设计测试方法,并提供测试工具,典型的例子是谷歌地图的测试工具。测试工程师还负责探索和引入新型的测试思路,帮助更有效地发现缺陷,典型的例子是探索式测试的引入。
2)帮助产品更好地采集使用信息和用户反馈。采集使用信息是对用户操作过程的数据进行性能和易用性分析,目的是帮助分析业务达成目标的瓶颈是什么,比如分析用户放弃操作的比例和原因。更好地采集用户反馈,典型案例是谷歌地图的用户问题报告功能,用户发现地图错误时,用几个非常简单的步骤就可以进行缺陷报告。为什么谷歌的测试会有这个职责?我认为主要因为产品是自运营的,这使得研发需要主动发现产品缺陷,同时产品的发展、新需求的发现需要从产品应用中得到启发。
3)安全性、可靠性、性能等专项测试。这些测试内容非常专业,在谷歌也是由一个集中的专项测试团队进行测试的。
谷歌应该说是一个非常成熟的互联网公司,互联网的业务特征决定了这个组织对一般功能性缺陷不敏感,但是对商业目标是否达成十分敏感,自运营决定了产品的缺陷非常容易更正,文化决定了测试工程师不做功能测试(其实,除了狗粮文化,还有一个组织机制也许更关键,谷歌的研发团队在做完一个产品后,会自由重组,信誉不好的开发者很快就会被组织淘汰)。

时间: 2024-10-29 03:53:45

《 软件测试价值提升之路》——1.3 谷歌的软件测试的相关文章

《 软件测试价值提升之路》——3.3 受攻击出错

3.3 受攻击出错 3.3.1 问题案例 我们的产品中遇到的这类问题并不多见,最典型的就是春节.麦加朝觐时,由于通信需求骤然增大对产品产生的浪涌冲击.我们的产品就是在这样的考验下,由最初的业务请求不断堆积形成拥塞,甚至无法进行维护操作,直至系统完全崩溃:到后来在32倍浪涌冲击下,都能保持业务处理能力.相应的测试方法和工具,也是随着产品可靠性能力的增强同步建设完善的. 众所周知,目前很多互联网产品的安全防护能力是较弱的,有一次一个同事兴奋地和我说,他获得了一项新技能,只用最简单的横向越权手段,就通

《 软件测试价值提升之路》——1.4 微软的软件测试

1.4 微软的软件测试 微软的软件研发特征是:典型的大型传统软件企业,软件完成后完全部署在用户的环境中使用(微软还有必应.Skype.OneDrive等自运营产品,这些不在本节考虑之内),版本发布周期半年甚至更长,产品有非常好的继承性,十分注重在发布前排除软件缺陷.属于领域老大,开发内容不由客户需求主导.开发测试比是1∶2(裁员之前),这个比例在测试领域家喻户晓,也常常成为很多测试经理艳羡微软测试的主要原因.但这个比例真正的含义是,微软的测试工程师一定承担了很大的责任,因为开发测试比完全取决于公

《 软件测试价值提升之路》——1.6 华为的软件测试

1.6 华为的软件测试 华为的软件研发特征是:典型的传统软件企业,软件完成后完全部署在用户的环境中使用,有按月交付的业务版本,也有半年甚至更长时间才交付的基础版本或平台版本,产品有一定的继承性,但架构重构也不是小概率事件(这主要是因为华为还是电信领域的新人,对这个领域的把握还不十分老道),十分注重在发布前排除软件缺陷.属于领域跟随者,开发内容绝大部分由客户需求主导.开发测试比是2∶1-10∶1,2∶1是比较核心的平台部门的比例:10∶1是大量测试外包的业务部门的比例.如果加上外包一起计算,比例大

《 软件测试价值提升之路》——1.5 腾讯的软件测试

1.5 腾讯的软件测试 腾讯的软件研发特征是:典型的互联网企业,产品完全是自运营,以周或者更短的周期发布版本.有追求快的新业务,也有平台性质的QQ.需求的提出并非客户主导.属于领域的领先者但并非先驱,所以快是首要要求.开发测试比是3∶1.这是电商产品线的比例情况,其他产品的测试团队以前也类似,但近年收缩,外包的比例加大.测试职位的名称:TE.TE既做测试也做工具,主要职责如下:1)在业务上线之前尽可能地发现导致商业目标无法达成的缺陷.比如业务不能正确工作,正常完成操作很困难,性能极差等,如果在计

《 软件测试价值提升之路》——第1章 Chapter 1 他山之石 1.1 测试困局

第1部分 引 子测试工作是否有价值,这似乎是一个不值得讨论的问题,因为几乎所有的软件公司都有测试团队,既然一个以盈利为目的的组织,舍得为了测试进行投资,那么测试工作就一定是有价值的.但是另一方面,无论是从业界了解的情况,还是从我们测试团队自身看,测试工程师转行的比例都高于同级别的开发工程师和系统工程师,这些转行的测试工程师在新的职业道路上大多获得了更高职位.更好的发展.这说明他们在测试岗位上的发展受阻,并非由于自身的素质和能力造成的,很可能是由于工作的价值没有得到肯定.测试的工作大多数是属于破坏

《 软件测试价值提升之路》——3.4 随机出错

3.4 随机出错 3.4.1 问题案例 十多年前我曾经参与解决一个产品的随机问题,这个问题导致产品宕机,重启后就能正常处理业务,但是宕机在一个月内总会发生,时间不固定,也没有发现和哪些操作有关系.这个问题持续影响客户的应用长达几个月,一直无法定位解决.后来公司在面对各方的巨大压力下,暂停新特性的开发,让整个团队花了一个月的时间,终于定位了这个由于魔鬼数字引起的问题,仅仅问题重现就花了差不多3周. 这类问题典型的有:产品偶尔无规律地宕机:用户偶尔无规律地无法操作或操作出错:进行简单恢复后,不再必然

《 软件测试价值提升之路》——3.2 正常使用中部分出错

3.2 正常使用中部分出错 3.2.1 问题案例 我们的产品中遇到的大部分客户问题都属于此类.例如: 某产品的客户端是运行在浏览器上的,支持IE8.IE9.Firefox,但是经常出现某些页面在其中一款浏览器上显示不全或者错位等问题,有个产品由于问题太多,以至于不再支持Firefox.对于移动应用,最常见的是APP在某个终端品牌或操作系统版本上不能正常使用. 某产品新版本逐渐替换老版本的过程中,客户开始使用时都没有发现问题,到某个客户那里突然和原有的功能不兼容.分析发现某个接口字段的合法取值是0

《 软件测试价值提升之路》——第3章 拦截缺陷 3.1 用户无法正常使用

第2部分 扫 门 前 雪作为一个测试团队,基本的职责是:测试产品,发现缺陷,报告结果,使每个版本的测试水准稳步提升.这些价值是作为一个测试所必须具备的,发挥这些价值能够让测试获得研发团队的基本信任.这类价值分为3部分:1)拦截缺陷,即对产品进行测试,尽可能把产品的缺陷拦截在研发阶段.2)提供数据,即提供产品的质量结论,并且给出支撑这些结论的数据.3)测试过程可控,提升测试团队和测试工程师的能力,使得产品测试的效率.质量.成本都处于可控状态."扫门前雪"说明这些价值基本上是测试的本职工作

《 软件测试价值提升之路》——3.5 分层构建缺陷拦截能力

3.5 分层构建缺陷拦截能力 找缺陷(bug)是公认的.测试最基本的职责(或者说价值).本小节按照缺陷的激活条件介绍了拦截各类缺陷的思路.方法及工具,如表3-4所示. 缺陷拦截并没有放诸四海而皆准的方法,需要根据缺陷的特点定制针对性的方法,如果把拦截缺陷比喻为捉鱼,不同激活条件的缺陷,需要不同捕鱼手段,图3-11所示. 基本用例集.测试基线库是一个面积比较大但是不很密的网,作用是"捞大鱼",确保基本的功能和应用场景的正确性,因此,这个网追求的是对特性.功能.需求.场景层面的覆盖.测试设