做任务系统的自动化测试做了几年最常被问到的一类问题是某个成长任务面板上那十几个任务能不能不点界面直接用接口一次性跑完。这个问题背后其实藏着一条完整的工程链路——行为事件上报链怎么还原、协议怎么固化、状态怎么推进最后才谈得上纯接口自动领奖。这次我把这套东西从头到尾拆一遍讲清楚17个成长任务是怎么被一条脚本串起来的每一环为什么这么设计中间哪些地方最容易翻车。这篇内容适合三类人看做过客户端埋点或服务端任务系统的后端同学、想学接口自动化但只会用现成工具的测试同学、以及对从抓包到协议还原这条路径好奇的工程爱好者。读完之后你应该能自己搭一套结构类似的任务编排脚本跑在你自己的测试环境里。先说明一件事下文所有分析对象都是我自己搭建的模拟成长任务系统和它对应的测试客户端所有协议都是我这边环境里的字段讲的是方法论不是某个线上产品的操作说明书。涉及真实业务系统时动手之前先确认你有授权这一点没有例外。1. 先把问题拆开这个一键完成到底在做什么1.1 成长任务的四段式生命周期很多人一上来就想直接调领奖接口结果必然失败。成长任务这件事从系统设计的角度看是四个阶段串起来的事件采集 → 事件上报 → 服务端校验与进度累加 → 达标发奖。这四个阶段是严格串行的前一个没走完后一个连门都进不去。拿最常见的完成3次收藏这个任务举例。客户端在用户点击收藏时本地SDK先记一条行为事件塞进队列到了上报时机这条事件被打包发到服务端服务端拿到事件后先做合法性和防重放校验再判断它是否匹配某个任务的条件匹配上了任务进度从1变成2再变成3进度达到目标值后任务状态从进行中翻转为可领取最后一步才是用户点领取服务端发放奖励并把状态置为已领取。这四段里普通用户只感知到第三段的进度条和第四段的小红点但自动化要复现的是全链路。你得让服务端相信用户真的收藏了三次而这件事的唯一凭证就是那条事件上报请求。所以整件事的命门不在领奖接口而在上报链的结构还原上。1.2 为什么绕开界面直接调接口反而更稳有同学会问既然有界面用UI自动化点不就完了我试过17个任务用UI脚本跑平均要在30分钟左右失败率接近三成。原因很朴素界面层耦合了太多跟业务无关的东西——页面加载动画、元素定位、滚动位置、弹窗拦截、版本改版导致的选择器失效。任何一样出问题整条脚本就断了。而接口层的调用只有三件事请求能不能构造对、签名能不能算对、服务端状态机能不能推进对。前两件是确定性的第三件可以通过轮询拿到明确的结果。确定性的东西就好办能重试、能复现、能加日志。还有个更实际的原因很多成长任务的触发条件在界面上根本不好模拟。比如首次在XX页面停留超过60秒你总不能在UI脚本里真的干等一分钟但在事件层这条事件就是一次带时长字段的上报构造起来干净利落。所以纯接口方案不只是快它解决的是事件条件难以在UI层复现这个根本问题。注意这里的稳是建立在协议已经被完整还原、且你拥有合法测试权限的前提下的。协议还原不完整时接口方案的失败率会比UI方案更高因为UI至少能靠肉眼看出卡在哪一步。1.3 合规边界能做什么碰不得什么这条得单独拎出来说因为这件事很容易滑到不该去的地方。我给自己定的边界是三条只用在自己拥有或已获书面授权的系统上只用于自动化测试、压测、回归验证这类正当工程目的不用于规避任何平台的规则去获取不当利益。具体到操作层面如果你分析的是你自己的系统那随便拆这是你的资产如果是合作方提供的测试环境先拿到明确的测试授权和接口说明如果是别人的线上系统那就到此为止看看设计思路就够了别往下走。很多同学栽跟头不是因为技术问题是因为把我想学协议设计和我要拿它做点什么混为一谈了。前者值得鼓励后者风险自负。2. 行为事件上报链的结构还原2.1 事件模型一条上报到底带了什么我这边环境里一条行为事件的请求体大概长这样。字段名做了脱敏但结构是完整的{ event_id: e_20240518143012_a7f3, event_type: collect_item, occur_ts: 1716013812, client_seq: 128, session_id: s_9c1e4b..., device_id: d_5f2a..., app_version: 3.7.2, extra: {item_id: 1024, page: detail}, nonce: 8f3c1a9d, sign: b41d9e... }这十来个字段各有各的用处缺一个都可能被打回。event_type是业务语义服务端靠它匹配任务条件occur_ts是事件真实发生的时间用来做时间窗口校验一般允许的正负偏差在300秒左右client_seq是客户端自增序号服务端用它做顺序校验防止乱序nonce是随机串用于去重sign是签名防篡改。我一开始以为client_seq只是个摆设结果有一次本地调试时偷懒固定成1连续上报十几条服务端全部接收了但进度只增加了1——原因是服务端用(device_id, client_seq)做了幂等键。这个细节如果不抓包对比多次请求根本发现不了。所以还原一条链路最重要的动作是对同一种行为抓三次以上的包逐字段做diff把变的和不变的区分开。变的通常是时间戳、随机数、序号、签名不变的是设备和版本信息。分清楚这两类模型就立起来了。2.2 签名与防重放那串 sign 是怎么算出来的签名是整条链路上最硬的一关也是最容易让人卡住的地方。常见的做法是把参与签名的字段按字典序排序拼成keyvaluekeyvalue的形式末尾追加密钥再做一次哈希。我这边环境的实现是 HMAC-SHA256import hmac, hashlib, time, uuid def build_sign(params: dict, secret: str) - str: items sorted((k, str(v)) for k, v in params.items() if k ! sign) raw .join(f{k}{v} for k, v in items) return hmac.new(secret.encode(), raw.encode(), hashlib.sha256).hexdigest()看着简单但实际还原时有三个坑第一哪些字段参与签名。有的实现是全字段参与有的是白名单有的会把sign之外的全部算进去。判断方法是做对照实验构造两个请求只改动某个字段看服务端返回的是签名错误还是参数错误。返回签名错误说明该字段参与了签名反之则没有。这个技巧我用得最多靠逐字段试探就能把签名范围圈出来。第二拼接格式的细节。还是|还是:值要不要URL编码空值参不参与——这些都是要靠报错反推的。我的做法是先实现一版跑一遍错就调整格式一般五六轮之内能对上。第三密钥从哪来。这一步在自有环境里很简单读取本地配置就行。但要注意密钥可能有版本跟着app_version走。我把密钥做成可配置项放在独立文件里切换版本时只改配置不改代码。防重放这边服务端一般做两件事occur_ts跟服务器时间比对超窗口直接拒nonce在缓存里查存在就拒不存在则写入并设置TTL我这边是600秒。这意味着自动化脚本每次上报都必须生成新的 nonce而且时间戳要用当前时间而不是随便填。我用固定时间戳调试过一次前几条成功后面全被拒排查了半小时才反应过来是时间窗口的问题。2.3 服务端校验的三道闸门搞清楚了请求怎么构造还得搞清楚服务端会拦什么。我实测下来这类任务系统的校验大致分三道闸门校验内容失败表现应对思路第一道身份与签名令牌有效性、签名正确性、时间窗口401 / 签名错误保证会话新鲜、签名逻辑逐字段对齐第二道事件合法性事件类型是否注册、字段是否完整、序号是否递增参数错误 / 静默丢弃字段严格按抓包结果构造序号单调递增第三道行为合理性事件间隔、单日频次、序列是否符合业务逻辑200但进度不动加随机间隔、控制速率、按真实操作顺序编排第三道闸门最值得说。它不报错就默默不给你加进度你从返回体上完全看不出来。我第一次遇到的时候以为是签名问题反复排查了两个小时最后把请求间隔从50毫秒改成1.2秒才发现通了。后来我总结凡是返回成功但状态没变化的先怀疑频率和序列再怀疑其他。序列这块也有讲究。比如浏览商品→加入收藏→下单这类任务链服务端可能校验前置事件是否存在你直接发下单事件它不会报错但也不会算数。所以任务编排不能只看单个任务的条件要把任务之间的依赖关系也排进去。2.4 版本差异与字段漂移协议不是一成不变的。我这边的测试客户端在两个版本之间做了三次调整新增了一个channel字段、extra从字符串改成了对象、client_seq的起始值从0变成了1。每一次改动都让上一版脚本报废。应对办法是把协议描述从代码里抽出来做成独立配置。代码只负责读配置→构造请求→发出去→解析回包具体字段长什么样由配置决定。这样版本一变改的是配置文件不是逻辑代码改动量和出错面都小一个数量级。这个思路后面第3节会展开讲。3. 从抓包到可复用协议把链路固化成配置3.1 抓包与字段清洗抓包本身没什么技术含量难的是清洗。原始抓包里混着大量跟自动化无关的东西Cookie里一堆统计标识、请求头里的浏览器指纹、一堆用不上的埋点事件。直接照抄的结果就是脚本又长又脆改一处崩一片。我的清洗原则是三条只保留服务端真正校验的字段、把可变字段参数化、把固定字段提到公共配置里。判断真正校验的方法是删字段测试——从上往下一个个删删掉之后报参数错误的就留下删掉没影响的就去掉。这个过程有点笨但一轮下来能砍掉三成以上的冗余字段。清洗完之后一条请求应该只剩下三类东西公共头设备、版本、令牌、事件主体类型、时间、序号、扩展、安全字段nonce、签名。分好类之后配置文件的结构自然就出来了。3.2 协议描述文件设计我用 YAML 来描述协议一个任务对应一个条目大致长这样tasks: - key: collect_3 name: 完成3次收藏 event_type: collect_item repeat: 3 extra_template: item_id: ${rand_item} page: detail interval_ms: [900, 1600] verify: progress_api: /task/progress task_key: collect_3 target: 3这份配置干了几件事告诉执行器要发什么事件、发几次、每次的扩展字段怎么填、间隔多久、发完之后用哪个接口去验证进度。${rand_item}这种占位符在执行时会被替换成随机值避免每次上报的item_id都一样触发重复判定。有了这层抽象17个任务的编排就从写17段代码变成了写17条配置。加任务、改参数、调间隔全在配置里完成。我后来把这个文件扩展到了四十多条代码一行没动。3.3 状态机驱动17个任务怎么排任务之间不是完全独立的。有些任务有前置依赖有些共享同一个事件类型有些领奖之后会刷新出新任务。所以执行器不能简单地 for 循环遍历得有个状态机。我把每个任务的状态定义为四个未开始、进行中、可领取、已领取。执行器的工作就是把这个状态往前推。STATE_TODO, STATE_DOING, STATE_CLAIMABLE, STATE_DONE range(4) def run_task(ctx, task): # 阶段一先查当前状态已领过的直接跳过 prog ctx.query_progress(task[key]) if prog[status] claimed: return STATE_DONE # 阶段二补事件直到进度达标 need prog[target] - prog[current] for _ in range(need): ctx.send_event(task[event_type], ctx.render(task.get(extra_template))) ctx.sleep_random(*task.get(interval_ms, [800, 1500])) # 阶段三轮询确认进度 if not ctx.wait_until(lambda: ctx.query_progress(task[key])[status] claimable, timeout10): return STATE_DOING # 阶段四领奖 ctx.claim(task[key]) return STATE_DONE这段逻辑最关键的地方是先查状态再补事件而不是无脑发满次数。原因很实际脚本可能中途断掉重跑如果每次都发满3次第二次跑就会超额上报触发频率限制。先查差多少补多少天然就是幂等的断了重跑也不会出问题。另外need可能为0进度已经够了但没领奖这时候直接跳到轮询和领奖阶段。这种情况在重跑时非常常见处理不好就会白跑一轮。4. 纯接口自动领奖的实现细节4.1 会话与凭证管理所有请求都依赖一个有效的会话。凭证一般是登录后拿到的令牌有效期从几十分钟到几天不等。这里有两个实践点一是令牌要带过期时间做本地缓存。我一开始每次跑脚本都重新登录结果触发了登录频次限制。后来改成把令牌和时间戳存到本地文件剩余有效期超过10分钟就直接复用低于阈值再重新登录。这个改动让脚本的整体耗时降了不少。二是令牌失效要有统一的处理入口。服务端返回401的时候不能简单抛异常应该触发一次重新登录再重放当前请求最多重试一次。重试还失败就停下来报错别死循环。我在封装层统一做了这件事业务代码里完全不用关心令牌。4.2 事件上报的构造与发送上报请求的构造分三步填模板、补动态字段、算签名。顺序不能乱因为签名依赖前面的所有字段。def send_event(ctx, event_type, extra): now int(time.time()) ctx.seq 1 body { event_id: fe_{now}_{uuid.uuid4().hex[:6]}, event_type: event_type, occur_ts: now, client_seq: ctx.seq, session_id: ctx.session_id, device_id: ctx.device_id, app_version: ctx.app_version, extra: extra, nonce: uuid.uuid4().hex[:8], } body[sign] build_sign(body, ctx.secret) resp ctx.post(/event/report, jsonbody, timeout8) return resp.json()这里的client_seq是进程内自增的注意不要每次都从1开始——如果服务端用(device_id, client_seq)做幂等重启脚本后序号回退就会造成新事件被当成重复丢弃。我的做法是把 seq 也持久化到本地状态文件里启动时读出来接着往下走。4.3 任务进度轮询与领奖判定上报成功后不是立刻就变成可领取服务端可能有异步处理。所以中间要加一轮轮询。轮询策略是间隔1秒最多10次也就是10秒超时。这个参数是根据我这边的处理延迟定的实测平均1.5秒内会更新10秒是留了足够余量。轮询超时之后怎么处理我的选择是标记为进行中、跳过、继续跑下一个任务全部跑完之后再回头重试一轮。这样能避免因为某个任务卡住拖垮整个流程。第二轮还失败的单独输出到失败清单里人工看。领奖请求本身很简单带上任务key就行。但要注意两点一是领奖也要做幂等保护同一任务重复领奖应该返回明确的状态码而不是报错二是领奖成功后最好再查一次状态确认真的变成已领取有些实现是在异步发放的。4.4 限速、重试与幂等限速这块我踩了最多次坑。参数是这么定的参数取值依据单事件间隔800~1600ms 随机低于500ms时连续发会出现进度不增全局QPS不超过2超过后偶发429单任务重试最多2次再多会放大风控触发概率重试退避1s / 3s指数退避避免集中重放轮询间隔1000ms服务端处理延迟均值1.5s以内随机间隔比固定间隔有效得多。固定间隔的特征太明显服务端如果要统计间隔方差一眼就能看出来。我在间隔上加了±30%的抖动之后成功率明显提升。当然这不是教你去对抗检测而是在真实的自动化测试里人类操作本来就有随机性脚本模拟得更接近真实反而更少产生脏数据。重试要区分错误类型。网络超时、5xx 这类可以重试4xx 里的参数错误、签名错误不要重试重试一百次结果都一样只会刷日志。我在封装层按状态码分流5xx 和超时进重试队列4xx 直接抛出并记录请求体方便排查。5. 常见问题与排查速查5.1 签名类问题签名错误是最常见的问题表现形式是明确的报错好排查。但有一种隐蔽情况报错信息统一是请求非法不告诉你是哪个字段。这时候就要用二分法把参数字段分成两半先只对一半签看结果逐步缩小范围直到定位。我把踩过的坑整理成了速查表现象最可能原因快速验证方法全部请求签名错误密钥不对或拼接分隔符不对用抓包里的原始数据反算看能否复现出同样的sign部分字段改了才报错签名白名单不完整逐字段改动做对照测试时间戳用本地时间报错服务器时区或时钟偏移先调一次时间接口取服务端时间再算偶发签名错误排序不稳定或浮点数格式化差异强制把所有值转字符串再排序中文参数报错编码方式不一致统一UTF-8并检查是否做了URL编码第一行的方法最好用拿一条抓包记录里的完整参数在本地反复算直到算出的 sign 跟抓包完全一致。这一步通过了说明算法、密钥、拼接格式全对后面就只是参数构造的问题了。这一步过不了后面全是白费。5.2 进度不刷新与领奖失败这类问题最磨人因为没报错。我遇到过四种情况第一种是频率太高前面提过加间隔就好。第二种是事件序列不对服务端要求某个前置事件先存在得调整任务执行顺序或者补发前置事件。第三种是单日次数上限我在测试环境里跑太多轮触发了第二天才恢复。第四种最隐蔽——extra里的字段用了固定值服务端做了去重同一条内容重复上报不算新的行为。领奖失败一般是三种原因任务没真正达标进度查询和领奖接口的判断条件不一致、已经领过、奖励库存不足测试环境常见。排查顺序是先查进度再查领取记录两个都对还失败就是服务端问题直接看日志。提示调试阶段建议打开完整的请求/响应日志把每次上报的 body 和返回都落到文件里。出问题时能直接对比成功那次和失败那次的差异比凭记忆猜快十倍。5.3 稳定性与并发单任务串行跑17个任务正常情况下一分半到两分钟能跑完。想提速的话可以小并发但并发度一旦超过3失败率就往上窜而且失败原因很难归因——你不知道是并发导致的风控还是某个任务本身的逻辑问题。我的建议是默认串行把并发当成一个需要谨慎开启的选项。真要做并发按任务之间是否有依赖关系分组无依赖的组内并发有依赖的串行。同时给并发加一个全局令牌桶保证整体QPS不超过阈值。还有一个稳定性细节脚本要能处理中途的意外中断。我的做法是每完成一个任务就把状态写进本地 JSON 文件重跑时先读状态跳过已完成的。这个改动看起来很小但让调试体验好了非常多——不用每次都从头跑一遍。6. 面板化与工程收尾6.1 面板该有什么脚本能跑之后下一步自然是做成面板。我做的面板很简单一个表格列出17个任务每行显示状态、进度、最后一次操作时间和错误信息顶部两个按钮全量执行、只跑失败项。右半边是一块实时日志区。面板的价值不在于好看在于把不确定性可视化。之前排查一个偶发失败翻日志翻得头大有了面板之后一眼就能看到某个任务连续三次都是上报成功但进度不增直接锁定是频率问题。技术上用什么不重要我用的就是最简单的本地Web页面加一个执行器进程通过文件或内存队列通信。轻量、改起来快、不用维护额外服务。6.2 可观测性与回归测试自动化脚本最怕的是今天能跑下周不能跑而且不知道为什么。解决办法是留痕。我做了三层记录请求层记完整 body 和响应脱敏后任务层记状态流转会话层记登录和令牌续期。三层结合起来任何一次异常都能回溯到具体是哪一层的问题。另外每次协议有变更我都会用固定的一组黄金样本跑一次回归把抓包保存下来的请求凝固成测试用例验证签名函数、字段构造、解析逻辑是否还对得上。这样版本升级的时候能在脚本真正跑之前就发现不兼容的地方。6.3 我踩过的几个坑最后分享三条我觉得最值钱的经验。第一条不要过早优化。我一开始就想把17个任务做成完全数据驱动的通用框架结果配置写了一堆抽象层实际只用到了三成。后来砍掉多余抽象老老实实一条配置对应一个任务反而维护成本最低。抽象是在重复出现第三次之后才值得做的事。第二条日志要在动手前就设计好。前两版脚本我都是先写逻辑后加日志结果每次出问题都要重新加打点、重跑、再等失败复现。第三版我一开始就把请求、响应、状态、耗时全都落下来后面排查问题的速度提升了不止一倍。日志不是负担是调试时唯一可信的东西。第三条把不确定当成一等公民。接口返回成功不代表业务成功进度加了不代表任务完成任务完成不代表奖励到账。每一步都要有独立的确认动作。我现在的流程里领奖之后一定会再查一次最终状态就是为了堵住这个缺口。多做一次查询比事后补数据省事得多。这套东西跑下来我最深的体会是所谓一键完成本质上不是某个神奇的工具或脚本而是对整个链路理解的完整度。链路还原得越细脚本就越短、越稳。反过来只要还有一环是靠猜的那这个脚本迟早会在某个你想不到的地方断掉。什么时候你能把一条上报请求的每个字段为什么存在都说清楚什么时候这件事就真的做完了。
做任务系统的自动化测试做了几年最常被问到的一类问题是某个成长任务面板上那十几个任务能不能不点界面直接用接口一次性跑完。这个问题背后其实藏着一条完整的工程链路——行为事件上报链怎么还原、协议怎么固化、状态怎么推进最后才谈得上纯接口自动领奖。这次我把这套东西从头到尾拆一遍讲清楚17个成长任务是怎么被一条脚本串起来的每一环为什么这么设计中间哪些地方最容易翻车。这篇内容适合三类人看做过客户端埋点或服务端任务系统的后端同学、想学接口自动化但只会用现成工具的测试同学、以及对从抓包到协议还原这条路径好奇的工程爱好者。读完之后你应该能自己搭一套结构类似的任务编排脚本跑在你自己的测试环境里。先说明一件事下文所有分析对象都是我自己搭建的模拟成长任务系统和它对应的测试客户端所有协议都是我这边环境里的字段讲的是方法论不是某个线上产品的操作说明书。涉及真实业务系统时动手之前先确认你有授权这一点没有例外。1. 先把问题拆开这个一键完成到底在做什么1.1 成长任务的四段式生命周期很多人一上来就想直接调领奖接口结果必然失败。成长任务这件事从系统设计的角度看是四个阶段串起来的事件采集 → 事件上报 → 服务端校验与进度累加 → 达标发奖。这四个阶段是严格串行的前一个没走完后一个连门都进不去。拿最常见的完成3次收藏这个任务举例。客户端在用户点击收藏时本地SDK先记一条行为事件塞进队列到了上报时机这条事件被打包发到服务端服务端拿到事件后先做合法性和防重放校验再判断它是否匹配某个任务的条件匹配上了任务进度从1变成2再变成3进度达到目标值后任务状态从进行中翻转为可领取最后一步才是用户点领取服务端发放奖励并把状态置为已领取。这四段里普通用户只感知到第三段的进度条和第四段的小红点但自动化要复现的是全链路。你得让服务端相信用户真的收藏了三次而这件事的唯一凭证就是那条事件上报请求。所以整件事的命门不在领奖接口而在上报链的结构还原上。1.2 为什么绕开界面直接调接口反而更稳有同学会问既然有界面用UI自动化点不就完了我试过17个任务用UI脚本跑平均要在30分钟左右失败率接近三成。原因很朴素界面层耦合了太多跟业务无关的东西——页面加载动画、元素定位、滚动位置、弹窗拦截、版本改版导致的选择器失效。任何一样出问题整条脚本就断了。而接口层的调用只有三件事请求能不能构造对、签名能不能算对、服务端状态机能不能推进对。前两件是确定性的第三件可以通过轮询拿到明确的结果。确定性的东西就好办能重试、能复现、能加日志。还有个更实际的原因很多成长任务的触发条件在界面上根本不好模拟。比如首次在XX页面停留超过60秒你总不能在UI脚本里真的干等一分钟但在事件层这条事件就是一次带时长字段的上报构造起来干净利落。所以纯接口方案不只是快它解决的是事件条件难以在UI层复现这个根本问题。注意这里的稳是建立在协议已经被完整还原、且你拥有合法测试权限的前提下的。协议还原不完整时接口方案的失败率会比UI方案更高因为UI至少能靠肉眼看出卡在哪一步。1.3 合规边界能做什么碰不得什么这条得单独拎出来说因为这件事很容易滑到不该去的地方。我给自己定的边界是三条只用在自己拥有或已获书面授权的系统上只用于自动化测试、压测、回归验证这类正当工程目的不用于规避任何平台的规则去获取不当利益。具体到操作层面如果你分析的是你自己的系统那随便拆这是你的资产如果是合作方提供的测试环境先拿到明确的测试授权和接口说明如果是别人的线上系统那就到此为止看看设计思路就够了别往下走。很多同学栽跟头不是因为技术问题是因为把我想学协议设计和我要拿它做点什么混为一谈了。前者值得鼓励后者风险自负。2. 行为事件上报链的结构还原2.1 事件模型一条上报到底带了什么我这边环境里一条行为事件的请求体大概长这样。字段名做了脱敏但结构是完整的{ event_id: e_20240518143012_a7f3, event_type: collect_item, occur_ts: 1716013812, client_seq: 128, session_id: s_9c1e4b..., device_id: d_5f2a..., app_version: 3.7.2, extra: {item_id: 1024, page: detail}, nonce: 8f3c1a9d, sign: b41d9e... }这十来个字段各有各的用处缺一个都可能被打回。event_type是业务语义服务端靠它匹配任务条件occur_ts是事件真实发生的时间用来做时间窗口校验一般允许的正负偏差在300秒左右client_seq是客户端自增序号服务端用它做顺序校验防止乱序nonce是随机串用于去重sign是签名防篡改。我一开始以为client_seq只是个摆设结果有一次本地调试时偷懒固定成1连续上报十几条服务端全部接收了但进度只增加了1——原因是服务端用(device_id, client_seq)做了幂等键。这个细节如果不抓包对比多次请求根本发现不了。所以还原一条链路最重要的动作是对同一种行为抓三次以上的包逐字段做diff把变的和不变的区分开。变的通常是时间戳、随机数、序号、签名不变的是设备和版本信息。分清楚这两类模型就立起来了。2.2 签名与防重放那串 sign 是怎么算出来的签名是整条链路上最硬的一关也是最容易让人卡住的地方。常见的做法是把参与签名的字段按字典序排序拼成keyvaluekeyvalue的形式末尾追加密钥再做一次哈希。我这边环境的实现是 HMAC-SHA256import hmac, hashlib, time, uuid def build_sign(params: dict, secret: str) - str: items sorted((k, str(v)) for k, v in params.items() if k ! sign) raw .join(f{k}{v} for k, v in items) return hmac.new(secret.encode(), raw.encode(), hashlib.sha256).hexdigest()看着简单但实际还原时有三个坑第一哪些字段参与签名。有的实现是全字段参与有的是白名单有的会把sign之外的全部算进去。判断方法是做对照实验构造两个请求只改动某个字段看服务端返回的是签名错误还是参数错误。返回签名错误说明该字段参与了签名反之则没有。这个技巧我用得最多靠逐字段试探就能把签名范围圈出来。第二拼接格式的细节。还是|还是:值要不要URL编码空值参不参与——这些都是要靠报错反推的。我的做法是先实现一版跑一遍错就调整格式一般五六轮之内能对上。第三密钥从哪来。这一步在自有环境里很简单读取本地配置就行。但要注意密钥可能有版本跟着app_version走。我把密钥做成可配置项放在独立文件里切换版本时只改配置不改代码。防重放这边服务端一般做两件事occur_ts跟服务器时间比对超窗口直接拒nonce在缓存里查存在就拒不存在则写入并设置TTL我这边是600秒。这意味着自动化脚本每次上报都必须生成新的 nonce而且时间戳要用当前时间而不是随便填。我用固定时间戳调试过一次前几条成功后面全被拒排查了半小时才反应过来是时间窗口的问题。2.3 服务端校验的三道闸门搞清楚了请求怎么构造还得搞清楚服务端会拦什么。我实测下来这类任务系统的校验大致分三道闸门校验内容失败表现应对思路第一道身份与签名令牌有效性、签名正确性、时间窗口401 / 签名错误保证会话新鲜、签名逻辑逐字段对齐第二道事件合法性事件类型是否注册、字段是否完整、序号是否递增参数错误 / 静默丢弃字段严格按抓包结果构造序号单调递增第三道行为合理性事件间隔、单日频次、序列是否符合业务逻辑200但进度不动加随机间隔、控制速率、按真实操作顺序编排第三道闸门最值得说。它不报错就默默不给你加进度你从返回体上完全看不出来。我第一次遇到的时候以为是签名问题反复排查了两个小时最后把请求间隔从50毫秒改成1.2秒才发现通了。后来我总结凡是返回成功但状态没变化的先怀疑频率和序列再怀疑其他。序列这块也有讲究。比如浏览商品→加入收藏→下单这类任务链服务端可能校验前置事件是否存在你直接发下单事件它不会报错但也不会算数。所以任务编排不能只看单个任务的条件要把任务之间的依赖关系也排进去。2.4 版本差异与字段漂移协议不是一成不变的。我这边的测试客户端在两个版本之间做了三次调整新增了一个channel字段、extra从字符串改成了对象、client_seq的起始值从0变成了1。每一次改动都让上一版脚本报废。应对办法是把协议描述从代码里抽出来做成独立配置。代码只负责读配置→构造请求→发出去→解析回包具体字段长什么样由配置决定。这样版本一变改的是配置文件不是逻辑代码改动量和出错面都小一个数量级。这个思路后面第3节会展开讲。3. 从抓包到可复用协议把链路固化成配置3.1 抓包与字段清洗抓包本身没什么技术含量难的是清洗。原始抓包里混着大量跟自动化无关的东西Cookie里一堆统计标识、请求头里的浏览器指纹、一堆用不上的埋点事件。直接照抄的结果就是脚本又长又脆改一处崩一片。我的清洗原则是三条只保留服务端真正校验的字段、把可变字段参数化、把固定字段提到公共配置里。判断真正校验的方法是删字段测试——从上往下一个个删删掉之后报参数错误的就留下删掉没影响的就去掉。这个过程有点笨但一轮下来能砍掉三成以上的冗余字段。清洗完之后一条请求应该只剩下三类东西公共头设备、版本、令牌、事件主体类型、时间、序号、扩展、安全字段nonce、签名。分好类之后配置文件的结构自然就出来了。3.2 协议描述文件设计我用 YAML 来描述协议一个任务对应一个条目大致长这样tasks: - key: collect_3 name: 完成3次收藏 event_type: collect_item repeat: 3 extra_template: item_id: ${rand_item} page: detail interval_ms: [900, 1600] verify: progress_api: /task/progress task_key: collect_3 target: 3这份配置干了几件事告诉执行器要发什么事件、发几次、每次的扩展字段怎么填、间隔多久、发完之后用哪个接口去验证进度。${rand_item}这种占位符在执行时会被替换成随机值避免每次上报的item_id都一样触发重复判定。有了这层抽象17个任务的编排就从写17段代码变成了写17条配置。加任务、改参数、调间隔全在配置里完成。我后来把这个文件扩展到了四十多条代码一行没动。3.3 状态机驱动17个任务怎么排任务之间不是完全独立的。有些任务有前置依赖有些共享同一个事件类型有些领奖之后会刷新出新任务。所以执行器不能简单地 for 循环遍历得有个状态机。我把每个任务的状态定义为四个未开始、进行中、可领取、已领取。执行器的工作就是把这个状态往前推。STATE_TODO, STATE_DOING, STATE_CLAIMABLE, STATE_DONE range(4) def run_task(ctx, task): # 阶段一先查当前状态已领过的直接跳过 prog ctx.query_progress(task[key]) if prog[status] claimed: return STATE_DONE # 阶段二补事件直到进度达标 need prog[target] - prog[current] for _ in range(need): ctx.send_event(task[event_type], ctx.render(task.get(extra_template))) ctx.sleep_random(*task.get(interval_ms, [800, 1500])) # 阶段三轮询确认进度 if not ctx.wait_until(lambda: ctx.query_progress(task[key])[status] claimable, timeout10): return STATE_DOING # 阶段四领奖 ctx.claim(task[key]) return STATE_DONE这段逻辑最关键的地方是先查状态再补事件而不是无脑发满次数。原因很实际脚本可能中途断掉重跑如果每次都发满3次第二次跑就会超额上报触发频率限制。先查差多少补多少天然就是幂等的断了重跑也不会出问题。另外need可能为0进度已经够了但没领奖这时候直接跳到轮询和领奖阶段。这种情况在重跑时非常常见处理不好就会白跑一轮。4. 纯接口自动领奖的实现细节4.1 会话与凭证管理所有请求都依赖一个有效的会话。凭证一般是登录后拿到的令牌有效期从几十分钟到几天不等。这里有两个实践点一是令牌要带过期时间做本地缓存。我一开始每次跑脚本都重新登录结果触发了登录频次限制。后来改成把令牌和时间戳存到本地文件剩余有效期超过10分钟就直接复用低于阈值再重新登录。这个改动让脚本的整体耗时降了不少。二是令牌失效要有统一的处理入口。服务端返回401的时候不能简单抛异常应该触发一次重新登录再重放当前请求最多重试一次。重试还失败就停下来报错别死循环。我在封装层统一做了这件事业务代码里完全不用关心令牌。4.2 事件上报的构造与发送上报请求的构造分三步填模板、补动态字段、算签名。顺序不能乱因为签名依赖前面的所有字段。def send_event(ctx, event_type, extra): now int(time.time()) ctx.seq 1 body { event_id: fe_{now}_{uuid.uuid4().hex[:6]}, event_type: event_type, occur_ts: now, client_seq: ctx.seq, session_id: ctx.session_id, device_id: ctx.device_id, app_version: ctx.app_version, extra: extra, nonce: uuid.uuid4().hex[:8], } body[sign] build_sign(body, ctx.secret) resp ctx.post(/event/report, jsonbody, timeout8) return resp.json()这里的client_seq是进程内自增的注意不要每次都从1开始——如果服务端用(device_id, client_seq)做幂等重启脚本后序号回退就会造成新事件被当成重复丢弃。我的做法是把 seq 也持久化到本地状态文件里启动时读出来接着往下走。4.3 任务进度轮询与领奖判定上报成功后不是立刻就变成可领取服务端可能有异步处理。所以中间要加一轮轮询。轮询策略是间隔1秒最多10次也就是10秒超时。这个参数是根据我这边的处理延迟定的实测平均1.5秒内会更新10秒是留了足够余量。轮询超时之后怎么处理我的选择是标记为进行中、跳过、继续跑下一个任务全部跑完之后再回头重试一轮。这样能避免因为某个任务卡住拖垮整个流程。第二轮还失败的单独输出到失败清单里人工看。领奖请求本身很简单带上任务key就行。但要注意两点一是领奖也要做幂等保护同一任务重复领奖应该返回明确的状态码而不是报错二是领奖成功后最好再查一次状态确认真的变成已领取有些实现是在异步发放的。4.4 限速、重试与幂等限速这块我踩了最多次坑。参数是这么定的参数取值依据单事件间隔800~1600ms 随机低于500ms时连续发会出现进度不增全局QPS不超过2超过后偶发429单任务重试最多2次再多会放大风控触发概率重试退避1s / 3s指数退避避免集中重放轮询间隔1000ms服务端处理延迟均值1.5s以内随机间隔比固定间隔有效得多。固定间隔的特征太明显服务端如果要统计间隔方差一眼就能看出来。我在间隔上加了±30%的抖动之后成功率明显提升。当然这不是教你去对抗检测而是在真实的自动化测试里人类操作本来就有随机性脚本模拟得更接近真实反而更少产生脏数据。重试要区分错误类型。网络超时、5xx 这类可以重试4xx 里的参数错误、签名错误不要重试重试一百次结果都一样只会刷日志。我在封装层按状态码分流5xx 和超时进重试队列4xx 直接抛出并记录请求体方便排查。5. 常见问题与排查速查5.1 签名类问题签名错误是最常见的问题表现形式是明确的报错好排查。但有一种隐蔽情况报错信息统一是请求非法不告诉你是哪个字段。这时候就要用二分法把参数字段分成两半先只对一半签看结果逐步缩小范围直到定位。我把踩过的坑整理成了速查表现象最可能原因快速验证方法全部请求签名错误密钥不对或拼接分隔符不对用抓包里的原始数据反算看能否复现出同样的sign部分字段改了才报错签名白名单不完整逐字段改动做对照测试时间戳用本地时间报错服务器时区或时钟偏移先调一次时间接口取服务端时间再算偶发签名错误排序不稳定或浮点数格式化差异强制把所有值转字符串再排序中文参数报错编码方式不一致统一UTF-8并检查是否做了URL编码第一行的方法最好用拿一条抓包记录里的完整参数在本地反复算直到算出的 sign 跟抓包完全一致。这一步通过了说明算法、密钥、拼接格式全对后面就只是参数构造的问题了。这一步过不了后面全是白费。5.2 进度不刷新与领奖失败这类问题最磨人因为没报错。我遇到过四种情况第一种是频率太高前面提过加间隔就好。第二种是事件序列不对服务端要求某个前置事件先存在得调整任务执行顺序或者补发前置事件。第三种是单日次数上限我在测试环境里跑太多轮触发了第二天才恢复。第四种最隐蔽——extra里的字段用了固定值服务端做了去重同一条内容重复上报不算新的行为。领奖失败一般是三种原因任务没真正达标进度查询和领奖接口的判断条件不一致、已经领过、奖励库存不足测试环境常见。排查顺序是先查进度再查领取记录两个都对还失败就是服务端问题直接看日志。提示调试阶段建议打开完整的请求/响应日志把每次上报的 body 和返回都落到文件里。出问题时能直接对比成功那次和失败那次的差异比凭记忆猜快十倍。5.3 稳定性与并发单任务串行跑17个任务正常情况下一分半到两分钟能跑完。想提速的话可以小并发但并发度一旦超过3失败率就往上窜而且失败原因很难归因——你不知道是并发导致的风控还是某个任务本身的逻辑问题。我的建议是默认串行把并发当成一个需要谨慎开启的选项。真要做并发按任务之间是否有依赖关系分组无依赖的组内并发有依赖的串行。同时给并发加一个全局令牌桶保证整体QPS不超过阈值。还有一个稳定性细节脚本要能处理中途的意外中断。我的做法是每完成一个任务就把状态写进本地 JSON 文件重跑时先读状态跳过已完成的。这个改动看起来很小但让调试体验好了非常多——不用每次都从头跑一遍。6. 面板化与工程收尾6.1 面板该有什么脚本能跑之后下一步自然是做成面板。我做的面板很简单一个表格列出17个任务每行显示状态、进度、最后一次操作时间和错误信息顶部两个按钮全量执行、只跑失败项。右半边是一块实时日志区。面板的价值不在于好看在于把不确定性可视化。之前排查一个偶发失败翻日志翻得头大有了面板之后一眼就能看到某个任务连续三次都是上报成功但进度不增直接锁定是频率问题。技术上用什么不重要我用的就是最简单的本地Web页面加一个执行器进程通过文件或内存队列通信。轻量、改起来快、不用维护额外服务。6.2 可观测性与回归测试自动化脚本最怕的是今天能跑下周不能跑而且不知道为什么。解决办法是留痕。我做了三层记录请求层记完整 body 和响应脱敏后任务层记状态流转会话层记登录和令牌续期。三层结合起来任何一次异常都能回溯到具体是哪一层的问题。另外每次协议有变更我都会用固定的一组黄金样本跑一次回归把抓包保存下来的请求凝固成测试用例验证签名函数、字段构造、解析逻辑是否还对得上。这样版本升级的时候能在脚本真正跑之前就发现不兼容的地方。6.3 我踩过的几个坑最后分享三条我觉得最值钱的经验。第一条不要过早优化。我一开始就想把17个任务做成完全数据驱动的通用框架结果配置写了一堆抽象层实际只用到了三成。后来砍掉多余抽象老老实实一条配置对应一个任务反而维护成本最低。抽象是在重复出现第三次之后才值得做的事。第二条日志要在动手前就设计好。前两版脚本我都是先写逻辑后加日志结果每次出问题都要重新加打点、重跑、再等失败复现。第三版我一开始就把请求、响应、状态、耗时全都落下来后面排查问题的速度提升了不止一倍。日志不是负担是调试时唯一可信的东西。第三条把不确定当成一等公民。接口返回成功不代表业务成功进度加了不代表任务完成任务完成不代表奖励到账。每一步都要有独立的确认动作。我现在的流程里领奖之后一定会再查一次最终状态就是为了堵住这个缺口。多做一次查询比事后补数据省事得多。这套东西跑下来我最深的体会是所谓一键完成本质上不是某个神奇的工具或脚本而是对整个链路理解的完整度。链路还原得越细脚本就越短、越稳。反过来只要还有一环是靠猜的那这个脚本迟早会在某个你想不到的地方断掉。什么时候你能把一条上报请求的每个字段为什么存在都说清楚什么时候这件事就真的做完了。
