摘要我参与建设某连锁零售企业的订单与履约协同平台项目覆盖商品、库存、订单、配送和售后五个模块需要与门店收银、仓储系统及第三方配送接口交互。我担任需求分析与测试协同负责人负责梳理业务规则、维护需求追踪关系、组织验收测试并协调缺陷闭环。针对迭代快、接口组合多、历史用例更新滞后的问题项目以已评审的规格说明、接口契约和脱敏样例为依据引入 LLM 辅助生成测试场景、数据和断言候选再经人工评审与自动化回归验证。实践表明受控使用 LLM 能加快测试分析但必须以规则基线、权限隔离和结果验证约束其输出。该平台的目标是让门店订单在库存不足、拆单配送、退款逆向等场景下仍保持订单状态、库存数量和结算金额一致。项目启动时业务人员常用口头方式描述“缺货可拆单”“部分退款后优惠重算”等规则如果这些规则没有转化为可测试条件开发和测试对同一订单可能得出不同预期。我的主要工作是访谈运营、仓储、财务和客服代表形成业务规则表、状态转换模型和接口字段说明在需求评审后建立需求—用例—缺陷追踪矩阵并组织测试人员与开发人员对关键场景进行评审和验收。在测试用例生成方面我没有把原始需求直接交给 LLM 而是先将已基线化的用户故事、规则编号、状态图和接口契约按模块切分并删除订单号、手机号等敏感字段。模型收到的输入包含规则来源、前置条件、操作步骤和输出格式约束要求它按照“场景—条件—步骤—预期结果—关联规则编号”生成候选用例。例如对“订单部分缺货后拆单”的规则模型需要分别列出全量可发、部分缺货、全部缺货、重复回调和取消后重发等路径。测试分析师随后检查每一条预期是否能回指规则编号不能回指的内容不进入测试库。这样 LLM 的自然语言归纳能力被用于补充组合场景而业务规则仍由项目工件控制。第二种实现方式是结合接口定义和代码变更辅助路径分析。每次迭代将变更接口的 OpenAPI 描述、字段校验规则、调用链摘要和已确认的缺陷类型输入受限知识库由 LLM 输出可能受影响的正向、异常和边界路径并给出需要的模拟依赖。对于金额计算类接口模型只提出候选断言如“退款金额不得超过已支付金额”“拆单后子单金额之和应与原单一致”具体公式由测试人员依据财务规则确认。确认后的断言被转换为自动化脚本在隔离环境中调用模拟服务执行。这样既利用模型阅读多份材料的速度也避免让它擅自决定业务正确性。第三种实现方式是辅助测试数据构造和缺陷分析。项目按等价类、边界值和状态转换规则先定义数据模板 LLM 根据模板生成脱敏的组合数据如不同库存、优惠券、配送状态下的订单集合生成数据通过格式、范围和关联完整性校验后才写入测试库。回归失败时我将日志摘要、接口请求响应和关联规则编号交给模型让其归纳可能原因和影响范围但不允许其直接关闭缺陷。测试人员据此复现问题开发人员确认根因最后由我更新缺陷单、回归用例及需求追踪矩阵。这种做法的优势首先是提高了测试分析的完整性。过去人工容易按主流程设计用例 LLM 在规则约束下可快速枚举状态组合提醒测试人员检查取消、重试、重复消息等非主路径。其次它缩短了接口变更后的初步影响分析时间使测试人员把精力放在规则确认和高风险场景上。再次统一的输出模板让用例、数据和断言之间保留规则编号便于验收时追溯“某项需求是否已验证”。这些收益来自已有工件和人工判断不应归因于模型自动保证质量。项目中也暴露出生成内容质量不稳定、幻觉和数据安全问题。一次模型依据旧版说明生成了“退款后库存立即回补”的断言而当前规则规定待仓储确认后再回补。测试人员发现断言与规则版本不一致后我先分析影响若直接执行可能把正确的异步流程误报为缺陷。随后将旧资料从检索库下线要求提示词必须引用有效规则编号并由业务代表确认库存状态图开发负责人负责更新接口契约测试人员重新执行相关回归。我复验通过后将版本号写入用例和缺陷记录并同步更新追踪矩阵。对敏感数据则采用脱敏、最小权限、隔离测试环境和输入审计禁止把生产订单明细输入外部模型。LLM 还有不能仅靠提示词消除的局限。它难以自行理解未文档化的隐性业务目标不能对罕见异常的真实影响承担责任也可能受训练知识和上下文长度限制而遗漏跨系统约束。因此项目不能把它作为需求确认者或上线放行者。我的解决办法是持续由业务负责人确认规则、由测试负责人批准高风险用例并保留人工探索性测试对跨系统链路采用契约测试、端到端演练和监控告警进行独立验证。对于模型回答不确定或无法引用可信来源的情况系统将其标为待分析项而不是生成结论。综上 LLM 在软件测试中的价值在于把需求、代码和历史缺陷中的信息转化为可审查的候选测试资产。只有将其置于规则基线、人工评审、自动执行和追踪闭环之中才能同时获得效率与可靠性并把模型的能力边界控制在项目可承担的范围内。