¥
立即购买

系统功能测试用例设计

35 浏览
3 试用
0 购买
Dec 11, 2025更新

本提示词专为系统分析师和测试工程师设计,能够根据具体功能需求生成结构完整、逻辑严谨的测试用例。通过系统化的分析流程,确保测试用例覆盖功能边界、异常场景和性能要求,提供清晰的测试步骤、预期结果和优先级评估。适用于软件开发生命周期中的测试阶段,帮助团队建立标准化的测试文档,提高测试效率和质量保证水平。

文生文-长文摘要 功能测试用例集(功能测试|测试环境)

以下用例基于需求“对包含议程、结论、行动项的会议纪要进行自动摘要,输出不超过300字,按‘背景-要点-行动’三段结构呈现,保留日期、负责人与关键指标,去除口头语与重复,支持中英混排与常见表情符号”设计,覆盖正常流程、边界条件与异常输入。

通用约定

  • 输出结构:三段,且按顺序“背景:/要点:/行动:”,每段为独立段落或行。
  • 字数限制:输出总长度≤300字(按Unicode字符计数,包含中英文、标点与 emoji)。
  • 保留要素:会议日期(任一标准格式)、负责人姓名(中/英文均可)、关键指标(数值+单位/百分号/KPI 名称)。
  • 清洗规则:去除口头语(如“嗯、啊、那个、就是、然后、呃”等)与重复信息;无乱码。
  • 不臆造:若原文缺失某类信息,不得凭空生成,可在对应段标注“未提及/无”或留空但保留段落标题。

测试环境与前置条件(适用于所有用例)

  • 环境:测试环境(UTF-8),摘要服务可用,接口/页面可访问。
  • 账号:测试账号已就绪(如需鉴权)。
  • 工具:浏览器或API工具(如Postman),文本编辑器用于统计字符数。
  • 配置:关闭浏览器/系统自动翻译;确保emoji显示正常。
  • 校验方法:人工比对 + 辅助脚本统计字符长度(以Unicode code point计);正则验证段落标题与顺序。

用例 SUM-001|正常流程-完备纪要摘要

  • 测试目标和范围
    • 验证标准会议纪要能按“背景-要点-行动”三段输出,保留日期/负责人/指标,≤300字。
  • 前置条件和测试环境要求
    • 使用包含议程、结论、行动项、日期(2025-12-10)、负责人(张三/Alice)、指标(CTR 12.5%/DAU 1.2万)的中文纪要样本。
  • 详细的测试步骤
    1. 准备会议纪要文本(含:会议日期、议程3条、结论2条、3条行动项及负责人与截止日期、关键指标)。
    2. 提交到摘要功能(页面粘贴或API调用)。
    3. 查看输出。
    4. 统计字符数;比对结构与要素保留情况。
  • 预期结果和验收标准
    • 输出分3段,顺序与标题准确:背景、要点、行动。
    • 含会议日期“2025-12-10”;至少1名负责人姓名;保留关键指标(如“CTR 12.5%,DAU 1.2万”)。
    • 去除口头语与明显重复;无乱码。
    • 总长度≤300字。
  • 测试优先级和执行建议
    • P0;首批执行。
  • 备注和风险提示
    • 指标保留需优先于次要细节;若超长,应优先保留指标与负责人。

用例 SUM-002|超长输入-摘要限长与信息优先级

  • 测试目标和范围
    • 验证超长纪要(>10,000字)时,输出≤300字且优先保留日期/负责人/指标/决策要点。
  • 前置条件和测试环境要求
    • 超长中文纪要,含丰富细节、重复发言、多个小议题。
  • 详细的测试步骤
    1. 提交超长纪要。
    2. 检查输出结构与长度。
    3. 核对是否保留关键要素并去重。
  • 预期结果和验收标准
    • 结构正确;≤300字。
    • 保留:会议日期、每个核心议题的结论要点、关键指标、行动项与负责人。
    • 显著重复与冗语被删除;语句通顺无截断。
  • 测试优先级和执行建议
    • P0;与SUM-001后执行。
  • 备注和风险提示
    • 注意是否出现生硬截断(如半句末尾)。

用例 SUM-003|缺少行动项

  • 测试目标和范围
    • 原文无行动项时,验证“行动”段存在但不臆造内容。
  • 前置条件和测试环境要求
    • 纪要包含议程与结论,无“行动项/ToDo/Next Steps”。
  • 详细的测试步骤
    1. 提交文本。
    2. 核对输出“行动”段。
  • 预期结果和验收标准
    • “行动:”段存在,内容为“未提及/无/空”其一;不生成虚构任务。
    • 其他段正常;≤300字。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 接受“空段内容”或“未提及”两种形式之一,需产品确认一致性策略。

用例 SUM-004|缺少结论类信息

  • 测试目标和范围
    • 原文议程多、结论弱或缺失时,“要点”能提炼讨论要点,不臆造“已决策”。
  • 前置条件和测试环境要求
    • 纪要以讨论为主,无明确“结论/决定”字样。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查“要点”段措辞。
  • 预期结果和验收标准
    • “要点:”归纳讨论重点,避免“已决定/将执行”等断言性措辞。
    • 结构与长度合规。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 关注措辞客观性。

用例 SUM-005|日期识别多格式

  • 测试目标和范围
    • 识别并保留日期的多种格式且不误取历史日期。
  • 前置条件和测试环境要求
    • 原文包含“会议日期:2025-12-10”,同时提及“上次会议 2025/12/01 回顾”。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查摘要中的日期。
  • 预期结果和验收标准
    • 摘要仅保留当前会议日期(2025-12-10或等价中文格式);不误用“上次会议”日期。
    • 其他项合规。
  • 测试优先级和执行建议
    • P0。
  • 备注和风险提示
    • 若保留多个日期,需明确当次会议日期优先并在上下文不产生歧义。

用例 SUM-006|负责人识别-中英混排与@标记

  • 测试目标和范围
    • 保留负责人姓名(中/英),识别“负责人/Owner/DRI/@姓名”形式。
  • 前置条件和测试环境要求
    • 文本含“负责人:张三”、“Owner: Alice”、“@Bob 负责数据联调”。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查“要点/行动”中负责人展示。
  • 预期结果和验收标准
    • 至少保留1-2个关键负责人与其对应事项;名称未被误分词或丢失。
  • 测试优先级和执行建议
    • P0。
  • 备注和风险提示
    • 英文名大小写与特殊字符(如连字符)保持原样或规范化但不失真。

用例 SUM-007|关键指标保留与单位

  • 测试目标和范围
    • 保留并正确呈现指标数值与单位/百分号/KPI名称。
  • 前置条件和测试环境要求
    • 指标示例:CTR 12.5%,DAU 1.2万,转化率提升2pp,预算 30k USD,GMV 300万。
  • 详细的测试步骤
    1. 提交含多指标文本。
    2. 检查“要点/背景”中指标展示。
  • 预期结果和验收标准
    • 关键指标未被遗漏或错误归一化(如12.5%不变成0.125);单位与KPI名称保留。
  • 测试优先级和执行建议
    • P0。
  • 备注和风险提示
    • 若字数受限,指标优先保留于一般描述之前。

用例 SUM-008|去除口头语与重复

  • 测试目标和范围
    • 清洗“嗯、啊、就是、那个、然后、呃”等口头语与重复句。
  • 前置条件和测试环境要求
    • 文本包含大量口头语与同义重复表述(连续两段重复结论)。
  • 详细的测试步骤
    1. 提交文本。
    2. 对比输出与原文,检查冗语是否去除。
  • 预期结果和验收标准
    • 口头语基本消除;重复要点合并为一次表达;语义不受损。
    • 结构与长度合规。
  • 测试优先级和执行建议
    • P0。
  • 备注和风险提示
    • 允许极少量上下文必须的口语保留,但不得影响专业性。

用例 SUM-009|中英混排与Emoji支持

  • 测试目标和范围
    • 混合中英文本与常见emoji(🙂👍😂)时输出稳定,无乱码,长度合规。
  • 前置条件和测试环境要求
    • 文本含中英句段及emoji;部分行动项为英文表达。
  • 详细的测试步骤
    1. 提交文本。
    2. 校验输出字符显示与长度。
  • 预期结果和验收标准
    • 输出不出现方框/问号替代符;可选择性不保留emoji,但不得影响内容与结构;≤300字。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 若输出保留emoji,计入字符数且不破坏段落。

用例 SUM-010|跨段重复要点去重

  • 测试目标和范围
    • 议程与结论重复时,摘要只保留一次或合并,不自相矛盾。
  • 前置条件和测试环境要求
    • 同一要点在“议程/讨论/结论”出现3次。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查“要点”去重情况。
  • 预期结果和验收标准
    • 去重后保留为清晰的一条;语义完整;结构合规。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 注意不要误删导致信息缺失。

用例 SUM-011|复杂格式解析(列表/表格/Markdown)

  • 测试目标和范围
    • 含有项目符号、编号、简单表格或Markdown标记的文本可被正确解析并摘要。
  • 前置条件和测试环境要求
    • 文本含“•/-/*/1.”列表,简易表格(| 指标 | 数值 |),Markdown标题。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查摘要内容是否正确抽取(不带原始标记)。
  • 预期结果和验收标准
    • 输出不包含生硬标记字符(如“|---|”),信息被语义化整合;结构与长度合规。
  • 测试优先级和执行建议
    • P2。
  • 备注和风险提示
    • 仅验证常见简单格式,非富文本渲染。

用例 SUM-012|特殊字符与标点鲁棒性

  • 测试目标和范围
    • 处理中文全角标点、破折号、引号、非断行空格、长数字串等不出现乱码或断句异常。
  • 前置条件和测试环境要求
    • 文本含“——”“……”“‘’”““””“ (不换行空格)”及长货号/订单号。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查输出标点与断句。
  • 预期结果和验收标准
    • 输出标点正常;无异常换行与乱码;结构合规。
  • 测试优先级和执行建议
    • P2。
  • 备注和风险提示
    • 注意字符计数是否将特殊空格计入。

用例 SUM-013|行动项提取-含截止日期

  • 测试目标和范围
    • 行动项正确提取,保留负责人与截止日期(yyyy-mm-dd/中文日期/英文DUE)。
  • 前置条件和测试环境要求
    • 文本含“李四 截止 2025/12/31 完成X”“DUE: 2026-01-15 Owner: Bob”。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查“行动”段是否列出上述行动项与日期。
  • 预期结果和验收标准
    • 行动项清晰,含“任务+负责人+截止日期”;不遗漏关键一项。
  • 测试优先级和执行建议
    • P0。
  • 备注和风险提示
    • 若多项超出长度,优先保留期限更近/更关键项。

用例 SUM-014|行动项含多人协作

  • 测试目标和范围
    • 行动项涉及多负责人时准确呈现(“张三/王五”“Alice & Bob”)。
  • 前置条件和测试环境要求
    • 原文明确多名执行人。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查“行动”段多人保留情况。
  • 预期结果和验收标准
    • 多负责人均被保留或以清晰合并格式呈现;不误归属。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 避免把协作者合并为单人。

用例 SUM-015|输出结构校验-标题与顺序强约束

  • 测试目标和范围
    • 标题文本与顺序严格为“背景:/要点:/行动:”。
  • 前置条件和测试环境要求
    • 任意标准纪要文本。
  • 详细的测试步骤
    1. 提交文本。
    2. 用正则校验三段标题与顺序。
  • 预期结果和验收标准
    • 标题与顺序完全一致;无缺段、无调换。
  • 测试优先级和执行建议
    • P0。
  • 备注和风险提示
    • 若产品允许等价标题(如“背景-”),需统一约定。

用例 SUM-016|输出长度边界-恰好300字

  • 测试目标和范围
    • 验证边界:输出可达到恰好300字但不超;不出现词语截断。
  • 前置条件和测试环境要求
    • 通过构造使摘要接近边界的长文本。
  • 详细的测试步骤
    1. 提交文本。
    2. 统计输出字符数。
    3. 人工检查末尾语义完整。
  • 预期结果和验收标准
    • 字符数==300或<300;末尾不截断词语/人名/数字;结构合规。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 统计以Unicode计;换行计入或不计入需固定策略(建议计入)。

用例 SUM-017|极短文本/信息缺失

  • 测试目标和范围
    • 极少信息时仍输出三段结构,不臆造。
  • 前置条件和测试环境要求
    • 文本仅含“会议日期:2025-12-10”。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查三段内容。
  • 预期结果和验收标准
    • 三段存在;背景可仅含日期;要点/行动为“未提及/无/空”之一;≤300字。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 不得生成虚构要点或行动。

用例 SUM-018|非会议文本的稳健处理

  • 测试目标和范围
    • 输入并非会议纪要时,系统稳健输出且不误造信息。
  • 前置条件和测试环境要求
    • 文本为产品说明片段或随笔。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查输出措辞与结构。
  • 预期结果和验收标准
    • 保持三段结构;说明信息不足或给出通用概述;不生成虚构日期/行动项。
  • 测试优先级和执行建议
    • P2。
  • 备注和风险提示
    • 可标注“非会议文本,信息不足”。

用例 SUM-019|HTML/富文本标签清理


用例 SUM-020|多日期语境-选择当次会议日期

  • 测试目标和范围
    • 同时出现历史日期、计划日期时,摘要保留“当次会议日期”。
  • 前置条件和测试环境要求
    • 文本含“会议日期:2025-12-10”“回顾 2025-12-01”“上线目标 2026-01-05”。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查保留日期。
  • 预期结果和验收标准
    • 保留“2025-12-10”;其他日期可被提及但不得混淆当次日期语义。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 若仅能保留一个日期,必须是当次会议日期。

用例 SUM-021|数字与本地化单位识别

  • 测试目标和范围
    • 识别“1.5k/30k USD/2亿/3m/2pp”等单位与缩写。
  • 前置条件和测试环境要求
    • 文本含多种本地化及英文缩写单位。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查关键指标呈现。
  • 预期结果和验收标准
    • 单位与数值不被错误换算或丢失;如“2pp”不误为“2%”。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 关注“万/亿”等中文数量级。

用例 SUM-022|段内排序与逻辑清晰

  • 测试目标和范围
    • “要点/行动”段内部信息按照重要性或时间顺序呈现,不杂糅。
  • 前置条件和测试环境要求
    • 文本含多条要点与行动,含不同重要级与截止时间。
  • 详细的测试步骤
    1. 提交文本。
    2. 检查要点逻辑顺序、行动按截止期排序倾向。
  • 预期结果和验收标准
    • 要点从总体决策到细节;行动优先更紧急/关键项(如无法保证严格排序,至少重要项不被淹没)。
  • 测试优先级和执行建议
    • P2。
  • 备注和风险提示
    • 若产品无排序承诺,则以不打乱主要逻辑为准。

用例 SUM-023|多议题会议-跨议题要点归纳

  • 测试目标和范围
    • 多个议题(产品/运营/技术)下的要点被压缩成清晰分条,不混淆负责人。
  • 前置条件和测试环境要求
    • 文本至少3个议题,各含结论与行动项。
  • 详细的测试步骤
    1. 提交文本。
    2. 核对要点与行动中议题与负责人的对应关系。
  • 预期结果和验收标准
    • 要点覆盖各议题核心结论;行动项与对应负责人不串项;≤300字。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 注意跨议题同名指标上下文。

用例 SUM-024|语言输出一致性(中文标题)

  • 测试目标和范围
    • 输出标题与整体语言统一为中文;英文内容保留原文但不改变标题语言。
  • 前置条件和测试环境要求
    • 文本含较多英文段落。
  • 详细的测试步骤
    1. 提交文本。
    2. 校验标题语言与内容语言混排显示。
  • 预期结果和验收标准
    • 标题为中文“背景/要点/行动”;英文要点原样或合理压缩保留;≤300字。
  • 测试优先级和执行建议
    • P1。
  • 备注和风险提示
    • 避免自动翻译导致术语失真。

用例 SUM-025|敏感/私密占位策略(不泄露)

  • 测试目标和范围
    • 验证在未授权的敏感内容示例下,摘要不泄露真实敏感配置(使用伪造占位符)。
  • 前置条件和测试环境要求
    • 使用脱敏示例(如“XX系统”“某指标”)。
  • 详细的测试步骤
    1. 提交脱敏文本。
    2. 检查输出是否保持脱敏。
  • 预期结果和验收标准
    • 输出不还原真实数据;沿用占位信息;结构合规。
  • 测试优先级和执行建议
    • P2。
  • 备注和风险提示
    • 该用例用于验证测试数据规范性与系统不反推细节。

执行建议与顺序

  • 第一批(P0):SUM-001/002/005/006/007/008/013/015
  • 第二批(P1):SUM-003/004/009/014/016/017/020/021/023/024
  • 第三批(P2):SUM-010/011/012/018/019/022/025

附加说明

  • 样例输入请使用虚构组织与人物(如张三、李四、Alice、Bob),避免真实业务数据。
  • 若产品对“无/未提及/空段”的呈现需统一,请在执行前冻结期望格式。
  • 字符统计口径需在团队内对齐(是否计入换行),建议计入所有可见字符与换行,以便一致验证。

以下为“文生文-风格改写(社交聊天体 → 正式公文体)”回归测试用例集。各用例均在开发环境执行,覆盖正常流程、边界条件与异常处理,并重点验证数字/时间/人名/引用保留、客观语气、分段清晰、全角/半角与emoji处理、以及改写差异高亮标记等关键需求。

用例统一前置说明(适用于所有用例,个别用例若有差异将单独补充):

  • 环境:开发环境,功能模块“文生文-风格改写”已部署可用
  • 账号:具备该模块访问权限的测试账号
  • 差异高亮标记规范:以当前产品配置为准(例如:是否提供“新增/删除/替换”粒度、使用何种标记样式)。本用例在验收中以“符合系统既定的差异标记规范”为判定标准
  • 输入输出接口/页面:按系统提供的交互路径(Web或API),本用例步骤按“页面交互”描述;API场景可等价替换为HTTP调用步骤
  • 最大输入长度、超时时间、并发限制等以系统配置为准(本文不设具体数值,仅要求满足系统SLA)

— — —

测试用例编号和名称:RW-001 基础改写-口语到公文体(含数字/时间/人名/引用) 测试目标和范围:

  • 验证基础改写能力:将口语化文本转为客观、正式、公文体
  • 核查数字、时间、人名、引用内容严格保留且不改变事实
  • 验证分段清晰与差异高亮展示 前置条件和测试环境要求:
  • 参见统一前置说明
  • 测试输入: 大家好啊~关于昨天的会,我这边先说下,张三上午10点说“下周一再讨论”,我们差不多3点再看吧;我觉得问题不大^_^ 详细的测试步骤:
  1. 打开“文生文-风格改写”模块
  2. 粘贴上述输入文本并提交改写
  3. 查看改写结果与差异高亮 预期结果和验收标准:
  • 输出语气客观、正式,不包含“啊~、吧、^_^”等口语/表情
  • 数字“10”“3”、时间“上午10点”、引用“下周一再讨论”、人名“张三”不被更改、顺序不变、未被差异高亮误标
  • 事实不变(含“下周一”语义不变)
  • 输出分段合理(至少将“关于会议”与“后续时间点”信息明确分句/分段)
  • 差异高亮仅对风格/措辞变化进行标注,未改内容不高亮 测试优先级和执行建议:P0,优先执行 备注和风险提示:
  • 如系统策略对表情处理为删除或替换,需符合既定策略且不影响事实

— — —

测试用例编号和名称:RW-002 数字与单位保留 测试目标和范围:

  • 验证整数/小数/区间/百分比/单位不被修改、不错位 前置条件和测试环境要求:
  • 输入: 昨天修了2个bug,还剩1个,预计3~5天搞定,进度90%。内存从1.5GB降到1.2GB,CPU 3.2GHz那台还行。 详细的测试步骤:
  1. 提交输入文本
  2. 对比输出与差异高亮 预期结果和验收标准:
  • 数字与单位原样保留:2、1、3~5、90%、1.5GB、1.2GB、3.2GHz
  • 未改变事实数量/区间/单位,未被误高亮
  • 文风转正式(如“还行”等口语被正式化) 测试优先级和执行建议:P0 备注和风险提示:注意“~”区间符、百分号、单位与数字的紧邻关系不被打断

— — —

测试用例编号和名称:RW-003 多种时间格式保留 测试目标和范围:

  • 验证多样时间表达保留:相对/绝对时间、带时区 前置条件和测试环境要求:
  • 输入: 今天下午3点我们对齐;截止时间是2025-12-31 23:59:59(UTC+8);另一个时段为3pm。 详细的测试步骤:
  1. 提交输入
  2. 校验时间串在输出与差异高亮中的一致性 预期结果和验收标准:
  • “今天下午3点”“2025-12-31 23:59:59”“UTC+8”“3pm”均原样保留且不被误改/误高亮
  • 语气客观、标点规范 测试优先级和执行建议:P0 备注和风险提示:如系统对相对时间有标准化策略,需与配置一致但不可改变事实含义

— — —

测试用例编号和名称:RW-004 人名保留(中英文/昵称/@提及) 测试目标和范围:

  • 验证中英文姓名、昵称、@提及不改动 前置条件和测试环境要求:
  • 输入: @李四 和 Alice Chen 会参与评审;另外请 @hugo 跟进。 详细的测试步骤:
  1. 提交输入
  2. 核查输出与差异高亮 预期结果和验收标准:
  • “@李四”“Alice Chen”“@hugo”不被改动、不被误高亮
  • 文风公文化(如“请…跟进”可保留客观礼貌表述) 测试优先级和执行建议:P0 备注和风险提示:避免将@提及误判为特殊符号而丢失

— — —

测试用例编号和名称:RW-005 引用内容保留(含内层引号) 测试目标和范围:

  • 验证双引号/单引号/嵌套引用内文本原样保留 前置条件和测试环境要求:
  • 输入: 他说:“请保持‘原文引用’不变”。我们将据此处理。 详细的测试步骤:
  1. 提交输入
  2. 比对输出与差异高亮 预期结果和验收标准:
  • “请保持‘原文引用’不变”内文本完全不变、不被改写或高亮
  • 引号成对、方向与样式不紊乱(全角/半角按配置)
  • 段落与语气正式 测试优先级和执行建议:P0 备注和风险提示:重点检查嵌套引号方向性与配对

— — —

测试用例编号和名称:RW-006 事实含义不变-否定/范围/比较用语 测试目标和范围:

  • 验证否定、不超过/不少于、至少/至多等语义不被改变 前置条件和测试环境要求:
  • 输入: 本次不是上线,是预演;数量不超过10个,至少保留2个;目前未发现阻塞问题。 详细的测试步骤:
  1. 提交输入
  2. 审核改写后关键否定/范围词语 预期结果和验收标准:
  • “不是”“不超过10个”“至少2个”“未发现阻塞”语义完全不变
  • 不因公文化而出现语义翻转或范围变化
  • 差异高亮不覆盖保留的事实性词组 测试优先级和执行建议:P0 备注和风险提示:关注“≥/≤/不/未/无”等词组在改写中的保留

— — —

测试用例编号和名称:RW-007 emoji 正确处理 测试目标和范围:

  • 验证常见emoji及组合不乱码、不破坏句法;按策略处理(保留或去除) 前置条件和测试环境要求:
  • 输入: 这事儿搞定啦😂👍,辛苦大家啦~🎉 详细的测试步骤:
  1. 提交输入
  2. 核查输出与差异高亮 预期结果和验收标准:
  • 不出现乱码或方框字;若系统策略为删除/替换,删除或替换位置不影响句法与事实
  • 语气客观,去除口语化表达(如“啦~”)
  • 差异高亮准确标记与emoji相关的改动,不误伤其他文本 测试优先级和执行建议:P0 备注和风险提示:不同平台emoji渲染差异,注意统一编码验证

— — —

测试用例编号和名称:RW-008 全角/半角标点处理 测试目标和范围:

  • 验证中英文标点全角/半角混排时不乱码、不丢失、不错位 前置条件和测试环境要求:
  • 输入: 请确认(A/B测试),涉及范围:产品、运营; 同步人:[张三、李四]。 详细的测试步骤:
  1. 提交输入
  2. 检查输出标点的成对性与位置 预期结果和验收标准:
  • 括号、方括号、冒号、分号、中英文逗号等保持语义正确;不出现丢失或顺序错乱
  • 若系统有标点正则化策略(如中文内优先全角),应符合该策略 测试优先级和执行建议:P0 备注和风险提示:关注“;”与“;”、“,”与“,”的规范化一致性

— — —

测试用例编号和名称:RW-009 段落与结构化输出 测试目标和范围:

  • 验证长句/多主题输入被拆分为清晰段落 前置条件和测试环境要求:
  • 输入: 昨天对接了供应商,初步确认报价可谈,我们内部还要再评估下;另外,下周需要准备材料给法务,再者,市场那边也在看竞品,可能会调整定位。 详细的测试步骤:
  1. 提交输入
  2. 查看输出段落划分 预期结果和验收标准:
  • 至少按“供应商报价”“法务材料”“市场竞品”划分为多段或多句清晰表达
  • 语气客观,无口头语
  • 差异高亮集中在风格化更改 测试优先级和执行建议:P0 备注和风险提示:避免机械断句导致语义割裂

— — —

测试用例编号和名称:RW-010 混合中英文/技术术语/货币与百分号 测试目标和范围:

  • 验证英文术语、版本号、货币、百分号、下划线保留 前置条件和测试环境要求:
  • 输入: 已升级到 API v2.1,ID 为 abc_123;成本约 CNY ¥1,234.50,折扣 12.5%。 详细的测试步骤:
  1. 提交输入
  2. 校验英文术语、符号 预期结果和验收标准:
  • “API v2.1”“abc_123”“CNY ¥1,234.50”“12.5%”原样保留,不改动、不误高亮
  • 千分位与货币符号不丢失 测试优先级和执行建议:P1 备注和风险提示:注意“¥”“$”“€”等特殊符号编码

— — —

测试用例编号和名称:RW-011 引用中的数字与姓名保留且不高亮 测试目标和范围:

  • 验证引用块内任何事实性信息均不被改写/高亮 前置条件和测试环境要求:
  • 输入: 会议纪要引用:“由王小明在3月15日提出的‘方案B’需保留评审结论”。 详细的测试步骤:
  1. 提交输入
  2. 检查引用内数字、人名、方案名 预期结果和验收标准:
  • “王小明”“3月15日”“方案B”在引号内无改动且无高亮 测试优先级和执行建议:P1 备注和风险提示:避免引用内术语被替换为近义词

— — —

测试用例编号和名称:RW-012 仅包含emoji/符号的输入 测试目标和范围:

  • 验证无法公文化的输入的稳健性 前置条件和测试环境要求:
  • 输入:😂😂😂!!!??? 详细的测试步骤:
  1. 提交输入
  2. 观察系统响应 预期结果和验收标准:
  • 系统不报错、不乱码;输出遵循策略(可能为原样返回或清理为可接受的空/提示性文本),不改变任何事实(不存在事实即不引入新事实)
  • 若有提示信息,应清晰、可理解 测试优先级和执行建议:P1 备注和风险提示:与产品确认该类输入的预期策略

— — —

测试用例编号和名称:RW-013 空输入/全空白输入 测试目标和范围:

  • 验证输入校验与错误提示 前置条件和测试环境要求:
  • 输入:空字符串或仅空格/换行 详细的测试步骤:
  1. 提交空/空白输入 预期结果和验收标准:
  • 友好的前端或接口错误提示(例如“输入不能为空”),不触发改写流程
  • HTTP/API状态码与错误码符合接口规范(如适用) 测试优先级和执行建议:P0 备注和风险提示:避免返回200但内容为空的歧义

— — —

测试用例编号和名称:RW-014 超长输入-边界内 测试目标和范围:

  • 验证最大允许长度边界内稳定改写 前置条件和测试环境要求:
  • 构造接近系统最大长度限制(N-少量字符)的文本,包含数字/时间/人名/引用/emoji/中英混排 详细的测试步骤:
  1. 提交边界长度文本
  2. 观察性能与结果 预期结果和验收标准:
  • 在SLA内完成改写;无截断、无乱码
  • 关键事实与格式保留正确;差异高亮正常 测试优先级和执行建议:P1 备注和风险提示:记录耗时用于趋势监控

— — —

测试用例编号和名称:RW-015 超出最大长度-错误处理 测试目标和范围:

  • 验证长度超限时的错误提示 前置条件和测试环境要求:
  • 构造超过最大长度N的文本 详细的测试步骤:
  1. 提交超限文本 预期结果和验收标准:
  • 返回明确错误提示(如超出长度限制);不产生部分改写或不完整输出
  • 状态码与错误码符合接口规范(如适用) 测试优先级和执行建议:P0 备注和风险提示:避免服务端超时或崩溃

— — —

测试用例编号和名称:RW-016 Markdown/HTML符号与转义 测试目标和范围:

  • 验证包含“< > &”与Markdown语法字符时不被错误渲染或注入 前置条件和测试环境要求:
  • 输入: 请参考重要重点;路径为 ac;特殊符号:<, >, &。 详细的测试步骤:
  1. 提交输入
  2. 检查输出与差异高亮 预期结果和验收标准:
  • 输出不发生HTML注入/渲染错乱;必要时正确转义
  • 差异高亮本身的标记不与内容混淆(不破坏显示) 测试优先级和执行建议:P1 备注和风险提示:前端高亮渲染与后端转义需一致

— — —

测试用例编号和名称:RW-017 嵌套引用与多层引号健壮性 测试目标和范围:

  • 验证复杂嵌套引号保持配对与内容不变 前置条件和测试环境要求:
  • 输入: 他表示:“李四提到‘张三说“本周五提交”’应记录在案。” 详细的测试步骤:
  1. 提交输入
  2. 检查引号层级与时间、人名 预期结果和验收标准:
  • 所有引号配对正确,最内层“本周五提交”、人名“李四”“张三”不变
  • 无错误高亮 测试优先级和执行建议:P1 备注和风险提示:关注中英文引号混用时的方向一致性

— — —

测试用例编号和名称:RW-018 URL/邮箱/标识符保留 测试目标和范围:

  1. 提交输入
  2. 检查输出与高亮 预期结果和验收标准:
  • URL、邮箱、编号“NO-2025-001”原样保留、不被高亮
  • 文风公文化 测试优先级和执行建议:P1 备注和风险提示:确保“&”“?”等符号未被转义破坏

— — —

测试用例编号和名称:RW-019 已较为正式文本的最小改动 测试目标和范围:

  • 验证输入已为正式风格时,改写最小化(避免过度修改) 前置条件和测试环境要求:
  • 输入: 经讨论,初步结论如下:一是继续推进现有方案;二是同步评审进度;三是下周提交材料。 详细的测试步骤:
  1. 提交输入
  2. 比对差异 预期结果和验收标准:
  • 输出与输入基本一致,仅进行必要的标点/格式微调(如有)
  • 差异高亮最小化,未引入新事实或变更语义 测试优先级和执行建议:P0 备注和风险提示:防止风格“来回折腾”造成噪声

— — —

测试用例编号和名称:RW-020 差异高亮-新增/删除/替换覆盖性与准确性 测试目标和范围:

  • 系统化验证高亮标记对所有改动均有覆盖,且未高亮未变更内容 前置条件和测试环境要求:
  • 选取包含口语词、emoji、标点规范化、同义替换的综合输入(可复用RW-001与RW-007文本并微调) 详细的测试步骤:
  1. 提交综合输入
  2. 将输出与输入做人工比对
  3. 检查差异高亮的覆盖与误报/漏报 预期结果和验收标准:
  • 所有改写处均被正确标记;数字/时间/姓名/引用/URL等保留项没有误高亮
  • 高亮标记不破坏显示(跨段落/跨句正常) 测试优先级和执行建议:P0 备注和风险提示:如高亮支持结构化diff,应覆盖新增/删除/替换三类

— — —

测试用例编号和名称:RW-021 幂等性:对改写结果再次改写 测试目标和范围:

  • 验证对“已改写结果”再次改写应无进一步变化 前置条件和测试环境要求:
  • 选取任一完成改写后的输出文本 详细的测试步骤:
  1. 将改写输出再次作为输入提交
  2. 比对两次输出 预期结果和验收标准:
  • 二次输出与一次输出一致(允许无关空白/不可见字符层面的微差,视系统规范)
  • 二次差异高亮为空或最小 测试优先级和执行建议:P1 备注和风险提示:防止递归风格漂移

— — —

测试用例编号和名称:RW-022 空行与多段混合输入 测试目标和范围:

  • 验证多段文本与空行在输出中被合理保留或规范化 前置条件和测试环境要求:

  • 输入: 第一段:昨天已完成初审。

    第二段:下周交付材料,联系人张三。 详细的测试步骤:

  1. 提交输入
  2. 检查段落与空行处理 预期结果和验收标准:
  • 段落边界清晰;空行处理符合产品规范(保留/合并但不混乱)
  • 事实与联系人信息保留 测试优先级和执行建议:P2 备注和风险提示:对富文本/多换行的兼容

— — —

测试用例编号和名称:RW-023 重复标点与情绪化标点规范化 测试目标和范围:

  • 验证“!!!”“??”等情绪化标点被规范处理 前置条件和测试环境要求:
  • 输入: 这个问题很紧急!!!能不能今天就搞定??? 详细的测试步骤:
  1. 提交输入
  2. 检查标点与语气 预期结果和验收标准:
  • 情绪化标点被规范化(按系统规则),语气客观
  • 不影响事实含义(未引入确定性承诺等) 测试优先级和执行建议:P2 备注和风险提示:确保不过度删减造成语义不明

— — —

测试用例编号和名称:RW-024 性能与简单并发回归(非指标测试) 测试目标和范围:

  • 基本验证在开发环境下常规长度输入的响应稳定性 前置条件和测试环境要求:
  • 选取10条常规长度的多样化输入(覆盖数字/时间/人名/引用/emoji) 详细的测试步骤:
  1. 逐条提交并记录响应是否超时/异常
  2. 可在短时间内并发触发多次请求(按环境允许) 预期结果和验收标准:
  • 均返回成功,结果正确,未出现超时/异常
  • 差异高亮均可正常展示 测试优先级和执行建议:P2 备注和风险提示:非性能压测,仅作稳定性回归

— — —

测试用例编号和名称:RW-025 异常字符编码与不可见字符 测试目标和范围:

  • 验证混入零宽空格、全角数字、稀有Unicode字符时的稳健性 前置条件和测试环境要求:
  • 输入示例(可人工插入零宽空格、全角数字123、罕见字符) 版本123将于明日上线,联系人张三​(含零宽空格)。 详细的测试步骤:
  1. 提交输入
  2. 检查输出是否丢字或乱码 预期结果和验收标准:
  • 字符不乱码;数字值语义不变(全角数字与半角的处理按系统策略)
  • 差异高亮不因不可见字符而错位 测试优先级和执行建议:P2 备注和风险提示:关注前端展示与后端处理一致性

— — —

测试用例编号和名称:RW-026 引用边界与高亮边界一致性 测试目标和范围:

  • 验证高亮边界不跨越引用边界导致视觉错乱 前置条件和测试环境要求:
  • 输入: 请严格保留“关键句子:上线日期为2025-01-01”。其他部分可公文化。 详细的测试步骤:
  1. 提交输入
  2. 检查高亮覆盖范围是否越界至引号内 预期结果和验收标准:
  • 引号内“关键句子:上线日期为2025-01-01”不高亮
  • 引号外的风格化改动被正确高亮 测试优先级和执行建议:P1 备注和风险提示:防止分词切断导致高亮越界

— — —

测试用例编号和名称:RW-027 语义边界-数量词与量纲 测试目标和范围:

  • 验证“约/大约/超过/不足/接近”等模糊量词不被语义强化/改变 前置条件和测试环境要求:
  • 输入: 大约需要5天,成本不超过20万元,目前接近完成。 详细的测试步骤:
  1. 提交输入
  2. 校核量词语义 预期结果和验收标准:
  • “大约/不超过/接近”语气与不确定性保持不变
  • 不被改写为确定性表述 测试优先级和执行建议:P1 备注和风险提示:避免将“约/不超过”改为固定值或范围变化

— — —

测试用例编号和名称:RW-028 列表/序号/项目符号的保留与规范 测试目标和范围:

  • 验证口语化列表转为规范序号/条款,且数字/顺序不变 前置条件和测试环境要求:
  • 输入: 我们后面做三件事:1) 完成测试;2) 出报告;3) 评审上线。 详细的测试步骤:
  1. 提交输入
  2. 检查输出的条款格式 预期结果和验收标准:
  • 1/2/3顺序与内容不变;可规范为条款格式(按系统策略)
  • 差异高亮聚焦格式与措辞变化 测试优先级和执行建议:P2 备注和风险提示:避免序号与内容错位

— — —

测试用例编号和名称:RW-029 含多个主题与跨句事实保留 测试目标和范围:

  • 验证多句跨主题时事实串联不被打断 前置条件和测试环境要求:
  • 输入: 张三负责A项目,里程碑在4月10日;李四对B项目做风险评估,预计两周后出结论。 详细的测试步骤:
  1. 提交输入
  2. 检查人员-项目-时间映射关系 预期结果和验收标准:
  • A项目—张三—4月10日;B项目—李四—两周后 的对应关系保持不变
  • 不产生交叉或归属混淆 测试优先级和执行建议:P1 备注和风险提示:关注句法重组后的事实映射

— — —

通用数据准备与环境要求补充:

  • 明确系统的:
    • 输入长度上限N与超时/并发限制
    • 差异高亮输出规范(字段/标记样式/是否结构化)
    • 标点与emoji处理策略(保留/替换/删除)
  • 准备一组覆盖用例所需的固定测试文本以便回归对比
  • 如使用API,准备对比脚本校验:数字/时间/人名/引用子串一致性、差异高亮命中率

统一结果验证要点(执行中须关注):

  • 不改变事实:数字、时间、人名、引用、URL/邮箱、编号、量词语气
  • 风格客观:去口语化、规范标点、避免感叹词/表情化用语
  • 段落清晰:按主题/事项拆分,避免语义割裂
  • 全角/半角/emoji:无乱码、无丢失、无错位
  • 差异高亮:不漏标、不误标、不越界、不破坏展示

统一测试优先级建议:

  • P0:RW-001/003/006/013/015/019/020(基础能力、输入校验、差异高亮准确性)
  • P1:RW-002/004/005/010/011/017/018/026/027/029
  • P2:RW-007/008/009/012/014/016/021/022/023/024/025/028

备注与风险提示(整体):

  • 差异高亮标记与文本内容存在转义/渲染耦合风险,需联合前端验证
  • emoji与全角/半角处理策略需在产品层清晰定义,避免验收歧义
  • 超长与编码类用例在开发环境性能可能与生产不同,回归时关注趋势一致性
  • 对于“语气客观”的判定应结合内置词库/规则基线,避免主观误差,可通过禁用词清单和保留项白名单提升一致性(测试侧校验,不要求产品暴露实现细节)

测试用例集:文生文-纲要成文(性能测试)

以下用例基于功能描述:“根据给定提纲生成五段产品发布说明,每段含标题与2-3句正文,术语与版本号一致,引用统一变更列表;需在2秒内完成生成,支持Markdown一级标题与有序列表输出”。系统环境:预生产环境。


TC-PERF-001 单请求SLA与格式完整性

  • 测试目标和范围

    • 验证在典型输入下,单次生成在2秒内完成,并且输出结构与格式满足要求(5段、每段标题+2-3句正文、Markdown一级标题、引用统一变更列表、术语与版本号一致)。
  • 前置条件和测试环境要求

    • 预生产环境可用,服务可访问且无异常告警。
    • 本地或CI环境时间同步(NTP),网络稳定(往返延时<50ms,抖动<10ms)。
    • 具备性能采集工具(如浏览器Performance、cURL+time_total、JMeter单线程取样、或服务端API网关日志)。
    • 准备标准化术语规范文档(本次版本使用术语的标准拼写/大小写,例如:“工作区”“插件”“集成”)与版本号(如:v3.2.0)。
    • 准备统一变更列表(示例:8条)。
    • 输出格式参数为:Markdown(一级标题+有序列表)。
  • 详细的测试步骤

    1. 构造请求,包含:
      • 提纲(5条):功能概述、性能优化、安全增强、兼容性改进、已知问题。
      • 版本号:v3.2.0。
      • 统一变更列表(示例8条,编号1-8)。
      • 输出格式:Markdown(一级标题+有序列表)。
    2. 启动定时器(T0),发送请求。
    3. 接收响应(T1),计算耗时(T1-T0)。
    4. 校验输出结构与格式:
      • 恰好5段,每段以Markdown一级标题“# 标题”开头。
      • 每段正文2-3句,标点完整。
      • 存在统一变更列表引用(引用的列表体一致,编号连续,且不因段落而变化)。
      • 全文版本号一致使用v3.2.0,无其他版本号混入。
      • 术语使用与术语规范一致(无别名/大小写混用/中英混写等不一致)。
    5. 记录日志:响应时间、解析校验结果、输出示例摘要。
  • 预期结果和验收标准

    • 性能:总耗时≤2s。
    • 格式:5段、每段“# 标题+2-3句正文”,统一变更列表被引用且一致。
    • 一致性:全文术语与版本号一致,无偏差。
  • 测试优先级和执行建议

    • 优先级:P0
    • 执行建议:冒烟后立即执行;作为后续批/并发测试的基线。
  • 备注和风险提示

    • 网络波动会影响结果,必要时在同网段或近端代理下复测3次取中位数。
    • 确保校验脚本能准确统计句子数(中文标点“。!?;”)。

TC-PERF-002 冷启动SLA

  • 测试目标和范围

    • 验证服务冷启动或长时间空闲后的首个请求是否仍满足2秒SLA。
  • 前置条件和测试环境要求

    • 停止相关服务/实例或清理预热缓存(按运维流程)。
    • 其他同TC-PERF-001。
  • 详细的测试步骤

    1. 冷启动服务或让服务空闲≥15分钟。
    2. 采用与TC-PERF-001相同的请求体。
    3. 记录首个请求的耗时与输出合规性。
    4. 重复3次冷启动场景(如重启3次),记录各次耗时。
  • 预期结果和验收标准

    • 每次首请求耗时≤2s。
    • 输出结构、术语、版本号、变更列表引用均合规。
  • 测试优先级和执行建议

    • 优先级:P0
    • 执行建议:每日构建或发布后执行,捕获冷启动回归。
  • 备注和风险提示

    • 如使用弹性伸缩/冻结策略,需与运维确认稳定复现冷启动条件。

TC-PERF-003 预热后稳定SLA(批量)

  • 测试目标和范围

    • 在服务预热后,连续多次请求的稳定性与SLA(≤2秒)。
  • 前置条件和测试环境要求

    • 服务已预热(先发送20次无记录请求)。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 发送20次预热请求(与TC-PERF-001同样输入),不计入统计。
    2. 连续发送100次同构请求,记录每次耗时与输出校验结果。
    3. 统计min/avg/95th/99th/max。
  • 预期结果和验收标准

    • 100%请求耗时≤2s。
    • 95th≤2s,且无输出结构或一致性校验失败。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:功能合规后执行,作为基线稳定性评估。
  • 备注和风险提示

    • 如存在偶发抖动,需复测并记录环境噪声(CI噪声/共享资源)。

TC-PERF-004 最大提纲规模边界SLA

  • 测试目标和范围

    • 验证在“最大合法提纲规模”输入下仍满足2秒SLA且输出合规。
  • 前置条件和测试环境要求

    • 获取接口文档中“提纲项数/字符数上限”(记为MAX_N与MAX_LEN)。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 构造接近上限的提纲(项数=MAX_N,单项字符≈MAX_LEN,总体不越界)。
    2. 其他输入同TC-PERF-001(版本号、术语规范、统一变更列表、Markdown格式)。
    3. 发送请求并记录耗时与输出合规性。
  • 预期结果和验收标准

    • 耗时≤2s;输出仍为5段、结构与一致性合规。
    • 不出现截断、乱码、格式错乱或服务端错误。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:在上线前对边界可靠性进行确认。
  • 备注和风险提示

    • 如无法从文档获取上限,先通过探测性测试确认安全边界再执行。

TC-PERF-005 最小提纲规模边界SLA

  • 测试目标和范围

    • 验证最小合法提纲输入时仍输出恰好5段且≤2秒。
  • 前置条件和测试环境要求

    • 获取接口文档中“最少项数/最少字符数”(MIN_N与MIN_LEN)。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 构造最小合法提纲(项数=MIN_N,每项≈MIN_LEN)。
    2. 其他输入同TC-PERF-001。
    3. 发送请求并验证输出段落数=5,结构与一致性合规,记录耗时。
  • 预期结果和验收标准

    • 耗时≤2s。
    • 无论提纲精简程度,仍生成5段;术语/版本/变更列表引用合规。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:与最大边界用例成对执行,覆盖输入边界。
  • 备注和风险提示

    • 若文档未规定最小输入,选择2-3条短项作为“近最小”方案并注明。

TC-PERF-006 术语一致性校验(带性能约束)

  • 测试目标和范围

    • 验证输出中术语在所有段落保持一致;同时满足2秒SLA。
  • 前置条件和测试环境要求

    • 有一份术语规范清单(示例:工作区、插件、集成、工作流),含中文全称/固定写法。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 构造包含上述术语的提纲内容(在每个段落的关注点中覆盖这些术语)。
    2. 请求参数同TC-PERF-001。
    3. 完成后扫描输出,统计术语出现次数与变体(包含大小写、简繁、英中混写、复数等)。
    4. 记录耗时。
  • 预期结果和验收标准

    • 耗时≤2s。
    • 所有术语仅以规范形态出现,无变体或不一致。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:在功能验收后执行,结合自动化正则校验。
  • 备注和风险提示

    • 若系统支持术语词表输入,可同步提供词表;否则基于输出进行一致性比对。

TC-PERF-007 版本号一致性与格式校验(带性能约束)

  • 测试目标和范围

    • 验证任意合法版本格式(如v3.2.0、v3.2.0-rc1)在全文保持一致且≤2秒。
  • 前置条件和测试环境要求

    • 版本号集合:v3.2.0、v3.2.0-rc1、3.2.0(无前缀,看系统要求择一)。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 选择本次发布使用的版本号(如:v3.2.0-rc1)。
    2. 构造标准请求(同TC-PERF-001),在正文逻辑中确保会多次引用版本号(如“本次v3.2.0-rc1发布……”)。
    3. 发送请求,记录耗时。
    4. 全文搜索版本号,确认只有目标版本格式出现,无其他变体(如“3.2”或“V3.2.0”等)。
  • 预期结果和验收标准

    • 耗时≤2s。
    • 版本号在所有段落一致,无格式漂移或变体。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:与术语一致性一并进行。
  • 备注和风险提示

    • 注意中英文字符混用导致的外观一致但编码不同的问题(全角/半角)。

TC-PERF-008 统一变更列表引用一致性(带性能约束)

  • 测试目标和范围

    • 验证所有段落引用同一份变更列表(内容与顺序一致、有序列表),≤2秒。
  • 前置条件和测试环境要求

    • 准备统一变更列表(10条,标题+简述),列表标号1..10。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 请求中提供统一变更列表,指定输出需“引用统一变更列表”(不按段落拆分)。
    2. 发送请求并记录耗时。
    3. 检查输出:
      • 是否存在单一的有序列表(1. 2. 3. …),未被拆分成多份。
      • 各段落对该列表的引用表述一致(如“详见以下变更列表”),未生成额外列表。
      • 列表条目顺序与文本一致、编号连续。
  • 预期结果和验收标准

    • 耗时≤2s。
    • 存在且仅存在一份变更列表;所有段落引用同一份列表;顺序与编号正确。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:与格式校验、术语/版本一致性联动校验。
  • 备注和风险提示

    • 若系统设计是在文末集中输出列表,应确认位置稳定且未重复。

TC-PERF-009 Markdown输出规范校验(带性能约束)

  • 测试目标和范围

    • 验证Markdown规范:一级标题(#)、有序列表(1. 2. 3.),行尾换行、编号连续,且≤2秒。
  • 前置条件和测试环境要求

    • Markdown渲染器(本地或在线)用于人工/自动对照渲染效果。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 构造请求(同TC-PERF-001)。
    2. 获取输出后,自动/人工校验:
      • 标题行以“# ”开头,紧随标题文本。
      • 段落正文非标题行,句间标点正确,换行符合Markdown习惯。
      • 变更列表使用“数字+点+空格”格式,编号连续,列表项之间换行。
    3. 记录耗时。
  • 预期结果和验收标准

    • 耗时≤2s。
    • Markdown结构正确,无渲染异常(渲染后标题、列表显示正确)。
  • 测试优先级和执行建议

    • 优先级:P1
    • 执行建议:与功能验收同步执行,纳入自动化校验。
  • 备注和风险提示

    • 跨渲染器差异(如GFM与CommonMark)可能造成轻微表现差异,聚焦基本语法。

TC-PERF-010 并发场景下SLA验证(中等并发)

  • 测试目标和范围

    • 验证在中等并发下SLA是否维持(每次请求≤2秒),并检测是否出现格式/一致性退化。
  • 前置条件和测试环境要求

    • 选定并发度K(与性能负责人确认,建议从K=10起分层:10/20/30)。
    • 负载工具(JMeter/Locust/k6),稳定网络与充足配额。
    • 同TC-PERF-001环境要求。
  • 详细的测试步骤

    1. 预热20次后,设置并发K,持续1-3分钟压测,采用与TC-PERF-001相同请求。
    2. 采集每次请求耗时与输出校验结果(结构、术语、版本、列表)。
    3. 统计成功率、avg/95th/99th/max。
  • 预期结果和验收标准

    • 成功率=100%(无错误/超时)。
    • 每次请求耗时≤2s;95th≤2s。
    • 无格式或一致性校验失败。
  • 测试优先级和执行建议

    • 优先级:P2
    • 执行建议:在与运维确认不影响他人使用的前提下执行,逐级提升并发,保留曲线。
  • 备注和风险提示

    • 预生产配额/限流可能影响结果,注意区分系统限流与性能瓶颈。

TC-PERF-011 段落体量边界(2句与3句)性能一致性

  • 测试目标和范围

    • 验证在正文句数边界(2句与3句)配置下均≤2秒且结构合规。
  • 前置条件和测试环境要求

    • 同TC-PERF-001环境要求。
    • 若支持句数约束参数,应显式传入;若不支持,则通过提纲与提示语控制。
  • 详细的测试步骤

    1. 请求A:要求每段2句(5段),其余同TC-PERF-001。
    2. 请求B:要求每段3句(5段),其余同TC-PERF-001。
    3. 分别记录耗时与输出校验结果(句子数、结构、一致性)。
  • 预期结果和验收标准

    • 两种配置下耗时均≤2s。
    • 对应句数严格满足2或3句,无越界。
  • 测试优先级和执行建议

    • 优先级:P2
    • 执行建议:与格式与一致性用例捆绑执行。
  • 备注和风险提示

    • 句子判定需考虑中文标点与可能的英文缩写,建议正则+人工抽样复核。

TC-PERF-012 多样化提纲分布(主题跨度)下的SLA稳健性

  • 测试目标和范围

    • 验证不同主题跨度(技术、产品、运营、合规、已知问题)混合时,SLA与合规性稳定。
  • 前置条件和测试环境要求

    • 同TC-PERF-001环境要求。
    • 准备3组不同主题组合的提纲(每组≥5项,覆盖不同语义领域)。
  • 详细的测试步骤

    1. 针对3组提纲分别发送请求(版本号、术语规范、统一变更列表一致)。
    2. 记录每组的耗时、结构、一致性与列表引用情况。
    3. 对比不同主题下的性能波动。
  • 预期结果和验收标准

    • 每组请求耗时≤2s。
    • 输出结构与一致性均合规,无主题导致的格式异常。
  • 测试优先级和执行建议

    • 优先级:P2
    • 执行建议:用于发现语义复杂度对生成时间的潜在影响。
  • 备注和风险提示

    • 主题跨度不应改变统一变更列表的一致性要求。

补充说明(通用于上述用例):

  • 数据准备

    • 示例统一变更列表(片段,用于占位):1. 提升启动速度;2. 优化内存占用;3. 加强登录安全策略;4. 新增Webhook扩展;5. 改进移动端适配;6. 修复崩溃问题;7. 提升API速率限制反馈;8. 改善日志可观测性。
    • 术语规范(示例):工作区、插件、集成、工作流、令牌、会话。
    • 版本号:v3.2.0 或 v3.2.0-rc1(按发布计划选定一种)。
  • 结果验证与度量方法

    • 时间度量:优先采集端到端时间(客户端T1-T0);如可用,辅以服务端处理时间以剔除网络因素。
    • 句子数判定:基于中文终止符(。!?)与英文终止符(.!?),对缩写及括号内终止符进行例外处理。
    • Markdown校验:正则校验结构+渲染器抽样对照。
  • 执行顺序建议

    1. TC-PERF-001(基线)→ 002(冷启动)→ 003(稳定批量)
    2. 006/007/008/009(一致性与格式)→ 011(句数边界)
    3. 004/005(输入边界)→ 012(主题跨度)
    4. 010(并发SLA,需运维窗口)
  • 风险提示

    • 不要在预生产执行超出许可的并发或持续压测,避免影响他人验证。
    • 若SLA临界(1.8-2.0s),建议复测并与网络与服务端监控对齐(CPU、内存、GC、限流、依赖RPC耗时)。
    • 如接口文档更新(输入上限/最小值/格式),需及时同步并调整边界用例。

示例详情

解决的问题

用一次清晰的输入,快速把“功能需求”转化为“可直接执行的测试用例包”,覆盖正常流程、边界与异常场景,并给出清晰的步骤、预期结果与优先级建议。帮助测试与产品团队:1) 标准化用例文档与输出结构;2) 提升覆盖率与可追溯性,降低漏测与返工;3) 按风险与业务价值排序执行,缩短发布周期;4) 支撑新功能验证、集成、回归与验收等全流程测试;5) 赋能新人快速上手,沉淀团队经验为可复用资产。

适用用户

测试工程师

新功能或改版时,一键生成覆盖主流程、边界与异常的用例包;自动带出步骤、数据与预期,减少重复撰写,快速进入执行阶段。

测试经理 / QA负责人

按业务风险自动分层与排序,形成优先级清单;统一文档格式用于评审与交付,提升人效与上线把控力。

系统分析师 / 产品经理

把需求条目转成可验证场景集,提前暴露逻辑缺口与歧义;为UAT准备标准脚本,保障验收一次通过。

特征总结

一键从功能描述生成成套测试用例,覆盖流程、边界与异常,减少手工编写时间
自动识别关键场景与角落条件,给出清晰步骤与预期结果,避免遗漏与歧义
内置优先级与执行建议,快速安排用例顺序,聚焦高风险高价值验证
智能提示数据准备与环境要求,减少搭建反复,保障测试一次到位更高效
输出结构规范易读,可直接纳入测试文档与评审材料,提升协作效率
适配功能验证、回归与验收等多类型,一套提示词覆盖多阶段全链路
支持Web、移动与企业系统等多端场景,轻松迁移到不同项目无缝复用
内置风险提示与验收标准,帮助团队统一口径,减少返工与争议成本
模板可按业务修改参数,批量生成变体用例,高效适配复杂流程需求

如何使用购买的提示词模板

1. 直接在外部 Chat 应用中使用

将模板生成的提示词复制粘贴到您常用的 Chat 应用(如 ChatGPT、Claude 等),即可直接对话使用,无需额外开发。适合个人快速体验和轻量使用场景。

2. 发布为 API 接口调用

把提示词模板转化为 API,您的程序可任意修改模板参数,通过接口直接调用,轻松实现自动化与批量处理。适合开发者集成与业务系统嵌入。

3. 在 MCP Client 中配置使用

在 MCP client 中配置对应的 server 地址,让您的 AI 应用自动调用提示词模板。适合高级用户和团队协作,让提示词在不同 AI 工具间无缝衔接。

AI 提示词价格
¥20.00元
先用后买,用好了再付款,超安全!

您购买后可以获得什么

获得完整提示词模板
- 共 573 tokens
- 4 个可调节参数
{ 功能模块名称 } { 测试功能描述 } { 测试类型 } { 系统环境 }
获得社区贡献内容的使用权
- 精选社区优质案例,助您快速上手提示词
使用提示词兑换券,低至 ¥ 9.9
了解兑换券 →
限时半价

不要错过!

半价获取高级提示词-优惠即将到期

17
:
23
小时
:
59
分钟
:
59