现在包括 Google、Facebook 和 eBay 等一线互联网巨头公司都在逐渐推行“没有专职测试,测试工作由开发人员完成”的全新模式,原本专职的业务功能测试团队的规模逐渐缩小,有些甚至已经完全没有了,而原本的测试开发团队逐渐在向工程效能团队转型。 这些互联网巨头之所以能够很好地落地这种全新的模式,是因为他们都较好地解决了这个模式的两个最大的难题:开发人员如何能够胜任测试? 工程效能团队如何赋能开发人员,帮助开发人员高效地完成高质量测试? 本文会围绕这两个问题来展开讨论。首先让我们一起看一下开发人员自己做测试都会遇到哪些问题和阻碍。 首先从人性的角度来看,开发人员通常是属于“创造性思维”,自己开发的代码就像是亲儿子一样,怎么看都觉得实现很棒;而测试人员则属于“破坏性思维”,测试人员的职责就是要尽可能多的找到潜在的缺陷,而且专职的测试人员通常已经在以往的测试实践中积累了大量典型的容易出错的模式,所以测试人员比起开发人员,往往更能客观且全面做好充分的测试。 思维惯性的问题 刚才是从人性角度上来讲的,如果从技术层面来看,由开发人员自己测试,会存在严重的“思维惯性”,通常开发人员在设计和开发过程中没有考虑到的分支和处理逻辑,在自己做测试的时候同样不会考虑到。 被测试环境和测试执行环境的复杂性问题 有专职测试的时候,测试工作是专职测试人员完成的,专职测试人员通常会负责搭建被测试环境以及管理测试执行环境。被测试环境好理解,就是 System Under Test(SUT)。 而测试执行环境是指用于执行测试用例的机器,比如对于 Web 的 GUI 测试,最简单的测试执行环境就是你本地机器上的浏览器。但是对于大型互联网企业,测试执行环境远远要比你想象的更复杂。 测试数据准备的问题 测试数据准备是测试过程中必不可少的关键步骤,有专职测试的时候,是由测试人员来准备测试数据的,一方面测试人员往往比开发人员在全局层面上更了解被测系统,所以对于测试数据的设计与生成也会更高效,另一方面测试人员在以往的测试过程中已经积累了很多测试数据生成的方法和小工具。 现在这些都需要开发人员自己来完成了,无疑进一步加大了开发人员的工作量,而且开发人员往往对跨模块,跨系统的测试数据准备缺乏系统性的理解,往往为了生成一条非自己业务领域的数据而花费大量的学习成本。 测试执行与 CI/CD 集成问题 对于不同的业务开发团队,各个阶段采用的自动化测试框架可能都不同,比如有些会使用基于 Java 的 Selenium,也有些会使用基于 JavaScript 的 Nightwatch 等,有专职测试的时候,各种不同的测试框架与 CI/CD 的集成,都是由各个业务团队的测试人员和 CI/CD 的人员一起完成的,现在没有了专职测试,这部分工作就需要开发人员自己和 CI/CD 人员一起完成,这就要求开发人员不仅需要非常熟悉自动化测试框架的细节(很多时候为了更好地和 CI/CD 集成,会对开源测试框架或者是自研测试框架做二次开发。 失败测试用例归属问题 有专职测试的时候,开发人员往往只关注自己修改部分相关的测试用例,模块或者服务的全回归测试中如果有失败的测试用例,通常是由测试人员跟进去分析具体原因,并协调解决然后才能发布上线,但是现在开发人员负责所有测试,他就必须关注全局的测试。 赋能的基本思路是能够让开发人员更专注于测试本身,而从那些辅助测试的工作(比如搭建测试执行环境、CI/CD 集成等)上解放出来,这些辅助测试的工作由“工程效能”服务或者相关支持工具链来统一解决。 这些“工程效能”服务或者相关支持工具链通常都会由原本从测试开发转型过来的工程效能团队来设计和开发。那么我们接下来看一下可以提供哪些“工程效能”服务或者相关支持工具链,并且能以什么样的方式来解决或缓解上面提到的开发自己测试带来的问题。 测试执行服务 CI/CD 各个阶段所有的测试执行发起都通过测试执行服务(TES,Test Execution Service),TES 通过统一的 Web Service 接口与 CI/CD 以解耦的方式进行集成。 无论是 CI/CD 流水线,还是开发人员执行测试,都通过 TES 来发起,唯一的区别是开发人员一般使用 TES 的 UI 界面发起测试,而 CI/CD 是直接在流水线脚本里面调用 TES 的 Restful API 发起测试。 测试执行服务的输入参数也很简单直观,通常只包括测试框架名字、测试用例集版本号、测试用例路径、 测试报告获取方式、同步 / 异步执行开关等。 一旦调用 TES 发起测试,后续如何调用 Jenkins job、如何打包下载 test jar、如何找到适合的测试执行环境、如何发起测试以及如何收集测试报告等都对使用者完全透明。 可以想象,现在,开发人员在和 CI/CD 集成以及执行测试的时候,已经可以完全不需要去关心执行测试的命令行、发起测试的 Jenkins job 以及配置、测试的具体执行环境、测试报告获取等信息。这将大大提高开发人员自己执行测试的效率和便利程度。 测试数据服务 前面提到过,跨模块,跨系统的测试数据准备对于开发自己做测试是个挑战,尤其是现在大量采用微服务架构,这个问题就会更突出。测试数据服务将会以 Web Service 接口的形式为所有类型的测试提供一致的测试数据准备入口。 无论开发是要做 API 测试,还是 GUI 测试,或者是性能测试,都可以通过调用 TDS 的 Web Service 或者 UI 来准备各种组合类型和量级的测试数据。 测试执行环境服务 正如前面提到的,测试执行环境对于大型企业来说是很庞大复杂的,为了方便开发人员使用测试执行环境,或者说为了使测试执行环境对于开发人员透明,就需要引入测试执行环境服务(TBS,Test Bed Service)。 TBS 的主要职责是负责管理、创建,扩容 / 收缩测试执行集群。一个常见的测试执行环境架构如下图所示,TBS 会根据等待执行的测试用例的排队情况,动态决策测试执行集群的节点数量和类型,通常会使用 Docker 和 Kubernetes 来实现 TBS 的 Gird 管理。 构建工程效率工具链仓库 类似于 App Store 的概念,可以把各种测试小工具以及提高效率的工具集统一在 Engineering Productivity Tools Store 里面集中版本化管理。 除了以上的内容,其实还有诸如测试报告服务(TRS,Test Report Service)、全局测试配置服务(GRS,Global Registry Service)和用于 API 测试解耦的 Mock 服务(Unified Mock Service),由于篇幅无法一一展开。 需要强调是的是,这里谈到的很多服务已经在某些企业内部有了落地实践,并取得了很好地效果。最后,以 Test as a Service 的全局架构图来结束本文。
下一篇没有文章了!