企业官网建设流程全解析

最近在盘点暖食坊项目测试资产的时候，我又把从需求评审到上线回归这一路的测试用例完整过了一遍。暖食坊不是一个简单的点餐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 下单核心链路用例拆解

暖食坊最核心的链路是“选菜-加购-提交订单-支付-生成订单-商家接单-配送或取餐”，这条链路用一个用例覆盖往往不够，要拆成多条。这里举几条有代表性的用例，编号习惯是“模块-场景-序号”：

这四类用例分别覆盖了正常流程、业务规则、数据状态和边界值。写这类用例时有一个容易被漏掉的重点：前端拦截了不等于后端不需要校验。暖食坊曾经有一段时间前端做了优惠券过期校验，但后端接口没有判断，直接提交订单仍然会成功。后来我在用例里加了一条“绕过前端直接调用接口提交过期优惠券”的用例，才把这个问题拦住。功能测试用例不要只盯着页面上能看到的操作，还要站在接口层考虑问题。

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，维护成本高；跨浏览器兼容性测试需要单独配置Driver，CI里很麻烦。后来对比了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 + Playwright：

def test_create_order(page): login_page = LoginPage(page) login_page.goto() login_page.login("at_qa_user", "Test@123") 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是不是已经有对应用例了。有时候，用例库的优化就是从这么一个小动作开始的。