《Google软件测试之道》读书笔记---第一章

第一章 Google软件测试介绍
第二章 软件测试开发工程师
第三章 测试工程师
第四章 测试工程经理
第五章 Google软件测试改进
 

第一章 Google软件测试介绍

1.Google是如何测试的？

在Google，软件测试软对归属于一个被称为“工程生产力”的中心组织部门，这个部门的职责横跨开发测试人员使用工具的研发、产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。Google拥有大量针对互联网产品的共享工具与测试基础框架，服务于包括搜索、广告、Apps、YouTube视频和其它我们再Web上提供的产品。

2.Google在测试人员如此缺乏的情况下，是如何应对的呢？

在Google，写代码的开发人员也承担了质量的重任。质量从来就不仅仅是一些测试人员的问题。在Google,每个写代码的开发者本身就是测试者，质量在名义上也是由这样的开发测试组合共同承担。

1.1质量不等于测试

1.质量不是被测出来的，但同样有证据可以表明，未经测试也不可能开发出有质量的软件。如果测试都没有做，如何保证你的软件具有很高的质量呢？

有一个简单的办法可以解决这个难题，那就是停止开发与测试的隔离对立。开发和测试应该齐肩并驱。你需要在写完每一段代码后立刻测试这段代码，当完成了更多的代码时就要做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分。质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，知道不能区分彼此的时候，你就等到了质量。

2.Google能用如此少的专职测试人员的原因，就是开发对质量的复制。边开发边测试。

3.测试是开发过程中必不可少的一部分，当开发过程和测试仪器携手联姻时，即是质量达成之时。

1.2角色

有一种工程师角色必须存在，他可以让开发人员更加有效且高效地做测试。在Google,我们的确创建了这样的角色，他的职责就是让其他的工程师更有效率和质量意识。这些角色把他们自己看做是测试者，但实际上他们的使命是提高生产率。测试人员的存在是为了让开发人员的工作更有效率，并且很大一部分体现在避免因马虎存心导致的返工，因此，质量也是效率的一部分。

1.软件开发工程师（SWE）：开发角色，实现最终用户所使用的功能代码。

2.软件测试开发工程师（SET）：开发角色，工作重心在可测试下和通用测试基础框架上；相比较SWE是在增加功能性代码或是提高性能的代码，SET更加关注于质量提升和测试覆盖率的增加。

3.测试工程师（TE）：一些Google的TE会花费大量的时间在模拟用户的使用场景和自动化脚本或代码的编写上，他们会把开发工程师和SET编写的测试分门别类地组织起来，分析、解释、测试运行结果，驱动测试执行，特别是项目的最后阶段，推进产品的发布。

1.3组织结构

1.4爬、走、跑

Google经常在最初的版本里只包含最基本的可用功能，然后再后继的快速迭代的过程中得到内部和外部用户的反馈，而且每次迭代的过程中都非常注重质量，一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta版本或正式发布版本。

1.金丝雀版本：这是每日都要构建的版本，用来排除过滤一些明显不适宜的版本。

2.开发版本：开发人员日常使用的版本，一般是每周发布一个。

3.测试版本：这是一个通过了持续测试的版本。这个版本基本上是最近一个月的最佳版本。

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

1.5测试类型

1.Google并没有使用代码测试、集成测试、系统测试这些命名方式，而是使用小型测试、中型测试、大型测试这样的称谓，着重强调测试的范畴规模而非形式。

2.小型测试一般来说（但也并非所有）都是自动化实现的，用于验证一个单独函数或独立功能模块的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差错误等方面的验证。通常由SWE来实现。

3.中型测试通常也都是自动化实现的。该测试一般会涉及两个或两个以上，甚至更多模块之间的交互。测试重点在于验证这些“功能邻近区”之间的交互，以及彼此调用时的功能是否正确。

4.大型测试涵盖三个或以上（通常更多）的功能模块，使用真实用户使用场景和实际用户数据，一般可能需要消耗数个小时或更长的时间才能运行完成。大型测试关注的是所有模块的集成，单更趋向于结果驱动，验证软件是否满足最终用户的需求。