读书笔记：Google 软件测试之道【二】

1、“乌托邦式”软件开发过程



在理想的情况下，TDD模式先行，即在代码编写前开发人员会构思好整个代码逻辑并编写成伪代码（当然伪代码中包含了数据取值边界，循环嵌套，异常处理等情况），然后根据伪代码编写单元测试脚本，最后根据单元测试脚本编写业务代码并运行之。最后，如果运行通过则大功告成，一切美妙而顺畅，我称之为“乌托邦式”软件开发。



在这样理想的环境下，人的思维模式会随着岗位的不同而略显差异。对于功能代码开发人员来说：思维模式是创建，重点在于构建业务功能并尽快交付，因此其测试模式为建设性测试；对于测试开发人员来说：思维模式则是破坏，重点在于打破其业务逻辑与数据流，因此其测试模式为破坏性测试。但是两者不会把用户体验放在首位，因此这里需要第三种开发人员“用户开发人员”，他们聚焦于用户场景、用户体验、探索性测试等活动，他们考虑的是端到端的整体能否给用户带来价值，这里我称之为“理想”的三剑客模式。



对Google来说，这三种角色是跟“三剑客”模式比较相似，这就是上篇文章中提到的SWE、SET、TE。



SWE：代码开发人员，负责功能模块开发及相应的单元测试活动；



SET：测试开发人员，部分负责在代码开发人员的单元测试中提供支持，另一部分则为代码开发人员提供测试框架，以便进行更多质量相关的测试工作；



TE：即用户开发人员，负责从业务角度思考开发质量的各种问题，他们也负责编写部分的自动化用例代码，也参与评估整体代码的覆盖率。



2、SET的工作



实际上，整个开发流程中SET和SWE是紧密配合的伙伴，虽然日常工作有所重叠，但是Google是这样认为的：测试工作是由整个工程团队负责，而不仅仅单独由那些头衔上带着“测试”的工程师来负责的。



代码的组织形式、开发过程、维护是日常的工作重点。Google使用统一的工具，这样可以最大程度降低团队成员在不同项目切换的学习成本，而且Web应用开发人无须申请任何权限即可查看其他团队编写在类似场景写下的代码，同时在代码库工具中提供了诸如搜索的便利功能。应该这样说：公开的代码库、和谐的工程工具、公司范围内的资源共享，成就了丰富的Google内部共享代码库与公共服务。



针对这个这些共享的代码，Google内部形成了一套不成文的实践：



• 所有工程师必须复用已经存在的公共库，除非在项目特定需求方面有很好的理由；

• 对于共享代码，首先要考虑的是能否可以容易找到，并具有良好的可读性；

• 共享代码必须尽可能被复用且相对独立；

• 所有依赖必须明确指出，不可被忽视。即这些共享代码在没有知会其他引用它的项目团队或工程师前是不允许被修改；

• 如果一个工程师对共享代码有优化方案时，他需要去重构已有代码并为其他引用它的应用进行迁移提供支持；同时，该“善举”是被鼓励的。如Google的"同僚奖金（peer bonus）"，这样做的目的可以让该“善举”形成良性循环。

• Google非常重视代码审查，特别针对共享代码必须通过相关的可读性审核，并且在通过审核后工程师被授予“良好可读性”证书。另外，内部建有可读性方面的代码风格指南。

• 共享代码对测试有着更高的要求。



Google内部有一种（peer bonus）制度，这是为他人申请小额奖金的制度。不管是在同一个部门还是在不同的部门，只要这个人给自己很大的帮助，或是因为有他的默默努力公司变得越来越好，就可以帮他申请这份对等奖金。我认为这是一种很好的制度，它能孕育出发现他人的优点并积极主动地去感谢这一美德。



首先，SET是名100%的编码角色，是名软件工程师，这个角色设定的特别之处在于该岗位使得测试方式可以让测试人员尽早接入到开发流程，但不是通过所谓的“质量模型”和“测试计划”的方法，而是通过参与设计和代码开发的方式。



1. SET与SWE处于相同的地位，他积极参与各类测试活动，如手动测试和探索性测试等，也会参与SWE的代码评审（因为SET的另外一个考核就是必须了解如何去测试他们编写的代码）；因为在Google看来，测试也是应用产品的另外一种功能，而SET则是这个功能的负责人。

2. 另外，Google也从物理位置上让SET与SWE坐在一起，方便互相学习互相借鉴。正是这样的组合一起构成了Google最有效率的工程产品团队。



以下以软件开发的过程对SET的工作进行介绍：



1、项目早期阶段



在项目早期阶段测试一般不会介入，这个在传统眼光看来可能会有点核突，可能这跟Google的文化及非正式的创新驱动产品的流程约束有关。大家一定听过Google的工程师是有20%的时间用于做自己的事情，且Google的很多创新产品也是来自于那20%。因为在Google看来，在一个产品如果在概念都没完全成型时就去关心质量，这就是优先级混乱的表现。



针对上面这段体会我有两点的感受：

1、我真的很羡慕那20%，最近几个月我一直在做DevOps方面的学习，也把部分所掌握的应用到日常工作中，但是遗憾的是这些时间都是晚上挤出来的，因此推进比较慢；在支撑我做这个的原因不外乎两个：1）想改善工作中的某些东西；2）兴趣所致；

2、关于“优先级混乱”这个事情，我还是那句老话：任何事情合不合理要看当时的上下文。因为Google是互联网公司，天生就是短平快，对质量的考量在某种类型产品在某个特定时间域内确实是没毛病的；但是换成是银行，特别是涉及到动账类交易的话，质量则无论如何都是first priority，这是没得商量的。因此我认为上述这句话没有对错，只有是否适用。大家也不必视为圣经。



2、设计阶段



所有的Google项目都有设计文档，而且文档中会囊括所有将来需要完成的工作清单，也作为项目前进的路标。



在项目初期，在SWE完成设计文档的初稿并发送给更大范围人做正式评审前会请求SET的反馈。因为：



1、SET需要熟悉了解对应的系统设计；

2、SET早期的建议能够马上反馈并更新到文档上，这样也增强了SET在团队中的影响力；

3、对于SET来说，这是一个可以在项目初期快速建立与开发工程师的良好工作关系的好机会。



并在审核过程中，SET一般是带着一定的的目的性，需要完成特定的目标；Google建议从以下几个维度进行审核：



• 完整性 - 鼓励文档编写者通过添加更多细节或外部链接以便补充背景知识，方便新人快速了解；

• 正确性 - 注意文档编写的语法、文字等准确性，注意严谨性；

• 一致性 - 确保配图与文字描述一致性；

• 设计 - 文档中的一些设计需要经过深思熟虑，要考虑到设计所需的前置条件是否满足；

• 接口与协议 - 接口协议是否定义清晰（如接口文档是否都清晰描述了每个字段的格式、长度【字符还是字节】、是否支持为空、是否有缺省值、是否描述清楚支持中文或英文、跟其他字段是否有关联组合值关系、等等）

• 测试 - 文档描述的整个系统的可测试性如何？是否需要增加testing hook，是否需要新增一些内部接口用于服务可测试性？（请永远记住可测试性也是系统非功能性需求的其中一个需求）



3、集成测试前置阶段



为了能够尽早可以运行集成测试，SET在设计文档（特别是接口文档）都基本定版的情况下，会开始针对各个模块的依赖（接口依赖）编写相应的mock或fake代码。有时候，在SWE还没完成业务模块代码编写完成前，其对应的mock或fake已经完成。



4、自动化测试阶段



在自动化测试方面，Google是这样建议的：尽早给SWE提供一个可实施的自动化测试框架及计划是一个很好的解决方案，但是一味追求100%覆盖的自动化却是不切实际的，因为全覆盖意味着维护工作量大及难度大。（其实这个在我看来就是二八原则）



在Google，SET在这个阶段要准备以下工作：



1、把容易出错的接口通过mock或者fake进行隔离，确保良好的覆盖率；

2、构建一个轻量级的自动化框架，控制mock系统的构建与执行；

3、构建一个报表或仪表盘，以确保该系统的质量方面的数据是公开给所有关心的人，同时信息获取的成本是很低的。