理想情况下，一个完美的开发过程是测试先行，在一行代码都没有编写前，就思考如何测试即将要编写的代码。理想情况下，需要两种开发工程师：功能开发人员和测试开发人员。前者的思维模式是创建，主要关注用户、使用场景和数据流程；后者的思维模式是破坏，重点在如何写代码用以扰乱数据。理想情况下，产品的每个功能对应一个开发，整个产品配备一定数量的测试开发，另外，整个产品还需要一些面向用户的测试人员。
SET一部分职责是在单元测试方面给开发人员支持，另一部分职责是为开发人员提供测试框架，方便他们编写中小型测试。
1.SET的工作
1）开发和测试流程
单一的代码库，所有的源代码对每个人都是开放的，每个人都可以修改别人的代码，但要遵守一些规则。另外，最小化对平台的依赖。每个工程师的机器、系统、工具、编译器尽量保证和线上一致。
一个版本的构建流程：
a）写功能函数，编译通过，并将它的构建目标设定为公共库
b）针对a)写一套单元测试用例，并创建一个测试构建目标
c）构建并运行测试目标，修改调整，直到所有的测试运行成功
d）运行静态分析工具，保证代码风格等的正确性
e）提交代码审核，根据反馈修改，并运行单元测试，审核通过后，提交代码
2）SET究竟是谁？
SET工作的有趣之处在于他们不是通过“质量模式”和“测试计划”介入到开发流程中，而是通过参与设计和代码开发的方式。测试是产品的另外一种功能，而SET就是这个功能的负责人。
3）项目的早期阶段
只有在软件产品变的重要的时候质量才显得重要。明显，在试验初期阶段强调测试是一件非常愚蠢的事情。因此，一些来源于团队20%的业余时间投入的产品，在早期原型阶段，主要精力在于试验并证明这些想法的可行性。一旦项目得到正式批准立项，开发总监就会找测试资源。他们在寻求测试帮助时，会介绍他们的项目、进度、发布计划、当前已有的测试状态、期望的单元测试覆盖率水平、以及明确在发布过程中各自承担的责任。
4）团队结构
SWT一般仅在自己的模块领域里提供最优方案，而一个好的SET不仅要具有宽广的整体产品视野，而且在产品的整个生命周期里对产品及功能特性做充分理解。Google产品团队最初由一个技术负责人和一个或更多的项目发起人组成。
5）设计文档
最早期的项目设计文档，包含项目的目标、背景、成员、系统设计，将来需要完成的工作清单，如果系统足够大，还要有子系统设计文档。设计文档必须要经过相关技术负责人的审核。SET在初期阶段就加入项目，通常来说，代码复用和模块交互方面的设计由SET来做，而不是SWE。SWE在完成设计文档的各部分后，SET会进行审核，一般审核以下要点：完整性、正确性、一致性、设计、接口与协议、测试。在SET与相应的SWE一起沟通设计文档时，关于测试的工作量以及各个角色之间如何共同参与测试，也会有一个比较正式的讨论。
6）接口与协议
开发人员使用protocol buffer的描述语言来定义数据结构，然后使用自动生成的源代码。对于新项目而言，protocol buffer源码通常是第一份源代码。protocol buffer定义的接口与协议的代码实现是要由SET来完成的，在系统真正搭建起来之前，集成测试的运行依赖于这些接口实现。
7）自动化计划
自动化计划中需要包含自动化、以及如何公开产品质量方面的信息（测试结果和测试进度）给所有关心的人。自动化中如果包含所有端到端的测试用例是错误且难以维护的，需要构建一个轻量级的自动化框架，控制mock系统的创建和执行，SWE需要使用mock接口自测，保证提交的代码永远是正确的、干净的。
8）可测试性
Googler每个新开发人员提交代码时需要提交CL（变更列表）以及所有变更的测试代码，给具有审阅资格的SWE或SET审核，审核成功后，才能提交。在提交审查之前，会经过一系列的自动化检查。规模较大的团队可利用提交队列在同一个分支上开发。提交队列的主要功能是保持“绿色”的构建，即所有测试必须全部通过。
在早期，所有等待提交的CL必须逐个排队，等待测试，如果测试通过则可以提交进代码库，但随着项目规模和复杂度的上升，当有大量长时间运行的测试需要执行时，CL在发送给提交队列和CL真正被提交到源码库之间可能需要消耗数小时。因此，后来，允许所有等待的CL在互相隔离的前提下，并发地构建并运行测试。这样会有一些竞争条件的出现，但实际上很少发生。由此，保证进入代码库的代码不会出现问题，不影响测试。
由于第二章内容挺多了，暂且分为上、中、下三部分，以防消化不完~，上篇到此为止，中篇从 2.1.9（SET的工作流程：一个实例）开始~
图1-太长了
上篇看完的整个感受是原来Google的SET远比国内很多公司所说的测试开发工程师做的事情要多很多，包含编码、设计、写设计文档、审核、自动化等等，因此，需要的技能应该比开发还多~
网友评论