1. 别慌先看懂 PyCharm 为什么把你的脚本当成了 test遇到“pycharm一运行就是test怎么改”这句话的朋友十有八九是点击了那个绿色三角结果底部控制台没有像以往那样老老实实跑你的if __name__ __main__:而是弹出来一段 pytest 的输出甚至跑完了什么都没打印只给个Process finished with exit code 0。这种体验确实让人憋屈但你得先明白一件事这不是你的电脑坏了也不是 PyCharm 疯掉了而是PyCharm 的测试自动发现机制test discovery替你做主了。1.1 插槽匹配原理pytest 为什么总能在角落里找到你的文件pytest 有一套自己的“找文件规则”PyCharm 默认装好了 pytest 插件当你项目里存在以下任意一种情况它就会认为“这是一个测试文件”文件名以test_开头或_test.py结尾文件名就是test.py文件内部的函数名以test_开头文件内部的类名以Test开头并且这个类里含有test_开头的方法。你回想一下你的报错文件或者脚本文件是不是叫test_baogao.py、test01.py、或者里面定义了一个叫test_python()的函数我见过很多朋友写代码多年文件命名习惯是“功能 test”比如test_apk.py、test_db.py如果内容是验证连接、发送请求这些确实有“测试”的味道。但 PyCharm 不看你代码里的逻辑它只看名字和函数签名命中了就自动切到 pytest 运行方式。这个机制的根源是你在安装 PyCharm 时它会自动配置Python Integrated Tools 的默认测试运行器Default test runner默认值在很多版本里就是 pytest。一旦它扫到符合规则的文件运行命令就从python xxx.py变成了pytest xxx.py。1.2 两步判断你是不是真的“被 pytest 接管”了光看现象可能不准我有两个快速判断方法你可以先检查一下再改看运行配置下拉框。PyCharm 右上角那块写着当前运行配置。如果显示的是pytest in xxx.py或者test_xxx.py这样的名字而且运行按钮旁边有个像“双 V”一样的图标那它就是用 pytest 跑的。看控制台第一行。普通 Python 运行日志第一行是路径和 Python 解释器地址pytest 模式第一行会显式打出C:\...\pytest.exe之类的路径后面还会跟一个测试收集的进度列表比如collecting ... collected 1 item。这些特征你只要认出一次以后就不会再被它骗了。遇到这种状况你并不需要卸载 pytest、也不需要删虚拟环境下面几节的方法按顺序做基本五分钟之内能解决。2. 三种直接改回普通运行的姿势别再做无头苍蝇这个问题的核心是“修改运行的入口”不是“改代码”。你有三条路可以走按由快到慢排序我只把每一步说透。2.1 最快方案右键菜单里的 Run 其实分两种你点错了一个很多人点击运行的姿势是选中文件然后点右上角绿色三角。这个动作等价于“使用上次的配置运行”如果上次配置被 PyCharm 自动建成了 pytest那它就一直用 pytest。正确做法是在代码编辑器左侧的文件名标签页上点击鼠标右键在弹出的菜单里选择Run ‘你的文件名’注意文件名后缀.py可能被省略但别跟下面的 pytest 选项搞混如果你从来没有为这个文件创建过普通 Python 运行配置PyCharm 会立刻新建一个Python类型的配置并直接运行。这里有个关键细节右键菜单里如果出现Run ‘pytest in 你的文件名’就说明你之前用过 pytest 方式运行过这个文件PyCharm 记住了把它放到了右键菜单的同一级。你只要选上面那个不带pytest in前缀的普通 Run 项就行。如果两种选项都在那就优先选普通 Run 项。右键菜单是临时的运行动作它不修改任何全局配置所以是最安全、最不容易出错的方式。2.2 清掉“黑历史”运行配置真正的根治办法如果你不想每次右键选菜单希望点一下绿色三角就是普通运行那我建议你直接清理运行配置列表。运行配置是会“记忆”的PyCharm 会把旧配置存在工作区里。步骤如下打开 PyCharm 顶部工具栏找到运行配置下拉框点击那排下拉箭头选择Edit Configurations...编辑配置在左侧列表里找到所有名字里带有pytest in ...的配置项或者一个名字形如test_xxx.py的配置选中它们点击左上角的减号删除最后点右下角 Apply 和 OK。删干净后你再直接点文件的绿色三角运行PyCharm 没有旧配置可用就会按文件类型重新判断生成一个普通的 Python 运行配置。如果你已经执行过第 2.1 节的右键 Run那它会沿用它创建的普通配置就不会再出问题了。这一步清理动作尤其适合项目用了很久、运行配置列表特别杂乱的情况。2.3 釜底抽薪修改默认测试运行器设置你的 PyCharm 之所以喜欢把 test 开头文件当 pytest是因为它在全局设置里认定了 pytest 为你默认的测试框架。你可以在 PyCharm 的设置里把它改成别的或者干脆关掉测试发现机制。操作系统不同入口略有差异点击File SettingsWindows 或 Linux或者PyCharm PreferencesmacOS在左侧栏找Tools展开后选Python Integrated Tools在右边的Testing区域有一个Default test runner下拉框默认值通常是pytest把它改成Unittests或者如果你想彻底摆脱可以直接选Disabled。如果不打算在这个项目里写单元测试我推荐选Disabled让 PyCharm 别再把任何文件跟测试框架绑定。如果你需要继续写测试选Unittests可能更温和不会被 pytest 那个自动收集机制“绑架”。改完之后原来生成的旧配置不会立刻消失还得回第 2.2 步把旧配置删干净两者搭配使用才彻底。3. 如果你的代码本来就是测试代码又不想被误跑怎么处理有一部分朋友的情况是不一样的他们写的确实是测试用例用 pytest 运行是正确的但由于整个文件里混入了普通的调试代码或者文件路径和测试代码混在一起导致一运行就跑出很多无关用例或者干脆只跑了第一个用例就停了。这种问题不是“改回普通运行”而是要“让 pytest 按你指定的方式运行”。3.1 用运行目标的粒度控制只跑你想跑的测试不跑全部PyCharm 里识别测试文件后运行按钮的逻辑是这样的文件右键运行等价于pytest 文件名它会收集这个文件中所有符合test_开头的函数并全部执行。如果你只想跑其中一个用例直接把鼠标光标放在那个函数名上面然后再右键选择运行PyCharm 会提议运行pytest in 文件名::函数名。命令行里写清楚就是pytest test_login.py::test_about_info这样可以只执行指定的那个测试函数不用把它改名也不用删除其他用例。如果光标停在类名上则运行整个类中的全部测试方法。这个粒度控制是 pytest 比较实用的能力知道以后调试会高效很多。3.2 目录隔离大法给测试代码一个“独立小房间”如果你的项目中有普通脚本也有测试脚本两者都叫带 test 的名字互相干扰我建议你把所有测试文件放到专门的目录里比如根目录下建一个tests文件夹或者叫testcase文件夹。放进去之后PyCharm 的测试发现机制会默认从这个目录采集用例。你跑普通脚本时右键脚本选普通 Run 一点问题都没有你需要跑测试时右键那个 tests 文件夹里的文件PyCharm 会正确识别为 pytest 用例。这样处理两个世界互不打扰。但要注意一个坑PyCharm 里的Mark Directory as目录标记非常关键。如果你建了tests文件夹右键这个文件夹选择Mark Directory as然后选Tests Sources RootPyCharm 会把整个文件夹标记为测试专属目录。被标记成测试目录之后文件夹内所有文件默认认为是用例。如果你的某个文件虽然是放在 tests 目录里但它只是提供数据或工具函数那么它会被 pytest 尝试采集容易报错。处理方案很简单不要在 tests 目录里放不以 test 命名且不会包含 test 函数的工具模块或者你需要把普通脚本放在外面非测试代码不受采集影响。3.3 命令行运行绕开 PyCharm 图形界面的“千层套路”有时候图形界面的各种配置反而碍手碍脚我就直接用 Terminal 运行了。PyCharm 底部自带终端窗口打开后它会自动进入你项目的虚拟环境。普通脚本运行就用python your_script.py如果确实是测试文件想用 pytest 跑那就用pytest test_xxx.py如果 PyCharm 死活不给你跑普通 Python比如右键菜单都没有Run xxx使用命令行是最快恢复工作流的方式。你还可以通过命令行绕过运行配置并且逐步排查到底是 IDE 层面卡住了还是代码本身有问题。很多时候用户被“一运行就是test”困住直接在命令行里敲python 文件.py就能看到正常输出了压根不需要配置。3.4 关于 pytest 收集不到用例的处理心得反过来还有一种情况文件明明符合test命名但 PyCharm 运行后控制台提示no tests ran意思是“一个测试都没找到”。我早年踩过这个坑后来总结出来几个常见原因文件里函数名虽然以test开头但这个文件并不是被 pytest 当作模块导入因为 Python 包__init__.py缺失pytest 无法递归导入函数有参数但没写参数化标记pytest 不会自动注入数据类名以Test开头但类里的函数名没有以test开头函数被装饰器包裹但装饰器未正确传递__name__。这类问题处理思路不是改运行配置而是检查测试代码本身的导入路径和命名。前两种比较隐蔽我看到不少朋友在群里发截图说“为什么 pycharm 跑 test 没有结果”最后发现是缺失__init__.py在项目根目录创建空文件补一层包结构就可以跑了。说到底PyCharm 的运行配置只是入口能不能收集成功还得看 pytest 自己的规则代码结构问题只能按照它的规矩来。4. 常见问题与排查技巧实录这些坑我踩过替你们蹚平了每当我讲完上面这些内容总会有人在下边追问各种离奇现象我整理几个出现频率最高的问题顺便附上排查思路节省大家到处搜索的时间。4.1 为什么明明改成 Unittests 了一运行还走 pytest这个问题很典型。很多人设置改完了发现 PyCharm 依然用 pytest 跑于是就觉得“设置没用”。其实是因为你项目里已经存在一个 pytest 相关的运行配置。PyCharm 的运行配置就类似于一个“快捷方式”只要它在优先级别高于全局默认。你必须先去 Edit Configurations 里面删除那个带 pytest 标记的配置设置才会重新对下次新建的配置生效。这就好比你给整个房间换了灯的类型但桌面上那个台灯还插着电它照样亮你得把台灯拔了才能看到房间的新灯光。4.2 运行按钮是灰色的点击没反应如果你发现 PyCharm 工具栏上的运行按钮是灰色的大概率是当前文件没有被 PyCharm 接受为可运行目标。这种情况发生在文件尚未保存、还没设置好 Python 解释器或者文件处于非项目文件夹之外。先确认文件已经保存过再打开Settings Project Python Interpreter看看解释器是否配置了如果为空指定一个虚拟环境。如果解释器没问题关掉 PyCharm重新打开工程通常就能恢复。运行按钮灰色跟“test 误判”是两回事不要混淆前者通常是配置缺失后者是配置冗余。4.3 pytest 模式下控制台不显示 print 输出误以为代码没跑这个现象特别容易让新手崩溃。写了一段print(hello)运行 pytest控制台干干净净什么都没有只有退出码。不是说 pytest 不执行你的代码而是它默认会把 print 输出捕获起来只有测试失败时才展示。解决方式有两个在 pytest 运行配置里额外参数加上-s这样关闭捕获命令行运行pytest -s 文件名.py。我发现很多人其实并不需要 pytest 的采集功能只是无意中命名带 test被选中成了默认运行器真没必要为了打印输出去加-s折腾直接把默认测试运行器改成 Disabled一切都清静了。4.4 控制台输出中文乱码怎么调都不行很多人运行脚本时出现乱码跟是不是 pytest 没太大关系而是 Windows 控制台默认编码的问题。最简单的处理方式是在代码最上方加编码声明或者把文件存成 UTF-8 编码格式。但在 PyCharm 中更直接的办法是改动运行配置的 Environment variables加上PYTHONIOENCODINGutf-8环境变量。步骤打开 Edit Configurations选择对应的配置在 Environment variables 一栏填入PYTHONIOENCODINGutf-8保存后重新运行。如果你是用 pytest 跑的同样操作在 pytest 运行配置里设置。这个问题跟“test”无关但往往是被这个问题引出来的因为普通运行不显示输出所以没人注意到乱码pytest 模式下收集信息多了乱码更显眼。4.5 每次点运行都弹“Select Python Interpreter”窗口烦死了这个提示说明 PyCharm 当前项目还没有关联解释器。你可以在右下角状态栏看到 Python 版本号如果没有点击Add Interpreter选择虚拟环境。创建虚拟环境的建议是使用venv不要直接用全局解释器因为全局环境会积累大量第三方包也容易跟系统环境互相影响。配置一次以后大部分项目都能稳定运行。出现这个窗口跟 test 误判没有直接关系但如果你每次重新开项目都要选解释器说明你没有正确为项目指定解释器建议一次性配置好。4.6 配置列表里一串 pytest 配置越看越烦但还是会跑错之前提到删除配置但不少项目是团队协同的.idea文件夹存放项目配置被提交到版本库里了导致别人的运行配置混在一起。更好的做法是定期清理但更根本的方式是把.idea/workspace.xml中的运行配置有意识地清理或者从版本控制中排除毕竟运行配置属于个人使用习惯不应该跟随代码库共享。具体操作打开项目根目录的.idea文件夹找到workspace.xml你会看到无数个configuration块这就是历史运行配置。手动删除包含 pytest 的部分或者干脆 Git 里把.idea/workspace.xml加入忽略列表减少这类问题的发生频率。5. 还有什么容易忽略的细节一次性给你整明白问题解决了但真正用起来还会碰到一些边角料这里多说两句。5.1 分清“运行”和“调试”很多人把调试也搞混了PyCharm 里除了绿色三角是运行还有旁边的绿色瓢虫是调试。如果你的代码被识别成 pytest调试按钮也会变成 pytest 的调试模式。要是问题出在普通脚本里右键调试的时候也注意选不带pytest in前缀的那个调试入口。调试模式下断点机制和运行模式基本一致但 pytest 的调试模式会把测试的 fixture 生命周期也纳入断点范围容易踩到一些莫名其妙的断点看起来就像程序不动了。所以调试普通脚本前最好先确认运行配置是普通的Python类型。如果你发现调试入口不对同样按第 2.2 节删掉 pytest 配置即可。5.2 项目工作目录处处留神相对路径和文件路径别搞混不管是普通运行还是 pytestPyCharm 运行时默认工作目录都是项目的根目录。但 pytest 在采集测试用例时会基于文件实际所在目录做路径推导如果你在代码里写相对路径open(data.txt)普通脚本和 pytest 两种方式下相对路径的基准点可能不一样。这会导致同一份代码在普通运行时正常但被 pytest 运行时却找不到文件。这个问题看似跟主题无关却是很多人把运行模式切来切去之后冒出来的新麻烦。建议在所有代码文件里显式指定基于文件绝对路径的资源定位或者统一使用pathlib.Path(__file__).parent这种方式这样无论哪个运行器至少路径不会跑偏。5.3 运行配置命名有讲究别让“测试”的名字混进业务代码仓库最后说一个跟协作相关的建议。如果你所在的团队多人使用 PyCharm一定不要让.idea文件夹被提交到共享代码仓库。它里面的运行配置、测试框架标记都会跟着项目走别人拉下来代码之后PyCharm 会根据这些配置自动切换运行方式导致明明没写过测试却总是遇到“一运行就是 test”的怪现象。正确做法是团队共享代码用 Git 管理时在.gitignore文件里加入.idea/每个人都保留自己本地的运行习惯。这算是一种防御策略从源头防止别人被同样的问题恶心到。这些内容汇总起来说穿了就是“测试运行器”和“运行配置”这两个东西在捣鬼。工具是死的人是活的搞懂规则之后你也能像我一样看着报错列表三分钟找到元凶。希望这个经验分享对你有帮助以后回归快乐的日常写码别再跟 PyCharm 的运行按钮生闷气了。