开发要不要⾃⼰做测试？怎么做？
selenium怎么使用现在包括Google、Facebook 和eBay 等⼀线互联⽹巨头公司都在逐渐推⾏“没有专职测试，测试⼯作由开发⼈员完成”的全新模式，原本专职的业务功能测试团队的规模逐渐缩⼩，有些甚⾄已经完全没有了，⽽原本的测试开发团队逐渐在向⼯程效能（Engineering Productivity）团队转型。这些互联⽹巨头之所以能够很好地落地这种全新的模式，是因为他们都较好地解决了这个模式的两个最⼤的难题：
开发⼈员如何能够胜任测试？
⼯程效能团队如何赋能开发⼈员，帮助开发⼈员⾼效地完成⾼质量测试？
本⽂会围绕这两个问题来展开讨论。⾸先让我们⼀起看⼀下开发⼈员⾃⼰做测试都会遇到哪些问题和阻碍。
1开发⼈员⾃⼰做测试会遇到哪些问题 ⼈性⾓度引发的问题
⾸先从⼈性的⾓度来看，开发⼈员通常是属于“创造性思维”，⾃⼰开发的代码就像是亲⼉⼦⼀样，怎么看都觉得实现很棒；⽽测试⼈员则属于“破坏性思维”，测试⼈员的职责就是要尽可能多的到潜在的缺陷，⽽且专职的测试⼈员通常已经在以往的测试实践中积累了⼤量典型的容易出错的模式，所以测试⼈员⽐起开发⼈员，往往更能客观且全⾯做好充分的测试。
思维惯性的问题
刚才是从⼈性⾓度上来讲的，如果从技术层⾯来看，由开发⼈员⾃⼰测试，会存在严重的“思维惯性”，通常开发⼈员在设计和开发过程中没有考虑到的分⽀和处理逻辑，在⾃⼰做测试的时候同样不会考虑到。⽐如对于⼀个函数，其中有⼀个 String 类型的输⼊参数，如果开发⼈员在做功能实现的时候压根没有考虑到 String 存在 Null 值得可能性，那么代码的实现⾥⾯也不会对 Null 值做处理，连带结果就是测试的时候就更不会设计Null 值得测试数据，这样的“⼀条龙”缺失就会给代码的质量留下了缺陷隐患。更糟糕的是，对于这种情况，即便启⽤了代码覆盖率指标去衡量测试完整程度，也不能有效暴露这类问题，因为处理 Null 值得代码压根没有写，⼜何来代码覆盖率⼀说呐。
被测试环境和测试执⾏环境的复杂性问题
有专职测试的时候，测试⼯作是专职测试⼈员完成的，专职测试⼈员通常会负责搭建被测试环境以及管理测试执⾏环境。被测试环境好理解，就是 System Under Test（SUT）。⽽测试执⾏环境是指⽤于执⾏测试⽤例的机器，⽐如对于 Web 的 GUI 测试，最简单的测试执⾏环境就是你本地机器上的浏览器。但是对于⼤型互联⽹企业，测试执⾏环境远远要⽐你想象的更复杂。通常都是⼀些⼤型的测试执⾏集，甚⾄是内部的测试执⾏私有云，⽐如⽤Selenium Grid 搭建的GUI 测试执⾏环境，往往这样的集都会有成百上千台机器，再⽐如⽤Appium+Selenium Grid 搭建的移动设备测试集，也往往会
有上千台设备。现在没有了专职的测试⼈员，那就需要开发⼈员⾃⼰去管理、维护和搭建这些测试基础架构，这样做其实是得不偿失的，⼯作量本⾝并没有减少，只是换了⼀批⼈来做同样的事情，⽽且开发的精⼒往往更应该花在构建新的业务功能上，⽽不是⽤在维护测试基础设施。
测试数据准备的问题
测试数据准备是测试过程中必不可少的关键步骤，有专职测试的时候，是由测试⼈员来准备测试数据的，⼀⽅⾯测试⼈员往往⽐开发⼈员在全局层⾯上更了解被测系统，所以对于测试数据的设计与⽣成也会更⾼效，另⼀⽅⾯测试⼈员在以往的测试过程中已经积累了很多测试数据⽣成的⽅法和⼩⼯具。现在这些都需要开发⼈员⾃⼰来完成了，⽆疑进⼀步加⼤了开发⼈员的⼯作量，⽽且开发⼈员往往对跨模块，跨系统的测试数据准备缺乏系统性的理解，往往为了⽣成⼀条⾮⾃⼰业务领域的数据⽽花费⼤量的学习成本。举个例⼦，假设现在“买家模块”的开发⼈员需要测试“商品买⼊”的操作，那么就需要事先准备好“可以被卖的商品”，这就意味着“买家模块”的开发⼈员需要明确知道“卖家模
块”和“商品模块”的细节，才能⽣成“可以被卖的商品”。这类问题在⽬前主流的微服务架构⾯前会更严重，原因是为了产⽣⼀条测试数据，可能会需要依次调⽤很多个服务。
测试执⾏与 CI/CD 集成问题
对于不同的业务开发团队，各个阶段采⽤的⾃动化测试框架可能都不同，⽐如有些会使⽤基于Java 的Selenium，也有些会使⽤基于JavaScript 的 Nightwatch 等，有专职测试的时候，各种不同的测试框架与 CI/CD 的集成，都是由各个业务团队的测试⼈员和 CI/CD 的⼈员⼀起完成的，现在没有了专职测试，这部分⼯作就需要开发⼈员⾃⼰和 CI/CD ⼈员⼀起完成，这就要求开发⼈员不仅需要⾮常熟悉⾃动化测试框架的细节（很多时候为了更好地和 CI/CD 集成，会对开源测试框架或者是⾃研测试框架做⼆次开发，⽐如改进 retry 机制，增加覆盖率统计等等），还必须了解 CI/CD 的流⽔线设计以及脚本设计，然后再将需要⽀持的⾃动化测试框架的运⾏命令⾏和需要暴露的参数（测试⽤例 Git 路径、测试执⾏环境、测试报告路径等等）写进 CI/CD 的脚本。这些⼯作在很⼤程度上分散了开发的精⼒，对于提⾼开发⾃⾝效率是⾮常不利的。
失败测试⽤例归属问题
有专职测试的时候，开发⼈员往往只关注⾃⼰修改部分相关的测试⽤例，模块或者服务的全回归测试中如果有失败的测试⽤例，通常是由测试⼈员跟进去分析具体原因，并协调解决然后才能发布上线。但是现在开发⼈员负责所有测试，他就必须关注全局的测试。举个实际的例⼦来看，⽐如“⽤户登录”服务的开发⼯程师修复了⼀个缺陷，然后本地⾃测通过后递交了代码，然后很不幸，在CI/CD 的流⽔线上全回归测试却发现有部分⽤例失败了，虽然这些失败的⽤例和这次的代码修改没有任何关系，但是为了保证⾃⼰的修改能够顺利上线（CI/CD 的流⽔线要求只有全回归测试 100% 通过才可以上线），
他必须挨个去分析失败的测试⽤例然后⾃⼰去到对应的⼈去协调解决，这显然是⾮常不合理和不敏捷的做法。
归根结底，这些问题的本质都会直接影响开发⼈员本质⼯作的进度和效率，那么我们应该如何解决或者在⼀定程度上缓解这些问题呢？这就是接下来要讨论的问题，⼯程效能团队如何赋能开发⼈员，帮助开发⼈员⾼效地完成⾼质量的测试。
2⼯程效能团队赋能开发⼈员进⾏⾼效率⾼质量的测试
赋能的基本思路是能够让开发⼈员更专注于测试本⾝，⽽从那些辅助测试的⼯作（⽐如搭建测试执⾏环境、CI/CD 集成等）上解放出来，这些辅助测试的⼯作由“⼯程效能”服务或者相关⽀持⼯具链来统⼀解决。这个思想和和⽬前⾮常流⾏的Service Mesh 的设计思想不谋⽽合，Service Mesh 也是可以让服务的开发⼈员可以把所有的精⼒集中在业务功能的实现上，⽽不需要去关⼼服务间通信的基础设施，像类似于服务的注册与发现，熔断机制等都会统⼀由 Service Mesh 以对业务应⽤透明的⽅式来实现。这些“⼯程效能”服务或者相关⽀持⼯具链通常都会由原本从测试开发转型过来的⼯程效能团队来设计和开发。那么我们接下来看⼀下可以提供哪些“⼯程效能”服务或者相关⽀持⼯具链，并且能以什么样的⽅式来解决或缓解上⾯提到的开发⾃⼰测试带来的问题。
测试执⾏服务（Test Execution Service）
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 以及配置、测试的具体执⾏环境、测试报告获取等信息。这将⼤⼤提⾼开发⼈员⾃⼰执⾏测试的效率和便利程度。
测试数据服务（Test Data Service）
前⾯提到过，跨模块，跨系统的测试数据准备对于开发⾃⼰做测试是个挑战，尤其是现在⼤量采⽤微服务架构，这个问题就会更突出。测试数据服务（TDS，Test Data Service）将会以Web Service 接⼝的形式为所有类型的测试提供⼀致的测试数据准备⼊⼝。⽆论开发是要做API 测试，还是 GUI 测试，或者是性能测试，都可以通过调⽤ TDS 的 Web Service 或者 UI 来准备各种组合类型和量级的测试数据。TDS 本⾝还是个开发平台，任何开发⼈员都可以通过脚⼿架代码来贡献新的数据类型⽀持，
并且 TDS 平台本⾝借助⾃⼰的 Core Service 和内建数据库具有元数据管理能⼒，能够提供诸如测试数据数量以及质量的管理。下图展⽰了典型的 TDS 架构设计简图供参考。
测试执⾏环境服务（Test Bed Service）
正如前⾯提到的，测试执⾏环境对于⼤型企业来说是很庞⼤复杂的，为了⽅便开发⼈员使⽤测试执⾏环境，或者说为了使测试执⾏环境对于开发⼈员透明，就需要引⼊测试执⾏环境服务（TBS，Test Bed Service）。TBS 的主要职责是负责管理、创建，扩容/ 收缩测试执⾏集。⼀个常见的测试执⾏环境架构如下图所⽰，TBS 会根据等待执⾏的测试⽤例的排队情况，动态决策测试执⾏集的节点数量和类型，通常会使⽤ Docker 和 Kubernetes 来实现 TBS 的 Gird 管理。
构建⼯程效率⼯具链仓库（Engineering Productivity Tools Store）
类似于App Store 的概念，可以把各种测试⼩⼯具以及提⾼效率的⼯具集统⼀在Engineering Productivity Tools Store ⾥⾯集中版本化管理。⽐如⽂章开头我们提到过开发⾃⼰做测试的时候存在思维盲区，对于像String 这样的参数可能遗漏Null 值得⽤例，我们就可以开发⼀个⼩⼯具对被测函数的输⼊参数类型基于边界值⾃动⽣成边界测试⽤例，⽐如String 类型的参数⼀定会⽣成Null，SQL 注⼊攻击字符串，⾮英⽂字符，超长的字符串等，这样就可以系统性地避免开发的盲区。诸如此类的⼯具还有很多，以后有机会再和⼤家⼀⼀分享。
3测试即服务（TaaS，Test as a Service）的全局架构
除了以上的内容，其实还有诸如测试报告服务（TRS，Test Report Service）、全局测试配置服务（GRS，Global Registry Service）和⽤于 API 测试解耦的 Mock 服务（Unified Mock Service），由于篇幅⽆法⼀⼀展开。需要强调是的是，这⾥谈到的很多服务已经在某些企业内部有了落地实践，并取得了很好地效果。最后，以 Test as a Service 的全局架构图来结束本⽂。
作者介绍
茹炳晟，eBay 中国研发中⼼测试基础架构技术主管，先后任职于 HP 软件中国研发中⼼、阿尔卡特朗讯、Cisco 中国研发中⼼等公司。
免责声明：本⽂系⽹络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并⽀付稿酬或者删除内容。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。