游戏测试这行干久了你会慢慢发现一个规律项目越复杂越考验的不是你发现了多少Bug而是你有没有办法把那些重复到让人想吐的操作交给脚本去完成。而脚本里最基础、也最容易把效率和稳定性拉出巨大差距的就是循环语句。Python的for和while在游戏测试里出现的频率比很多测试工具还要高。今天我把它们实际用到的8个高频场景拿出来晒一晒都是我这些年踩过坑、提过效、也被同事当模板抄过的东西分享给正在做游戏测试或者准备转自动化测试的朋友。这篇文章不是Python语法教程而是直接从游戏测试的工作场景出发讲清楚循环到底在什么时候用、怎么写才能不翻车、以及哪些地方容易出事故。不管你是刚入行的测试小白还是已经写了半年脚本的提效爱好者都应该能从里面找到值得直接抄回去的代码片段和设计思路。1. 为什么游戏测试要先搞懂循环1.1 循环就是游戏测试的“最省力杠杆”游戏测试和其他软件测试有个很不一样的地方游戏里的操作步骤往往需要高度重复而且这种重复经常带着明确的时序。举个例子你想验证体力系统在连续战斗10次后的数值变化如果手动点一次战斗来回至少30秒10次就是5分钟中间手一抖可能还会漏掉步骤。但如果你用循环让脚本自动点击“开始战斗”按钮、等待结算弹窗、记录体力值然后重复10次整个过程只需要挂机跑几十秒并且每次打点的时机都是统一的不存在手速造成的数据误差。从工作量上看这不只是省时间更是把人工执行中“不可控”的部分降到了零。循环的意义不是让你少写几行代码而是让你把游戏里的“批量性、重复性、周期性”动作全部变成可以被精确控制、精确重复的机器行为。这也是为什么游戏测试自动化的第一步基本都是围绕循环来搭框架的。1.2 for 和 while 在测试脚本里的分工很多刚接触脚本的朋友会纠结一个问题什么时候用for什么时候用while我给你的判断标准其实很简单如果你知道要循环多少次就选for因为它更直观、不容易失控如果你不确定会循环多少次只知道要在某个条件满足时结束就选while但一定要给循环加上超时保护。举个实际的对比批量执行5个流程用例是明确的5次用for永远是对的而“等游戏切到主界面”这件事你没法预知具体要等多少秒有可能是0.5秒也有可能是20秒这时候用while配合轮询才是正解。两者不是谁替代谁而是在不同场景里各司其职。这个判断标准几乎覆盖了游戏测试里最常用的几个场景。下面我一个个拆开讲。2. 高频场景一批量跑测试用例for 的基本盘2.1 场景描述游戏测试每天最常见的活儿就是把一组功能用例按顺序跑了然后把结果记录下来。比如一个角色创建系统需要验证不同职业、不同名称长度、不同皮肤选择能不能顺利建号。这种场景天然就是for循环的阵地从测试用例列表里逐个取出用例执行对应的游戏操作收集结果。我自己在做某模拟项目X的时候项目验收要求对所有功能模块进行一次快速回归那一刻我意识到与其每天早晨手动把十几个用例点一遍不如把用例路径写成一个列表让for循环帮我干这个活。2.2 代码示例与原理test_cases [ {name: 创建战士角色, steps: select_warrior, expect: 角色界面显示战士}, {name: 创建法师角色, steps: select_mage, expect: 角色界面显示法师}, {name: 创建弓箭手角色, steps: select_archer, expect: 角色界面显示弓箭手}, ] for case in test_cases: enter_create_page() perform_steps(case[steps]) time.sleep(1) result get_current_ui_text() if result case[expect]: log(fPASS: {case[name]}) else: log(fFAIL: {case[name]}期望{case[expect]}实际{result}) back_to_previous_page()这里最核心的思路是把用例的数据和用例的执行逻辑分离。循环只是负责按顺序把每个数据套进同一套动作里这样你以后新增用例只需要在列表里加一行完全不用改执行逻辑。这招叫数据驱动是游戏测试脚本进阶的重要起点。2.3 注意事项用for跑用例有三点很容易翻车。第一每个用例执行完一定要有回到初始状态的操作不然后一个用例会被前一个用例留在现场的弹窗、页面状态干扰产生一堆假失败。第二日志里要带用例名和具体断言值否则跑完100个用例后回看日志你根本不知道哪一条对应的是什么步骤。第三批量执行时尽量给每条用例加独立的try/except包裹不要让一个用例崩溃后整个循环直接退出中断后续全部测试。提示我在跑批量用例的时候习惯在循环体内部加一个简单的失败重试机制如果断言失败自动重进页面再试一次。很多游戏页面的加载延迟是偶发的一次失败不代表功能真的坏了重试一次能过滤掉大量伪Bug。3. 高频场景二等待游戏状态切换while 的拿手戏3.1 场景描述游戏测试里最让人焦虑的事情就是“游戏切状态的时候到底要等多久”。点了一个“进入副本”按钮画面转圈、加载进度条、白屏、切地图这一系列过程在不同机型、不同网络下耗时完全不同。如果用固定time.sleep(10)去等慢的机器可能还没加载完脚本就去点击下一步了直接报错快的机器又白白浪费了7秒钟整个用例跑下来积少成多非常浪费时间。这时候while循环的价值就体现出来了它不是死等一个固定时间而是每隔一小段时间就去检查一次“游戏是否切换到了目标状态”到条件成立后立刻继续往下走。3.2 带超时的轮询实现def wait_for_condition(condition_func, timeout20, interval0.5): start_time time.time() while time.time() - start_time timeout: if condition_func(): return True time.sleep(interval) raise TimeoutError(f等待超时: {timeout}秒后条件仍未满足)调用方式也很直白# 等待进入副本场景 wait_for_condition(lambda: is_element_visible(副本入口), timeout30) click_button(开始战斗) wait_for_condition(lambda: is_element_visible(战斗结算面板), timeout60)这里while配合time.time()做超时判断是整个轮询函数的灵魂。它保证了条件提前满足就提前退出减少等待浪费条件一直不满足也会在指定时间后报错不会变成死循环把脚本挂死。3.3 注意事项用while做等待最大的坑就是你忘了设超时。游戏一旦进入异常状态比如网络断开、加载卡死条件函数永远返回False没有超时保护的while就会永远循环下去。轻则脚本卡住不往下走重则整个自动化集群被这一个小循环拖死。第二个坑是轮询间隔设置太小。有的测试员把interval设成0.1秒看起来很灵敏实际上如果条件函数里去查UI控件每次查询都是一次跨进程通信0.1秒一次的频率会给游戏客户端造成不小压力反而可能因为频繁操作导致客户端卡顿。我实际用下来0.3到0.5秒的轮询间隔在大多数游戏上都很稳。注意条件函数里不要做复杂的数据计算只做“状态判断”。如果同时需要等待多个条件就写一个把多个判断合起来的函数不要在wait循环里堆一堆业务逻辑。4. 高频场景三反复模拟玩家操作4.1 场景描述游戏里有很多“枯燥但必须重复”的玩家操作比如反复抽卡测试概率、连续强化装备、反复发送聊天消息验证敏感词过滤、同一个副本刷100次看掉落率。这些操作的共同点是循环次数明确过程高度一致但每次操作之间的间隔和触发条件可能有微小变化。这种场景最适合用for循环把“操作套餐”整体重复N次。如果你让一个人手动去刷50次装备强化他可能刷到第20次就开始分心然后点错按钮脚本就不存在这个问题50次就是50次每次都按照同一套标准动作去执行。4.2 代码示例for i in range(50): click_button(强化) time.sleep(0.5) if is_element_visible(强化成功提示): log(f第{i1}次强化: 成功) click_button(关闭提示) elif is_element_visible(强化失败提示): log(f第{i1}次强化: 失败) click_button(关闭提示) else: log(f第{i1}次强化: 异常状态截图存档) take_screenshot(fstrengthen_error_{i1}.png) break这段代码里我故意写了一个break分支当出现“既不是成功也不是失败”的异常状态时立刻中断循环并截图存档。因为连续操作类的循环最怕的不是失败而是“卡在中间状态导致后续步骤全部错位”。提前把异常存档配合break可以帮你把事故现场完整保留下来。4.3 注意事项循环里模拟玩家操作需要额外关注两次操作之间的间隔。很多游戏都有防连点机制如果你脚本点太快客户端会把它当作外挂行为触发惩罚或者直接忽略部分操作。我一般会在每次点击后加上微小的随机延迟比如time.sleep(0.3 random.uniform(0, 0.2))既能保证操作节奏接近真人又不会因为固定间隔被识别。另外这类循环一定要在开头记录当前金库、体力、道具数量等资源状态。因为连续操作会消耗游戏资源跑完一轮后你要能对比消耗是否在预期范围内一旦发现消耗异常说明循环里某个步骤点错了浪费了资源。5. 高频场景四遍历场景物体或地图格子5.1 场景描述游戏测试里有一类很麻烦的工作检查场景里有没有“摆错位置”的东西。比如某张地图上有200个可交互物体你要确认它们的位置坐标都在配置表预期的范围内或者某个塔防游戏把地图抽象成20乘以15的格子每个格子属于“可通行”还是“不可通行”跟关卡配置表的预期是否一致。这种“一个个过去查”的活最合适的就是循环加遍历。5.2 地图格子遍历示例map_data load_map_config(level_3_map.json) for y in range(map_data[height]): for x in range(map_data[width]): cell map_data[grid][y][x] expected map_data[expected][y][x] if cell ! expected: report_error(f位置({x},{y})格子类型错误预期{expected}实际{cell})这里的双重for循环本质是用嵌套循环把二维经纬度完整扫一遍。先固定y然后遍历这一行里的每个x全部跑完再跳到下一行这样能够保证每个格子都被访问且只被访问一次不会漏查。遍历场景物体的时候也是一样的思路所有物体ID放在一个列表里循环每个物体读取它的坐标再跟配置表中的坐标做比较差异超过阈值就记录。很多放置类游戏的地图校验脚本核心逻辑也就是这么几十行。5.3 注意事项遍历场景和地图数据时最大的坑是索引越界和空数据。游戏的地图配置如果有一列数据漏填grid数组长度不齐双重循环跑到一半就会抛异常。我习惯在遍历前先对数据做一次合法性检查确认每一行的列数和表头一致确认所有坐标都在地图边界内确认没有None值混在数据里。宁可前面多花几行代码做防御也不要等跑了一半再返工。另一个容易被忽视的问题是遍历效率。几百个格子的地图直接遍历没问题但到了上万格子的沙盘地图纯Python循环就会显得慢了。如果遇到这种情况可以考虑先用numpy把整张地图读成矩阵再做一次性的比较运算效率能提升几十倍。不过大多数关卡地图的体量还到不了这个级别普通for循环已经够用。6. 高频场景五收集性能数据6.1 场景描述游戏测试不只测功能还要测性能。帧率FPS、内存占用、CPU占用、渲染耗时这些指标不是看一个瞬时值就够的得在游戏运行过程中持续采样才能看出有没有严重的波动和掉帧。循环在这里的角色就是“定时采样器”每隔一段时间抓一次性能数据记录下来然后汇总分析。比如你想测试某个场景在团战特效全开后的帧率稳定性手动用性能工具录一遍数据是很准但录不了几次就累得不行。用循环写个自动采样器让它跑10分钟、每隔2秒抓一次帧率你大可以去做别的事回来直接看曲线图。6.2 循环采样示例fps_samples [] while is_game_running() and len(fps_samples) 300: current_fps get_current_fps() fps_samples.append(current_fps) timestamp time.time() write_to_log(f{timestamp}, {current_fps}) time.sleep(1)看到一个细节没为什么用while而不是for因为这个循环到底要跑多久其实取决于游戏进程是否还活着。如果游戏在测试过程中崩了采样循环应该立刻结束否则一直循环下去也只是在为空进程记录无意义的数据。这里把“游戏运行中”这个条件加进while判断能够让脚本在游戏崩溃时自动收尾不会留下大量的无效采样数据。6.3 注意事项性能采样的循环需要注意两个问题。第一是采样间隔的稳定性。如果你在循环体里写了很多耗时操作比如把数据写入Excel、截图保存这些操作本身就会影响采样频率导致数据间隔不均匀。我的解决方案是循环里只做“采样和轻量写入”把FPS、时间戳存到一个列表里循环结束后再统一做分析和生成报告。第二是内存问题。长时间性能测试经常要跑几小时如果每采样一次就把数据追加到一个不断变大的DataFrame里跑久了脚本自己的内存就会爆掉。我建议的做法是每采100个样本就批量落盘一次然后清空内存里的列表这样脚本运行再久都保持着稳定的内存占用。7. 高频场景六随机输入与压力测试7.1 场景描述游戏测试里有一种很“野”的测试方式乱点乱按。随机点击屏幕上的不同位置随机输入超长字符串、特殊符号、负数数值、空值看看游戏会不会崩、会不会卡死、会不会出现资源错误。这种模糊测试Fuzz Testing看起来没有章法但特别能发现一些正经用例想不到的边界Bug。而随机输入要想到规模和可复现的效果就离不开循环。7.2 循环构造随机输入import random import string random_strings [] for _ in range(200): length random.randint(1, 50) chars .join(random.choices( string.ascii_letters string.digits !#$%^*()_-。……, klength )) random_strings.append(chars) for s in random_strings: enter_input_box() type_text(s) click_button(提交) wait_for_condition(lambda: is_element_visible(提交结果), timeout5) log(f输入长度{len(s)}: 结果正常)这里用了两层循环第一层循环先批量生成200个随机字符串第二层循环再把它们逐个输入到游戏里。生成和输入分开的原因很简单如果你在输入循环里现场随机生成字符串某次随机出来一个超级长的内容导致游戏卡顿你很难判断到底是“这个特定字符串”引发的问题还是游戏整体性能就扛不住了。先把数据准备好再逐个输入出了问题才好复现和定位。7.3 注意事项压力测试循环里的一个重大隐患是“异常处理不彻底”。如果某次随机输入后游戏弹出了一个你循环体里没有处理的对话框脚本可能直接卡死在等待下一轮点击。所以做随机输入循环一定要在每轮结束时检查游戏是否还在主界面不在就强制复位而不是硬着头皮点下去。另一点是随机数的种子问题。如果你在脚本开头设置了random.seed(42)那么每次跑测试生成的随机字符串序列是完全一样的。这在定位Bug时是个很大的优势测试第10轮报错重新运行脚本第10轮又会用同样的字符串触发同样的错误复现率非常高。但如果你想做长时间的全新随机测试就不要设置种子否则每天跑的输入都是同一批。8. 高频场景七日志解析与错误检查8.1 场景描述游戏跑完一轮测试后会产出一堆客户端日志、服务端日志、崩溃日志、性能日志。人工翻这些日志去查是否有报错效率低不说还容易漏。尤其是有时候错误只出现在某个特定操作后的几行日志里而且不是每次都出现隔三差五才冒出来一次。这种场景很适合用循环逐行扫日志把可疑信息挑出来汇总。8.2 日志扫描循环keywords [ERROR, Exception, NullReference, HTTP 500, OutOfMemory] errors [] with open(game_client.log, r, encodingutf-8, errorsignore) as f: for line_number, line in enumerate(f, 1): for kw in keywords: if kw in line: errors.append((line_number, kw, line.strip())) break for line_number, keyword, content in errors: log(f第{line_number}行发现{keyword}: {content[:120]})这个例子里出现了两层for循环嵌套。外层循环按行扫描日志内层循环检查这一行里是否包含任一可疑关键词。用enumerate给行号编号是为了出现问题后能快速跳转到对应日志位置查看上下文。很多人会问直接用字符串的find或者in判断不就行了吗为什么还要循环因为游戏日志的文件可能非常大一个普通的游戏测试跑个把小时客户端日志就能到几百MB逐行扫描是处理大文件最稳妥且不占内存的方式。配合循环你可以在不把整个文件读进内存的前提下完成全量检查。8.3 注意事项日志解析循环里最容易出的问题是“关键词误报”。游戏里的某个正常代码可能包含“Exception”但后面跟着“Handled”或者包含“error”但只是美术资源文件名的一部分。所以我建议匹配时用更完整的特征词比如“Unhandled Exception”“FATAL ERROR”或者干脆用正则表达式去匹配更精确的格式减少误报带来的排查成本。另外解析完日志后不要只把错误信息打印在控制台就完事建议按错误类型分类汇总统计每个错误出现的次数。用循环扫日志顺手再写一个循环统计错误频次这样既能拿到单点错误详情又能拿到整体错误分布对判断Bug的严重程度和影响范围非常有用。9. 高频场景八按数据表驱动测试9.1 场景描述游戏测试里经常需要处理“一批相似但参数不同的用例”。比如说验证某个道具在不同品质等级下的数值加成是否正确或者验证商店里50个商品的价格和描述是否跟配置表一致。这种批量化、参数化的验证需求最适合用循环去读外部表格数据然后逐条驱动测试流程。这就是测试行业里常说的“表格驱动”或“数据驱动”在游戏测试里特别有用因为游戏里同一套逻辑被不同配置数据反复调用的情况极其常见。9.2 表格驱动的循环实现import csv with open(shop_items.csv, encodingutf-8) as f: reader csv.DictReader(f) item_list list(reader) for item in item_list: item_id item[id] expected_price int(item[price]) expected_name item[name] open_shop() click_item(item_id) actual_price get_item_price() actual_name get_item_name() if actual_price ! expected_price or actual_name ! expected_name: log(f商品{item_id}数据错误: 价格期望{expected_price}实际{actual_price}名称期望{expected_name}实际{actual_name}) close_shop()这种写法的好处非常明显测试数据在表里测试逻辑在代码里两边完全分离。游戏策划改了配置表你不需要去动代码直接更新一下CSV文件再跑一遍就行。循环在这里充当了“调度中心”把表格里每一行数据转换成一次完整的测试执行。9.3 注意事项数据驱动循环最需要留意的是数据格式和单位。游戏配置表里的数值经常有类型坑比如价格字段在Excel里显示的是整数但导出成CSV后可能变成“500.0”甚至带科学计数法你如果用int直接转型很容易报错。我的建议是在读表时就做统一的数据清洗用float解析再转int并做好异常兜底避免因为一条脏数据让整个表格测试中断。其次如果表格里数据量很大比如500个商品每个商品测试都完整走一遍“打开商店-点击商品-读取数据-关闭商店”那整个循环会非常耗时。这种情况下可以考虑把“打开商店”“关闭商店”这两个动作从循环体里挪出去只让循环聚焦在“点击-读取-判断”上能大幅缩短整体时长。不过这样做的前提是商品列表界面支持不退出商店就切换查看多个商品。10. 常见问题与排查技巧10.1 死循环脚本卡住不往下走这是我见过最多的循环事故。写循环的时候忘了加结束条件或者超时保护写错了位置导致脚本一直卡在同一段代码里游戏客户端倒是没啥事可测试流程整个废掉了。排查死循环有一个很实用的技巧在循环体内部设置“最后执行时间”变量在循环头部检查如果超过N秒没有新的输出就手动中止。更简单的方法是凡是自己写while轮询一律使用前面提到过的wait_for_condition模式把超时判断放在循环条件里而不是循环体内部这样逻辑上不容易遗漏。还有一招是打印进度。循环里隔几轮就打印一条当前执行到第X轮的日志如果日志停留在某个数字不动了你基本可以断定问题发生在哪一轮定位起来非常快。10.2 循环体内修改了正在遍历的数据有些测试脚本在循环里处理一个列表的时候会根据条件往列表里加元素或者删元素导致循环越界或者漏掉某些元素。我自己的习惯是如果循环过程中需要增删数据先遍历原列表的副本再把处理结果放回一个新列表里。这样原数据保持不动循环的迭代次数始终稳定不会出意外。如果确实需要在一个列表上循环处理的同时不断新增待处理项目比如“从任务队列里取任务跑完后可能产生新任务”那就应该用while加索引指针而不是for。用for去遍历一个会变长的列表Python会在迭代过程中根据原始长度决定什么时候停止新加的元素大概率不会被处理到这就是典型的隐面Bug。10.3 日志量爆炸循环跑得爽日志也可能多得吓人。如果每轮循环都要打印几十行调试信息跑200轮就是几千行日志你的电脑风扇直接起飞排查问题的时候两眼一黑关键信息全被淹没在无意义的日志里。我的处理原则是正常通过的情况只记录一行摘要失败的情况才打印详细堆栈和数据。这样日志既保持了可读性又保留了足够的故障现场信息。如果项目有日志分级机制就把循环内的详细输出调到debug级别默认只显示info和error。10.4 不同运行环境下循环表现不一致同样的循环脚本在自己的Windows电脑上跑得好好的放到Linux服务器上就各种问题。原因往往是路径分隔符、编码格式、sleep精度存在差异。游戏测试脚本要跨环境跑路径操作统一用os.path拼接不要手写反斜杠读日志文件的时候统一指定utf-8或者按需指定编码不要依赖系统默认编码等待函数用time.sleep在不同系统上精度差别不大但如果需要毫秒级精度就要用time.perf_counter来配合。11. 写在最后的一点体会从我刚开始做游戏测试只会写for i in range(10): print(i)到现在能用循环把整条冒烟回归流程串起来中间经历过无数次脚本卡死、数据错乱、日志找不到Bug位置的问题。回过头看循环本身不难难的是想清楚“这个循环要解决什么、什么时候该结束、异常了怎么办”这三件事。只要每次写循环前先在脑子里把这三个问题过一遍你写出来的脚本质量就能超过一大批同行。如果你现在刚开始学着用Python做游戏测试别急着去看那些花里胡哨的框架和平台。先把for、while、嵌套循环、超时保护这几个基础项练扎实你会发现日常八成以上的重复工作都已经能用几段小循环脚本搞定了。等基础打牢了再往自动化和持续集成方向走会顺很多。 
长河君 · 2026/10/24 7:49:13 · 阅读 1.2k 游戏测试必学：Python循环8个高频场景，自动化脚本提效实战
游戏测试这行干久了你会慢慢发现一个规律项目越复杂越考验的不是你发现了多少Bug而是你有没有办法把那些重复到让人想吐的操作交给脚本去完成。而脚本里最基础、也最容易把效率和稳定性拉出巨大差距的就是循环语句。Python的for和while在游戏测试里出现的频率比很多测试工具还要高。今天我把它们实际用到的8个高频场景拿出来晒一晒都是我这些年踩过坑、提过效、也被同事当模板抄过的东西分享给正在做游戏测试或者准备转自动化测试的朋友。这篇文章不是Python语法教程而是直接从游戏测试的工作场景出发讲清楚循环到底在什么时候用、怎么写才能不翻车、以及哪些地方容易出事故。不管你是刚入行的测试小白还是已经写了半年脚本的提效爱好者都应该能从里面找到值得直接抄回去的代码片段和设计思路。1. 为什么游戏测试要先搞懂循环1.1 循环就是游戏测试的“最省力杠杆”游戏测试和其他软件测试有个很不一样的地方游戏里的操作步骤往往需要高度重复而且这种重复经常带着明确的时序。举个例子你想验证体力系统在连续战斗10次后的数值变化如果手动点一次战斗来回至少30秒10次就是5分钟中间手一抖可能还会漏掉步骤。但如果你用循环让脚本自动点击“开始战斗”按钮、等待结算弹窗、记录体力值然后重复10次整个过程只需要挂机跑几十秒并且每次打点的时机都是统一的不存在手速造成的数据误差。从工作量上看这不只是省时间更是把人工执行中“不可控”的部分降到了零。循环的意义不是让你少写几行代码而是让你把游戏里的“批量性、重复性、周期性”动作全部变成可以被精确控制、精确重复的机器行为。这也是为什么游戏测试自动化的第一步基本都是围绕循环来搭框架的。1.2 for 和 while 在测试脚本里的分工很多刚接触脚本的朋友会纠结一个问题什么时候用for什么时候用while我给你的判断标准其实很简单如果你知道要循环多少次就选for因为它更直观、不容易失控如果你不确定会循环多少次只知道要在某个条件满足时结束就选while但一定要给循环加上超时保护。举个实际的对比批量执行5个流程用例是明确的5次用for永远是对的而“等游戏切到主界面”这件事你没法预知具体要等多少秒有可能是0.5秒也有可能是20秒这时候用while配合轮询才是正解。两者不是谁替代谁而是在不同场景里各司其职。这个判断标准几乎覆盖了游戏测试里最常用的几个场景。下面我一个个拆开讲。2. 高频场景一批量跑测试用例for 的基本盘2.1 场景描述游戏测试每天最常见的活儿就是把一组功能用例按顺序跑了然后把结果记录下来。比如一个角色创建系统需要验证不同职业、不同名称长度、不同皮肤选择能不能顺利建号。这种场景天然就是for循环的阵地从测试用例列表里逐个取出用例执行对应的游戏操作收集结果。我自己在做某模拟项目X的时候项目验收要求对所有功能模块进行一次快速回归那一刻我意识到与其每天早晨手动把十几个用例点一遍不如把用例路径写成一个列表让for循环帮我干这个活。2.2 代码示例与原理test_cases [ {name: 创建战士角色, steps: select_warrior, expect: 角色界面显示战士}, {name: 创建法师角色, steps: select_mage, expect: 角色界面显示法师}, {name: 创建弓箭手角色, steps: select_archer, expect: 角色界面显示弓箭手}, ] for case in test_cases: enter_create_page() perform_steps(case[steps]) time.sleep(1) result get_current_ui_text() if result case[expect]: log(fPASS: {case[name]}) else: log(fFAIL: {case[name]}期望{case[expect]}实际{result}) back_to_previous_page()这里最核心的思路是把用例的数据和用例的执行逻辑分离。循环只是负责按顺序把每个数据套进同一套动作里这样你以后新增用例只需要在列表里加一行完全不用改执行逻辑。这招叫数据驱动是游戏测试脚本进阶的重要起点。2.3 注意事项用for跑用例有三点很容易翻车。第一每个用例执行完一定要有回到初始状态的操作不然后一个用例会被前一个用例留在现场的弹窗、页面状态干扰产生一堆假失败。第二日志里要带用例名和具体断言值否则跑完100个用例后回看日志你根本不知道哪一条对应的是什么步骤。第三批量执行时尽量给每条用例加独立的try/except包裹不要让一个用例崩溃后整个循环直接退出中断后续全部测试。提示我在跑批量用例的时候习惯在循环体内部加一个简单的失败重试机制如果断言失败自动重进页面再试一次。很多游戏页面的加载延迟是偶发的一次失败不代表功能真的坏了重试一次能过滤掉大量伪Bug。3. 高频场景二等待游戏状态切换while 的拿手戏3.1 场景描述游戏测试里最让人焦虑的事情就是“游戏切状态的时候到底要等多久”。点了一个“进入副本”按钮画面转圈、加载进度条、白屏、切地图这一系列过程在不同机型、不同网络下耗时完全不同。如果用固定time.sleep(10)去等慢的机器可能还没加载完脚本就去点击下一步了直接报错快的机器又白白浪费了7秒钟整个用例跑下来积少成多非常浪费时间。这时候while循环的价值就体现出来了它不是死等一个固定时间而是每隔一小段时间就去检查一次“游戏是否切换到了目标状态”到条件成立后立刻继续往下走。3.2 带超时的轮询实现def wait_for_condition(condition_func, timeout20, interval0.5): start_time time.time() while time.time() - start_time timeout: if condition_func(): return True time.sleep(interval) raise TimeoutError(f等待超时: {timeout}秒后条件仍未满足)调用方式也很直白# 等待进入副本场景 wait_for_condition(lambda: is_element_visible(副本入口), timeout30) click_button(开始战斗) wait_for_condition(lambda: is_element_visible(战斗结算面板), timeout60)这里while配合time.time()做超时判断是整个轮询函数的灵魂。它保证了条件提前满足就提前退出减少等待浪费条件一直不满足也会在指定时间后报错不会变成死循环把脚本挂死。3.3 注意事项用while做等待最大的坑就是你忘了设超时。游戏一旦进入异常状态比如网络断开、加载卡死条件函数永远返回False没有超时保护的while就会永远循环下去。轻则脚本卡住不往下走重则整个自动化集群被这一个小循环拖死。第二个坑是轮询间隔设置太小。有的测试员把interval设成0.1秒看起来很灵敏实际上如果条件函数里去查UI控件每次查询都是一次跨进程通信0.1秒一次的频率会给游戏客户端造成不小压力反而可能因为频繁操作导致客户端卡顿。我实际用下来0.3到0.5秒的轮询间隔在大多数游戏上都很稳。注意条件函数里不要做复杂的数据计算只做“状态判断”。如果同时需要等待多个条件就写一个把多个判断合起来的函数不要在wait循环里堆一堆业务逻辑。4. 高频场景三反复模拟玩家操作4.1 场景描述游戏里有很多“枯燥但必须重复”的玩家操作比如反复抽卡测试概率、连续强化装备、反复发送聊天消息验证敏感词过滤、同一个副本刷100次看掉落率。这些操作的共同点是循环次数明确过程高度一致但每次操作之间的间隔和触发条件可能有微小变化。这种场景最适合用for循环把“操作套餐”整体重复N次。如果你让一个人手动去刷50次装备强化他可能刷到第20次就开始分心然后点错按钮脚本就不存在这个问题50次就是50次每次都按照同一套标准动作去执行。4.2 代码示例for i in range(50): click_button(强化) time.sleep(0.5) if is_element_visible(强化成功提示): log(f第{i1}次强化: 成功) click_button(关闭提示) elif is_element_visible(强化失败提示): log(f第{i1}次强化: 失败) click_button(关闭提示) else: log(f第{i1}次强化: 异常状态截图存档) take_screenshot(fstrengthen_error_{i1}.png) break这段代码里我故意写了一个break分支当出现“既不是成功也不是失败”的异常状态时立刻中断循环并截图存档。因为连续操作类的循环最怕的不是失败而是“卡在中间状态导致后续步骤全部错位”。提前把异常存档配合break可以帮你把事故现场完整保留下来。4.3 注意事项循环里模拟玩家操作需要额外关注两次操作之间的间隔。很多游戏都有防连点机制如果你脚本点太快客户端会把它当作外挂行为触发惩罚或者直接忽略部分操作。我一般会在每次点击后加上微小的随机延迟比如time.sleep(0.3 random.uniform(0, 0.2))既能保证操作节奏接近真人又不会因为固定间隔被识别。另外这类循环一定要在开头记录当前金库、体力、道具数量等资源状态。因为连续操作会消耗游戏资源跑完一轮后你要能对比消耗是否在预期范围内一旦发现消耗异常说明循环里某个步骤点错了浪费了资源。5. 高频场景四遍历场景物体或地图格子5.1 场景描述游戏测试里有一类很麻烦的工作检查场景里有没有“摆错位置”的东西。比如某张地图上有200个可交互物体你要确认它们的位置坐标都在配置表预期的范围内或者某个塔防游戏把地图抽象成20乘以15的格子每个格子属于“可通行”还是“不可通行”跟关卡配置表的预期是否一致。这种“一个个过去查”的活最合适的就是循环加遍历。5.2 地图格子遍历示例map_data load_map_config(level_3_map.json) for y in range(map_data[height]): for x in range(map_data[width]): cell map_data[grid][y][x] expected map_data[expected][y][x] if cell ! expected: report_error(f位置({x},{y})格子类型错误预期{expected}实际{cell})这里的双重for循环本质是用嵌套循环把二维经纬度完整扫一遍。先固定y然后遍历这一行里的每个x全部跑完再跳到下一行这样能够保证每个格子都被访问且只被访问一次不会漏查。遍历场景物体的时候也是一样的思路所有物体ID放在一个列表里循环每个物体读取它的坐标再跟配置表中的坐标做比较差异超过阈值就记录。很多放置类游戏的地图校验脚本核心逻辑也就是这么几十行。5.3 注意事项遍历场景和地图数据时最大的坑是索引越界和空数据。游戏的地图配置如果有一列数据漏填grid数组长度不齐双重循环跑到一半就会抛异常。我习惯在遍历前先对数据做一次合法性检查确认每一行的列数和表头一致确认所有坐标都在地图边界内确认没有None值混在数据里。宁可前面多花几行代码做防御也不要等跑了一半再返工。另一个容易被忽视的问题是遍历效率。几百个格子的地图直接遍历没问题但到了上万格子的沙盘地图纯Python循环就会显得慢了。如果遇到这种情况可以考虑先用numpy把整张地图读成矩阵再做一次性的比较运算效率能提升几十倍。不过大多数关卡地图的体量还到不了这个级别普通for循环已经够用。6. 高频场景五收集性能数据6.1 场景描述游戏测试不只测功能还要测性能。帧率FPS、内存占用、CPU占用、渲染耗时这些指标不是看一个瞬时值就够的得在游戏运行过程中持续采样才能看出有没有严重的波动和掉帧。循环在这里的角色就是“定时采样器”每隔一段时间抓一次性能数据记录下来然后汇总分析。比如你想测试某个场景在团战特效全开后的帧率稳定性手动用性能工具录一遍数据是很准但录不了几次就累得不行。用循环写个自动采样器让它跑10分钟、每隔2秒抓一次帧率你大可以去做别的事回来直接看曲线图。6.2 循环采样示例fps_samples [] while is_game_running() and len(fps_samples) 300: current_fps get_current_fps() fps_samples.append(current_fps) timestamp time.time() write_to_log(f{timestamp}, {current_fps}) time.sleep(1)看到一个细节没为什么用while而不是for因为这个循环到底要跑多久其实取决于游戏进程是否还活着。如果游戏在测试过程中崩了采样循环应该立刻结束否则一直循环下去也只是在为空进程记录无意义的数据。这里把“游戏运行中”这个条件加进while判断能够让脚本在游戏崩溃时自动收尾不会留下大量的无效采样数据。6.3 注意事项性能采样的循环需要注意两个问题。第一是采样间隔的稳定性。如果你在循环体里写了很多耗时操作比如把数据写入Excel、截图保存这些操作本身就会影响采样频率导致数据间隔不均匀。我的解决方案是循环里只做“采样和轻量写入”把FPS、时间戳存到一个列表里循环结束后再统一做分析和生成报告。第二是内存问题。长时间性能测试经常要跑几小时如果每采样一次就把数据追加到一个不断变大的DataFrame里跑久了脚本自己的内存就会爆掉。我建议的做法是每采100个样本就批量落盘一次然后清空内存里的列表这样脚本运行再久都保持着稳定的内存占用。7. 高频场景六随机输入与压力测试7.1 场景描述游戏测试里有一种很“野”的测试方式乱点乱按。随机点击屏幕上的不同位置随机输入超长字符串、特殊符号、负数数值、空值看看游戏会不会崩、会不会卡死、会不会出现资源错误。这种模糊测试Fuzz Testing看起来没有章法但特别能发现一些正经用例想不到的边界Bug。而随机输入要想到规模和可复现的效果就离不开循环。7.2 循环构造随机输入import random import string random_strings [] for _ in range(200): length random.randint(1, 50) chars .join(random.choices( string.ascii_letters string.digits !#$%^*()_-。……, klength )) random_strings.append(chars) for s in random_strings: enter_input_box() type_text(s) click_button(提交) wait_for_condition(lambda: is_element_visible(提交结果), timeout5) log(f输入长度{len(s)}: 结果正常)这里用了两层循环第一层循环先批量生成200个随机字符串第二层循环再把它们逐个输入到游戏里。生成和输入分开的原因很简单如果你在输入循环里现场随机生成字符串某次随机出来一个超级长的内容导致游戏卡顿你很难判断到底是“这个特定字符串”引发的问题还是游戏整体性能就扛不住了。先把数据准备好再逐个输入出了问题才好复现和定位。7.3 注意事项压力测试循环里的一个重大隐患是“异常处理不彻底”。如果某次随机输入后游戏弹出了一个你循环体里没有处理的对话框脚本可能直接卡死在等待下一轮点击。所以做随机输入循环一定要在每轮结束时检查游戏是否还在主界面不在就强制复位而不是硬着头皮点下去。另一点是随机数的种子问题。如果你在脚本开头设置了random.seed(42)那么每次跑测试生成的随机字符串序列是完全一样的。这在定位Bug时是个很大的优势测试第10轮报错重新运行脚本第10轮又会用同样的字符串触发同样的错误复现率非常高。但如果你想做长时间的全新随机测试就不要设置种子否则每天跑的输入都是同一批。8. 高频场景七日志解析与错误检查8.1 场景描述游戏跑完一轮测试后会产出一堆客户端日志、服务端日志、崩溃日志、性能日志。人工翻这些日志去查是否有报错效率低不说还容易漏。尤其是有时候错误只出现在某个特定操作后的几行日志里而且不是每次都出现隔三差五才冒出来一次。这种场景很适合用循环逐行扫日志把可疑信息挑出来汇总。8.2 日志扫描循环keywords [ERROR, Exception, NullReference, HTTP 500, OutOfMemory] errors [] with open(game_client.log, r, encodingutf-8, errorsignore) as f: for line_number, line in enumerate(f, 1): for kw in keywords: if kw in line: errors.append((line_number, kw, line.strip())) break for line_number, keyword, content in errors: log(f第{line_number}行发现{keyword}: {content[:120]})这个例子里出现了两层for循环嵌套。外层循环按行扫描日志内层循环检查这一行里是否包含任一可疑关键词。用enumerate给行号编号是为了出现问题后能快速跳转到对应日志位置查看上下文。很多人会问直接用字符串的find或者in判断不就行了吗为什么还要循环因为游戏日志的文件可能非常大一个普通的游戏测试跑个把小时客户端日志就能到几百MB逐行扫描是处理大文件最稳妥且不占内存的方式。配合循环你可以在不把整个文件读进内存的前提下完成全量检查。8.3 注意事项日志解析循环里最容易出的问题是“关键词误报”。游戏里的某个正常代码可能包含“Exception”但后面跟着“Handled”或者包含“error”但只是美术资源文件名的一部分。所以我建议匹配时用更完整的特征词比如“Unhandled Exception”“FATAL ERROR”或者干脆用正则表达式去匹配更精确的格式减少误报带来的排查成本。另外解析完日志后不要只把错误信息打印在控制台就完事建议按错误类型分类汇总统计每个错误出现的次数。用循环扫日志顺手再写一个循环统计错误频次这样既能拿到单点错误详情又能拿到整体错误分布对判断Bug的严重程度和影响范围非常有用。9. 高频场景八按数据表驱动测试9.1 场景描述游戏测试里经常需要处理“一批相似但参数不同的用例”。比如说验证某个道具在不同品质等级下的数值加成是否正确或者验证商店里50个商品的价格和描述是否跟配置表一致。这种批量化、参数化的验证需求最适合用循环去读外部表格数据然后逐条驱动测试流程。这就是测试行业里常说的“表格驱动”或“数据驱动”在游戏测试里特别有用因为游戏里同一套逻辑被不同配置数据反复调用的情况极其常见。9.2 表格驱动的循环实现import csv with open(shop_items.csv, encodingutf-8) as f: reader csv.DictReader(f) item_list list(reader) for item in item_list: item_id item[id] expected_price int(item[price]) expected_name item[name] open_shop() click_item(item_id) actual_price get_item_price() actual_name get_item_name() if actual_price ! expected_price or actual_name ! expected_name: log(f商品{item_id}数据错误: 价格期望{expected_price}实际{actual_price}名称期望{expected_name}实际{actual_name}) close_shop()这种写法的好处非常明显测试数据在表里测试逻辑在代码里两边完全分离。游戏策划改了配置表你不需要去动代码直接更新一下CSV文件再跑一遍就行。循环在这里充当了“调度中心”把表格里每一行数据转换成一次完整的测试执行。9.3 注意事项数据驱动循环最需要留意的是数据格式和单位。游戏配置表里的数值经常有类型坑比如价格字段在Excel里显示的是整数但导出成CSV后可能变成“500.0”甚至带科学计数法你如果用int直接转型很容易报错。我的建议是在读表时就做统一的数据清洗用float解析再转int并做好异常兜底避免因为一条脏数据让整个表格测试中断。其次如果表格里数据量很大比如500个商品每个商品测试都完整走一遍“打开商店-点击商品-读取数据-关闭商店”那整个循环会非常耗时。这种情况下可以考虑把“打开商店”“关闭商店”这两个动作从循环体里挪出去只让循环聚焦在“点击-读取-判断”上能大幅缩短整体时长。不过这样做的前提是商品列表界面支持不退出商店就切换查看多个商品。10. 常见问题与排查技巧10.1 死循环脚本卡住不往下走这是我见过最多的循环事故。写循环的时候忘了加结束条件或者超时保护写错了位置导致脚本一直卡在同一段代码里游戏客户端倒是没啥事可测试流程整个废掉了。排查死循环有一个很实用的技巧在循环体内部设置“最后执行时间”变量在循环头部检查如果超过N秒没有新的输出就手动中止。更简单的方法是凡是自己写while轮询一律使用前面提到过的wait_for_condition模式把超时判断放在循环条件里而不是循环体内部这样逻辑上不容易遗漏。还有一招是打印进度。循环里隔几轮就打印一条当前执行到第X轮的日志如果日志停留在某个数字不动了你基本可以断定问题发生在哪一轮定位起来非常快。10.2 循环体内修改了正在遍历的数据有些测试脚本在循环里处理一个列表的时候会根据条件往列表里加元素或者删元素导致循环越界或者漏掉某些元素。我自己的习惯是如果循环过程中需要增删数据先遍历原列表的副本再把处理结果放回一个新列表里。这样原数据保持不动循环的迭代次数始终稳定不会出意外。如果确实需要在一个列表上循环处理的同时不断新增待处理项目比如“从任务队列里取任务跑完后可能产生新任务”那就应该用while加索引指针而不是for。用for去遍历一个会变长的列表Python会在迭代过程中根据原始长度决定什么时候停止新加的元素大概率不会被处理到这就是典型的隐面Bug。10.3 日志量爆炸循环跑得爽日志也可能多得吓人。如果每轮循环都要打印几十行调试信息跑200轮就是几千行日志你的电脑风扇直接起飞排查问题的时候两眼一黑关键信息全被淹没在无意义的日志里。我的处理原则是正常通过的情况只记录一行摘要失败的情况才打印详细堆栈和数据。这样日志既保持了可读性又保留了足够的故障现场信息。如果项目有日志分级机制就把循环内的详细输出调到debug级别默认只显示info和error。10.4 不同运行环境下循环表现不一致同样的循环脚本在自己的Windows电脑上跑得好好的放到Linux服务器上就各种问题。原因往往是路径分隔符、编码格式、sleep精度存在差异。游戏测试脚本要跨环境跑路径操作统一用os.path拼接不要手写反斜杠读日志文件的时候统一指定utf-8或者按需指定编码不要依赖系统默认编码等待函数用time.sleep在不同系统上精度差别不大但如果需要毫秒级精度就要用time.perf_counter来配合。11. 写在最后的一点体会从我刚开始做游戏测试只会写for i in range(10): print(i)到现在能用循环把整条冒烟回归流程串起来中间经历过无数次脚本卡死、数据错乱、日志找不到Bug位置的问题。回过头看循环本身不难难的是想清楚“这个循环要解决什么、什么时候该结束、异常了怎么办”这三件事。只要每次写循环前先在脑子里把这三个问题过一遍你写出来的脚本质量就能超过一大批同行。如果你现在刚开始学着用Python做游戏测试别急着去看那些花里胡哨的框架和平台。先把for、while、嵌套循环、超时保护这几个基础项练扎实你会发现日常八成以上的重复工作都已经能用几段小循环脚本搞定了。等基础打牢了再往自动化和持续集成方向走会顺很多。