最近在盘点暖食坊项目测试资产的时候我又把从需求评审到上线回归这一路的测试用例完整过了一遍。暖食坊不是一个简单的点餐Demo它把堂食点单、外卖配送、会员营销和商家后台管理四块业务都揉在了一套系统里用例设计如果只按页面功能一个个去怼最后大概率会得到一份几百条却抓不住重点的用例库。真正的价值不在于用例数量而在于每一条用例能不能在正确的时间暴露正确的问题。这篇文章不会跟你讲那种放之四海而皆准的“测试理论”而是以暖食坊为例把测试用例从设计、编写、维护到自动化的完整过程拆开来看。内容包括功能测试用例怎么写才不会漏场景、测试用例Excel模板哪些字段真正有用、自动化框架为什么选Playwright、以及我在实际执行里踩过的坑。无论你是在给一个小程序点餐页面写冒烟用例还是在搭建整套测试基础设施里面的大部分做法都可以直接搬到你的项目里。1. 暖食坊测试范围拆解与用例体系设计1.1 先画功能地图再定用例边界第一次拿到暖食坊的需求文档时我没有急着打开Excel写用例而是先做一个动作把产品拆成用户端、商家端、运营端三大块再往下细分到功能模块。用户端包括注册登录、门店选择、菜单浏览、加入购物车、确认订单、在线支付、订单查询、评价售后商家端包括店铺设置、菜品管理、库存管理、接单出餐、清结算查看运营端包括优惠券配置、会员等级、活动营销、数据报表。这一步看起来费时间但实际价值很大它决定了你后续用例的目录结构也避免用例之间互相重叠。写用例最怕的是边界不清。比如“用户下单成功”这条用例到底属于购物车模块还是订单模块如果不做功能地图规划几条类似的用例会被不同的人重复写。我的习惯是在功能地图上用三种标记一是纯前端展示和交互二是核心业务规则三是第三方依赖功能。纯前端展示类用例可以少而精业务规则类要逐条覆盖第三方依赖功能比如支付和地图需要在用例里明确写好前置条件与Mock策略。这样划分之后整份用例库的组织结构就清楚了。1.2 用例分级不是所有用例都值得天天回归暖食坊的用例我习惯分成P0、P1、P2、P3四个级别。P0是冒烟级用户从进店到完成支付这一段主路径必须覆盖每次发版之前必定执行P0挂了直接阻断发布P1是核心业务级包括优惠券抵扣、退款、库存扣减、商家接单这些直接影响收入或用户体验的场景每次回归必跑P2是正常功能级比如个人资料修改、我的订单筛选这些一般每周或版本回归时跑P3是边缘和兼容性像极低版本手机浏览器、异常网络、特殊字符输入这类用例不需要每次都执行但每次大版本升级前要挑重点跑一遍。这里有一个关键认知用例分级不是给用例评职称而是给回归策略定成本预算。如果不分级全量用例几百条手动跑要一个下午自动化也没时间维护最后大家就会选择性执行漏掉真正的问题。暖食坊上线之后我统计过真正能拦截线上问题的用例集中在P0和P1只占全量回归用例的百分之六七十。所以宁可把P0、P1设计得精细一些也不要把精力平均撒到P3上。1.3 测试数据和环境用例能不能跑起来全靠它暖食坊项目里我最开始写的几条用例跑不起来的根本原因不是步骤有问题是测试数据没准备好。很多新人容易忽略这一点用例前置条件里写“用户已登录”但账号对应的门店已经停业了“优惠券可用”但券已经被领完。这类问题在执行阶段会浪费大量时间。所以我在用例模板里强制加了一行“测试数据要求”同时在环境准备阶段就准备好一组标准的测试数据两个测试门店、三个测试菜品、一个固定优惠券池、一个可重复消费的会员账号、支付沙箱账号。这些数据要保证两点可重复性和隔离性。可重复性是指用例执行后数据能复位比如下单成功后自动取消订单库存能加回来隔离性是指测试数据不要和演示数据混在一起。暖食坊之前发生过一次事故测试环境的优惠券配置被人改掉结果整条促销用例报废。从那以后我要求所有用例数据必须打上环境标识比如测试门店名称统一加“AT-”前缀账号用at_开头这样至少能一眼看出数据属于哪个环境排查问题时就会快很多。2. 功能测试用例编写实战2.1 一个可执行用例必须包含的字段我见过一种典型的不合格用例标题是“订单创建成功”步骤里就一句话“正常创建订单”预期结果写“订单创建成功”。这种用例没有任何执行价值因为它没有前置条件、没有数据、没有具体操作路径。一个真正可执行的用例至少要包含用例编号、所属模块、用例标题、优先级、前置条件、测试步骤、预期结果、测试数据要求。编号要稳定方便在缺陷单和自动化脚本里引用前置条件写清楚环境、账号、数据状态步骤要写成“单步可执行”的粒度比如“点击门店卡片进入门店主页”、“搜索框输入‘脆皮鸡饭’并点击搜索”每一步加一个预期结果。我自己写步骤的底线是一个人从来没接触过这个系统拿着这条用例也能一步步跑完并且能明确判断每一步是否通过。你可以把用例当成一份操作说明书而不是给自己看的技术随笔。预期结果要写可观察的结果不要用“页面显示成功”这种含糊说法要写“订单号出现且订单状态为待支付购物车为空优惠券已标记为使用”。这种写法才具备断言价值后面转自动化时能直接翻译成断言语句。2.2 下单核心链路用例拆解暖食坊最核心的链路是“选菜-加购-提交订单-支付-生成订单-商家接单-配送或取餐”这条链路用一个用例覆盖往往不够要拆成多条。这里举几条有代表性的用例编号习惯是“模块-场景-序号”用例编号用例标题前置条件关键步骤预期结果AT-ORDER-001营业时间内正常下单并完成支付测试门店营业中菜品库存充足用户已登录进入门店-加购-去结算-微信支付-支付成功回跳生成订单状态待商家接单库存扣减支付流水存在AT-ORDER-002门店休息时下单被拦截测试门店设置为休息中进入门店菜单页面尝试加购下单菜单页提示休息中或加购按钮置灰无法进入结算AT-ORDER-003优惠券过期后不可用于订单用户有一张已过期优惠券结算页选择优惠券优惠券置灰并提示已过期或提交订单时报错AT-ORDER-004购物车商品数量达到上限购物车已有999件商品继续加购一件前端提示已达数量上限加购请求被拦截这四类用例分别覆盖了正常流程、业务规则、数据状态和边界值。写这类用例时有一个容易被漏掉的重点前端拦截了不等于后端不需要校验。暖食坊曾经有一段时间前端做了优惠券过期校验但后端接口没有判断直接提交订单仍然会成功。后来我在用例里加了一条“绕过前端直接调用接口提交过期优惠券”的用例才把这个问题拦住。功能测试用例不要只盯着页面上能看到的操作还要站在接口层考虑问题。2.3 等价类、边界值和场景法的实际用法测试用例设计方法在学校里都学过但实际用起来最容易跑偏的是为了用方法而用方法。拿暖食坊的“满30减10”优惠券来说等价类划分可以分成订单金额大于等于30、小于30、刚好等于30、加上配送费后满30。边界值要覆盖29.99、30、30.01这几个金额再加上折扣后出现两位小数的情况。这里有一个实际坑订单金额在很多情况下不是简单的商品总额可能有配送费、打包费、餐具费优惠券计算规则是“满多少减多少”到底满减的基数是商品总额还是含配送费总额需求文档如果没写清楚用例设计阶段就要找产品确认否则等到你写用例时会发现预期结果没法确定。场景法适合串流程尤其适合暖食坊这种多步操作场景。比如“用户领取优惠券-下单-支付-申请部分退款-退款到账后优惠券是否返还”这种跨模块场景单点功能用例覆盖不到。我把这类跨模块链路单独建了一张场景用例表每个场景用编号串联相关单点用例。这样设计出来的用例集才不是一堆孤立检查点而是能还原真实用户行为。2.4 需求变更时的用例维护暖食坊迭代速度不慢两周一个小版本很常见。需求一变用例不改用例库很快变成垃圾。我常用的做法是在用例Excel里加“关联需求ID”和“变更记录”两列。需求变动时我用需求ID反查用例把受影响用例标记为“待更新”更新完成后把版本号和变更人填进去。更重要的是需求变更后不仅手工用例要改自动化用例也要同步改否则就会出现自动化用例一直在跑旧流程根本不管新逻辑的情况。还有一个我踩过的坑线上线下用例不一致。线上出Bug后研发修复了代码但用例库里没有任何记录等下一个回归版本时同一个Bug又出现。后来我给自己定了个规矩任何线上事故修复后必须关联新增或修改一条用例并且这条用例要能覆盖当时的现场输入。这个动作看起来是增加工作量实际上是在给用例库持续补血。3. 测试用例Excel模板设计与工具对接3.1 小团队为什么不要一上来就平台化管理很多团队一提到测试用例管理第一反应是上一套平台。我之前也这么想但实际用下来发现三五个人的测试组、几十上百条用例时Excel的灵活度远高于平台。Excel可以随时加一列备注条件格式标出执行结果数据透视表统计用例分布打开就能改不需要权限申请。等团队大了、用例量上千了再迁到平台也来得及因为用例的字段结构在Excel里设计好了迁移只是数据搬运和字段映射的问题。暖食坊项目这个阶段我就坚持用Excel作为用例主存储。好处是评审的时候可以直接投屏修改不用在平台里反复点“保存-刷新-分享链接”坏处是多人同时编辑会冲突所以我在组内约定了一个分工用例由一个人统一维护其他人提修改意见由维护人合并。如果你实在需要多人一起编辑可以用在线表格但一定要约定好谁改哪张表不然同一条用例被两个人改出两个版本得不偿失。3.2 三张工作表的Excel模板我用的用例Excel模板不是一张表打天下而是三张工作表加一个命名规范。第一张是“模块注册表”列有模块ID、模块名称、负责人、需求版本。第二张是“用例明细表”列包括用例编号、用例标题、模块ID、优先级、用例类型、前置条件、测试步骤、预期结果、测试数据要求、关联需求ID、自动化脚本ID、维护人、最后更新时间。第三张是“执行记录表”列包括执行批次、执行人、用例编号、执行结果、实际结果、缺陷编号、执行环境、执行日期。这里重点说明三个容易被忽略的字段。用例类型字段要区分“功能”“接口”“自动化”因为同一个业务规则可能既有手工用例又有自动化脚本如果混在一起统计回归覆盖率时会算错。关联需求ID是需求追踪的锚点没有这个字段需求变更时就找不到受影响用例。自动化脚本ID则是把Excel用例和代码仓库里的脚本连起来的钥匙脚本ID可以简单约定成用例编号去掉前缀比如AT-ORDER-001就对应order_001.py这样两边对得上。3.3 把Excel用例迁移到Tessy等管理工具如果团队后续要用Tessy这类管理平台来做用例执行和结果追溯Excel用例的迁移质量直接决定平台上用例好不好用。我见过直接把Excel整表粘贴到平台里的做法结果是平台字段空了一半历史记录全丢。正确做法是先做字段映射把Excel里的用例标题对应平台标题前置条件对应前置条件预期结果对应预期结果Excel里多出来的测试数据要求和关联需求ID想办法映射到平台自定义字段不要直接丢弃。Tessy这类工具通常对用例格式有较严格的要求尤其是单元测试、接口测试场景它关心“输入值”“预期输出”“桩函数”这类字段。我们当时拿到工具模板后是先建了一条样例用例跑通之后再去批量导入。批量导入前还要检查Excel表头命名、Sheet页名称、日期格式这些细节错一个就可能导致整批导入失败。一个心得是迁移用例不是一次性的搬运迁移后要在新平台里重新执行一遍P0用例用执行结果来验证迁移质量而不是只看导入条数。4. Playwright在暖食坊测试中的自动化落地4.1 选Playwright而不是Selenium不是跟风暖食坊的自动化项目一开始就面临工具选型。我以前的自动化经验主要围绕Selenium它生态成熟踩坑案例多但有两个痛点解决不了等待时机要自己写很多Expected Conditions维护成本高跨浏览器兼容性测试需要单独配置DriverCI里很麻烦。后来对比了Cypress和Playwright我最终选了Playwright。原因有三点一是自动等待机制页面上元素出现前会自动等待我不用在脚本里塞一堆sleep二是选择器API直观按钮直接按文本、输入框按Placeholder不需要维护一长串XPath表达式三是内置了多浏览器和移动端模拟暖食坊商家后台主要跑Chrome但用户端还有小程序WebView场景这套能力省了不少事。必须说一句公道话Playwright不是银弹。它默认跑在自己的进程里与浏览器交互的方式和Selenium不太一样如果你们团队已经有成熟的Selenium基础设施和大量脚本迁移成本不一定划算。我的建议是新项目直接选Playwright老项目别冲动重构。暖食坊是从零开始搭自动化所以Playwright是很自然的选择。4.2 什么手工用例值得转自动化手工用例不是越多转自动化越好这是我在暖食坊项目里花了两个月才真正想明白的事。我自己的筛选标准有三条一是主流程和回归频次高的用例比如登录、下单、支付、退款这些每次发版都要跑自动化价值最大二是跨页面数据传递复杂的链路比如商家接单后订单状态在用户端同步变化这类场景人工点起来容易看漏自动化反而稳三是需要大量重复数据的用例比如批量创建10个订单再验证列表分页手工执行既慢又无聊。不适合自动化的用例也清清楚楚需要人工看图判断的视觉类用例比如UI样式、海报图是否美观依赖真实第三方服务的用例比如真的去调用微信支付或真实地图定位还有一次性探索性测试。这类用例我保留在手工回归包里。判断标准就一句话这个用例如果跑100次结果都一样且不需要人做主观判断才值得自动化。4.3 PO模式脚本实现与执行稳定性暖食坊的自动化脚本我采用了Page Object模式把页面定位和业务操作封装成类用例脚本只做业务编排。下面这是下单主流程的简化示例用的是Python Pytest Playwrightdef test_create_order(page): login_page LoginPage(page) login_page.goto() login_page.login(at_qa_user, Test123) store_page StorePage(page) store_page.search_store(AT-测试门店) store_page.enter_store() menu_page MenuPage(page) menu_page.add_dish(招牌脆皮鸡饭, 1) cart_page CartPage(page) cart_page.go_to_checkout() order_page OrderPage(page) order_page.submit_order() assert order_page.order_success_text() 支付成功代码本身不难难的是让这套脚本稳定跑下去。我踩过的坑主要有四个选择器退化、登录态重复损耗、依赖数据不隔离、断言太弱。选择器退化用代码修登录态优化方式是用Playwright的storage_state来复用登录信息不要每次用例都走一遍登录流程依赖数据不隔离就通过API或数据库造专属测试数据断言太弱则在每个步骤后写具体的状态断言比如订单号存在、库存减少。执行稳定性的另一个关键是环境独立性。暖食坊的自动化脚本在本地跑和CI跑结果经常不一致一开始我以为脚本写坏了排查了很久发现是CI环境没有预设门店营业状态。后来我把所有依赖环境的数据准备全部挪到测试Setup里面脚本启动时先通过接口把门店状态、菜品库存调成预期值跑完再清理。这样脚本和环境是解耦的拿到任何环境都能跑。4.4 报告、通知与用例库联动执行完自动化只是第一步结果要能被团队看到才有价值。我给暖食坊自动化接上了Allure报告跑完自动上传失败用例自动对应截图和页面状态。同时在CI流水线里设置一个步骤失败时把相关用例编号回填到Excel执行记录表这样手工用例库和自动化结果是一份数据不靠人肉同步。这里的一个关键设计是用例ID在自动化脚本和Excel里保持一致。报告里出现失败我能根据用例ID在Excel表里定位到对应的用例、数据和历史执行情况。没有这个关联自动化报告做得再漂亮也只是一堆孤立的成功失败数字。5. 常见问题与排查技巧实录5.1 执行失败最容易被忽略的三类原因用例执行失败时第一反应通常是“我有Bug”但实际排查下来绝大部分失败来自三类问题。第一类是环境状态不对比如测试门店打烊、优惠券被领完、依赖服务没起这类失败往往批量出现特征是很多用例同时挂。第二类是测试数据被污染比如前一个用例没有清理订单数据后一个用例断言订单列表里只有一条记录时失败。第三类是脚本或用例自身问题选择器写死、步骤顺序有误、断言过强。我发现很多团队没有把这三类失败分开统计导致明明是环境问题却让开发在代码里翻了半天的低效情况。我的排查习惯是失败发生后先看是不是批量失败批量失败直接查环境单条失败则先复跑一次能复现再看具体步骤和断言不能复现多半是数据污染或时序问题。为了减少排查时间我在每个自动化用例的失败截图里都加上执行批次号和环境标识一看截图就能知道是哪个环境、哪次执行出的问题不用再去猜。5.2 别让用例库变成“全绿空转”用例库最危险的信号不是有失败而是长期“全绿”。全绿意味着两个可能要么系统真的没有问题要么你的用例已经失去发现问题能力。我在暖食坊项目里做过一次自查把自动化断言挨个打开看发现很多断言只写了“页面没有报错”或“按钮存在”这些断言根本发现不了业务错误。比如断言“加购成功”用的是页面Toast出现但Toast出现并不代表购物车数据正确。真正的验证要落到数据上。下单后去查接口返回的订单号、去数据库看库存字段变化、支付完成后再去商家端看订单状态同步。写用例的时候每一条断言都要自问一个问题如果系统逻辑错了这条断言能不能把它揪出来如果答案是不能这个断言就是死的。宁可少一些“能跑通”的用例也要保住每条用例能真正暴露问题。5.3 用例维护的节奏最后说说维护节奏。暖食坊项目里我每隔两周到一个月会做一次用例体检主要做四件事清理已经失效的用例合并重复覆盖的用例检查自动化覆盖率有没有往下掉把线上故障新增的用例归位到正确模块。这个节奏不重但能保证用例库始终是活的。另一个经验是回归用例集要分三层冒烟集每天跑、核心集发版前跑、全量集大版本跑。分层跑才能平衡成本和收益否则每天跑全量等用例量大了团队一定坚持不住。我实际踩过的坑是一开始把全量用例都塞进冒烟集结果每次几分钟变成几十分钟大家执行意愿越来越低最后连主流程都漏测。后来强制把冒烟集限制在20条以内效果立竿见影。做暖食坊这套测试用例我最深的体会其实是一份好用例不是写出来的是长出来的。从第一次需求评审时的几十条主流程到后来覆盖各种边界和异常场景的完整用例库中间靠的是一次次线上事故复盘、一次次自动化失败排查、一次次需求变更同步。如果你现在也在维护一套用例库不妨先把手里的用例翻出来挑几条P0看看断言能不能发现问题或者检查一下刚刚修复的线上Bug是不是已经有对应用例了。有时候用例库的优化就是从这么一个小动作开始的。