自动化流程不是写完就一劳永逸的。
拼多多改一个表单字段，TEMU 调整了上传图片的尺寸限制，TikTok Shop 换了一个弹窗的关闭逻辑——
任何一个上游变化，都可能让原本跑得好好的流程突然失效。
我们是在一次“凌晨批量改价全平台失败”之后，才开始认真做测试的。
那次事故的原因，仅仅是拼多多后台把价格输入框的 name 属性改了一个字母。
如果有回归测试，上线前跑一遍，几秒钟就能发现。
但现实是，RPA 流程的自动化测试几乎是一片空白地带。
这篇文章写的就是，我们如何从零搭建一套针对影刀流程的自动化测试体系，
让流程变更不再靠“祈祷不出事”来保障。
一、RPA 流程测试为什么难
传统的软件自动化测试，面对的是 API 和函数。
输入可控，输出可断言，环境容易 Mock。
但影刀的流程，操作的是真实的浏览器页面。
输入来自页面元素，输出依赖于 DOM 结构和网络响应。
一个按钮的 xpath 变了，流程就断了。
一个弹窗延迟了 300ms，流程就可能点错位置。
更麻烦的是，测试环境依赖真实的平台后台。
你没法像 Mock 一个 HTTP 接口那样，Mock 一个拼多多后台。
测试如果不小心，还可能把测试数据写进真实店铺，酿成线上事故。
这些特点决定了，RPA 流程的测试必须有一套专门的设计。
二、测试分层：从单元到端到端
我们把流程测试分成了三层：
- 单元级测试：验证单个操作步骤的选择器是否有效，页面元素是否存在。
- 流程级测试：验证一个完整流程（如上架）在标准数据下能否正常走完。
- 回归套件：所有核心流程的组合，每次发版或平台变更后自动执行。
前两层在开发阶段运行，第三层在 CI 流水线和预发布环境里跑。
2.1 单元级测试：只测元素，不跑流程
影刀流程里的每一个“点击”、“输入”，都绑定了页面元素的选择器。
选择器失效，是流程故障最常见的原因。
我们写了一个轻量的选择器验证工具，不启动完整流程，只打开目标页面，逐个验证所有步骤涉及的元素是否可见、可操作。
class SelectorValidator:
def __init__(self, browser_page):
self.page = browser_page
async def validate(self, selector: str) -> bool:
try:
element = await self.page.wait_for_selector(selector, timeout=5000)
if element and await element.is_visible() and not await element.is_disabled():
return True
except Exception:
pass
return False
async def validate_flow_selectors(self, flow_config: dict) -> dict:
results = {}
for step_name, selector in flow_config["selectors"].items():
results[step_name] = await self.validate(selector)
return results
这个工具集成在开发环境里。
开发修改流程后，先跑一遍选择器验证，确保所有目标元素都还能找到。
如果某一步的选择器失效了，开发在本地就能立即修复，而不是等到测试环境才发现。
2.2 流程级测试：跑通但不影响真实店铺
单元验证通过后，就要跑完整流程。
这里最关键的事，是测试环境和生产环境严格隔离。
每个平台我们都维护了一批专用测试店铺。
拼多多有沙箱环境，TEMU 有测试卖家账号，TikTok Shop 也有沙箱。
测试店铺里创建的商品不会对外展示，但后台逻辑与真实店铺一致。
测试数据也独立管理。
我们建了一个测试数据仓库，里面是专门用于验证的标准商品信息。
数据的格式和线上完全一致，但标题里会带上 [TEST] 前缀，方便人工识别。
class TestDataLoader:
def load_standard_product(self, platform: str) -> dict:
return {
"title": f"[TEST]自动化验证商品_{platform}_{uuid.uuid4().hex[:6]}",
"price": 9.99,
"stock": 100,
"main_image": "https://test-cdn.example.com/test_product.jpg",
"description": "此商品由自动化测试生成",
}
流程执行完毕后，测试脚本会去后台验证结果。
比如上架流程跑完，脚本会打开商品列表页，检查是否出现了刚创建的商品。
这一层的断言，是“流程是否产生了预期的业务结果”。
三、回归测试的触发机制：不依赖人记得
测试写得再好，没人跑就等于白写。
我们把回归测试绑定到了两个触发事件上：
- 流程包版本变更：任何一个流程包提交新版本，自动触发对应平台的回归套件。
- 定时巡检：每天凌晨 3 点，全平台核心流程回归一次，产出健康报告。
回归的执行调度，复用之前介绍的分布式任务系统。
测试任务被封装成特殊的任务类型，打入独立的 test 队列，由测试专用的执行节点消费。
class RegressionTrigger:
def __init__(self, cron_scheduler, task_repo):
self.cron_scheduler = cron_scheduler
self.task_repo = task_repo
def on_flow_version_change(self, platform: str, action: str, new_version: str):
suite = self.task_repo.get_regression_suite(platform, action)
for test_case in suite:
task = test_case.create_task()
self.task_repo.enqueue_test_task(task)
async def daily_health_check(self):
for platform in ["pdd", "temu", "tiktok"]:
suite = self.task_repo.get_smoke_suite(platform)
for test_case in suite:
task = test_case.create_task()
await self.task_repo.enqueue_test_task(task)
每天早上的健康报告，会在 Grafana 看板上更新各平台流程的通过率。
一片绿，大家安心工作。
有红色方块，技术团队在运营发现之前就已经在处理了。
四、稳定性的最大敌人：页面异步行为
真正让流程测试变得困难的，不是逻辑分支，而是页面的异步行为。
网络请求的延迟、动画过渡、弹窗的随机出现——这些都是测试不稳定性的来源。
我们下了不少功夫处理等待策略。
首先，禁止流程里使用 sleep 做固定等待。
所有等待必须基于元素状态：wait_for_selector、wait_for_response。
影刀自身提供了这些能力，但需要开发者有意识地使用。
其次，在测试代码里增加了“条件重试”逻辑。
如果某一步因为网络波动失败，测试框架会自动重试一次（但不会像线上那样多次重试）。
class RetryableTestStep:
def __init__(self, max_retries=2):
self.max_retries = max_retries
async def execute(self, step_func):
last_error = None
for attempt in range(self.max_retries + 1):
try:
return await step_func()
except TransientException as e:
last_error = e
await asyncio.sleep(2 ** attempt)
raise last_error
我们区分了“瞬态异常”和“持久异常”。
只有在选择器失效、页面结构变化这类持久异常下，才标记为测试失败。
网络超时、元素暂时不可见，都视为可重试的瞬态问题。
这个区分让测试的误报率大幅下降。
五、Mock 外部依赖：当沙箱不够用时
平台沙箱虽然好，但它不能模拟所有场景。
比如“发货后买家退款”、“平台系统繁忙”这类边界情况，很难在沙箱里主动复现。
我们在测试环境里引入了一层轻量级的 Mock 代理。
它在浏览器和平台服务器之间，拦截特定的 API 响应，模拟边界情况。
class MockInterceptor:
def __init__(self, browser_context, mock_rules):
self.context = browser_context
self.rules = mock_rules
async def setup(self):
await self.context.route("**/*", self._handle_route)
async def _handle_route(self, route):
url = route.request.url
for rule in self.rules:
if rule.matches(url):
await route.fulfill(status=rule.status, body=rule.body)
return
await route.continue_()
通过 Mock，我们可以测试流程在面对“接口返回错误”、“库存不足”等异常时的行为是否正确。
这弥补了沙箱环境只能验证正常路径的不足。
但 Mock 不能滥用。
核心的回归套件，永远走真实平台沙箱，不用 Mock。
Mock 只用在边界测试和异常路径验证里。
六、测试报告与质量门禁
测试跑完了，结果要能看懂。
我们为每一次回归生成一份 JSON 报告，包含每个用例的执行情况、耗时、失败截图。
然后通过一个简单的 Python 脚本转成 Markdown，推到企业微信群。
## 回归测试报告 - 2026-06-06
| 平台 | 流程 | 状态 | 耗时 |
|------|------|------|------|
| 拼多多 | 商品上架 | ✅ | 42s |
| 拼多多 | 批量改价 | ✅ | 28s |
| TEMU | 商品上架 | ❌ | 55s |
| TikTok Shop | 商品上架 | ✅ | 38s |
质量门禁设置在调度侧的发布流程里。
如果新版本流程的回归测试未通过，发布自动阻断。
运维无法手动绕过，除非测试负责人审批豁免。
这个门禁，逼着所有人养成了“先过测试再上线”的习惯。
刚开始有人抱怨，但几次提前拦截问题之后，抱怨就变成了信任。
七、测试数据的管理与清理
测试跑多了，测试店铺里会堆积大量测试商品。
如果不定期清理，轻则影响后台加载速度，重则可能触发平台的风控（异常的商品创建/删除频率）。
我们在每个测试用例执行完后，立即执行清理步骤。
如果流程是“上架商品”，那清理步骤就是“下架并删除该商品”。
清理步骤本身也被写成了可复用的小流程，作为测试套件的 teardown。
class TestCaseRunner:
async def run(self, test_case: TestCase):
try:
result = await self._execute_test(test_case)
return result
finally:
await self._cleanup(test_case)
即使测试中断或失败，finally 块也会确保清理流程被触发。
测试环境因此保持了干净，第二天凌晨的自动化巡检不会因为残留数据而失败。
八、测试体系的代码组织结构
为了避免测试代码散落在各处，我们将所有测试相关的逻辑放在项目的 tests/ 目录下，按平台组织：
tests/
├── common/
│ ├── base_test.py
│ ├── selector_validator.py
│ └── mock_interceptor.py
├── pdd/
│ ├── test_product_upload.py
│ └── test_price_update.py
├── temu/
│ └── test_product_upload.py
└── tiktok/
└── test_product_upload.py
每个测试用例继承 BaseTest，它封装了浏览器获取、测试数据加载、清理逻辑等公共能力。
这种结构让新加一个测试变得简单——只需关注业务步骤，无需重复写环境准备。
九、真实踩坑：测试环境的一个小疏忽
有一次我们在测试环境跑回归，TikTok Shop 的流程一直失败。
排查了半天，发现是测试店铺的登录态过期了，而生产环境的 Token 刷新逻辑没有同步到测试流程里。
测试环境因为长期不更新，悄悄腐烂了。
从那以后，我们把测试环境的配置刷新也纳入了每日的自动任务里。
每天凌晨在回归测试之前，先跑一遍“登录态检查与刷新”流程，确保测试环境状态和生产保持一致。
很多团队最开始都会忽略测试环境的持续维护。
直到某天测试全红，才发现是环境问题，而不是代码问题。
浪费排查的几小时，如果能提前花半小时维护环境，就完全不会发生。
十、写在最后
自动化流程的测试，在很多团队眼里是奢侈品。
“流程能跑就行了，为什么要花时间写测试？”
当店铺只有几个的时候，这种想法可能没问题。
但当店铺数量上去、平台规则频繁变动、团队里不只一个人修改流程的时候，
没有测试的流程，就是一座没有护栏的桥。
我们从零到一搭建这套测试体系，花了将近一个月。
但这个月换来的，是流程变更不再需要运维通宵盯盘，是平台突然改版后第一时间发现的告警。
如果你正在做店群自动化，希望这篇复盘能让你更早地把测试体系提上日程。
它不会让你的流程跑得更快，但会让你的系统更值得信任。
作者：林焱