提高软件质量实践――Amazon 篇
来源：Bill Liu 的博客（@billliu_seattle）
前几天回国转了一圈，做了两家企业质量管理培训，一次上海测试沙龙，和 chinatest 两次演讲。收获颇多，以后慢慢分享。回来后发现我的软件质量实践系列文章距离上一次发表已经有很长一段时间了。我想还是先把它写完，再写别的文章吧。那么今天我们看看互联网公司的另外一个大哥大是如何做质量控制的――Amazon.
Amazon 是一个很传奇的公司，它 1995 年的时候以一个网上书店起家，在短短的十几年里成为全球最大的在线购物公司。更为甚者，他在 2005 推出的 AWS 云计算服务更是被业界公认为云计算的鼻祖，也是现在全球最大最成功的云计算服务提供商。我一直坚信成功的产品一定是由成功的质量控制做保障的，采取什么样的测试策略只有两个决定因素。一是企业文化，二是产品特点。在分析 Amazon 的测试策略之前，我们先看看它的企业文化。
业界关于 amazon 企业文化和成功要素有很多，我觉得实际上最为核心的只有一个，就是他们的 “low margin, large volume” 理念。就是通过单个商品的低利润和巨大的销售量来最终提高公司利润和公司业务向前发展。工程团队的理念就是要保障企业文化得以顺利实施，所以 Amazon 的工程团队的理念就是如何保障公司 “low margin, large volume” 的企业文化。Amazon 工程团队有以下特点：
●独立的团队：在 Amazon，负责产品功能模块的每个团队相对独立。他们对该模块的所有功能，性能，开发，质量，上线，维护等从头到尾的绝对负责。我们在 Google 中也可以明显看的这一特征.
●敏捷的团队：为了保障团队的敏捷，Amazon 采用 “2 个比萨饼” 的原则来看控制一个团队的大小。也就是 2 个比萨饼就可以吃饱（5－7 个人）的大小。团队内部和团队之间尽量减少工作的交接，一方面减少因为交接照成的不必要延迟，另一方面避免互相推卸责任。Amazon 是最早采用敏捷开发（scrum）的公司之一，他们现在绝大多说产品组都是用 scrum，据说有超过 400 多个 CSM.
●面向服务的产品体系架构。在 01 年的时候，Amazon 随着它的产品线迅速扩大，业务逻辑越来越复杂，现有的产品体系架构极大地限制了整个公司的高速发展。他们重新设计了基于面向服务的，松耦合体系架构，使得各个模块独立开发，修改和维护。所以 Amazon 可以在不牺牲质量的同时，快速推出新产品新服务。
很遗憾的是 Amazon 很少公开谈论他们的质量管理流程和策略，不过通过有限的资料，还是不难看出他们的质量管理的策略：
●开发对质量负责：因为每个团队对模块完全负责，并且要做到敏捷。Amazon 要求开发对质量负责：从设计，写代码开始一直到代码上线。开发做测试不仅可以尽快地发现 bug，而且可以避免过分依赖测试人来提高质量，更为重要的优点是开发在设计是会考虑代码的可测试性（因为他们自己要测试，肯定想方设法使得测试更为容易些），从而使得模块容易测试，容易维护，松耦合，最终极大提高模块质量。因为开发做了大量的测试，Amazon 专职测试工程师也比较稀少（据说对开发的比例是 1:7 左右）。测试的主要职责是负责复杂用户环境下的测试，以及开发测试工具，流程和基础设施。而且很多产品组把一部分功能测试外包，所以即使 Amazon 的测试工程师不多，但是整个产品的测试工作却没有一点减少。
●自动化测试：这里我就不在多说了，和 microsoft, google 一样，他们开发了大量的测试工具和流程基础设施来提高测试效率。开发专注于写代码和测试，不用在搭建环境，部署，运行测试用例，和反馈上浪费时间。除了测试自动化外，他们也开发了一整套用以产品上线，维护和监控的工具和流程。只有这样，开发才有可能既要写代码，又要对代码质量从头到尾负责。
●数据驱动的决策流程：和 google 一样，Amazon 全方位监控它的应用服务的运行状态，从每个 API 调用时间，到用户使用产品的每一步骤。根据对这些数据的分析和挖掘，开发团队决定如何提高产品质量。
如果大家熟悉 Google 的软件质量实践应该可以发现，Amazon 和 google 在软件质量控制的理念和实践有非常的相似之处。有所不同的是，google 的很多项目以实验性为目的，最初没有任何专职测试。只有等到项目真的被重视后，测试才开始介入。做为互联网产品的两个大哥大，他们的测试方式或许可以代表着互联网产品的测试发展方向吧。下一次我们介绍最后一个公司的测试策略－facebook。
相关文章提高软件质量实践――Facebook 篇提高软件质量实践――Google 篇一个女孩从软件测试工程师到主管的成长历程做社会化的测试工程师之一：把软件测试搬出实验室关于软件测试的 5 个误传