让框架跑得久一点：失败继续、日志、截图、HTML 与网络现场

摘要前面几篇讲了框架如何执行 CSV、如何处理变量和状态、如何做网络断言。到这里框架已经能跑起来。但自动化测试长期使用时真正麻烦的不是失败而是失败后看不懂。这篇文章讲框架为了“失败后能排查”做了哪些设计continue_on_fail、depends_on_step、日志、截图、HTML、网络记录和最终失败汇总。自动化失败不可怕看不懂才可怕自动化测试失败很正常。可能是页面元素变了。可能是接口返回变了。可能是测试环境不稳定。可能是第三方登录弹窗多了一步确认。如果失败后只看到AssertionError: timeout排查成本就会很高。真正需要知道的是哪条用例失败 哪一步失败 当时执行的 action 是什么 target / value / expect 是什么 页面当时长什么样 HTML 是什么 捕获到了哪些网络请求 变量池里已经保存了哪些值所以第一版框架不只关注“怎么执行”也关注“失败后怎么留下现场”。continue_on_fail 控制失败后是否继续case_steps.csv最后一列是continue_on_fail比如GUEST_001,5,wait init api,wait_request,,/test-api/client/init,status200;response.code200,init_response,3,true这里的true表示这一步失败后框架可以继续执行后续步骤。为什么要这样设计因为有些场景里我不想只看到第一个失败点。比如点击游客登录后我可能想同时观察登录接口有没有发 用户信息接口有没有发 登录成功埋点有没有发如果第一个接口断言失败就立刻停止后面的接口情况就看不到了。但也不是所有失败都应该继续。比如某个步骤是强前置条件失败后后续步骤必然没有意义那就可以设置成不继续。depends_on_step 控制步骤级依赖继续执行不等于盲目执行。每一步还有一个字段depends_on_step例如GUEST_001,6,click guest login,click,guest_login_button,,,,5,true表示第 6 步依赖第 5 步。CaseRunner里会判断依赖步骤是否通过def_should_skip(self,step:StepConfig,results:list[StepResult])-bool:statuses{result.step_id:result.statusforresultinresults}returnany(statuses.get(step_id)!PASSEDforstep_idinstep.depends_on_step)如果依赖步骤失败或被跳过当前步骤就会变成skippedifself._should_skip(step,step_results):messagefDependency step failed or skipped:{step.depends_on_step}step_results.append(StepResult(case_idcase.case_id,step_idstep.step_id,step_namestep.step_name,actionstep.action,statusSKIPPED,messagemessage,))continue这让执行结果更清楚failed - 当前步骤真的执行失败 skipped - 当前步骤没执行因为前置步骤失败排查时这两种状态要分开看。StepResult 记录每一步结果框架用StepResult记录步骤结果dataclassclassStepResult:case_id:strstep_id:intstep_name:straction:strstatus:strmessage:str一条步骤执行成功后会记录StepResult(case.case_id,step.step_id,step.step_name,step.action,PASSED,detail)执行失败后会记录StepResult(case_idcase.case_id,step_idstep.step_id,step_namestep.step_name,actionstep.action,statusFAILED,messagestr(exc),)这比只抛异常更适合框架化执行。因为最后可以按用例、按步骤统一汇总而不是让错误散落在控制台输出里。失败时保存现场步骤失败后CaseRunner会调用self._save_failure_artifacts(case.case_id,step.step_id,session,recorder)核心代码是stampdatetime.now().strftime(%Y%m%d_%H%M%S)base_namef{case_id}_step_{step_id}_{stamp}session.page.screenshot(pathstr(ARTIFACTS_DIR/screenshots/f{base_name}.png),full_pageTrue,)(ARTIFACTS_DIR/html/f{base_name}.html).write_text(session.page.content(),encodingutf-8,)ifrecorderisnotNone:(ARTIFACTS_DIR/network/f{base_name}.json).write_text(recorder.dump_json(),encodingutf-8,)也就是说一步失败后会尽量保存三类现场artifacts/screenshots - 页面截图 artifacts/html - 当前页面 HTML artifacts/network - 已捕获网络请求这三个文件解决的问题不同截图看页面状态、弹窗、文案、按钮是否出现。 HTML看元素是否存在、选择器是否变化。 网络记录看接口是否发出、请求响应是否符合预期。排查时不要只看截图。比如页面看起来没问题但网络记录里可能没有目标接口或者接口有返回但 HTML 里状态文案没更新。RunLogger 记录运行过程除了失败产物框架还会写运行日志。RunLogger的核心很简单classRunLogger:def__init__(self,path:Path|NoneNone):self.pathpathorLOGS_DIR/frun_{datetime.now().strftime(%Y%m%d_%H%M%S)}.logdefwrite(self,message:str)-None:timestampdatetime.now().strftime(%Y-%m-%d %H:%M:%S)linef[{timestamp}]{message}ifmessageelsewithself.path.open(a,encodingutf-8)asfile:file.write(line\n)执行时会记录selected_case_ids run_order headed CASE START STEP running / passed / failed CASE END variables_snapshot failures log_file步骤日志由CaseRunner._log_step()生成fSTEP{step.step_id}[{status}]{step.step_name}| faction{step.action}| target{step.targetor-}| fvalue{step.valueor-}| expect{step.expector-}|{message}这对测试同学很友好。因为你能直接看到失败步骤当时使用的action、target、value和expect不用先打开 CSV 对照半天。变量快照帮助理解上下文运行结束时框架会记录变量池快照logger.json_block(variables_snapshot,summarize_variables(variables.snapshot()))网络响应里可能有 token 这类敏感或超长字段所以日志里会做摘要defsummarize_network_record(record:dict)-dict:return{method:record.get(method),url:record.get(url),status:record.get(status),request:_pick_fields(request,[eventName,loginType,productId,channelId]),response:_pick_fields(response,[code,message]),response_data:_pick_fields(response.get(data),[access_token,refresh_token,userName,isNewUser],),}这让日志既有排查价值又不会把完整 token 到处打印。当你排查assert_var失败时变量快照尤其有用。比如你可以看到guest_a guest_123 guest_a_again guest_123 guest_b guest_456这样就能判断是变量提取错了还是业务结果真的不符合预期。ResultCollector 做最终汇总最后统一判断成功失败的是ResultCollectorclassResultCollector:defadd_case_result(self,result:CaseResult)-None:self.case_results.append(result)defsummarize_failures(self)-str:lines[]forcaseinself.case_results:ifcase.statusPASSED:continuelines.append(f{case.case_id}{case.case_name}:{case.status})forstepincase.steps:ifstep.statusin{FAILED,SKIPPED}:lines.append(f step{step.step_id}{step.step_name}[{step.status}]:{step.message})return\n.join(lines)defassert_all_passed(self)-None:failed[caseforcaseinself.case_resultsifcase.status!PASSED]iffailed:raiseAssertionError(self.summarize_failures())这意味着框架可以先尽量跑完再在最后统一失败。最终 pytest 仍然会红但红的时候会带着完整的失败摘要。排错建议一次失败发生后建议按这个顺序看1. 先看控制台或 pytest 报错里的失败摘要。 2. 再看 logs/run_xxx.log确认执行顺序和失败步骤。 3. 看 artifacts/screenshots 里的截图确认页面状态。 4. 看 artifacts/network 里的 JSON确认接口是否发出以及响应内容。 5. 看 artifacts/html确认元素选择器是否变化。 6. 最后再决定是改 CSV、改 YAML、改断言还是改框架关键字。不要一失败就先改等待时间。超时可能是等待不够也可能是按钮没点到、接口路径改了、元素选择器错了、依赖步骤被跳过了。先看现场再改代码。小结这一篇要记住continue_on_fail - 控制失败后是否继续 depends_on_step - 控制步骤之间的前置关系 StepResult - 记录每一步结果 artifacts - 保存截图、HTML、网络现场 RunLogger - 记录运行过程和变量快照 ResultCollector - 最后统一汇总失败一个能长期使用的自动化框架不只是会跑用例。它还要在失败时把现场留下来让人能继续分析而不是回到手工复现。