干测试这行十几年最怕的不是加班,也不是需求天天改,而是项目一启动,谁都说不清测试到底该管什么。我见过太多团队在这种模糊地带里内耗:开发觉得这个逻辑我自测过了,不用再验,产品觉得功能能点通就是OK,项目经理觉得测试不就是最后点一遍吗,结果版本发出去三天,线上冒出来一串问题,复盘会上第一个被点名的又是测试。这种场面待久了就明白,软件测试的项目职责、分工和测试流程这三件事如果不提前讲透,后面所有的工作都会退化成救火。这篇东西我想按真实的项目节奏来讲:从职责怎么划、团队里几个人分别干什么,到需求介入、用例设计、执行推进、缺陷闭环、发布收口,再把银行、嵌入式、移动端这几种典型场景下流程的变形说清楚。不管你是在读软件测试基础知识准备面试,还是刚进项目组不知道从哪儿下手,或者是带团队想理顺流程,希望能直接拿走用。1. 把职责边界划在会议室外测试究竟背哪几口锅职责这件事,写进制度文件很容易,难的是在具体冲突里站得住。我的做法是把测试职责拆成三条底线,任何时候都拿这三条去对齐,而不是争论这个归谁。1.1 三条基线质量评估、风险暴露、过程反馈第一条是质量评估。测试要能回答一个具体问题:这个版本能不能发。注意是能给出判断依据,不是保证没问题。判断依据包括用例执行情况、缺陷收敛趋势、遗留缺陷的等级和影响面。任何一个版本,我要求最终结论里必须有一句明确的话,比如核心链路通过,支付模块存在一个二级缺陷,建议带条件发布,而不是测试完毕,请发布这种等于没说的话。第二条是风险暴露。测试的价值很多时候不在于发现了多少BUG,而在于把可能出事的地方提前摆到台面上。哪些模块改动量最大、哪些是老代码没人敢动、哪些需求描述本身有歧义、哪些依赖第三方接口时间不可控——这些都属于风险,应该在提测前就以清单形式发给项目组。我习惯在测试计划里单独留一节叫风险与不确定性,这一节往往比用例数量更能体现测试的专业度。第三条是过程反馈。测试是项目里唯一从头到尾贯穿的角色,需求阶段在场、开发阶段在场、发布阶段还在场,所以对流程本身的毛病看得最清。提测质量差、需求变更没有记录、环境不稳定、缺陷单写得像谜语,这些都是流程问题,测试有义务把它说出来并推动改进。但也仅止于提出来给方案,没有权力替别人做决定,这条界限要拎清。1.2 最容易吵起来的三块灰色地带第一块是自测的深度。开发说我自测过了,测试说你那个自测不算。这个争论的标准其实可以量化:自测应该覆盖新增功能的主流程和明显分支,并且留下痕迹——哪怕是简短的验证记录或者接口调用截图。我通常会要求开发在提测说明里写清自测了哪几条路径,结果如何,写不出来的就退回。第二块是需求歧义导致的缺陷判定。需求文档写用户输入非法字符时给出提示,但没写提示在哪儿显示、什么样式、能不能重复提示。测出来之后开发说我按我的理解做的,不算BUG,产品说这是需求没写清。我的处理方式是:歧义本身就是缺陷,挂在需求文档上而不是代码上,由产品确认后统一修订,然后测试补充用例。这样既避免了和开发私下扯皮,也让需求文档越来越严谨。第三块是上线后的线上问题归属。线上出了问题不等于漏测,这一点很多团队没共识。判断标准是:如果测试用例覆盖了该场景且执行通过,那就是环境差异或者上线操作问题;如果用例没覆盖,那是用例设计遗漏,测试要认;如果连需求都没提,那主要是需求侧问题,测试附带责任。把这三类区分清楚写在复盘模板里,能省掉大量无效的甩锅。1.3 一张职责对照表,把扯皮挡在会议室门口下面这张表是我们团队实际用的,每次项目启动会直接投屏,有异议当场提,确认后归档。环节产品/需求开发测试项目经理需求评审主讲、确认范围评估可行性提可测性问题、识别歧义组织、控节奏测试计划确认优先级提供排期与依赖主编、输出策略与风险审核资源与时间提测准入确认需求已冻结保证自测通过、留痕定义准入标准、执行冒烟协调卡点处理缺陷处理裁定需求歧义修复、回复根因发现、复现、验证跟踪遗留缺陷决策发布决策确认业务期望提供发布包与回滚方案给出质量结论最终决策与签核线上问题反馈现象定位修复协助复现、补用例组织复盘这张表最大的作用不是分工本身,而是把这件事不归我这种话变成有依据的判断。项目里最怕的不是忙,是忙完之后发现大家在同一个点上重复使劲。2. 一个测试组里到底有几种人角色分工与人力配比职责讲的是做什么,分工讲的是谁来做。很多团队的分工是靠临时指派的,今天张三测登录,明天李四测登录,结果谁都不熟悉那块业务。稳定的分工方式是按角色划分职能,再按模块划分归属。2.1 五类常见角色各自的核心产出测试负责人(Test Lead)。核心产出是测试策略、计划、进度与质量报告、资源调配。这个岗位最关键的能力不是技术,是判断力——判断哪些功能可以少测、哪些必须死磕。我见过不少负责人把精力全花在写用例上,结果项目节奏失控,这是典型的角色错位。功能测试工程师。核心产出是用例、执行记录、缺陷单。这是团队里人数最多的角色,也是最容易被低估的角色。同样一个功能,有人能写出二十条用例覆盖主要分支,有人写五条就自以为覆盖完了,差距全在对业务的理解深度上。自动化测试工程师。核心产出是自动化脚本、框架维护、持续集成里的回归任务。要注意一点,自动化不是拿来替代手工用例的,它的定位是高频重复、结果稳定、值得长期维护的那部分回归工作。硬把所有手工用例脚本化,维护成本能拖垮整个团队。性能测试工程师。核心产出是性能方案、压测脚本、指标报告、调优建议。这个角色在项目里的介入时间点很关键,最好在架构设计阶段就参与,否则等到系统做完了发现瓶颈在数据库设计上,改起来成本极高。测试开发(Test Dev)。核心产出是测试工具、平台、数据构造能力、Mock服务。当团队规模超过十人,或者接口数量超过几百个,没有测试开发支撑会非常吃力,光靠人工构造测试数据就能耗掉一半工时。2.2 人力配比怎么算才不至于拍脑袋常见的拍脑袋算法是开发和测试一比三或者一比五,这种粗算只适合做预算,不适合排项目。我习惯用下面三个维度叠加来算:按用例规模:先用历史项目的数据估算本次用例条数,再按人均日执行量折算。手工执行的合理区间大概在每人每天 60 到 120 条,具体看用例复杂度和环境稳定性。按模块风险:核心交易链路、涉及金额计算、涉及权限变更的模块,人力要按 1.5 倍甚至 2 倍配置,因为需要多轮回归和交叉验证。按迭代节奏:两周一个迭代的团队,测试窗口通常只有 4 到 5 个工作日,倒推下来执行量必须在上限附近,这时候提前做自动化回归覆盖就变成刚需。把这三个维度写进排期表,再和项目经理对资源,比空口争论人不够有说服力得多。举个具体例子:某次迭代新增和修改功能共 380 个用例,历史人均日执行 90 条,那纯执行就是 4.2 人日;再加一轮回归 200 条,约 2.2 人日;缺陷验证按缺陷数 40 个、每个 0.15 人日算,约 6 人日。合计约 12.4 人日,五天窗口至少需要 2.5 个人。这个数字摆在桌面上,是要人还是砍范围,就变成一个可以讨论的决策了。2.3 小团队一人多岗怎么排优先级三个人的测试团队不可能把五类角色配齐。这种情况下我的排法是:功能测试保底、自动化保回归、性能按节点外借。具体说,所有人先保证核心功能的用例设计和执行,这是底线;自动化只在回归量大、重复度高的模块上做,优先覆盖接口层而不是UI层,因为接口脚本稳定得多;性能测试如果在项目里只是节点性需求,就集中两周突击,平时不做常态化投入。至于测试开发,小团队一般用现成的开源工具加简单脚本解决,不自己造平台。一人多岗最容易出的问题是什么都在做,什么都做不完。我的经验是每周固定一天做自动化维护,其余时间全给功能测试,把自动化的产出节奏放慢,反而更稳。3. 流程的起点不是拿到安装包需求与设计阶段的测试介入很多团队把测试流程定义成拿到提测包之后开始,这就等于主动放弃了最容易控制风险的阶段。需求阶段冒出来的一个歧义,在编码之后解决的成本可能是在评审时解决的十倍。3.1 需求评审会上测试必须问的七个问题我列了一份自己的清单,每次需求评审都拿出来对:这个需求的验收标准是什么,由谁来验收?涉及哪些老功能会被影响,有没有回归范围说明?异常流程怎么处理,包括超时、重复提交、并发冲突、数据不存在?边界值定义清楚了吗,比如最大值、最小长度、小数位数、时间范围?权限和数据可见范围是什么,不同角色看到的数据一样吗?涉及外部系统交互时,对方的接口契约和测试环境是否可用?这个需求能不能测试——有没有可观测的结果,比如日志、页面状态、数据库落库?第七个问题经常被忽略但特别重要。有些需求只做了后台异步处理,前端什么都不显示,测试根本没法验证处理结果,只能靠翻数据库。这种时候就要在评审现场推动开发补日志或者补一个查询入口,这叫可测性要求,应该在需求阶段提。我踩过一次坑:某个数据同步需求做完之后,同步结果只在日志里打一行,而日志又没做保留策略,上线三天后日志被清掉,线上问题根本查不到。从那以后,凡是需求里有异步处理的,我一律要求补一个可查询的状态字段。3.2 测试策略写多厚才合适测试计划这东西,写三十页没人看,写三行又没意义。我的标准是:一页纸能说清楚范围、策略、资源、风险、产出就够了。范围部分要明确写清测什么和不测什么。不测的部分尤其重要,比如本次不包含老版本数据迁移验证不包含IE浏览器兼容性,写清楚之后就不会在项目后期被人问这个怎么没测。策略部分讲方法:哪些模块用自动化回归,哪些必须手工,性能指标的目标值是多少,兼容性要覆盖哪些设备。资源部分讲人、环境、时间。风险部分就是前面提到的清单。产出部分写明交付物:测试报告、缺陷清单、回归记录。我见过把测试计划写成教科书的情况,里面塞满了测试的重要性测试的基本原则这类内容,对项目没有任何指导意义。测试计划是给项目组看的行动文件,不是给自己看的论文。3.3 可测性设计让开发顺手把测试点埋好可测性这件事,测试要主动去提,开发通常会配合,因为大部分改动成本很低。我常提的几类:关键分支打印业务日志,带上唯一标识(比如订单号、请求ID),方便串联全链路。提供状态查询接口或者后台查询页面,不做业务处理,只读。时间相关的逻辑支持参数注入或者配置开关,否则测过期场景要等到明天。涉及第三方的部分提供可控的Mock开关,避免测试环境被对方牵着走。数据清理脚本或者重置接口,让测试环境可以重复使用。最后这一条尤其关键。很多团队测试环境里堆了几年的脏数据,每次测试都要花时间挑一条能用的。有了一键重置能力,测试效率能提升一大截。我在一个项目里推动做了环境重置脚本之后,回归一轮的时间从两天压到半天,这个投入完全值得。4. 用例设计与评审最常被压缩、也最不该被压缩的一环项目一紧,第一个被砍的就是用例评审。这是很要命的做法,因为用例是用例,执行是执行,设计阶段的错误在评审时发现成本最低,在执行时发现就只能返工。4.1 四种设计方法各自的适用边界等价类划分适合输入域很大但逻辑单一的字段,比如金额、数量、年龄。它的核心是把无限输入压缩成几类代表值,划分的依据是处理逻辑是否相同,不是值是否相近。举个例子,某系统对金额 0.01 到 100000 是正常处理,超过走人工审核,那有效等价类就是这两个区间,无效等价类是非数字、负数、超长位数。边界值分析是等价类的补充,专门盯着区间的两端和相邻值。0.01 这个下界,要测的是 0.00、0.01、0.02 三个点;上界 100000 要测 99999.99、100000.00、100000.01。边界值最容易出问题,因为它往往是条件判断里的和写错。判定表适合多个条件组合决定一个结果的功能,比如会员等级 支付方式 优惠券类型决定折扣比例。这种用等价类和边界值都覆盖不全,只有列出条件桩和动作桩做笛卡尔积,才能发现组合缺失。条件是三四个的时候表格还能看,超过五个就要考虑用正交或者用工具约简。场景法适合业务流程类功能,按主线、备选线、异常线来设计。比如下单主线是选商品→下单→支付→发货,备选线是支付超时后重新支付,异常线是支付成功后库存不足。场景法写出来的用例条数少但覆盖真实路径,和业务方沟通时也最好理解。实际工作中这四种方法不是选一个,而是叠着用。我的习惯是先用场景法把主流程骨架搭出来,再对每个步骤里的输入项用等价类和边界值细化,遇到多条件判断的地方补判定表。4.2 用例评审真正该盯的三件事第一,覆盖是否完整。评审前先做一个需求条目与用例的双向对照表,每条需求至少对应一条用例,反过来每条用例都能追溯到需求。这个方法叫需求覆盖率检查,能有效防止漏测。第二,步骤是否可执行。用例步骤要写到换一个人照着做也能执行的程度,包括前置数据、操作路径、输入值、预期结果。预期结果必须是可判断的,不能写页面显示正常这种模糊表述。第三,冗余是否有必要。有时候同一条路径被三四个场景重复覆盖,这时候要判断是真冗余还是必要的交叉验证。一般来说,涉及数据状态变化的场景值得保留重复,纯查询类的可以合并。评审参与人建议包括:测试组内其他人(交叉评审,换视角)、开发(确认技术可行性)、产品(确认预期结果)。评审时长控制在每人 50 条用例一小时左右,超了效率就下降。4.3 用例库的维护别让它变成一次性消耗品用例写完只用一次是极大的浪费。我的做法是给用例打标签,至少包括模块、版本、优先级、是否自动化。迭代时新需求挂新标签,老用例按标签筛选出回归集,这样回归范围就是可计算的,而不是每次靠脑子回忆。优先级分级我用三级:P0:核心业务链路,任何版本必须执行,执行失败即阻塞发布。P1:主要功能的正常分支和常见异常分支,常规回归执行。P2:次要功能、极端异常、兼容性场景,按版本改动范围选择性执行。另外要定期清理失效用例。产品下线了某个功能,对应用例要标记废弃而不是直接删除,保留半年后归档,免得以后追责时找不到依据。5. 执行阶段的推进节奏从冒烟到收敛执行阶段是流程里最容易失控的一段,因为它涉及多方协同:开发还在改代码、环境时不时挂掉、产品又插进来一个小需求。控制节奏的关键是有明确的卡点和可量化的进度。5.1 提测准入与冒烟卡点提测准入标准要提前定好并公开,常见的有这几条:需求已冻结、开发自测通过并留痕、提测说明写明改动范围和影响面、代码已合并到约定的分支、部署完成且服务可访问。冒烟测试是提测后的第一道门。冒烟不通过直接退回,不要犹豫。这一点很多新人做不到,觉得改一改再验就行了,结果就是在不稳定版本上反复测,记录全部作废。冒烟范围建议控制在 15 到 30 条核心用例,半小时内跑完,覆盖登录、主流程、核心接口连通性。退回过一次之后,我一般会要求开发在提测邮件里明确写上上一次退回的原因已修复,这能显著降低二次退回率。5.2 轮次划分与进度可视化一个迭代的测试执行通常分几轮:第一轮全量执行新增用例,第二轮集中回归改动影响范围,第三轮修缺陷后的验证与收尾回归。进度的呈现方式直接影响沟通效率。我推荐一张简单的表:轮次计划用例数已执行通过失败阻塞通过率第一轮38026023026488.5%第二轮2001201155095.8%通过率不是唯一指标,更要看失败用例的集中度。如果失败集中在某一个模块,说明那个模块质量有问题,需要专项处理;如果四处开花,往往是环境或者基础数据的问题,先解决环境再谈质量。阻塞用例要单独跟踪,它通常意味着依赖没就绪,比如第三方接口没开、测试数据没造、环境没配好。阻塞超过半天就要升级同步,不要自己扛。5.3 环境和数据准备被低估的时间黑洞说实话,我在项目里见过的时间浪费,有一大半花在环境上面。表现包括:环境被人随手改了配置、数据库被另一个项目占用、测试账号权限不对、依赖服务版本和线上不一致。几个实用的做法:环境配置用脚本管理,不靠手工改。哪怕只是几个配置文件的替换,也写成脚本,别人也能用。每个项目组独立账号和数据空间,不共用。共用迟早出冲突。建立数据构造工具或者脚本集,常见场景比如一个新注册用户一个已下单未支付订单一个余额不足的账户,一键生成。记录环境变更日志,谁改了配置、改了什么、什么时间,写一行。这个习惯能省掉无数排查时间。数据这块还要注意生产数据的脱敏使用。有些场景确实只有真实数据才能复现,这时候必须走审批、脱敏、限定范围,并且在测试结束后清理。这不是合规要求的问题,是基本的职业素养。6. 缺陷的全生命周期一个BUG从发现到关闭缺陷管理是测试流程里最见功力的部分。同样发现一个BUG,有人写出来的单子开发十分钟就改完,有人写出来开发来回问五遍还是不明白。6.1 缺陷分级:别把标准挂在墙上不用分级标准每个团队都有,但执行起来经常走样。我用的四级定义和判断口径是这样的:等级定义判断口径处理时限致命导致系统不可用、数据错误、资金差错主流程完全阻断或产生错误业务结果立即处理严重主要功能不可用,无绕过方式核心功能失败且有业务影响当日处理一般功能异常但有绕过方式非核心功能失败或体验明显异常迭代内处理轻微界面、文案、易用性问题不影响业务正确性排期处理分歧最大的是严重和一般的边界,分歧点在于有没有绕过方式。我一般这样判断:如果有替代路径能让用户完成同样的事情,就是一般;如果替代路径的成本高到用户会放弃,就是严重。实际项目中还有一类特殊缺陷叫数据类缺陷,它本身可能不导致功能报错,但已经写入了错误数据。这类缺陷一律按严重以上处理,因为修复代码容易,清理数据麻烦,而且影响面会随着时间扩大。6.2 一份让开发无法拒绝的缺陷单缺陷单的核心是让开发不用问任何问题就能动手。我用的模板长这样:标题:[模块] 简短现象描述(可复现) 例:[订单] 优惠券叠加使用时金额计算少减 10 元 环境:测试环境 v2.3.1 / 数据库 test_order / 浏览器 Chrome 120 账号:user_test_01 前置数据:用户持有满 100 减 10 的优惠券 1 张,满 200 减 30 的优惠券 1 张 复现步骤: 1. 登录 user_test_01,选择商品 A(单价 120 元) 2. 进入结算页,勾选两张优惠券 3. 点击提交订单 4. 查看订单详情页的应付金额 预期结果:应付 120 - 10 - 30 80 元 实际结果:应付 90 元(只减了 30 元) 复现概率:必现(连续 3 次均出现) 补充信息:接口 /api/order/confirm 返回的 discountAmount 字段为 30 附件:结算页截图、订单详情截图、接口请求响应日志关键要素是前置数据和接口信息。前置数据决定了开发能不能立刻复现,接口信息能帮开发快速定位是前端传参问题还是后端计算问题。我见过太多缺陷单只写优惠券用不了,开发问一圈才知道是环境不对、账号不对、数据没造。另外提醒一句:缺陷单里不要写情绪化的东西。这么明显的BUG都没测出来?开发是不是没测?这种话写进去只会让事情更难办,而且会留在系统里。就事论事,把事实讲清楚,效率最高。6.3 修复验证与回归范围的收敛缺陷修复后的验证不是简单地把原来那几步再做一遍。我一般按三层做:第一层,原始场景复现验证。按缺陷单的步骤走一遍,确认问题消失。这一步最快,但不能只做这一步。第二层,相邻场景验证。想一想这个修复可能影响哪些相邻逻辑。比如修复了优惠券金额计算,那就要验证单张优惠券、不叠加、叠加后取消某个券、券过期等情况。这一层最容易被漏,也是线上问题的主要来源。第三层,回归范围收敛。不是所有修复都要跑全量回归,但要跑该模块的 P0 用例以及相关的接口自动化。我通常会把本轮所有缺陷涉及的模块汇总成一张回归清单,统一执行一轮,而不是修一个测一个。这里有个经验:缺陷修复引入的新问题,往往比原缺陷影响更大。所以我要求所有修复类提交必须在提交记录里关联缺陷编号,这样回归时能直接按编号反查改动范围。7. 发布与上线流程的收口动作不能省很多团队到发布阶段反而松了,觉得测完了就行。实际上发布环节的操作失误造成的线上问题,占比相当高,而且通常比代码缺陷更致命,因为它影响的是全部用户。7.1 发布检查清单我们团队的发布检查清单大概是这样,每次发布前逐条打勾:代码已冻结,发布分支无未验证提交数据库变更脚本已在测试环境执行验证,并准备好回滚脚本配置项、开关、定时任务、消息队列配置已核对依赖的第三方服务已确认可用发布包已打标签,版本号可追溯回滚方案已明确,回滚耗时已评估发布后冒烟用例清单已准备其中回滚方案和数据库脚本的回滚是最容易被忽略的。我会坚持要求:凡是有数据库结构变更的版本,必须提供回滚脚本并在测试环境演练一次。演练过和没演练过是两回事,前者出问题时能十分钟恢复,后者可能折腾两小时。7.2 上线后的验证与监控联动发布完成不等于结束。上线后的验证分几件事做:冒烟验证:核心链路走一遍,建议由测试执行,不要交给业务方。日志观察:发布后半小时内盯关键接口的错误日志和响应时间,异常增长立刻回滚。数据核对:涉及数据写入的功能,发布后抽查几条真实数据,确认落库正确。监控指标:错误率、响应时间、队列积压、数据库连接数,这些指标要有基线,没基线就判断不出异常。我要特别说一下灰度发布。如果项目支持,新功能尽量先放小比例流量,观察一段时间再全量。这能在真实流量下暴露测试环境里根本造不出来的问题,比如并发场景、真实设备兼容性、真实用户的操作习惯。7.3 版本复盘:让流程一次比一次顺复盘不是检讨会,目的只有一个:找出下次可以改进的具体动作。我用的复盘结构是现象—原因—动作三列,动作必须可执行、有责任人和时间点。比如:现象原因动作责任人完成时间上线后发现一个二级缺陷用例未覆盖并发提交场景补充并发类用例模板并加入评审清单测试A下个迭代前环境被其他项目占用导致半天无法执行缺少环境使用登记建立环境使用登记表和变更日志测试B本周内一份复盘如果最后产出的是下次要加强测试这种话,那就是白开了。可执行的改进动作才是复盘的唯一价值。8. 不同项目形态下流程的变形前面讲的是一套通用流程,但不同行业的项目对流程的约束差别很大。同一套做法照搬到银行项目或者嵌入式项目上,往往行不通。8.1 银行及金融类项目:流程更重、留痕更严这类项目最大的特点是流程留痕要求高、变更管控严格。测试计划、用例、缺陷单、测试报告通常都需要评审签字,需求变更要走变更单,测试环境的数据也要走审批。具体差异体现在几个方面:一是测试用例的评审往往是正式的,参与人多,记录要归档;二是缺陷分级更严格,涉及金额计算和账务的问题基本都按最高等级处理;三是回归测试要求完整,不能随意裁剪范围,因为业务影响面大;四是上线窗口固定,通常在夜间非交易时段,测试要配合做上线后的验证。在这种环境下工作,我最大的体会是:前期准备要做得更足。因为任何临时变更都要走流程,时间成本很高,所以在需求评审阶段就要把问题问透,用例评审阶段就要把覆盖做全。另外,文档能力比技术能力更重要,写得清楚、记得完整,是这类项目的基本功。8.2 嵌入式及硬件相关项目:测试对象不只是软件嵌入式项目里,被测对象是软件硬件环境的组合,很多问题不在代码里,而在时序、功耗、硬件兼容性上。流程上的主要差异:一是测试环境搭建周期长,可能需要实际的硬件设备或者仿真环境;二是自动化程度受限,很多场景需要人工操作和观察;三是问题复现难,同一个现象可能十次里只出现一次,必须靠长时间运行和日志记录来捕捉;四是需要关注边界条件,比如断电、弱信号、极端温度、内存不足等情况。我参与过的一个项目里,有个偶发问题排查了两周,最后发现是某个时序竞争条件,只在特定硬件版本的特定负载下触发。这种问题靠用例设计是设计不出来的,靠的是长时间稳定性测试加上详细的运行日志。所以做这类项目,耐心和日志规范比技巧更重要。8.3 移动端APP:必须额外补的几类测试移动端项目的流程骨架和其他项目一样,但有几个专项必须补:兼容性测试:按系统版本、屏幕尺寸、厂商定制系统分组覆盖。不要每个机型都测,而是选代表性机型,关键是覆盖差异大的定制系统。网络场景测试:弱网、切换网络、断网重连、请求超时。这类问题在测试环境用工具模拟,不要只测WiFi环境。安装与升级测试:首次安装、覆盖安装、跨版本升级、卸载重装后数据是否残留。升级路径是最容易出问题的地方。前后台切换与中断测试:来电、消息推送、锁屏、后台被杀,再回到APP时状态是否正确。这类场景用户天天遇到,但测试经常漏。权限相关测试:首次拒绝权限、后续再授予、在设置里关闭权限后的表现。移动端的回归成本比较高,因为安装包分发、设备管理都要时间。我的建议是把高频回归的场景尽量接口化,把设备相关的用例集中在一轮跑完,避免反复切换设备。9. 这些年踩过的坑和几条实在的建议写到这里,把几个印象最深的教训摆出来,都是实打实花时间换来的。第一个坑是用例评审走过场。早年带的一个项目,评审会开了一小时,大家点头通过,结果执行到第三天发现有整个模块的场景没覆盖。后来我改了个做法:评审前把需求条目和用例的对照表先发出去,让大家带着表来评审,会议上只对没覆盖上的条目做讨论。这么一改,漏测率明显下降。第二个坑是缺陷单里不写前置数据。开发看不懂,来回问,一天能问掉两个小时。后来强制要求所有缺陷单一律包含环境、账号、前置数据三要素,写不全的不允许提交。这个规定刚推的时候有人嫌麻烦,推行两周之后就没人抱怨了。第三个坑是把自动化当成万能药。有一年团队花大力气把 UI 用例全脚本化,结果页面一改版,几百条脚本全红,维护成本比手工执行还高。后来调整策略,只保留核心主流程的 UI 自动化,其余全部转到接口层,稳定性立刻就上来了。这个教训我现在还会讲给新同事:自动化要选变化慢、执行频繁的部分做。第四个坑是上线后没人盯。有次版本发完就下班了,第二天早上发现某个接口错误率一直偏高。从那以后我们固定安排发布后一小时的观察值班,谁发谁盯,有问题当场处理。一个小时的投入,换来的安心很值。最后分享一个我自己一直在用的习惯:每完成一个迭代,花二十分钟把这一轮我遇到的三个意外记下来,不管是环境问题、需求歧义还是自己判断失误。坚持几个项目之后你会发现,这些意外里有一半是重复出现的,而重复出现的问题,基本都能靠流程或者模板解决。测试这行做久了,提升往往不来自学了什么新技术,而来自把已经踩过的坑一个一个填平。