接手某内容管理平台编辑器重构的时候我拿到一批测试反馈单标题清一色都是“富文本测试代码块”。点开详细描述问题五花八门有的代码块粘贴进来样式全丢有的保存之后缩进错位有的代码高亮在部分浏览器里完全不渲染。这些 bug 单看起来单个都好解决但真正动手之后才发现代码块在富文本编辑器里是一块绕不开的“硬骨头”而且市面上能查到的系统性测试方案少之又少。这篇文章就把我做“富文本编辑器代码块功能测试”的全过程整理出来从前端的存储结构到手工用例设计再到自动化脚本落地最后附上我实际踩过的坑和排查思路希望对正在做编辑器测试的同学有点帮助。1. 代码块在富文本编辑器中为什么这么难测1.1 代码块的特殊位置既是“文本”又是“块”要设计测试方案先得搞懂被测对象到底特殊在哪。普通段落文本在富文本编辑器里基本是多个行内元素span、strong、em 之类的包裹起来的而代码块不同它是一个块级容器内部又要保留完整的空白符、换行符和缩进。这导致它在编辑器内部要遵循“块级元素”的规则比如敲回车时要在代码块内部换行而不是像普通段落那样直接拆分。更麻烦的是代码块内部不允许再插入段落标签、图片这类块级子元素。比如你在代码块中间点了回车编辑器应该在里面插入一个换行符而不是拆成两个代码块。这个行为在不同编辑器引擎里实现完全不一样有的引擎甚至会以newline节点代替换行有的直接用br。这就给测试提出了一个很具体的要求不能用普通文本的用例模板来测代码块必须单独设计一套输入、编辑、删除的交互用例。我在实际测试中还发现代码块的边缘场景比预想多得多空代码块无法聚焦、代码块与列表互相嵌套导致括号混乱、连续三个反引号触发快捷输入结果把页面搞得乱七八糟。这些只有在真正动手测的时候才会暴露也是测试设计中最容易遗漏的部分。1.2 存储结构决定了你要测什么测试代码块功能之前我建议先看一眼数据层是怎么存代码块内容的。目前主流方案有两类。第一种是纯 HTML 结构存储典型形态是precode classlanguage-javascriptconst a 1; /code/pre这类结构对后端友好渲染的时候可以直接插入页面。但问题在于解析时要把这段 HTML 识别成“不可编辑的代码块区域”否则用户点进去代码块内部编辑器会把它当成普通文本容器格式化按钮、对齐按钮都会被错误触发。第二种是自定义 JSON 结构比如{ type: codeBlock, language: javascript, content: const a 1;\nconsole.log(a); }这类结构更适合内容驱动的编辑器因为语言标识是独立字段前端高亮时直接读 language 属性就行不用从 class 里去正则匹配。不过坏处是一般需要额外的渲染层把 JSON 转成可视化 HTML一旦渲染层和编辑器内核不同步就会出现“编辑时看着正常、保存后内容变了”的问题。测试方案必须先确认当前项目用哪类存储因为两者的测试重点完全不同HTML 结构重点在 DOM 映射和光标定位JSON 结构重点在序列化往返和字段类型约束。我在开测前专门做了一次存储结构盘点把前后端字段梳理成一张表后面写自动化用例时基本就是照着这张表一项一项验。1.3 测试范围画清楚编辑器内核、序列化层、高亮层、工具栏代码块功能不是孤立的一个模块它牵涉的链路很长。我画了一条粗略的测试链路不是流程图就是一条责任链工具栏插入代码块 → 编辑器内部创建节点 → 光标定位 → 输入内容 → 高亮层渲染 → 序列化保存 → 解析还原 → 展示页面渲染链路里的任何一环出问题用户看到的现象都是“代码块坏了”但根因可能完全不同。比如展示页渲染错位可能问题根本不在这篇文章的编辑器代码里而是发布接口在存储前做了 HTML 清洗把pre标签干掉了。测试一定要从这条链路的角度去设计用例而不是只打开编辑器点来点去。基于这个链路我把测试拆成三层功能交互层、数据一致性层、渲染表现层。接下来会分别展开讲每一层具体测什么、怎么测、要注意什么。2. 测试维度拆解功能交互、数据一致与渲染表现2.1 功能交互层的测试要点功能交互层测试的核心是用户在界面上对所有与代码块相关的操作结果是否符合预期。这个层面不涉及太多的技术细节但它直接决定用户对编辑器的第一印象。我按使用频率把交互用例分成了三组。第一组是基础创建。测试工具栏插入按钮、快捷键比如 CtrlShiftC、Markdown 快捷输入三个反引号后接空格。这里有个很关键的点需要验证插入后的光标位置——到底落在代码块内部还是外部。如果光标落在外部用户直接打字打出来的文本会被加到代码块旁边而不是代码块内部给用户的感觉就是“我输了代码却不见了”。第二组是编辑操作。包括光标在代码块内部移动、Home/End 键到底跳到代码块的开始还是所在行的开始、退格键在空代码块内按下时是否删除整个代码块、在代码块中间粘贴多行文本时是否保留换行结构。这些操作看起来基础但每个编辑器实现都不一样尤其退格删除空代码块的逻辑很容易触发事务合并问题直接造成撤销栈错乱。第三组是边界组合。比如代码块首行或末行按 Delete 键要和相邻段落发生合并还是保持独立代码块里加粗、斜体等行内格式是什么表现代码块能不能嵌套在引用块里嵌套之后层级有没有深度限制这些组合场景不是每个产品都支持但没有一个统一的“正确答案”测试的价值就是帮你确认“当前实现到底是怎么样的、是否有明显问题”。交互测试有一个通用经验每个操作做完都刷新一下页面再检查状态。因为部分编辑器并没有把操作持久化到 undo 栈里刷新后页面表现和当前页面表现不一致这在交互测试里最容易被忽略。2.2 数据一致性层序列化与往返数据一致性层是我个人认为整个测试里最核心的部分。富文本编辑器给用户的感觉是“所见即所得”但在底层每一次编辑动作都会在内存里生成一个新的文档模型。保存的时候这个模型会被序列化成 HTML 或 JSON加载的时候序列化结果又要被解析回内存模型。一旦序列化或解析有 bug用户看到的内容和最终落库的内容就是两套东西。代码块的数据往返测试最典型的场景就是特殊字符。下面这个“往返测试用例表”我每次测代码块功能都会用到输入内容序列化预期解析还原预期常见问题if (a b b c)转义为lt;还原后原样输出还原时忘记反转义页面显示lt;const s 引号引号不丢失语言上下文无错误带引号代码被当成行内文本清掉连续 8 个空格空格保留为原样字符预览展示 8 个空格编辑器默认折叠多个空格\t制表符保留制表符或转成 4 空格展示统一缩进混合空格和制表符时展示错位空行保留空行空行不消失空行被解析成段落标记style标签文本转义显示还原后是文本被安全策略过滤丢失这个表格的用例测完之后还要做一层更强的验证叫“往返不变量”测试先在编辑器里真实输入一段代码然后取数据层序列化结果再把它塞回编辑器结果应该和编辑前的文档模型完全一致。哪怕编码方式不同渲染出来的内容也应该一致。自动化脚本里可以用这个不变量来写断言非常实用。数据层测试还有一个很容易被忽略的维度空代码块。用户可能插入一个代码块后就不小心失去了焦点最终落库的代码块内容是空字符串。空内容在序列化时能不能被识别成“有效代码块”能不能正常渲染出一条空的代码区域占位这些都要单独设计用例否则发布之后就会出现那种“灰色空框”的诡异页面。2.3 渲染表现层高亮、滚动与响应式渲染层的测试相对直观但坑也不少。代码块在编辑器和展示页通常都会做语法高亮高亮库会扫描代码内容然后输出一堆带 class 的span。我在测试中遇到过三种高亮相关的高频问题。第一种是前置依赖未加载导致的样式丢失。比如高亮库从 CDN 加载失败代码块内容还在页面却显示成一段无样式的纯文本。这个问题在弱网环境下被放大测试时要主动模拟 CDN JS 加载失败。第二种是语言类型不对应导致的报错。用户手动指定了语言类型但高亮库不支持这种语言应该优雅降级成无高亮状态而不是直接抛异常或中断后续渲染。第三种是代码块内部长行内容溢出。代码块通常固定overflow-x: auto但如果某个代码块嵌套在较窄的移动端容器里横向滚动就会比较糟糕。用户会感觉内容被截断实际上只是容器宽度不够。这个要在不同窗口尺寸下都验证一遍。另外还要检查代码块的行高和字体大小是否与正文媒体查询一致。很多项目为了展示代码效果套用了外部代码托管平台的 CSS字体过大或过小在手机上都会非常难看。3. 实操落地从用例设计到自动化脚本3.1 手工测试用例清单可直接抄用自动化之前我习惯先跑一轮手工用例把那些机器没法自动判断的交互问题筛出来。这里直接贴一份我整理后很实用的代码块手工测试清单基本覆盖目前主流富文本编辑器的代码块功能可以直接复制到你自己的测试计划里使用。在空文档中插入代码块确认默认语言是什么、光标是否在当前块的内部。在代码块内部连续输入 100 行代码确认平均帧率不出现明显掉帧。连续按 30 次退格确认撤销栈操作记录正确单次撤销不会删除多行。把代码块选中拖到段落中间确认拖放后目标位置正确源位置不残留空块。在代码块末尾按回车确认不会在代码块后面新增一个空段落。在代码块内部粘贴一段带script标签的 HTML确认被转义显示而不是执行。选中代码块内的部分代码设置为加粗确认文档模型仍保持代码块结构。切换语言类型确认高亮样式实时变化且语言字段持久化到数据层。用快捷键粘贴代码不经过工具栏确认粘贴后依然被识别为代码块而不是普通段落。打开空代码块的编辑状态点击页面其他区域再回来确认占位符正常显示。这份清单看起来很简单但实际上执行的时候很耗时间因为几乎每一项都要单独刷新页面确认状态。建议把清单做成本地 HTML 页面每项配一个 checkbox 和备注栏方便多人协作记录。3.2 自动化测试落地以 Playwright 为例手工用例跑完两轮后我就把高频用例固化成了自动化脚本。我们测试环境用 Playwright 做浏览器自动化整体稳定性和社区资料都比较成熟代码块测试特别适合用它来跑。下面是一段典型的“创建代码块并校验数据层结构”的自测脚本逻辑很简单页面打开后点击工具栏代码块按钮输入一行代码然后从编辑器实例里取数据层内容断言代码块的 type 与 language 字段符合预期。const { test, expect } require(playwright/test); test(代码块创建后数据层结构正确, async ({ page }) { await page.goto(/editor/demo); await page.click([data-testidtoolbar-code]); await page.keyboard.type(const demo () 1;); const model await page.evaluate(() { // 项目里编辑器实例挂在 window.editor return window.editor.getJSON(); }); expect(model.blocks[0]).toMatchObject({ type: codeBlock, language: javascript, }); });这段代码是从测试项目里简化来的实际项目里的编辑器 API 可能不叫getJSON但思路一致用编辑器自身的 API 读取数据层来做断言不要只用页面 DOM 上能不能看到文字来判断测试通过与否。此外模拟粘贴场景也很重要。我写了另一个用例复制一段多行代码到剪贴板在代码块内执行粘贴命令再读取渲染 DOM检查换行后的行数是否与代码行数一致。const code line1\nline2\nline3; await page.locator(.code-block).click(); await page.evaluate((text) { navigator.clipboard.writeText(text); }, code); await page.keyboard.press(ControlOrMetaV); await expect(page.locator(.code-block)).toContainText(line3);这里有个值得注意的点Playwright 模拟的粘贴行为和真实用户粘贴还是有差别的因为它走的是系统剪贴板不会触发表单自动填充之类的浏览器行为。所以自动化脚本只能证明“粘贴到内容模型里正确”真正的粘贴体验还是得手工验一遍。3.3 自动化脚本里的往返断言技巧我在 2.2 提到过“往返不变量”这里直接给出我在脚本里用的一个通用断言函数思路。它的逻辑是输入一段rawText等待编辑器渲染然后从数据层取出serialized1再把serialized1重新塞进空编辑器再次取出serialized2比较serialized1和serialized2是否完全一致。只要出现不一致基本就是序列化/解析逻辑出现了非常隐蔽的问题。async function roundTrip(page, rawText) { await page.fill(#input, rawText); const serialized1 await page.evaluate(() window.editor.getHTML()); await page.evaluate(() { window.editor.setContent(); }); await page.evaluate((html) { window.editor.setHTML(html); }, serialized1); const serialized2 await page.evaluate(() window.editor.getHTML()); expect(serialized2).toBe(serialized1); }这个断言思路非常强因为很多编辑器 bug 只在第二次加载时才暴露。实际测试中这个函数帮我抓到了两个很隐蔽的问题一个是序列化时把代码块里的两个连续空行压缩成一个另一个是语言字段在 HTML 解析后从language-javascript变成了javascript第二次加载时高亮层直接罢工。要是只测一次输入这两个问题完全发现不了。建议把往返测试作为代码块相关的回归用例每次改动编辑器内核或序列化模块后都跑一遍能有效防止老问题复发。4. 高频问题与排查技巧实录4.1 常见问题速查表下面是测试期间整理的一组高频问题每一项都来自实际项目现象。问题覆盖了编辑器内核、数据层和渲染层三方排查时可以参考“可能原因”快速定位方向。现象可能原因解决方案建议粘贴代码后格式变成普通文本粘贴前未触发代码块内容处理器在粘贴事件里做 HTML 清洗识别pre并映射成代码块节点保存后代码缩进全无序列化时未保留空白符或空格被 trim序列化前将\t、\n做占位保护避免被安全过滤代码块内高亮颜色错乱高亮库版本与语言类型不匹配检查语言映射表缺少的语言走默认降级样式空代码块刷新后消失解析层把空 pre 元素当无效节点删掉解析时对空代码块单独判断保留占位节点代码块嵌套列表后层级异常编辑器 schema 不支持嵌套块级元素需要调整 schema或限制代码块不能直接嵌在列表内部高亮样式只在编辑页生效、展示页不生效展示页未加载高亮脚本或高亮样式 CSS统一封装高亮组件编辑器与展示页复用同一套样式资源移动端代码块无法横向滚动容器样式缺少overflow-x: auto补充样式并限制代码块最小宽度这里面的问题覆盖面比较广但如果你在项目中遇到的现象不在表格里也建议按照“现象 → 数据层 → 渲染层”三个方向去拆基本都能找到根因。4.2 排查技巧一先看数据层别在 DOM 上死磕测试人员通常会在元素审查器里看结构但代码块功能的问题我看数据层的频率比看 DOM 高得多。因为 DOM 上的每个节点都可能是渲染层的“障眼法”真正的数据模型里早就错了。比如你在页面上看到代码块内有高亮元素看起来很精美但数据层里语言字段是空字符串保存后高亮会整片丢失。排查时我一般先从编辑器开发者工具里拉取getText()或getJSON()确认内容模型正确。如果模型正确问题就出在渲染层如果模型不正确问题就在编辑器内核或序列化层。这一刀切下去排查范围立刻缩小一半。4.3 排查技巧二最小化复现与版本对比遇到那种“偶尔出现一次”的代码块 bug强刷页面又好了最有效的方法永远是最小化复现。我会把操作路径压缩到三步以内比如插入代码块 → 输入特定字符串 → 保存。反复测试后如果还不行就要检查是否与前面一个操作相关比如上一次撤销操作没有正确合并事务。还有一个技巧值得一试同版本环境对比。同一段代码在编辑器当前页测试不复现把编辑器嵌入另一个半成品页面测试却复现了。这种情况基本都是外部 CSS 或全局事件监听的干扰。我经常在排查此类问题的时候先屏蔽页面上其他所有 JavaScript 模块再逐步放开通常问题就出现在一个与代码块事件毫无关系的全局键盘监听上。4.4 排查技巧三隔离高亮依赖代码块渲染经常依赖高亮库而高亮库版本升级又是一个非常容易引入回归的点。如果某个高亮问题在线上出现我建议先检查高亮库版本与构建产物是否一致确认本地构建出来后 CDN 缓存是否紧急刷新。很多时候“本地好好的、线上坏了”不是编辑器的问题而是静态资源版本缓存问题。这类问题有一个很实用的排查动作把代码块内容整体复制出来放到高亮库官方演示页跑一遍。如果官方演示页正常就说明高亮库本身没问题问题出在我们的调用方式或样式覆盖上。如果官方演示页也异常就要回头检查那串代码是否包含了特殊字符比如极长的无空格字符串导致高亮算法超时。一些个人的测试体会做了这一轮“富文本测试代码块”的专项之后我最大的感触是代码块功能看似简单却是富文本编辑器里牵涉环节最多的功能之一。测到后面我对编辑器内核、序列化层和渲染层的边界意识比以前清楚了很多再遇到奇奇怪怪的内容显示问题不再局限于调 CSS而是会下意识想“数据层此刻到底存的是什么”。建议所有做富文本测试的朋友都先把数据往返测试跑起来这个投入产出比非常可观。如果项目已经在线上跑还可以考虑补一段埋点统计用户保存内容时代码块的序列化失败率提前发现用户侧的实际问题。这套方法不只适用于代码块后续做表格、嵌套引用、多媒体嵌入等块级功能测试时同样是通用的底层思路。