《Google软件测试之道》的一些读书笔记

忙里偷闲，慢慢的把《Google软件测试之道》一书给读完了，以下是我从书里得来的两点经验：

一.紧密结合开发过程与测试

测试之难，保证产品开发质量之难，每个公司每个团队，都会碰到各自的的问题和困难。但最为常见的抱怨（尤其是在互联网行业）是：开发人员不重视测试，测试人员人手不足，开发迭代又快，测不过来。不少团队还喜欢争论开发测试比是1：1还是1：5或者5：1的问题,经常搬出微软这些传统软件巨头的开发测试比是多少多少来为自己辩护。其实，靠堆积人海战术的测试，是不适合在线型的快速的产品交付模式的。Google在这条路上就是另辟新径。

Google的“新径”说到底其实也很简单，就是将开发过程和测试混合在一起，密不可分，他们认为测试是开发过程中必不可少的部分，当开发过程和测试一起携手联姻时，即是质量达成之时。

Google的测试主管Patrick说道： 一个团队能编写出高质量的产品的唯一途径是全体人员共同对质量负责，包括产品经理，开发人员，测试人员等所有人。达到此目的最好方式是使测试人员有能力将测试变成代码库的一个实际功能，而测试功能的地位和应该与真是客户看到的任何其它功能同等重要。

Google将工程师团队分成以下三种角色：

1. 软件开发工程师(SWE，software engineer)

2. 软件测试开发工程师(SET,software engineer in test)

3.测试工程师(TE,test engineer)

以 上三个角色的紧密配合，完成了开发过程与测试的“联姻”。而这个负责“牵红线的月老”，我想就是SET这个角色。SET是产品可测试性的保证。同时，可测 试性不只是将开发过程和测试紧密结合的基础，同时还是检验代码质量和架构是否优良的最好工具。我一直信奉下面这个公式：可测试性=低耦合=优秀的代码=良好的架构

二.版本发布的“爬，走，跑”模式

熟 悉google产品的，应该经常能看到google许多发布的版本后面都带着beta的标签，如我现在是用的chrome版本就是 “33.0.1750.29 beta”。许多产品在线运营了多年，beta的标签也没有去掉，这个标签是在警示用户，产品仍处于改良之中。对于最终用户，只有产品达到99.99%的 可用性，才会将beta的标签去掉。

一般一个产品在发布给用户之前，一般要经历金丝雀版本，开发版本，测试版本，beta或正式发布版本。

金丝雀版本:即每日构建版本，用来排除一些明显问题的版本。这是一个极不稳定的版本，可能随时崩溃。一般只有产品的工程师（开发或测试人员）才会安装使用金丝雀版本。

开发版本：这个是开发人员日常使用的版本，一般是每周发布一个。该版本具有一定的功能并通过了一系列的测试。所有这个产品下的工程师都被要求去安装这个版本，并在日常工作中真正使用它。这其实体现“Eating your own dog food”的软件开发“黄金法则”。

测试版本：这是一个通过了持续测试的版本,一般是一个月里最佳版本。一般可以被挑选为内部尝鲜，当做整个公司的“dog food”。如果该版本能持续表现良好，可作为beta测试的候选版本。

beta或发布版本：这个版本由非常稳定的测试版本演变而来，并经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。

这种“爬，走，跑”的模式，能给产品提供一个测试验证的良好机会，并尽快得到使用过程中的反馈。

以上两点，就是《Google软件测试之道》一书能带来的两点经验，书的其它大部分内容是许多Google内部人士的访谈，我认为这部分都“太Google”了，价值不是太大，也是此书的问题所在。

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF948210000172F6E934F2ED1254