测试工程师
软件测试开发工程师（SET）负责可测试性和测试自动化体系的长期有效性。测试工程师（Test Engineer，后文简写TE）的职责与之有所不同，TE的重点在于评估对用户的影响以及软件产品整体目标上的风险。与Google的其他大多数技术岗位一样，TE的工作涉及到一些编程，但编程只是一小部分，实际上，在所有工程师中他们的职责范围堪称最广。TE对产品的贡献很大，但他们承担的很多任务不需要编程（注：这只是通常的说法。许多TE所从事的工作与SET非常类似，需要编写大量的代码，而另外一些TE的职责更类似发布工程师，只需要编写很少量的代码）。
Google的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力。
TE的职位描述是最难定义的，因为其职责范围很广而且不确定。人们期望TE在各种各样的构建物的完成、集成、最终形成完整的产品过程中监督所有产物的质量。因此，大多数的TE都会从事一些基础技术层的、需要另外一种视角和较强的专业技术能力的工作。这一切都与风险有关：TE以对某种特定的产品最合适的方式发现软件中风险最大的地方并尝试减少或消除它。如果需要做SET的工作，TE就去做；如果需要代码审查，那就只管去做。如果缺少测试工具，那就花一些时间在上面。
接下来，同一个人还会在项目的其他时段去领导探索式测试，或者管理内部试用版（或beta版）的测试工作。在不同的项目阶段，SET和TE的重点不同，早期的工作涉及到更多的面向SET的任务，而项目后期才是面向TE的任务。还有一些情况是TE的个人选择，他们可以在不同的角色间切换。但凡事没有绝对，我们在下面所做的描述，只是代表了理想的情况。
在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，TE通常没有太多的工作可做。
当TE进入产品的时候，并不需要从零开始。SWE和SET已经在测试技术和质量方面做了大量的工作，可以作为TE的起点。TE在进入产品时，需要考虑以下一些问题。
- 当前软件的薄弱点在哪里？
- 有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？
- 主要用户场景是否功能正常？对于全世界不同国家的用户都是这样么？
- 这个产品能与其他产品（软件和硬件）互操作吗？
- 当发生问题的时候，是否容易诊断问题所在？
当然这只是一个不完全列表。所有这些加起来，构成发布待评估软件的风险概要。TE并不需要自己去解决所有这些问题，但必须保证这些问题被解决掉，他们可以请其他人帮忙评估还有多少工作需要去做。TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。在Google，TE是一个团队中全职地负责从整体角度发现产品或服务弱点的唯一角色。因此，与SET相比，TE的工作并不是那么确定。TE会介入项目的各个阶段：从产品的构思阶段到第8个版本，甚至是照看一个已经下线的项目。一个TE同时参与几个项目也很常见，尤其是那些具备安全、隐私或全球化等专门技能的TE。
这个角色需要敏锐的洞察力和领导力，因此很多Google的高级测试经理们都来自于TE。
TE的工作经常需要去打破常规流程。TE可以在任何时间进入项目，必须迅速评估项目、代码、设计和用户的当前状态，然后决定首要的关注点。如果项目刚刚开始，测试计划是第一优先级。有时，TE在产品后期被拉进来帮助评估项目是否可以发布，或者在beta版本发布之前确认还有哪些主要的问题。当TE进入了一个新被收购的应用或缺少相关应用经验的时候，他们经常会先去做一些不怎么需要计划的探索式测试。有时，项目已经很久没有发布了，只是需要去做一些修饰、安全补丁或界面更新，这需要迥然不同的方法。
在Google，TE需要在不同的项目中做不同的事情。我们经常将TE的工作描述为"从中间开始（starting in the middle）"，因为TE必须保持足够的灵活，能够迅速融入一个产品团队的文化和现状。如果做测试计划已经来不及了，那就干脆不做了。如果一个项目最需要的是测试，那就做一个简单够用的指导性计划。一些测试教条所倡导的从头就介入的模式，在Google并不适用。
下面是我们关于TE职责的一般性描述。
- 测试计划和风险分析；
- 评审需求、设计、代码和测试；
- 探索式测试；
- 用户场景；
- 编写测试用例；
- 执行测试用例；
- 众包（译注：crowdsourcing，是互联网带来的新的生产组织形式。一个公司或机构把过去由员工执行的工作任务，以自由自愿的形式外包给非特定的（通常是大型的）大众网络的做法）；
- 使用统计；
- 用户反馈。
测试人员要处理的是真正的文档和其他临时性的事物。在项目的早期阶段，测试人员编写测试计划；然后，他们创建和执行测试用例，编写bug报告；接下来是准备覆盖度报告，收集用户满意度和软件质量数据。在软件成功发布（或失败）之后，很少有人会问及测试产物是什么。如果软件深受人们喜爱，大家就会认为测试所作所为是理所应当的；如果软件很糟糕，人们可能就会质疑测试工作。但其实也没人真正想去了解测试到底做了什么。
测试计划是最早出现、最先被遗忘的测试产物。
下面是我们希望测试计划具有的一些特性。
- 及时地更新。
- 描述了软件的目标和卖点。
- 描述了软件的结构、各种组件和功能特性的名称。
- 描述了软件的功能和操作简介。
从纯粹测试的角度看，我们担心的是测试计划的投入和价值产出是否匹配。
- 不必花过多的时间去撰写，必须随时可以被修改。
- 应该描述必测点。
- 应该能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足。
ACC（Attribute Component Capability，即特质、组件、能力。这是一种测试计划的替代方法，参见http://googletesting.blogspot.com/2011/10/google-test-analytics-now-in-open.html）可以做测试计划的替代。
特质是系统的形容词，代表了产品的品质和特色，是区别于竞争对手的关键。
源码工具：一系列用于简化创建工作环境、提交代码变更、代码风格检查的工具。可以用工具浏览数亿万行的代码，发现并预防重复的代码。还有用于建立大规模索引和代码重构的工具。
开发工具：集成开的发环境的一些插件，让其他各种工具适应google的代码并连接后端的云服务。代码审查工具，通过在审查阶段嵌入相关的信号，来快速完成高质量的代码审查。
构建框架：构建系统支持自动式，交互式，可以把原本需要数小时的任务缩短到数秒
测试基础架构：规模化的持续集成，开发人员的每次代码提交都会引发自动测试；另一方面是规模化的web测试，每个google产品都会启动数十万个浏览器会话，对各种不同的浏览器平台组合进行测试。
本地化工具
度量，可视化和报表：管理所有产品的bug，跟踪所有研发活动中工程师的各项指标。
技能、稀缺性、自动化和迭代集成。
参考资料
- 讨论 钉钉群21745728 qq群144081101 567351477
- 本文最新版本地址
- 本文英文原版书籍
- 本文源码地址
- 本文涉及的python测试开发库 谢谢点赞！
- 本文相关海量书籍下载
