鸿蒙 PC Markdown 编辑器自动化测试：Playwright、ohosTest 与构建门禁

鸿蒙 PC Markdown 编辑器自动化测试Playwright、ohosTest 与构建门禁编辑器测试不能只验证应用能启动。真正的风险集中在用户数据撤销是否跨文档、CRLF 是否保留、恶意 Markdown 是否进入 DOM、保存期间继续输入是否仍显示未保存、分栏滚动是否递归、五兆文档是否触发保护。只有把这些行为写成可重复断言版本迭代才不会依赖一次次人工回忆。本文基于鸿蒙 PC Markdown 编辑器 OhMarkdown拆解 Web 内核、ArkTS 服务、模拟器证据与构建脚本组成的质量基线说明哪些能力可以在 Linux Web Runner 验证哪些必须依赖 DevEco Studio 与鸿蒙设备。完整代码位于 https://gitcode.com/VON-/codex_md_oh本文对应提交3a9146e。测试分层由故障边界决定OhMarkdown 不是纯 Web 页面也不是纯 ArkUI 应用。编辑内核运行在 ArkWeb文件、窗口、系统选择器和打印位于原生层。把所有测试都塞进模拟器会很慢难以定位只跑 Playwright又无法证明 HarmonyOS API可用。当前质量体系分为四层Playwright验证 CodeMirror、Markdown 渲染、搜索、会话状态和 Web安全边界。ohosTest验证 ArkTS 文档格式、文件写入故障恢复和大纲偏移。Hvigor Debug、Release与 UnitTestBuild验证 ArkTS 编译、资源和 HAP产物。MateBook Pro 2in1 模拟器验证系统选择器、强杀恢复、主题、文件树和桌面交互。每层负责自己最接近的风险。正则替换不需要每次启动模拟器文件夹授权不能只在 Chromium 中伪造BOM字节一致应在 Core File Kit真实写入上测试主题是否原生与 Web同屏一致需要设备截图。这种分层不是追求测试种类而是减少“测试通过但没有覆盖真实边界”。Web 自动化运行真实生产逻辑Web 编辑器使用 Vite 与 TypeScript构建Playwright测试加载实际页面。测试前注入一个最小原生代理awaitpage.addInitScript((){consthostwindowasunknownasEditorTestWindow;host.bridgeCalls[];host.ohMarkdownBridge{onReady:()host.bridgeCalls.push({type:ready}),onState:(wordCount)host.bridgeCalls.push({type:state,wordCount}),onChange:(wordCount,dirty)host.bridgeCalls.push({type:change,wordCount,dirty}),onSnapshot:(content,revision)host.bridgeCalls.push({type:snapshot,content,revision}),onCommand:(command,content)host.bridgeCalls.push({type:command,command,content})};});替身不实现 ArkTS业务只记录 Web 发出的协议事件。测试可以断言中文输入后 onChange 字数、dirty、恢复快照 revision和保存命令正文。它不是把编辑器函数 mock掉而是让真实 CodeMirror、定时器和渲染器运行。awaitpage.goto(/);awaitpage.locator(.cm-editor).waitFor();等待编辑器 DOM 而不是固定 sleep降低不同机器上的时间波动。只有快照节流语义本身需要等待计时器其余交互尽量依赖条件断言。二十项回归覆盖的不是页面数量当前 Web自动化包含二十项覆盖以下主链路源码、分栏和预览模式。Markdown 净化和脚本不执行。GFM表格、删除线、自动链接、只读任务列表。系统深色与显式主题覆盖。中文输入、撤销、重做和保存命令快照。两秒内恢复快照和恢复文档脏状态。新文档撤销历史、相同内容重做历史隔离。多标签正文、撤销和未保存状态隔离。大小写、整词、正则、当前替换和全部替换。标题偏移跳转与预览切回源码。双向同步滚动与关闭同步。CRLF编辑语义。撤销回基线和保存后新基线。大文档保护。窄窗口分栏布局。安全独立 HTML导出和打印预览。生产包不引用外部子资源。测试数量本身不是质量指标。二十项有价值是因为每项对应一个可导致数据损坏、功能失效或安全退化的明确契约。后续新增测试应来自新需求、缺陷复现和风险分析而不是为了提高数字。脏状态必须用行为验证编辑器保存基线最容易出现“星号只会亮、不会灭”。测试先设置基线、输入再撤销awaitpage.evaluate(()host.OhMarkdownEditor.setDocument(基线));awaitpage.locator(.cm-content).click();awaitpage.keyboard.insertText(修改);awaitpage.evaluate(()host.OhMarkdownEditor.undo());awaitpage.waitForTimeout(200);constcallsawaitpage.evaluate(()host.bridgeCalls);expect(calls.at(-1)).toEqual({type:change,wordCount:2,dirty:false});断言 Bridge最后状态而不是检查一个 Web内部变量。这样能证明 updateListener、Text基线比较和原生通知链共同生效。保存后新基线用另一项测试输入“已保存”调用 requestCommand与 markSaved再输入“后续”并撤销最终 dirty应回到 false。这个路径覆盖保存请求时 Text快照而不是只测初始打开。多会话测试关注历史串线多标签视觉可以人工看到最严重错误却是撤销历史串线。自动化分别编辑 session-a和 session-bhost.OhMarkdownEditor.setSessionDocument(session-a,文档甲);// 输入“修改”host.OhMarkdownEditor.activateSession(session-b,文档乙);// 输入“新增”切回 a后撤销正文必须变回“文档甲”再切到 b仍然是“文档乙新增”。这项用例同时证明 EditorState、正文与历史归属于 sessionId。测试还需要继续增加选区、滚动和重做隔离。已有用例建立最低安全线不意味着会话所有状态都已覆盖。测试报告应区分自动断言、调用链审查和模拟器操作不能把三者混写成“全部自动化”。安全测试直接检查危险结果不存在Markdown 安全用例输入脚本constsource# HarmonyOS Markdown\n\nHello **world**.\n\nscriptwindow.unsafeScriptExecutedtrue/script;预览后断言标题与加粗存在、script节点数量为零、全局标记未定义。不能只检查 DOM 没有脚本标签因为脚本可能先执行再被清理全局副作用断言补上执行层证据。HTML导出还检查存在 doctype和 CSP标题、strong和本地图片保留不存在 script、javascript:URI和外部 stylesheet。功能允许列表与危险拒绝列表同时验证避免安全修复把正常 Markdown全部删掉。生产包测试读取实际打进entry/src/main/resources/rawfile/editor/index.html的文件constproductionHtmlreadFileSync(resolve(process.cwd(),../entry/src/main/resources/rawfile/editor/index.html),utf-8);expect(productionHtml).not.toMatch(/script[^]src/i);expect(productionHtml).not.toMatch(/link[^]rel[]stylesheet[]/i);expect(productionHtml).toContain(OhMarkdownEditor);这项检查锁住离线单文件约束。源码测试通过但构建产物仍引用 CDN会在无网络鸿蒙 PC 上白屏产物断言比检查 package.json更接近发布事实。大文档测试验证降级而不是速度Web用例创建五兆字符文档尝试切到预览host.OhMarkdownEditor.setDocument(a.repeat(5*1024*1024));host.OhMarkdownEditor.setMode(preview);预期工作区仍为 source、编辑器可见、预览隐藏、Bridge字数为 -1、打印准备返回 false。测试锁定的是保护策略超过边界不渲染、不统计、不打印。它不证明十兆文件在三秒内加载也不测内存。性能指标需要 Release模拟器记录读取、编辑器加载和进程内存。功能自动化与性能测试使用同一个边界常量但证据形式不同。ohosTest 验证 Core File Kit真实行为文档字节一致不能只在 Node文件系统上测因为产品使用 HarmonyOSfileIo、AtomicFile与 URI。ohosTest在应用沙箱创建文件通过 Core File Kit读写。原始 BOM与 CRLF 用例先读取十六进制constoriginal\uFEFF# 鸿蒙 PC\r\n\r\n第一行\r\n第二行\r\n;awaitwriteRawText(testPath,original);constbeforeHexawaitreadBytesAsHex(testPath);constopenedawaitreadUtf8Document(testPath);expect(opened.format.hasUtf8Bom).assertTrue();expect(opened.format.lineEnding).assertEqual(LineEnding.CRLF);awaitwriteUtf8Document(testPath,opened.content,opened.format);expect(awaitreadBytesAsHex(testPath)).assertEqual(beforeHex);比较字节十六进制而不是重新读取后只比较字符串。BOM是否保留只有字节层能确认。故障注入用例删除目标目录制造写入失败同时预先保存沙箱旧版本记录。写入失败后断言备份仍在再重建目录并恢复旧内容。它验证“失败后可恢复”而不是只断言 Promise抛错。第四项 ohosTest验证 Markdown大纲中文标题、Setext、代码围栏过滤和 UTF-16偏移。服务层纯函数可以快速跑仍在 ArkTS运行时确认正则与字符串坐标。统一脚本减少遗漏Web验证脚本非常小#!/bin/shset-euROOT_DIR$(CDPATH cd -- $(dirname--$0)/..pwd) cd $ROOT_DIR/web-editornpmrun test:e2eset -eu让任一命令失败立即退出未定义变量也失败。脚本从自身位置计算根目录不依赖调用者当前路径。本机统一入口继续执行 Debug和 UnitTestBuild$ROOT_DIR/scripts/verify-web.sh$ROOT_DIR/scripts/build-debug.shcd$ROOT_DIR$DEVECO_HOME/tools/hvigor/bin/hvigorw\UnitTestBuild\--modemodule\-pproductdefault\-pmoduleentrydefault\-pbuildModetest\-punitTestModetrue\--no-daemongitdiff--check统一入口的价值不是少打几条命令而是让开发者与流水线共享顺序避免只跑最熟悉的一层。git diff --check阻止空白错误进入提交。设备 ohosTest的安装和运行仍需要 HDC与模拟器尚未完全并入脚本。后续可增加目标检测、测试 HAP安装、执行和结果提取但脚本不能在没有设备时假装通过。GitCode 流水线只承担 Web层当前.gitcode-ci.yml配置使用 Playwright官方镜像stages:-testweb_editor_regression:stage:testimage:mcr.microsoft.com/playwright:v1.61.1-noblescript:-cd web-editor-npm ci--ignore-scripts-npm run test:e2e缓存web-editor/node_modules/key包含提交分支。Linux Runner可以验证 TypeScript、Vite与Chromium不包含 DevEco Studio macOS环境因此不能宣称鸿蒙 HAP也在 CI中通过。截至本文基线流水线配置已经入库但远程 Runner首次执行结果尚未确认。准确说法是“CI配置已建立”不是“远程流水线已通过”。质量文档把该项保持 In Progress直到平台真实产生成功结果。若 GitCode实际配置文件名、Runner权限或镜像拉取策略不同需要根据远程日志修正。CI不是因为仓库里出现 YAML就自动成立。版本化 Markdown 语料项目保存四类基线文件commonmark-baseline.md基础标题、段落、列表、引用、代码。gfm-baseline.md表格、删除线、链接和任务项。outline-baseline.mdATX、Setext、围栏与中文偏移。security-baseline.md脚本、危险协议和嵌入标签。测试代码中的最小字符串便于定位文件语料适合模拟器打开、人工比较和版本差异。每次发现缺陷应把最小复现加入对应语料再补自动断言。这样修复不会只存在于一次聊天或截图中。语料需要保持小而有目的不能把随机大型文档提交进测试目录。性能大文件可以在脚本运行时生成避免仓库膨胀字节语料则要明确 BOM和换行普通编辑器保存它可能改变内容因此最好由测试代码构造。鸿蒙 PC 应用基线截图下图来自 MateBook Pro 2in1模拟器展示实际 HAP中的 ArkUI工作台与离线 CodeMirror编辑区。自动化最终保护的不是测试页面而是这套进入鸿蒙 PC 应用的编辑能力。应用截图是设备层证据之一不替代自动化结果。每个关键用例保存对应截图或报告才能在 UI变化、平台升级和回归失败时知道基线是什么。截图前还要清理个人路径和文档内容技术证据不能制造隐私泄露。测试结果与退出条件提交3a9146e的本地基线为 Web 20/20、设备 ohosTest 4/4Debug、Release与 UnitTestBuild成功。构建成功说明当前代码与 API 24工具链兼容测试通过说明已覆盖契约在该环境成立。但第二阶段仍不能仅凭这些数字结束。G2-08还要求远程 CI首次通过并完成十名内部用户连续七天真实文档试用。自动化善于覆盖已知输入内部使用会暴露文件来源、目录规模、输入法、窗口习惯和恢复路径中的未知组合。质量门禁必须保留未完成项。把“测试全部通过”与“阶段退出条件全部满足”分开记录能防止工程团队为了里程碑把外部验证悄悄改成可选项。下一步应增加什么当前基线仍缺少保存并关闭选择器取消的设备自动化多标签完整恢复工作区两千项规模系统主题前后台多轮切换触控板同步滚动压力自由窗口多档宽度真实鸿蒙 PC而不只是2in1模拟器崩溃恢复重复强杀文件外部修改冲突CI上的 ArkTS构建。新增测试优先级应按数据损失和高频工作流排序。比如保存失败保留缓冲区比按钮悬停颜色更优先多会话恢复比边缘 Markdown排版更优先。UI视觉回归也有价值但不能挤占文件安全测试。长期还需要记录性能分位数、崩溃率和恢复成功率。单次加载345毫秒不能代表所有设备内部试用应匿名记录文档规模、操作结果和问题等级不收集正文。结语OhMarkdown 的质量基线把编辑内核、原生文件服务、构建工具和模拟器分开验证再通过统一脚本和版本化语料连接。Playwright锁定二十项 Web契约ohosTest验证四项 Core File Kit与 ArkTS行为Hvigor验证 HAP构建模拟器完成系统交互证据。这套体系最重要的特征是诚实Web Runner不冒充鸿蒙构建配置入库不冒充远程通过四项服务测试不冒充全应用自动化截图不冒充行为断言。鸿蒙 PC Markdown 编辑器要长期做大质量不是发布前的一轮点击而是每次改动都能重新回答“用户文档是否仍然安全”的工程能力。