企业官网建设流程全解析

干测试这行十几年，最怕的不是加班,也不是需求天天改,而是项目一启动,谁都说不清"测试到底该管什么"。我见过太多团队在这种模糊地带里内耗:开发觉得"这个逻辑我自测过了,不用再验",产品觉得"功能能点通就是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 需求评审会上测试必须问的七个问题

我列了一份自己的清单,每次需求评审都拿出来对:

1. 这个需求的验收标准是什么,由谁来验收?
2. 涉及哪些老功能会被影响,有没有回归范围说明?
3. 异常流程怎么处理,包括超时、重复提交、并发冲突、数据不存在?
4. 边界值定义清楚了吗,比如最大值、最小长度、小数位数、时间范围?
5. 权限和数据可见范围是什么,不同角色看到的数据一样吗?
6. 涉及外部系统交互时,对方的接口契约和测试环境是否可用?
7. 这个需求能不能测试——有没有可观测的结果,比如日志、页面状态、数据库落库?

第七个问题经常被忽略但特别重要。有些需求只做了"后台异步处理",前端什么都不显示,测试根本没法验证处理结果,只能靠翻数据库。这种时候就要在评审现场推动开发补日志或者补一个查询入口,这叫可测性要求,应该在需求阶段提。我踩过一次坑:某个数据同步需求做完之后,同步结果只在日志里打一行,而日志又没做保留策略,上线三天后日志被清掉,线上问题根本查不到。从那以后,凡是需求里有异步处理的,我一律要求补一个可查询的状态字段。

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 轮次划分与进度可视化

一个迭代的测试执行通常分几轮:第一轮全量执行新增用例,第二轮集中回归改动影响范围,第三轮修缺陷后的验证与收尾回归。

进度的呈现方式直接影响沟通效率。我推荐一张简单的表:

通过率不是唯一指标,更要看失败用例的集中度。如果失败集中在某一个模块,说明那个模块质量有问题,需要专项处理;如果四处开花,往往是环境或者基础数据的问题,先解决环境再谈质量。

阻塞用例要单独跟踪,它通常意味着依赖没就绪,比如第三方接口没开、测试数据没造、环境没配好。阻塞超过半天就要升级同步,不要自己扛。

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 版本复盘:让流程一次比一次顺

复盘不是检讨会,目的只有一个:找出下次可以改进的具体动作。我用的复盘结构是"现象—原因—动作"三列,动作必须可执行、有责任人和时间点。

比如:

一份复盘如果最后产出的是"下次要加强测试"这种话,那就是白开了。可执行的改进动作才是复盘的唯一价值。

8. 不同项目形态下流程的变形

前面讲的是一套通用流程,但不同行业的项目对流程的约束差别很大。同一套做法照搬到银行项目或者嵌入式项目上,往往行不通。

8.1 银行及金融类项目:流程更重、留痕更严

这类项目最大的特点是流程留痕要求高、变更管控严格。测试计划、用例、缺陷单、测试报告通常都需要评审签字,需求变更要走变更单,测试环境的数据也要走审批。

具体差异体现在几个方面:一是测试用例的评审往往是正式的,参与人多,记录要归档;二是缺陷分级更严格,涉及金额计算和账务的问题基本都按最高等级处理;三是回归测试要求完整,不能随意裁剪范围,因为业务影响面大;四是上线窗口固定,通常在夜间非交易时段,测试要配合做上线后的验证。

在这种环境下工作,我最大的体会是:前期准备要做得更足。因为任何临时变更都要走流程,时间成本很高,所以在需求评审阶段就要把问题问透,用例评审阶段就要把覆盖做全。另外,文档能力比技术能力更重要,写得清楚、记得完整,是这类项目的基本功。

8.2 嵌入式及硬件相关项目:测试对象不只是软件

嵌入式项目里,被测对象是"软件+硬件+环境"的组合,很多问题不在代码里,而在时序、功耗、硬件兼容性上。

流程上的主要差异:一是测试环境搭建周期长,可能需要实际的硬件设备或者仿真环境;二是自动化程度受限,很多场景需要人工操作和观察;三是问题复现难,同一个现象可能十次里只出现一次,必须靠长时间运行和日志记录来捕捉;四是需要关注边界条件,比如断电、弱信号、极端温度、内存不足等情况。

我参与过的一个项目里,有个偶发问题排查了两周,最后发现是某个时序竞争条件,只在特定硬件版本的特定负载下触发。这种问题靠用例设计是设计不出来的,靠的是长时间稳定性测试加上详细的运行日志。所以做这类项目,耐心和日志规范比技巧更重要。

8.3 移动端APP:必须额外补的几类测试

移动端项目的流程骨架和其他项目一样,但有几个专项必须补:

• 兼容性测试:按系统版本、屏幕尺寸、厂商定制系统分组覆盖。不要每个机型都测,而是选代表性机型,关键是覆盖差异大的定制系统。
• 网络场景测试:弱网、切换网络、断网重连、请求超时。这类问题在测试环境用工具模拟,不要只测WiFi环境。
• 安装与升级测试:首次安装、覆盖安装、跨版本升级、卸载重装后数据是否残留。升级路径是最容易出问题的地方。
• 前后台切换与中断测试:来电、消息推送、锁屏、后台被杀,再回到APP时状态是否正确。这类场景用户天天遇到,但测试经常漏。
• 权限相关测试:首次拒绝权限、后续再授予、在设置里关闭权限后的表现。

移动端的回归成本比较高,因为安装包分发、设备管理都要时间。我的建议是把高频回归的场景尽量接口化,把设备相关的用例集中在一轮跑完,避免反复切换设备。

9. 这些年踩过的坑和几条实在的建议

写到这里,把几个印象最深的教训摆出来,都是实打实花时间换来的。

第一个坑是用例评审走过场。早年带的一个项目,评审会开了一小时,大家点头通过,结果执行到第三天发现有整个模块的场景没覆盖。后来我改了个做法:评审前把需求条目和用例的对照表先发出去,让大家带着表来评审,会议上只对没覆盖上的条目做讨论。这么一改,漏测率明显下降。

第二个坑是缺陷单里不写前置数据。开发看不懂,来回问,一天能问掉两个小时。后来强制要求所有缺陷单一律包含环境、账号、前置数据三要素,写不全的不允许提交。这个规定刚推的时候有人嫌麻烦,推行两周之后就没人抱怨了。

第三个坑是把自动化当成万能药。有一年团队花大力气把 UI 用例全脚本化,结果页面一改版,几百条脚本全红,维护成本比手工执行还高。后来调整策略,只保留核心主流程的 UI 自动化,其余全部转到接口层,稳定性立刻就上来了。这个教训我现在还会讲给新同事:自动化要选"变化慢、执行频繁"的部分做。

第四个坑是上线后没人盯。有次版本发完就下班了,第二天早上发现某个接口错误率一直偏高。从那以后我们固定安排发布后一小时的观察值班,谁发谁盯,有问题当场处理。一个小时的投入,换来的安心很值。

最后分享一个我自己一直在用的习惯:每完成一个迭代,花二十分钟把"这一轮我遇到的三个意外"记下来,不管是环境问题、需求歧义还是自己判断失误。坚持几个项目之后你会发现,这些意外里有一半是重复出现的,而重复出现的问题,基本都能靠流程或者模板解决。测试这行做久了,提升往往不来自学了什么新技术,而来自把已经踩过的坑一个一个填平。