摘要

最近在阅读《Google 软件测试之道》这本书。书的前三章详细介绍了软件开发工程师、测试开发工程师和测试工程师。阅读后想要结合我们实际工作情况谈谈我的理解。文章会先介绍 Google 中的研发流程,测试和测试开发的工作内容。然后根据实际工作中的各种情况,聊一聊测试和测试开发在研发中的角色定位。


PartI Google 研发

在理想情况中,测试与开发的工作是同时进行的。甚至开发人员在便在代码时就会思考如何测试他的代码:数据取值范围、导致代码循环超出限制等情况。对于人的思维方式而言,编写功能代码和编写测试代码是迥然不同的两种逻辑思维,因此我们需要有功能开发人员(Feature Developer)和测试开发人员(Test Developer)。前者的思维模式是创建,即重点关注数据流向、功能实现上;而后者重点考虑如何通过代码的方式破坏工程代码的运行。除了代码层面以外,需要有一个角色站在用户层面的角度去考虑功能实现的价值。

在 Google 中有三种角色对应以上的描述:

下面举一个例子方便大家理解这三者的工作。

假设有一个登录页面,它的功能是让用户输入账号、密码和验证码,同时勾选《产品注册/登录协议》即可登录网站。

这个功能至少分成两个部分:前端服务 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% 时间里诞生;完备的代码审查机制。

而对于机制相对不完善的中小企业来说,保障功能快速上线是主要矛盾。能够在日常迭代任务的间隙,做好测试资产、技术沉淀是次要矛盾。因而大量的测试人员投入在了功能保障环节。但是,随着产品功能的膨胀、系统复杂度的提高,单纯的功能测试已经不满足需求,继而出现了测试开发人员。测试开发应从熟悉当前工作流中痛点的功能测试人员转换。他们应该熟悉被测系统,熟悉工作中哪些内容可以使用技术手段解决。就这个角度来看,对于我们个人来说要在完成日常工作的同时,注重自己的技术水平提升,同时关注业界时下正在讨论的问题,多实践多思考。

展望未来,相信我们的产研体系会越来越成熟。测试开发会在质量保障工作中占据绝大部份工作,功能测试工作也会越来越简约。通过技术手段解决重复、复杂的工作,同时将测试结果反馈研发端,提升整体产研效率。


↙↙↙阅读原文可查看相关链接,并与作者交流