企业官网建设流程全解析

先说个我经历过的事。前两年有个团队找我帮忙复盘自动化测试项目，他们用例写了上千条，但每次跑完报告一片红，点开一看，一半不是功能挂了，而是数据被别个用例改了、元素等不到、断言写得太脆。到最后，大家都不看这个报告了，自动化测试就变成了一个“每天定时失败”的仪式。这不是个例。很多人第一次接触自动化测试，第一反应就是把手工用例一条条“翻译”成脚本，觉得自动化测试用例就是“手工用例的代码版”。但真正跑起来才发现，这两者的设计逻辑完全不一样。

自动化测试用例不是把步骤写成代码就完事，而是一套“可重复执行、结果可判断、失败了能快速定位”的测试策略载体。它的核心价值是用机器的时间换人的时间，用稳定可靠的回归能力守住核心功能。换句话说，它不追求“覆盖全部”，而追求“每一分维护成本都花在刀刃上”。

这篇内容就是围绕“自动化测试用例到底要怎么写”展开的。我会从顶层设计思路、场景拆分方法、实际落地时最容易出问题的细节，到怎么用 AI 辅助生成用例、常见问题怎么排查，一次性把这些年的实战经验都倒出来。适合刚接触自动化测试的新人，也适合已经在写脚本但觉得维护成本越来越高的中级工程师。

1. 动笔之前，先把测试策略想清楚

1.1 到底哪些用例适合做自动化

我以前也犯过“什么都想自动化”的毛病。后来被现实教育了几次才明白，自动化测试不是取代手工测试，而是把手工测试里那部分最重复、最稳定、最费时的验证工作接过来。判断一个用例适不适合自动化，我一般看四个维度：是否高频回归、是否业务关键、是否结果可精确判断、执行环境是否稳定。

适合自动化的典型用例包括：核心业务流程的冒烟验证、跨版本回归的功能点、需要大量数据组合的参数化场景、接口层面的契约校验、需要每次发布前反复执行的检查项。不适合自动化的场景则往往是：探索性测试、一次性的临时性验证、依赖大量主观视觉判断的界面体验检查、极少执行且业务逻辑变动极快的临时功能。

我建议用一个最简单的标准来过滤：如果这个用例三个月内你至少会手动跑十次，那就值得考虑自动化；如果一年都跑不了一次，别折腾了，写成自动化就是给团队埋雷。下面这个表是我平时用来判断“要不要自动化”的快速参考：

1.2 优先级分层：自动化测试不是越全越好

“最全”这个说法其实是个陷阱。真正的“全”，指的是对核心业务风险的覆盖够全，而不是用例数量上的堆砌。我习惯把自动化用例分成 P0、P1、P2 三层。P0 是冒烟级用例，必须全绿，跑挂了发布流程就要停；P1 是核心业务回归，要求高稳定、低误报；P2 是功能细节和边缘场景，容忍一定程度的波动，但也要有淘汰机制。

我见过一些团队的自动化用例库只有“增量”没有“减量”，用例越加越多，维护成本像滚雪球一样膨胀，但实际跑出来的价值并没有等比例增加。原因很简单：每一条自动化用例都包含定位器、数据、断言、等待逻辑四部分，每一步都可能因为产品变化而失效。所以我在评审自动化用例时，一定会问三个问题：这条用例半个月后还有价值吗？如果失败了，能精准指出是哪个功能坏了吗？维护它的成本是它捕获缺陷概率的多少倍？回答不了就直接砍掉，这不是浪费，是在控制负债。

1.3 顶层设计的三条路线：数据驱动、关键字驱动、行为驱动

自动化测试用例写到一定规模后，真正比拼的就不再是单条脚本多漂亮，而是整体架构多抗造。目前业界用得比较多的三条路线，分别是数据驱动、关键字驱动和 BDD（行为驱动开发）。简单说，数据驱动是把“测试数据”和“操作逻辑”分开，一套脚本跑多组数据；关键字驱动则是把“打开页面”“输入内容”“点击按钮”“断言结果”这些动作抽象成关键字，用表格或配置文件组合成用例；BDD 则是用接近自然语言的格式描述行为，典型工具是 Cucumber。

选哪条路线没有绝对对错，得看团队的组成。如果团队里大部分是测试开发能力一般的业务测试同学，关键字驱动会更友好；如果团队里人人能写代码，数据驱动配合 PO 模式最灵活。我个人的习惯是：UI 自动化优先用 PO 模式加数据驱动，接口自动化优先数据驱动加契约测试，BDD 用于跨部门协作的场景，让产品和开发都能看懂用例在做什么。不管选哪条，核心目标都一样——用例的维护成本要低于手工回归的成本，否则自动化就没有存在意义。

2. 把业务场景拆成可自动化执行的用例

2.1 从需求文档到测试场景的拆解方法

很多人在写自动化测试用例的时候，习惯直接打开页面，照着操作路径开始录脚本。这种方式不能说错，但写出来的用例往往只能覆盖“happy path”，一遇到数据变化或异常流程就不行了。更靠谱的做法是先回到需求本身，把业务逻辑拆成可验证的场景，再把场景映射到自动化脚本上。

具体操作是：拿到需求之后，先列主流程，再列分支流程和异常流程。比如一个电商下单功能，主流程就是“搜索商品→加购→去结算→提交订单→支付成功”；分支包括优惠券抵扣、多地址切换、修改数量；异常包括库存不足、支付超时、接口返回错误码。每个流程都要明确前置条件、触发操作、期望结果。拆完之后再筛一遍，把适合自动化的场景挑出来，排好优先级。

举个例子。刚做接口自动化时，我喜欢盯着一个接口反复造参数来测，后来发现真正容易出问题的往往是多个接口串联起来的交互场景。比如“下单”这个接口本身没问题，但从“加购”到“提交订单”之间，如果中间态的 token 过期或库存状态不一致，整个流程就挂了。所以在场景拆解时，不要只站在单接口或单页面的视角，要用一条完整的用户操作链去走一遍，才能真正模拟出线上用户的使用体验。

2.2 自动化测试用例的基本结构模板

不管是用 Python、Java 还是其他语言，自动化测试用例的数据结构其实非常固定。一个完整可维护的用例，至少要包含以下要素：用例编号、所属模块、用例名称、优先级、前置条件、测试数据、操作步骤、预期结果、断言方式、依赖关系。把这些字段用表格管理起来，无论写脚本还是写文档，都不会乱。

我平时在项目里用的用例模板是这样的：

这个模板最大的价值不是格式好看，而是逼着你在写脚本之前就想清楚：这条用例需要什么样的数据环境？期望结果怎么验证？如果断言失败，是功能真坏了还是用例自身的问题？想不清楚这些，后面写出来的脚本大概率是跑得通但测不准的“假自动化”。

2.3 用例命名：看到名字就该知道测什么

命名这件事看着小，实际影响很大。自动化用例一旦超过一百条，靠名字检索就成了最常用的定位手段。我见过大量命名成 test_1、test_login、check_user 的用例，跑挂了查半天都不知道是哪个场景出了问题。好的命名应该是一个“可读的断言”，比如test_login_success_with_valid_credentials、test_add_item_to_cart_then_remove_it、test_checkout_with_expired_coupon。

命名规范还有个隐形的好处：它会强制你把业务维度拆得更细。因为只有场景拆得足够单一时，你才能用一句英文把用例目的写清楚。如果一个用例名字里出现了“and”和“then”好几个连接词，说明这条用例塞了太多逻辑，建议拆开。我在评审用例时会直接抽查命名，从命名基本就能判断这个团队的用例设计水平。

3. 从设计到脚本落地，真正绕不开的细节

3.1 元素定位和等待机制：稳定性的第一道关口

UI 自动化里最经常报的错就是找不到元素，报错信息千篇一律地写着NoSuchElementException。刚开始写用例的时候，我以为是定位表达式写错了，后来排查多了才发现，一半以上的情况是元素还没渲染出来脚本就去点击了，另一半才是表达式写得不准确。解决这个问题，核心既不是换一个更聪明的定位器，也不是盲目加等待，而是把“显式等待”变成标配。

显式等待的意思是用代码主动等待某个条件成立，比如元素可见、可点击、文本出现，再继续下一步。相比无脑用time.sleep(3)，显式等待更快也更稳，页面加载快了不会浪费时间，加载慢了也不会误报。在 Selenium 里我会封装一个通用方法，比如wait_for_element_clickable，所有用例统一调用，而不是每个用例各写各的等待逻辑。这样遇到因等待不够导致的偶发失败，只需要在一个地方调整参数，不用满项目找。

元素定位本身也有讲究。我一般不推荐用绝对路径或者拿一连串的 HTML 结构来做定位，因为页面布局稍微一调就全挂了。更稳的做法是优先用 id、data-testid 这类业务标识，其次是稳定的 CSS 选择器和相对定位，最少依赖文本内容去定位。为什么？文本往往是会变的，今天显示“提交订单”，明天为了转化率改成“立即支付”，你的脚本就得跟着改。现在不少前端团队已经习惯在关键控件上增加>import requests import pytest def test_create_order_with_valid_stock(): # 准备数据 payload = { "user_id": "u_10001", "product_id": "p_8888", "quantity": 1, "coupon_id": "" } # 执行下单接口 resp = requests.post("https://api.test.com/order/create", json=payload) order_data = resp.json() # 断言一：HTTP 状态码 assert resp.status_code == 200 # 断言二：业务状态码 assert order_data["code"] == 0 # 断言三：订单核心字段 assert order_data["data"]["order_status"] == "pending_payment" assert order_data["data"]["total_amount"] == 1999 # 断言四：数据库落库一致性（假设已封装 db 模块） db_order = db.query_order(order_data["data"]["order_id"]) assert db_order["order_status"] == "pending_payment" assert db_order["total_amount"] == 1999

UI 自动化的断言其实也有层次。最弱的是断言元素存在，最强的是断言完整的业务状态。比如一个“用户修改密码”的用例，只断言“保存成功”弹窗出现是不够的，最好再用新密码走一遍登录接口，确认密码真的改掉了。所谓“测试用例测的是业务，不是界面”，就是这个意思。

3.4 可读性和维护性：给三个月后的自己写代码

自动化测试脚本表面上是给机器执行的，本质上却是给人维护的。我经常提醒团队：“你现在写的每一条用例，三个月后大概率是你自己来改。”来想想那个场景，如果脚本里全是driver.find_element(By.ID, "xxx")这种裸代码、没有任何注释、变量名全是 a、b、c，到那时候你还能看懂它在测什么吗？所以从第一天开始，我建议就用工程化的标准来要求测试代码。

具体来说，第一要素是命名可读，不用多说；第二要素是页面对象和公共方法要下沉，不要在用例里堆细节；第三要素是日志要做好。至少要在关键步骤处输出日志，比如“正在执行登录操作, 用户: xxx”，这样用例跑挂了，你可以根据日志快速定位是卡在登录、下单还是支付环节。接口自动化里我还习惯在断言失败时打印请求参数和返回报文，这个信息帮助我在排查问题时节省了大量时间。

还有一点容易被忽视：用例之间的独立性。自动化测试用例最好是互不依赖的，能独立运行也能独立失败。如果用例之间存在隐式的执行顺序依赖，一旦中间某条挂了，后面的用例全都会跟着挂，排查起来一头雾水。现在测试框架普遍支持依赖控制或者按顺序执行，但我的建议是尽量保持用例的独立性，把公共的前置操作放到 fixture 里，而不是上一条用例的“尾巴”里。

4. 进阶玩法：让 AI 帮你跑通“从需求到用例”的最后一公里

4.1 AI 在自动化测试里的真实边界

这几年 AI 辅助测试的热度非常高，像“AI自动化测试平台搭建”“LangChain自动生成测试用例”“自己搭建Agent进行自动化测试”这些方向，已经有不少团队在尝试。我自己也实践过一段时间，说点真实感受：AI 在自动化测试里最擅长的不是“全自动跑测试”，而是把那些本身就有清晰规则的重复性工作自动化掉。比如根据接口文档生成参数化测试用例、根据需求描述生成场景化的用例初稿、把自然语言转成测试步骤、辅助推荐合适的元素定位表达式。

真正需要人来做的，是业务逻辑的梳理、边界条件和异常场景的设计，以及 AI 生成内容的筛选与验证。理解了这一点，就不会对 AI 有过高期待，也不会问出“AI 能不能完全替代手工测试”这种没有意义的问题。它更像一个特别擅长草拟框架的助手，而不是一个能直接负责质量的同事。

4.2 用 LangChain 生成测试用例的实践思路

我看很多文章讲“LangChain 自动生成测试用例”，听起来很玄，拆开看其实就是一个流程：把需求文本或接口定义喂给大模型，通过提示词模板让它输出结构化的测试用例，再通过脚本把输出的内容转成测试代码或测试用例表格。中间可以不用 LangChain，直接调大模型 API 也行；但 LangChain 这种框架提供了一个相对标准化的链路，方便你管理提示词、解析输出结果和做后处理。

实际操作大概分四步。第一步，准备输入数据，可能是接口文档的 JSON 结构，也可能是需求描述文本；第二步，设计提示词模板，明确让模型输出什么格式、包含哪些字段；第三步，调用模型生成结果，解析成结构化的 JSON；第四步，人工审核并落成标准的测试用例文档或可执行的测试数据文件。我试过一个例子，给模型一个登录接口的字段定义，让它生成“用户名、密码、验证码”的组合测试用例，包括必填校验、长度校验、特殊字符、错误密码、正确密码等场景，生成速度很快，覆盖的常规场景也比较全。

提示词模板可以很简单，下面是一个参考思路：

你是一名资深的软件测试工程师。请根据以下接口信息生成测试用例。 接口名称：登录接口 请求方式：POST 请求参数：username: 字符串, 必填; password: 字符串, 必填; captcha: 字符串, 必填 业务规则：用户名和密码正确则登录成功；密码连续错误5次后账号锁定；验证码有效期5分钟。 请输出 JSON 数组，每个元素包含：case_title, preconditions, steps, expected_result, priority 五个字段。

生成的输出虽然不一定能直接用，但至少把一套常规用例的骨架搭好了。需要人审的通常是两点：一是业务规则相关的边界条件有没有漏，二是期望结果是不是真的符合产品逻辑。这两个点恰好是大模型最容易一本正经胡说八道的地方。所以我的经验是：AI 负责写“面”，人负责补“点”。这样效率提升非常明显。

4.3 自己搭建 Agent 做自动化测试的实践建议

再进一步，不少人开始尝试让 Agent 自动执行“理解需求→编写用例→执行测试→收集结果→给出结论”的闭环。这个方向很吸引人，但以我目前的实践经验，完全无人值守的自动化 Agent 在绝大多数团队里还不靠谱，比较可行的路径是“人机协同的半自动流程”。什么意思？就是用 Agent 去完成用例生成、脚本草稿、失败日志初筛这几类相对机械的环节，但关键的用例设计评审、断言逻辑确认、失败结果判定，仍然需要人来把关。

比如在小程序或 Web 应用里，用 AI 辅助自动化测试的典型流程可以是：输入一个功能描述，AI 生成一套测试场景列表→测试工程师挑选并调整场景→AI 把已确认的场景生成对应的测试脚本骨架→工程师补充断言和业务数据→执行后 AI 自动汇总失败日志并推断可能原因→工程师做最终定位和修复。每一步里 AI 都在做事，但每一步都有人类确认的节点。这样既发挥了大模型擅长的文本生成和理解能力，也避开了它在真实业务判断上的短板。

最后提醒一句：用 AI 生成测试脚本时，定位器、等待逻辑、数据隔离这些工程化约束依然存在。AI 写出来的代码同样要遵循 PO 模式，同样要显式等待，同样不能把测试数据写死。所谓“AI 自动化测试”，本质上是把工程化积累的规范交给模型去执行，而不是让模型另搞一套不讲规矩的脚本。

5. 常见问题与排查技巧实录

5.1 自动化用例执行不稳定的排查表

自动化用例跑起来不稳定，是几乎每个测试团队都会遇到的事。这里我把平时归类过的高频问题、常见原因和排查思路整理成一个速查表，方便大家在实际工作中对照排查：