功能测试这件事很多人以为难点在“会不会写用例”真正做过几个完整迭代的人会告诉你难点从来不在某个单点技巧而在于整条链路的信息有没有断。我见过太多团队用例库写了几千条评审开了一轮又一轮结果上线还是漏测也见过三五人的小团队没什么像样的文档靠一张测试点清单和一套约定俗成的执行顺序把版本质量稳住了。差别不在于谁的用例写得漂亮而在于流程的每个环节有没有明确的输入和输出有没有人真正为“漏掉的东西”负责。这篇就围绕功能测试的完整流程展开从需求拆解、测试点梳理、用例设计、环境与数据准备、执行与回归、缺陷管理一直讲到移动端 App 和智能体类产品这两类特殊对象的流程差异。内容偏向实战适合刚接手测试工作的新人建立整体框架也适合已经做了几年、想把自己那套野路子整理成体系的老手对照参考。1. 功能测试流程的真正价值它是一套防漏机制不是一堆文档1.1 大多数团队卡住的不是技术而是信息断层我观察过一个很典型的现象同一个需求产品经理讲的时候是一个意思开发理解的是另一个意思测试写完用例后再去对一遍发现又是第三个意思。最后上线出问题三方坐下来复盘每个人说的都对因为大家各自理解的“需求”本来就不一样。这种失败跟测试人员的技术能力几乎无关纯粹是信息在传递过程中变形了。功能测试流程存在的意义就是把这种变形挡在中间。它的本质不是让你填一堆表格而是在需求的每一次转手处设置一个校验点需求从产品转到开发时测试参与评审做第一次校验需求从文档转成用例时测试点清单做第二次校验用例从纸面变成执行结果时实际行为与预期结果的对比做第三次校验。每一次校验都会暴露一批理解偏差而这些偏差如果在编码前暴露修复成本几乎是零如果在上线后暴露成本就变成了用户投诉加紧急回滚。所以判断一个流程好不好标准很简单它有没有在这些转手点真正拦住东西。如果一个团队每天都在填测试计划、写测试报告但需求评审时测试全程沉默用例评审时没人提新场景那这套流程就是纯装饰除了消耗时间没有任何作用。1.2 一条完整链路的输入输出物很多人对流程的理解是“步骤”但步骤本身不产生价值产生价值的是每一步的产出物。我习惯用一张表把每个环节的输入和输出列清楚这样任何人都能判断自己这一步有没有做完而不是靠感觉。环节输入必须的产出物常见失效方式需求评审需求文档、原型、接口说明需求疑问清单、测试范围初稿只旁听不提问会上全程沉默测试点梳理需求文档、业务背景测试点清单含异常与边界直接跳到写用例漏掉隐性需求用例设计测试点清单可执行的用例集、优先级标注只覆盖正向主流程用例评审用例集、需求文档评审意见与补充场景逐条念用例没人挑漏环境与数据准备部署包、表结构、造数脚本可用的测试环境、可复现的数据数据被人改乱回归无法复现冒烟测试可测版本准入结论通过/打回没有量化标准靠感觉放行正式执行用例集、环境、数据执行记录、缺陷单只记结果不记证据无法复现回归验证修复版本、缺陷单回归结果、遗留问题清单只验单点不改动不测关联影响上线验证发布说明、验收清单上线验证记录上线后无人跟问题靠用户反馈复盘缺陷数据、执行数据改进项与责任人变成追责会没人说真话这张表我自己用下来最大的价值是它把“测试计划”这种容易写成套话的文档替换成了可检查的清单。计划写得再漂亮不如明确回答一句这次改动的测试范围边界在哪里哪些不测为什么。1.3 流程裁剪的边界哪些环节可以砍哪些绝对不能砍流程必须跟团队规模匹配。三个人的团队照搬大厂那套评审制度只会把所有人拖死。但裁剪是有底线的有些环节砍掉之后问题不会立刻出现而是会在某个版本集中爆发那时再补就来不及了。可以砍的正式的测试计划文档改成口头对齐加一句话范围说明、独立的用例评审会改成开发与测试双边过一遍关键场景、详尽的执行日报改成缺陷单里的记录。不能砍的需求评审时测试必须提问、异常场景必须有人明确负责验证、缺陷必须有可复现的记录、上线前必须有人做过核心流程验证。这四条砍掉任何一条漏测就只是时间问题。我个人的经验是流程的形态可以变但“谁负责发现偏差”这件事必须有人认领。凡是写不进责任人的环节最后都会变成没人做。2. 需求拆解测试点清单比用例更早决定成败2.1 评审会上必须问出口的八个问题需求评审是整条流程里投入产出比最高的环节一小时会议能省掉后面十几小时的返工。但前提是测试真的开口了。我整理过一份自己每次评审都会过一遍的问题清单基本上覆盖了大部分容易翻车的地方。这个功能的入口在哪里用户在什么场景下会用到它有没有更短的路径输入项的取值范围是什么长度、类型、必填与非必填分别怎么定义超出范围时系统怎么反馈是拦截、截断、还是允许但给出提示同一个人重复操作会怎样是不是幂等重复提交有没有防抖或去重有并发吗两个人同时操作同一条数据谁赢怎么保证不出现脏数据依赖哪些上游服务上游挂了或超时界面上要显示什么数据的历史状态怎么处理老数据在新逻辑下会不会出现异常展示出问题了怎么排查有没有日志、有没有可追溯的操作记录这些问题听起来琐碎但每一条都对应着现实中的事故。比如“重复操作会不会产生两笔记录”这个点我在一个订单场景里问过之后开发才发现自己漏了去重逻辑如果等到测试阶段发现就是一个必现的严重缺陷。评审时开口提问本质上是用最低成本把一个潜在缺陷提前消掉。2.2 显性需求之外的三类隐性需求需求文档写出来的永远只是显性部分测试真正的功力体现在能不能补上隐性部分。我把它分成三类每一类都有固定的检查套路。第一类是异常与边界。正常流程谁都会测但输入为空、输入超长、输入特殊字符、网络中断、接口返回错误码、数据库连接失败这些情况文档里通常一个字都不提。我的习惯是任何一个输入框至少要有空值、超长值、特殊字符、纯空格四个用例任何一个依赖外部服务的功能至少要有一次失败注入的验证。第二类是数据一致性。一个操作往往会影响多张表、多个缓存、多个下游。表面上界面显示成功了但另一处数据没同步用户下次进来就会看到诡异的结果。这类问题的检查方法是从结果反推这个操作写入的数据会在哪些地方被读取把读取点列出来逐个验证。第三类是权限与可见性。谁能看到、谁能操作、越权访问会返回什么这三件事必须明确。我一般会把同一份数据用不同角色的账号都跑一遍尤其是“只能看不能改”的边界角色这是最容易漏的地方。2.3 用业务流加数据流双线拆解一个优惠券领取的完整例子光讲方法有点虚拿一个大家都熟悉的功能走一遍会清楚很多。假设需求是“用户可以在活动页面领取一张满减券每人限领一张”。先走业务流这条线。入口是什么是活动页的按钮还是弹窗点击之后有没有登录校验未登录怎么处理领取成功的反馈是什么是弹窗、Toast 还是跳转到券包领取失败有多少种原因活动已结束、库存不足、已达领取上限、账号被限制每种原因的提示文案是否区分领完之后在券包里能不能看到状态是什么什么时候过期。再走数据流这条线。领券这个动作实际写了哪些地方券的实例记录表、用户的领取计数、活动的剩余库存、可能的消息通知。每写一处就要验证一处。库存是预扣还是成功后扣扣减失败会不会导致券已经发出但库存没减用户领取计数是缓存还是数据库缓存失效后会不会出现重复领取。两条线交叉起来一个看起来简单的“领券”功能能拆出三十多个测试点。这就是为什么我一直认为测试点清单是比用例更关键的东西——它决定了你的覆盖边界在哪用例只是把这个边界内的每一条路径具体化。边界画错了用例写得再规范也是白费。我通常会把测试点清单做成一个表字段包括测试点编号、所属模块、测试点描述、来源需求条款或隐性补充、风险等级、是否已设计用例。最后那个字段特别有用它能保证没有测试点在写用例的过程中被悄悄丢掉。3. 用例设计方法的选择逻辑什么场景用哪把刀3.1 七种常用设计方法的适用边界设计方法本身没什么神秘的难的是知道什么时候该用哪把。我见过新人把所有功能都按等价类加边界值硬套结果复杂的业务规则压根测不出来。下面这张表是我自己总结的适用场景。方法最适合的场景不太适合的场景等价类划分输入项有明确的有效与无效区间多条件组合互相影响边界值分析数值范围、长度限制、分页、时间区间逻辑分支复杂的流程判定表多个条件组合决定不同结果的规则条件之间没有耦合的功能因果图条件与结果存在多对多依赖简单的单条件判断场景法端到端业务流程、跨模块操作单个字段的校验状态迁移订单、审批、工单等有明确状态机的对象无状态的一次性操作正交与组合多参数配置、多环境组合需要压缩用例量参数之间强依赖的场景判定表和状态迁移这两个方法在新人手里用得最少但恰恰是最能挖出问题的。比如一个审批流有提交、审核中、已通过、已驳回、已撤回几个状态每个状态下允许的操作不一样。用状态迁移法把状态和操作的矩阵画出来几乎立刻就能发现某些状态下缺少对应的处理逻辑——这种问题靠想是想不出来的。3.2 用例粒度与优先级写得多不等于覆盖全关于粒度业内一直有两种做法。一种是一条用例只验证一个点好处是失败时定位精准坏处是用例数量爆炸维护成本极高。另一种是一条用例走完流程、验证多个点好处是执行快坏处是失败之后要重新拆解是哪一步出问题。我的做法是按优先级区分P0 和 P1 的场景拆细一条用例一个验证点因为这些是最需要快速定位问题的路径P2 和 P3 的场景可以合并用一条用例串起多个次要校验点节省执行时间。这个折中的原则是执行成本高的地方追求精度执行成本低的地方追求效率。优先级划分也要有明确标准不能凭感觉。我按“出问题之后的业务影响”来分导致核心流程走不通、资金或数据出错、影响全部用户的是 P0导致主要功能不可用但可绕过的是 P1影响体验、特定条件下才出现的是 P2文案、样式、极端场景是 P3。这个标准定下来之后冒烟测试和回归测试的取舍就有了依据。3.3 用例评审怎么开才不浪费时间大多数用例评审会之所以低效是因为变成了“作者念、听众听”。作者逐条读用例别人跟着点头一小时过去什么新东西都没发现。真正有效的评审应该反过来——作者不念由参与评审的人去看然后专门找两类东西你没覆盖的场景和你覆盖了但预期结果写错的地方。我通常这么组织提前一天把用例和测试点清单发给开发与产品会上只讨论三件事。第一测试点清单里有没有漏掉的业务场景这个由产品拍板。第二用例里的预期结果跟实现逻辑是否一致这个由开发确认。第三有没有可以合并或删除的冗余用例这个由测试内部决定。还有一个容易被忽略的点评审时要特别关注那些“无法确定预期结果”的用例。这类用例往往意味着需求本身有歧义如果评审时含糊过去了执行阶段一定会卡住最后只能靠猜。与其到那时纠结不如在会上当场问清楚把结论写进需求备注里。4. 测试环境与数据准备流程中最容易被压缩、也最容易翻车的环节4.1 环境分层的实际意义环境分层不是为了显得规范而是为了解决一个具体问题不同阶段需要验证的东西不一样而它们的稳定性要求是互相冲突的。开发环境追求的是随时可改代码可以随时部署数据库可以随便改因为它服务于“快速验证一个想法”。测试环境追求的是相对稳定这个版本的代码和数据结构要能支撑一轮完整执行中途不能被人改掉。预发布环境追求的是与生产尽量一致配置、数据量、依赖服务都要贴近真实用来做上线前的最后验证。生产环境则是不可乱动的只做发布和验证。我遇到最多的问题是测试环境被开发随手改了配置或者清了数据导致回归测试无法复现缺陷。解决办法很笨但有效所有对测试环境的变更走一个简单的登记哪怕只是在群里说一句“我要重启服务五分钟后好”。听起来原始但比事后花两小时排查“为什么昨天还复现的问题今天不复现了”要划算得多。4.2 四类测试数据与三种造数路径测试数据这件事很多人只想到“造一份能跑通的数据”但实际需要的是四类不同的数据。静态基础数据是字典、配置、地区、分类这类相对固定的数据通常一次准备好可以反复用。动态业务数据是每次执行都要新建的比如一笔新订单、一个新用户这类数据的核心要求是唯一且有规律方便识别和清理。脏数据是为了验证异常处理能力比如字段为空的记录、状态异常的记录、超出合理范围的数值。边界数据则是刚好卡在限制值上的数据比如余额刚好等于下单金额、名称刚好等于最大长度。造数路径有三种各有取舍。数据库直接插入最快但绕过了业务逻辑容易造出实际不可能存在的数据组合导致测试结果失真。接口调用造数最贴近真实数据形态可靠但依赖接口可用速度慢。界面操作造数最真实但最慢一般只用于验证关键流程。造数方式速度数据真实性适用场景数据库插入最快低可能造出非法组合批量基础数据、压力场景接口调用中等高日常回归、需要业务逻辑处理的数据界面操作最慢最高核心流程验证、端到端场景我的常规做法是优先用接口造数把常用的造数动作写成一个脚本或者一组接口集合需要的时候一键执行。# 用接口批量造测试用户的简化示例 import requests BASE https://test-api.internal.example.com def create_user(index): payload { phone: f1390000{index:04d}, nickname: fautotest_{index}, source: auto_test # 打标记方便后续批量清理 } resp requests.post(f{BASE}/user/create, jsonpayload, timeout5) resp.raise_for_status() return resp.json()[userId] if __name__ __main__: ids [create_user(i) for i in range(1, 51)] print(fcreated {len(ids)} users)这里有个细节值得强调造出来的数据一定要带标记比如昵称前缀、来源字段。后面要清理的时候一句按标记筛选就能全部处理掉不用手工一个个找。这个习惯我坚持了很多年省下的时间难以计算。4.3 数据自清理与污染隔离测试数据污染是回归失败的头号原因。典型表现是昨天这个用例还是通过的今天执行就失败了查半天发现是昨天另一条用例把这条用例依赖的数据改掉了。解决思路有两个方向。一个是隔离让每条用例或每组用例使用独立的数据互不干扰。最简单的实现方式是给每条用例分配独立的账号或者独立的业务对象用例内部自己创建自己使用。另一个是自清理用例执行完之后把自己造的数据删掉或者置为不可用状态。两个方向结合起来效果最好。另外还有一个容易被忽视的点测试数据要有“可识别性”。我见过团队在测试环境里混着大量来路不明的历史数据排查问题时完全分不清哪些是本次造的、哪些是遗留的。加一个统一的来源标记字段哪怕只是备注里加个前缀排查效率都会提升一个档次。5. 执行与回归冒烟准入、三轮执行、回归集裁剪5.1 冒烟测试的准入标准要可量化冒烟测试的目的是用最小成本判断“这个版本值不值得投入正式测试”。如果没有量化标准这件事就会变成靠感觉——开发觉得能测了测试打开一看首页都打不开白浪费半小时。我的标准通常是这样定义的核心流程的 P0 用例必须全部通过不允许有任何一条失败P1 用例通过率不低于百分之九十服务启动无报错关键接口返回正常。三个条件同时满足才准入进入正式测试否则直接打回。这套标准的关键在于“P0 不允许失败”因为 P0 覆盖的是主流程主流程都不通的版本后面的测试基本没有意义。执行冒烟测试的人最好是测试而不是开发。原因很简单开发对自己的代码有心理预期容易不自觉地绕开问题路径测试是带着怀疑来的更容易发现“看起来能跑但实际有问题”的情况。5.2 三轮执行法的划分依据一轮执行就想把所有问题都测出来基本不可能。我一般分三轮每轮有不同的侧重点。第一轮聚焦新功能本身。这一轮只测本次需求涉及的范围把每个新功能的正常路径和主要异常路径走一遍。目的是尽快暴露阻塞性问题让开发有充足时间修复。这一轮不要急着测关联影响因为新功能如果还在反复改关联部分的测试结果也不稳定。第二轮做关联影响回归。新功能本身稳定之后开始测它影响到哪些原有功能。判断影响范围的方法有三条看代码改动涉及哪些模块看数据表改动影响哪些读取方看历史上的缺陷热点在哪些模块。三条线索的交集基本就是这轮要重点覆盖的范围。第三轮做全量回归与交叉验证。这一轮把回归用例集完整跑一遍同时安排不同的人交叉执行对方的模块。交叉的意义在于打破思维定式——同一个人测自己的模块容易沿着自己习惯的路径走别人来测往往会发现被忽略的入口。5.3 回归用例集怎么裁剪全量回归听起来很安全但如果用例集有几千条每轮都全跑时间上根本不现实。所以必须有裁剪策略。我的裁剪原则是按风险加权。改动直接影响的功能全量回归与改动共享数据或接口的功能重点回归完全不相干的模块只跑 P0 冒烟用例。另外还要叠加两个维度历史缺陷密集的模块提高权重因为那里本来就容易出问题近期频繁改动的模块提高权重因为变更越多引入问题的概率越大。要提醒一点回归用例集是需要维护的。如果只是不断往里加用例从来不删几年下来它会变得臃肿且互相重复。我一般每个迭代结束时会花半小时做一次清理把已经验证过很多次、又没出过问题的低风险用例合并或者降级把新出现的风险点加进去。5.4 探索式测试的时间盒与章程按用例执行有一个天然的局限它只能验证你已经想到的东西。探索式测试的价值就是补上这块——通过自由探索去发现用例没覆盖到的问题。做法上我推荐时间盒加章程的方式。时间盒是限定一段时间比如九十分钟期间专注探索一个目标区域不做其他事。章程是一句简短的探索方向比如“探索购物车在商品下架后的行为”“探索支付流程中返回上一步的各种路径”。章程的作用是让探索有边界避免变成漫无目的地乱点。探索过程中最重要的动作是记录。发现了什么、怎么发现的、当时的操作路径是什么都要即时写下。因为探索式测试的路径往往不可重复如果当时不记事后很难复现给开发看。我自己习惯用简单的记录格式时间点、操作、观察到的现象、怀疑的原因。积累几次之后这份记录本身就是很好的回归素材。6. 缺陷全生命周期管理从提单到关闭的每一步6.1 一份能让开发立刻动手的缺陷报告长什么样缺陷报告的质量直接决定了沟通成本。写得好的报告开发看一眼就能动手写得差的报告来回问几轮还没搞清楚问题在哪。标题是关键。好的标题包含“条件加现象”比如“购物车中有下架商品时点击结算按钮无响应”一眼就能看出是什么场景下的什么问题。差的标题是“结算有问题”“购物车崩溃了”开发看完还得来问一遍。正文部分我坚持要有这几个要素。环境信息包括测试环境地址、账号、应用版本、浏览器或机型。前置条件也就是复现之前需要做好哪些准备比如账号状态、数据状态。复现步骤一步一动能写几步就写几步不要合并。预期结果和实际结果分开写这是最容易被省略但最重要的部分因为“错在哪”本质上就是这两者的差异。证据包括截图、录屏、接口返回、日志片段、请求 ID。复现率必现、大概率还是偶现偶现的要写清楚尝试了多少次成功多少次。标题购物车中存在已下架商品时点击「去结算」按钮无任何响应 环境测试环境 v2.7.3 / 账号 auto_test_003 / 移动端 Android 13 前置条件购物车中有至少一件商品且该商品在商品详情页已被下架 复现步骤 1. 打开购物车页面 2. 确认页面中显示「商品已下架」的标签 3. 点击页面右下角「去结算」按钮 预期结果弹出提示说明该商品已下架并提供「移除并继续」的选项 实际结果按钮点击后无任何反应控制台无报错接口未发起请求 证据screen_record_1031.mp4、network_log.har 复现率必现连续尝试 5 次5 次均复现这份报告的价值在于开发不需要任何额外沟通就能定位到前端按钮的事件绑定逻辑。写报告多花五分钟省掉的是双方来回两小时的沟通。6.2 缺陷分级与响应时效分级标准如果不明确就会出现测试把所有缺陷都标成紧急、开发把所有缺陷都标成低优先级的情况。我的做法是把级别和业务影响绑定并约定响应时效。级别判定标准响应时效处理方式严重核心流程不可用、数据错误、影响全部用户立即停止测试优先修复当轮必须解决高主要功能不可用但存在绕过方式当天当轮修复修复后立即回归中次要功能异常、特定条件下出现两个工作日内可安排到下个迭代低文案、样式、极端场景问题按排期可积累批次处理这套标准要提前跟开发和产品对齐不能等出了问题再争。另外还要设一个兜底规则如果对级别有分歧以业务影响为准由产品最终裁定。这样能避免无休止的争论。6.3 三类典型扯皮场景的处理方式第一种是“在我这没问题”。这种情况九成以上是环境差异或者数据差异导致的。处理方式不是争论而是交换环境信息把你的环境地址、版本号、账号、操作数据发给对方请对方用同样的条件试一次。如果对方用你的环境还是复现不了那就一起看通常问题就出在版本不一致上。第二种是“这不是缺陷是需求这样设计的”。这种情况的关键是把判断权交回给需求方。不要跟开发争直接在产品、开发、测试三方都在的场合把现象描述清楚问一句“这个行为符合当初的设计预期吗”。如果产品说符合那就在需求文档里补上这条说明避免下次再被当成缺陷提出来如果产品说不符合那它就是一个明确的缺陷。第三种是“偶现问题先关掉吧”。偶现问题最容易被草率关闭但它往往指向并发、时序、缓存这类深层次问题上线后可能变成难查的偶发故障。我的处理原则是偶现缺陷不能直接关闭要么定位到根因后修复要么在缺陷单里写清楚当前的判断、已排除的可能、以及继续观察的触发条件并降级为观察项定期回顾。把结论写下来这件事很重要它保证了几个月后有人重新遇到同样问题时能接上之前的排查进度。7. App 功能测试的重点差异碎片化、中断与弱网7.1 设备与系统覆盖的取舍移动端测试最现实的问题是设备太多不可能全测。所以覆盖策略必须建立在数据上而不是凭感觉。基本做法是看用户设备的分布情况把占比最高的几个机型和系统版本作为必测范围长尾机型做抽样。除了机型还有几个维度要考虑。屏幕尺寸和分辨率影响布局尤其是长文本、按钮位置、弹窗适配。系统版本影响权限申请方式、通知行为、后台限制策略。厂商定制系统影响后台进程存活、推送到达率、权限弹窗样式。这些差异在真实用户那里都会变成问题但在模拟器上往往看不出来所以关键流程一定要在真机上跑。我一般的配置是主力机型两到三台覆盖主流系统版本一台低端机型验证性能与内存紧张时的表现一台大屏设备验证布局适配。这个组合能覆盖大部分现实场景成本也可控。7.2 中断、弱网与网络切换测试中断测试是移动端最容易漏、也最容易出严重问题的一块。用户在操作过程中随时可能被来电、通知、闹钟、锁屏、切后台打断应用必须能正确处理这些打断。具体要验证的场景包括填写表单过程中来电通话结束后返回应用已填内容是否还在支付过程中切到后台再切回来订单状态是否一致上传文件过程中锁屏解锁后上传是否继续或正确失败从通知栏点击进入应用是否能正确跳转到对应页面。这些场景的共性是应用的状态需要在被打断后恢复而恢复逻辑往往是最容易写错的部分。弱网测试的核心是验证应用在网络质量差时的表现。要覆盖的场景包括高延迟下的加载状态是否正常显示有没有超时提示网络中断时是否有明确的错误提示而不是一直转圈网络恢复后是否能自动重试或者引导用户重试弱网下重复提交会不会产生重复数据。这里有个实用技巧用系统自带的网络限速工具就能模拟大部分弱网场景不需要额外设备。网络切换测试主要是 Wi-Fi 与移动数据之间的切换。要验证的是切换过程中正在进行的数据请求会不会失败失败后有没有合理的处理用户重新操作后数据是否一致。7.3 安装升级卸载与权限链路这三个动作看起来简单实际藏着不少问题。安装测试要覆盖全新安装、覆盖安装、低版本升到高版本、跨多个版本升级这几种情况重点看升级后本地缓存的数据结构变化会不会导致崩溃或者数据错乱。很多团队只测全新安装结果用户升级后大量崩溃这是很典型的漏测。卸载测试要看卸载后残留的数据是否清理干净重新安装后是否会出现异常状态。有些应用把关键信息存在本地卸载时没清重装后读取到旧数据就会出现莫名其妙的错误。权限测试要覆盖首次申请、拒绝后再次触发、永久拒绝后引导去设置页、权限被中途收回这几种情况。特别要注意的是永久拒绝这个分支也就是用户选择了“不再询问”此时应用必须给出明确的引导而不是反复弹窗或者直接崩溃。这个分支很多实现都会漏掉。8. 智能体类产品的功能测试当输出不再确定8.1 断言方式的重构从相等判断到约束判断传统功能测试的核心是“实际结果等于预期结果”但智能体类产品的输出天然带有不确定性。同一个问题问两次措辞可能不同顺序可能不同甚至内容侧重也不同。如果还沿用相等判断测试会一直失败但实际功能是正常的。这时候断言方式必须重构从判断“相等”变成判断“满足约束”。常见的约束类型有几种。格式约束比如要求输出必须是合法的 JSON、必须包含指定字段、字段类型正确。关键信息约束比如回答里必须包含订单号、必须包含退款金额、必须提到某个时间点。边界约束比如不能提及超出知识范围的内容、不能输出违反规则的表述、不能调用未授权的工具。长度与结构约束比如回复长度在合理区间内、必须分点列出。把这四类约束组合起来就能在不依赖具体措辞的前提下判断输出是否合格。我通常会把每个测试用例的预期结果写成一组约束条件用例通过的标准是所有约束都满足。8.2 评测集、打分器与批量统计智能体产品的回归测试靠单次对话判断是没有意义的。正确的做法是构建评测集然后批量执行统计结果。评测集的构成上有几个要点。规模上核心场景至少要有几十条覆盖主要意图和主要分支。分布上正常场景占大部分边界与对抗场景占一部分专门用来验证安全性。标注上每条要有明确的判定标准不能是“看着还行”。执行完之后要统计几个指标约束满足率、关键信息命中率、格式合法率、拒绝率对不该回答的内容是否正确拒答。这些指标按版本对比才能看出改动带来的影响。比如某次优化之后所有场景的响应都变快了但格式合法率从百分之九十八掉到了百分之八十五这就说明改动引入了新的问题。打分方式上能用规则判定的就用规则判定因为规则判定稳定、可复现、成本低。规则判定覆盖不了的才用人工抽检。人工抽检要制定明确的评分标准并且要有交叉复核避免个人偏好影响结论。用模型来打分的话必须先用一批人工标注过的样本校准确认它的判断跟人工一致否则打出来的分数没有参考价值。8.3 多轮上下文、工具调用与越权边界多轮对话是智能体类产品最容易出问题的地方。要验证的场景包括上下文是否正确保留第三轮还能不能记住第一轮提到的信息用户中途改变意图系统能否正确切换用户提供纠正信息后之前的错误理解有没有被覆盖超长对话之后早期信息会不会丢失或被错误引用。这些都是靠单轮测试发现不了的。工具调用是另一个重点。要验证的是该调用工具的场景是否真的调用了调用的参数是否正确参数中的关键字段有没有被正确填充工具返回错误时系统是否能给出合理的应对而不是把原始错误信息直接抛给用户工具调用失败后是否会重试重试是否有次数限制。越权边界是安全相关的底线。要验证的是用户请求访问不属于自己的数据时系统是否拒绝用户通过构造话术诱导系统执行超出权限的操作时系统是否守住边界系统是否会因为上下文中的信息而误以为用户拥有某种权限。这几类场景要专门构造用例并且每次版本更新都要回归因为这类问题一旦出现影响面往往很大。9. 让流程落地的度量与裁剪9.1 六个能反映真实质量的度量指标流程本身好不好需要用数据说话。我日常关注六个指标它们能比较全面地反映测试工作的实际效果。需求覆盖率也就是测试点清单覆盖了多少条需求条款。这个指标低于百分之百就说明有需求没人测。用例执行率反映计划执行的情况但如果这个指标长期保持百分之百反而要警惕可能是用例集太保守没人做探索。缺陷密度也就是每个模块的缺陷数量。这个指标不用于考核只用于识别风险密度高的模块说明实现质量不稳定下一轮要加大测试投入。缺陷逃逸率也就是上线后才发现的缺陷占全部缺陷的比例这是最直接反映测试有效性的指标。回归通过率反映版本稳定性。平均修复时长反映协作效率。用这些指标的时候有个重要前提它们只能用来改进流程不能用来考核个人。一旦跟考核挂钩数据立刻就失真了执行率可以补录缺陷可以私下协商不提交指标好看了但质量反而更差。9.2 不同规模团队的流程裁剪方案流程的具体形态必须跟团队规模匹配。我按规模大致分三档。五人以下的测试团队重点是省略一切形式化的文档。需求对齐靠口头加一句话的范围说明用例写在一张共享表格里评审就是开发和测试双边过一遍关键场景回归靠一张手工维护的 P0 清单。这套办法的核心是人少的时候沟通成本低把时间花在执行上更划算。五到二十人需要开始有分工和规范。这个阶段要建立统一的用例库和缺陷单规范要有明确的优先级标准和准入标准要有人负责回归用例集的维护。同时要开始做自动化把稳定的 P0 用例沉淀成自动化脚本因为手工回归在这个规模下已经开始成为瓶颈。二十人以上需要考虑的是拆分和并行。按业务模块拆分成小组每个小组独立负责自己的测试范围建立公共的测试基础设施包括环境管理、数据工厂、自动化框架建立统一的度量体系和质量复盘机制。这个阶段最大的风险是流程过于复杂导致执行不下去所以要定期检查哪些环节已经流于形式该砍就砍。9.3 复盘会只谈事实和数据复盘会是流程闭环的最后一环但很多团队把它开成了追责会结果就是所有人都开始隐藏问题复盘失去意义。我的原则是只谈事实和数据不谈人。具体做法是提前把执行数据、缺陷数据整理好会上只讨论三个问题哪些问题本该更早发现却没有发现当时的流程在哪一步失效了下一步怎么调整。所有的讨论都围绕流程环节而不是围绕“谁没做好”。举几个复盘出来的真实改进项某次漏测是因为需求评审时测试没参与改进项是规定评审必须有测试到场某次上线问题是因为回归用例集里缺少一个关联模块改进项是把该模块加入回归清单某次偶现问题拖了很久才定位改进项是要求偶现缺陷必须记录排查线索而不能直接关闭。这些改进项都很具体能落地也有明确的责任人比一句“下次注意”有用得多。流程就是这样一点点磨出来的。没有哪套流程一开始就完美都是在一次次复盘里发现问题、补上漏洞、删掉冗余慢慢长成适合自己团队的样子。别人的模板可以借鉴但最终一定要按自己的业务特点、团队规模、风险承受能力去调。照搬的流程跑不动自己磨出来的流程才真正扛得住版本压力。