当前位置：首页 > news >正文

鸿蒙 PC Markdown 编辑器测试设计：字节语料覆盖文本保真

news 2026/7/20 22:23:35

鸿蒙 PC Markdown 编辑器测试设计：字节语料覆盖文本保真

Markdown编辑器最危险的回归往往肉眼看不出来。BOM消失、CRLF变成 LF、末尾换行增加、非法 UTF-8被替换字符吞掉，预览可能完全相同，Git却显示整文件变化。测试语料必须同时覆盖 Markdown语义和底层字节，而不是只准备几篇“看起来复杂”的文章。

本文基于 OhMarkdown，说明如何组织 CommonMark、GFM、大纲、安全与字节格式语料，如何区分文件 fixture和运行时构造，以及怎样用十六进制比较验证未编辑保存。代码位于 https://gitcode.com/VON-/codex_md_oh，对应提交3a9146e。

语料按风险分类

项目保留四份可读 Markdown基线：

test-fixtures/markdown/ commonmark-baseline.md gfm-baseline.md outline-baseline.md security-baseline.md

CommonMark覆盖标题、强调、代码、链接、引用和列表；GFM覆盖表格、任务项、删除线和裸链接；大纲覆盖 ATX、Setext、普通正文井号和围栏伪标题；安全语料包含 script、javascript协议、iframe和允许的相对图片。

分类让失败可定位。若表格消失，先检查 GFM插件；若围栏标题进入大纲，检查解析状态机；若脚本进入 DOM，检查净化链。把全部语法塞进一个大文件，测试失败只知道“页面不同”。

可读 fixture 与字节 fixture 分工

普通.md文件适合代码审查、模拟器打开和截图，但 BOM、CRLF和 Mixed可能被开发者编辑器自动转换。关键字节语料由 ohosTest在运行时构造：

constoriginal='\uFEFF# 鸿蒙 PC\r\n\r\n'+'第一行\r\n第二行\r\n';awaitwriteRawText(testPath,original);

字符串明确写出 U+FEFF与\r\n，测试文件每次在应用沙箱生成，不依赖 Git checkout的 autocrlf。Mixed语料同样显式：

awaitwriteRawText(testPath,'第一行\r\n第二行\n第三行\r');

可读 fixture验证语法内容，运行时 fixture验证编码字节，两者不能互相替代。

CommonMark 基线保持最小

# CommonMark 基线 普通文本、**粗体**、*斜体*、`行内代码` 与链接。 > 引用内容 1. 有序列表 - 无序列表 ```ts const platform: string = 'HarmonyOS PC';

最小基线不追求覆盖整个规范，而是锁住产品承诺的高频结构。每次遇到解析缺陷，新增一个最小复现。语料太大时，依赖升级产生差异难以判断是预期还是回归。 代码围栏本身要包含反引号和语言标记，验证预览不会把内部内容当 Markdown。链接目标使用稳定示例域名，但自动化不发网络请求。 ## GFM 基线验证扩展边界 ```md | 能力 | 状态 | | --- | --- | | 表格 | 完成 | | 任务列表 | 完成 | - [ ] 待处理任务 - [x] 已完成任务 ~~已废弃内容~~ https://example.com/gfm

同一文件包含四项，可在模拟器一次观察。Playwright不只比较截图，而是断言 table、s、a和 checkbox结构，任务复选框 disabled与 checked状态同时验证。

后续扩充应加入对齐列、转义管道、嵌套任务和带括号 URL，但每个边缘项最好有独立断言。语料负责复现，测试负责解释预期。

大纲语料故意制造伪标题

正文中的 # 不是标题。 Setext 一级标题 ============== ```md # 代码围栏中的标题必须忽略

只放正常 `# A`无法证明解析器会排除错误输入。正文内井号、Setext与围栏标题同时出现，才能覆盖行首规则、前瞻和围栏状态。 设备测试再加入中文并比较 UTF-16 offset： ```ts expect(headings[2].offset).assertEqual( content.indexOf('### 目标标题') );

中文让 UTF-8字节与字符串索引分离，能发现坐标单位错误。

安全语料同时包含允许项

<script>window.fixtureScriptExecuted = true</script> [危险链接](javascript:alert('blocked')) <iframe src="https://example.com"></iframe> ![允许的相对图片](./assets/example.png)

安全测试不能只输入危险内容。相对图片是允许能力，净化后应保留安全 src和 alt。如果修复通过把所有标签属性删除，危险消失但功能也坏了。拒绝列表和允许列表必须同场验证。

还应增加 style、form、object、embed、事件属性、data URI与编码协议变体。每个新增渲染插件都要重新跑安全语料。

字节读取辅助函数

测试使用 Core File Kit读取全部字节转十六进制：

asyncfunctionreadBytesAsHex(path:string):Promise<string>{constfile=awaitfileIo.open(path,fileIo.OpenMode.READ_ONLY);try{conststat=awaitfileIo.stat(file.fd);constdata=newArrayBuffer(stat.size);constbytesRead=awaitfileIo.read(file.fd,data,{length:stat.size});constbytes=newUint8Array(data,0,bytesRead);letresult='';for(letindex=0;index<bytes.length;index+=1){result+=bytes[index].toString(16).padStart(2,'0');}returnresult;}finally{awaitfileIo.close(file);}}

十六进制字符串便于 Hypium比较，不受文本解码影响。测试规模很小，字符串拼接成本可接受；大文件可比较哈希而不是生成两倍长度文本。

未编辑保存的黄金断言

constbeforeHex=awaitreadBytesAsHex(testPath);constopened=awaitreadUtf8Document(testPath);awaitwriteUtf8Document(testPath,opened.content,opened.format);expect(awaitreadBytesAsHex(testPath)).assertEqual(beforeHex);