测试-小程序打码平台

一、背景

1、小程序不同于H5有线上和线下环境，而是区分开发版、体验版、正式版，并且每个版本都有对应的权限管控
2、平时项目测试过程中，都是基于开发码进行测试和验收的；
3、开发码生成的流程：开发分支代码本地编译打包，通过微信开发者工具将代码上传至微信服务器，然后微信服务器会返回一个二维码，通过微信环境扫这个二维码，就能打开一个测试用的小程序

二、本地打码的流程

• 1、本地环境搭建
  • 安装node，环境配置
  • 安装微信开发者工具
  • 代码权限申请
  • 测试小程序的开发者权限申请
• 2、本地代码打包
  • 切换开发分支，拉取代码到本地
  • 根据项目，执行编译打包（例如：npm install、npm build、yarn install、yarn build等命令）生成dist文件
  • ps：因为项目和业务测试需要，可能还需要针对代码中一些appId等参数进行修改，修改后再进行编译打包
• 3、微信开发者工具生成开发码
  • dist文件夹生成后，通过微信开发者工具导入工程，直接编译生成开发码。或是指定path、query等参数编译，进入指定页面。

三、本地打码的问题

熟悉整套本地打码流程后，在一个项目中重复生成二维码“理论上”会很快。为什么说是理论上呢？有以下问题

• 1、整个打码过程受限于工作机的性能

  • 如果工作机上开启了很多软件，开发者工具打码的过程也会导致电脑卡住。除了工作机性能不好以外，大家在使用本地打码的过程中，也有其他阻塞测试效率的问题。

• 2、打码同学需要感知环境、打包命令等变更

  • 比如说原来开发环境用的node8，后面升级至node14，导致大家在本地构建时失败。而且这种失败并不会有比较明确的提示告诉我们需要去升级node版本。node环境外，还有打包命令的变更。早期大家用的npm安装依赖和构建，后面变更yarn命令后，有一部分同学使用npm打包失败后不知道原因是什么。

• 3、小程序开发者权限名额太少导致无法加上

  • 一个测试小程序只有200个开发者名额，但是有赞技术团队的人数远大于200。有时候测试紧急项目加上一个测试小程序的开发者权限，项目上线后自己微信号的开发者权限就被下掉给其他开发或者测试同学了。

四、打码平台自动化

1、设计思路

整理思路就是将本地打码的一套流程，转移到一台专属服务器中去操作；这台机器除了部署node环境和安装微信开发者工具以外，还部署了Jenkins服务，通过Jenkins的job调起开发者工具生成二维码。

• 专属提供一台服务器做打码自动化，因为微信开发者工具仅支持macOs和Windows系统，所以最后决定用macmini服务器
• 机器上需要安装node等环境
• 机器上需要安装微信开发者工具
• 部署jenkins服务，通过shell脚本启动Job执行
  • 代码的下载编译打包（通过git等命令）
  • 调用起微信开发者工具生成二维码等（通过微信提供的cli命令行工具）
• 生成开发码后，将图片存放至Jenkins的工作区中，方便直接通过Jenkins服务查看二维码。

2、平台1.0版本

• 1、 以下是Jenkins 通过shell脚本实现整套自动化的简易版代码。

# step1.切换到工程目录下，清理之前的文件
cd project
rm -rf ${projectFile}
# step2.拉取代码，切换到对应分支
git clone ${project}
git checkout -b ${branch} origin/${branch}
cd ${projectFile}
 
# step3.修改appId、店铺id
sed -i "" "s/1024-appId/${appId}/g" project/src/ext.json
sed -i "" "s/1024-店铺id/${店铺id}/g" project/src/ext.json
# step4.打包构建
yarn install
yarn build
 
# step5.打开开发者工具
/Applications/wechatwebdevtools.app/Contents/MacOS/cli open --project  project/dist 
# step6.预览二维码
/Applications/wechatwebdevtools.app/Contents/MacOS/cli preview --project project/dist --qr-format image --qr-output /.jenkins/workspace/${jenkinsJobName}/preview$BUILD_ID

• 2、使用后的问题
  Jenkins实现了打码的全自动化，测试同学不用再感知node环境、打包命令等变更，但是也有一些效率上的问题
  • 高频打码时段，一直在排队。
    微信开发者工具同时只能生成一个开发码。所以Jenkins的任务只能串行执行。而大家提交打码申请都是在同一时间段内。这样就导致大家一直在排队，无限延长了开发码生成的时长。
  • 单次任务时间在15分钟。
  • 公用测试小程序数量少，经常打码冲突。
  • 目前不支持qq、支付宝小程序的打码自动化。

3、平台2.0版本

打码平台是基于Jenkins实现的打码自动化的基础上，支持多个打码任务并行执行，同时提供可视化的页面。

• 1、多并发打码
  打码平台最需要解决的就是打码排队问题。我们首先想到的就是将串行的任务变成并行。
  幸运的是我们发现一台机器上是可以安装多个开发者工具。每个开发者工具登录不同的微信号，并且对应不同的Jenkins Job，就可以实现多并发。
  还可以增加打码的机器来实现更高的并发
  

• 2、单次任务执行时间降低
  单次任务时间降低主要从硬件、脚本两方面进行优化。

  • 硬件优化
    最早用来跑自动化打码的机器配置是4核8G，单次任务时间大概14分钟多，将近15分钟。将机器替换为8核16G后，单次任务执行时间降低至10分钟。
  • 脚本优化
    • 最早拉取代码用的是git clone + git checkout 2句。git clone时除了会拉取默认的master分支外，还会拉取所有远程分支的信息。这样会非常耗时间

      # version1
      git clone ${project}
      git checkout -b ${branch} origin/${branch}
      

    • 所以我们可以在git clone时增加branch参数，将两句合并为1句。

      # version2
      git clone -b ${branch} ${project}
      

    • version2的代码，只会拉取指定分支的数据。但这还不是最优解。version2的git语句，会将这个分支的所有commit信息都拉到本地。但是我们只是为了拉取最新的代码，直接打包构建。并不用到历史commit信息。所以可以在version2上再增加参数–depth=1，只拉取分支最新commit的信息。

      # version3
      git clone –b ${branch} ${project} –depth=1
      

  测试下来，version1时长在209s，version3只花了33s，优化了进3分钟。
  通过硬件+脚本的优化，单次任务从15分钟降低至7分钟。

• 3、打码冲突比较多
  这里的冲突，主要是受限于微信的限制。同个小程序同时只能存在一个开发码。但是目前大家在用的公用测试小程序只有2个。
  甲同学用小程序A打码，乙同学同时也提交了小程序A的打码申请。那当乙同学打码成功后，甲同学的二维码虽然还是可以扫，但是小程序内容已经是乙同学的改动了。
  从自动化打码的方面来说，是无法解决这种冲突的。我们只能建议高频打码的团队去申请自己的小程序，将这2个测试小程序留给打码需求比较少的团队共用。

• 4、可视化页面

  • 实现多并发打码后，直接通过Jenkins分发任务带来了一些问题。

    • 在使用Jenkins打码时，需要人工区分哪个Job是空闲的，这又将全自动化打码变成了半自动化。
    • Jenkins中都使用一个admin账号进行打码，有问题时找不到对应的分支是谁在打码。
    • Jenkins只记录了最近30次的构建结果。无法定期review打码数据，对打码流程进行优化。

  • 改进

    • 搭建了打码平台，用户只需要在可视化的页面上输入参数，点击提交。后端服务查询空闲的Jenkins任务，通过JenkinsApi调起对应的Job开始打码。Jenkins任务结束后，回调接口将打码结果返回给后端服务。
    • 同时结合公司的账号体系，每次打码都能直接拿到打码人的用户名，并且将用户名、打码参数、打码结果都持久化在DB中
    •