前言

• 前段时间老大让我在团队进行一次技术分享，这也是在新公司的第一次分享，想起之前在社区分享过那个客户端并发自动化测试小框架，那就拿它来说一下吧，本来的主题是想介绍一下小框架的实现原理和使用方法，后面想想不太对，写 ppt 的时候特意看了一下自己以前写过的技术帖，发现自己过去只是给大家分享我的工具怎么用，我的工具怎么实现的，但是好像没说或具体说过我为什么要做这些工具，后面，我把 ppt 的主题改了一下，改成了测试设计与分析， 工程化的流程大部分朋友都应该了解过，结合实际工作上的情况，我简单地总结为下图：
• 有了解过少部分同行，在开发测试工具，或者做测试方案，比较多的时候会直接想到什么就敲什么代码，想到什么坑就填什么坑，但是这样或许会带来越来越多的坑，做出来的东西也未必会满足原本在测试工作上的需求，甚至脱离原本的需求，没有合理的方案去治疗测试工作上的痛点，工作效率以及品质管理的水平是得不到有效提升的，测试工具或测试方案，其实可以作为一个工程，既然是工程，它必然会遵循上图的流程，也就是说我们可以把测试用工程化的方式进行分析，设计以及实现落地，同时它也是一个产品，产品最主要的作用就是满足需求，测试人员就是需求的来源，最终的目的就是在测试工作上服务测试人员，促进生产力以提升产品质量，所以在以往的一些技术设计当中，我会按照这样的套路来做方案，有清晰地分析和设计，才能有高可用的方案落地，授人以鱼不如授人以渔，这次分享一下我设计测试工具或测试方案的一些工程化的想法

测试工程化

一、测试需求分析

• 百度 测试道路上均安装了明显的自动驾驶测试路段指示标识，自动驾驶测试车辆上也统一张贴醒目的自动驾驶测试车身标识，便于公众识别。

  以并发自动化框架为例，随着业务的增长，自动化测试用例的数量也会随之增加，最明显的问题就是自动化测试执行的时间会越来越长，这个是自动化测试中遇到的一个很普遍的痛点，为了解决这个痛点，当时提出要做并发自动化测试，当然，东西要落地，还是需要论证的：

• 提高执行效率和收益：

  • 1、减少自动化测试的执行时间
  • 2、单位时间的测试过程可以覆盖更多的测试环境和测试范围
  • 3、可以满足某些特定场景的测试需求，比如多机互动
  • 4、........

• 但同时也会带来成本：

  • 1、环境资源成本
  • 2、项目成本
  • 3、维护成本
  • 4、.........
    

• 好了，结合我们的业务，满足做自动化测试的条件的项目有两个移动端和一个网页端，于是，我们就罗列出测试需求：

  • 1、使用操作相对简单，无 coding 基础也可以很快上手
  • 2、可以在 Mac 上 iOS、Android 和 Web 以及在 Win 上 Android 和 Web 的自动化测试
  • 3、可以多台真机或模拟器或多个浏览器同时执行自动化测试
  • 4、或许还有其他隐藏的需求………..

• 结合分析上述的需求，我们提出了这次测试工程的目标：用一句命令将整个并发自动化测试的过程执行起来，有了目标之后，下一步就可以进行测试设计了

二、测试设计

• 以上述的目标，我们需要设计一些方案来满足目标和需求，为了实现目标，有两个要素：技术选型和怎么用技术。对于技术选型，无非就是选取某种语言或某些框架等，怎么用，那就是一些设计方案，比如：

1、技术选型：

• 有了上面的技术选型之后，以技术作为元素，开始做要满足需求的设计方案

2、设计方案：

• 方案是为了满足需求和目标而设计的，但方案本身也来会带来需求或难点，为实现上面的一些方案，我们还需要解决一些主要问题

3、难点解决方案：

• 当然，对于方案自身还有其他亮点我们也可以一一攻破：

  • 1、自定义使用端口范围
  • 2、appium、selenium-grid 服务检查
  • 3、Docker 测试环境自动构建
  • 4、还有很多.........

• 有了上面的方案设计，能够清晰地指引我们如何去实现一个测试框架来满足我们对并发自动化测试的需求

三、测试实现和落地

• 通过设计以后，我们能够清晰地得到框架的架构图，这也是我们要实现的东西

• 对于移动端
  

• 对于 Web 端
  

• 这两幅图在帖子 1:Web 应用并发自动化测试和帖子 2:两句命令实现移动端并发自动化测试也有，具体的实现在文章中也有详细的讲到，其实帖子 1 就是帖子 2 的雏形，帖子 2 将移动端和 Web 端都整合起来得以实现（具体可以看帖子 2 下的更新评论），其落地的效果在帖子中也提到过，套路基本上是这样子，以工程化的模式，带点产品的思维来实现测试工具和测试方案

四、测试维护

• 在工具或方案实现落地之后，随着技术的升级以及业务的变化，测试业务和测试人员需求也会随之改变，所以要适时地调整维护升级已经落地执行的工具或方案，当然这也是需要把握一定的范围，比如技术升级，必须了解清楚技术的变动范围，盲目的升级会降低方案或工具可持续运行的能力，业务方面要把握工具或方案的定位，比如框架是做客户端并发自动化测试的，但不能因为具备并发的能力，就说要加上服务端性能测试的功能或其他的，这样也违背产品定位的原则，维护也是要有目的，维护是为了在保持原有的定位下将提高对需求以及需求提出人员的服务能力，所以再次按照上述的套路，实现满足需求的方案，一个工程化的闭环才得以完成

扩展

• 上文以一个工具或框架为例子，对于测试方案，这里就简单扩展一下，如灰度测试，灰度测试的需求更多地是我们怎么才能充分地去覆盖我们所期望带来价值的业务，保证其质量达标，满足生产经营的标准，我们也可以用工程化的思想，明确需求之后进行设计，要解决两个范围的需求：业务范围和用户范围。比如为了有效地覆盖业务范围，我们可以选取用户粘度和用户画像相对接近业务的用户范围，通过对这部分用户的灰度，通过 nginx 或 diffy 等数据引流方案以及服务隔离等方案，实现落地收集其使用的数据通过大数据处理方案等加以分析，最后论证业务解决需求痛点的程度以及得到新的需求，这也是一个从提出需求到设计到落地到最后得到新需求继续维护的过程，也就是工程化的闭环，百变不离其中

总结

• 从拿到需求，到分析需求，到方案设计，到实现落地，这都是很基本的工程化的套路，总的来说就是我们要清楚我们的目标是什么，要解决什么问题，用什么办法解决，最后得到什么价值，测试工程是一项庞大的工程，本文只是以一个测试工具的实现来简单概括工程化的模式，其实在产品研发乃至线上生产，每一个环节都需要测试工程化的支撑
• 我们之所以叫做测试工程师，不是因为我们会找 bug 或会写代码，是因为测试工程师能够将测试工作甚至是质量保障工作，以工程化的形式来支撑产品或项目能够持续经营，一套高可用的工具或方案的实现离不开工程化的模式
• 最近买了一本新书，里面也提到 测试=工程效率 + 品质管理，通俗地说就是，提高团队工作效率，提升产品业务质量，之前总是有同行说不清楚测试人员的价值所在，那现在就请重新审视一下吧，测试工程师在团队里面是很重要，很重要，很重要的。结合工程化的思想，为这两个核心服务，测试人员是互联网时代一个不可缺失的重要角色，前人总结的经验总是有用的，如果大家觉得这种套路在测试工作中有起到一点帮助的话，那非常好，如果有同行有更好的想法或其他方案，也欢迎一起讨论研究，谢谢