Google软件测试之道第一天

第一部分介绍了Google质量流程的所有角色、概念、流程和细节。
第一章：Google软件测试介绍
1.1质量不等于测试
你需要在写完每段代码后立刻测试这段代码。开发和测试必须同时开展，质量更像是一种预防行为，而不是检测。
1.2角色
you built it，you break it.you fix it
软件开发工程师（SWE：software engineer ）：工作是实现最终用户所使用的功能代码。创建设计文档，选择最优的数据结构和整体架构，并花费大量时间在代码的实现和代码审核上。
也需要编写与测试代码，包括测试驱动的设计 、单元测试、参与构建各种大小规模的测试等 。
软件测试开发工程师（SET：sofeware engineer in test）：也是开发角色，但是重心在可测试性和通用测试基础框架上。他们会参与设计评审，近距离观察代码质量与风险。甚至会对代码进行重构，并编写单元测试框架和自动化测试框架。SET更关注质量提升和测试覆盖率的增加。SWE更关注客户使用功能的开发实现上。
测试工程师（TE）：把用户放在第一位来思考。会花费大量的时间来模拟用户的使用场景和自动化脚本或代码的编写上，会把开发工程师和SET编写的测试分门别类的组织起来，分析、解释、测试运行结果，驱动测试执行，推动产品发布。
SET也是开发人员，负责提供测试支持。编写代码让SWE能够测试她们自己的功能。

1.3组织结构
测试人员在多个方面都有狩猎。、
1.4爬、走、跑
Google产品在最初的版本里只包含最基本的可用功能，然后在后继快速迭代的过程中得到内部和外部用户的反馈，而且在每次迭代的时候都会很注重产品质量，一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、Beta或正式发布版本。
金丝雀版本：每日都要构建的版本，用来过滤一些明显不适宜的版本。如果构建失败，说明流程出了严重的问题，需要去复查一遍我们的工作。需要忍耐度，并且这个版本可能还无法使用应有的基本功能。
开发版本：开发人员日常使用的版本，基本一周发布一个，该版本具备一定的功能，并通过了一系列的测试。
测试版本：通过了持续测试的版本。基本是这个月的最佳版本了。被称为内部尝鲜（dog food），如果该版本一直有较为优秀的表现，作为Beta测试的候选版本。
Beta或发布版本：由非常稳定的测试版本演变来的，经历了内部使用和质量考核的一个版本，也是对外发布的第一个版本。

1.5测试类型
Google没有代码测试、集成测试、系统测试这样的，只有小型测试（涵盖较少量的代码）、中型测试、大型测试这样的。
测试的规模越小，越有可能被实现称为自动化的测试。
小型测试一般是都是自动化实现的，用于验证一个单独的函数或者独立功能模块的代码是否按预期工作。着重于典型功能性问题、数据损坏、错误条件和大小差一错误（常见的程序设计错误）。
小型测试一般由SWE实现，也有少量SET参与，TE基本不参与。
需要使用mock和fake（mock对象是指外面依赖系统的模拟，运行时刻可以根据假设的需求提供期望的结果。fake对象是一种虚假的实现，内部使用了固定的数据和逻辑，但是只能返回特定的结果）。小型测试还是主要解决“这些代码是否按照预期的方式运行”。
中型测试：通常也是自动化实现，该测试会涉及两个或两个以上，甚至更多的模块之间的交互，重点是测试这些“功能交互区”之间的交互以及彼此调用 的时候功能是否正确。
SWE会自觉去查看分析原因，后期TE会手动的、自动化的执行这些用例。
大型测试：涵盖三个或者三个以上的功能模块，使用真实用户使用场景和实际用户数据。验证软件是否最终达到用户的期望。这个产品操作运行方式是否和用户的期望相同，并产生预期结果。

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

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