2021-10-12

Google软件测试之道笔记

第二章：软件测试开发工程师（SET）

编写功能代码和编写测试代码在思维方式上有着很大的不同。
对于功能代码而言，思维模式是创建，重点在考虑用户、使用场景和数据流程上；对于测试代码而言，思路是去破坏，怎样写测试代码用以扰乱分离用户及其数据。
完美理想情况下，产品的每个功能都对应一个开发人员，整个产品则配备一定数量的测试开发人员。测试开发人员通过使用测试工具与框架帮助功能开发人员解决特定的单元测试问题，而这些问题如果只是由功能开发人员独自完成，则会消耗掉他们许多的精力。
软件开发过程的乌托邦理想模式：功能开发人员（SWE）编写功能代码，同时测试开发人员（SET）编写测试代码，用户开发人员（TE）主要解决面向用户的任务，包括用例，用户故事，用户场景，探索式测试等，主要考虑系统级别问题，从用户角度出发验证独立模块集成在一起之后是否对最终用户产生价值。
Google的SWE、SET和TE
Google的SWE负责客户使用的功能模块开发。他们编写功能代码及这些功能的单元测试代码。
Google的SET负责在单元测试方面给与开发人员支持及为开发人员提供测试框架，以方便他们编写中小型测试，用以进行更多质量相关的测试工作。
Google的TE负责从用户角度来思考质量方面各种问题。从开发角度看， 他们编写用户使用场景方面的自动化用例代码；从产品角度看，他们评估整体测试覆盖度，并验证其他工程师角色在测试方面合作的有效性。

2.1SET的工作

融合开发角色和质量意识于一身的角色，即SET。

2.1.1开发和测试流程

新产品开发过程中，SET和SWE紧密合作的伙伴，甚至一些实际工作会有所重叠。Google认为测试工作是由整个工程团队负责，而不仅仅单独由那些头衔上带着“测试”的工程师来负责。Google多数代码存放在同一个代码库中，并使用统一的一套工具。这些工具和代码支撑着Google的构建和发布流程。所有工程师都对如何使用这些工具环境都非常地熟练，团队成员都可完成新代码的入库、提交、执行测试、创建版本等任务（前提角色有这样的需求）。
“百分之二十的贡献”：每周投入一天时间在日常工作之外的项目上，用以试验和创新。
从有经验的工程师那里学习到类似场景下如何编写代码，重用一些通用模块或详细的数据结构，甚至重用一些程序控制结构。

1. 所有工程师必须复用已存在的公共库，除非在项目特定需求有很好的理由。
2. 对于公共的共享代码，首先要考虑能否可容易地被找到，并具有良好的可读性。代码必须存在代码库的共享区域，以便查找。所有的代码都要考虑到未来会被其他人阅读或修改。
3. 公共代码必须尽可能地被复用且相对独立。与功能复杂性或设计巧妙性而言，可复用性带来的价值更大。
4. 所有依赖必须明确指出，不可被忽视。若一个项目依赖一些公用共享代码，在项目工程师不知情的前提下，这些共享代码时不允许被修改的。
5. 如果一个工程师对共享代码库在某些地方有更好的解决方案，需重构已有的代码，并协助依赖在这个公用代码库之上的应用项目迁移到新的代码库上。鼓励“乐善好施”。让正向团队合作形成一种良性循环，并持续下去。除此之外，更应私下感谢。
6. 注重代码审核，特别是公共通用模块的代码必须经过审核。
7. 在共享代码库里的代码，对测试有更高的要求。

所有对平台有依赖的代码，都会强制要求使用公共的底层库。

**Google在平台方面有特定目标，保持简单且统一。**开发工作机和生产环境都保持统一的Linux发行版本；一套集中控制的通用核心库；一套统一的通用代码、构建和测试基础设施；每个核心语言只有一个编译器；与语言无关的通用打包规范；文化上对这些共享资源的维护表示尊重且有激励。

SET会参与到许多测试目标的构建之中，并指出哪些地方需要小型测试。在多个构建目标集成在一起，形成规模更大应用程序的构建目标时，SET需要加速他们的工作，开始做一些更大规模的集成测试。在一个单独的库构建目标中，需要运行几乎所有的小型测试（由SWE编写，所有支持这个项目的SET都会给予帮助）。当构建目标日益增大时，SET也会参与到中型测试的编写之中去。构建目标增长至一定规模，针对功能集成的小型测试会成为回归测试的一部分。若一个测试用例，本应通过，但失败，会报一个bug。这个针对测试用例的bug和针对功能的bug无异。**功能性bug一定要得到修复。**以此保证新增的功能不会把已有功能损坏掉，任何代码的修改都不会导致测试本身的失败？？ 。以上活动，SET始终是核心参与者。他们在开发人员不知道哪些地方需要单元测试时可明确指出。他们同时编写许多mock和fake工具。甚至编写中大型集成测试。