devops多浏览器同步测试工具的设计与实现

在代码方面，继续秉承组件化思想，结合 antd pro 的高阶组件，对多处进行了抽象复用。

import { ProCard, ProTable } from '@ant-design/pro-components';

操作部分，结合了较为小众但稳定可靠的react-vnc库，同时为了降低用户的浏览器资源消耗，操作页面在同步浏览器列表展开时才会进行 vnc 连接展示。

<Sider width={'20%'} collapsible collapsed={collapsed} onCollapse={collapsed => this.setState({collapsed})}>
<Card size="small" title={!collapsed? "同步浏览器列表": '同步'} >
{syncBrowsers && syncBrowsers.length > 0? (
syncBrowsers.map(item => (
<Card.Grid key={item.sessionId} className={styles.syncContainer}>
{!collapsed ? (
<VncScreen
url={item.vncUrl}
rfbOptions={{
credentials: {
password: 'selenoid',
},
}}
scaleViewport
background='#000000'
style={{
height: '100%'
}}
/>
): (
<div className={styles.browserName}><img src={`/${item?.browserName}.react.svg`} alt='' />{item.browserName}</div>
)}
<div ref={n => (this[`hover_${item.sessionId}`] = n)} className={styles.hoverContainer}>
<SyncModal data={item} actions={this.state.syncActions[item.sessionId]} />
</div>
</Card.Grid>
))
): (
<Empty />
)}
</Card>
</Sider>

服务端设计

服务端主要是提供数据给前端展示，以及启动脚本调用系统命令的，接口部分千篇一律，增删改查而已，不展开介绍了。

这里有个小细节，yutu本身不会和数据库已经服务端进行交互的，所以它的任务运行状态，需要告知脚本是个麻烦事。我是通过脚本监控单个任务进程的控制台信息，来达成的，这样的成本最小，也不必让 2 个工具过度耦合。

async def start_task(self):
logger.info(f'Task {self.task_id} is starting...')
run_cmd = f'yutu case.spec.js' 
f' --browser_size={self.task_info["screen"]}' 
f' --http_proxy={self.task_info["proxy"]}' 
f' --default_url={self.task_info["url"]}'
logger.info(f'start cmd: {run_cmd} ')
p = subprocess.Popen(
run_cmd,
shell=True,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
encoding='utf-8',
cwd=self.task_dir_path
)
for i in iter(p.stdout.readline, 'utf-8'):
if 'consoleParams:' in i:
try:
data = json.loads(i.replace('consoleParams:', ''))
singal = await self.update_task_info(data)
print(data)
if not singal:
break
except Exception as e:
print(e)
async def update_task_info(self, data):
if not data:
return
row = BrcSyncTask.query.filter_by(id=self.task_id).first()
if data['type'] == 'server':
row.sync_server_ip = data['serverAddress']
row.sync_server_port = data['serverPort']
db.session.commit()
elif data['type'] == 'main':
row.main_session_id = data['sessionId']
db.session.commit()
elif data['type'] == 'sync':
info = json.loads(row.sync_sessions) if row.sync_sessions else {}
info[data['browserInfo']] = data['sessionId']
row.sync_sessions = json.dumps(info)
db.session.commit()
elif data['type'] == 'signal':
if data['status'] == 'ready':
self.update_task_status(5)  # 开始同步
      if data['status'] == 'end':
self.update_task_status(3)  # 同步结束
        db.session.flush()
return False
return True

自定义镜像封装

此处主要介绍本地封装 windows 版本的 selenoid 浏览器镜像的心得，懂得都懂，就不详细展开介绍了。
为什么要封装 windows 镜像，有 2 个原因。

• 还原用户场景：用户用的是 windows 系统，官方提供的 liunx 版本浏览器镜像不能代表实际的浏览器使用场景。
• 方便环境隔离：直接调用单个主机的 webdriver 的方式，无法实现同一时间不同用户的远程操作和代理隔离（f2etest 的 webdriver 云方案无法远程操作）。

关于 windows 封装的基础教程可以参考：windows-images

不过按照教程走下去后会发现，有可能你的容器能启动，但死活连不上浏览器 driver。
再通过反复试验后，我采用了 selenoid+selenoid 的方式，才让流程通起来。

容器内的 selenoid 服务

关键在于在浏览器和 driver 都安装后，再在 windows 里启动一个 selenoid 服务，让它来提供 4444 端口服务给外部的 selenoid hub 调用，由它来和容器内的浏览器 driver 进行交互。

为了方便复用，我在基础镜像中就加入这个基础工具包，文件目录如下：


start.bat 是一个封装后的执行文件，参数可以根据自己设备性能调整，内容如下：

C:selenoid-windowsselenoid_windows_386.exe -conf C:selenoid-windowsbrowsers.json -disable-docker -limit 4 -service-startup-timeout 240s -session-attempt-timeout 240s -session-delete-timeout 240s -timeout 240s > C:selenoid-windowsselenoid.log 2>&1

browsers.json 如下

{"MicrosoftEdge":{"default":"18","versions":{"18":{"image":["C:\selenoid-windows\webdrivers\msedgedriver.exe","--host=127.0.0.1","--verbose"]}}}}

容器内的 flask 服务

看上面的工具包内容可以看到，我们还在里面起了个 flask 轻量服务，它的作用是接收外部传过来的配置参数，动态设置当前容器中的分辨率和系统代理。这个问题是 windows 镜像特有的，selenoid 官方团队说解决不了，为此也做过解释，
windows starts 1024x768 resolution even SCREEN_RESOLUTION changed to 1920x1080x24

我贡献的这个方法可以曲线解决这个问题，步骤也很简单，

• 1.在基础镜像中安装个 python（2、3 随意）
• 2.安装工具包中依赖（关键是 flask、pywin32、winproxy 这几个库）
• 3.容器退出保存前，启动 flask、selenoid 服务

flask 中的内容如下：

from flask import Flask
from flask import request
from flask import jsonify
import win32api
from winproxy import ProxySetting
app = Flask(__name__)
def setProxy(host, port):
proxy = ProxySetting()
proxy.enable = True
proxy.server = f"{host}:{port}"
proxy.override = ["127.*","192.168.*","10.*"]
proxy.registry_write()
def setScreen(width, height):
dm = win32api.EnumDisplaySettings(None, 0)
dm.PelsWidth = int(width)
dm.PelsHeight = int(height)
dm.BitsPerPel = 32
dm.DisplayFixedOutput = 0
win32api.ChangeDisplaySettings(dm, 0)
@app.route('/setDisplay', methods=['GET'])
def index():
height = request.args.get('height')
width = request.args.get('width')
host = request.args.get('host')
port = request.args.get('port')
setScreen(width, height)
if host and port:
setProxy(host, port)
return jsonify({'width': width, 'height': height})
if __name__ == '__main__':
app.run(host='127.0.0.1', port=5000)

由于这个服务是起在容器里的，因此我们可以在 yutu 的 driver 建立后，通过固定的 url 来调用，而不必维护容器的 ip 和网络情况。

if (configJson.webdriver.host !== '127.0.0.1'){
const setScreenUrl = `http://127.0.0.1:5000/setDisplay?width=${width}&height=${height}&host=${hostname}&port=${port}`
await driver.url(setScreenUrl);
}

开发过程中坑

项目真正开发到完成，投入 1.5 人/月左右，按照时间顺序来回顾这过程中的坑吧。

• 同步浏览器从一个改成 N 个后，浏览器关闭异常。
结合异步转同步的方式，改造关闭浏览器方法，保证执行有序

  async function closeBrowser (){
  if(syncCheckBrowserDrivers){
  for (var browserIndex in syncCheckBrowserDrivers){
  var browser = syncCheckBrowserDrivers[browserIndex];
  await new Promise((resolve) => {
  const {browserName, browserVersion } = browser;
  browser.close(() => {
  console.log(`${__('checker_browser_closed')}${browserName}${browserVersion}`.green);
  resolve();
  })
  })
  }
  }
  }
  

• 原先的 webdriver 客户端不支持 w3c 协议，导致新浏览器无法正常同步操作
这是我万万没想到的，虽然知道前端技术日新月异，用外部老的工具，肯定会有需要兼容的差异，但没想到 ali 老大哥们也摆烂了，也导致了我在中后期几乎重写了大部分的 yutu 中的同步操作方法。

• windows 镜像的产出后，运行不起来
一开始并没有明确定义 windows 支持对于我们系统的重要性，因此一直在以 liunx 版本的浏览器作为最小试验对象，但后期流程通后，要交付时才发现没有以用户实际的使用场景为目标，这样即使交付也没啥用处。
因此开始硬啃，为了突破这个技术难点，我的工作机被刷成 ubuntu 系统，好不容易产出了 windows 镜像后，又发现镜像运行很艰难，我的小破机根本带不动。


  

  
  终于在领导的关照下，搞个高配的开发机器，运行流畅。

• windows 系统分辨率超出，操作界面显示不全的问题
原先的 selenoid 系统，是通过传给 qemu 分辨率参数来设置系统环境变量的。但 windows 版本并没有这样的能力，老外给的方案是默认启动时就给最大的分辨率，在通过设置浏览器窗口大小来实现指定大小分辨率的测试执行，最起码这样显示内容是全的。但这对于我这种可能需要用户手动去 vnc 操作的方式来说，并不适用，用户一旦不小心点了最大化，那么同步浏览器的比例就完全乱套了。因此结合自己 python 脚本经验，深度挖掘了上述更为灵活的 flask server 方案。

• windows 系统代理无法通过环境变量设置
原先的 selenoid，我只要在启动容器时给个 env 变量就可以指定代理了，但 windows 版本这样不行。有了上面的分辨率解决经验，我通过 python 的 winproxy 库进行了处理。

• 非主流浏览器借用的别人的内核，缺少浏览器驱动
这里的非主流浏览器其实不光指的是我们的一众换皮国产浏览器，国外的 opera、yandex 等等其实也是换皮 chromium。这些家伙的兼容才是真的坑，我到现在还没填完。
下面就 qqbrowser 举个例子吧：
它的内核是 chrome 94 的，在启动时要传的浏览器名称 “chrome”，而我们系统中本身也可能有 chrome 这个版本。因此要区分开，我是自定义一个版本区间给它，如：chrome 1～11，同样在 yutu 中要做别名区分，启动时传 chrome，记录时要记 qq。

  {"chrome":{"default":"94","versions":{"94":{"image":"windows/chrome:80","port":"4444","path":"/wd/hub"},"11":{"image":"windows/qq:11","port":"4444","path":"/wd/hub"}}}}

  var browserNameToDriver = {
  'yandex': 'chrome',
  'qq': 'chrome',
  'chrome': 'chrome',
  'firefox': 'firefox',
  'MicrosoftEdge': 'MicrosoftEdge',
  'opera': 'opera',
  'safari': 'safari',
  'internet explorer': 'internet explorer',
  }
  capabilities['browserName'] = browserNameToDriver[options.browserName]
  

结语

项目目标算是达成了，但还不够完美，我会持续的优化。

通过此次的开发经历，也使我感触良多，技术类需求的不确定性，是软件行业的特性。以后对接公司工作中技术需求，我也要引以为戒，做好风险管理。

同时看到一个个曾经的明星项目的沉寂，也是让我百感交集，他们本该能够成长的更好，但或是公司环境的变化，或是创作者乏力无奈，总之慢慢淡出人们的记忆，甚至连创作团队自己都忘记，而我们就在这不断创造与消亡中轮回。

最后，借用尼采的警言与各位共勉：所有美好的事物都是曲折地接近自己的目标，一切笔直都是骗人的，所有真理都是弯曲的，时间本身就是一个圆圈。