谈起敏捷测试的优秀实践，其实我们已经在第 7 讲中介绍过一家优秀公司——Etsy 公司的实践。该公司建立了“代码即艺匠（Code as Craft）”这样优秀的工程师文化和质量内建文化，开发阶段的测试由开发人员负责，但 Etsy 拥有独立的测试（QA）团队，主要负责下列一些工作：

针对新功能和新产品进行探索式测试、集成测试及跨平台的兼容性测试；

针对移动端的发布进行验证测试；

验证用户可感知的改变。

这一讲，将介绍微软、谷歌、亚马逊、Facebook、奈飞等几家优秀公司的敏捷测试实践。

Microsoft 的优秀实践之前谈起软件测试，一定会竖起微软这杆大旗。在传统软件测试领域，微软的确做得很好，不少同学应该都看过《微软的软件测试之道》这本书，而且在高峰期的时候，有些团队开发:测试比是 1:2，没错，测试人员比开发人员多。即使在移动互联的今天，微软也没有辜负大家的期望，最近几年转型很成功，市值 1.39 万亿，超过苹果，成为世界第一。

微软搞敏捷比较迟，2008 年参加微软的软件研发高峰论坛，那时微软还是在提每日构建、每日集成，还没有提“持续集成”和敏捷。直到 2011 年 7 月，微软公司副总裁 Brian Harry 才正式宣布：微软郑重承诺开始全面实施敏捷，这种对敏捷的承诺是由商业需求驱动的，也就是为了让企业具有更大的活力、竞争力和生命力，必须改变过去每隔几年才交付一个新的软件版本，为此，微软别无选择，只能选择敏捷。在 2014 年微软大刀阔斧进行了组织变革，除了在操作系统团队保留了 300 左右的专职测试人员，一万多专职的测试人员彻底消失了，其中 80% 的专职测试人员（SDET）头衔都统一改为“软件工程师”，融入整个敏捷团队中去了，既做测试，也做开发或运维。

2015 年 10 月 27、29 日，Steve Denning 连续写了两篇文章《惊奇：微软是敏捷的》（Surprise: Microsoft Is Agile）和《微软实现大规模敏捷的 16 个关键》（Microsoft’s 16 Keys To Being Agile At Scale），对微软实施敏捷的肯定。在第一篇文章中，作者的习惯性认识被颠覆了，之前认为微软这样拥有十几万员工的大公司，就像一艘航空母舰那样（如图 1 所示），很难掉头，变革困难，前进的速度很慢，难以快速交付产品。甚至 Scrum 创始人之一 Ken Schwaber 在其博客中都在质疑像微软这样的大公司是否能够从官僚主义体制中解放出来。

图1 之前对微软的错误认识

但在作者走进微软公司之后，感到惊奇，原来公司已被成功改造成无数个小团队，航空母舰大部队被分解成乘坐快艇的快速反应部队（如图 2 所示）。即实现了今天我们熟悉的多管道快速发布的机制，发布周期从几年到现在几周，的确震撼。

图2 走进微软之后的真实印象

这段旅程，不会那么顺利，而是跌宕起伏，其间做对了一些事情，也做错了一些事情，经历了痛苦，但最终还是成功了，这也从微软的股票市值上得到了验证。微软的一些优秀的实践，可以概括为永远用最优秀的工程师和最优秀的工程实践，包括下列几点：

一体化的工程系统（One Engineering System，1ES）团队是 Microsoft 的 Cloud + AI Platform 部门的一部分，以帮助改善设计和研发人员的工程经验，包括提升内部源代码质量、产品和服务的可访问性、安全性和合规性，类似华为2012实验室之下的研发能力提升中心；

推行积极的“自我托管（self-hosting）” 文化，一方面确保本地团队运行自己的构建并解决发现的任何问题，另一方面公司内部首先部署公司开发的最新内部版本，及时发现缺陷；

专注于为客户提供价值，特别强调向用户交付价值，即按照对客户的影响决定积压工作的优先级，并建立了客户反馈系统（Customer Feedback Systems），了解系统运行状况、可用性、性能及服务质量（QoS）等质量指标，更好地理解用户使用系统的情况，形成产品完整的闭环，从而持续地改进产品，提升用户体验；

测试即服务（Testing as a Services），测试不仅为研发提供服务，而且也为运维提供服务，主动发现性能方面的异常，并判断造成这种情况的原因，消除产生各种问题的根源，只有做好测试服务，才能更好地保证产品质量；

强大的基础设施，逐步将 IT 系统全部迁移至微软的公有云 Azure 之上，同时在内部全面推行 Azure DevOps 平台作为统一的 DevOps 工具链，以及构建数据驱动质量（Data-Driven Quality，DDQ）平台。

Google 的优秀实践Google 和微软在实践方面有许多的相同点，包括只招聘最优秀的人才、构建强大的基础设施、内部尝鲜、金丝雀发布（灰度发布）、不断提高迭代速度等，而且在更早的时候 Google 就去掉了 SET（Software Engineer in Test）的角色，将测试团队转化为工程效率（Engineering Productivity）团队，为整个软件研发提供自动化测试技术和工具支持。

这里侧重讨论 Google 的两大实践：整洁的代码和又快又好的测试。

整洁的代码

要求代码遵守代码规范，之前许多公司的 C++/Java 语言规范都是以谷歌的代码规范为榜样的，在 Google，诸如库、程序和测试这些构建实体，均由高级的**声明式构建规范（DBS）**进行声明，描述具体的每一个实体，比如实体的名称、源文件、相关的库文件或所依赖的其他实体。构建文件可以自动生成和更新，并确保构建系统通过分析构建文件而不是源文件来快速地确定依赖关系，并以此避免了构建系统和编译器，或者用于支撑其他编程语言的分析工具之间的过度耦合。

所有源代码主库的变更都必须经过除作者外至少一个以上的工程师审查，每一个项目都要开代码评审会；如果发现一个错误，通常会追踪到引入此项错误的变更和原代码的评审意见，并指出问题在哪里，以便让原始作者和评审人员都了解问题所在，而且开发了优秀的基于 Web 的代码评审工具。整个评审流程疏而不漏且高效。在 Google 的团队中定期扫描各个组件中未关闭的 Bug 是十分常见的，优先关注这些 Bug 并合理地将它们分配给相应的工程师。

又快又好的测试

又快又好的测试，强调任何单个测试超过 60 秒都没有价值，测试执行越快越有价值，每天执行近 1 亿个测试用例。

单元测试是 Google 公司非常提倡和广泛采用的工程实践。产品线上所有的代码都要求进行单元测试，如果新添加的源文件没有进行相应的测试，那么代码审核工具会将它们突显出来。

所有的构建都需要经过测试。如果测试失败，则几分钟内系统就能自动通知作者及其评审人员，从而添加新的变更来修复失败，新的变更会再次合并到新版本分支，再重新构建和重新测试。直到测试全部通过后，将构建好的可执行文件和数据文件一起打包。所有这些步骤都是自动执行的，因此发布工程师只需要运行一些简单的命令就能完成。

集成测试和回归测试也得到了广泛的应用。一旦候选版本已经完成打包，则通常部署到 staging 服务器上，进一步完成集成测试，而且采用先进的技术和高效的策略来完成测试。例如，从产品线上发送一份请求的 copy 到 staging 服务器，即采用真实的数据请求完成测试。自动化系统频繁地运行测试，只要有代码改动就进行回归测试，迅速而准确地检测到问题的发生。

2018 年，Google 更是推出了一款全新的持续集成和持续交付（CI/CD）工具，即 Google Cloud Build，能用来快速且大规模构建、测试和部署软件。可以在 Google Cloud Build 中设置持续构建流水线，自动执行构建和测试工作；而且它能够发现持续集成中出现的问题，可以提供分析和建议，用户还可以通过历史错误、警告和过滤器来识别那些可能会阻碍程序构建与部署的问题。

Amazon 的优秀实践之前人们关注 Amazon 公司不多，今天它的股票价格超过 2440 美元，市值超过一万亿美元，超过 Google，值得我们好好研究。说起 Amazon，就想起他们一直提倡建立“两个比萨的团队（Two-Pizza Teams）” ——真正的敏捷团队（5 ~ 9 人，中餐两个比萨可以让团队吃饱）、扁平化的组织结构，对人才也非常重视，在招聘上很下功夫，专门在公司设立 200 ~ 300 人的 Bar Raiser，提高新人加入公司的门槛。

Amazon 现在是世界上最大的云服务供应商，它的基础设施不容怀疑，完全可以和微软、Google 媲美，甚至超越他们。在 AWS 弹性云上实现持续集成、持续交付以及 DevOps 的各种服务，如 AWS CodeDeploy，平均每秒钟超过一次的部署活动，也能做到一键回滚。

Amazon 做得最好的方面是把“以客户为中心”这样的质量文化做到极致，不仅把“以客户为中心”写到企业愿景中，真正痴迷于客户，有着特殊的“空椅子文化”： 在开会的时候总是在会议室放一把留给客户的空椅子，以此提醒与会者，这里有最重要的人——客户。这种仪式感可以帮助参加会议的人员把自己带入到客户角色，从客户的角度思考问题，制定决策。而且围绕客户需求而制定了 400 个量化指标来衡量运营表现，追求细节，即便是最细微的网页载入延迟也不是小事，必须找到原因，尽快纠正。因为根据 Amazon 的统计，0.1 秒的网页延迟，会直接导致客户活跃度下降 1%。

以极致的“以客户为中心”质量文化为基础，始终强调敏捷的核心实践之一“质量内建”， 这包含了今天倡导的许多敏捷测试和 DevOps 的优秀实践，比如测试左移、持续集成、持续交付、测试右移等。而且开发人员通过承担编码、测试、部署，甚至是线上运维的责任，真正做到对自己的代码质量负责。其次，还体现在架构优化上，架构从单体结构演化成面向服务的 SOA 架构、再演化成微服务结构、一切皆 API，彻底解耦，系统组件/服务之间的依赖度降低，团队间的代码冲突减少，而且错误被隔离到单个微服务中，绝大部分的测试都可以基于接口开展，做得又快又好。

除此之外，还有其他质量内建的具体实践，比如：

通过技术上的创新不断提升用户体验；

相互之间的代码评审以便尽早发现代码的缺陷；

编写各种测试脚本，比如单元测试、集成测试、性能测试；

通过自动化的部署管道把软件部署到测试环境、类生产环境、生产环境中；

监控生产环境中软件的运行情况。

除了上面介绍的三大公司的优秀实践之外，Facebook、Netflix 等优秀公司也做得不错。Netflix 成熟的质量保障之道、强大的基础设施、混沌工程、微服务实践等也闪闪发光。Facebook 和 Google 一样，都有工程师文化，代码为王，并强调用正确的工程方法、思路来完成工作的文化，这也能极大地激发开发人员的内驱力和创造力。例如，Facebook 搭建了强大的试验框架，在任何一个时刻都可以测试上千个不同版本的 Facebook 服务，和 Google 类似，可以做到又快又好的测试，很好地支持快速迭代、持续交付的目标。

由于篇幅所限，这一讲就讲到这里，最后出一个思考题，学习完本讲之后，结合自己公司的实际情况，上面所介绍的哪些优秀实践，你会想马上采用、实施？

-– ### 精选评论