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

<Google软件测试之道>

2.1 SET的工作

2.11 开发和测试流程

代码的组织形式、开发过程、维护是日常的工作重点
工程师在代码库修改代码时的规则:

• 必须复用已经存在的公共库，除非在项目特定需求方面有很好的理由
• 对于共享代码，首先考虑是否容易被找到，并具有良好的可读性。所有的代码都要考虑到未来会被其他人阅读
• 公共代码必须尽可能复用且相对独立。与功能的复杂或设计的巧妙性相比，可复用性带来的价值更大
• 所有的依赖必须明确指出，不可被忽视。如果一个项目依赖一些公共共享代码，在项目工程师不知情的前提下，这些代码不允许被修改
• 如果一个工程师对共享代码库在某些地方与更好的解决方案，他需要去重构已有的代码，并协助依赖在这个公共代码库之上的应用项目迁移到新的代码库。

 Google非常重视代码审核，特别是公共通用模块的代码必须经过审核。
 在共享代码库里的代码，对测试有更高的要求
一个版本在构建的时候需要制定构建目标，这个目标由许多源文件构建而成，下面是流程：

1) 针对某个服务，编写功能函数，并保持所有代码可以编译通过
2) 把这个新服务的构建目标设定为公共库
3) 通过调用这个库的方式编写一套单元测试用例，把外部重要依赖通过mock模拟实现。对于需要关注的代码路径，使用最常见的输入参数来验证
4) 为单元测试创建一个测试构建目标。
5) 构建并运行测试目标，修改至所有目标都能运行成功
6) 按要求运行静态代码扫描工具
7) 提供代码申请代码审核，根据反馈修改，运行所有单元测试并保证顺利通过

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

2.12 SET究竟是谁

SET是一个100%的编码角色，使测试人员尽早介入到开发流程中去。

2.13 项目的早期阶段

只有在软件产品变得重要的时候质量才显得重要。一个产品如果在概念上还没有完全确定成型就去关心质量，这就是优先级混乱的表现。在实验初期强调测试是一件很愚蠢的事情。但如果产品长时间没有测试的介入，早期在可测试性上的糟糕设计在后期也很难去做改进，这样会导致自动化难以实施且测试工具极不稳定。
在早期原型阶段，主要精力集中在如何试验并证明这些想法的可行性上。为了演示而使用脚本搭建的产品，一旦得到正式批准立项，其开发总监会找到工程生产力团队，寻找测试资源

2.14 团队结构

在早期阶段，我们经常去改变我们的目标。我们做目标，并尝试把东西做出来。我们尝试去文档化我们要做的东西。我们尝试去保证，我们早期做的决定，长期看来也是正确的。
Google的产品团队最初是由一个技术负责人和多个项目发起人

2.15 设计文档

这是一个动态文档
早期包括目标、背景、团队成员、系统设计。项目规模变大，子系统也要创建相应的设计文档，并在所有项目设计文档中增加子项目的链接
SWE渴望得到SET的帮助与反馈。一个优秀的SET会对文档审核比较期待

• SET需要熟悉所负责的系统设计，SET和SWE都期望如此
• SET早期提出的建议会反馈在文档和代码里，这样也增加了SET的整体影响力
• 作为一个审阅所有文档的人（也因此了解所有迭代过程），SET对项目的整体了解都超过了技术负责人
• 对于SET来说，可以在项目初期就与相应的开发工程师建立良好的工作关系

推荐的要点：

• 完整性：找出文档中残缺不全或者需要特殊背景知识的地方。鼓励文档作者在这些方面添加文档细节，或者外部链接，以补充背景知识
• 正确性：语法、拼写、标点符号
• 一致性：图文一致，观点和描述一致
• 设计：考虑可用资源，目标是否可以顺利达成？要使用何种基础的技术框架？期望的设计在框架方面是否正确？设计是否太过复杂？有可能简化吗？还是太简单了?这个设计还需要增加哪些内容？
• 接口与协议:文档是否对所使用的协议清楚地定义？是否完整地描述了产品对外的接口和协议？这些接口协议是否与他们期望的那样一致？对于其他的google产品是否满足统一的标准？是否鼓励开发人员自定义protocol buffer 数据格式
• 测试:系统或文档中描述的整套系统的可测试性怎样？是否需要新增测试钩子(testing hook:
  为了测试而增加的一些接口，用以显示系统内部状态信息)？如果需要，确保他们也被添加到文档中。系统的设计是否考虑到易测试性，而为他们也做了一些调整？是否可以使用已有的测试框架？预估一下在测试方面我们需要哪些工作。

小型测试涵盖单一的代码段，一般运行在完全虚假实现（fake）的环境里。中型测试涵盖多个模块且重点关注模块之间的交互上，一般运行在虚假实现（fake）环境或真实环境之中。大型测试涵盖任意多个模块，一般运行在真实的环境中，并使用真正的用户数据与资源

2.16 协议和接口

Google protocol buffer语言，被用来定义数据结构。Protocol buffer通常是第一份源代码。其定义的所有接口和协议是SET第一个实现的。为了尽早可以运行集成测试，针对依赖服务，SET提供了mock 与fake.

2.17 自动化计划

SET的时间，本应投入在提高质量方面，在端到端的自动化测试上过度投入，会把你与特定产品功能设计绑定在一起，在产品稳定前这部分测试不会特别有用。
SET遵循的方法：
把容易出错的接口做隔离,并针对他们创建mock和fake,以控制与这些接口之间的交互，确保良好的测试覆盖率
构建轻量级自动化框架，控制mock系统的创建和执行。写代码的SWE可以使用这些mock接口做一个私有构建。提交代码到服务器前运行自动化测试，确保只有通过测试的代码才能被提交到代码库

2.18 可测试性

SET的第一要务是可测试性。提供程序结构和代码风格方面的建议给开发人员。
开发人员一个基本要求是有能力做审查。