传统软件里，输入确定，输出就确定，测试用例的设计有清晰的代码路径可循。LLM 应用打破了这个前提。同一段提示词，换个说法、调一下 temperature，返回结果可能完全不同。测试人员面对的是一个概率系统，而不是确定性逻辑。
这不是说 LLM 应用没法测，而是测试策略需要重新设计。
为什么 LLM 应用比传统软件难测
三个核心原因。
输入输出都是自然语言，本身不具备结构化特征，用户怎么描述需求非常随意，边界模糊。
大模型是黑盒。传统软件可以拆解代码逻辑来设计分支覆盖，LLM 应用没有代码逻辑可以参照，参数权值是从数据里学出来的，无法逐行审查。
输出有随机性。temperature、top_k 这些参数直接干预生成结果的分布，同一个 prompt 跑两次结果可能不一样。
更麻烦的是，LLM 应用的正常输出也未必精准或合适。非结构化、高度依赖用户主观感受的产品，质量怎么度量？这个问题不解决，测试就没法落地。
先分清：模型质量和应用质量是两回事
LLM 模型的质量，关注底层模型本身的性能，通过特定任务评估输出的有效性和合理性。业界常见的做法是跑 benchmark 数据集，看模型卡片上的评估指标。
LLM 应用的质量，是整合了 LLM 之后的整体软件质量。它不只涵盖模型本身，还包括上下游组件、部署环境、接口层、缓存策略等一整套东西。
讨论测试方案时，对象是 LLM 应用，不是模型本身。两者有交集，但不能混为一谈。
通用测试维度仍然适用
LLM 应用作为软件产品，质量界定和传统软件一致。基本的验证执行依然涵盖：
功能测试，确认申明的功能点都实现，实现符合需求界定。
性能测试，满足用户对 token 响应速度的需求，满足资源消耗要求，能长期平稳运行。
安全测试，漏洞扫描、红队攻击等。
这些是底座。但 LLM 应用在功能测试上多了几个传统软件不需要操心的维度。
LLM 功能测试的三个额外关注点
输出一致性。大模型对同一问题的不同表述形式，输出效果要维持一致。用户问“怎么退款”和“我要退钱”，系统不应该给出完全矛盾的答案。
道德与合规。Transformer 在技术上实现了功能，但输出还需要考虑道德问题、偏见问题。不能输出歧视性内容，不能违反法律法规或社会公序良俗。这类测试用例需要专门维护。
幻觉测试。模型会产生幻觉，生成明显不合常理的内容，即便功能逻辑本身正常。幻觉检测是 LLM 应用特有的测试项。
这里有个坑：幻觉测试不能只靠人工抽查。用例集需要覆盖高频问题、边界问题、以及模型容易“编造”的知识盲区。
模型评估：选型和质量基准的依据
各大厂家公布的模型卡片上，可以看到各类数据集下的评估指标。质量工作需要一套标准来度量 LLM 应用的“好”与“坏”，收益有三个：
评估各模型之间、或应用之间的优劣，为选型提供参考。
为模型或应用的改动指出短板，明确改善路径。
便于质量人员明确评估基准，判断是否达到发布准入条件。
测试人员应当根据自己 LLM 应用的用户场景，挑选相关的评估数据集进行跑分测试。不要盲目追求通用榜单的高分，场景匹配度更重要。
功能验证的三层手段
模型评估达标后，集成到 LLM 应用体系里，还需要做功能测试。
传统测试方式依然有效：搭建用户场景的输入输出，确认功能可用，维护测试用例集进行单元测试和回归测试。
LLM 自动化测试解决效率问题。LLM 测试场景比传统软件多出许多，人力成本不可忽视。可以把标杆 LLM 应用的输出作为参考，比如 ChatGPT 或 Llama 的输出，比对自己产品的输出，计算相似度来判断用例是否通过。
A/B 测试补足权威性。自动化测试效率高，但欠缺人工测试的权威性。一款 LLM 产品好不好，终端用户最有发言权。产品设计上可以建立用户反馈机制，部署 A/B 测试来评估质量。
直接反馈：在输出效果界面提供“赞”和“踩”按钮，让用户对结果投票。
间接反馈：页面插桩分析用户行为，推理用户是否认同输出结果。
实测这样更稳：自动化相似度测试适合回归阶段快速筛选，A/B 测试适合发布前的最终验证。两者配合，不要互相替代。
性能测试：token 速率和 GPU 显存
LLM 应用的性能验证，关注指标和传统软件有明显差异。
响应体验上，核心指标是 token 的输出速率，即应用每秒输出多少 token。用户感知的“快慢”直接取决于这个数字，而不是传统的页面加载时间。
资源消耗上，传统软件主要关注 CPU、Memory、IO，LLM 应用需要额外关注 GPU 使用情况、显存消耗。显存溢出会直接导致推理失败，这是生产环境最常见的故障之一。
监控 GPU 显存和 token 速率，建议用以下命令做基础采集：
判定标准：token 速率低于业务容忍阈值，或显存占用持续超过显卡容量的 90%，就需要告警。具体阈值根据模型大小和并发量调整。
安全验证不能省
进行安全风险评估和验证，进行必要的安全扫描。可以参考 OWASP 的 LLM top 10 漏洞解释，覆盖提示注入、不安全输出处理、训练数据投毒等风险项。
LLM 应用的安全面比传统 Web 应用更宽，提示词本身就是攻击入口。安全测试需要专门设计对抗性用例，不能只靠通用漏洞扫描器。
不建议在生产环境直接跑红队攻击脚本，容易触发模型的安全策略导致服务异常。在预发布环境验证更稳妥。
