摘要
最近在阅读《Google 软件测试之道》这本书。书的前三章详细介绍了软件开发工程师、测试开发工程师和测试工程师。阅读后想要结合我们实际工作情况谈谈我的理解。文章会先介绍 Google 中的研发流程，测试和测试开发的工作内容。然后根据实际工作中的各种情况，聊一聊测试和测试开发在研发中的角色定位。
PartI Google 研发
在理想情况中，测试与开发的工作是同时进行的。甚至开发人员在便在代码时就会思考如何测试他的代码：数据取值范围、导致代码循环超出限制等情况。对于人的思维方式而言，编写功能代码和编写测试代码是迥然不同的两种逻辑思维，因此我们需要有功能开发人员（Feature Developer）和测试开发人员（Test Developer）。前者的思维模式是创建，即重点关注数据流向、功能实现上；而后者重点考虑如何通过代码的方式破坏工程代码的运行。除了代码层面以外，需要有一个角色站在用户层面的角度去考虑功能实现的价值。
在 Google 中有三种角色对应以上的描述：
SWE（SoftwareEngineer）：功能开发工程师，负责客户使用的功能模块开发以及这些功能代码的单元测试。
SET（SoftwareEngineer In Test）：测试开发工程师，负责在单元测试中给 SWE 提供支持、为 SWE 提供测试框架，方便他们进行中小型测试。
TE（TestEngineer）：测试工程师，负责从用户的角度来思考质量问题。
下面举一个例子方便大家理解这三者的工作。
假设有一个登录页面，它的功能是让用户输入账号、密码和验证码，同时勾选《产品注册/登录协议》即可登录网站。
这个功能至少分成两个部分：前端服务 loginFrontend 和后端服务 loginService。后端服务接受前端服务的请求，检查数据是否有错误，并与数据持久层交互。
SET 需要使用 GoogleProtocolBuffer 描述性语言定义 loginService 协议。如
message LoginRequest {
required string url = 1;
optional string comment = 2;
}
message LoginReply {
optional int32 error_code = 1;
optional string error_details = 2;
}
service LoginService {
rpc LoginUrl(loginRequest) return (LoginReply) {
optional deadline = 10;
}
}
该文件定义了 loginRequest 的消息格式、loginReply 的消息格式和 login 远程方法调用服务（RPC）。后续 SWE 就需要根据上述协议进行代码开发、单元测试；同时 SET 开始编写自动化运行程序。待 SWE 前后端调试结束后，执行自动化测试程序。等到单元测试和自动化测试都通过之后，提交代码审查。若代码审查结果需要修改，则重新执行前面的步骤，至代码审查通过。
至此，一个登录模块就已经开发完毕了。可以看到 TE 并没有参与到研发过程中。当 TE 介入时，整个产品已经有了商品模块、购物车模块、订单模块。SWE 和 SET 已经在测试技术和质量方面做了大量工作。TE 们介入后通常考虑以下问题：
当前软件薄弱点在哪里？
有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？
主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？
发生问题时是否容易诊断问题
TE 需要在测试计划及测试完整性上需要更加系统和周密，重点在真实用户的使用方式和系统级别的体验上。
并非所有的产品都需要 TE 介入。试验性工作、目标尚不明确或用户故事处于早期的产品，TE 很少甚至不参与;即使是一个明确要发布的产品，在研发的早期阶段，最终功能列表和范畴还没有确定,TE 通常也没有太多的工作可以做。过早的投入 TE 意味着资源的浪费，尤其是 SET 已经深度介入的时候。
小结：
在 Google 研发流程中，SWE 和 SET 承担了大部分的测试工作。TE 则更关注产品整体层面和用户的体验感受。简单来说：Google 的研发逻辑是先生产椅子腿、椅背、扶手、椅座等零件，这些零件的质量由开发人员和测试开发共同保障。等确定需要生产一个椅子的时候，再由测试工程师介入，看椅子是否舒适、是否牢固等用户体验层的问题。
PartII 我们的产品研发
与 Google 研发逻辑相反，基本所有产品在规划之初就就配齐产品、研发、测试这些角色。即我们在研发开始时就质量保障工作。
产品迭代的初期，为了产品能够迅速上线，通常缺少详细的技术评审、接口文档。架构设计、接口定义往往是口口相传。这个时期功能性需求会非常多且压缩测试的工作时间，比如两周的开发时间，给到测试可能只有 3～5 天。此时测试需要从产品研发流程、文档规范等角度来约束产品和研发，同时沉淀测试资产，包括且不限于测试用例、迭代/性能测试报告、迭代遗留问题等。
产品的成熟期，功能趋于稳定。这个阶段开始，研发开始着手解决以前遗留的技术债务；产品功能开始优化；同时新功能也在不断的开发。回归测试可能占据了测试人员日常工作中的大部分。但是庞大复杂的产品功能导致测试的回归工作量成倍的增加。这时候需要一个角色，将重要的测试用例转换成自动化测试用例。同时，测试数据构造难的问题也显现。一个涉及新用户的场景，每个用例都需要手动注册新用户，产生了大量重复劳动时间，因此开始考虑使用脚本批量生成数据；运营设计的每一次活动，对产品性能提出了更高的要求，因而压测从以往的单模块压测转向了全链路压测。
所以在这个阶段中，测试开发的重要性越来越高。测试开发需要非常熟悉业务逻辑、熟悉产品架构设计。他需要实现一些工具来解决测试在工作中的难题，如线上数据监控；他需要编写自动化测试用例来减少测试的重复劳动；他需要与研发讨论性能测试方案，解决诸如埋点监控、日志回放、数据染色等技术问题。
PartIII 总结
Google 中的研发逻辑要求有完备的基础设施建设。例如他们共享所有代码库，所有人都可以往代码库提交代码（只要通过审查）因此有大量的工具保证质量工作；他们每周可以有 20% 做探索式工作，很多产品、工具往往在这 20% 时间里诞生；完备的代码审查机制。
而对于机制相对不完善的中小企业来说，保障功能快速上线是主要矛盾。能够在日常迭代任务的间隙，做好测试资产、技术沉淀是次要矛盾。因而大量的测试人员投入在了功能保障环节。但是，随着产品功能的膨胀、系统复杂度的提高，单纯的功能测试已经不满足需求，继而出现了测试开发人员。测试开发应从熟悉当前工作流中痛点的功能测试人员转换。他们应该熟悉被测系统，熟悉工作中哪些内容可以使用技术手段解决。就这个角度来看，对于我们个人来说要在完成日常工作的同时，注重自己的技术水平提升，同时关注业界时下正在讨论的问题，多实践多思考。
展望未来，相信我们的产研体系会越来越成熟。测试开发会在质量保障工作中占据绝大部份工作，功能测试工作也会越来越简约。通过技术手段解决重复、复杂的工作，同时将测试结果反馈研发端，提升整体产研效率。