软件测试 | 角色介绍

为了保证“解铃还须系铃人这”这句话名言成为事实（译注：“you buid it,you bfeaka it”,摘自“you build it, you break”）的问题，只有开发人员自己才能修复。这里的意思是开发人员自己才能修复。 比专职的测试人员更适合做测试工作。在传统的开发岗位之外我们又增加了几种角色。我们明确地提出了有一种工程师角色必须存在，他可以让开发人员更加有效率和质量意识。这些角色常把他们自己看做是测试者，但实际上他们的使命是提高生产率。测试人员的存在是为了让开发人员的工作更有效率，并且很大一部分体现在避免因马虎粗心而导致的返工，因为，质量也效率的一部分。

软件开发工程师（SWE）

软件开发工程师（译注:software engineer,后文简称 SWE）是一个传统上的开发角色，他们的工作是实现最终用户所使用的功能代码。他们创建设计文档、选择最优的数据结构和整体架构，并且花费大量时间在代码实现与代码审核上。SWE 需要编写与测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等，这些测试会在本章的后面做详细解释。SEW 会对他们编写、修复以及修改的代码承担责任。假设一个开发者不得不修改一个函数，如果这次修改导致已有测试用例运行失败，或者需要增加一个新的测试用例，他就必须去实现这个测试用例的代码。开发工程师几乎将所有的时间都花费在了代码编写上。

软件测试开发工程师（SET）

软件测试开发工程师（译注：software engineer in test，后文简称 SET）也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。他们参与设计评审，非常近距离地观察代码质量与风险。为了增加可测试性，他们甚至会对代码进行重构，并编写单元测试框架和自动化测试框架。SET 是 SWE 在代码库上的合作伙伴，相比较 SWE 是在增加功能性代码或是提高性能的代码，SET 更加关注与质量提升和测试覆盖率的增加。SET 同样会花费近百分之百的时间在编写代码上，他们这样做的目的是为质量服务，而 SEW 则更关注客户使用功能的开发实现上。

测试工程师（TE）

测试工程师（译注：test enginner,后文简称 TE）是一个和 SET 关系密切的角色，有自己不同的关注点——把用户放在第一位来思考，代表用户的利益。一些 Google 的 TE 会花费大量时间模拟用户的使用场景和自动化脚本或代码的编写上。同时，他们会把开发工程师和 SET 编写的测试分门别类地组织起来，分析、解释、测试运行结果，驱动测试执行，特别是在项目的最后阶段，推进产品发布，TE 是真正的产品专家、质量顾问和风险分析师。某些 TE 需要编写大量的代码，而另外一些 TE 则只用编写少量的代码。

从质量的角度来看，SWE 负责功能实现和这些独立功能的质量。他们对容错设计、故障恢复，通过模拟一个真实的工作运行环境（一个包含 stubs、mock、fake 等方法的流程，这些后面会详细提到）和代码提交队列来管理代码的提交。换句话说，SET 编写代码，通过这些代码提供的功能让 SWE 能够自己测试他们的功能。多数测试代码是由 SWE 完成，SET 存在的目的是保证这些功能模块具有可测试性，并且相对的 SWE 还可以积极地参与到测试代码的编写中去。

很明显，SET 的主要关注对象就是开发人员。SET 的主要职责是让开发者很容易地编写测试代码，从而达到独立功能模块的质量要求。专注于用户角度的测试则是 TE 的职责。考虑到 SWE 和 SET 已经做了足够多的模块级别与功能级别的测试，下一步要考虑的就是要验证这些执行的代码与数据集成在一起之后，是否可以满足最终用户的需求。在这里，TE 扮演者一个双重确认的角色，确认开发人员在测试方面的工作是否到位，任何明显的 bug 都会明确表明早期开发人员所做的测试工作存在不足或比较马虎。当这些明显的 bug 变少时，TE 会把注意力转移到常见用户使用场景中去，是否满足性能期望，在安全性、国际化、访问权限等方面是否满足用户的要求。TE 运行许多测试的同时，也负责和其他图阿奴地的 TE、合同工编制的测试人员、以众包形式参与的测试者、内部尝鲜者、beta 测试者以及早期用户进行合作交流，与各方讨论基本设计带来的风险、功能逻辑复杂性和错误避免的方法。一旦 TE 参与到项目之中，基本上就会没完没了。

搜索微信公众号：TestingStudio 霍格沃兹的干货都很硬核