目录
前言
测试工程化
一、测试需求分析
二、测试设计
三、测试实现和落地
四、测试维护
扩展
前言
-
测试工程化是指将软件测试过程中的各个环节进行自动化和标准化，以提高测试效率、质量和可持续性。在测试工程化中，使用并发自动化框架是一个重要的组成部分。
并发自动化框架可以帮助测试团队实现并发执行测试用例的能力，从而加快测试速度和提高效率。在传统的串行执行测试用例的方式下，测试时间会较长，而并发自动化框架可以同时执行多个测试用例，大大缩短了测试时间。
结合实际工作上的情况，我简单地总结为下图：
- 有了解过少部分同行，在开发测试工具，或者做测试方案，比较多的时候会直接想到什么就敲什么代码，想到什么坑就填什么坑，但是这样或许会带来越来越多的坑，做出来的东西也未必会满足原本在测试工作上的需求，甚至脱离原本的需求，没有合理的方案去治疗测试工作上的痛点，工作效率以及品质管理的水平是得不到有效提升的，测试工具或测试方案，其实可以作为一个工程，既然是工程，它必然会遵循上图的流程，也就是说我们可以把测试用工程化的方式进行分析，设计以及实现落地，同时它也是一个产品，产品最主要的作用就是满足需求，测试人员就是需求的来源，最终的目的就是在测试工作上服务测试人员，促进生产力以提升产品质量，所以在以往的一些技术设计当中，我会按照这样的套路来做方案，有清晰地分析和设计，才能有高可用的方案落地，授人以鱼不如授人以渔，这次分享一下我设计测试工具或测试方案的一些工程化的想法
测试工程化
一、测试需求分析
-
以并发自动化框架为例，随着业务的增长，自动化测试用例的数量也会随之增加，最明显的问题就是自动化测试执行的时间会越来越长，这个是自动化测试中遇到的一个很普遍的痛点，为了解决这个痛点，当时提出要做并发自动化测试，当然，东西要落地，还是需要论证的：
-
提高执行效率和收益：
- 1、减少自动化测试的执行时间
- 2、单位时间的测试过程可以覆盖更多的测试环境和测试范围
- 3、可以满足某些特定场景的测试需求，比如多机互动
- 4、........
-
但同时也会带来成本：
- 1、环境资源成本
- 2、项目成本
- 3、维护成本
- 4、.........
-
好了，结合我们的业务，满足做自动化测试的条件的项目有两个移动端和一个网页端，于是，我们就罗列出测试需求：
- 1、使用操作相对简单，无 coding 基础也可以很快上手
- 2、可以在 Mac 上 iOS、Android 和 Web 以及在 Win 上 Android 和 Web 的自动化测试
- 3、可以多台真机或模拟器或多个浏览器同时执行自动化测试
- 4、或许还有其他隐藏的需求………..
-
结合分析上述的需求，我们提出了这次测试工程的目标：用一句命令将整个并发自动化测试的过程执行起来，有了目标之后，下一步就可以进行测试设计了
二、测试设计
- 以上述的目标，我们需要设计一些方案来满足目标和需求，为了实现目标，有两个要素：技术选型和怎么用技术。对于技术选型，无非就是选取某种语言或某些框架等，怎么用，那就是一些设计方案，比如：
1、技术选型：
| 项目 | 作用 |
|---|---|
| Appium | 移动端支撑 |
| Selenium | Web 端支撑 |
| Python | 跨平台，实现支撑 |
| RobotFramework | 易用性，测试执行支撑 |
| Docker | 测试环境支撑 |
| Xterm | Mac 上多窗口服务支撑 |
- 有了上面的技术选型之后，以技术作为元素，开始做要满足需求的设计方案
2、设计方案：
| 方案 | 描述 |
|---|---|
| 并发方案 | 1、按测试套件分配，使用 RF 中的 tag 作为区分标记 2、为同时满足 mac 和 win 上的并发执行，采用多进程的方式，按测试套件 tag 分配并发 |
| 环境方案 | 1、Web 端环境：Docker 的浏览器镜像 +Selenium-Grid 镜像集群 2、移动端环境：多台真机或模拟器（Android 的无线调试，iOS 也支持） |
| 分配方案 | 1、移动端：一个 tag 对应一台设备和一个 appium 服务 2、Web 端：一个 tag 的对应一个浏览器 |
- 方案是为了满足需求和目标而设计的，但方案本身也来会带来需求或难点，为实现上面的一些方案，我们还需要解决一些主要问题
3、难点解决方案：
| 难点 | 解决方案 |
|---|---|
| 设备 udid 获取 | 获取 udid 构造成设备列表: 1、Android：adb devices 2、iOS：idevice_id –l 输入参数获取对应类型的设备 udid |
| Appium 启动方式 | 1、根据设备数量或输入的参数值自启动对应的数量的 Appium 服务 2、自动根据参数和系统识别以 sh 或 bat 的形式启动 3、用到的端口：服务端口，bootstrap 端口，wda 端口 范围： Android：默认 4723,5723 开始加一启动 iOS：默认 14723,8101 开始加一启动 |
| 设备和 appium 对应的方式 | 1、默认接入的第一台设备对应第一个启动的 appium 服务，以此类推 2、可选择以第 N 台接入的设备开始来执行自动化测试 |
| 环境和测试类型 | 1、自动识别是 Mac OS 还是其他操作系统，以执行不同的命令类型 2、参数化要支持测试设备的类型 |
-
当然，对于方案自身还有其他亮点我们也可以一一攻破：
- 1、自定义使用端口范围
- 2、appium、selenium-grid 服务检查
- 3、Docker 测试环境自动构建
- 4、还有很多.........
-
有了上面的方案设计，能够清晰地指引我们如何去实现一个测试框架来满足我们对并发自动化测试的需求
三、测试实现和落地
-
通过设计以后，我们能够清晰地得到框架的架构图，这也是我们要实现的东西
-
对于移动端
-
对于 Web 端
四、测试维护
- 在工具或方案实现落地之后，随着技术的升级以及业务的变化，测试业务和测试人员需求也会随之改变，所以要适时地调整维护升级已经落地执行的工具或方案，当然这也是需要把握一定的范围，比如技术升级，必须了解清楚技术的变动范围，盲目的升级会降低方案或工具可持续运行的能力，业务方面要把握工具或方案的定位，比如框架是做客户端并发自动化测试的，但不能因为具备并发的能力，就说要加上服务端性能测试的功能或其他的，这样也违背产品定位的原则，维护也是要有目的，维护是为了在保持原有的定位下将提高对需求以及需求提出人员的服务能力，所以再次按照上述的套路，实现满足需求的方案，一个工程化的闭环才得以完成
扩展
- 上文以一个工具或框架为例子，对于测试方案，这里就简单扩展一下，如灰度测试，灰度测试的需求更多地是我们怎么才能充分地去覆盖我们所期望带来价值的业务，保证其质量达标，满足生产经营的标准，我们也可以用工程化的思想，明确需求之后进行设计，要解决两个范围的需求：业务范围和用户范围。比如为了有效地覆盖业务范围，我们可以选取用户粘度和用户画像相对接近业务的用户范围，通过对这部分用户的灰度，通过 nginx 或 diffy 等数据引流方案以及服务隔离等方案，实现落地收集其使用的数据通过大数据处理方案等加以分析，最后论证业务解决需求痛点的程度以及得到新的需求，这也是一个从提出需求到设计到落地到最后得到新需求继续维护的过程，也就是工程化的闭环，百变不离其中
作为一位过来人也是希望大家少走一些弯路
在这里我给大家分享一些自动化测试前进之路的必须品，希望能对你带来帮助。
（软件测试相关资料，自动化测试相关资料，技术问题答疑等等）
相信能使你更好的进步！
点击下方小卡片
