写点什么

Facebook 如何提高软件质量?

  • 2012-11-04
  • 本文字数:1939 字

    阅读完需:约 6 分钟

刘彪是微软测试技术团队的一名软件设计工程师,他在自己的博客上分享了 Facebook 如何提高软件质量的原则、手段和背后的原因。

在文章开头,刘彪指出:

虽然 facebook 已经早已不是创业公司,但是不难看出它在产品研发和质量控制仍然保持着创业公司的风格。

他提到,Facebook

以小的研发团队为核心,遵循几个非常重要的原则:

  • Be there from start to ship: 每个工程师自始至终负责产品。从最开始的一个想法,到开发原型,到内部审核,反馈,到产品开发,上线和维护,全部有工程师自己搞定。
  • Show work early and often: facebook 非常看重反馈,尤其早期内部反馈。他们鼓励工程师有了想法后,尽快开发出原型,尽快得到反馈。
  • Gets your hands dirty: 动手去做,去实现。
  • Don’t fall in love: 互联网产品是不断变化的,不需要等到把一个产品设计的很完美了才发布。

接下来,他举出了 Facebook 为了遵循上述原则而采取的质量控制机制:

  • 开发对质量负责: 开发从设计,实现,测试,到部署都要自己做。其它做工具,流程的工程师通过开发工具和流程来帮助开发人员更为简单方便地做测试,做部署和做监控。每个开发人员有自己单独的测试环境,测试环境就是运行在开发本地机器上,部署非常简单快速。测试环境用的是真实的用户数据。
  • 持续集成和测试自动化:每周发布一次。星期天晚上,要发布的构建从主线上分支出来到发布分支,到星期二的中午如果没有大的问题,就可以上线了。所有的测试运行控制在 10 分钟以内,所以不需要考虑不运行哪些测试用例。运行所有测试用例。 (只是听说,没有经过考证。)
  • 内测 (dog food):发布之前,公司员工使用要发布的功能。2-3 天之内可以有几百个或上千个人在使用新功能。负责要发布功能的开发人员在星期天晚上到星期二中午之间会做大量的测试 。
  • 发布风险控制:新功能本身质量可能有问题,新功能也可能影响其它现有功能。为了减少或控制这些风险。Facebook 开发了一整套完善的发布,控制,监控流程和工具。做到:1. 测试通过后,产品质量基本有保证。2. 即使有漏测的 bug,只会影响很少量的用户。3. 及时监控到问题。4. 及时修复。
  • 产品监控:监控产品的系统的运行状态。

刘彪指出:

Facebook 之所以采取这种质量控制策略和它的产品特点密切相关:

  1. 用户对社交产品质量的容忍度相对较高。比如发微博,现在连不上,等一会在连接也可以,现在发布不出去可以等一会再发,粉丝数量统计有误,没有人太关心。其实 Facebook 并不认为自己的质量差。他们认为产品的质量高低不是有多少个 failed 测试用例, 有多少个 bug 来确定的,而是有用户对质量的期望值来决定的。如果用户对产品质量的期望值很高很高,一个 bug 漏掉了都会照成质量差的印象,用户很有可能放弃使用。相反,如果用户的期望值一般,100 个 bug 漏掉了都不会影响用户继续使用。所以 facebook 产品发布的条件是满足用户对质量的期望值即可。
  2. 相对宽松的产品发布周期。不像微软或 google 很多产品已经在市场上,用户对下一版本的发布时间和新增加功能的期望很高,这往往给产品开发组的压力很大。Facebook 基本没有这个问题,它有适合自己的发布期限,不用受到外界干扰。
  3. 产品发布和监控流程比较完善,即使有漏测的 bug,对用户的影响可以控制在最小而且可以及时发现及时修复。

“没有专职测试工程师”,刘彪认为这是 Facebook 质量控制中引以为豪而且倍受瞩目的的一点:

  1. 什么是“专职测试工程师”? 头衔里面有“测试”的工程师?专门找 bug 的工程师?专门做质量控制的工程师?等等。
  2. Facebook 的确没有带“测试”头衔的工程师,也没有专门运行产品找 bug 的工程师。每个人都是开发工程师。但是他们的实际工作有区别,有的专门做面对用户的产品,有的专门做测试,开发工具,有的专门做产品的构建和持续集成工具和流程,有的专门做发布和监控的工具和流程。如果按照传统意义上的开发和测试的划分的话,除了第一类外,其他都可以看做专职测试工程师。
  3. Facebook 不是惟一一个没有带“测试”头衔工程师的公司,很多软件公司都没有,比如 Twitter。
  4. 很多人把专职测试工程师指专门运行产品找 bug 的工程师。微软在 2005 年去掉 STE (software test engineer ) 岗位,就已经没有这一类型的专职测试工程师了。

对于专职测试工程师,刘彪的看法是:

专职测试工程师是个非常模糊的结论。尤其现在我们对产品质量控制方法的不断演变和提高,“测试”的概念不仅仅是指找 bug 了,所有围绕提高产品质量的工作都是测试。头衔上有没有“测试”不重要,有没有“测试”岗位不重要,重要的是如何有效保证和提高产品质量。

刘彪曾在多个技术大会上做过微软相关开发技术和流程的演讲,同时也主编了《详解Windows Azure 云计算平台》一书,在他的博客中,还分享了 Amazon Google 微软如何提升软件质量,感兴趣的读者可以移步一观。

2012-11-04 19:106903
用户头像

发布了 479 篇内容, 共 158.2 次阅读, 收获喜欢 50 次。

关注

评论

发布
暂无评论
发现更多内容

食堂就餐卡系统设计 - 简陋版

X﹏X

食堂就餐卡设计说明书

小师妹学JavaIO之:NIO中Channel的妙用

程序那些事

io nio 小师妹 buffer channel

【总结】架构师如何做架构

小胖子

week01总结

seki

极客大学架构师训练营

架构方法:架构师如何做架构

【第一周】学习总结

黑莓

架构师训练营--第1周总结感想

芥菜

让独立思考成为习惯

Neco.W

学习 深度思考 思考

量子技术到底有哪些突破值得重点关注?

蔡芳芳

架构师训练营——食堂就餐卡系统设计

养乐多

《第一章:架构师如何做架构》总结

尔东雨田

极客大学架构师训练营

架构师训练营作业一:食堂就餐卡系统设计

常江舟

极客大学架构师训练营

架构师训练营第一周学习总结

常江舟

极客大学架构师训练营

架构师训练营-Week1-作业2

车小勺的男神

使用VSCode连接到IBM Cloud区块链网络

程序那些事

智能合约 hyperledger fabric ibm cloud

架构师训练营——第一周总结

养乐多

架构方法

shangyu

极客大学架构师训练营

SpringBoot分布式任务中间件开发 附视频讲解 (手把手教你开发和使用中间件)

小傅哥

小傅哥 中间件 springboot 分布式任务

Week 01 食堂饭卡系统设计

Geek_165f3d

架构师课程学习第一周心得

秤须苑

极客大学架构师训练营

玄姐公开课总结【构建基于ServiceMesh的普适业务中台架构】

魔曦

架构 Service Mesh

第一周:架构方法-架构师如何做架构学习总结

DZ

食堂就餐卡系统设计文档

秤须苑

极客大学架构师训练营

架构师训练营-Week1-作业1

车小勺的男神

第1周 学习总结

安阳

【第一周作业】食堂就餐卡系统设计

黑莓

架构师训练营——第一周总结

Andy风

week01作业

seki

就餐卡系统设计

小胖子

架构师第一周上课总结

种个大西瓜

Facebook如何提高软件质量?_研发效能_郑柯_InfoQ精选文章