功能代码的思维模式为创建， 重点在考虑用户、使用场景和数据流程上
测试代码的思维模式为破坏，怎样写测试代码用以扰乱分离用户及其数据
软件开发过程中乌托邦理想模式：功能开发人员、测试开发人员、用户开发人员在可用性和可靠性方面分工合作，达到完美：
- 功能开发人员编写功能代码
- 测试开发人员编写测试代码
- 用户开发人员解决面向用户的任务，包括用例、用户故事、用户场景、探索式测试（？）
2.1 SET的工作
开发和测试流程
代码的组织形式、开发过程、维护是日常工作重点
（1）公共的代码库、和谐的工程工具、公司范围内的资源共享，成就了丰富的google内部共享代码库与公共服务， 有利于加速项目完成和减少项目失败。
共享的基础代码实践规则：
- 复用已经存在的公共库
- 公共的共享代码容易被知道（存储在代码库的共享区域），具有良好的可读性，容易理解
- 公共代码尽可能被复用且相对独立
- 依赖明确指出，不可忽略
- 若共享代码某些地方有更好的解决方案，则需重构已有代码，此行为值得鼓励
- 公共模块代码必须经过审核
（2）最小化平台依赖
操作系统尽可能地与google生产环境的操作系统一致， CPU和OS变化尽可能小。限制运行环境可以节省大量下游的测试工作，避免环境调试问题。保持简单，同样相对安全
（3）打包
打包是一个过程，将源代码编译成二进制文件，然后将二进制文件统一封装在一个linux rpm包里面
构建整体流程：
- 针对服务，编写功能代码，并编译通过
- 新服务构建目标设定为公共库
- 通过调用用库的方式编写单元测试用例，外部依赖用mock模块实现
- 为单元测试创建一个测试构建目标
- 构建并运行测试目标，做适当调整，知道所有测试运行成功
- 静态代码分析
- 递交代码审核
google产品由三部分组成：经过良好测试的独立库、可读性与可复用性不错的公共服务库、覆盖所有主要构建目标的单元测试套件
SET参与到测试目标构建中可，做更大规模的集成测试，编写mock和fake工具
SET职责
通过参与设计和代码开发的方式尽早介入到开发流程中。SET需要了解如何去测试SWE编写的代码，并解答测试问题
项目的早期阶段
若一个产品在概念上还没完全确定成型时去关心质量， 这是优先级混乱的表现；若测试长时间未介入到产品众，则产品可测试性也会很糟糕
团队结构
google产品团队最初由一个技术负责人和一个或者多个项目发起人组成：技术负责人负责设定技术员方向、开展合作、充当与其他团队沟通的项目接口人， 理解细节
设计文档
设计文档主要包括项目的目标、背景、团队成员、系统设计
审阅设计文档推荐要点：
- 完整性：支出文档中残缺不全或需要特殊背景知识的地方， 鼓励作者添加更多的细节， 方便新人阅读理解
- 正确性：语法、拼写等方面的错误
- 一致性：图与介绍的一致性
- 设计：考虑可用的资源，目标是否可以顺利达成？何种基础设计框架？设计是否过于复杂？能否简化？还是过于简单？需要增加什么内容？
- 接口与协议：协议是否有清晰的定义？对外的接口和协议是否完整？是否满足统一的标准？
- 测试：可测试性如何？是否需要新增测试钩子（为了给测试而增加的一些接口，泳衣显示系统内部状态信息）？这部分内容需要添加到设计文档中是否使用已有的测试框架？测试方面需要做哪些工作？
接口与协议
SET会对protocol buffer代码做系统全面的审查， 集成测试的运行依赖这些接口的实现。集成测试依赖mock和fake，因为有了它们，一些依赖服务的期望错误场景和条件异常，会比较容易构建
自动化计划
规模更小且目的性更强的自动化计划，并存在可以提供帮助的测试框架， 会吸引SWE一起参与测试
SET应该把精力花费在提高质量方面，而不是花费在维护那些不稳定的端到端测试套件上， 因此SET遵循下面的方法：
- 容易出错接口做隔离，针对它们创建mock和fake,这样可以控制接口之间的交互，确保良好的测试覆盖率
- 构建轻量级自动化框架，控制mock系统的创建和执行
- 公开产品质量方面的信息给所有关心的人， 使用报表和仪表盘来展示收集到的测试结果以及测试进度。将整个过程简化和信息公开透明化，获取高质量代码的概率增加
可测试性
SET第一要务就是可测试性， 质量顾问的角色
CL(chang list 变更列表)先经过自动化检查（代码风格、测试用例执行是否通过），然后代码审查（通过邮件方式通知审阅者）， 反复进行， 直到递交者和审阅者满意为止
提交队列主要功能是保持“绿色”的构建， 这是构建系统和版本控制系统之间最后一道防线
提交队列和持续集成构建的由来：P29
在机器上持续不断的构建并运行相应的单元测试与集成测试， 后来发现该系统具有一定的通用性， 可以用来支持其他团队