做过几年测试的人大概都经历过这种落差感面试时把功能测试讲得头头是道真进了项目被开发怼回来一句“这根本不是bug”、被产品追问“这个场景你怎么没覆盖”才发现测试流程这四个字里全是没写在文档上的细节。功能测试看起来门槛最低点页面、点按钮、看有没有报错谁都能上手可真要把一个版本稳稳当当送上线靠的不是手感是一套能复用的流程以及流程里每个环节的判断力。这篇东西我按自己的实际经验拆一遍从需求到上线从用例设计到缺陷回归中间穿插移动端和接口场景的差异也聊聊自动化介入的时机。适合刚转行做测试的朋友建立整体认知也适合做了两三年、想把自己的流程梳理得更顺的人对照着查漏补缺。1. 功能测试流程的整体设计与阶段拆解1.1 流程真正解决的问题是漏和乱很多人把测试流程理解成一堆要填的表格测试计划、测试用例、测试报告、缺陷记录。填完交差流程就算走完了。我一开始也这么想后来发现这种理解直接把流程的价值做没了。流程要解决的是两个具体问题一个是漏一个是乱。漏指的是同一个版本里有人测了登录没测注册有人测了支付成功没测支付失败最后上线出问题一复盘发现不是没人会测是没人明确说这块归谁。乱指的是开发提测时间、环境地址、数据准备、缺陷标准全靠群里喊喊完就淹没在消息里第二天没人记得住。流程的本质是把这些口头承诺变成书面共识让每个人知道自己在哪个时间点该交什么东西。我见过一个团队十几个人测试文档几乎为零全靠每天早会同步。前半年跑得挺欢业务变化快、沟通成本低等到版本并行到三个以上缺陷开始互相污染A版本的修复影响了B版本的功能一个简单的回归要测一整天。后来他们补流程补的不是文档数量是版本边界和环境隔离这两件事效率立刻回来了。所以流程设计的第一原则不是全面是匹配当前团队规模小团队别硬套大厂那套五级评审大团队也别指望微信群同步能撑住。另一个容易被忽略的点是流程的收口位置。测试流程不能到测试报告发出就结束真正的收口是上线后的验证和线上问题的回溯。我坚持每个版本上线后48小时内做一次小范围的线上冒烟重点看核心链路和这次改动涉及的功能很多时候回归环境测得好好的线上因为配置差异、数据量差异、缓存问题冒出来一堆事这些只有上线后才发现。1.2 六阶段主干流程与每个阶段的实际交付物抛开各种方法论功能测试的主干流程其实就是六个阶段每个阶段的交付物不用多但要实打实有用。下面这张表是我自己常用的版本列出来的交付物都是能直接拿给别人看的不是写完就锁进文件夹的那种。阶段核心动作关键交付物常见卡点需求分析拆解需求、识别可测点、提澄清问题需求疑问清单、可测点拆解需求模糊、口头约定测试计划定范围、排期、资源、风险测试计划说明、排期表提测时间反复变用例设计用方法推导用例、评审、分级用例集、优先级标记用例写太粗或太细测试执行冒烟、系统测试、记录缺陷执行记录、缺陷单环境不稳定、数据难造回归验证按影响面选回归范围、验证修复回归用例集、验证结论全量回归耗时太长上线与复盘线上冒烟、问题回溯、流程改进上线验证记录、复盘结论上线后无人跟进这张表里我认为最被低估的是需求分析和上线复盘这两头。中间四个阶段大家都有意识做两头最容易糊弄。需求分析糊弄的直接后果是用例设计阶段才发现有一堆业务规则没搞清楚只能边写边问进度全乱上线复盘糊弄的后果是同一个类型的线上问题反复出现团队始终在原地打转。举个真实例子。之前做一个订单退款的功能需求文档只写了用户可申请退款审核通过后原路退回看起来很简单。需求分析阶段我列了几个问题部分退款允不允许退款申请有没有时间限制优惠券抵扣的部分退不退现金审核拒绝后用户能不能再次申请这几个问题产品当时也没想全尤其是优惠券部分最后确认下来是退券不退现金如果没在需求阶段抠出来用例肯定写漏上线后必然被用户投诉。这就是需求分析阶段最值钱的地方把模糊写成明确把隐含写成条文。2. 需求分析与测试用例设计流程里最容易被压缩的环节2.1 需求评审要抠出来的四类信息需求评审会上产品讲一遍开发问几个技术问题测试坐在下面点头会议半小时结束。这是很多团队的标准流程也是隐患埋得最深的地方。测试在需求评审里不是来听故事的是来找漏洞的我通常盯四类信息。第一类是业务规则的边界。上面退款那个例子就是典型规则里没说清楚的边界一定要当场问。金额的最小值、最大值、是否允许零、是否允许负数时间窗口的起止状态流转的完整路径这些都是边界。第二类是异常分支的处理方式。正常流程谁都会讲异常流程往往是评审时缺失的比如网络超时怎么办、第三方回调失败了怎么办、并发提交同一笔请求怎么办。第三类是数据来源和依赖。这个功能依赖哪些上游数据、依赖哪个服务、服务挂了是什么表现决定了测试时要不要做挡板、要不要造特殊数据。第四类是验收标准。什么叫做测完了双方要有共识。我习惯在评审会上直接问产品这个版本你验收的时候会点哪几个场景他说的那几个场景我记下来作为冒烟测试的最小集合同时也作为测试报告里重点说明的部分。这样做的好处是上线后出了问题责任边界清楚不会出现我以为你要测的扯皮。提示需求评审前一定要自己先过一遍原型和文档把疑问按必须澄清可以后置分类。评审会上按优先级问不要去纠结那些不影响测试设计的细节否则会拖长会议、消耗别人的耐心。2.2 用例设计方法的选择逻辑与实操取舍用例设计方法网上一搜一大堆等价类、边界值、判定表、因果图、场景法、错误推测法、正交实验法。新手最容易犯的错是把这些方法当清单每个功能都套一遍结果用例写得又长又没重点。我的用法是按功能类型选方法不是按方法找功能。输入类功能比如表单填写、搜索框、金额输入优先用等价类划分加边界值分析。有效等价类和无效等价类各挑代表值边界值取上点、离点、内点。举个例子一个用户名输入框要求6到18位字母数字组合我会取这几个值5位、6位、18位、19位、纯字母、纯数字、字母数字混合、含特殊符号、含空格、纯中文、空值。这十一个用例基本能把校验逻辑摸清楚比按照等价类一条条推导快得多。状态流转类功能比如订单状态、审批流程优先用场景法加状态迁移。订单从待支付到已支付到已发货到已完成还有待支付到已取消、已支付到退款中这些支线每一条路径都要至少一条用例。状态类功能最怕的就是漏支线主流程谁都会测异常流转才是bug重灾区。多条件组合类功能比如优惠券叠加规则、权限组合条件数少用判定表条件多了用正交实验或者干脆拆成单条件加两两组合。我见过有人对着一个四条件的优惠券功能硬写判定表16条规则写出来一大半在执行时根本跑不到纯属浪费。错误推测法是经验活靠的是踩过坑的记忆。比如涉及到浮点数的金额计算我会条件反射去试0.1加0.2涉及到分页的会去试最后一页删除数据涉及到并发的会去试两个人同时点提交。这些用例写不出方法论但抓bug效率极高前提是你得刻意积累。功能类型首选方法典型用例数量备注表单输入等价类边界值8至15条重点在非法输入状态流转场景法状态迁移每条路径1条支线不能漏多条件组合判定表/正交8至20条条件多于4个考虑降维经验易错点错误推测法按经验需长期积累2.3 用例评审和优先级分级怎么做才不流于形式用例写完不评审等于没写。但评审也有讲究把几百条用例从头念一遍参会的人十分钟就开始走神。我的做法是只评审三类用例核心业务流程的用例、这次改动新增的用例、历史上出过问题的模块用例。其他常规用例自己过一遍就行不用占用大家时间。评审的时候不念用例念场景和预期。比如我测的是用户下单后取消订单预期是库存回滚、优惠券返还、订单状态变为已取消这个理解对不对让开发确认技术实现上是否一致让产品确认业务预期是否正确。这样做效率高而且能当场发现理解和实现之间的偏差。用例分级我一般分三级P0是核心链路和冒烟用例必须每次执行P1是重要功能的正向用例版本测试时执行P2是异常分支和边界用例时间充裕时执行。分级不是为了偷懒是为了在时间被压缩的时候有取舍依据。项目延期是常态真到了最后一天只能测半天有分级你至少知道该保住哪些。注意分级不是给用例贴标签就完了每次版本上线前要重新审视P0集合。有些旧功能已经下线了P0里还挂着执行时浪费时间有些新功能很关键忘了提到P0回归时漏掉。这个动作我一般放在提测前一天做改动一次也就十分钟。3. 测试执行与缺陷全生命周期管理3.1 冒烟、系统测试、回归的执行节奏提测之后不要上来就全量跑先做冒烟测试。冒烟的范围就是核心链路目标是确认这个版本到底能不能测。我通常挑十到二十条最关键的用例半小时到一小时内跑完重点看登录、核心业务主流程、本次改动涉及的功能。冒烟不通过直接打回开发不要硬着头皮往下测否则后面测出来的问题全是白费功夫因为地基都不稳。冒烟通过之后进入系统测试这时候按用例集完整执行先测本次新增和改动的部分再测关联的旧功能。为什么先测新的因为新功能的问题最集中而且发现问题越早留给开发的修复时间越充裕。旧功能的回归可以放在后面但如果时间紧优先保证改动影响范围内的旧功能。执行过程中有个习惯我一直在坚持边执行边记录环境、数据、操作步骤尤其是发现可疑现象但还没确定是不是bug的时候。很多时候一个偶现的问题你当时不记清楚数据和环境回头想复现根本复现不出来只能眼睁睁看着它上线。记录不用多正式一句话加截图就够比如用户A在测试环境订单号尾号1234点了三次退款第二次报500。回归测试是最后一个环节也是最考验判断力的。全量回归当然最保险但时间成本太高一个几百条用例的系统全跑一遍可能两天。我的做法是基于影响面分析做定向回归这次改了哪个模块、改了哪几个文件、调用了哪些公共方法涉及到谁就回归谁。开发提交代码时我会让他顺便说一句改动了哪些文件这句话比什么工具分析都管用。3.2 缺陷单怎么写才不会被开发打回缺陷单被开发打回无法复现不是bug设计如此是测试最消耗情绪的事。我统计过自己早期被打回的缺陷单百分之八十的问题出在信息不完整和预期不明确上。一条合格的缺陷单至少要包含这几样东西环境信息、前置条件、操作步骤、实际结果、预期结果、复现概率、必要截图或日志。环境信息要具体到版本号、环境地址、浏览器或设备型号前置条件要写清楚账号状态、数据状态比如用户已实名但未绑定手机号操作步骤要能按着一步步走通不要写操作如下然后只有一句点退款。预期结果这一栏是最容易偷懒的很多人写应该正常退款这等于没写。正确的写法是引用需求文档的具体条款或者写清楚具体的数值和状态比如退款金额应为订单实付金额减优惠券抵扣部分即99元订单状态变为退款中优惠券状态变为已退回。写清楚这一条开发基本没法反驳因为他要么承认实现错了要么去找产品改需求无论哪种问题都往前推进了。遇到设计如此的回复不要直接接受也不要情绪化对抗去翻需求文档或者找产品确认。如果确实是设计如此而你觉得不合理把它记下来作为改进建议单独提不要混在缺陷里纠缠。这样既保住了缺陷单的严肃性也把有价值的意见传递出去了。缺陷单要素写法示例反面示例环境测试环境v2.3.1安卓14测试环境前置条件用户已登录购物车有2件商品无操作步骤进入结算页选择优惠券点提交下单实际结果提示系统繁忙订单未生成报错了预期结果订单生成金额扣减10元应该成功复现概率3次中出现2次偶尔3.3 回归策略和影响面分析的实操方法回归范围定得太大浪费时间定得太小漏bug平衡点就在影响面分析上。我一般从三个维度判断代码改动范围、功能依赖关系、历史问题分布。代码改动范围最好拿问开发要或者看提交记录。功能依赖关系需要平时积累比如支付模块依赖订单模块和账户模块改了支付就得回归订单和账户的相关功能。历史问题分布是经验数据哪个模块以前bug多这次就多测点。这三个维度交叉一下回归范围基本就定了。还有一个技巧是保留常驻回归集。把每个版本都会影响到的核心用例固定下来比如登录、下单、支付、退款这四条主链路每次版本必跑其他用例按影响面筛选。常驻回归集不要太大控制在五十条以内一上午能跑完这样即使版本再紧也能保住底线。4. 移动端与接口场景下的功能测试重点4.1 App功能测试和Web差在哪App的功能测试和Web看着像实际差异很大很多从Web转过来的人一开始会不适应。Web上你能随时清缓存、随时刷新、随时开控制台看请求App上这些操作成本高得多而且多了几个Web没有的变量。权限和系统交互是第一个坎。定位、相机、相册、通知、通讯录这些权限用户允许和拒绝是两种完全不同的路径测试时两条都要走。还有来电打断、切到后台再回来、锁屏解锁、低电量模式这些都是Web遇不到的。我见过一个App在权限被拒绝后直接白屏因为开发只处理了允许的分支这种问题在Web上根本不会出现。设备和系统版本碎片化是第二个坎。安卓阵营的机型、分辨率、系统版本、厂商定制系统的差异比Web浏览器的差异大得多。不可能每台都测我一般按用户占比选三到五台主力机型再补一台低端机和一台最新系统的机器。低端机重点看性能和内存最新系统重点看兼容性和权限弹窗的样式差异。网络环境是第三个坎。弱网、断网、网络切换是App测试的必测项。用代理工具把网络限速到2G水平看看加载和提交的表现测试过程中断开网络看是否有合理的提示从WiFi切到移动数据看长连接是否重连、正在进行的请求是否失败。这几个场景在Web上相对没那么重要在App上是常态。安装升级也是App独有的。覆盖安装、卸载重装、跨版本升级、升级过程中断这几种情况都要测。尤其是升级后本地数据的兼容性旧版本的数据结构在新版本里能不能正常读取这是上线后最容易出事的地方。4.2 接口层功能验证为什么绕不开现在稍微正规点的项目都是前后端分离前端界面只是数据的一个展示层真正的业务逻辑在接口里。只测界面不测接口等于只看了橱窗没进仓库很多问题根本暴露不出来。接口测试我一般分两层。一层是单接口的功能验证重点测参数校验和返回结构。必填参数缺失、参数类型错误、参数超长、特殊字符、越权访问这几类都要覆盖。返回结构要核对字段名、字段类型、字段是否缺失尤其是新增字段和废弃字段前后端容易对不齐。还有状态码和错误信息的对应关系业务失败到底返回200带错误码还是返回400这个要和开发确认清楚并保持一致。另一层是多接口串联的业务验证。一个完整的业务动作往往要调好几个接口比如下单会涉及商品查询、库存扣减、订单创建、支付发起。前端串起来看起来是一个动作接口层面是好几步中间任何一步的异常处理都要测库存扣减成功了订单创建失败怎么办、支付超时了库存怎么回滚。这类问题在界面上往往被吞掉了只有从接口层面才能看清。接口验证我习惯用脚本或者工具跑不用手工点。一来快二来方便做数据驱动的参数组合三来可以集成到后续的自动化里。哪怕不接入流水线单独跑一遍也比手工高效得多。具体的工具选型看团队习惯能发请求、能断言、能保存用例就行不用追求花哨。提示接口测试一定要有独立的测试数据不要用界面测试剩下的脏数据。每次跑之前做好数据准备和清理否则断言会因为数据状态不对而误报排查起来非常浪费精力。5. 自动化与智能体场景下的测试流程延伸5.1 自动化测试该在什么时机介入自动化不是越早越好也不是所有项目都值得做。我的判断标准有两个功能是否稳定是否会被反复回归。一个功能每两天变一次你写好的脚本两天就废了维护成本比手工还高一个功能半年不变但每次版本都要回归那它就非常适合自动化。介入时机上我一般等这个功能上线跑过两三个版本、需求稳定下来之后再考虑把它脚本化。这样写的脚本存活率高收益也看得见。自动化覆盖的范围优先选核心链路和常驻回归集也就是每次必测的那部分把这部分自动化掉手工测试的精力就能腾出来做探索性测试和新功能测试。还有一点要提前想清楚自动化测试的失败结果怎么处理。脚本跑失败是产品真的有bug还是脚本本身的问题如果不做区分每次跑完一堆红没人看自动化就成了摆设。我的做法是脚本断言尽量精确失败时自动截图、自动保存请求响应降低人工排查成本同时定期清理失效脚本不要让死脚本一直挂着。5.2 智能体类产品的功能测试方法这两年智能体类的产品多了起来测试方法和传统功能测试有相似也有不同。相似的是流程主干没变需求分析、用例设计、执行回归这套还成立不同的是输出不确定同一个输入每次的回答可能都不一样传统的等值断言完全用不了。我的做法是把断言从结果断言换成特征断言。比如测试一个问答类的智能体不去断言它具体输出哪句话而是断言几个特征是否包含关键信息、是否在设定的长度范围内、是否触发了正确的能力调用、响应时间是否在可接受区间。这几个特征组合起来基本能判断功能是否正常工作。另一个重点是边界和异常输入。智能体对空输入、超长输入、含义模糊的输入、包含特殊结构的输入处理方式差异很大这些都是bug高发区。还有多轮对话的状态保持第一轮说的条件在第三轮还能不能记住中途改变意图能不能正确识别这类问题在单轮测试里根本发现不了必须设计连续对话的用例。测试数据的准备也比传统功能测试麻烦因为智能体的表现依赖上下文。同一个问题在不同的对话历史下答案可能完全不同所以每个用例都要带上完整的前置对话。这块我目前还是手工为主能自动化的部分主要是特征校验和数据记录真正的判断还是靠人。6. 常见问题与排查技巧实录6.1 功能测试高频问题速查表下面这张表是我这几年遇到最多的问题和对应的排查思路基本都是反复踩过的坑整理出来方便对照。问题现象可能原因排查思路处理建议本地复现不了线上有问题环境差异、数据差异、缓存对比配置项、抓包看请求、清缓存重试尽量用和生产一致的测试数据偶尔报错无法稳定复现并发、时序、异步回调看日志时间线、加并发重试、查异步任务记录完整现场不要靠记忆复现数值计算结果不一致浮点精度、单位换算核对计算链路、打印中间值金额一律用分为单位或高精度类型页面显示和数据库不一致缓存未刷新、查询条件不同直接查库对比、看缓存过期策略明确缓存刷新时机并写入用例提测版本功能不全分支合并遗漏、构建问题核对版本号和提交记录提测前要求开发自测并给版本说明回归时旧功能挂了公共方法改动、依赖变更对比改动文件、查公共模块调用方建立公共模块的影响面清单我特别想说的是偶尔报错这一类。这种问题最容易被搁置因为当时复现不了开发也会说再观察观察。但偶现问题往往指向并发、时序、异步这些深层缺陷上线后在高并发下会放大。遇到这种问题我的做法是不轻易放过至少把现场信息记录完整时间点、用户ID、订单号、请求参数、服务端日志。哪怕当天解决不了也要挂个跟踪单下一次复现时能直接关联。6.2 我踩过的坑和几条私人心得第一个坑是过度依赖用例。有一段时间我严格执行用例用例写了两百条执行时一条条跑跑完觉得万事大吉。结果上线还是出了问题因为用例是照着需求写的需求本身就没覆盖到的场景用例自然也没有。后来我养成了一个习惯每轮测试留出一定时间做探索性测试不带用例就按照真实用户的方式去用乱点、快操作、来回切换反而发现了不少用例外的bug。第二个坑是不重视测试数据。以前测试喜欢用现成的数据登录就用那几个老账号下单就下那几笔。时间长了这些数据状态复杂有的订单卡在中间状态测出来的结果都不准。后来我坚持每轮测试前准备一套干净的数据用完清理测试结果的可信度高了很多。第三个坑是缺陷单只写现象不写影响。写点击按钮无反应和写点击按钮无反应导致用户无法完成支付影响主流程开发看到的优先级完全不一样。测试的价值不只在于发现问题还在于说清楚问题的严重性让团队把有限的修复资源放在最该修的地方。第四个心得是和开发保持信息同步。测试不是对立面很多问题直接在座位上沟通两分钟就能解决非要走缺陷单走一遍流程反而慢。我的习惯是发现问题的第一时间先口头同步一下确认是问题再提单这样能过滤掉一部分误报也让沟通更顺。当然口头沟通后该补的单还是要补留痕是为了后续追溯不是为了应付流程。最后一条上线后不要立刻撒手。版本发出去只是开始前48小时是线上问题的高发期。我会主动关注监控、看用户反馈、跑一遍核心链路的线上冒烟。很多时候线上问题的表现和测试环境完全不同看一眼真实数据比在测试环境猜半天有用得多。这套流程坚持下来我自己负责的版本线上事故率确实降下来了靠的不是运气是每个环节都多想了一步。