企业官网建设流程全解析

1. 我为什么把竞品对比测试的用例编写交给AI —— 尝试前的痛点

1.1 竞品对比测试到底是什么，它和普通功能测试有什么不同

在上一家公司做质量保障负责人时，我接到最多的一类需求就是“把竞品 App 拆一遍，看对方怎么做，我们再跟上”。拆完界面、录完流程之后，最痛苦的不是测试执行，而是编写那一批竞品 App 对比测试用例。

竞品对比测试和普通功能测试有个本质差异：普通功能测试有产品需求文档、有明确的验收标准，用例写得好不好，对照需求就能判断。但竞品对比测试没有“标准答案”，我们要对比的是另一个团队闭门设计出来的产品，它的很多交互、文案、边界处理只能靠测试人员一点点去探。更麻烦的是，竞品版本经常更新，今天写的用例，下个月对方改版了，整个对比基线就全部作废。

我刚接手这类任务时，习惯的做法是打开竞品 App，按功能模块手动操作，一边录屏一边在表格里记步骤。一个主流程走完，能产出十几条用例，听起来效率还行，但放到整个 App 层面就远远不够。一个对标产品通常有几十个功能模块，每个模块又分正常流程、异常流程、权限流程、弱网流程，靠手工编写用例根本覆盖不过来。这也让我后来下定决心把 AI 引入到用例生成环节。

1.2 手工维护竞品用例的三个最大成本

先说时间成本。一个稍微复杂的电商类竞品 App，注册登录、首页信息流、搜索、商品详情、下单支付、售后客服这六条主链路走一遍，每条链路至少能写出 20 到 30 条用例。算下来竟是 150 条以上，这还不算个人中心、消息通知、设置这类通用模块。当年我们团队三个人花了两周时间，才把当时主要竞品的主流程用例整理出一个相对完整的版本，中间还不停返工。

第二个成本是更新成本。竞品几乎每两到三周就会发布一个新版本。他们的需求文档我们拿不到，只能靠发版说明、用户反馈和界面变化去猜。每次版本更新，我们都要重新截图、重新比对，再手动调整受影响用例。这种维护方式非常消磨士气，因为写出来的用例像一次性筷子，用完就得扔。

第三个成本是口径不一致。两个测试人员对同一个竞品功能的理解不同，写出来的用例深度完全不同。一个人认为“搜索后列表展示”算一条完整用例，另一个人会把“搜索关键词为空时展示什么”“搜索词过长如何截断”“历史搜索如何排列”拆成三条。口径不统一，后续的测试执行和缺陷统计就很难对齐。这也是我在项目里最头疼的部分。

1.3 AI解决的是"写用例"还是"想用例"的问题

在真正使用大模型之前，我花了很长时间想清楚一个问题：AI 在竞品对比测试用例生成里，到底扮演什么角色？

我的结论是：AI 主要解决“写用例”的效率问题，同时在部分场景下辅助“想用例”的覆盖问题。所谓“写”，是把我已经明确的功能点、页面路径、竞品行为描述转换成结构化的测试用例；所谓“想”，是让大模型基于海量移动端产品设计经验，帮我补充那些我没想到的边界场景，比如输入超长字符、断网重连、权限拒绝后二次授权等等。

但这里有一个前提：AI 不会凭空知道我们的竞品长什么样、我们的产品有哪些差异点。它需要我去喂足够多的上下文。如果我只丢给大模型一句“帮我生成竞品对比测试用例”，它生成出来的一定是通用话术，完全没法直接落地。而如何组织输入，恰恰是整个方案里最值得花功夫的部分。

2. 输入侧的准备：如何把竞品App变成可被AI理解的结构化素材

2.1 先把竞品拆成功能地图

很多测试人员拿到 AI 工具后第一反应是写提示词，但我建议先别急。AI 生成质量的上限，取决于输入的完整度。连竞品有哪些功能模块都没梳理清楚，提示词写得再花哨也没用。

我习惯先把竞品拆成一张功能地图。这张地图不是简单的菜单列表，而是包含三个层级：一级模块、二级功能点、入口路径。比如“搜索”这个一级模块，下面可以拆出“搜索入口”“搜索联想”“搜索历史”“搜索结果页”“搜索无结果页”“搜索推荐词”六个二级功能点，每个二级功能点后面还要标注它的入口路径，例如“首页顶部搜索框 -> 输入关键词 -> 点击搜索按钮”。

这张功能地图是后续所有工作的基础。整理方式也很原始：录屏、截图、人工走查三件套。一个 Android 设备、一个 iOS 设备，把竞品每个一级模块完整走一遍，过程中把关键页面截图，然后对照截图补功能点。第一次做会有点繁琐，但做完之后，你手里就有了一份可以反复使用的竞品基础资产。

2.2 截图+OCR+页面描述：让大模型“看到”界面

功能地图是骨架，截图和页面描述是血肉。如果要让 AI 生成贴合真实界面的用例，最好把关键页面截图直接传给大模型。

现在主流的多模态大模型已经可以直接读取图片里的按钮、文案、布局。我会把竞品页面的截图按模块命名，比如“01-首页-顶部搜索框.png”“02-首页-Banner位.png”，然后在上传时附带一段简短的页面描述。这里有个细节：截图不要只截一张完整长图，最好按功能区域切成小图。因为整页长图内容太多，大模型容易忽略边缘细节，反而按区域切分之后，每个按钮、每个文案都能被清晰识别。

如果团队暂不具备使用多模态模型的条件，退而求其次的办法是给页面写文字版描述。描述模板大概是：页面名称、页面入口、核心元素列表、每个元素的可交互行为。比如“搜索历史页”的描述可以写成：页面展示最近搜索过的 10 个关键词，每个关键词右侧有关闭按钮，底部有“清空历史”按钮，点击任一关键词可直接跳转搜索结果页。这种描述方式麻烦一些，但胜在稳定，文本模型的输出质量也会更高。

2.3 用竞品版本差异表驱动测试关注点

竞品对比测试最怕漫无目的地全量对比。聪明的做法是先做一轮差异标注，把两个产品之间“你有的我没有”“我有的你没有”“大家都有但交互不同”三种类型识别出来，再针对差异点生成用例。

我常用的版本差异表长这样：

这张表直接作为 AI 的输入，配合功能地图一起使用。AI 看到差异表后，能自动把测试重心放在高优先级差异点上，避免在两边完全一致的功能上浪费生成额度。实际跑下来，这个做法能把无效用例数量减少至少三分之一。

3. 提示词工程落地：一套能直接复用的竞品对比用例生成模板

3.1 角色设定与任务边界

提示词不是越长越好，但角色和任务边界必须清晰。我推荐的竞品对比用例生成提示词结构分四层：角色、任务、输入、输出约束。

角色设定要让大模型进入资深测试专家的语境：

你是一名有 8 年移动端测试经验的资深测试工程师，擅长竞品对比测试和功能测试用例设计。你的任务是基于我提供的竞品功能地图、页面描述和差异表，生成可直接执行的功能测试用例。

任务边界一定要写明“只做什么、不做什么”。这个太重要了。不写边界的时候，大模型经常会自己脑补额外的功能点，比如我让它生成搜索功能用例，它连“支付成功后的分享引导”都能编出来。加了“只覆盖输入资料中出现的功能点，不得假设输入材料里不存在的功能”之后，这种跑偏大幅减少。

3.2 用例字段规范与输出约束

每个团队对用例的字段要求不一样，AI 不知道你的规范，必须提前写明。我们团队的用例模板包含七个字段：用例编号、所属模块、前置条件、测试步骤、测试数据、预期结果、优先级。放在提示词里就是这样：

请按照以下字段结构输出用例：

• 用例编号：格式为 TC-模块名-三位序号
• 前置条件：执行该用例前需要满足的状态
• 测试步骤：用数字列表给出完整步骤，步骤中注明操作页面
• 测试数据：步骤中需要用到的具体输入值
• 预期结果：每个步骤对应的预期结果，需同时描述竞品A和自家产品的表现
• 优先级：高/中/低

另外还要定义用例粒度。我通常会要求“一条用例聚焦一个独立场景，不要混合多个无关断言”。不加这条约束的话，AI 会把“点击搜索按钮”和“检查加载动画”塞进同一条用例，导致执行时一旦中间任一步失败，整条用例就失去参考价值。

3.3 Few-shot示例的作用：让AI学会写“对比用例”

大模型需要看到具体例子才知道你要的用例长什么样。尤其是“对比用例”，它有别于普通功能用例，预期结果里需要体现双边产品表现对比，这条规则光靠文字描述很难让 AI 完全理解，必须配一个示例。

下面这个示例会被我直接写进提示词里：

示例： 用例编号：TC-Search-001 所属模块：搜索 功能点：搜索联想词展示 前置条件：用户已登录，进入首页，搜索框为空 测试步骤：

1. 点击首页顶部搜索框
2. 输入关键词“保温杯”
3. 观察搜索联想区域展示内容 测试数据：关键词“保温杯” 预期结果：

• 竞品A：输入后 0.3 秒内展示联想词列表，联想词高亮匹配部分，最多展示 8 条
• 自家产品：输入后 0.5 秒内展示联想词列表，联想词无高亮，最多展示 6 条
• 本次测试关注点：联想词的展示速度和数量差异是否影响用户体验 优先级：高

给一个示例之后，AI 输出的用例格式就比较稳了。如果你发现 AI 还是跑偏，再加一条反例：“以下是他人的错误写法，不要模仿”，把你不想要的格式贴进去，效果立竿见影。反例教学在提示词工程里非常有用。

3.4 一轮生成后的追问与收敛

不要指望一次提示词就能把用例生成完整。我通常分三轮走：第一轮让 AI 生成正常流程用例，第二轮要求补充异常和边界用例，第三轮针对差异表中标红的高优先级功能点做深度追问。

追问的方向也有讲究。比如第一轮生成完搜索功能用例后，我会追加一句：

针对“搜索历史”这个功能点，补充以下异常场景的用例：搜索历史为空、搜索历史超过 10 条、单条删除与清空历史同时触发、弱网状态下删除历史记录、切换账号后历史记录隔离。

这种追问本质上是在利用大模型对移动端通用交互的知识积累，把容易漏掉的异常分支补齐。实际使用中，AI 在异常场景上的补充能力远远超过普通测试人员的第一反应，因为它读过的产品案例足够多。

4. 从单条用例到场景矩阵：批量生成时的编排思路

4.1 按用户旅程拆解对比场景

单个功能点生成用例只是初步胜利，落到项目实践时，我们需要的是场景矩阵，而不是散落的用例列表。所谓场景矩阵，是把一条完整用户旅程上的所有用例串起来，保证从进入页面到完成目标，每一步都有用例覆盖。

我按用户旅程拆解场景时，通常用“主链路 + 支链路 + 异常链路”三种类型。以“下单支付”为例，主链路是“商品详情页 -> 立即购买 -> 确认订单 -> 选择支付方式 -> 支付成功 -> 订单列表可见”。支链路是“改地址 -> 改数量 -> 改优惠券 -> 返回详情页重新选规格”。异常链路则是“支付中断 -> 支付超时 -> 重复支付 -> 库存不足无法提交”。

拆解完成之后，把每个功能点塞进对应的链路位置，形成一张场景清单。这张清单既是给 AI 的输入索引，也是后续测试执行的检查表。AI 在场景矩阵里的作用不是从零到一创造场景，而是把场景里缺的步骤和边界条件自动补齐。

4.2 用例去重的自动策略

批量生成很容易出现重复用例。同一个“搜索无结果”场景，可能既出现在“搜索功能”模块，又出现在“首页搜索入口”模块，AI 会基于上下文生成两条高度相似的用例。如果不处理，导入测试管理平台后一堆重复项，评审工作量反而增加。

我试过几种去重方式，最简单有效的是“场景路径归一化”加“文本相似度阈值”。场景路径归一化是把用例的测试步骤转换成一个标准化字符串，比如“首页-搜索框-输入关键词-点击搜索-查看结果页”，然后对标准化后的字符串做文本相似度比较，相似度超过 85% 的自动标记为疑似重复。

在实际操作中，我会把 AI 生成的 JSON 结果先跑一遍这个去重脚本，再人工看一眼被标记的重复项。脚本不一定完全准确，但能把需要人工检查的量压缩到原来的三分之一。这个步骤虽然不起眼，却在批量生成时省下了大量时间。

4.3 让AI输出JSON，直接对接测试管理平台

用例生成出来最终要落到测试管理平台里。如果你用的平台有导入接口，强烈建议在提示词里要求 AI 输出结构化 JSON，而不是输出 Markdown 表格。JSON 可以直接被脚本解析，自动映射到平台字段。

我的输出约束通常是这样的：

请以 JSON 数组格式输出结果，数组中的每个元素包含以下字段：case_id、module、feature、precondition、steps、test_data、expected_result、priority、case_type。steps 和 test_data 用字符串数组，expected_result 用字符串描述。不要输出任何额外解释文字。

这里补充一个容易踩的坑：大模型输出 JSON 偶尔会附带前言，比如“好的，以下是你需要的用例：”，这段文字会直接把 JSON 解析器搞崩。我的解决方法是让解析逻辑自动截取第一个“{”到最后一个“}”之间的内容再解析，同时把“不要输出额外解释文字”这句话写进提示词。双保险之后，解析报错率能控制在 1% 以内。

5. 生成之后的事：AI用例的评审、校准与沉淀

5.1 最容易出现的幻觉类型和识别方式

AI 生成用例最大的风险是幻觉，而且幻觉出现的方式很有迷惑性。根据我的实际观察，竞品对比用例生成里最常见的幻觉有三种。

第一种是虚构竞品功能。比如差异表里只写了搜索历史最多展示 10 条，AI 可能在预期结果里补充“竞品A在搜索历史的第 10 条位置显示‘查看全部’按钮”，这个按钮实际上并不存在。第二种是混入自家产品逻辑。大模型在生成预期结果时，可能把自家产品的某个已知交互错误地套到竞品头上，导致用例断言失真。第三种是编造版本信息。AI 会说“竞品A在 8.2 版本中已经支持批量删除”，但实际上我们根本没验证过 8.2 版本的该功能。

识别幻觉的方法只有一个：抽检。AI 生成的每一条用例，都要有对应的输入来源标记。我在提示词里要求 AI 在 feature 字段后额外输出一个 source 字段，标注这条用例依据的是功能地图里的哪个功能点、差异表里的哪一行。如果没有明确的来源对应关系，这条用例就要被打回。

5.2 用回归结果反向修正提示词

AI 用例经过人工评审和测试执行之后，会产生一批执行结果。这些执行结果是非常宝贵的反馈数据，可以用来反向修正提示词。

举一个真实例子。第一版提示词生成的用例里，很多条预期结果写的是“页面展示正常”，这种描述在测试执行时基本没法判断通过与否。我们发现这个问题后，在提示词里加了一条约束：“预期结果必须包含可观察的页面状态、数据展示条件或交互反馈，禁止使用‘正常’‘异常’‘正确’等模糊词汇”。加上这条之后，后续生成的用例质量明显提升。

另一个例子是“测试数据”字段。AI 刚开始生成时喜欢用“输入合法手机号”“输入错误密码”这种抽象描述。我们在评审后把提示词改成“测试数据必须给出具体值，手机号用 13800138000，密码用自定义 8 位字符串”，让执行人员能直接复制使用。这个过程其实迭代了三轮才稳定下来。

5.3 把评审后的用例变成团队的提示词记忆库

AI 生成用例不是一次性活动。当某个模块的用例经过人工评审、测试执行、修正之后，这套“标准用例”本身就是高质量的示例数据。把评审后的用例沉淀下来，作为后续生成新用例的 Few-shot 示例，整个提示词库的价值会越来越大。

我采用的方式是维护一个“用例语料库”，按模块分类存放已评审通过的高质量用例。新项目来了，先从语料库里挑选 2 到 3 条相似模块的用例作为提示词示例，再让 AI 生成新用例。这样做的效果非常明显，AI 输出的风格和深度会向团队已有标准靠拢，人工修改量逐月下降。

这里要特别提醒一点：语料库里的用例一定要在评审通过之后才能入选，不然低质量用例会被 AI 当成“标准”反复学习，反而带偏后续生成结果。宁缺毋滥，是维护提示词记忆库的原则。

6. 我在真实项目里跑通的落地流程与工具选型

6.1 最小可用链路：脚本调用LLM生成用例

先给出一套任何人都能快速跑通的最小可用链路，不需要买平台，不需要写复杂系统。

第一步是整理输入数据：竞品功能地图和差异表，存成两个 Markdown 文件。第二步是准备一份提示词模板，模板里的输入部分用占位符替代，比如“{功能地图内容}”“{差异表内容}”“{功能模块名称}”。第三步是写一个简单的 Python 脚本，读取模板文件，替换占位符后调用大模型 API，把返回的 JSON 结果保存到本地。第四步是导入测试管理平台，做人工评审。

整个链路里唯一需要开发的就是那个 Python 脚本，核心逻辑不到 100 行。如果你对代码不熟悉，也可以直接用网页版模型，手动复制粘贴，只是批量生成时效率会差一些。

我当时是在一个中型电商项目上试运行的，整个过程只有我一个人在推进，从搭建脚本到生成第一批用例用了三天。第一天搭输入数据，第二天调提示词，第三天跑通生成并完成初步评审。第一批生成了三个模块共 120 条用例，人工修改了 30 条左右，整体可用率接近 75%，这个结果在当时已经给了团队很大的信心。

6.2 工具选型对比

市面上的 AI 工具选择很多，没必要一步到位搭 LangChain 这类复杂框架。我根据项目规模整理了三种典型方案，供不同团队参考。

在我们项目里，最实用的是第二种方案。脚本本身承担了输入组装、API 调用、JSON 解析、格式校验四个工作，而提示词模板放在独立的文本文件里，谁都可以改。这样既保留了灵活性，又比纯手动稳定得多。

6.3 成本与耗时实测

很多人提到 AI 生成用例，第一反应是成本会不会很高。从我实际测试的数据来看，结论可能和你想的不一样。

以当时使用的 LLM 为例，生成 100 条标准用例，输入部分主要是功能地图、差异表和提示词模板，大约消耗 8000 个 token；输出部分 100 条用例大概需要 15000 到 20000 个 token。按当时 API 价格折算，人民币大约在几块钱到十几块钱之间。这个成本在项目预算里基本可以忽略。

真正的大头是人力成本，但 AI 依然能显著压缩它。过去人工编写三个模块的对比用例，经验丰富的测试工程师需要一天到一天半。用 AI 生成后做人工评审和修改，整体半天左右就能完成。即使算上整理输入数据的时间，整体效率也提升了至少一半。而且 AI 最厉害的地方在于，它能保持输出格式的一致性，评审过程几乎不用花时间在格式调整上。

7. 给打算入坑的人几点建议

7.1 从小范围试点开始

不要一上来就把所有竞品、所有模块都交给 AI。我一开始也是雄心勃勃，想直接把整个竞品的用例全部生成完，结果被大量幻觉和格式问题淹没，差点放弃。后来冷静下来，只挑“搜索”这个功能模块做试点，从生成到评审跑通全流程，验证质量和效率都可以接受之后，再逐步扩大到其他模块。

试点模块的选择也有讲究。尽量挑边界清晰、功能稳定、差异点明确的模块，比如注册登录、搜索、个人中心。像支付、直播这类强业务逻辑、强后端交互的模块，初期建议让 AI 只负责生成主流程场景，异常场景留给资深测试人员手动补充，等提示词库沉淀成熟后再逐步放开。

7.2 决定“测什么”是人，AI 负责“怎么测”

使用 AI 半年之后，我最大的体会是：AI 是一个执行力极强的助手，但不是产品专家。测试范围和测试重点必须由人来定，AI 的价值在于把确定下来的范围快速转化成规范、细致的用例。

具体到协作方式上，我会在动手前把功能地图和差异表完整人工梳理一遍，把真正需要关注的差异点标出来。这个动作看似费时，实际上是在给 AI 划定边界。边界越清晰，AI 的幻觉越少，生成结果的可用率越高。如果你跳过这个步骤直接让 AI 发挥，生成的用例数量再多，也只是一堆漂亮话。

7.3 保持用例的可追溯性

最后一条建议也是我踩坑最深的教训：每一条 AI 生成的用例都要能追溯到它的输入来源。否则两个月后你发现一条用例的预期结果有问题，想回头查是哪个功能描述被误解了，会完全摸不着头脑。

我在实践中建立了一个简单的关联规则：每条用例的 feature 字段必须和功能地图中的功能点一一对应，差异表里的每个高优先级差异项必须至少有一条用例覆盖。这样既保证了生成结果不遗漏重点，也方便项目复盘时回头审查。竞品对比测试本身就是一场持续博弈，AI 帮你把用例生成效率提上去了，可追溯性才是让这套体系长期运转的保障。

在实际项目里把 AI 生成竞品对比用例这套流程跑通之后，我现在反而不担心竞品改版了。每次竞品发布新版本，团队只需要更新功能地图和差异表，重新跑一遍生成链路，就能很快拿到一份结构统一的对比用例。省下来的时间被我们用在了更值得投入的地方——分析竞品为什么这样设计、我们的下一步该往哪儿走。这种从“搬砖”到“思考”的转变，才是测试人员真正需要的价值。