《Google 软件测试之道》读书笔记（1~2章）

第 1 章 Google 软件测试介绍

• 在 Google ，软件测试团队归属于一个被称为工程生产力（工程效率、工程生产率）部门的中心组织的部门。
• 越来越多的公司从桌面应用转向网络应用，Google 的软件测试方法很可能称为这类公司竞相模仿的榜样
• Google 是一家以创新和速度为基础的公司，测试需要异常灵活，并且在技能上需要做许多前期规划，只是不停地简单维护并不能真正解决问题。
• 有时，测试和开发交织在一起，无法区分彼此，但有时候又是完全分离的，甚至开发人员都不知道测试人员在做什么。
• 测试，并非 “教条式的、强流程、体力密集型、耗时的”，测试不能成为导致创新和开发过程变慢的阻碍。
• Google 不招聘太多的测试人员，队伍小而精。
• 写代码的开发人员同时也承担了质量的重任，质量从来就不仅仅是测试人员的责任，每个写代码的开发者本身就是测试者，质量在名义上由这样的测试开发组合共同承担。

1.1 质量不等于测试

• 质量不是被测试出来的，但未经测试也不可能开发出有质量的软件。
  解释：如果在最开始设计创建的时候就是错的，那它永远不会变成正确的；但如果连测试都没有做，怎么证明软件具有很高的质量呢？

• 解决办法：停止测试与开发的独立！
  每写完一段代码就立即进行测试，当完成了更多的代码时，就需要完成更多的测试（这些测试由开发人员完成）。

• 测试不是独立隔离的活动，它本身就是开发的一部分。
  质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，就得到了质量。

• Google 的目标：把开发过程和测试融合到一起——开发测试必须同时开展。

• Google 能用如此少的专职人员的原因：开发对质量的负责
  如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个 bug 的测试人员。

• 质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是检测。

• 在 Google，测试的目标：判断预防工作做得怎么样。

1.2 角色

• 开发人员要对自己写的代码负责，比专职的测试人员更适合做测试工作。
• 测试者的使命是提高生产率。他们的存在是为了让开发人员的工作更有效率，并且很大程度上是为了避免因马虎粗心而导致的返工，因此，质量也是效率的一部分。

1.2.1 软件开发工程师（software engineer，SWE）

工作重心	工作内容	时间花费	备注
实现最终用户所使用的功能代码	创建设计文档，选择最优的数据结构，和整体架构，花费大量的时间在代码实现与代码审核上，编写、测试代码（包括测试驱动的设计、单元测试、参与构建各种大小规模的测试）	几乎将所有的时间花费在代码编写上	SWE 会对他们编写、修复以及修改的代码承担质量责任

1.2.2 软件测试开发工程师（siftware engineer in test，SET）

工作重心	工作内容	时间花费	备注
可测试性和通用基础测试框架	参与设计评审、近距离观察代码质量与风险、对代码进行重构、编写单元测试框架和自动化测试框架	同样花近百分百的时间在代码编写	他们花大量时间编写代码是为质量服务，而SWE更关注客户使用功能的开发实现上

两者比较	关联	不同点
SWE、SET	两者在代码库上是合作伙伴	1. SWE 更关注增加功能性代码和提高性能的代码；SET 更关注质量的提升和测试覆盖率的增加；2. SET 写代码的目的是为了让 SWE 测试自己的功能

1.2.3 测试工程师（test engineer，TE）

工作重心	工作内容	时间花费	备注
把用户放在第一位，代表用户的利益	组织整体质量实践，分析、解释、测试运行结果，驱动测试执行，构建端到端的自动化测试	花费大量时间在模拟用户的使用场景，自动化脚本或代码的编写上	TE 是真正的产品专家、质量顾问、风险分析师

三者工作比较	责任	工作内容
SWE	负责功能实现和这些独立功能的质量	对容错设计、故障恢复、测试驱动设计、单元测试负责；并和 SET 一起编写测试代码
SET	提供测试支持	大部分代码由 SWE 完成，SET 编写代码的主要职责是让开发者可以很容易地编写测试代码
TE	扮演一个双重确认的身份	1. 确认开发人员在测试方面的工作是否到位；2. 常见用户使用场景中，是否满足性能期望，安全性、国际化、访问权限等是否满足用户的要求；3. 与其他团队的TE、合同工编制的测试人员、以众包形式参与的测试人员、内部尝鲜者、beta测试者、以及早期用户进行合作交流，讨论基本设计带来的风险、功能逻辑复杂性、错误避免的方法

<