鸿蒙 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测试加载实际页面。测试前注入一个最小原生代理：

await page.addInitScript(() => {
  const host = window as unknown as EditorTestWindow;
  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、定时器和渲染器运行。

await page.goto('/');
await page.locator('.cm-editor').waitFor();

等待编辑器 DOM 而不是固定 sleep，降低不同机器上的时间波动。只有快照节流语义本身需要等待计时器，其余交互尽量依赖条件断言。

二十项回归覆盖的不是页面数量

当前 Web自动化包含二十项，覆盖以下主链路：

• 源码、分栏和预览模式。
• Markdown 净化和脚本不执行。
• GFM表格、删除线、自动链接、只读任务列表。
• 系统深色与显式主题覆盖。
• 中文输入、撤销、重做和保存命令快照。
• 两秒内恢复快照和恢复文档脏状态。
• 新文档撤销历史、相同内容重做历史隔离。
• 多标签正文、撤销和未保存状态隔离。
• 大小写、整词、正则、当前替换和全部替换。
• 标题偏移跳转与预览切回源码。
• 双向同步滚动与关闭同步。
• CRLF编辑语义。
• 撤销回基线和保存后新基线。
• 大文档保护。
• 窄窗口分栏布局。
• 安全独立 HTML导出和打印预览。
• 生产包不引用外部子资源。

测试数量本身不是质量指标。二十项有价值，是因为每项对应一个可导致数据损坏、功能失效或安全退化的明确契约。后续新增测试应来自新需求、缺陷复现和风险分析，而不是为了提高数字。

脏状态必须用行为验证

编辑器保存基线最容易出现“星号只会亮、不会灭”。测试先设置基线、输入，再撤销：

await page.evaluate(() =>
  host.OhMarkdownEditor.setDocument('基线')
);
await page.locator('.cm-content').click();
await page.keyboard.insertText('修改');
await page.evaluate(() =>
  host.OhMarkdownEditor.undo()
);
await page.waitForTimeout(200);

const calls = await page.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-b：

host.OhMarkdownEditor.setSessionDocument(
  'session-a',
  '文档甲'
);
// 输入“修改”
host.OhMarkdownEditor.activateSession(
  'session-b',
  '文档乙'
);
// 输入“新增”

切回 a后撤销，正文必须变回“文档甲”；再切到 b，仍然是“文档乙新增”。这项用例同时证明 EditorState、正文与历史归属于 sessionId。

测试还需要继续增加选区、滚动和重做隔离。已有用例建立最低安全线，不意味着会话所有状态都已覆盖。测试报告应区分自动断言、调用链审查和模拟器操作，不能把三者混写成“全部自动化”。

安全测试直接检查危险结果不存在

Markdown 安全用例输入脚本：

const source =
  '# HarmonyOS Markdown\n\n' +
  'Hello **world**.\n\n' +
  '<script>' +
  'window.unsafeScriptExecuted=true' +
  '</script>';

预览后断言标题与加粗存在、script 节点数量为零、全局标记未定义。不能只检查 DOM 没有脚本标签，因为脚本可能先执行再被清理；全局副作用断言补上执行层证据。

HTML导出还检查：存在 doctype和 CSP；标题、strong和本地图片保留；不存在 script、javascript: URI和外部 stylesheet。功能允许列表与危险拒绝列表同时验证，避免安全修复把正常 Markdown全部删掉。

生产包测试读取实际打进 entry/src/main/resources/rawfile/editor/index.html 的文件：

const productionHtml = readFileSync(
  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文件系统上测，因为产品使用 HarmonyOS fileIo、AtomicFile与 URI。ohosTest在应用沙箱创建文件，通过 Core File Kit读写。

原始 BOM与 CRLF 用例先读取十六进制：

const original =
  '\uFEFF# 鸿蒙 PC\r\n\r\n第一行\r\n第二行\r\n';
await writeRawText(testPath, original);
const beforeHex = await readBytesAsHex(testPath);
const opened = await readUtf8Document(testPath);

expect(opened.format.hasUtf8Bom).assertTrue();
expect(opened.format.lineEnding)
  .assertEqual(LineEnding.CRLF);

await writeUtf8Document(
  testPath,
  opened.content,
  opened.format
);
expect(await readBytesAsHex(testPath))
  .assertEqual(beforeHex);

比较字节十六进制，而不是重新读取后只比较字符串。BOM是否保留只有字节层能确认。

故障注入用例删除目标目录制造写入失败，同时预先保存沙箱旧版本记录。写入失败后断言备份仍在，再重建目录并恢复旧内容。它验证“失败后可恢复”，而不是只断言 Promise抛错。

第四项 ohosTest验证 Markdown大纲：中文标题、Setext、代码围栏过滤和 UTF-16偏移。服务层纯函数可以快速跑，仍在 ArkTS运行时确认正则与字符串坐标。

统一脚本减少遗漏

Web验证脚本非常小：

#!/bin/sh

set -eu

ROOT_DIR="$(CDPATH= cd -- "$(dirname -- "$0")/.." && pwd)"

cd "$ROOT_DIR/web-editor"
npm run test:e2e

set -eu 让任一命令失败立即退出，未定义变量也失败。脚本从自身位置计算根目录，不依赖调用者当前路径。

本机统一入口继续执行 Debug和 UnitTestBuild：

"$ROOT_DIR/scripts/verify-web.sh"
"$ROOT_DIR/scripts/build-debug.sh"

cd "$ROOT_DIR"
"$DEVECO_HOME/tools/hvigor/bin/hvigorw" \
  UnitTestBuild \
  --mode module \
  -p product=default \
  -p module=entry@default \
  -p buildMode=test \
  -p unitTestMode=true \
  --no-daemon

git diff --check

统一入口的价值不是少打几条命令，而是让开发者与流水线共享顺序，避免只跑最熟悉的一层。git diff --check 阻止空白错误进入提交。

设备 ohosTest的安装和运行仍需要 HDC与模拟器，尚未完全并入脚本。后续可增加目标检测、测试 HAP安装、执行和结果提取，但脚本不能在没有设备时假装通过。

GitCode 流水线只承担 Web层

当前 .gitcode-ci.yml 配置使用 Playwright官方镜像：

stages:
  - test

web_editor_regression:
  stage: test
  image: mcr.microsoft.com/playwright:v1.61.1-noble
  script:
    - 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.md：ATX、Setext、围栏与中文偏移。
• security-baseline.md：脚本、危险协议和嵌入标签。

测试代码中的最小字符串便于定位，文件语料适合模拟器打开、人工比较和版本差异。每次发现缺陷，应把最小复现加入对应语料，再补自动断言。这样修复不会只存在于一次聊天或截图中。

语料需要保持小而有目的，不能把随机大型文档提交进测试目录。性能大文件可以在脚本运行时生成，避免仓库膨胀；字节语料则要明确 BOM和换行，普通编辑器保存它可能改变内容，因此最好由测试代码构造。

鸿蒙 PC 应用基线截图

下图来自 MateBook Pro 2in1模拟器，展示实际 HAP中的 ArkUI工作台与离线 CodeMirror编辑区。自动化最终保护的不是测试页面，而是这套进入鸿蒙 PC 应用的编辑能力。

应用截图是设备层证据之一，不替代自动化结果。每个关键用例保存对应截图或报告，才能在 UI变化、平台升级和回归失败时知道基线是什么。截图前还要清理个人路径和文档内容，技术证据不能制造隐私泄露。

测试结果与退出条件

提交 3a9146e 的本地基线为 Web 20/20、设备 ohosTest 4/4，Debug、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 编辑器要长期做大，质量不是发布前的一轮点击，而是每次改动都能重新回答“用户文档是否仍然安全”的工程能力。