《Google软件测试之道》第二天

第二章：软件测试开发工程师
对于功能代码而言，思维模式是创建，重点考虑用户、使用场景和数据流程上；对于测试代码而言，主要思路是破坏，怎样编写测试代码用于扰乱分离用户以及其数据。
（思路不同）
功能开发人员（feature developer）、测试开发人员（test developer）、用户开发人员（user developer）主要问题是面对用户的任务，用例（use case ）、用户故事、用户场景、探索测试等。
Google的SWE是功能开发人员，SET是测试开发人员，TE是用户开发人员。

2.1SET的工作
2.1.1开发与测试流程
工程师团队的交付物就是即将发布的代码——代码的组织形式，开发过程，维护是日常工作重点。 同一代码库，统一的一套工具。
Google在平台方面有特定的目标，就是保持简单且统一。开发工作机和生产环境的机器都保持统一的通用代码、构建和测试基础设施，每个核心语言只有一个编译器；与语言无关的通用打包规范；文化上对这些共享资源的维护表示尊重且有激励。
重视代码的审核与复用

一个Google产品由三个部分组成：
一个经过良好测试的独立库
一个可读性和复用性都不错的公共服务库
一套覆盖所有重要构建目标的单元测试套件

SET的工作就是在SWE负责对应的一个服务，SET参与到许多测试目标的构建之中，并指出哪些地方需要小型测试；在多个构建目标集成在一起成为一个规模更大应用程序的构建目标时，SET开始做更大规模的集成测试。当构建目标的增长到一定规模时，针对功能集成的小型测试会成为回归测试的一部分。也会报BUG。
SET在开发人员不知道在哪些地方需要单元测试的时候会提出，还同时编写mock和fake工具，甚至编写大型集成测试。

2.1.2SET究竟是谁
SET参与SWE的代码评审。
SET需要了解如何测试他们的代码。

2.1.3.项目的早期阶段
早期阶段，主要精力都在如何试验并证明这些想法的可行性上。当项目还是概念阶段的时候，测试人员不会参与进来。
2.1.4.团队结构
Google团队最初由一个技术负责人（tech  lead）和一个或更多的项目发起人组成。
技术负责人通常由工程师（SWE）担任，负责设定技术方向/开展合作/充当与其他团队沟通的项目接口人。
第一件事就是设计文档。
2.1.5.设计文档
早期的设计文档，主要包括项目的目标/背景/团队成员/系统设计。

1，SET需要熟悉了解所负责的系统设计（文档）；
2，SET早期提出的建议会反馈在文档和代码里；
3，作为第一个阅读所有文档的人，SET对项目的整体了解程度超过了技术负责人。
在审阅文档的时候要有一定的目的性：
（1）完整性；
（2）正确性；
（3）一致性；
（4）设计；
（5）接口与协议；
（6）测试：可测试性/易测试性；

2.1.6 接口与协议
SET是第一个实现所有接口和协议的人。为了可以尽早运行集成测试，针对依赖服务，SET提供了mock和fake。

2.1.7自动化计划
SET尽早的提供一个可实施的自动化测试计划是一个很好的解决办法。试图在一个测试套件中自动化所有端到端的测试用例，这是一个错误。
自动化上投入的越多，维护的成本越大。
SET遵循下面的方法来避免将时间投入到自动化的端到端测试套件上。（1）先把容易出错的接口做隔离，并对他们创建mock和fake。，这样可以控制这些接口的交互，确保良好的测试覆盖率。
（2）接下来构建一个轻量级的自动化框架，控制mock系统的创建和执行。
2.1.8.可测试性
SET编写测试框架。以及一些维护工作。
SET的第一要务就是可测试性，质量顾问的角色，提供程序结构和代码风格方面的建议给开发人员。

代码审查很重要。。。
自动化静态检查，
提交队列（构建系统和版本控制系统之间的防线）——代码冻结。。。

现在发现一个问题。。这本书我看的不是特别的懂，有很多的东西，我可能需要在不断的历练后才看得懂。
那就暂时先放下，先开始把基础的知识和Python补起来再继续看吧。