自动化测试用例编写指南：六大设计准则与实战排查经验

写自动化测试用例这事儿，说难不难，说简单也真不简单。我见过太多团队，框架搭得挺唬人，用例也写了好几百条，结果跑起来全红，或者今天能过明天就挂，最后沦为天天修脚本的苦力活。问题出在哪儿？十有八九不是代码水平不行，而是用例本身的设计没做对。这就像盖房子，框架是钢筋，用例就是砖头，砖头要是歪的，楼早晚得塌。

这篇内容我围绕“自动化测试用例编写”这个主题，把我在实际项目中踩过的坑、总结的经验、验证过的方法全部梳理一遍。不管你是刚接触自动化的新手，还是已经被脚本稳定性折磨了半年的老手，这篇文章都值得你花十分钟看完。我不会讲虚的，全是能直接落地的思路和写法。

1. 用例设计的第一步：先搞懂“为什么写”而不是“怎么写”

很多人一上来就埋头写脚本，这是个致命误区。自动化测试用例不是把手工用例翻译成代码就完事了，它是一个有生命周期的产品，需要先想清楚定位和边界。

1.1 自动化用例要解决的核心痛点

手工测试最大的问题是什么？是重复劳动和回归成本。你发一个新版本，核心流程全要手工过一遍，点几十个按钮，填十几张表单，一天就没了。自动化的核心价值就是把这种重复性极高的操作交给机器，把测试人员的时间解放出来做更有价值的探索性测试、复杂场景设计、结果分析。

所以我每次接到自动化用例编写任务，第一件事不是打开IDE，而是先问三个问题：

• 这套用例是给谁用的？是给研发做冒烟测试，还是给测试团队做全量回归？
• 哪些场景最适合自动化？哪些场景自动化投入产出比极低？
• 用例跑挂了之后，由谁来分析、怎么快速定位？

这三个问题直接决定你的用例设计风格。如果是做冒烟测试，用例数量不在多，而在精，核心链路必须全覆盖；如果是做全量回归，那就要考虑用例的独立性、执行顺序、数据隔离这些更深层的问题。

1.2 自动化用例的适用范围：什么该写，什么不该写

我在实际项目里总结了一个比较实用的筛选标准，用来判断一个用例是否值得自动化：

• 执行频率高：每个版本都要回归的用例，值得自动化
• 数据准备复杂：需要构造大量测试数据的场景，值得自动化
• 人工验证易出错：涉及大量数值计算、文案校验、跨系统数据比对的场景，值得自动化
• 稳定性差、环境依赖强：比如依赖第三方服务偶尔挂掉的场景，不适合早期自动化
• 纯视觉验证：需要人眼判断界面美观度、布局是否合理的场景，不要自动化，投入产出比太低
• 一次性探索：开发阶段快速验证某个功能是否实现的用例，不要自动化

判断标准就一句话：如果一个用例跑一百遍都是同样的操作和预期，那它就该自动化；如果一个用例每次跑都需要人临场判断、随机应变，那它就不该自动化。

2. 高质量自动化用例的六大设计准则

好用例和烂用例的差距，不体现在语法上，而体现在设计上。下面这六条准则是我在多个项目里验证过的，照着做，你的用例稳定性至少翻一倍。

2.1 用例独立性是命门，必须做到互不依赖

我见过最惨烈的自动化项目，就是用例之间有强依赖关系。先登录、再创建订单、再支付订单、最后校验订单状态，一条龙串着跑，一旦中间某个环节挂掉，后面全线崩溃。

正确的做法是每个用例都是独立的个体，能单独跑、能乱序跑、能重复跑。这要求你做到：

• 前置数据通过API或数据库准备，而不是依赖前一个用例的执行结果
• 每个用例自己的数据自己清理，不留垃圾数据给下一个用例
• 用例之间不共享页面状态，每个用例开始前都回到初始状态

举个例子，如果你要测下单流程，不要写“先登录然后下单然后验证”，而是要拆成“通过API预置登录态，然后直接打开下单页，验证下单功能”。这样即使登录模块挂了，下单流程的用例还能正常执行，问题定位也更精准。

2.2 可读性是长期维护的基础，写给人看而不是写给机器看

自动化用例不仅仅是脚本，更是一种测试资产的沉淀。三个月后你回头看自己写的用例，如果看不明白当初的意图，那这代码就是负资产。

我建议遵循一套命名和结构规范：

• 用例名称必须包含“模块_操作场景_预期结果”三段信息，比如login_success_with_valid_account
• 用例内部按 Arrange（准备）、Act（操作）、Assert（断言）三段式结构组织，一眼就能看懂每一步在干什么
• 页面元素定位符统一抽取到单独的文件管理，不要把选择器散落在各个用例里

关于元素定位，我特别强调一点：**优先使用可读性强的定位策略，比如># 伪代码：等待某个条件成立后才继续执行 wait.until(expected_conditions.visibility_of_element_located(locator)) # 伪代码：等待接口响应稳定后再进入断言 wait.until(lambda driver: driver.execute_script("return document.readyState") == "complete")

在执行速度和稳定性之间做取舍时，我永远倾向稳定性。测试环境又不是生产环境，多花十秒八秒根本不痛不痒，但一个红彤彤的失败报告需要你花半小时去排查，那才叫真浪费。

2.6 失败信息必须可读，报错要让人一眼知道问题在哪

写用例的时候，多想想“如果这个用例挂了，看报告的人能不能在三秒内知道问题出在哪里”。这个原则看着小，实际体验差别巨大。

我常用的几个做法：

• 在关键步骤添加自定义步骤日志，让报告呈现操作过程
• 在失败时自动截图并附加到报告，UI类用例必须截图，这是铁律
• 失败信息写明预期值和实际值的差异，而不是只给一个难懂的异常堆栈
• 对常见的环境问题（比如网络超时、环境未启动）做单独的异常捕获，给出“环境问题请恢复环境后重试”之类的提示，而不是让使用者对着一个 timeout 的错误猜半天

网上很多团队抱怨自动化测试没人愿意维护，很大一部分原因就是用例失败后分析成本太高。把失败信息的可读性做好了，维护成本至少降低一半。

3. 自动化用例的实现：从手工用例到可执行脚本的完整拆解

通篇讲理论不给实操就是耍流氓，这一节我用一个非常典型的场景——用户登录——来完整拆解用例实现全流程。虽然登录看起来简单，但它麻雀虽小五脏俱全，自动化用例该考虑的元素基本都有。

3.1 第一步：手工用例怎么转成自动化用例

手工用例和自动化用例之间有个思维转换过程，不能照搬。手工用例的步骤是人来执行，机器没有判断能力，所以你要把步骤拆得更加机械、更加明确。

就登录而言，手工用例可能是这样的：

但自动化用例的逻辑就要重排了，核心是确定前置条件、数据来源、操作步骤和检查点的机械定义：

• 前置条件：测试账号已存在，密码正确，系统可访问
• 数据来源：从数据驱动文件中读取多组测试数据
• 操作步骤：打开登录页、输入用户名、输入密码、点击登录
• 检查点：当前URL变化、页面显示用户名
• 异常处理：等待元素超时后截图，表示用例失败
• 数据清理：退出登录，恢复环境

看到区别没有？手工用例靠人脑灵活处理，自动化用例需要把所有可能的分支走向都设计清楚。

3.2 第二步：从零搭建一个可落地的登录用例脚本

这里我用Python加Selenium的经典组合，给一个完整可运行的示例。你不用照抄代码，重点看结构和设计思路。

import pytest from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class TestLogin: # 测试数据通过参数化注入 @pytest.mark.parametrize("casename, username, password, expected_text", [ ("success_with_valid", "test_user", "Test@12345", "test_user"), ("fail_wrong_password", "test_user", "wrong", "用户名或密码错误"), ("fail_empty_username", "", "Test@12345", "请输入用户名"), ]) def test_login(self, casename, username, password, expected_text): # Arranged: 准备阶段 self.driver = webdriver.Chrome() self.driver.get("https://your-test-env.com/login") # Act: 操作阶段 username_input = self.driver.find_element(By.ID, "username") password_input = self.driver.find_element(By.ID, "password") submit_btn = self.driver.find_element(By.ID, "submit") if username: username_input.send_keys(username) if password: password_input.send_keys(password) submit_btn.click() # Assert: 断言阶段 if casename == "success_with_valid": WebDriverWait(self.driver, 10).until( EC.visibility_of_element_located((By.CSS_SELECTOR, ".user-info")) ) assert expected_text in self.driver.page_source else: WebDriverWait(self.driver, 10).until( EC.visibility_of_element_located((By.CSS_SELECTOR, ".error-msg")) ) assert expected_text in self.driver.find_element(By.CSS_SELECTOR, ".error-msg").text self.driver.quit()

这个脚本的骨架结构几乎可以直接套用到任何UI自动化用例上。三个用例共用同一套操作逻辑，只通过参数化传入不同的输入和期望值，要扩展新用例？加一行参数就行。

3.3 第三步：数据准备与数据清理的精细设计

用例执行前的数据准备，我见过五花八门的写法。最差的做法是在用例内部手动画界面创建数据，耗时且不稳定。比较好的做法有三种，按优先级排列：

1. 通过API直接造数：被测系统如果有管理后台API或内部接口，直接调用创建测试数据，最快也最稳定
2. 直连数据库插入：对于不太好走接口的数据，可以直接操作数据库预置。但注意要走独立的事务，测完要回滚或清理
3. 通过UI创建：实在没办法才用，一般用于测试数据创建功能本身的用例

清理策略上我遵循几个约定：

• 每个用例自己产生的数据自己负责清理，不依赖全局清理脚本
• 使用测试账号时，数据尽量隔离在特定的测试标识符下（比如用户名统一加autotest_前缀），方便批量识别和清理
• 必须在测试环境清理，生产环境飘数据就麻烦了

再分享一个我常用的技巧，创建测试数据时就在测试用例里记录数据ID，清理的时候直接用这个ID定向删除。这比全表扫描快得多，也不会误删其他用例的数据。

3.4 第四步：用例执行顺序与重试机制的设计

不要完全相信框架默认的执行顺序。当你有多个用例文件时，要显式地控制执行策略。Pytest这类框架默认按文件名的字母序执行，如果你有“先注册后登录”这类天然的场景顺序，要么把用例拆开变成独立用例，要么用依赖注入的方式显式调用。

重试机制是个好东西，但要用得克制。我在实践中总结了一条经验：不要全局开启自动重试，而是针对特定类型的问题重试。

适合重试的情况：

• 网络抖动导致的加载失败
• 第三方依赖服务偶发超时
• 前端资源加载缓慢但最终可以加载完成

不适合重试的情况：

• 业务断言失败（说明功能真的有bug，重试也不会过）
• 数据错误导致的功能异常（重试只会浪费更多时间）
• 界面元素定位失败（如果是选择器写错了，重试一万次也没用）

我一般这样处理：业务断言失败直接FAIL，重试标记为“环境不稳定”的异常类型，通过装饰器或监听器实现针对性的重试。这样可以避免真正的问题被重试掩盖成“误报”。

3.5 第五步：日志与报告——让自动化结果真正可用

自动化跑完了不能只看一个执行结果百分比。要看得懂用例为什么失败、在哪一步失败的、是环境问题还是功能问题，所以日志和报告这两块必须投入精力做好。

我个人的规范是这样：

• 每个用例的关键操作步骤，用统一的日志格式输出，比如【点击登录按钮】,【等待订单列表加载】
• 步骤日志附带时间戳，方便定位是否有长时间停顿
• 断言失败时，捕获当前页面HTML和截图，HTML用._source类似的接口拿，截图用驱动自带方法
• 重试的用例，在报告中标注清楚是第几次执行通过的，让维护人员心里有数

报告工具可以选现成的。Python圈子用Allure比较多，报告界面确实漂亮，失败截图展示直观看得出来；如果不想引入太重的东西，pytest-html也够日常用。但不管用什么，保证“打开报告就能知道问题大概是哪类”才是真正的目标。

4. 自动化用例编写常见问题与排查实录

这一节我列几个在实际项目里几乎天天遇到的高频问题，把排查思路完整写出来。这些问题在官方文档里找不到答案，全靠踩坑积累。

4.1 用例偶发失败：昨天还绿的，今天怎么红了？

偶发失败是最让人火大的问题，因为重跑它又过了，你不重跑，它就在那边挂着红彤彤的报告。根据我的经验，偶发失败的原因大致集中在这几个方向：

• 等待不充分：页面还在加载中，代码已经去找元素了。排查方法看失败截图，如果是NoSuchElementException且截图显示元素未加载完成，基本就是等待策略问题
• 环境资源不足：测试环境没重启，内存泄漏导致响应变慢。排查方法是看日志时间戳，如果整个用例执行时间比平时慢了几倍，大概率就是这个
• 数据冲突：两个用例的数据在库里面互相影响。排查方法是在失败用例的时间点前后，去数据库查有没有其他测试用例使用同一份数据

解决偶发要先解决稳定性，把等待全部改成显式等待，然后把数据冲突的可能性去掉（用互不干涉的测试数据），最后如果是环境问题就加一层“环境探活”操作，用例启动前先探测页面是否可以正常访问。

4.2 定位不到元素：按下F12明明看的到，脚本就是找不到？

这类问题的根源基本都是动静之争。你用F12在已经渲染完毕的页面上看到元素，但脚本执行到那一步时，元素可能还没渲染完成，或者压根没有进入当前页面状态。

排查顺序我建议是这样的：

• 看失败截图，确认脚本执行到什么位置
• 查看日志里操作步骤，确认是否已经进入目标页面
• 用浏览器开发者工具确认元素是否在iframe里，这是一个特别容易踩的坑
• 确认选择器是否有唯一性，是不是页面上存在多个相同元素

对于iframe里的元素，需要在定位前先切换上下文，这是新手最容易忽略的。iframe的自动化有个铁律：先进去、操作完、必须切出来，否则下一步操作会全部失效。

4.3 环境切换导致全盘皆崩：本地能过，跑在CI上全挂

这种问题通常是自动化环境配置不一致导致的。本地浏览器版本和服务器上的版本不一致、屏幕分辨率不同导致元素位置变化、服务器没有外网访问权限导致字体或第三方库加载异常。

我建议这样做：

• 浏览器和驱动版本在项目初始化时固定住，把版本号写进依赖文件里锁死
• 涉及滚动或坐标操作的用例，优先使用JS注入的方式执行，不要依赖页面尺寸
• 服务器上安装和本地完全一致的浏览器版本，存放在固定的路径
• 页面访问依赖的静态资源，统一走内网镜像，不要外网加载

还有一个小细节，服务器上跑UI自动化一定要用无头模式，不要试图去开可视化桌面，实验室环境带宽和CPU资源都紧张，没必要浪费在渲染界面上。

4.4 用例执行过多导致数据越积越多，环境越来越慢

测试数据不清理，跑一个月的自动化之后，测试环境基本就变成一个垃圾场。列表页越来越慢、查询超时、唯一性约束冲突频频爆出，这些全是数据膨胀的并发症。

我的处理方法有两个方向：

• 用例内清理：每个用例执行完，立即通过API或数据库将创建的数据标记为无效或直接删除，成本低、效果好
• 定时批量清理：用定时任务每一天执行一次数据清理脚本，把表里标记为测试数据的历史记录统一清理掉，防止异常中断时留下漏网之鱼

在数据表设计上，我强烈建议在测试过程中给所有数据打上可识别的标签。比如订单编号前缀是AT_，用户名称前缀是autotest_，这样不管批量清理还是定向排查都极其方便。

4.5 重试后用例“假成功”：问题被掩盖了

这是很多团队沾沾自喜实则在埋雷的地方。开了自动重试后，用例第一次跑是失败的，重跑后通过了，可能只是网络抖动或环境瞬时波动，但如果是功能真有问题，这种重试机制就会把问题掩盖成“最终通过”。

我个人对重试的态度列个表，方便你直接参考：

如果你发现某个用例经常重试后才过，那它本身就是个风险信号，要去查为什么它不稳定，而不是靠重试来“兜底”。

5. 把用例从“能跑”进化到“可靠”：进阶策略实录

前面讲的是用例怎么从无到有，这一节讲怎么从有到优。一套真正可靠的自动化资产，是需要持续打磨的，下面是我总结的几个进阶方向。

5.1 基于风险的优先级分层

用例应按业务价值和对系统核心功能的重要性做分层管理。我从几个项目里沉淀下来的分层方式比较简单：

• P0级：业务核心链路，比如登录、下单、支付。执行频率最高，每次代码提交都要跑
• P1级：主要功能模块的关键路径，比如购物车、订单查询。每天定时执行
• P2级：边缘场景、组合场景。每周执行一次或按版本节奏执行

分层的好处是显而易见的：当你的用例数量达到几百上千条时，全量回归的时间成本已经不可忽视，这时候按优先级做增量回归就变得至关重要。P0挂了，开发必须马上修复；P2挂了，可以进测试池观察反馈，不用半夜把运维叫起来。

5.2 保持用例与需求同步的流程机制

自动化用例最尴尬的宿命就是需求变了，用例没跟上。时间久了，用例池会成为一潭死水，越跑越没人信。

我建议团队里维持一个简单的同步流程：

• 需求变更评审时，测试负责人同步评估自动化用例是否需要调整
• 用例变更走代码评审流程，不能随改随发
• 测试环境发生结构变化时，第一时间更新自动化用例中的选择器和流程设计

一定要拒绝“一次性交付”的心态。自动化用例不是交付完就完事的，它是系统的测试资产，随系统生命周期共存亡。

5.3 失败分类与持续改进的闭环

建立用例失败的分析闭环是我提高自动化稳定性的利器。每次回归后，我会把失败用例分类汇总，统计出三大类的占比：

过去半年我盯过一阵数据，环境问题从最初占比60%降到了20%，真实缺陷占比反而从5%提升到了30%。这里面的道理很微妙：当自动化用例越来越稳定，它报告的东西就越来越可信，那些不敢提交代码的开发也会被逼着面对真实的测试结果。整个流程走上了正循环。

6. 最后再分享一点实操中的体会

写自动化测试用例这份工作，做久了其实会发现，真正有价值的不是代码本身，而是你对业务的理解和对质量的判断力。我见过一些刚入行的同学，天天追着新框架跑，今天觉得这个好，明天觉得那个好，结果是框架换了好几个，自动化资产却一盘散沙。我的建议是，选个主流的底层框架，把精力花在用例设计和用例管理上，这才是自动化投入回报率最高的地方。

还有一个真正的经验之谈：不要为了覆盖率而写用例。我在团队里最常说的一句话是，**十条稳定且能精准发现缺陷的用例，远远好过一百条跑得飞快但从不失败、也从没发现过bug的用例。**每条用例都该有它存在的原因，要么守护一段核心业务逻辑，要么覆盖一个容易出错的边界场景，如果一条用例半年都没失败过一次而且也没保护住任何东西，那它就该被删除。

自动化测试的道路上没有捷径，但走正确的路子会让你少掉很多头发。先把用例设计思路理清，再去考虑框架选型和技术栈，你会发现那些曾经让人崩溃的偶发失败、乱七八糟的数据问题、没人愿意维护的一堆脚本，都会慢慢变得可控起来。