很多人第一次看到OpenMontage这个项目名会以为它跟视频剪辑有关。蒙太奇嘛自然是把零散的镜头剪成一个完整故事。我第一次接触这个开源工具时的第一反应也是这样但真正用了半年之后我反而觉得这个名字起得非常贴切——它干的活确实是“剪辑”只不过剪的不是视频素材而是散落在各个CI系统里的自动化测试报告。我手上维护的项目大概涉及6条产品线、3个测试框架每天的CI构建会产出将近20份测试结果文件。在没有OpenMontage之前我每天早上都要挨个打开Jenkins、GitLab CI翻进每个Job的归档目录去下载XML再手动汇总出通过率和失败用例。这活儿不难但极其耗时而且历史趋势、回归对比基本靠Excel手搓。在经历了一次因为漏看一个失败用例导致线上事故之后我开始认真寻找一款能把所有测试报告聚合到一个看板里的工具最终选定了开源方案OpenMontage。这篇文章会从实际使用角度完整记录我从下载部署到接入CI、再到做日常分析的全部经验。如果你是测试开发工程师、DevOps或者正在为“测试结果太分散”发愁的技术负责人这篇应该能帮你少走不少弯路。1. 每天早上翻三个CI系统找测试结果这个工具把我解放了1.1 一个测试负责人被报告淹没的真实场景先说说我遇到的实际问题这样你能判断OpenMontage是否适合你。我们团队的情况是这样的后端用pytest跑接口测试前端用Jest跑单元测试还有一套基于Selenium的端到端用例在Jenkins的另一个独立Job里运行。再加上移动端的Appium脚本整个测试体系横跨6个代码仓库、5个测试Job每轮构建完成之后产物里的测试报告格式也不一样有JUnit XML、有JSON、有HTML。最痛苦的是每天做结果同步。我要从不同的Job归档目录里把一个个XML文件下载下来然后用脚本解析最后拼到内部的在线表格里。问题在于很多失败不是当天就能修复的我需要在明天、后天继续跟进。而在线表格只能记文本摘要不能保留完整的堆栈信息每次要定位问题还得回头去CI系统翻原始日志。这样搞了几个月之后团队里几乎没有人愿意去维护那张表格了测试结果变成了“只有机器知道的秘密”。这个场景你应该不陌生你的项目可能没这么复杂但只要自动化用例超过几十条报告分散的问题就会开始拖累效率。1.2 OpenMontage是什么聚合、归档、可视化OpenMontage解决的核心问题就是一句话把各种格式、各个来源的测试结果统一收进来形成一个可检索、可追溯、可对比的历史看板。我一开始以为它只是一个“报告格式转换器”实际上手后发现它的定位比我想象的更完整。它做的事情可以拆成三块聚合通过适配器或命令行工具接收JUnit XML、JSON等格式的测试结果归档把每次上报结果按项目、分支、执行时间存储进数据库形成历史数据可视化提供Web仪表盘展示通过率、失败用例、执行耗时等指标支持按模块和时间范围筛选。用一句话概括它像是一个测试报告专用的“档案馆展示厅”。你不需要再自己去维护在线表格也不用反复去CI系统里翻归档。顺便说一句OpenMontage部署起来并不重单人维护完全没问题。后面我会讲具体的部署和接入方式。1.3 什么情况下建议引入它结合我自己的经验如果你的团队符合下面任意一条就可以认真评估这个工具测试用例分布在多个代码仓库且使用了不止一种测试框架CI任务数量超过5个手工汇总报告已经变成每周固定负担测试失败后需要回到Jenkins或GitLab里翻原始日志流转链路太长管理层或合作方经常要测试通过率数据而你不想再花半小时手搓Excel。反过来如果你们只有一个项目、一个测试框架、用例量也不大那直接用CI系统自带的看板就够了。OpenMontage的收益来自“聚合”和“历史对比”数据量太小的时候这层价值不明显。这算是我比较真诚的劝退建议。2. 下载OpenMontage之前先弄清楚这4个核心边界2.1 它解决什么问题又不解决什么问题很多工具死于预期错位。OpenMontage也不是万能的先划清边界再决定是否引入。它能解决的测试报告格式不统一难以集中查看缺少历史数据无法判断测试稳定性趋势失败用例信息分散需要逐个CI系统跳转测试结果需要定期同步给团队或领导人工整理耗时。它不能解决的不会自动修复失败的用例不做测试用例的管理和编排那是用例管理平台的事不做实时日志流它消费的是构建结束后的报告文件而不是实时输出不是测试计划系统不负责调度CI任务。我见过不少团队把OpenMontage当成测试平台的一站式解决方案后来发现它管不了用例设计又去找别的系统折腾了好几周。建议你在做出决定之前先明确你要的是“结果的集中展示与追溯”而不是“测试过程的全面管理”。2.2 服务端、适配器、CLI上报器三件套从部署视角看OpenMontage由三部分组成。第一部分是服务端承载Web仪表盘和存储。它负责接收上报的测试结果、解析并写入数据库、提供查询接口和页面展示。日常维护只需要保证这个服务在线并且数据库有备份。第二部分是适配器作用是把不同的测试报告格式转换成OpenMontage的统一数据模型。系统自带了一批常用格式的解析器比如JUnit XML、Cucumber JSON等如果你的测试框架输出的是自定义格式则需要写一个简单的转换脚本。第三部分是CLI上报器这是最常接触的部分。在CI脚本里调用这个命令行工具指定报告文件路径和目标项目它就会把结果推送到服务端。我在实际使用中绝大多数场景只用得到这个CLI。这三件套的划分有一个好处上报入口足够轻CI里只需要多执行一条命令而已不需要引入重级依赖。2.3 支持哪些报告格式和运行环境目前OpenMontage开箱即用的报告格式覆盖了主流测试框架测试框架原始报告格式接入方式pytestJUnit XMLCLI/适配器自动解析Java/JUnitJUnit XMLCLI/适配器自动解析JestJSON或JUnit XML先转换后上报CucumberJSON适配器直接解析Postman/NewmanJSON适配器直接解析运行环境方面服务端推荐在Linux服务器上部署官方提供Docker镜像如果只是想在自己电脑上试用用Docker Desktop也可以。CLI工具是Python编写的所以装有Python3.8的机器都能跑Windows和macOS也都能配合CI使用。提示不要一上来就纠结支持多少种格式。把最常用的pytest/JUnit打通已经能覆盖绝大多数团队的诉求。3. 第一次启动Docker Compose部署全流程3.1 环境准备和目录规划我推荐的部署方式是Docker Compose因为OpenMontage除了自身的应用容器还依赖一个数据库容器用Compose可以把这两个编成一整套启动和升级都方便。到GitHub的Release页面下载最新的docker-compose.yml模板之前先想清楚几个问题数据目录放在哪里。我习惯在/home/你的用户名/opt/openmontage下创建一个data目录用于持久化数据库文件端口是否冲突。默认面板端口是8080如果你本机已经占了就在Compose文件里映射成别的宿主机端口数据库账号密码。首次部署时设置好避免后面再改。这些配置看起来都是小事但后期维护时影响很大。我见过同事图省事把数据目录放到/tmp下面结果服务器一重启所有历史报告全没了那个教训相当惨痛。3.2 docker-compose.yml详解下面这个Compose文件是我在生产环境使用的精简版本包含了应用服务和PostgreSQL数据库服务version: 3.8 services: openmontage-server: image: ghcr.io/openmontage/server:latest container_name: openmontage-server ports: - 8080:8080 environment: - DATABASE_URLpostgresql://om:om_passwordpostgres/om volumes: - ./data/uploads:/app/uploads depends_on: - postgres restart: unless-stopped postgres: image: postgres:15 container_name: openmontage-postgres environment: - POSTGRES_USERom - POSTGRES_PASSWORDom_password - POSTGRES_DBom volumes: - ./data/db:/var/lib/postgresql/data restart: unless-stopped注意几个关键点环境变量DATABASE_URL告诉服务端往哪里连接数据库如果不设置服务端会使用内置的SQLite但这更适合单机试用多人团队建议直接上PostgreSQL。uploads目录用于存放上报时附带的一些独立文件比如截图、附件别把它放在容器内部否则重建容器就丢了。启动命令很简单docker compose up -d docker compose ps等两个容器都进入healthy状态浏览器打开http://localhost:8080应该能看到OpenMontage的登录页。3.3 pip安装方案的取舍如果你只是想在开发机上快速体验不想碰Docker也可以用pip安装CLI和服务端pip install openmontage openmontage serve --port 8080不过这个方案有几个限制服务端需要你在本机安装好PostgreSQL并自己初始化数据库升级时要手动处理依赖版本没有现成的日志轮转和健康检查。我的建议是临时试用用pip正式使用直接上Docker Compose。我最初是在MacBook上用pip装的跑demo没问题但后来挪到团队服务器时就改成了Docker。理由很简单Compose文件提交到Git之后新同事一条命令就能拉起完整环境不需要再读一长串安装文档。4. 把第一份测试报告喂进去从pytest到可视化看板4.1 生成标准JUnit XML报告成功启动服务之后重点就变成了“下载后如何使用”也就是怎么把测试结果送进去。第一步先让测试框架输出OpenMontage能识别的报告格式。拿pytest举例在项目根目录执行pip install pytest pytest --junitxmlreport.xml tests/执行完之后目录下会生成一个report.xml文件里面记录了每个用例的名称、执行耗时、状态和失败信息。如果你用的是Jest需要额外装一个转换器才能输出JUnit格式npm install --save-dev jest-junit JEST_JUNIT_OUTPUT_FILEjest-report.xml npx jest --ci得到XML文件之后最好手动打开看一眼确认它至少包含testsuite和testcase节点这是OpenMontage解析的基础。4.2 CLI上报与REST API两种方式拿到报告文件后上报方式有两种。第一种是CLI适合手工操作或写进脚本openmontage submit --server http://localhost:8080 \ --project 订单服务 \ --branch main \ --report report.xml上报成功后CLI会返回一条记录ID例如Record #1024 created. View at http://localhost:8080/projects/订单服务/records/1024第二种是REST API适合编程调用curl -X POST http://localhost:8080/api/v1/records \ -H Content-Type: multipart/form-data \ -F project订单服务 \ -F branchmain \ -F filereport.xml两种方式实质相同CI脚本里我建议用CLI因为参数校验和错误提示更友好。我第一次用curl传文件时字段名写错了服务端没有给出有效的错误信息排查了十几分钟才发现是-F参数不对。4.3 仪表盘页面元素逐项解读第一次打开项目页面你会发现界面并不复杂核心元素就几块总览卡片显示当前项目的用例总数、通过率、失败数、执行总时长最近趋势图按天展示通过率变化曲线这是判断测试稳定性的第一入口失败用例列表列出最近一次执行中的失败用例点击可查看完整堆栈记录时间线按时间倒序排列每次上报的记录可以展开看详细数据。我建议你第一次接入后先只关注“失败用例列表”。因为趋势图在数据量不足时意义不大至少得等积累一周的记录才能看出规律。另外有个小细节如果你用中文作为项目名URL里的中文会被浏览器转码看起来很长但不影响使用。我自己习惯用一句话做项目名比如“订单服务接口测试”在筛选列表里更好认。5. 接入CI流水线每天自动生成团队测试看板5.1 集成方式选择Agent模式上报单独手工上报意义有限真正的价值在于把上报动作嵌到CI流水线里让每次构建结束自动生成记录。在选集成方式时我推荐的是“Agent模式”在CI机器上安装openmontage CLI然后在流水线脚本里把执行完测试后的上报命令作为额外一个Step加进去。这样做的优点是CI的配置文件改动很少测试任务本身不受影响缺点是每台CI机器都需要安装CLI不过一条pip命令就能解决。另一种方式是直接调用REST API连CLI都不用装适合容器化程度高、不方便预装依赖的流水线。两种方式我都跑过最终统一用了Agent模式因为出错时能在CLI那里看到更明确的提示。5.2 Jenkins Pipeline配置示例这是一段我实际用的Jenkins Pipeline片段stage(测试) { steps { sh pytest --junitxmlreport.xml tests/ } } stage(上报结果) { steps { sh openmontage submit --server $OM_SERVER --project 订单服务 --branch main --report report.xml } }这里有个细节我把服务端地址和项目名都做成了Jenkins的全局环境变量OM_SERVER等而不是硬编码在脚本里。这样换环境、换项目名的时候只需要改配置不需要改Pipeline代码。5.3 GitLab CI配置示例GitLab CI的配置也类似在.gitlab-ci.yml里增加一个stagereport: stage: report image: python:3.11-slim before_script: - pip install openmontage script: - openmontage submit --server ${OM_SERVER} --project 订单服务 --branch ${CI_COMMIT_BRANCH} --report report.xml only: - main我特别用到了CI_COMMIT_BRANCH这个预定义变量这样每次提交所在的分支名会自动传给OpenMontage不需要人肉维护。接入CI后的效果是每日构建完成所有测试结果自动归档我可以随时打开浏览器看到最新的通过率而不再等某个同事手工同步表格。这个变化对团队最大的影响不是省了时间而是测试数据的可信度提升了——记录是自动生成的没人质疑它是不是漏掉了哪次执行。6. 数据多了以后我只看这几个分析视图6.1 失败用例的归类与筛选数据积累一周之后你会发现仪表盘上最常看的不是通过率而是失败用例列表。OpenMontage支持按照模块、分支、时间来筛选失败项这时候一定要做的一件事是给高频失败用例打标签。我自己的习惯是每个周五花10分钟过一遍本周的失败列表把失败原因分成几类稳定性问题偶发超时、端口冲突、外部依赖抖动环境问题测试数据被污染、数据库状态不一致真实缺陷断言失败、接口返回值变化。打上标签后后续再出现同类失败就能快速判断是不是已知问题。这个过程虽然只是记录层面的操作但它让测试结果从“机器数据”变成了“团队资产”。后面复盘版本质量时这些标签直接决定了你能不能在5分钟内给出结论。6.2 三个仪表盘核心视图趋势、回归、耗时积累的数据量上来之后有三个视图的参考价值最大。趋势视图最适合回答“测试是不是越来越稳定”这类问题。单看一天可能因为环境或偶发失败得出错误结论但看两周以上的通过率曲线就能识别出测试是否存在劣化趋势。我之前就遇到过某个模块的通过率从98%慢慢掉到90%的情况单日看都不算异常拉长到一个月的曲线后问题立刻浮现。回归对比视图是OpenMontage相比手工Excel最占优的地方。它能直接把当前记录的失败用例跟上次记录对比标出“新增失败”“持续失败”“已恢复”三组。我在版本发布前一定会看这个视图持续失败的用例数量基本可以代表历史欠债新增失败则需要警惕是否被这次改动影响。耗时视图则用来发现执行时间的异常增长。我之前曾经通过耗时曲线发现某个接口测试越来越慢最后定位到是测试环境的连接池配置被误改这类问题如果只看通过率很难察觉。6.3 测试结果与代码提交的关联使用了一段时间后我建议把CI里的提交号如Git提交哈希作为参数一并上报。OpenMontage会把它和报告记录关联起来。这样当某个版本发布后出现线上问题时你可以反查该版本对应的测试记录看看是否早有失败的用例只是上线时没有注意到。实际操作的时候在CLI后面多加一个参数就行openmontage submit --server $OM_SERVER --project 订单服务 --branch main --commit $GIT_COMMIT --report report.xml这一步看着简单但非常有用因为它把测试结果和版本交付真正串在了一起。有一次我们排查线上问题最后就是靠这个提交关联找到了一个“测试环境通过、生产环境失败”的用例节省了大量回溯时间。7. 踩坑记录时区、路径、格式兼容性7.1 最近一天的曲线始终是空的接入后的第三天我发现趋势图上“今天”这一格永远是空的但数据库里明明有记录。排查后确认是时区问题服务端容器默认使用UTC而CI构建所在主机使用的是本地时区导致每天上报的记录被归到了UTC的当天也就是本地时间的凌晨或前一日。解决办法是在docker-compose.yml里给服务端容器显式设置时区environment: - TZAsia/Shanghai同时在CLI上报时加上时区参数确保报告里的执行时间也被正确解析。这个坑只会在数据积累后暴露越早处理越好不然等你发现的时候前几天的趋势图已经错位了。7.2 Windows上报的路径分隔符导致失败用例打不开团队里有同事用Windows本机跑CLI上报上传后仪表盘能显示用例名但点进失败详情时堆栈文件路径全是反斜杠点击之后打不开。原因是OpenMontage处理文件路径时默认按Unix风格的正斜杠解析。我当时的处理方式是在CI脚本里做一次路径归一化sed -i s/\\/\//g report.xml在Linux的CI机器上执行就能把反斜杠统一成斜杠。虽然这不是一个特别优雅的解法但胜在简单、可控不需要改OpenMontage的服务端代码。7.3 JUnit XML里缺失属性值被当作失败另一种情况是某次接入新框架时生成的JUnit XML里部分testcase节点没有time属性。OpenMontage在解析时严格按schema校验缺失字段就整条记录解析失败导致该次上报全部失败。定位方法很简单用本地的XML解析工具跑一遍报告确认哪些节点缺少必填属性然后在上报前补上默认值。我的解决办法是在CI里加了小脚本用Python的xml.etree把缺失的time属性补成0import xml.etree.ElementTree as ET tree ET.parse(report.xml) for tc in tree.iter(testcase): tc.set(time, tc.get(time, 0)) tree.write(report_fixed.xml)这样既不用改OpenMontage源码也不影响原测试框架的输出。处理完这类格式问题之后新接入一个测试框架的耗时基本能控制在半小时以内。7.4 数据库越跑越大之后的处理OpenMontage默认保留所有历史记录跑了大半年之后我的PostgreSQL数据目录大概占了几十GB。好消息是它提供了数据清理接口可以通过一条命令按项目加时间范围清理旧记录。如果你没有设置定时清理建议加一个cron任务比如每天凌晨清理90天前的记录0 2 * * * openmontage cleanup --server http://localhost:8080 --project 订单服务 --older-than 90d不过清理前一定要确认已把重要记录导出备份否则历史趋势会断档。我的做法是每季度导出一份JSON存档再执行清理既控制了存储成本又保留了可回溯的数据。我在这个项目上投入的时间前后算起来大概是两个周末真正难的部分不是启动服务而是让团队的CI和人员习惯都围绕它转起来。数据上报一旦变成自动化OpenMontage的长期价值就体现出来了。如果你正在评估这个工具我的建议是先拿一个项目试跑两周重点看失败用例列表和回归对比视图有没有帮你省下翻报告的时间再来决定是否全团队推广。 
长河君 · 2026/9/16 12:29:10 · 阅读 1.2k OpenMontage：把散落的CI测试报告聚合到一个看板
很多人第一次看到OpenMontage这个项目名会以为它跟视频剪辑有关。蒙太奇嘛自然是把零散的镜头剪成一个完整故事。我第一次接触这个开源工具时的第一反应也是这样但真正用了半年之后我反而觉得这个名字起得非常贴切——它干的活确实是“剪辑”只不过剪的不是视频素材而是散落在各个CI系统里的自动化测试报告。我手上维护的项目大概涉及6条产品线、3个测试框架每天的CI构建会产出将近20份测试结果文件。在没有OpenMontage之前我每天早上都要挨个打开Jenkins、GitLab CI翻进每个Job的归档目录去下载XML再手动汇总出通过率和失败用例。这活儿不难但极其耗时而且历史趋势、回归对比基本靠Excel手搓。在经历了一次因为漏看一个失败用例导致线上事故之后我开始认真寻找一款能把所有测试报告聚合到一个看板里的工具最终选定了开源方案OpenMontage。这篇文章会从实际使用角度完整记录我从下载部署到接入CI、再到做日常分析的全部经验。如果你是测试开发工程师、DevOps或者正在为“测试结果太分散”发愁的技术负责人这篇应该能帮你少走不少弯路。1. 每天早上翻三个CI系统找测试结果这个工具把我解放了1.1 一个测试负责人被报告淹没的真实场景先说说我遇到的实际问题这样你能判断OpenMontage是否适合你。我们团队的情况是这样的后端用pytest跑接口测试前端用Jest跑单元测试还有一套基于Selenium的端到端用例在Jenkins的另一个独立Job里运行。再加上移动端的Appium脚本整个测试体系横跨6个代码仓库、5个测试Job每轮构建完成之后产物里的测试报告格式也不一样有JUnit XML、有JSON、有HTML。最痛苦的是每天做结果同步。我要从不同的Job归档目录里把一个个XML文件下载下来然后用脚本解析最后拼到内部的在线表格里。问题在于很多失败不是当天就能修复的我需要在明天、后天继续跟进。而在线表格只能记文本摘要不能保留完整的堆栈信息每次要定位问题还得回头去CI系统翻原始日志。这样搞了几个月之后团队里几乎没有人愿意去维护那张表格了测试结果变成了“只有机器知道的秘密”。这个场景你应该不陌生你的项目可能没这么复杂但只要自动化用例超过几十条报告分散的问题就会开始拖累效率。1.2 OpenMontage是什么聚合、归档、可视化OpenMontage解决的核心问题就是一句话把各种格式、各个来源的测试结果统一收进来形成一个可检索、可追溯、可对比的历史看板。我一开始以为它只是一个“报告格式转换器”实际上手后发现它的定位比我想象的更完整。它做的事情可以拆成三块聚合通过适配器或命令行工具接收JUnit XML、JSON等格式的测试结果归档把每次上报结果按项目、分支、执行时间存储进数据库形成历史数据可视化提供Web仪表盘展示通过率、失败用例、执行耗时等指标支持按模块和时间范围筛选。用一句话概括它像是一个测试报告专用的“档案馆展示厅”。你不需要再自己去维护在线表格也不用反复去CI系统里翻归档。顺便说一句OpenMontage部署起来并不重单人维护完全没问题。后面我会讲具体的部署和接入方式。1.3 什么情况下建议引入它结合我自己的经验如果你的团队符合下面任意一条就可以认真评估这个工具测试用例分布在多个代码仓库且使用了不止一种测试框架CI任务数量超过5个手工汇总报告已经变成每周固定负担测试失败后需要回到Jenkins或GitLab里翻原始日志流转链路太长管理层或合作方经常要测试通过率数据而你不想再花半小时手搓Excel。反过来如果你们只有一个项目、一个测试框架、用例量也不大那直接用CI系统自带的看板就够了。OpenMontage的收益来自“聚合”和“历史对比”数据量太小的时候这层价值不明显。这算是我比较真诚的劝退建议。2. 下载OpenMontage之前先弄清楚这4个核心边界2.1 它解决什么问题又不解决什么问题很多工具死于预期错位。OpenMontage也不是万能的先划清边界再决定是否引入。它能解决的测试报告格式不统一难以集中查看缺少历史数据无法判断测试稳定性趋势失败用例信息分散需要逐个CI系统跳转测试结果需要定期同步给团队或领导人工整理耗时。它不能解决的不会自动修复失败的用例不做测试用例的管理和编排那是用例管理平台的事不做实时日志流它消费的是构建结束后的报告文件而不是实时输出不是测试计划系统不负责调度CI任务。我见过不少团队把OpenMontage当成测试平台的一站式解决方案后来发现它管不了用例设计又去找别的系统折腾了好几周。建议你在做出决定之前先明确你要的是“结果的集中展示与追溯”而不是“测试过程的全面管理”。2.2 服务端、适配器、CLI上报器三件套从部署视角看OpenMontage由三部分组成。第一部分是服务端承载Web仪表盘和存储。它负责接收上报的测试结果、解析并写入数据库、提供查询接口和页面展示。日常维护只需要保证这个服务在线并且数据库有备份。第二部分是适配器作用是把不同的测试报告格式转换成OpenMontage的统一数据模型。系统自带了一批常用格式的解析器比如JUnit XML、Cucumber JSON等如果你的测试框架输出的是自定义格式则需要写一个简单的转换脚本。第三部分是CLI上报器这是最常接触的部分。在CI脚本里调用这个命令行工具指定报告文件路径和目标项目它就会把结果推送到服务端。我在实际使用中绝大多数场景只用得到这个CLI。这三件套的划分有一个好处上报入口足够轻CI里只需要多执行一条命令而已不需要引入重级依赖。2.3 支持哪些报告格式和运行环境目前OpenMontage开箱即用的报告格式覆盖了主流测试框架测试框架原始报告格式接入方式pytestJUnit XMLCLI/适配器自动解析Java/JUnitJUnit XMLCLI/适配器自动解析JestJSON或JUnit XML先转换后上报CucumberJSON适配器直接解析Postman/NewmanJSON适配器直接解析运行环境方面服务端推荐在Linux服务器上部署官方提供Docker镜像如果只是想在自己电脑上试用用Docker Desktop也可以。CLI工具是Python编写的所以装有Python3.8的机器都能跑Windows和macOS也都能配合CI使用。提示不要一上来就纠结支持多少种格式。把最常用的pytest/JUnit打通已经能覆盖绝大多数团队的诉求。3. 第一次启动Docker Compose部署全流程3.1 环境准备和目录规划我推荐的部署方式是Docker Compose因为OpenMontage除了自身的应用容器还依赖一个数据库容器用Compose可以把这两个编成一整套启动和升级都方便。到GitHub的Release页面下载最新的docker-compose.yml模板之前先想清楚几个问题数据目录放在哪里。我习惯在/home/你的用户名/opt/openmontage下创建一个data目录用于持久化数据库文件端口是否冲突。默认面板端口是8080如果你本机已经占了就在Compose文件里映射成别的宿主机端口数据库账号密码。首次部署时设置好避免后面再改。这些配置看起来都是小事但后期维护时影响很大。我见过同事图省事把数据目录放到/tmp下面结果服务器一重启所有历史报告全没了那个教训相当惨痛。3.2 docker-compose.yml详解下面这个Compose文件是我在生产环境使用的精简版本包含了应用服务和PostgreSQL数据库服务version: 3.8 services: openmontage-server: image: ghcr.io/openmontage/server:latest container_name: openmontage-server ports: - 8080:8080 environment: - DATABASE_URLpostgresql://om:om_passwordpostgres/om volumes: - ./data/uploads:/app/uploads depends_on: - postgres restart: unless-stopped postgres: image: postgres:15 container_name: openmontage-postgres environment: - POSTGRES_USERom - POSTGRES_PASSWORDom_password - POSTGRES_DBom volumes: - ./data/db:/var/lib/postgresql/data restart: unless-stopped注意几个关键点环境变量DATABASE_URL告诉服务端往哪里连接数据库如果不设置服务端会使用内置的SQLite但这更适合单机试用多人团队建议直接上PostgreSQL。uploads目录用于存放上报时附带的一些独立文件比如截图、附件别把它放在容器内部否则重建容器就丢了。启动命令很简单docker compose up -d docker compose ps等两个容器都进入healthy状态浏览器打开http://localhost:8080应该能看到OpenMontage的登录页。3.3 pip安装方案的取舍如果你只是想在开发机上快速体验不想碰Docker也可以用pip安装CLI和服务端pip install openmontage openmontage serve --port 8080不过这个方案有几个限制服务端需要你在本机安装好PostgreSQL并自己初始化数据库升级时要手动处理依赖版本没有现成的日志轮转和健康检查。我的建议是临时试用用pip正式使用直接上Docker Compose。我最初是在MacBook上用pip装的跑demo没问题但后来挪到团队服务器时就改成了Docker。理由很简单Compose文件提交到Git之后新同事一条命令就能拉起完整环境不需要再读一长串安装文档。4. 把第一份测试报告喂进去从pytest到可视化看板4.1 生成标准JUnit XML报告成功启动服务之后重点就变成了“下载后如何使用”也就是怎么把测试结果送进去。第一步先让测试框架输出OpenMontage能识别的报告格式。拿pytest举例在项目根目录执行pip install pytest pytest --junitxmlreport.xml tests/执行完之后目录下会生成一个report.xml文件里面记录了每个用例的名称、执行耗时、状态和失败信息。如果你用的是Jest需要额外装一个转换器才能输出JUnit格式npm install --save-dev jest-junit JEST_JUNIT_OUTPUT_FILEjest-report.xml npx jest --ci得到XML文件之后最好手动打开看一眼确认它至少包含testsuite和testcase节点这是OpenMontage解析的基础。4.2 CLI上报与REST API两种方式拿到报告文件后上报方式有两种。第一种是CLI适合手工操作或写进脚本openmontage submit --server http://localhost:8080 \ --project 订单服务 \ --branch main \ --report report.xml上报成功后CLI会返回一条记录ID例如Record #1024 created. View at http://localhost:8080/projects/订单服务/records/1024第二种是REST API适合编程调用curl -X POST http://localhost:8080/api/v1/records \ -H Content-Type: multipart/form-data \ -F project订单服务 \ -F branchmain \ -F filereport.xml两种方式实质相同CI脚本里我建议用CLI因为参数校验和错误提示更友好。我第一次用curl传文件时字段名写错了服务端没有给出有效的错误信息排查了十几分钟才发现是-F参数不对。4.3 仪表盘页面元素逐项解读第一次打开项目页面你会发现界面并不复杂核心元素就几块总览卡片显示当前项目的用例总数、通过率、失败数、执行总时长最近趋势图按天展示通过率变化曲线这是判断测试稳定性的第一入口失败用例列表列出最近一次执行中的失败用例点击可查看完整堆栈记录时间线按时间倒序排列每次上报的记录可以展开看详细数据。我建议你第一次接入后先只关注“失败用例列表”。因为趋势图在数据量不足时意义不大至少得等积累一周的记录才能看出规律。另外有个小细节如果你用中文作为项目名URL里的中文会被浏览器转码看起来很长但不影响使用。我自己习惯用一句话做项目名比如“订单服务接口测试”在筛选列表里更好认。5. 接入CI流水线每天自动生成团队测试看板5.1 集成方式选择Agent模式上报单独手工上报意义有限真正的价值在于把上报动作嵌到CI流水线里让每次构建结束自动生成记录。在选集成方式时我推荐的是“Agent模式”在CI机器上安装openmontage CLI然后在流水线脚本里把执行完测试后的上报命令作为额外一个Step加进去。这样做的优点是CI的配置文件改动很少测试任务本身不受影响缺点是每台CI机器都需要安装CLI不过一条pip命令就能解决。另一种方式是直接调用REST API连CLI都不用装适合容器化程度高、不方便预装依赖的流水线。两种方式我都跑过最终统一用了Agent模式因为出错时能在CLI那里看到更明确的提示。5.2 Jenkins Pipeline配置示例这是一段我实际用的Jenkins Pipeline片段stage(测试) { steps { sh pytest --junitxmlreport.xml tests/ } } stage(上报结果) { steps { sh openmontage submit --server $OM_SERVER --project 订单服务 --branch main --report report.xml } }这里有个细节我把服务端地址和项目名都做成了Jenkins的全局环境变量OM_SERVER等而不是硬编码在脚本里。这样换环境、换项目名的时候只需要改配置不需要改Pipeline代码。5.3 GitLab CI配置示例GitLab CI的配置也类似在.gitlab-ci.yml里增加一个stagereport: stage: report image: python:3.11-slim before_script: - pip install openmontage script: - openmontage submit --server ${OM_SERVER} --project 订单服务 --branch ${CI_COMMIT_BRANCH} --report report.xml only: - main我特别用到了CI_COMMIT_BRANCH这个预定义变量这样每次提交所在的分支名会自动传给OpenMontage不需要人肉维护。接入CI后的效果是每日构建完成所有测试结果自动归档我可以随时打开浏览器看到最新的通过率而不再等某个同事手工同步表格。这个变化对团队最大的影响不是省了时间而是测试数据的可信度提升了——记录是自动生成的没人质疑它是不是漏掉了哪次执行。6. 数据多了以后我只看这几个分析视图6.1 失败用例的归类与筛选数据积累一周之后你会发现仪表盘上最常看的不是通过率而是失败用例列表。OpenMontage支持按照模块、分支、时间来筛选失败项这时候一定要做的一件事是给高频失败用例打标签。我自己的习惯是每个周五花10分钟过一遍本周的失败列表把失败原因分成几类稳定性问题偶发超时、端口冲突、外部依赖抖动环境问题测试数据被污染、数据库状态不一致真实缺陷断言失败、接口返回值变化。打上标签后后续再出现同类失败就能快速判断是不是已知问题。这个过程虽然只是记录层面的操作但它让测试结果从“机器数据”变成了“团队资产”。后面复盘版本质量时这些标签直接决定了你能不能在5分钟内给出结论。6.2 三个仪表盘核心视图趋势、回归、耗时积累的数据量上来之后有三个视图的参考价值最大。趋势视图最适合回答“测试是不是越来越稳定”这类问题。单看一天可能因为环境或偶发失败得出错误结论但看两周以上的通过率曲线就能识别出测试是否存在劣化趋势。我之前就遇到过某个模块的通过率从98%慢慢掉到90%的情况单日看都不算异常拉长到一个月的曲线后问题立刻浮现。回归对比视图是OpenMontage相比手工Excel最占优的地方。它能直接把当前记录的失败用例跟上次记录对比标出“新增失败”“持续失败”“已恢复”三组。我在版本发布前一定会看这个视图持续失败的用例数量基本可以代表历史欠债新增失败则需要警惕是否被这次改动影响。耗时视图则用来发现执行时间的异常增长。我之前曾经通过耗时曲线发现某个接口测试越来越慢最后定位到是测试环境的连接池配置被误改这类问题如果只看通过率很难察觉。6.3 测试结果与代码提交的关联使用了一段时间后我建议把CI里的提交号如Git提交哈希作为参数一并上报。OpenMontage会把它和报告记录关联起来。这样当某个版本发布后出现线上问题时你可以反查该版本对应的测试记录看看是否早有失败的用例只是上线时没有注意到。实际操作的时候在CLI后面多加一个参数就行openmontage submit --server $OM_SERVER --project 订单服务 --branch main --commit $GIT_COMMIT --report report.xml这一步看着简单但非常有用因为它把测试结果和版本交付真正串在了一起。有一次我们排查线上问题最后就是靠这个提交关联找到了一个“测试环境通过、生产环境失败”的用例节省了大量回溯时间。7. 踩坑记录时区、路径、格式兼容性7.1 最近一天的曲线始终是空的接入后的第三天我发现趋势图上“今天”这一格永远是空的但数据库里明明有记录。排查后确认是时区问题服务端容器默认使用UTC而CI构建所在主机使用的是本地时区导致每天上报的记录被归到了UTC的当天也就是本地时间的凌晨或前一日。解决办法是在docker-compose.yml里给服务端容器显式设置时区environment: - TZAsia/Shanghai同时在CLI上报时加上时区参数确保报告里的执行时间也被正确解析。这个坑只会在数据积累后暴露越早处理越好不然等你发现的时候前几天的趋势图已经错位了。7.2 Windows上报的路径分隔符导致失败用例打不开团队里有同事用Windows本机跑CLI上报上传后仪表盘能显示用例名但点进失败详情时堆栈文件路径全是反斜杠点击之后打不开。原因是OpenMontage处理文件路径时默认按Unix风格的正斜杠解析。我当时的处理方式是在CI脚本里做一次路径归一化sed -i s/\\/\//g report.xml在Linux的CI机器上执行就能把反斜杠统一成斜杠。虽然这不是一个特别优雅的解法但胜在简单、可控不需要改OpenMontage的服务端代码。7.3 JUnit XML里缺失属性值被当作失败另一种情况是某次接入新框架时生成的JUnit XML里部分testcase节点没有time属性。OpenMontage在解析时严格按schema校验缺失字段就整条记录解析失败导致该次上报全部失败。定位方法很简单用本地的XML解析工具跑一遍报告确认哪些节点缺少必填属性然后在上报前补上默认值。我的解决办法是在CI里加了小脚本用Python的xml.etree把缺失的time属性补成0import xml.etree.ElementTree as ET tree ET.parse(report.xml) for tc in tree.iter(testcase): tc.set(time, tc.get(time, 0)) tree.write(report_fixed.xml)这样既不用改OpenMontage源码也不影响原测试框架的输出。处理完这类格式问题之后新接入一个测试框架的耗时基本能控制在半小时以内。7.4 数据库越跑越大之后的处理OpenMontage默认保留所有历史记录跑了大半年之后我的PostgreSQL数据目录大概占了几十GB。好消息是它提供了数据清理接口可以通过一条命令按项目加时间范围清理旧记录。如果你没有设置定时清理建议加一个cron任务比如每天凌晨清理90天前的记录0 2 * * * openmontage cleanup --server http://localhost:8080 --project 订单服务 --older-than 90d不过清理前一定要确认已把重要记录导出备份否则历史趋势会断档。我的做法是每季度导出一份JSON存档再执行清理既控制了存储成本又保留了可回溯的数据。我在这个项目上投入的时间前后算起来大概是两个周末真正难的部分不是启动服务而是让团队的CI和人员习惯都围绕它转起来。数据上报一旦变成自动化OpenMontage的长期价值就体现出来了。如果你正在评估这个工具我的建议是先拿一个项目试跑两周重点看失败用例列表和回归对比视图有没有帮你省下翻报告的时间再来决定是否全团队推广。