学习记录：把海外社区论坛场景下的自动化测试整理成一篇入门笔记，结合个人实践，并与 AI 一起补全结构，便于按模块与方法查阅。

若你在测需要长期回归的社区类产品，希望这篇能当落地路线图用。

适合对象：准备从接口自动化起步、逐步搭建稳定回归的同学；文中不默认你已熟悉某一框架或 CI 流水线细节。

阅读提示：全文按「基础概念 → 论坛自动化实战 → 专项方法 → 用例、脚本与总结」四块展开；配合页面 TOC 或下方折叠目录跳转。第 11～22 章对应登录、发帖、互动、Feed、搜索与通知私信等主链路，宜优先沉淀接口层断言与数据清理策略。

章节目录（共 38 章，点击展开，条目可点击跳转）
  1. 为什么要学习自动化测试
  2. 什么是自动化测试
  3. 自动化测试和手工测试有什么区别
  4. 自动化测试适合测什么
  5. 自动化测试不适合测什么
  6. 接口自动化、UI 自动化、单元测试分别是什么
  7. 自动化测试的基本流程是什么
  8. 自动化测试需要准备什么
  9. 自动化测试常用工具有哪些
  10. 新手应该从哪里开始学自动化
  11. 社区论坛哪些场景适合自动化
  12. 注册登录自动化怎么做
  13. 用户资料自动化怎么做
  14. 发帖自动化怎么做
  15. 评论与回复自动化怎么做
  16. 点赞、收藏、关注自动化怎么做
  17. Feed 信息流自动化怎么做
  18. 搜索自动化怎么做
  19. 通知消息自动化怎么做
  20. 私信自动化怎么做
  21. 举报与审核自动化怎么做
  22. 多语言和时区接口自动化怎么做
  23. 接口自动化怎么入门
  24. UI 自动化怎么入门
  25. 自动化用例怎么设计
  26. 自动化断言怎么写
  27. 自动化测试数据怎么准备
  28. 环境变量和 Token 怎么管理
  29. 自动化测试报告怎么看
  30. 自动化脚本失败怎么定位
  31. 自动化测试如何接入 CI/CD
  32. 自动化测试如何维护稳定性
  33. 自动化测试的风险和注意事项
  34. 自动化测试用例怎么写
  35. 自动化脚本设计思路
  36. 自动化失败问题怎么提交
  37. 新手常见误区
  38. 最后总结

第一部分：自动化测试基础概念

如果你是自动化测试新手，建议先完整学习这一部分。

如果你已经了解接口自动化和 UI 自动化，可以直接跳到 第二部分：海外社区论坛自动化测试实战。

1. 为什么要学习自动化测试

前面你已经学习了很多测试内容：

功能测试
接口测试
数据一致性测试
权限测试
风控审核测试
国际化测试
兼容性测试
性能测试
安全测试

这些内容里，有些需要人工判断，有些可以交给脚本重复执行。

例如每次版本发布前，都要验证：

  • 用户能否登录
  • 用户能否发帖
  • 用户能否评论
  • 用户能否点赞
  • 未登录不能发帖
  • 普通用户不能删除别人帖子
  • Feed 接口能正常返回
  • 搜索接口能正常返回

这些场景稳定、重复、规则明确，就适合做自动化测试。

1.1 自动化测试能解决什么问题

问题 自动化能带来的价值
每次版本都要重复回归 脚本自动执行，减少重复劳动
核心流程容易漏测 自动化固定覆盖核心路径
接口数量很多 批量执行接口用例
回归时间太长 缩短回归周期
改动频繁 快速发现基础功能是否被影响
线上前风险验证 发布前快速跑冒烟测试

1.2 自动化测试不能解决所有问题

自动化不是万能的。

它更适合验证：

确定性的、重复的、稳定的、可断言的场景

不适合完全替代：

  • 新需求理解
  • 复杂体验判断
  • UI 美观判断
  • 探索性测试
  • 一次性临时功能测试
  • 强依赖人工判断的内容审核结果

所以自动化测试不是替代手工测试，而是帮助测试同学把重复工作沉淀下来。

2. 什么是自动化测试

自动化测试就是：

使用工具或代码代替人工执行测试步骤，并自动判断测试结果是否符合预期。

简单理解：

手工测试：人一步一步操作和判断
自动化测试：脚本一步一步操作和判断

例如接口自动化可以做到：

调用登录接口
  ↓
保存 Token
  ↓
调用发帖接口
  ↓
断言返回成功
  ↓
调用详情接口
  ↓
断言帖子内容正确

2.1 自动化测试的核心

自动化测试核心不是“会写代码”，而是：

知道哪些用例值得自动化
知道如何准备数据
知道如何执行步骤
知道如何判断结果
知道失败后如何定位
知道如何长期维护

3. 自动化测试和手工测试有什么区别

对比项 手工测试 自动化测试
执行方式 人操作 脚本执行
适合场景 新功能、复杂判断、探索测试 稳定流程、重复回归、接口验证
成本特点 初始成本低，重复成本高 初始成本高，重复成本低
结果判断 人判断 断言判断
维护成本 用例文档维护 脚本、数据、环境维护
常见风险 漏测、效率低 脚本不稳定、维护困难

3.1 举个例子：发帖功能

手工测试：

打开 App
登录账号
进入发帖页
输入标题和正文
点击发布
查看帖子详情
人工判断是否成功

接口自动化：

调用登录接口
调用创建帖子接口
断言 code=0
断言返回 postId
调用帖子详情接口
断言标题和正文正确

UI 自动化：

启动 App 或浏览器
自动输入账号密码
自动点击发帖按钮
自动输入标题正文
自动点击发布
自动检查页面是否出现帖子标题

4. 自动化测试适合测什么

适合自动化的场景通常有这些特点：

  • 流程稳定
  • 结果明确
  • 经常回归
  • 不需要复杂人工判断
  • 数据可准备
  • 环境可控
  • 执行成本高但重复频率高

4.1 社区论坛适合自动化的场景

场景 是否适合 原因
登录接口 适合 稳定、基础、经常回归
发帖接口 适合 核心流程，结果可断言
评论接口 适合 高频核心功能
点赞接口 适合 幂等和状态可验证
Feed 接口 适合 核心接口，回归价值高
搜索接口 适合 可验证返回结构和基础结果
权限接口 适合 越权结果明确
图片上传 部分适合 接口可测，UI 上传稳定性稍差
复杂 UI 动画 不太适合 结果难断言，脚本易不稳定
内容审核准确性 部分适合 流程可测，判断质量需人工或固定样本

5. 自动化测试不适合测什么

以下场景不建议一开始就自动化：

  • 需求还不稳定的功能
  • 页面经常改版的功能
  • 需要人工判断美观的 UI
  • 只测试一次的临时功能
  • 第三方授权非常不稳定的 UI 链路
  • 复杂图片/视频内容人工判断
  • 强依赖短信、邮箱、真实第三方环境的流程

5.1 新手容易误解的点

不是所有手工用例都要变成自动化用例。

自动化用例应该优先选择：

核心流程 + 高频回归 + 稳定接口 + 明确断言

不要一开始就追求覆盖所有页面，否则脚本会非常难维护。

6. 接口自动化、UI 自动化、单元测试分别是什么

6.1 接口自动化

接口自动化是直接调用接口并判断返回结果。

适合：

  • 登录
  • 发帖
  • 评论
  • 点赞
  • 权限校验
  • 参数校验
  • 分页
  • 数据一致性基础检查

优点：

  • 稳定性高
  • 执行快
  • 维护成本相对低
  • 不依赖页面

建议新手优先从接口自动化开始。

6.2 UI 自动化

UI 自动化是模拟用户在页面或 App 上操作。

适合：

  • 冒烟测试
  • 核心主流程
  • 登录发帖等关键路径
  • Web 后台简单回归

缺点：

  • 脚本容易受页面变化影响
  • 执行较慢
  • 定位问题比接口自动化复杂

6.3 单元测试

单元测试一般由开发同学编写，用于测试某个函数或方法是否正确。

测试同学可以了解，但不一定作为第一阶段重点。

7. 自动化测试的基本流程是什么

自动化测试通常包括这些步骤：

选择自动化场景
  ↓
设计自动化用例
  ↓
准备测试数据
  ↓
编写脚本
  ↓
执行脚本
  ↓
生成测试报告
  ↓
分析失败原因
  ↓
维护脚本

7.1 自动化不是写完就结束

自动化脚本需要长期维护。

例如：

  • 接口字段变了，要更新脚本
  • 页面元素变了，要更新定位
  • 测试账号失效，要更新数据
  • 环境地址变了，要更新配置
  • 业务规则变了，要更新断言

所以自动化测试不是一次性工作，而是一套持续维护的资产。

8. 自动化测试需要准备什么

8.1 准备接口文档和稳定环境

需要：

  • 测试环境地址
  • 接口文档
  • 测试账号
  • 管理员账号，按需求
  • 测试数据
  • 是否有验证码绕过方案
  • 是否有稳定的测试 Token 获取方式
  • 是否有测试数据库或清理数据方式

8.2 准备工具和语言

常见选择：

类型 工具
接口调试 Postman、Apifox
接口自动化 Postman Runner、Apifox 自动化、pytest、requests、JMeter、k6
Web UI 自动化 Selenium、Playwright、Cypress
App UI 自动化 Appium、Airtest
测试报告 Allure、HTML Report、平台自带报告
CI/CD Jenkins、GitHub Actions、GitLab CI

新手建议路线：

Apifox/Postman 调试接口
  ↓
Apifox/Postman 简单自动化
  ↓
Python + pytest + requests
  ↓
接入 Jenkins 或 CI

9. 自动化测试常用工具有哪些

9.1 Postman / Apifox

适合新手入门接口自动化。

能做：

  • 保存接口集合
  • 设置环境变量
  • 设置前置脚本和后置断言
  • 批量运行接口
  • 生成简单报告

9.2 Python + pytest + requests

适合进一步系统化接口自动化。

优点：

  • 灵活
  • 易扩展
  • 适合数据驱动
  • 适合接入 CI
  • 适合生成报告

9.3 Playwright / Selenium

适合 Web UI 自动化。

例如：

  • Web 登录
  • Web 发帖
  • 后台审核
  • 后台列表查询

9.4 Appium / Airtest

适合 App UI 自动化。

例如：

  • App 登录
  • App 发帖
  • App 评论
  • App 私信

但 App UI 自动化维护成本较高，新手不建议一开始就大规模做。

10. 新手应该从哪里开始学自动化

建议从接口自动化开始。

原因：

  • 你已经学过接口测试
  • 接口结果更容易断言
  • 接口脚本比 UI 脚本稳定
  • 执行速度快
  • 更适合回归测试

推荐学习路径：

1. 熟练用 Apifox/Postman 调接口
2. 学会设置环境变量
3. 学会保存 Token
4. 学会写简单断言
5. 学会批量运行接口集合
6. 学会用 Python requests 调接口
7. 学会 pytest 组织用例
8. 学会生成报告
9. 学会接入 CI

第二部分：海外社区论坛自动化测试实战

这一部分开始进入项目实战。

社区论坛自动化不要一开始追求“大而全”，建议先覆盖核心稳定流程，再逐步扩展。

11. 社区论坛哪些场景适合自动化

优先自动化这些场景：

优先级 场景 原因
P0 登录、刷新 Token、退出登录 所有功能基础
P0 发帖、帖子详情查询 社区核心链路
P0 评论、回复 高频互动
P0 点赞、取消点赞 高频且易回归
P0 权限越权接口 风险高，结果明确
P1 Feed 列表 核心浏览入口
P1 搜索 高频入口
P1 通知未读数 易出现数据问题
P1 关注、收藏 高频互动
P2 私信 受环境和实时链路影响，逐步覆盖
P2 举报审核 流程长，但回归价值高

12. 注册登录自动化怎么做

注册登录自动化要谨慎，因为它经常涉及验证码、邮箱、短信、第三方授权。

12.1 登录接口自动化

适合优先做。

流程：

调用登录接口
  ↓
断言登录成功
  ↓
保存 accessToken
  ↓
调用用户信息接口
  ↓
断言当前用户信息正确

断言点：

  • HTTP 状态码正确
  • 业务 code 成功
  • 返回 Token 不为空
  • 返回 userId 正确
  • 使用 Token 能访问登录态接口

12.2 注册自动化

注册自动化要考虑测试数据清理。

适合场景：

  • 邮箱格式校验
  • 密码规则校验
  • 重复注册校验
  • 验证码错误校验

不建议频繁自动创建大量真实账号，除非有清理机制。

12.3 第三方登录自动化

第三方登录 UI 自动化通常不稳定。

建议优先自动化后端接口层：

  • 授权 code 为空失败
  • 授权 code 错误失败
  • 已绑定账号登录成功，使用模拟或测试桩，按项目条件

真实 Google / Apple 授权流程不建议作为高频自动化回归主链路。

13. 用户资料自动化怎么做

用户资料接口适合自动化。

13.1 修改资料自动化流程

登录用户A
  ↓
修改昵称和简介
  ↓
查询用户A资料
  ↓
断言昵称和简介已更新
  ↓
恢复测试数据

断言点：

  • 修改接口返回成功
  • 查询接口返回新昵称
  • 用户B不能修改用户A资料
  • 超长昵称修改失败
  • 特殊字符昵称按规则处理

13.2 注意事项

自动化修改资料后，最好恢复原数据，避免影响其他用例。

例如：

测试前记录原昵称
测试中修改昵称
测试后恢复原昵称

14. 发帖自动化怎么做

发帖是最适合接口自动化的核心链路之一。

14.1 发帖成功链路

登录用户A
  ↓
调用创建帖子接口
  ↓
断言返回 postId
  ↓
调用帖子详情接口
  ↓
断言标题、正文、作者正确
  ↓
删除测试帖子或标记清理

14.2 发帖异常自动化

适合自动化的异常场景：

  • title 为空失败
  • title 超长失败
  • topicId 不存在失败
  • 未登录发帖失败
  • 被禁言用户发帖失败
  • 用户B不能编辑用户A帖子
  • 重复提交按规则处理

14.3 测试数据清理

自动化发帖会产生测试数据。

需要考虑：

  • 用例结束后删除帖子
  • 使用测试专用板块
  • 标题加自动化标识，例如 AUTO_TEST_POST_时间戳
  • 定期清理自动化数据

15. 评论与回复自动化怎么做

评论自动化要依赖已有帖子。

15.1 评论成功链路

登录用户A创建帖子
  ↓
登录用户B发表评论
  ↓
查询评论列表
  ↓
断言评论内容存在
  ↓
查询帖子详情
  ↓
断言评论数增加

15.2 回复成功链路

用户B评论帖子
  ↓
用户C回复用户B评论
  ↓
查询回复列表
  ↓
断言 parentId、replyToUserId 正确

15.3 异常场景

  • 空评论失败
  • 超长评论失败
  • 未登录评论失败
  • 被禁言用户评论失败
  • 评论已删除帖子失败
  • 用户A不能删除用户B评论，按需求判断

16. 点赞、收藏、关注自动化怎么做

这些接口非常适合自动化，因为结果明确。

16.1 点赞自动化

流程：

准备帖子 P001
  ↓
用户A点赞 P001
  ↓
查询帖子详情
  ↓
断言 likeStatus=true
  ↓
断言 likeCount 增加
  ↓
用户A取消点赞
  ↓
断言 likeStatus=false

重点断言：

  • 重复点赞不重复加数
  • 重复取消不出现负数
  • 未登录点赞失败
  • 已删除帖子点赞失败

16.2 收藏自动化

断言点：

  • 收藏成功
  • 收藏列表包含该帖子
  • 取消收藏成功
  • 收藏列表不再包含该帖子
  • 重复收藏不重复生成记录

16.3 关注自动化

断言点：

  • 用户A关注用户B成功
  • 用户A关注列表包含用户B
  • 用户B粉丝列表包含用户A
  • 不能关注自己
  • 重复关注不重复增加数量
  • 取消关注后列表更新

17. Feed 信息流自动化怎么做

Feed 自动化要注意：推荐流结果可能不稳定。

17.1 适合自动化的断言

Feed 不适合强断言“某条帖子一定排第一”，除非是测试环境固定数据。

适合断言：

  • 接口返回成功
  • list 是数组
  • 字段完整
  • pageSize 生效
  • nextCursor 存在或为空符合规则
  • 不返回已删除帖子
  • 不返回审核失败帖子
  • 分页之间无重复，按测试数据判断

17.2 推荐流注意事项

推荐流可能受算法影响，不稳定。

自动化中不要过度依赖推荐排序。

更适合测试：

  • 最新流
  • 关注流
  • 指定板块流
  • 测试专用数据流

18. 搜索自动化怎么做

搜索自动化适合使用唯一关键词。

18.1 搜索成功链路

创建标题唯一的帖子：AUTO_SEARCH_时间戳
  ↓
等待搜索索引同步，按需求
  ↓
调用搜索接口
  ↓
断言结果中包含该帖子

18.2 搜索异常场景

  • keyword 为空
  • keyword 为空格
  • keyword 超长
  • 特殊字符搜索
  • 无结果搜索
  • 分页查询
  • 多语言关键词搜索

18.3 注意事项

搜索可能有索引延迟。

自动化中要避免立即强断言，可以：

  • 等待固定短时间
  • 重试几次
  • 查询接口确认索引状态，按项目能力
  • 使用已有稳定搜索数据

19. 通知消息自动化怎么做

通知自动化要关注异步延迟。

19.1 评论通知自动化流程

用户A创建帖子
  ↓
用户B评论帖子
  ↓
用户A查询通知列表
  ↓
断言存在评论通知
  ↓
标记通知已读
  ↓
断言未读数减少

19.2 注意事项

通知可能异步生成。

自动化中可以设置：

  • 等待重试
  • 最大等待时间
  • 超时后失败

不要只立即查一次就判断失败。

20. 私信自动化怎么做

私信自动化可以先从接口层做。

20.1 发送消息链路

用户A发送消息给用户B
  ↓
用户B查询会话列表
  ↓
断言最近消息正确
  ↓
用户B查询消息列表
  ↓
断言消息内容正确
  ↓
用户B标记已读
  ↓
断言未读数变化

20.2 实时消息自动化

WebSocket 或实时消息自动化更复杂，可以作为后续提升。

新手阶段先覆盖：

  • 发送接口
  • 会话列表接口
  • 消息列表接口
  • 未读状态接口

21. 举报与审核自动化怎么做

举报审核流程较长，但核心链路适合自动化。

21.1 举报自动化流程

用户A创建帖子
  ↓
用户B举报该帖子
  ↓
查询后台举报列表
  ↓
断言生成举报记录

21.2 审核自动化流程

用户A发布待审核内容
  ↓
管理员查询待审核列表
  ↓
管理员审核通过或拒绝
  ↓
用户侧查询内容状态
  ↓
断言前台展示符合审核结果

21.3 注意事项

审核自动化要注意不要影响真实审核数据。

建议：

  • 使用测试专用板块
  • 使用测试专用风险词
  • 使用测试审核员账号
  • 自动化数据加明显标识

22. 多语言和时区接口自动化怎么做

海外项目可以把多语言和时区能力沉淀成接口自动化。

22.1 多语言 Header 自动化

测试：

Accept-Language: en-US
Accept-Language: ja-JP
Accept-Language: ar-SA

断言：

  • 接口返回语言符合预期
  • 不支持语言使用默认语言
  • 错误提示语言正确
  • 枚举值不因语言变化而错乱

22.2 时区 Header 自动化

测试：

X-Timezone: Asia/Singapore
X-Timezone: America/New_York
X-Timezone: Europe/London

断言：

  • 时间字段格式正确
  • 不同时区展示符合产品规则
  • 错误时区有兜底
  • 活动开始/结束时间转换正确

第三部分：自动化测试专项方法

这一部分不是某个具体模块，而是一套可以复用的方法。

自动化测试的关键不是写很多脚本，而是写出稳定、可维护、能持续产生价值的脚本。

23. 接口自动化怎么入门

接口自动化建议从简单链路开始。

23.1 第一个接口自动化场景

推荐从登录接口开始：

1. 调用登录接口
2. 断言返回成功
3. 提取 Token
4. 调用用户信息接口
5. 断言用户信息正确

这是后续所有接口自动化的基础。

23.2 接口自动化基本结构

一个接口自动化用例通常包括：

前置条件
请求地址
请求方法
请求头
请求参数
执行请求
响应断言
数据清理

24. UI 自动化怎么入门

UI 自动化适合做少量核心冒烟，不建议新手一开始大规模做。

24.1 Web UI 自动化适合场景

  • 登录成功
  • 发帖成功
  • 搜索成功
  • 后台审核通过
  • 后台筛选查询

24.2 App UI 自动化适合场景

  • App 启动
  • 登录
  • 进入首页
  • 发帖主流程
  • 评论主流程

24.3 UI 自动化注意事项

  • 页面元素定位要稳定
  • 不要依赖频繁变化的文案
  • 等待机制要合理
  • 不要用固定 sleep 过多
  • UI 脚本失败要截图
  • 优先覆盖核心主流程

25. 自动化用例怎么设计

25.1 自动化用例选择原则

优先选择：

  • P0 核心链路
  • 高频回归场景
  • 稳定接口
  • 结果明确
  • 数据可控
  • 失败影响大的场景

不优先选择：

  • 需求变化频繁
  • 依赖人工判断
  • 强依赖第三方不稳定环境
  • 数据难清理
  • 页面频繁改版

25.2 自动化用例分层

建议分成：

层级 内容
冒烟用例 登录、发帖、评论、点赞等最核心流程
回归用例 常用模块接口和权限场景
专项用例 多语言、权限、风控、数据一致性等
稳定性用例 定时执行、监控核心接口健康

26. 自动化断言怎么写

断言就是自动判断结果是否符合预期。

26.1 常见断言

  • HTTP 状态码正确
  • 业务 code 正确
  • message 正确，按需求判断
  • data 不为空
  • 返回字段存在
  • 字段类型正确
  • 字段值等于预期
  • 列表长度符合预期
  • 数据状态正确
  • 权限失败时数据未变化

26.2 不好的断言

只断言接口返回 200

这不够。

因为接口返回 200，也可能业务失败。

26.3 好的断言示例

发帖成功用例应断言：

  • HTTP 状态码成功
  • 业务 code 成功
  • postId 不为空
  • 查询详情成功
  • 详情标题等于请求标题
  • 作者 ID 等于当前用户 ID

27. 自动化测试数据怎么准备

自动化测试最难的部分之一是数据。

27.1 数据准备方式

方式 说明
预置数据 提前准备固定账号和帖子
接口造数 用接口在用例前创建数据
数据库造数 直接写入数据库，需谨慎和授权
Mock 数据 模拟接口返回，适合部分场景
随机数据 使用时间戳避免重复

27.2 数据清理

自动化用例执行后要考虑清理：

  • 删除测试帖子
  • 删除测试评论
  • 取消点赞
  • 取消关注
  • 恢复用户资料
  • 清理测试通知，按需求判断

如果不清理，测试环境会越来越脏。

28. 环境变量和 Token 怎么管理

28.1 常见环境变量

变量 示例
base_url 测试环境接口地址
userA_email 用户A邮箱
userA_password 用户A密码
userA_token 用户A Token
admin_token 管理员 Token
topic_id 测试板块 ID

28.2 Token 管理

不要手动复制 Token 到每个请求中。

建议：

登录接口执行后自动提取 Token
后续请求自动使用 Token
Token 过期时重新登录获取

28.3 安全注意

不要把真实密码、Token 提交到公共代码库。

测试账号密码也要按团队规范管理。

29. 自动化测试报告怎么看

自动化报告至少要看：

  • 总用例数
  • 通过数
  • 失败数
  • 跳过数
  • 失败原因
  • 失败截图，UI 自动化
  • 请求和响应，接口自动化
  • 执行耗时
  • 历史趋势

29.1 失败结果怎么判断

自动化失败不一定都是产品 Bug。

可能是：

  • 产品 Bug
  • 脚本问题
  • 测试数据问题
  • 环境问题
  • 网络问题
  • 接口文档变更
  • Token 失效
  • 第三方服务异常

所以自动化失败后要先分析，再提交 Bug。

30. 自动化脚本失败怎么定位

定位思路：

先看失败用例名称
  ↓
看失败步骤
  ↓
看请求参数
  ↓
看响应结果
  ↓
看测试数据是否存在
  ↓
看环境是否正常
  ↓
判断是产品问题还是脚本问题

30.1 常见失败原因

现象 可能原因
登录失败 账号密码变更、账号被锁、环境异常
发帖失败 Token 失效、参数变化、用户状态异常
查询不到数据 数据未创建成功、搜索索引延迟
UI 找不到元素 页面改版、定位方式不稳定
用例偶现失败 异步延迟、网络波动、等待不足
所有接口失败 环境挂了或 base_url 错误

31. 自动化测试如何接入 CI/CD

CI/CD 是持续集成和持续交付。

自动化测试接入 CI 后，可以在代码提交、版本构建、发布前自动执行。

31.1 常见触发方式

  • 每次代码提交后执行
  • 每次构建后执行
  • 每天定时执行
  • 发布前手动触发
  • 合并主分支前执行

31.2 适合接入 CI 的用例

优先接入：

  • 冒烟用例
  • 接口核心链路
  • 权限高风险用例
  • 稳定且执行快的用例

不建议一开始接入：

  • 不稳定 UI 用例
  • 强依赖第三方登录 UI 的用例
  • 执行时间很长的全量用例

32. 自动化测试如何维护稳定性

自动化最大问题之一是“不稳定”。

32.1 提高稳定性的方法

  • 使用稳定测试环境
  • 使用固定测试账号
  • 用例之间尽量独立
  • 每个用例准备自己的数据
  • 避免依赖执行顺序
  • 异步场景使用合理重试
  • UI 自动化使用稳定元素定位
  • 定期清理测试数据
  • 脚本失败及时维护

32.2 用例独立性

不好的设计：

用例2依赖用例1创建的帖子
用例3依赖用例2创建的评论

如果用例1失败，后面全部失败。

更好的设计：

每个用例自己准备需要的数据
用例结束后自己清理数据

33. 自动化测试的风险和注意事项

33.1 常见风险

  • 自动化脚本维护成本过高
  • 脚本频繁误报
  • 测试数据污染环境
  • 过度依赖自动化，忽略手工探索
  • 自动化覆盖了很多低价值用例
  • 敏感账号密码管理不当
  • CI 中失败无人关注

33.2 注意事项

  • 先小范围试点
  • 优先做接口自动化
  • 优先覆盖核心链路
  • 脚本要有人维护
  • 失败结果要有人分析
  • 自动化用例要定期清理和优化

第四部分：用例、脚本设计、问题与总结

自动化测试不是单纯写脚本，而是把稳定、有价值、可重复执行的测试流程沉淀成长期资产。

34. 自动化测试用例怎么写

自动化测试用例建议包含：

  • 用例编号
  • 模块
  • 自动化类型
  • 前置条件
  • 测试数据
  • 操作步骤
  • 断言点
  • 数据清理方式
  • 优先级

34.1 用例模板

字段 示例
用例编号 AUTO_API_POST_001
模块 发帖
自动化类型 接口自动化
前置条件 用户A已登录，测试板块存在
测试数据 title=AUTO_TEST_POST_时间戳，content=auto test content
操作步骤 调用创建帖子接口，再调用详情接口
断言点 创建成功；postId 不为空；详情标题和正文正确
数据清理 删除测试帖子
优先级 P0

34.2 示例用例：点赞幂等自动化

字段 内容
用例编号 AUTO_API_LIKE_001
模块 点赞
自动化类型 接口自动化
前置条件 存在正常帖子 P001，用户A已登录
测试数据 postId=P001，userA_token
操作步骤 用户A连续调用点赞接口 3 次，再查询帖子详情
断言点 likeStatus=true；likeCount 只增加一次；不生成重复点赞记录
数据清理 取消点赞
优先级 P0

35. 自动化脚本设计思路

35.1 分层设计

建议把脚本分成几层：

接口请求层
业务封装层
测试用例层
测试数据层
配置层
报告层

简单理解：

  • 接口请求层：负责发送请求
  • 业务封装层：负责登录、发帖、评论这些业务动作
  • 测试用例层：负责组织测试步骤和断言
  • 测试数据层：负责账号、标题、内容、ID
  • 配置层：负责环境地址、Token、语言等
  • 报告层：负责展示结果

35.2 为什么要分层

如果不分层，脚本会变得很乱。

例如每个用例都手写登录请求、发帖请求、断言逻辑，后面接口一变，所有地方都要改。

分层后，只需要改封装方法。

36. 自动化失败问题怎么提交

自动化失败先判断是否产品 Bug。

如果确认是产品 Bug，再提交。

36.1 自动化失败记录应包含

  • 自动化执行时间
  • 执行环境
  • 失败用例名称
  • 失败步骤
  • 请求参数
  • 响应结果
  • 断言失败原因
  • 相关测试数据 ID
  • 是否手工复现
  • 截图或日志

36.2 示例 Bug

标题

[自动化回归][接口] 被禁言用户发帖接口返回成功

来源

自动化回归任务：API Smoke Test
执行时间：2026-05-08 10:00
失败用例：AUTO_API_POST_MUTED_USER_001

实际结果

被禁言用户调用创建帖子接口，接口返回 code=0，并返回 postId。

预期结果

被禁言用户不允许发帖，接口应返回账号受限错误，不应创建帖子。

补充信息

已手工使用同账号复现。

37. 新手常见误区

37.1 一开始就做 UI 自动化大而全

UI 自动化维护成本高。

新手建议先从接口自动化开始。

37.2 自动化用例没有断言

只执行步骤，不判断结果，不叫有效自动化。

例如只调用发帖接口，但不检查 postId 和详情内容，就是不完整的。

37.3 测试数据不清理

自动化长期运行会产生大量脏数据。

要设计清理机制。

37.4 用例之间强依赖

一个用例失败，后面一串失败，会导致定位困难。

尽量让用例独立。

37.5 自动化失败没人看

自动化不是跑完报告就结束。

失败结果必须有人分析，否则自动化没有价值。

38. 最后总结

自动化测试的核心不是“写很多脚本”，而是要理解：

哪些场景值得自动化？
哪些场景结果明确、适合断言？
测试数据如何准备？
执行后如何清理？
失败后如何定位？
脚本如何长期维护？
自动化如何融入版本回归？

对于海外社区论坛项目，最适合优先自动化的方向是：

  • 登录接口
  • 发帖接口
  • 评论接口
  • 点赞、收藏、关注接口
  • 权限越权接口
  • Feed 基础接口
  • 搜索基础接口
  • 通知未读数接口
  • 用户资料接口
  • 多语言和时区 Header 基础校验
  • 冒烟级 UI 主流程

你可以记住一个万能自动化测试公式：

稳定场景 + 明确断言 + 可控数据 + 可重复执行 + 可维护脚本 = 有价值的自动化测试

例如：

登录接口 + 断言 Token + 固定测试账号 + 每次回归执行 + 统一封装登录方法
发帖接口 + 断言 postId 和详情 + 自动生成标题 + 执行后删除帖子
点赞接口 + 断言 likeStatus 和 likeCount + 准备固定帖子 + 执行后取消点赞

只要你先从接口自动化的小闭环做起，再逐步扩展到 UI 自动化和 CI 集成，自动化测试能力就会越来越成熟。