《Google软件测试之道》——介绍

一、质量不等于测试
质量不等于测试，当你把开发过程和测试放到一起，混合搅拌，直到不能区分彼此时，就得到了质量。

二、角色的划分
测试人员的存在是为了让开发人员的工作更有效率，质量也是效率的一部分。

• 软件开发工程师 SWE
  实现最终用户所使用的功能代码

• 软件测试开发工程师 SET
  开发出可测试性和通用的测试基础框架

• 软件测试工程师 TE
  模拟用户的使用场景或编写自动化脚本，把控整体质量

  SWE负责功能实现和这些独立功能的质量。SET负责提供测试支持，保证这些功能模块具有可测试性。TE专注用户角度的测试，确认开发人员在测试方面的工作是否到位，确认功能十分满足性能期望，在安全线、国际化、访问权限等方面是否满足用户的要求。

三、组织结构

测试是独立存在的部门，是与专注领域部门平行的部门。测试人员以租借的方式进入产品团队，去做提高质量相关的事情，寻找一些测试的不足，或公开一些不可接受的缺陷率数据。

这种测试人员在不同项目之间的借调模式，可以让SET和TE时刻保持新鲜感并且总是很忙碌。

四、版本模式（爬、走、跑）

在一个产品的基本核心功能实现后，就立刻对外发布使用，然后从用户那里得到真实反馈，再进行迭代，每次迭代的过程中非常注重质量。一个产品在发表给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta版本

• 金丝雀版本：产品工程师（测试或开发人员）和管理人员才会安装的版本，用来排除过滤一些明显不适宜的版本
• 开发版本：开发人员日常使用的版本，一般一周一个。具有一定的功能，并通过了一系列的测试
• 测试版本：公司内部人员使用，一般是一个月以来最佳版本。这个版本通过了持续测试，也是在日程工作中使用的最稳定最信任的一个版本。
• beta版本：由非常稳定的测试版本演变而来，并经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。

五、测试类型
使用小型测试、中型测试、大型测试等称谓，着重强调测试的范畴规模而并非形式。

• 小型测试：用于验证一个单独函数或独立功能模块的代码是否按照预期工作，通常都是自动化实现。

• 中型测试：涉及两个或两个以上、甚至更多模块之间的交互。通常也是自动化实现，

• 大型测试：涵盖三个或三个以上的功能模块，使用真实用户使用场景和实际用户数据，更倾向于结果驱动，验证软件是否满足最终用户的需求，

  将自动化做到力争克服“人类智慧的最后一英寸”