软件测试开发工程师SET
- 软件测试开发工程师（SET) ：开发的测试辅助工具，服务于开发和测试人员。SET属于软件工程师。
- 版本划分：
- 金丝雀版本 - 每天，排除明显问题
- 开发版本 - 每周，内部使用测试
- 测试版本 - 一定时间后的较稳定版本
- beta或发布版本 - 对外发布版本
- 测试类型划分：
- 小型测试 - 模块级别，代码是否能够按照预期运行，占70%
- 中型测试 - 一系列模块交互是否正常工作，占20%
- 大型测试 - 整个产品操作运行方式和结果是否与用户期望相同，通常贯穿系统整个前端到后端，占10%
- 公共通用模块代码必须经过审核，对可读性有要求。Google公开了代码风格指南，包括
- Google C++ 风格指南
- Google Objective-C 风格指南
- Google Python 风格指南
- Google JSON 风格指南
- Google Shell 风格指南
- Google很少在项目创建初期就投入一大帮人在做计划（包括质量是测试计划）。一般都是几个开发人员做原型，拿着原型演示，然后正式立项批准
- 所有Google项目都有设计文档。最早期的设计文档主要包括项目的目标、背景、团队成员、系统设计。后面随着项目越来越大，对子系统也创建相应的设计文档。SWE写设计文档，SET是第一个审核者。SET也是第一个使用ProtocolBuffer实现所有接口和协议的人。
- 自动化所有端到端的测试用例是一个常见的错误，应当开发规模更小且目的性更强的自动化计划。SET的时间应该投入在提高质量方面，而不是永无止尽的维护不稳定的端到端测试套件，特别是针对产品的特定功能的测试。正确的做法，应当是针对容易出错的接口，创建mock和fake，做一个轻量级的自动化框架。设计工程师在提交代码到服务器之前，必须通过这些自动化测试。
- Google把代码审查作为开发流程的中心，相比较代码编写而言，代码审查更值得炫耀。Google使用了“可读性”资格来达到这一点。目的是确保整个代码库看起来像一个人编写的一样。
- 为了兼顾多个团队同时开发的测试效率和质量，Google使用了提交队列和持续集成的方式进行测试和提交。持续集成以更细的颗粒度（每次提交）来做测试，使得能够更快更准定位到某一次代码的变更导致的问题。
- 把测试工作变成每个功能开发人员的职责，大家共享许多在测试方面有积极意义的经验，鼓励整个团队都去做测试。
测试工程师TE
- TE的工作涉及一些编程，但是编程只是一小部分，他们承担的很多任务不需要编程。
- 在研发早期阶段，功能还在不断变化，TE通常没有太多工作可做。SET通常会更早介入。
- 测试计划是最早出现、最先被遗忘的产物，维护一份测试计划要花费大量精力，除非多数项目的成员会定期查看，否则测试计划并没有什么价值。
- Google采用的测试计划替代方法称为ACC (Attribute, Component, Capability)
- Attribute特质：这个产品存在的原因，其核心价值。一般是一个列表，例如12个短语。测试人员通过阅读特质列表，了解自己所作的测试是如何对产品的存在根本原因产生影响。任何高级用户都应该能够立刻罗列出特质列表。
- Component组件：构成系统的设计模块。任何对源代码和文档有访问权限的项目内部人员应该能迅速罗列出项目的组件。
- Captibility能力：能力处于特质和组件的交接点，组件执行某种功能，来满足产品的一个特质，结果是向用户提供某种能力。能力最重要的一个特点是它的可测试性。
- 对于风险的评估分成两个要素：失败频率和影响
- 失败频率：分成罕见、偶尔、常见、最小
- 对客户影响：最小、一些、较大、最大
- 上述特质和组件会组成一个二维矩阵，然后将能力测试的失败频率、影响加权后，填写到矩阵中，会形成一个风险估计表。
- 10分钟测试计划：30分钟左右80%完整性的测试计划。执着于计划的精准，而无视注定的变化，无疑是严重脱离现实的。
- Google使用一个内部开发的平台GTA(Google Test Analytics)来管理测试，目前已经开源
测试工程经理
- Google的工程师负责的项目是流动的，每隔18个月可以自由选择不同的项目，不需要当前或未来经理许可，切换的过程则利用20%自由时间兼顾前后项目。
- 新员工的分配通常由3个优先级确定
- 新员工的技能与项目所需技能的匹配程度，员工成功
- 新员工的个人意愿，员工快乐
- 项目需要，公司战略
- 在年度评审和晋升决议中，影响力是一个非常重要的因素，高级工程师需要在团队层面和产品层面体现影响力，更高级别后需要在整个Google都发挥影响力。
- 最有力的问题“为什么”。测试的首要两个目的：
- 提高产品质量
- 提高开发工程师效率
- 在Gmail测试团队，测试开发工程师开发自动化测试工具，在测试工作中占50%比例。
- 20%的用例覆盖了80%的使用场景，把这20%自动化，剩下的可以手工完成。大量重复性的工作不适合手工测试，适合自动化。
- 先为少量用户放出一个版本，获得必要的反馈，然后再为大量的自动化测试进行投入
- 测试开发工程师应该牢记测试是开发人员的工作，而他们自己应该专心让测试成为开发人员工作中的一环。我们通过编写测试工具帮助开发人员做到这点。
- 测试的价值在于测试的动作，而不是测试产物。测试的中心是产品，而不是测试角色或者测试用例。
-
在Google，SET的薪资与开发一样，以开发的标准来评估绩效，SET与开发其实是一个角色。
image.png
