Google软件测试之道-第二章观后感

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

在去工作前，立下一个小flag，把这本书看完。观摩大佬们如何做测试，和大家一起研读感受测试的乐趣。

---

---

前言

功能开发人员在编写功能代码的时候，测试开发人员编写测试代
码，但我们还需要第三种角色，一个关心真正用户的角色。显然在我们
理想化的乌托邦测试世界里，这个工作应该由第三种工程师来完成，既
不是功能开发人员，也不是测试开发人员。我们把这个新角色称为用户
开发人员（译注：user developer）。他们需要解决的主要问题是面向用
户的任务，包括用例（use case）、用户故事、用户场景、探索式测试
等。用户开发人员关心这些功能模块如何集成在一起成为一个完整的整
体，他们主要考虑系统级别的问题，通常情况下都会从用户角度出发，
验证独立模块集成在一起之后是否对最终用户产生价值。。

感觉我即将要工作的地方，测开和用户开发人员是一个角色，整体称为QA？

Google的SWE是功能开发人员；
Google的SET是测试开发人员；
Google的TE是用户开发人员。

用户开发好像就是我们平时说的测试人员呀、

---

一、SET的工作

随着Google的不断成长壮大，出现了第一个融合开发
角色和质量意识于一身的角色，即SET。

本渣以后的角色。

1、开发和测试流程

公开的代码库、和谐的工程工具、公司范围内的资源共享，成就了
丰富的Google内部共享代码库与公共服务。

所有依赖必须明确指出，不可被忽视。如果一个项目依赖一些公用
共享代码，在项目工程师不知情的前提下，这些共享代码是不允许被修
改的。

这个感觉是很重要的，但是如何控制呢？

整体流程：
（1）针对某个服务，在一个或多个源代码文件中编写一类或一系列功能函数，并保证所有代码可以编译通过。
（2）把这个新服务的构建目标设定为公共库。
（3）通过调用这个库的方式编写一套单元测试用例，把外部重要依赖通过 mock 模拟实现。对于需要关注的代码路径，使用最常见的输入参数来验证。
（4）为单元测试创建一个测试构建目标。
（5）构建并运行测试目标，做适当的修改调整，直到所有的测试都运行成功。
（6）按要求运行静态代码分析工具，确保遵守统一的代码风格，且通过一系列常见问题的静态扫描检测。
（7）提交代码申请代码审核（后面对代码审核会做更多详细说明），根据反馈再做适当的修改，然后运行所有的单元测试并保证顺利通过。

2、SET究竟是谁

在面试SET的时候，在代码要求标准上与SWE的招聘要求是一样的，而且增加了一个额外考核——SET需要了解如何去测试他们编写的代码。换句话说，SWE和SET都需要回答代码问题，而且SET还要求去解答测试问题。

假想这样的场景，公司里的开发人员可以做测试，而测试人员可以写代码。Google其实还没有完全做到这一点，或许永远也做不到。这两大群体之间相互交流学习，SWE向SET学习，SET也在学习SWE，正是我们这些最优秀的工程师一起构成了我们最有效率的工程产品团队。

这大概是理想中的吧，理想国度，终究还是开发承担了所有。

3、项目的早期阶段

“只有在软件产品变的重要的时候质量才显得重要”

真理，这也是开发和测试的共同目标吧，把产品变得重要。

许多创新的产品都是来源于团队20%的业余时间。

这个20%的时间，在当今互联网的快速迭代下不知道会不会实现。

考虑到项目还没有正式批准，且所有的演示脚本最终都会被 C++代码重写替换，如果在早期投入大量测试和可测试性方面努力，其实没有太大的实用价值。为了演示而使用脚本搭建的产品，一旦得到正式批准立项，其开发总监就会找到工程生产力团队，寻求测试资源。

测试不能太早介入，也不能太晚介入。

4、团队结构

Google 产品团队最初是由一个技术负责人（tech lead）和一个或更多的项目发起人组成。在Google，技术负责人这个非正式的岗位一般由工程师担任，负责设定技术方向、开展合作、充当与其他团队沟通的项目接口人。他知道关于项目的任何问题，或者能够指出谁知道这些问题的细节。技术负责人通常是一名SWE，或者由一名具备SWE能力的工程师来担任。

双主R?

5、设计文档

所有Google项目都有设计文档。这是一个动态的文档，随着项目的演化也在不断地保持更新。

审阅设计文档的时候要，具备一定的目的性，需要完成特定的目
标，而不是像读报纸那样随意看两眼。

认真看文档

6、接口与协议

为了能够尽早地开始做集成测试，SET针对各个模块的依赖提供了mock或fake的实现。虽然功能模块代码还没有实现，集成测试的代码就已经可以开始编写了。在这个时候，如果集成测试代码可以运行起来，那将会更有价值。另外，在任何阶段，集成测试总是依赖 mock 和 fake。因为有了它们，一些依赖服务的期望错误场景
和条件异常，会比较容易产生。

很好奇这个mock是咋实现的呢，每个模块要实现的功能很复杂。

7、自动化计划

在端到端的自动化测试上过度投入，常常会把你与产品的特定功能设计绑定在一起，这部分测试在整个产品稳定之前都不会特别有用。

自动化实现核心功能，过早的实现自动化会导致后面的维护成本较高。

我们首先把容易出错的接口做隔离，并针对它们创建 mock 和fake（在之前的章节中做过介绍），这样我们可以控制这些接口之间的交互，确保良好的测试覆盖率。接下来构建一个轻量级的自动化框架，控制 mock 系统的创建和执行。这样的话，写代码的SWE可以使用这些mock接口来做一个私有构建。

应该还是保核心功能吧，其他的细节的自动化先不着急写，可能后面会有较大的改变。

8、可测试性

SET的第一要务就是可测试性。SET在扮演一个质量顾问的角色，提供程序结构和代码风格方面的建议给开发人员，这样开发人员可以更好地做单元测试。同时提测试框架方面的建议，使得开发人员能够在这些框架的基础上自己写测试。

9、测试分类

1.小型测试
小型测试是为了验证一个代码单元的功能，一般与运行环境隔离，例如针对一个独立的类或一组相关函数的测试。小型测试的运行不需要外部依赖。在Google之外，小型测试通常就是单元测试。

2.中型测试
中型测试是验证两个或多个模块应用之间的交互，如图 2.3 所示。和小型测试相比，中型测试有着更大的范畴且运行所需要的时间也更久。小型测试会尝试走遍单独函数的所有路径，而中型测试的主要目标是验证指定模块之间的交互。在Google之外，中型测试经常被称为“集成测试”。

3.对于大型测试
在 Google 之外通常被称为“系统测试”或“端到端测试”。大型测试在一个较高层次上运行，验证系统作为一个整体是如何工作的。这涉及应用系统的一个或所有子系统，从前端界面到后端数据储存，如图 2.4所示。该测试也可能会依赖外部资源，如数据库、文件系统、网络服务等。