Google的软件测试之道-学习笔记

第1章 Google软件测试介绍

1.Google是一家以创新和速度为基础的公司，

1. 快速地发布有用的代码、
2. 迭代地增加早期用户希望使用的功能——最大化用户反馈。
   ——这样的环境下，测试会变得灵活，测试和开发会交织在一起无法区分彼此。

2.测试不是教条式的，不能成为导致创新和开发过程变慢的阻碍。

3.如果你是工程师，那么你同时也是一名测试人员；如果你的头衔有测试字样，你的任务就是怎样使哪些头衔上没有测试的人可以更好地去测试。

4.开发对质量负责，质量是一种预防行为，而不是检测
——这样可以有效减少测试人员的数量。

5.三个职位

1. 软件开发工程师 SWE
   实现最终用户所使用的功能代码，并实现测试用例的代码
   ——增加功能性代码或提高代码性能。
2. 软件测试开发工程师 SET
   工作重心在可测试性和通用（自动化）测试框架上
   ——关注质量提升和测试覆盖率的增加，为了让SWE更好地测试自己的功能。
3. 测试工程师 TE
   把用户放在第一位来思考，代表用户利益
   ——模拟用户的使用场景和编写自动化脚本，构建端到端的自动化测试（关注性能、安全性、国际化、访问权限等方面）。

第2章 软件测试开发工程师

1.理想情况下，完美的开发过程：测试先行

1. 在没有代码之前，开发人员就去思考如何测试他即将编写的程序；
2. 另外一些依赖于外部设施的测试，在你需要时，这些设施可以随时被使用。

2.区分功能开发人员和测试开发人员：

1. 功能代码：思维模式是创建，重点在考虑用户、使用场景和数据流程上；
2. 测试代码：思路是破坏，怎样写测试代码用意扰乱分离用户及其数据。

3.开发背景：单一的公开代码库
——工程师可以从容的在不同项目之间切换，几乎不需要学习成本；
并且对于有需求的工程师，所有源代码都是开放的，带来极大的可复用性。

• 当代码库修改时，需要测试所有受影响的部分重新测试，保证项目的“绿色”。
• 一个完整的Google产品由三部分组成：
  1. 一个经过良好测试的独立库；
  2. 一个可读性与复用性方面都不错的公共服务库；
  3. 一套覆盖所有重要构件目标的单元测试套件。

4.自动化计划

• 规模小目的性强的测试计划，并存在可以提供帮助的测试框架，可以使SWE更愿意参与和帮助SET的工作，且参与测试；不要过分地想得到一个端到端的自动化测试。
• 在端到端的自动化测试上过度投入，往往会将测试与产品的特定功能绑定在一起，而这部分的测试在整个产品稳定之前都不会特别有用。

5.可测试性
SET的任务是编写测试框架，保证SWE代码的可测试性。

6.测试规模

1. 小型测试——单元测试
   集中在函数级别的独立操作与调动上；
   在代码变更时就能立即执行，容易隔离错误，从而较早地发现缺陷并提供及时的反馈。
<