鸿蒙 PC Markdown 编辑器 Beta 质量门禁与千文件压力

鸿蒙 PC Markdown 编辑器 Beta 质量门禁与千文件压力仓库地址https://gitcode.com/VON-/codex_md_oh代码基线G3-09 设备收口fc7de5aG3-10 第一质量纵切941a1dc。Beta 质量不是把测试数量写大Markdown 编辑器从 Alpha 进入 Beta最大的变化不是又多了几个按钮而是已有能力开始面对规模、组合和长期使用。单文件打开通过不等于一千文件工作区仍能搜索五兆字符能触发保护模式不等于十兆字符不会在状态计算中复制全文一次恢复成功也不等于高频操作后仍没有数据丢失。OhMarkdown 的 G3-10 将质量工作分成内部可重复基线和外部真实证据。内部基线可以由工程环境完成全量自动化、精确大文档、模拟器工作区压力、原生服务测试、依赖审计和安全边界。外部证据必须等待真实条件竞品统一任务、鸿蒙 PC 真机、物理键鼠、50-100 人封闭测试和长期强杀。两类证据不能互相冒充。本轮完成的是第一类。Playwright 从 43 项增加到 44 项ohosTest 从 9 项增加到 10 项新增精确 10 MiB Web 保护模式与 1000 文件模拟器搜索。结果全部通过但项目进度仍保持 G38/10因为一个小阶段通过不等于整个 Beta 评审退出。先把门禁变成统一入口项目使用scripts/verify-local.sh串联 Web、HAP、ArkTS 和 diff 检查。核心脚本保持简单$ROOT_DIR/scripts/verify-web.sh$ROOT_DIR/scripts/build-debug.sh$DEVECO_HOME/tools/hvigor/bin/hvigorw\UnitTestBuild\--modemodule\-pproductdefault\-pmoduleentrydefault\-pbuildModetest\-punitTestModetrue\--no-daemongitdiff--check统一入口的价值是让一次变更不能只挑对自己有利的用例。新增 1000 文件原生测试时仍要跑渲染、右键、快捷键、导出和大文档修改 Web 大文件策略时仍要证明 ArkTS 可以构建。门禁不是追求一条命令的仪式感而是减少“局部通过、整体破坏”的机会。Playwright 临时服务器需要本机端口权限HarmonyOS 构建依赖 DevEco Studio JBR 与 SDK。报告必须记录这些环境条件避免 CI 端口失败被误写为产品失败也避免本地构建成功被误写成 GitCode Runner 已通过。十兆字节为什么必须精确构造旧用例用a.repeat(5 * 1024 * 1024)验证保护模式阈值能证明边界触发却不能覆盖 PRD 指定的 10 MiB。新用例在浏览器页面内部构造精确 10,485,760 个 UTF-16 字符避免把 10 MB、10 MiB 和 UTF-8 字节混成同一个概念。consttargetLength10*1024*1024;constline鸿蒙PC大文档\n;constcontentline.repeat(Math.ceil(targetLength/line.length)).slice(0,targetLength);conststartedAtperformance.now();host.OhMarkdownEditor.setDocument(content);host.OhMarkdownEditor.setMode(preview);第一次实现曾用人工估计的“每行九字符”计算重复次数实际得到 9,320,680 字符测试立即失败。修正后使用line.length作为事实来源再 slice 到目标长度。这次失败很有价值它说明性能语料也需要精确校验不能仅凭文件名或生成公式宣称是 10 MiB。用例随后检查三件事getDocument().length必须完全相等工作区 mode 必须仍为 source操作耗时小于 3000 ms。编辑器和预览可见性也分别断言防止状态属性正确但布局没有同步。大文档保护模式保护的是什么五兆字符以上OhMarkdown 使用 CodeMirror minimalSetup不加载 Markdown 语言扩展与自动换行预览、专业渲染、HTML、PDF、PNG、链接助手和周期恢复快照停止。字数返回 -1原生状态栏显示大文件模式。目的不是“功能缩水”而是把用户最重要的源码编辑和保存留在可响应范围内。保护模式必须在setDocument创建 EditorState 时生效而不是等到第一次输入后才切换。否则 10 MiB 文档会先完成高成本语法树、行包装和预览再补救已经发生的内存峰值。当前createEditorState根据 content.length 直接选择 minimalSetup后续 transaction 仍调用updateLargeDocumentMode保持一致。本轮 Chromium 页面内setDocument、请求预览和状态切换合计 87 ms远低于三秒。但它不包含 Core File Kit 读取、ArkTS 到 ArkWeb 的字符串传递、进程调度和真机存储所以文章只把它写成 Web 回归。G1 模拟器曾测得 10 MiB 整链 345 msRelease 真机 P95 仍待 G4 质量专项。一千文件语料怎样避免假快如果 1000 个文件都含查询词SearchService 达到 500 结果上限后会提前停止扫描。此时测试可能很快却不能证明工作区能遍历 1000 个文档。新用例只让最后一个report-0999.md包含“唯一压力命中”前 999 个只有普通内容。要获得唯一结果控制器必须走完整个集合。for(letindex0;index1000;index1){constsequenceindex.toString().padStart(4,0);constcontentindex999?# 压力文档\n\n唯一压力命中\n:# 文档${sequence}\n\n普通内容\n;awaitwriteRawText(${searchWorkspace}/report-${sequence}.md,content);}用例断言documentsDiscovered1000、documentsScanned1000、documentsSkipped0、results.length1和结果路径。任何文件被扩展名过滤、读取失败、TaskPool 异常或提前截断都会留下不同数字。语料位于应用测试沙箱不进入 Git。beforeEach 和 afterEach 递归清理目录测试中断后的下一轮也会先清理。这样既避免仓库膨胀又保证同名旧文件不会污染结果。搜索 419 毫秒意味着什么MateBook Pro 2in1 模拟器日志记录 1000 文件全文搜索 419 ms、快速打开 50 ms。完整用例包含 1000 次小文件写入、两轮文档收集和断言耗时 1556 ms完整十项 ohosTest 为 1649 ms。419 ms 可以证明当前模拟器环境下没有明显的秒级阻塞但不能直接证明 UI 输入 P95。WorkspaceSearchController 的单篇正则匹配放到 TaskPool目录枚举和读取仍由异步 Core File Kit 完成真正的用户体验还取决于结果面板渲染、取消手势、磁盘缓存与工作区目录层次。更不能据此宣称比 Typora、Obsidian 或 VS Code 快 20%。竞品必须使用相同文件数量、层级、文件大小、查询位置、冷/热缓存和设备。没有这些元数据两个毫秒数字不能比较。快速打开与全文搜索为何分测全文搜索读取正文并执行查询快速打开只收集文件元数据并在 TaskPool 中模糊排序。它们共享工作区收集器却有不同成本和产品任务。把快速打开当成全文搜索性能会得到过度乐观结果把全文搜索时间当成文件名跳转也会低估桌面效率。用例对report-0999执行 quickOpen第一结果必须为report-0999.md耗时上限 5 秒。当前实测 50 ms。最近文件权重数组传空避免旧会话把目标提前加权这样测的是文件名精确前缀与路径排序而不是持久化历史。未来竞品实测应分别记录“打开已知文件名”和“查找正文中的未知文件”。两个任务的操作数、认知成本和结果质量不同不能用一个平均数掩盖。应用内部设备证据下图来自最终 G3-09/G3-10 Debug HAP 在 HarmonyOS MateBook Pro 2in1 模拟器中的真实 OhMarkdown 主窗口。1280 vp 预算下多标签、停靠侧栏、分栏预览、工具栏和状态栏同时存在没有重叠。1000 文件压力使用同一应用服务和同一测试 HAP不是 Node.js 对纯函数的替代跑分。原生十项回归覆盖什么ohosTest 现在包含未保存正文分享快照、BOM/CRLF 字节一致、混合换行归一、失败保存备份恢复、文件指纹、图片完整落盘/重名/三模式、基础搜索/取消、1000 文件压力、中文链接补全/越界拒绝和 UTF-16 标题偏移。它们共同覆盖文件事实来源和原生服务但不点击所有 ArkUI 组件。右键、拖放、自由窗口和系统对话框仍由设备操作用例覆盖Web 右键与渲染由 Playwright 覆盖。测试分层不是重复而是让每个环境验证自己能观察的事实。最终 Debug HAP 为 8,542,985 字节SHA-256f88af05e83a411f7230927c527d0b1fa74243049a6e2261fe9d11c7e544e8655ohosTest HAP 为 9,315,428 字节SHA-256ca0400141d46d51e3698a2d9187fe70359a6b1f8e1018eab9f4c36e0fd3c5571。哈希把测试结果绑定到明确产物。性能断言为什么要有宽松硬上限10 MiB Web 用例断言 3 秒直接对应 PRD1000 文件搜索使用 10 秒快速打开使用 5 秒。这些上限不是当前性能目标而是 CI 退化保险。当前结果比上限快很多给不同机器和模拟器调度留下余量避免把偶发系统负载当成产品回归。精细性能门槛应在固定 Release 真机上统计 P50/P95并预热/冷启分组。把本机 87 ms 直接变成 CI 的 100 ms 断言会产生脆弱测试把上限设成一分钟又无法拦截算法退化。阶段门禁使用产品预算或数量级边界专项基准再使用统计分布。测试数据不能泄露真实正文压力语料完全合成只包含序号和固定中文查询。日志记录文件数量、耗时和结果路径中的测试名不记录用户正文、真实路径或文件名。生产性能日志也只记录读取字节、字符数与耗时。真实封闭测试的数据字典更严格不上传正文、文件名、路径、链接或图片崩溃附件可查看、关闭和清理。工程性能用例先遵守同样原则可以减少后续“为了测量再重写遥测”的隐私债务。全量门禁的真实结果最终verify-local中 Vite 单 HTML约 7.67 MBgzip 约 3.43 MBPlaywright 44/44Debug HAP 和 ArkTS UnitTestBuild 成功diff check 通过。ohosTest 单独构建安装后 10/10Failure 与 Error 为 0。这里没有把首次错误语料隐藏。第一版 10 MiB 用例只生成约 9.32 MiB断言失败修复生成公式后定向 1/1 和全量 44/44 均通过。保留失败原因能证明测试确实约束样本而不是永远成功的装饰。仍未完成的 Beta 退出条件第一G3-08 仍缺系统 PDF 服务、兼容 Markdown 分享接收方和 HTML/PNG 独立查看。第二PRD 要求 50-100 人封闭测试真实参与者尚未开始。第三核心任务领先 20% 尚无统一竞品数据。第四鸿蒙 PC 真机、物理触控板、系统字体与输入法矩阵仍缺。第五1000 次强杀恢复不能用一次 ohosTest代替。因此 G3-10 状态是“进行中”不是“完成”。工程团队可以继续准备竞品语料、真机脚本和匿名反馈表但不能把模拟器自动化换算成用户满意度、崩溃率或留存。对产品优势的实际贡献一千文件搜索把“工作区搜索存在”推进为“指定规模下准确且有界”十兆字节把“大文档模式存在”推进为“精确样本三秒门禁”哈希与统一脚本让设备证据可追溯。这些能力不会出现在营销标题里却决定编辑器在真实项目中是否可信。当前工作区搜索可以保持记分卡 3 分因为功能、失败路径和模拟器规模证据完整。升到 4 分仍需要真机和竞品中位数。10 MiB 仍为 2 分因为本轮新增的是 Web 自动化既有模拟器数据也不是最终 Release 真机。这种保守评分能防止产品在开发期提前消费信誉。下一步质量工程后续先固定竞品版本、语料哈希、设备和计时边界再执行打开单文件、1000 文件工作区、图片、冲突、恢复、中文输入、复杂导出和全键盘任务。真机性能要记录主进程与 ArkWeb 进程组 PSS、输入 P95、搜索取消后的 CPU 和冷/热缓存。恢复专项需要可重复强杀脚本与每轮内容校验任何数据丢失立即停止功能扩展。封闭测试则以真实任务成功率和缺陷闭环为主不把自动化通过数当作用户完成率。结论鸿蒙 PC Markdown 编辑器的 Beta 质量门禁必须同时回答“有没有”“规模下是否准确”“失败会不会污染”“结论能否复现”。OhMarkdown 在 G3-10 第一纵切中增加精确 10 MiB Web 用例和 1000 文件模拟器压力用统一脚本串联 44 项 Web、10 项原生、HAP 构建和 diff 检查。当前 10 MiB Web 加载 87 ms1000 文件搜索 419 ms快速打开 50 ms所有结果都绑定代码、环境和 HAP 哈希。它们足以证明内部质量基线继续向前但不足以替代真机、竞品和真实用户。把这个边界写清楚本身就是一个长期产品的质量能力。