带测试新人学Python时我最常被问的一句话是“文件读写到底在游戏测试里有什么用”问这个问题的同学多半刚学到第二周语法摸了个大概循环、列表、函数都还没捂热突然接触到open()、write()、readlines()整个人是懵的。其实文件读写没这么玄乎——它就是让Python程序跟硬盘上的文件互相交换数据而你作为游戏测试工程师以后读配置文件、写测试报告、攒运行日志本质上全是在三件事之间打转读取、写入、追加。把这三种核心模式啃明白第二周才算真正通关。今天这篇就把第二周所有知识点做一次整合顺便用游戏测试的实际场景把文件读写彻底讲透。1. 第二周学完为什么文件读写是必须啃下来的硬骨头1.1 第二周的知识版图所有基础语法都在给文件读写做铺垫很多同学学到第二周会有一种感觉变量、分支、循环、列表、函数都学了但不知道这些零散的工具凑在一起能干成什么事。这很正常因为第二周本来就是打地基的阶段而文件读写恰好是把这些零散工具组装起来的最佳练习场。第二周的课程通常覆盖这些内容变量与数据类型、输入输出、条件判断、循环、列表与字典、函数、异常处理入门最后落到文件读写。它们之间的配合关系可以拿测试工作来对照着看。第二周知识点一句话理解在游戏测试里的对应场景变量与数据类型给数据起名字并分类记录用例编号、测的版本号、机型型号输入输出程序与人交互手动测试时输入账号密码、输出提示条件判断按规则走不同分支按日志级别分流处理循环让重复动作自动化遍历几百条用例、逐行扫描日志列表与字典批量存储和快速查找保存用例集、用字典统计错误类型函数把一段逻辑打包复用封装日志解析、结果汇总异常处理出错时不至于崩溃文件缺失、编码错误时的兜底文件读写在内存和硬盘之间搬数据读配置、写报告、存日志这张表里文件读写之所以放在最后不是因为它最难而是因为它要用到前面几乎全部的东西。想逐行分析日志文件你得会用for循环想统计各种错误出现几次你得会用字典想把这套分析逻辑反复跑你得会用函数文件万一找不到或者编码错了你得会用异常处理。所以第二周的收尾一定是文件操作它相当于一次“验收考试”。1.2 文件读写是把程序与数据世界焊在一起的桥先说一个容易被初学者忽视的事实程序一旦退出内存里的变量全都没了。你殚精竭虑统计出来的错误数量、精心构造的测试数据关掉终端的一瞬间就蒸发。游戏测试这个岗位偏偏最看重“留证据、给结论、找规律”——测试结论要能交付证据要能追溯数据要能分析而这些全都要落在文件里。打个比方变量是捧在手里的水文件才是装进杯子的水。程序结束时手里的水洒了杯子里的水还在。游戏测试工程师跟研发扯皮的时候拿出一份txt报告、一份日志文件比嘴上说一百句都管用。配置文件、存档文件、日志文件、报告文件都是程序之外的真实存在你的测试脚本要能“从文件里取货”也要能“把结果打包发货”靠的就是文件读写。我见过不少新人学到最后能写出漂亮的循环但一碰到“怎么把结果留下来”就卡住最后只能人肉复制终端输出。那自动化测试的效率至少打折一半。第二周学文件读写的意义就是让你从“代码在内存里自嗨”跳到“代码和外部世界真正互动”这一步跨过去后面写任何测试工具都有底气。2. 三大核心模式的真正区别读、写、追加到底谁该用谁这一章是整个第二周的重头戏。文件读写的核心是open()函数里的mode参数r、w、a这三个字母决定了你这个文件在Python眼里是“只能看”“彻底重来”还是“持续续写”。模式选错轻则读不到数据重则直接把配置清空。我逐个拆开讲。2.1 读取模式r只带眼睛入场绝不动数据读取模式是最安全、也最容易理解的一种。open(file_path, r)打开一个文件用来读取内容这个文件的原始数据不会被改动。r模式有几条死规矩文件必须存在否则直接报FileNotFoundError。在游戏测试里这反而是好事比如日志文件缺失说明测试环境没搭对报错正好提醒你先去查环境。r模式打开后指针默认在文件开头可以顺序往下读。想写文件r模式不行会报io.UnsupportedOperation。读取数据又分三种方式很多新手在这块混成一锅粥方法返回内容适合场景read()整个文件拼成一个大字符串文件很小、要全文搜索readline()一次只读一行返回字符串手动逐行处理readlines()所有行组成一个列表行数少、需要随机访问某一行但说句实话游戏测试里最常见的日志文件往往很大几百MB也不奇怪。这时候readlines()会把全部行都塞进内存机子差点直接卡死。我最推荐的方式是用for循环直接迭代文件对象with open(error.log, r, encodingutf-8) as f: for line in f: print(line.strip())这种写法的底层是一行一行地读读完一行处理一行内存占用极小跑上千行的日志毫无压力。初学者可以记住一个简单结论纯读取场景默认用for line in f遍历错不了。读取模式还有个“指针”概念要搞明白——文件打开后Python会维护一个位置标记读一行指针前进一次读到末尾之后再读就返回空字符串。这个指针概念在追加模式那边还会再遇到。2.2 写入模式w从零开始整个文件推倒重来写入模式是三种模式里最危险的但恰恰是很多人最爱乱用的。open(file_path, w)的核心行为是文件不存在就自动创建文件已存在就先把旧内容全部清空再从第一行开始写。我私下给新人讲课的时候常说w的“w”与其记成write不如记成wipe——抹掉重来。写代码时一个手滑把r打成w打开的瞬间旧文件就没了连提示都不带打的。游戏测试里真出过这种事故有同学想“更新”一份旧的配置文件用w模式打开写了几行新配置结果整个文件原有配置被清得干干净净最后只能找研发要备份重做。所以用w模式之前一定要问自己一句这个文件里旧的东西我确定不要了写入的具体操作有两个write()和writelines()。write()写单个字符串writelines()接收一个字符串列表把列表的每一项连续写进去。注意它们都不会自动换行需要换行就得自己在字符串末尾加\n。with open(test_report.txt, w, encodingutf-8) as f: f.write(回归测试报告\n) f.write( * 30 \n) f.writelines([用例1: PASS\n, 用例2: FAIL\n, 用例3: PASS\n])另外提一句r后面跟个加号变成r意思是可读可写但不会清空文件w也是可读可写但依旧会先清空文件。初学者如果只是想写结果老老实实用w就行不要为了“多一个读的能力”去选w等真正需要两个方向操作时再切换避免把问题搞复杂。2.3 追加模式a保留历史只在末尾续写追加模式a存在的意义就是“不破坏既有内容只在文件末尾继续写”。文件名不存在时自动创建文件已存在时保留原内容新内容一行一行接在后面。这个特性让它成了日志类数据的天然归宿。游戏测试里最常见的流水账是性能日志、内存占用日志、每轮用例的执行历史。你跑完一轮测试往history.log里追加一条“某年某月某日完成回归测试发现3个Bug”下一轮再追加一条文件越积累越有分析价值。如果这里用w模式每跑一轮就要把之前的记录清掉历史全丢就完全背离了日志的初衷。a模式有两个容易踩的坑打开后直接read()会得到空字符串。因为追加模式的指针默认指向文件末尾你还没写呢它已经站在结尾了。想读旧内容需要手动seek(0)。无论你把指针挪到哪里write()的内容永远落在文件末尾。这是追加模式写死的规则。with open(history.log, a, encodingutf-8) as f: f.write(2025-01-10 10:30:00 完成第3轮回归异常数: 2\n)有一种理解方式比较省脑子追加模式就像你在一本已经写了很多页的笔记本后面继续记前面怎么写好的一个字都不会动。2.4 别忘配套动作with语句到底帮你干了什么三种模式讲完还得把打开文件的标准姿势补上。常见写法是with open(..., mode) as f:很多人只把它当成固定模板背下来其实它解决的是“文件用完要关闭”这个老大难。如果不用with你得这样写f open(test.txt, w, encodingutf-8) f.write(hello) f.close()问题在于如果write()中间程序抛了异常close()这行根本执行不到文件就开着没人管。更常见的是写完忘关程序把内容放在缓冲区还没真正落到硬盘一旦程序崩溃数据就丢了。with语句则是一个上下文管理器它承诺代码块里的内容无论正常跑完还是中途异常跳出退出时都会自动关闭文件把缓冲区数据刷到磁盘。对测试脚本来说这几乎是保命级的操作因为测试跑着跑着出异常实在太常见了。还有一个细节重要日志需要实时落盘。with退出时确实会自动刷盘但如果程序直接被强杀、断电、或者测试到一半系统蓝屏缓冲区里没来得及写的数据照样会丢。所以写需要长时累积的关键数据时我习惯在循环里手动加一句f.flush()每写一行就强制刷到硬盘牺牲少量性能换数据安全。尤其是第3章要讲到的性能采集场景这个动作非常值。3. 游戏测试工程师天天离不开这三种模式讲完语法这一章落到场景。r、w、a不是三个抽象概念它们对应着游戏测试日常里最频繁的三种需求从文件构造被测状态、把结论变成可交付资产、持续记录运行过程。3.1 读取模式在日常测试中的用法校验配置、构造存档状态游戏测试的第一步往往是先搞清楚“现在被测的到底是什么状态”。配置文件是最常见的状态来源。研发把音量默认值、语言选项、画质档位写进config.json你的测试脚本要用r模式读进来逐项断言是否符合需求文档里的设定。存档文件更是如此。产品想验证“金币数达到999999时商店页面是否会出现特殊按钮”你不可能手动去刷几十万金币正确做法是直接改存档文件。现在的游戏存档基本都是JSON格式用r模式把存档读进Python改完字段再用w模式写回去import json with open(save.json, r, encodingutf-8) as f: save json.load(f) save[gold] 999999 with open(save.json, w, encodingutf-8) as f: json.dump(save, f, ensure_asciiFalse, indent2)这里特别提醒一下改存档属于“修改既有文件”虽然最终写回确实用了w模式但前提是必须先用r模式把原始内容完整读进内存改完再整体覆盖。如果上来就w模式打开那文件已经空了你到时候拼的就不是“修改后的存档”而是一份残缺数据。这个前后顺序就是测试工作中“先读入、后加工、再写回”的标准链路。3.2 写入模式在测试中的典型用法把结论变成可交付的报告自动化测试跑完结果只打印在终端里等于没测。你手上几百条用例几十个成功几个失败开发要的是能打开、能翻看、能留在缺陷单里的材料。这时候w模式就是标准出口。我习惯把测试结果直接写成Markdown报告通用性强测试组、开发组都能直接打开往协作平台上贴也非常方便results [ {name: 登录功能, status: PASS, time: 1.2}, {name: 商店购买, status: FAIL, time: 3.5}, {name: 设置修改, status: PASS, time: 0.8}, ] with open(case_report.md, w, encodingutf-8) as f: f.write(# 回归测试报告\n\n) f.write(f用例总数: {len(results)}\n\n) for case in results: f.write(f- {case[name]}: **{case[status]}** ({case[time]}s)\n)用w模式生成报告核心逻辑是“这一次的结果完全覆盖上一次的记录”因为报告只要反映最新一轮测试就够不需要跟旧报告混在一起。这一点跟日志天然不同——报告要新日志要全两个需求正好对应w与a的分工。3.3 追加模式支撑长时运行日志与性能采集是它的主场游戏性能测试和稳定性测试一跑就是半小时起步这段时间产生的数据必须一丝不苟地留在文件里。帧率、内存占用、加载时长每一条单独看没什么串起来才能看出性能曲线的变化规律。性能采集场景有个硬要求程序崩溃了前面累计的数据不能丢。w模式重开一次就清空旧记录绝对不能用r模式又写不进去。唯有追加模式天然就是为这种“持续累积”而生的import time with open(fps_log.csv, a, encodingutf-8) as f: for _ in range(600): fps get_current_fps() # 从引擎或外设读取实时帧率 memory get_current_memory() # 读取当前内存占用 f.write(f{int(time.time())},{fps},{memory}\n) f.flush() time.sleep(1)这套代码跑10分钟fps_log.csv里就多了600行记录跑1小时就是3600行。中途脚本崩了也不用慌之前写的每一行都因为flush()稳稳躺在硬盘上。我在做某次稳定性测试时脚本半夜崩了第二天一看崩溃前20分钟的性能数据一条没丢靠的就是追加模式加flush这套组合。从数据回看帧率突变的时间点正好跟那次资源加载吻合问题一下子就定位了。4. 实战操练把第二周知识点串成一个日志分析小工具这一章直接动手写一个完整工具。你要做的是把一个游戏的错误日志吞进去吐出一份分析报告同时把分析过程记到历史文件里。这个工具麻雀虽小但第二周的变量、列表、字典、循环、分支、函数、异常处理、文件读写一个不落全用上了。4.1 需求拆解这个工具要完成哪几件事假设游戏跑了一批测试留下一个error.log里面每一行都有清晰的日志级别标识[2025-01-10 10:30:12] [INFO] 游戏启动版本号 3.2.1 [2025-01-10 10:30:13] [INFO] 加载角色模型 [2025-01-10 10:30:15] [WARNING] 内存占用偏高 560MB [2025-01-10 10:30:18] [ERROR] 加载纹理文件失败texture_armor.dds [2025-01-10 10:30:20] [INFO] 进入主菜单 [2025-01-10 10:30:22] [ERROR] 存档写入失败磁盘空间不足 [2025-01-10 10:30:25] [WARNING] 网络延迟超过300ms工具要满足四个要求用读取模式逐行扫描日志统计INFO、WARNING、ERROR三个级别的数量。把包含ERROR的行单独提取出来后续要重点分析。用写入模式生成一份analysis_report.txt报告把统计结果和错误明细沉淀下来。用追加模式把“本次分析的执行时间和错误数量”记入history.log方便日后回溯。再加一条底线日志文件不存在、或者编码不是UTF-8程序都不能崩要给出明确提示后退出去。4.2 代码实现从读取到统计再到双路落盘第一步定义函数并初始化统计结构。字典是统计的天然工具三个键分别存三种级别的数量列表用来收集ERROR明细。import datetime def analyze_log(log_path): stats {INFO: 0, WARNING: 0, ERROR: 0} error_lines []第二步用读取模式逐行扫描。这里用for line in f而不是readlines()日志再大也不怕内存爆炸。try: with open(log_path, r, encodingutf-8) as f: for line in f: if [ERROR] in line: stats[ERROR] 1 error_lines.append(line.strip()) elif [WARNING] in line: stats[WARNING] 1 elif [INFO] in line: stats[INFO] 1 except FileNotFoundError: print(f找不到日志文件: {log_path}) return except UnicodeDecodeError: print(f日志编码不是UTF-8请确认文件格式: {log_path}) return第三步用写入模式生成报告。w模式的意义在于下一轮重新跑分析时旧报告被新报告完整覆盖留下的永远是最新结果。report_path analysis_report.txt with open(report_path, w, encodingutf-8) as f: f.write(日志分析报告\n) f.write( * 30 \n) f.write(fINFO数量: {stats[INFO]}\n) f.write(fWARNING数量: {stats[WARNING]}\n) f.write(fERROR数量: {stats[ERROR]}\n) f.write(- * 30 \n) f.write(ERROR明细:\n) for err in error_lines: f.write(err \n)第四步用追加模式把本次分析的过程写入历史。历史文件的价值在于累积所以这里绝不能用w否则历史记录会被一轮新分析冲掉。now datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) with open(history.log, a, encodingutf-8) as f: f.write(f{now} 完成一次日志分析ERROR {stats[ERROR]} 条\n) print(分析完成报告已生成:, report_path)最后加上入口判断让脚本既可以独立执行也能被别人导入调用if __name__ __main__: analyze_log(error.log)这个工具从开头到结尾用的全是第二周的知识点字典存储统计、列表保存错误行、for循环逐行扫描、if分支判断级别、函数封装逻辑、异常处理兜底最后r、w、a三种模式各司其职。做完这个小项目第二周的所有内容就真正连成一条线了。4.3 跑起来看效果输入、输出与结果验证拿4.1节那份模拟日志跑一次程序输出分析完成报告已生成: analysis_report.txt同时生成两个文件。analysis_report.txt的内容是日志分析报告 INFO数量: 3 WARNING数量: 2 ERROR数量: 2 ------------------------------ ERROR明细: [2025-01-10 10:30:18] [ERROR] 加载纹理文件失败texture_armor.dds [2025-01-10 10:30:22] [ERROR] 存档写入失败磁盘空间不足history.log里追加了一条2025-01-10 10:30:28 完成一次日志分析ERROR 2 条这时候可以验证一下三种模式的真实行为把日志文件删掉再跑一次程序不会崩溃而是提示找不到文件把日志文件用GBK编码保存再跑程序会提示编码问题。等把这两个异常都处理明白了你对文件读写的理解就从“能跑”升级成了“稳得住”。5. 编码与路径新手在文件读写上翻车的重灾区模式选对只是第一步。文件读写还有一个让大量初学者头疼的问题代码在别人电脑上跑没问题换到你这就乱码、找不到文件、打不开。这背后主要是编码和路径两件事。5.1 编码不一致Windows与UTF-8的纠缠Python 3的字符串默认是Unicode读写文件时则需要把Unicode编码成字节流再落盘编码方式必须跟文件的实际编码对齐。麻烦在于Windows中文版系统上的历史遗留记事本默认用的是GBK而绝大多数现代项目和日志文件都已经采用UTF-8。如果你open()时不指定encoding参数Python会参考当前系统的默认编码。在Windows中文系统上很多场景会落到GBK。这会导致一个很典型的症状打开一个UTF-8编码的log文件中文全部变成乱码甚至直接抛UnicodeDecodeError。解决办法非常简单直接所有open()都显式指定编码。with open(error.log, r, encodingutf-8) as f: for line in f: print(line.strip())如果遇到的是老游戏遗留的GBK日志文件那就把encoding改成gbk。还有一个实用的排查技巧文件用VS Code或者Notepad打开右下角会显示当前文件的编码照着它填就是最稳的。额外唠叨一句写文件时也别忘了指定encodingutf-8尤其是Windows下写中文报告不指定编码生成的txt文件用记事本打开能看但很多测试工具读进去会乱码统一UTF-8能省去后面一堆麻烦。5.2 路径问题反斜杠、相对路径和运行目录第二个高频翻车点是路径。第一个坑是Windows路径里的反斜杠。在Python字符串里反斜杠是转义符所以C:\game\logs\error.log会被解释得乱七八糟常见处理是写成原始字符串log_path rC:\game\logs\error.log第二个坑更隐蔽相对路径是相对的“当前工作目录”但当前工作目录不一定是脚本所在的目录。你在IDE里运行脚本启动目录由IDE决定你在命令行里运行启动目录是你当时所在的文件夹。同一个相对路径换个启动方式就指向不同文件于是经常出现“在我电脑上没问题到你那就FileNotFoundError”。推荐做法是用pathlib根据脚本自身位置计算路径from pathlib import Path base_dir Path(__file__).resolve().parent log_path base_dir / logs / error.log__file__是当前脚本文件的位置resolve()把相对路径转成绝对路径parent拿到脚本所在目录再往下一层拼接logs目录。这样不管从哪启动、在哪台机器上跑路径都能稳定落到同一处。测试项目里日志、配置、报告往往分散在不同目录用pathlib拼路径比手动加号拼接字符串清爽得多也不会碰到反斜杠转义的问题。5.3 文件不存在与权限工具健壮性从异常处理起步文件操作里最常见的两类异常一是FileNotFoundError文件不存在二是PermissionError文件被占用或没有权限。游戏测试脚本经常被放在各种环境里跑日志缺失、报告被Excel占用打不开都是家常便饭。健壮的测试工具应该有明确的容错逻辑。一个简单的准则是根据场景决定要不要“救”。try: with open(run_result.txt, w, encodingutf-8) as f: f.write(测试结果) except PermissionError: print(文件被占用请关闭Excel等程序后重试) except OSError as e: print(f其他系统错误: {e})读取场景比较特殊某个文件不存在时如果它是非关键的辅助文件可以跳过如果它是被测试的核心数据文件那宁可让脚本停下来也不要假装一切正常继续跑。异常处理不是让你把所有错误都吞掉而是让你在报错的时候给出足够清晰的信息让测试人员三秒钟内知道该检查什么。第二周学到这一步你写出的小工具就已经从“能在自己机器上跑”进化到“能在测试组的机器上跑”了。最后再分享一个我自己的习惯动手写任何跟文件打交道的脚本前先大声把模式念出来——这个文件我是要读、要覆盖还是要追加顺序想清楚90%的运行事故都能避免。第二周的知识点整合格局说白了就一句话让循环、列表、函数这些基本功配上r、w、a三种文件模式真正能处理测试里那些看得见摸得着的文件。你把这个小工具写完、跑通、改过几个异常之后回头再看第二周一定会觉得知识全活了。
Python文件读写三种模式，游戏测试日志分析与报告生成实战
带测试新人学Python时我最常被问的一句话是“文件读写到底在游戏测试里有什么用”问这个问题的同学多半刚学到第二周语法摸了个大概循环、列表、函数都还没捂热突然接触到open()、write()、readlines()整个人是懵的。其实文件读写没这么玄乎——它就是让Python程序跟硬盘上的文件互相交换数据而你作为游戏测试工程师以后读配置文件、写测试报告、攒运行日志本质上全是在三件事之间打转读取、写入、追加。把这三种核心模式啃明白第二周才算真正通关。今天这篇就把第二周所有知识点做一次整合顺便用游戏测试的实际场景把文件读写彻底讲透。1. 第二周学完为什么文件读写是必须啃下来的硬骨头1.1 第二周的知识版图所有基础语法都在给文件读写做铺垫很多同学学到第二周会有一种感觉变量、分支、循环、列表、函数都学了但不知道这些零散的工具凑在一起能干成什么事。这很正常因为第二周本来就是打地基的阶段而文件读写恰好是把这些零散工具组装起来的最佳练习场。第二周的课程通常覆盖这些内容变量与数据类型、输入输出、条件判断、循环、列表与字典、函数、异常处理入门最后落到文件读写。它们之间的配合关系可以拿测试工作来对照着看。第二周知识点一句话理解在游戏测试里的对应场景变量与数据类型给数据起名字并分类记录用例编号、测的版本号、机型型号输入输出程序与人交互手动测试时输入账号密码、输出提示条件判断按规则走不同分支按日志级别分流处理循环让重复动作自动化遍历几百条用例、逐行扫描日志列表与字典批量存储和快速查找保存用例集、用字典统计错误类型函数把一段逻辑打包复用封装日志解析、结果汇总异常处理出错时不至于崩溃文件缺失、编码错误时的兜底文件读写在内存和硬盘之间搬数据读配置、写报告、存日志这张表里文件读写之所以放在最后不是因为它最难而是因为它要用到前面几乎全部的东西。想逐行分析日志文件你得会用for循环想统计各种错误出现几次你得会用字典想把这套分析逻辑反复跑你得会用函数文件万一找不到或者编码错了你得会用异常处理。所以第二周的收尾一定是文件操作它相当于一次“验收考试”。1.2 文件读写是把程序与数据世界焊在一起的桥先说一个容易被初学者忽视的事实程序一旦退出内存里的变量全都没了。你殚精竭虑统计出来的错误数量、精心构造的测试数据关掉终端的一瞬间就蒸发。游戏测试这个岗位偏偏最看重“留证据、给结论、找规律”——测试结论要能交付证据要能追溯数据要能分析而这些全都要落在文件里。打个比方变量是捧在手里的水文件才是装进杯子的水。程序结束时手里的水洒了杯子里的水还在。游戏测试工程师跟研发扯皮的时候拿出一份txt报告、一份日志文件比嘴上说一百句都管用。配置文件、存档文件、日志文件、报告文件都是程序之外的真实存在你的测试脚本要能“从文件里取货”也要能“把结果打包发货”靠的就是文件读写。我见过不少新人学到最后能写出漂亮的循环但一碰到“怎么把结果留下来”就卡住最后只能人肉复制终端输出。那自动化测试的效率至少打折一半。第二周学文件读写的意义就是让你从“代码在内存里自嗨”跳到“代码和外部世界真正互动”这一步跨过去后面写任何测试工具都有底气。2. 三大核心模式的真正区别读、写、追加到底谁该用谁这一章是整个第二周的重头戏。文件读写的核心是open()函数里的mode参数r、w、a这三个字母决定了你这个文件在Python眼里是“只能看”“彻底重来”还是“持续续写”。模式选错轻则读不到数据重则直接把配置清空。我逐个拆开讲。2.1 读取模式r只带眼睛入场绝不动数据读取模式是最安全、也最容易理解的一种。open(file_path, r)打开一个文件用来读取内容这个文件的原始数据不会被改动。r模式有几条死规矩文件必须存在否则直接报FileNotFoundError。在游戏测试里这反而是好事比如日志文件缺失说明测试环境没搭对报错正好提醒你先去查环境。r模式打开后指针默认在文件开头可以顺序往下读。想写文件r模式不行会报io.UnsupportedOperation。读取数据又分三种方式很多新手在这块混成一锅粥方法返回内容适合场景read()整个文件拼成一个大字符串文件很小、要全文搜索readline()一次只读一行返回字符串手动逐行处理readlines()所有行组成一个列表行数少、需要随机访问某一行但说句实话游戏测试里最常见的日志文件往往很大几百MB也不奇怪。这时候readlines()会把全部行都塞进内存机子差点直接卡死。我最推荐的方式是用for循环直接迭代文件对象with open(error.log, r, encodingutf-8) as f: for line in f: print(line.strip())这种写法的底层是一行一行地读读完一行处理一行内存占用极小跑上千行的日志毫无压力。初学者可以记住一个简单结论纯读取场景默认用for line in f遍历错不了。读取模式还有个“指针”概念要搞明白——文件打开后Python会维护一个位置标记读一行指针前进一次读到末尾之后再读就返回空字符串。这个指针概念在追加模式那边还会再遇到。2.2 写入模式w从零开始整个文件推倒重来写入模式是三种模式里最危险的但恰恰是很多人最爱乱用的。open(file_path, w)的核心行为是文件不存在就自动创建文件已存在就先把旧内容全部清空再从第一行开始写。我私下给新人讲课的时候常说w的“w”与其记成write不如记成wipe——抹掉重来。写代码时一个手滑把r打成w打开的瞬间旧文件就没了连提示都不带打的。游戏测试里真出过这种事故有同学想“更新”一份旧的配置文件用w模式打开写了几行新配置结果整个文件原有配置被清得干干净净最后只能找研发要备份重做。所以用w模式之前一定要问自己一句这个文件里旧的东西我确定不要了写入的具体操作有两个write()和writelines()。write()写单个字符串writelines()接收一个字符串列表把列表的每一项连续写进去。注意它们都不会自动换行需要换行就得自己在字符串末尾加\n。with open(test_report.txt, w, encodingutf-8) as f: f.write(回归测试报告\n) f.write( * 30 \n) f.writelines([用例1: PASS\n, 用例2: FAIL\n, 用例3: PASS\n])另外提一句r后面跟个加号变成r意思是可读可写但不会清空文件w也是可读可写但依旧会先清空文件。初学者如果只是想写结果老老实实用w就行不要为了“多一个读的能力”去选w等真正需要两个方向操作时再切换避免把问题搞复杂。2.3 追加模式a保留历史只在末尾续写追加模式a存在的意义就是“不破坏既有内容只在文件末尾继续写”。文件名不存在时自动创建文件已存在时保留原内容新内容一行一行接在后面。这个特性让它成了日志类数据的天然归宿。游戏测试里最常见的流水账是性能日志、内存占用日志、每轮用例的执行历史。你跑完一轮测试往history.log里追加一条“某年某月某日完成回归测试发现3个Bug”下一轮再追加一条文件越积累越有分析价值。如果这里用w模式每跑一轮就要把之前的记录清掉历史全丢就完全背离了日志的初衷。a模式有两个容易踩的坑打开后直接read()会得到空字符串。因为追加模式的指针默认指向文件末尾你还没写呢它已经站在结尾了。想读旧内容需要手动seek(0)。无论你把指针挪到哪里write()的内容永远落在文件末尾。这是追加模式写死的规则。with open(history.log, a, encodingutf-8) as f: f.write(2025-01-10 10:30:00 完成第3轮回归异常数: 2\n)有一种理解方式比较省脑子追加模式就像你在一本已经写了很多页的笔记本后面继续记前面怎么写好的一个字都不会动。2.4 别忘配套动作with语句到底帮你干了什么三种模式讲完还得把打开文件的标准姿势补上。常见写法是with open(..., mode) as f:很多人只把它当成固定模板背下来其实它解决的是“文件用完要关闭”这个老大难。如果不用with你得这样写f open(test.txt, w, encodingutf-8) f.write(hello) f.close()问题在于如果write()中间程序抛了异常close()这行根本执行不到文件就开着没人管。更常见的是写完忘关程序把内容放在缓冲区还没真正落到硬盘一旦程序崩溃数据就丢了。with语句则是一个上下文管理器它承诺代码块里的内容无论正常跑完还是中途异常跳出退出时都会自动关闭文件把缓冲区数据刷到磁盘。对测试脚本来说这几乎是保命级的操作因为测试跑着跑着出异常实在太常见了。还有一个细节重要日志需要实时落盘。with退出时确实会自动刷盘但如果程序直接被强杀、断电、或者测试到一半系统蓝屏缓冲区里没来得及写的数据照样会丢。所以写需要长时累积的关键数据时我习惯在循环里手动加一句f.flush()每写一行就强制刷到硬盘牺牲少量性能换数据安全。尤其是第3章要讲到的性能采集场景这个动作非常值。3. 游戏测试工程师天天离不开这三种模式讲完语法这一章落到场景。r、w、a不是三个抽象概念它们对应着游戏测试日常里最频繁的三种需求从文件构造被测状态、把结论变成可交付资产、持续记录运行过程。3.1 读取模式在日常测试中的用法校验配置、构造存档状态游戏测试的第一步往往是先搞清楚“现在被测的到底是什么状态”。配置文件是最常见的状态来源。研发把音量默认值、语言选项、画质档位写进config.json你的测试脚本要用r模式读进来逐项断言是否符合需求文档里的设定。存档文件更是如此。产品想验证“金币数达到999999时商店页面是否会出现特殊按钮”你不可能手动去刷几十万金币正确做法是直接改存档文件。现在的游戏存档基本都是JSON格式用r模式把存档读进Python改完字段再用w模式写回去import json with open(save.json, r, encodingutf-8) as f: save json.load(f) save[gold] 999999 with open(save.json, w, encodingutf-8) as f: json.dump(save, f, ensure_asciiFalse, indent2)这里特别提醒一下改存档属于“修改既有文件”虽然最终写回确实用了w模式但前提是必须先用r模式把原始内容完整读进内存改完再整体覆盖。如果上来就w模式打开那文件已经空了你到时候拼的就不是“修改后的存档”而是一份残缺数据。这个前后顺序就是测试工作中“先读入、后加工、再写回”的标准链路。3.2 写入模式在测试中的典型用法把结论变成可交付的报告自动化测试跑完结果只打印在终端里等于没测。你手上几百条用例几十个成功几个失败开发要的是能打开、能翻看、能留在缺陷单里的材料。这时候w模式就是标准出口。我习惯把测试结果直接写成Markdown报告通用性强测试组、开发组都能直接打开往协作平台上贴也非常方便results [ {name: 登录功能, status: PASS, time: 1.2}, {name: 商店购买, status: FAIL, time: 3.5}, {name: 设置修改, status: PASS, time: 0.8}, ] with open(case_report.md, w, encodingutf-8) as f: f.write(# 回归测试报告\n\n) f.write(f用例总数: {len(results)}\n\n) for case in results: f.write(f- {case[name]}: **{case[status]}** ({case[time]}s)\n)用w模式生成报告核心逻辑是“这一次的结果完全覆盖上一次的记录”因为报告只要反映最新一轮测试就够不需要跟旧报告混在一起。这一点跟日志天然不同——报告要新日志要全两个需求正好对应w与a的分工。3.3 追加模式支撑长时运行日志与性能采集是它的主场游戏性能测试和稳定性测试一跑就是半小时起步这段时间产生的数据必须一丝不苟地留在文件里。帧率、内存占用、加载时长每一条单独看没什么串起来才能看出性能曲线的变化规律。性能采集场景有个硬要求程序崩溃了前面累计的数据不能丢。w模式重开一次就清空旧记录绝对不能用r模式又写不进去。唯有追加模式天然就是为这种“持续累积”而生的import time with open(fps_log.csv, a, encodingutf-8) as f: for _ in range(600): fps get_current_fps() # 从引擎或外设读取实时帧率 memory get_current_memory() # 读取当前内存占用 f.write(f{int(time.time())},{fps},{memory}\n) f.flush() time.sleep(1)这套代码跑10分钟fps_log.csv里就多了600行记录跑1小时就是3600行。中途脚本崩了也不用慌之前写的每一行都因为flush()稳稳躺在硬盘上。我在做某次稳定性测试时脚本半夜崩了第二天一看崩溃前20分钟的性能数据一条没丢靠的就是追加模式加flush这套组合。从数据回看帧率突变的时间点正好跟那次资源加载吻合问题一下子就定位了。4. 实战操练把第二周知识点串成一个日志分析小工具这一章直接动手写一个完整工具。你要做的是把一个游戏的错误日志吞进去吐出一份分析报告同时把分析过程记到历史文件里。这个工具麻雀虽小但第二周的变量、列表、字典、循环、分支、函数、异常处理、文件读写一个不落全用上了。4.1 需求拆解这个工具要完成哪几件事假设游戏跑了一批测试留下一个error.log里面每一行都有清晰的日志级别标识[2025-01-10 10:30:12] [INFO] 游戏启动版本号 3.2.1 [2025-01-10 10:30:13] [INFO] 加载角色模型 [2025-01-10 10:30:15] [WARNING] 内存占用偏高 560MB [2025-01-10 10:30:18] [ERROR] 加载纹理文件失败texture_armor.dds [2025-01-10 10:30:20] [INFO] 进入主菜单 [2025-01-10 10:30:22] [ERROR] 存档写入失败磁盘空间不足 [2025-01-10 10:30:25] [WARNING] 网络延迟超过300ms工具要满足四个要求用读取模式逐行扫描日志统计INFO、WARNING、ERROR三个级别的数量。把包含ERROR的行单独提取出来后续要重点分析。用写入模式生成一份analysis_report.txt报告把统计结果和错误明细沉淀下来。用追加模式把“本次分析的执行时间和错误数量”记入history.log方便日后回溯。再加一条底线日志文件不存在、或者编码不是UTF-8程序都不能崩要给出明确提示后退出去。4.2 代码实现从读取到统计再到双路落盘第一步定义函数并初始化统计结构。字典是统计的天然工具三个键分别存三种级别的数量列表用来收集ERROR明细。import datetime def analyze_log(log_path): stats {INFO: 0, WARNING: 0, ERROR: 0} error_lines []第二步用读取模式逐行扫描。这里用for line in f而不是readlines()日志再大也不怕内存爆炸。try: with open(log_path, r, encodingutf-8) as f: for line in f: if [ERROR] in line: stats[ERROR] 1 error_lines.append(line.strip()) elif [WARNING] in line: stats[WARNING] 1 elif [INFO] in line: stats[INFO] 1 except FileNotFoundError: print(f找不到日志文件: {log_path}) return except UnicodeDecodeError: print(f日志编码不是UTF-8请确认文件格式: {log_path}) return第三步用写入模式生成报告。w模式的意义在于下一轮重新跑分析时旧报告被新报告完整覆盖留下的永远是最新结果。report_path analysis_report.txt with open(report_path, w, encodingutf-8) as f: f.write(日志分析报告\n) f.write( * 30 \n) f.write(fINFO数量: {stats[INFO]}\n) f.write(fWARNING数量: {stats[WARNING]}\n) f.write(fERROR数量: {stats[ERROR]}\n) f.write(- * 30 \n) f.write(ERROR明细:\n) for err in error_lines: f.write(err \n)第四步用追加模式把本次分析的过程写入历史。历史文件的价值在于累积所以这里绝不能用w否则历史记录会被一轮新分析冲掉。now datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) with open(history.log, a, encodingutf-8) as f: f.write(f{now} 完成一次日志分析ERROR {stats[ERROR]} 条\n) print(分析完成报告已生成:, report_path)最后加上入口判断让脚本既可以独立执行也能被别人导入调用if __name__ __main__: analyze_log(error.log)这个工具从开头到结尾用的全是第二周的知识点字典存储统计、列表保存错误行、for循环逐行扫描、if分支判断级别、函数封装逻辑、异常处理兜底最后r、w、a三种模式各司其职。做完这个小项目第二周的所有内容就真正连成一条线了。4.3 跑起来看效果输入、输出与结果验证拿4.1节那份模拟日志跑一次程序输出分析完成报告已生成: analysis_report.txt同时生成两个文件。analysis_report.txt的内容是日志分析报告 INFO数量: 3 WARNING数量: 2 ERROR数量: 2 ------------------------------ ERROR明细: [2025-01-10 10:30:18] [ERROR] 加载纹理文件失败texture_armor.dds [2025-01-10 10:30:22] [ERROR] 存档写入失败磁盘空间不足history.log里追加了一条2025-01-10 10:30:28 完成一次日志分析ERROR 2 条这时候可以验证一下三种模式的真实行为把日志文件删掉再跑一次程序不会崩溃而是提示找不到文件把日志文件用GBK编码保存再跑程序会提示编码问题。等把这两个异常都处理明白了你对文件读写的理解就从“能跑”升级成了“稳得住”。5. 编码与路径新手在文件读写上翻车的重灾区模式选对只是第一步。文件读写还有一个让大量初学者头疼的问题代码在别人电脑上跑没问题换到你这就乱码、找不到文件、打不开。这背后主要是编码和路径两件事。5.1 编码不一致Windows与UTF-8的纠缠Python 3的字符串默认是Unicode读写文件时则需要把Unicode编码成字节流再落盘编码方式必须跟文件的实际编码对齐。麻烦在于Windows中文版系统上的历史遗留记事本默认用的是GBK而绝大多数现代项目和日志文件都已经采用UTF-8。如果你open()时不指定encoding参数Python会参考当前系统的默认编码。在Windows中文系统上很多场景会落到GBK。这会导致一个很典型的症状打开一个UTF-8编码的log文件中文全部变成乱码甚至直接抛UnicodeDecodeError。解决办法非常简单直接所有open()都显式指定编码。with open(error.log, r, encodingutf-8) as f: for line in f: print(line.strip())如果遇到的是老游戏遗留的GBK日志文件那就把encoding改成gbk。还有一个实用的排查技巧文件用VS Code或者Notepad打开右下角会显示当前文件的编码照着它填就是最稳的。额外唠叨一句写文件时也别忘了指定encodingutf-8尤其是Windows下写中文报告不指定编码生成的txt文件用记事本打开能看但很多测试工具读进去会乱码统一UTF-8能省去后面一堆麻烦。5.2 路径问题反斜杠、相对路径和运行目录第二个高频翻车点是路径。第一个坑是Windows路径里的反斜杠。在Python字符串里反斜杠是转义符所以C:\game\logs\error.log会被解释得乱七八糟常见处理是写成原始字符串log_path rC:\game\logs\error.log第二个坑更隐蔽相对路径是相对的“当前工作目录”但当前工作目录不一定是脚本所在的目录。你在IDE里运行脚本启动目录由IDE决定你在命令行里运行启动目录是你当时所在的文件夹。同一个相对路径换个启动方式就指向不同文件于是经常出现“在我电脑上没问题到你那就FileNotFoundError”。推荐做法是用pathlib根据脚本自身位置计算路径from pathlib import Path base_dir Path(__file__).resolve().parent log_path base_dir / logs / error.log__file__是当前脚本文件的位置resolve()把相对路径转成绝对路径parent拿到脚本所在目录再往下一层拼接logs目录。这样不管从哪启动、在哪台机器上跑路径都能稳定落到同一处。测试项目里日志、配置、报告往往分散在不同目录用pathlib拼路径比手动加号拼接字符串清爽得多也不会碰到反斜杠转义的问题。5.3 文件不存在与权限工具健壮性从异常处理起步文件操作里最常见的两类异常一是FileNotFoundError文件不存在二是PermissionError文件被占用或没有权限。游戏测试脚本经常被放在各种环境里跑日志缺失、报告被Excel占用打不开都是家常便饭。健壮的测试工具应该有明确的容错逻辑。一个简单的准则是根据场景决定要不要“救”。try: with open(run_result.txt, w, encodingutf-8) as f: f.write(测试结果) except PermissionError: print(文件被占用请关闭Excel等程序后重试) except OSError as e: print(f其他系统错误: {e})读取场景比较特殊某个文件不存在时如果它是非关键的辅助文件可以跳过如果它是被测试的核心数据文件那宁可让脚本停下来也不要假装一切正常继续跑。异常处理不是让你把所有错误都吞掉而是让你在报错的时候给出足够清晰的信息让测试人员三秒钟内知道该检查什么。第二周学到这一步你写出的小工具就已经从“能在自己机器上跑”进化到“能在测试组的机器上跑”了。最后再分享一个我自己的习惯动手写任何跟文件打交道的脚本前先大声把模式念出来——这个文件我是要读、要覆盖还是要追加顺序想清楚90%的运行事故都能避免。第二周的知识点整合格局说白了就一句话让循环、列表、函数这些基本功配上r、w、a三种文件模式真正能处理测试里那些看得见摸得着的文件。你把这个小工具写完、跑通、改过几个异常之后回头再看第二周一定会觉得知识全活了。
![[游戏开发日志] day 3 - Godot 跑起来：用 TaoToken 统一 Key 接入像素风等距赛博朋克原型](http://pic.xiahunao.cn/yaotu/[游戏开发日志] day 3 - Godot 跑起来：用 TaoToken 统一 Key 接入像素风等距赛博朋克原型)
