企业官网建设流程全解析

1. 需求拆解与系统设计思路

1.1 测试用例生成到底难在哪

先说一个我观察到的现象：很多测试团队的需求文档写得相当完整，页面原型图、PRD、交互说明一应俱全，但真正落到用例编写阶段，往往还是靠测试工程师对着界面一点点扒。

扒的过程无非是：打开页面，看按钮文案，猜交互逻辑，翻需求文档确认边界，再对照历史缺陷想哪里容易翻车。这套流程跑下来，一个稍微复杂点的模块，用例设计可能要一到两周，而且质量高度依赖人的经验。

我接手这个项目时，团队里积压的痛点非常明确：旧系统UI频繁迭代，导致UI自动化用例维护成本极高；需求变更后，用例同步更新滞后；历史缺陷库里的踩坑记录没有被充分利用，同一个问题换了页面就漏测；再加上项目里有大量的动态报表、审批流页面，界面上很多元素靠DOM解析根本拿不准是干什么的。

所以当时想做这个“AI测试用例生成系统”的目标就很明确：把"需求文本+界面截图+历史知识"这三类输入喂给AI，自动化产出结构化、可执行、贴合业务背景的测试用例，让测试工程师从重复劳动里解放出来，把精力放到评审和探索性测试上。

1.2 为什么是“多模态+OCR+知识库增强”三方联合

老实说，一开始我也考虑过“直接拿一个大模型对话生成”的简单方案，但试下来发现根本不够用。

生成用例这件事的问题在于：模型没有看到真实界面，它不知道页面元素长什么样；模型不了解你的业务知识，它不知道你们这个审批流有特殊权限限制；模型不掌握历史教训，你不知道这个模块以前在什么场景下出现过高危问题。

所以整个系统落地的关键，不是“塞给模型更多文本”，而是让模型具备三种能力：

• 多模态理解能力：能同时看需求文档和界面截图，把视觉信息转化为测试依据；
• OCR解析能力：把截图上那些模型认不出来的按钮文案、弹窗提示、表格数字，先转成文本再参与推理；
• 知识库增强能力：检索历史缺陷、业务规范、字段规则，作为上下文注入生成过程，让输出结果更贴合项目实际。

这三者缺一不可。多模态解决“看到了什么”的问题，OCR解决“看清了哪些字”的问题，知识库解决“结合什么背景来思考”的问题。后面所有的架构设计、选型判断、踩坑经验，几乎都围绕这三条主线展开。

1.3 系统的整体分层结构

整个系统的模块划分，我最初设计成了五个层次，后来在落地过程中又做了不少调整，最终稳定下来的结构如下：

解析层是最容易被低估的一层。需求文档可能是Word、PDF、Markdown，界面可能是Web端、桌面端甚至报表大屏，OCR识别出来的文本还带着坐标信息，这些异构数据不统一，后面的Prompt组装就无从谈起。

融合层是整个系统里逻辑最重的部分，它决定了模型拿到手的上下文是不是“够料”。这一层做得好不好，直接体现在生成用例的质量上——上下文里缺了关键业务规则，模型再强也救不回来。关于这块的具体落地方法，我会在后面详细展开。

2. 关键技术选型与多模态融合方案

2.1 文本生成体的选型考量

模型选型这块，我走了不少弯路，最开始试过用开源小参数模型本地部署。说实话，本地部署的好处是数据安全可控，但测试用例生成这个场景对模型的“结构化输出跟随能力”和“长文本处理能力”要求特别高。

小模型的问题在于：让它写一段自然语言描述，它能写得不错；但让它严格按照JSON结构输出一份包含前置条件、步骤、预期结果、优先级等多字段的用例，并且还要保证20条用例字段对齐，它就容易“阵脚大乱”，出现字段缺失、JSON格式跑偏的问题。

后来经过对比测试，我们对文本生成模型的硬性要求有三条：

• 长上下文处理能力要强，至少能处理4K以上输入，因为知识库片段+OCR文本+需求片段拼起来经常要占大量空间；
• 结构化输出稳定性要高，能保证用例字段完整、枚举值正确、JSON可解析；
• 业务指令遵循能力要好，让它“只输出用例不输出解释”就绝不多话。

我需要强调一个容易被忽视的点：生成效果不完全取决于模型参数量，还取决于你对模型输出的约束方式。后面对Prompt模板部分会专门讲，这里先记住结论：选模型时一定要拿“真实场景用例”做回归测试，而不是拿通用问答题目测。

2.2 OCR解析模块的工程化落地

OCR这块是整个项目里坑最多的地方，因为它不只是“识别文字”那么简单。在UI自动化测试场景中，截图上有按钮、输入框、表头、图表水印、弹窗提示等多种元素，OCR要完成的任务其实是“把界面视觉信息转成带空间位置的结构化数据”。

我最终敲定的OCR方案是“离线模型初识+规则后处理+模型语义纠错”的组合路线。流程如下：

• 第一步：对输入截图做预处理，包括去水印、去噪、缩放、灰度化、纠正倾斜角度；
• 第二步：用OCR模型识别文本块，输出内容包括文本内容、置信度、坐标框（左上角X、左上角Y、宽度、高度）；
• 第三步：基于坐标信息做版面结构还原，比如把同一行、同一列的文本聚合起来，还原出按钮组、表单行、表格列等页面结构；
• 第四步：将OCR结果送入模型做语义纠错，解决那些在截图中由于字体原因导致的识别错误。

这里要多说一句：识别准确率不能只看“字对不对”，还要看“位置准不准”。举个例子，页面上有个“提交”按钮，OCR识别出文字后，如果坐标框偏移，系统就可能把“提交”和附近的一个“取消”按钮合并成同一组，生成用例时对元素定位的推理就会出错。

我在实际项目中还建了一份“常见误识别对照表”，把容易弄混的字词收集起来，比如数字“1”和字母“l”、中文“设置”和“设备”这类，在后处理阶段做规则替换。这块积累越久越有价值，属于越用越准的基础数据。

2.3 多模态信息的融合方式

多模态融合是整个系统里最容易“翻车”的地方。市面上做了多模态联合训练的模型，在纯图片理解上表现不错，但在“截图识别+需求文本联合推理”这个场景下，需要我们自己设计融合策略。

我试过两种路径，最后在实际项目里采用的是混合方式：

第一种路径是把截图直接交给多模态模型，让模型“看图理解”。这种方式的优点是直观，模型能看到完整的界面布局、控件样式，但缺点也很明显：截图上的像素级干扰信息太多，模型容易被水印、推荐位、非功能性的装饰元素干扰，输出浮于表面。而且对多模态模型的响应速度、成本消耗都比较大。

第二种路径是“OCR文本为主、视觉特征为辅”：先用OCR引擎把截图转成带坐标的文本信息，再配合截图的整体视觉特征向量，两者拼接后一起作为模型输入。这种方式在成本和准确率之间取得了较好的平衡。

最终落地时，我采取的融合策略是：当界面元素以文字为主时，以OCR解析结果为核心信号；当界面包含图表、流程图、复杂布局时，引入视觉特征向量；两类特征在Prompt组装阶段按一定规则合并。视觉特征向量是这样用的：先对截图做全局编码，把页面布局特征压缩成一个向量，然后和OCR文本向量做拼接，进入模型前再一起投影到对齐空间。

在实际运行中我发现，即使使用支持多模态输入的模型，OCR解析这一步也不能省。模型直接看图确实能大概知道页面内容，但它无法精确获取按钮文案、输入框预设值、边界提示文字等关键信息。而OCR把这些文字提取出来后，模型能更准确地理解页面结构，生成用例时的步骤描述精确得多。

3. 知识库增强的实现路径

3.1 知识库里的内容从哪里来

知识库听起来高大上，但落到实处的本质是：把你项目里“能帮模型做对事”的信息，组织成可检索的格式。

我整理了一下，这个系统里实际纳入知识库的内容主要来自四类来源：

• 历史缺陷记录：这是最有价值的一类，特别是那些曾经发生在线上的高危缺陷。比如某个页面的“金额输入框允许输入负数”导致数据异常，这类教训如果检索到了，生成的用例自动就会把负数、零值、边界值用例加上。
• 业务规则文档：包括字段校验规则、权限控制逻辑、状态流转约束。比如“该按钮仅管理员角色可见”，如果知识库里没有这条，模型很可能生成一条普通用户也能操作的错误用例。
• 公共测试规范：包括团队的用例编写规范、命名约定、优先级定义。这类内容帮助模型输出格式上符合团队要求。
• 历史用例库：从高质量的历史用例中抽取的典型步骤模式。特别适合作为“少样本示例”注入Prompt，引导模型模仿团队的写作风格。

这里有一个很关键的认知：知识库不是越大越好，而是越精准越好。我见过有团队把整个产品手册全部灌进知识库，结果检索相关性被无关文档拉得很低，模型拿到的上下文质量不升反降。

3.2 向量化与检索策略

知识检索这块，我采用的方法是“混合检索”：BM25稀疏检索+向量稠密检索的组合方式。

BM25的优势是精确匹配能力强，适合检索“负数”“审批流”“超时时间”这类具有明确关键词的业务术语；向量检索的优势是语义泛化能力强，适合检索“页面金额校验异常”这类描述方式多样的问题。

具体流程是这样跑的：先把知识库的每个文档按篇幅切分成块，每一块生成对应的向量索引；查询时把“需求文本片段+OCR识别出来的界面操作词语”拼成一个查询向量，同时计算BM25分数和向量相似度；两组结果用加权分数合并，取Top-K作为最终上下文。

这里我要说一个细节：知识库切片粒度很重要。我最初用的是固定长度切片，比如按512个字符切，结果很多完整业务规则被切成了两半，检索效果很差。后来改成按“语义段落”切，优先使用标题、列表、表格这样的结构边界，一条规则尽量完整保留在一个块里，效果提升非常明显。

3.3 生成时的知识注入方式

检索到知识以后，“怎么喂给模型”同样是技术活。我的做法是把知识库内容放在Prompt中专门的“业务上下文”区域，在结构上形成“系统指令—业务上下文—需求片段—OCR信息—输出约束”这样的顺序。

业务上下文区域不是简单地把检索出来的内容拼在一起，要做两步加工：第一，过滤掉明显不相关的片段，比如检索结果中置信度较低的；第二，将相似的片段合并去重，避免多个块内容重复占用上下文空间。

在实际调优中我发现一种对生成质量帮助很大的方式：在知识库片段中标注来源编号，Prompt中要求模型在输出用例时，对每条用例标注关联的知识依据编号。这样做有两个好处，一是用例可追溯，测试工程师能查到这个用例是根据哪条历史缺陷生成的；二是倒逼模型更谨慎地组织用例，减少“自己脑补业务规则”的幻觉现象。

注意：知识注入时的顺序也很敏感。同样的知识内容，放在系统指令后面和放在对话末尾，生成结果会有差异。我在实践中倾向于把知识片段集中放在一次请求中，在Prompt末尾再次提醒“严格依赖以上业务上下文生成用例，不得自行编造规则”，这对稳定输出有实际帮助。

4. 核心流程与落地实操

4.1 从原始需求到最终用例的完整流水线

整个系统的运行流程最终稳定为六个环节，这里我画一下完整流水线：

需求文档导入 → 文档解析（抽取功能点与操作路径） → 模块截图采集与OCR解析 → 知识库检索（结合功能点与OCR文本） → Prompt组装与模型生成 → 格式校验与人工审核。

第一环节相对简单，主要做文档格式转换和基础清洗；第二环节是抽取功能点，比如登录功能、查询功能、导出功能，每个功能点对应后续的一组用例；第三环节就是前面讲的多模态解析；第四环节是知识库召回；第五环节是调用模型生成；最后校验通过后进入测试工程师的人工审核工作台。

在设计这个流程时，我一直坚持“人始终在环上”的原则。AI生成的不是最终产物，而是“高质量初稿”，测试工程师在审核台里做确认、修改和补充，而不是完全放手。这一步在系统上线初期尤其重要，既保证输出质量可控，也为后续调优积攒了人工修改数据。

4.2 从截图到用例的完整过程实例

我来用登录页面举个例子，完整走一遍这个流程。

假设输入是一张登录界面的截图，上面有：用户名输入框、“密码”输入框、“验证码”输入框、“登录”按钮、“记住我”勾选框、“忘记密码”链接。OCR解析后得到这些元素的文本内容和坐标信息。

知识库检索召回的相关内容可能是：历史缺陷里有一条“登录失败三次后未锁定账号”、“验证码过期后未给出明确提示”等记录；业务规则文档里标明“同一账号连续失败5次锁定30分钟”。

接着是Prompt组装，我把系统指令写清楚：你是资深测试工程师，请根据页面元素信息和业务规则，设计登录功能的测试用例。然后附带OCR识别出的控件清单和坐标信息、知识库检索到的业务规则、需求文档中的功能描述。最后，我要限定输出格式：一条条列出用例编号、模块、标题、前置条件、步骤、预期结果、优先级。

模型生成的用例就会包含：正常登录成功用例、密码错误提示用例、密码多次错误账号锁定用例、验证码过期用例、记住我功能用例等。这样生成的用例，既覆盖了基本功能，也覆盖了历史踩坑点，比单纯让模型“凭空想象”出来的用例贴近业务得多。

4.3 Prompt模板设计的几个关键细节

Prompt模板是整个系统里投入产出比最高的部分。同一个模型，Prompt换一版，输出质量可能就有天壤之别。我这里还原一个精简版的核心模板结构，供大家参考：

[系统指令] 你是一名资深测试工程师，负责为以下模块生成测试用例。 要求：只输出测试用例，不要输出任何解释、建议或额外说明。 用例必须覆盖正常流程、异常流程、边界值、权限控制。 [业务上下文] - 历史缺陷1：用户提交订单时，未对数量字段做上限校验，导致超出库存仍能提交成功。【依据编号：DEF-1023】 - 业务规则1：订单金额超过10000元时必须经过主管审批。【依据编号：RULE-0458】 - 业务规则2：接口超时时间设定为30秒，超过时需提示“请求超时”。【依据编号：RULE-0461】 [需求片段] 订单提交页面：用户可选择商品数量（1-999），点击“提交订单”后系统校验库存并生成订单。 [OCR元素清单] - 文本“商品数量” @坐标(120,250)，元素类型：标签 - 输入框 @坐标(260,250)，元素类型：文本输入 - 文本“提交订单” @坐标(180,320)，元素类型：按钮 - 文本“返回购物车” @坐标(400,320)，元素类型：按钮 [输出格式要求] 每条用例以JSON格式输出，包含字段：case_id, title, module, preconditions, steps, expected_result, priority, reference_ids。

我要强调一个实战心得：Prompt里一定要有“反例压制”列表。什么叫反例压制？就是你告诉模型“不要生成什么”的清单。比如：

• 不要生成无关通用用例（如“验证系统响应时间”这类没有依据的用例）；
• 不要在用例里捏造不存在的页面元素；
• 不要在无依据的情况下编造业务规则号。

加上这一条之后，输出质量有明显改善，特别是“模型自行脑补页面元素”这个问题几乎被杜绝了。

4.4 输出的格式校验与查重处理

模型生成完用例，不直接入库，要先过一道校验逻辑。

第一道是结构化校验：用JSON解析器校验输出格式是否合法，字段是否完整，枚举值是否正确，步骤列表是否为空。如果解析失败，系统自动触发“重试一次”的机制，带上解析错误信息重新请求模型，这种做法比直接返回失败要好得多。

第二道是查重校验：和已有用例库做相似度比对，把重复的用例识别出来。我在这里用的方法是“步骤序列归一化+BERT向量相似度”组合，先把操作步骤里的具体元素名做脱敏，再计算向量相似度，超过阈值的用例标记为“疑似重复”，需要人工确认。

这道校验一个容易被忽略的收益是防“碎片化冗余”。当模型多次生成用例时，可能会把同一场景拆成多个细微变体。查重模块加进去后，用例库的整洁度明显提升，人工审核的工作量也降下来了。

5. 效果评测与常见问题排查

5.1 我们用什么指标评估用例质量

系统上线后，最需要回答的问题是：生成的用例到底靠不靠谱。只看生成速度没有意义，关键要看质量。

我们最终确定了一套五个维度的评估指标：

这里说句客观的话：不要拿“AI生成用例能替代人工”当目标，这个目标在短期内不现实。我能做到的，是把一个模块的用例产出从2天压缩到半天，同时通过人机协同，把用例库的整体覆盖密度往上抬了一个台阶。

5.2 高频问题与排查实录

这个系统的开发和调优过程中，我记录了不少高频问题和对应解法，在这里整理一份速查表：

排查过程中我最大的体会是：很多问题表面上出在模型，实际上出在上游数据。数据经过OCR、知识切分、Prompt组装这些环节，任何一环引入了脏数据，模型输出的质量都会跟着崩。所以排查思路不要先怀疑模型，先回头检查输入侧。

5.3 几条基于实践经验的避坑建议

第一条建议是：先搭一个最小的闭环，再扩展规模。我建议你从“一张截图+一段需求+一个知识检索”这个最简单的链路开始，跑通了再往里面加模块。不要一上来就做完整系统，不然翻车的时侯你根本不知道是哪个环节出了问题。

第二条建议是：知识库里的数据不要贪多，宁缺毋滥。有些团队喜欢把整本产品手册灌进知识库，但检索效果反而不如只保留“规则条文与缺陷记录”这两类高价值信息。我这边知识库目前是过滤过的，大概保留了不足原始文档量三分之一的精华内容，检索质量反而更好。

第三条建议是：系统的每个关键环节，都要留下人工抽查的点。OCR的识别结果抽查、知识检索的相关性抽查、生成用例质量抽查，这些抽查不能省。省掉一次抽查，后面回归一个模块用例的成本比抽查要高得多。

第四条建议是：把“历史用例写作风格”纳入知识库。这样生成出来的用例跟团队原有风格保持一致，人工审核的时候顺滑很多。之前我遇到过一个情况：AI生成的用例逻辑没问题，但是写法跟项目组习惯差距太大，没人愿意看，后来我把H几篇典型用例放进了知识库作为风格参考，才把这个痛点解决掉。

写在最后

这个系统从最初的想法到稳定运行，前后迭代了好几轮。我最大的感悟是：AI测试用例生成真正难的不是模型能力，而是工程侧的“信息料理”能力——如何把界面视觉信息、需求语义、历史经验这三类不同形态的信息，加工成模型吃得透、用得准的上下文。

说个我在实际运行中发现的细节：系统上线初期，测试工程师对AI生成的用例天然带有不信任感。后来我在审核界面加了一个“知识依据”展示栏，把每条用例命中的历史缺陷编号和业务规则直接列出来。工程师看到某条用例是根据真实缺陷生成的，信任感一下子就上来了——这个改动解决了很多流程推进阻力。

如果你也要做类似的系统，我希望你从一开始就记住：不要试图用一个模型包揽一切，多模态、OCR、知识库增强这三块各有各的不可替代性。把每块做扎实，系统整体才有价值。另外，如果你准备用向量数据库和开源OCR模型搭建，注意提前预留版本管理的能力——OCR模型升级、向量索引更新、Prompt模板迭代，这些都需要可回滚的机制，否则线上用例质量波动了都不好定位原因。

最后分享一个收尾的小技巧：Prompt模板里的输出格式定义，可以单独放在配置中心里管理，不要写死在代码里。因为随着模型迭代，输出格式的约束方式会变动，配置化管理能让你在半天之内完成一次模板升级，而不是重新发版。这条经验是我踩过“模板写死”的坑之后得到的教训，希望对你有帮助。