测试-小程序打码平台
一、背景
1、小程序不同于H5有線上和線下環(huán)境，而是區(qū)分開發(fā)版、體驗版、正式版，并且每個版本都有對應的權限管控
2、平時項目測試過程中，都是基于開發(fā)碼進行測試和驗收的；
3、開發(fā)碼生成的流程：開發(fā)分支代碼本地編譯打包，通過微信開發(fā)者工具將代碼上傳至微信服務器，然后微信服務器會返回一個二維碼，通過微信環(huán)境掃這個二維碼，就能打開一個測試用的小程序
二、本地打碼的流程
- 1、本地環(huán)境搭建
- 安裝node，環(huán)境配置
- 安裝微信開發(fā)者工具
- 代碼權限申請
- 測試小程序的開發(fā)者權限申請
- 2、本地代碼打包
- 切換開發(fā)分支，拉取代碼到本地
- 根據(jù)項目，執(zhí)行編譯打包（例如：npm install、npm build、yarn install、yarn build等命令）生成dist文件
- ps：因為項目和業(yè)務測試需要，可能還需要針對代碼中一些appId等參數(shù)進行修改，修改后再進行編譯打包
- 3、微信開發(fā)者工具生成開發(fā)碼
- dist文件夾生成后，通過微信開發(fā)者工具導入工程，直接編譯生成開發(fā)碼?；蚴侵付╬ath、query等參數(shù)編譯，進入指定頁面。
三、本地打碼的問題
熟悉整套本地打碼流程后，在一個項目中重復生成二維碼“理論上”會很快。為什么說是理論上呢？有以下問題
-
1、整個打碼過程受限于工作機的性能
- 如果工作機上開啟了很多軟件，開發(fā)者工具打碼的過程也會導致電腦卡住。除了工作機性能不好以外，大家在使用本地打碼的過程中，也有其他阻塞測試效率的問題。
-
2、打碼同學需要感知環(huán)境、打包命令等變更
- 比如說原來開發(fā)環(huán)境用的node8，后面升級至node14，導致大家在本地構建時失敗。而且這種失敗并不會有比較明確的提示告訴我們需要去升級node版本。node環(huán)境外，還有打包命令的變更。早期大家用的npm安裝依賴和構建，后面變更yarn命令后，有一部分同學使用npm打包失敗后不知道原因是什么。
-
3、小程序開發(fā)者權限名額太少導致無法加上
- 一個測試小程序只有200個開發(fā)者名額，但是有贊技術團隊的人數(shù)遠大于200。有時候測試緊急項目加上一個測試小程序的開發(fā)者權限，項目上線后自己微信號的開發(fā)者權限就被下掉給其他開發(fā)或者測試同學了。
四、打碼平臺自動化
1、設計思路
整理思路就是將本地打碼的一套流程，轉(zhuǎn)移到一臺專屬服務器中去操作；這臺機器除了部署node環(huán)境和安裝微信開發(fā)者工具以外，還部署了Jenkins服務，通過Jenkins的job調(diào)起開發(fā)者工具生成二維碼。
- 專屬提供一臺服務器做打碼自動化，因為微信開發(fā)者工具僅支持macOs和Windows系統(tǒng)，所以最后決定用macmini服務器
- 機器上需要安裝node等環(huán)境
- 機器上需要安裝微信開發(fā)者工具
- 部署jenkins服務，通過shell腳本啟動Job執(zhí)行
- 代碼的下載編譯打包（通過git等命令）
- 調(diào)用起微信開發(fā)者工具生成二維碼等（通過微信提供的cli命令行工具）
- 生成開發(fā)碼后，將圖片存放至Jenkins的工作區(qū)中，方便直接通過Jenkins服務查看二維碼。
2、平臺1.0版本
- 1、 以下是Jenkins 通過shell腳本實現(xiàn)整套自動化的簡易版代碼。
- 2、使用后的問題
Jenkins實現(xiàn)了打碼的全自動化，測試同學不用再感知node環(huán)境、打包命令等變更，但是也有一些效率上的問題- 高頻打碼時段，一直在排隊。
微信開發(fā)者工具同時只能生成一個開發(fā)碼。所以Jenkins的任務只能串行執(zhí)行。而大家提交打碼申請都是在同一時間段內(nèi)。這樣就導致大家一直在排隊，無限延長了開發(fā)碼生成的時長。 - 單次任務時間在15分鐘。
- 公用測試小程序數(shù)量少，經(jīng)常打碼沖突。
- 目前不支持qq、支付寶小程序的打碼自動化。
- 高頻打碼時段，一直在排隊。
3、平臺2.0版本
打碼平臺是基于Jenkins實現(xiàn)的打碼自動化的基礎上，支持多個打碼任務并行執(zhí)行，同時提供可視化的頁面。
-
1、多并發(fā)打碼
打碼平臺最需要解決的就是打碼排隊問題。我們首先想到的就是將串行的任務變成并行。
幸運的是我們發(fā)現(xiàn)一臺機器上是可以安裝多個開發(fā)者工具。每個開發(fā)者工具登錄不同的微信號，并且對應不同的Jenkins Job，就可以實現(xiàn)多并發(fā)。
還可以增加打碼的機器來實現(xiàn)更高的并發(fā)
-
2、單次任務執(zhí)行時間降低
單次任務時間降低主要從硬件、腳本兩方面進行優(yōu)化。- 硬件優(yōu)化
最早用來跑自動化打碼的機器配置是4核8G，單次任務時間大概14分鐘多，將近15分鐘。將機器替換為8核16G后，單次任務執(zhí)行時間降低至10分鐘。 - 腳本優(yōu)化
- 最早拉取代碼用的是git clone + git checkout 2句。git clone時除了會拉取默認的master分支外，還會拉取所有遠程分支的信息。這樣會非常耗時間# version1 git clone ${project} git checkout -b ${branch} origin/${branch}
- 所以我們可以在git clone時增加branch參數(shù)，將兩句合并為1句。# version2 git clone -b ${branch} ${project}
- version2的代碼，只會拉取指定分支的數(shù)據(jù)。但這還不是最優(yōu)解。version2的git語句，會將這個分支的所有commit信息都拉到本地。但是我們只是為了拉取最新的代碼，直接打包構建。并不用到歷史commit信息。所以可以在version2上再增加參數(shù)–depth=1，只拉取分支最新commit的信息。# version3 git clone –b ${branch} ${project} –depth=1
測試下來，version1時長在209s，version3只花了33s，優(yōu)化了進3分鐘。
通過硬件+腳本的優(yōu)化，單次任務從15分鐘降低至7分鐘。 - 硬件優(yōu)化
-
3、打碼沖突比較多
這里的沖突，主要是受限于微信的限制。同個小程序同時只能存在一個開發(fā)碼。但是目前大家在用的公用測試小程序只有2個。
甲同學用小程序A打碼，乙同學同時也提交了小程序A的打碼申請。那當乙同學打碼成功后，甲同學的二維碼雖然還是可以掃，但是小程序內(nèi)容已經(jīng)是乙同學的改動了。
從自動化打碼的方面來說，是無法解決這種沖突的。我們只能建議高頻打碼的團隊去申請自己的小程序，將這2個測試小程序留給打碼需求比較少的團隊共用。 -
4、可視化頁面
-
實現(xiàn)多并發(fā)打碼后，直接通過Jenkins分發(fā)任務帶來了一些問題。
- 在使用Jenkins打碼時，需要人工區(qū)分哪個Job是空閑的，這又將全自動化打碼變成了半自動化。
- Jenkins中都使用一個admin賬號進行打碼，有問題時找不到對應的分支是誰在打碼。
- Jenkins只記錄了最近30次的構建結(jié)果。無法定期review打碼數(shù)據(jù)，對打碼流程進行優(yōu)化。
-
改進
- 搭建了打碼平臺，用戶只需要在可視化的頁面上輸入?yún)?shù)，點擊提交。后端服務查詢空閑的Jenkins任務，通過JenkinsApi調(diào)起對應的Job開始打碼。Jenkins任務結(jié)束后，回調(diào)接口將打碼結(jié)果返回給后端服務。
- 同時結(jié)合公司的賬號體系，每次打碼都能直接拿到打碼人的用戶名，并且將用戶名、打碼參數(shù)、打碼結(jié)果都持久化在DB中
-
總結(jié)
以上是生活随笔為你收集整理的测试-小程序打码平台的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 怎么在微软官网找到visual stud
- 下一篇： 【 Rust 基础】控制流 —— Rus