这种情况确实挺闹心的——明明测试能通过，但stderr里飘着错误信息，真出问题的时候根本分不清哪些是噪音哪些是正经错误。我来帮你拆解下原因，再给几个切实可行的解决办法。

问题原因分析 #

核心矛盾是pytest运行时的子进程环境，和你直接跑Python/PowerShell时的环境存在隐性差异，再加上Visual Studio Dev Shell初始化脚本里的一些依赖没被正确处理，导致了非致命的stderr输出，但没影响脚本整体执行（所以测试依然通过）。具体说几个关键点：

1. 32位PowerShell的路径重定向坑
   你在foo.py里把COMSPEC设成了SysWOW64下的32位PowerShell，而Visual Studio的工具链大多是64位优先。在32位进程里，Windows的文件系统重定向器会搞点“小动作”：比如Program Files(x86)的指向看似正常，但Launch-VsDevShell.ps1或它导入的模块里，可能有直接调用vswhere.exe而不带完整路径的逻辑。这时候32位PowerShell的PATH里没包含vswhere的目录，就会抛出“找不到命令”的错误——但这个错误是脚本内部非致命的（比如有 fallback 逻辑，或者后续步骤不依赖它），所以脚本接着跑，测试也能过。

2. 带空格路径的未引号解析问题
   第二个错误Get-ChildItem : A positional parameter cannot be found，是因为Dev Shell的某个内部脚本直接执行了类似dir C:\Program Files\Microsoft Visual Studio...的命令，没给带空格的路径加引号。在pytest的子进程环境下，这个路径被拆成了C:\Program、Files\Microsoft等多个参数，导致参数错误；而你直接跑PowerShell时，可能因为环境上下文的差异（比如脚本内部有额外的路径处理），这个问题被隐性修复了。

3. pytest的stderr捕获逻辑
   直接跑Python或PowerShell时，这些非致命的stderr输出可能被Dev Shell的初始化脚本悄悄重定向到null了，或者你没注意到；但pytest会完整捕获子进程的所有stderr输出并展示出来，所以这些噪音就显形了。又因为这些错误没让脚本退出码变非0，subprocess.run的check=True也不会触发异常。

解决办法 #

按优先级推荐这几个方案，从根源解决到临时过渡都有：

1. 改用64位PowerShell执行脚本（最推荐）

32位PowerShell和Visual Studio Dev Shell的兼容性本来就差，直接切到64位版本，大部分路径相关的问题都会消失。修改foo.py：

import subprocess
import os

def test_run() -> None:
    # 改用64位PowerShell（System32是64位目录，SysWOW64是32位）
    os.environ["COMSPEC"] = "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
    
    # 更稳妥的调用方式：不用shell=True，直接指定可执行文件和脚本参数
    subprocess.run(
        ["powershell.exe", "-ExecutionPolicy", "Bypass", "-File", ".\\tmp.ps1"],
        check=True,
        # 可选：合并stdout/stderr方便调试，或者分别捕获
        # stdout=subprocess.PIPE,
        # stderr=subprocess.PIPE,
        # text=True
    )

2. 提前把vswhere路径加入PATH（适配32位场景）

如果必须用32位PowerShell，就在tmp.ps1开头把vswhere的目录加到当前会话的PATH里，确保后续脚本能找到它：

# tmp.ps1
# 先把vswhere所在目录加入PATH
$vsInstallerDir = "${env:ProgramFiles(x86)}/Microsoft Visual Studio/Installer"
$env:Path += ";$vsInstallerDir"

# 原来的逻辑不变
$vsInstallPath = & "$vsInstallerDir/vswhere.exe" -property installationpath
echo "VS install path: $vsInstallPath"
. "$vsInstallPath\Common7\Tools\Launch-VsDevShell.ps1" -arch amd64 -SkipAutomaticLocation -VsInstallationPath "$vsInstallPath"
echo 'hurray'

3. 不修改全局COMSPEC，直接指定执行的Shell

避免修改全局环境变量影响其他测试，在subprocess.run里用executable参数直接指定PowerShell路径：

def test_run() -> None:
    subprocess.run(
        [".\\tmp.ps1"],
        shell=True,
        check=True,
        # 直接指定64位PowerShell作为执行Shell
        executable="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
    )

4. 过滤无害的stderr输出（临时过渡）

如果某些噪音实在没法从根源消除，可以捕获stderr并过滤掉已知的无害错误，只保留真正需要关注的内容：

def test_run() -> None:
    result = subprocess.run(
        ["powershell.exe", "-ExecutionPolicy", "Bypass", "-File", ".\\tmp.ps1"],
        check=True,
        stderr=subprocess.PIPE,
        text=True
    )
    
    # 过滤掉已知的无害错误行
    filtered_errors = [
        line for line in result.stderr.splitlines()
        if "vswhere.exe : The term 'vswhere.exe' is not recognized" not in line
        and "Get-ChildItem : A positional parameter cannot be found" not in line
    ]
    
    # 如果还有剩下的错误，就抛出异常
    if filtered_errors:
        raise RuntimeError(f"Unexpected errors detected:\n{chr(10).join(filtered_errors)}")

总结 #

最根本的思路是让PowerShell的执行环境和Visual Studio Dev Shell的要求匹配（比如用64位），同时避免脚本调用中的路径解析问题。这样就能彻底消除pytest里的stderr噪音，以后遇到真实错误时也能一眼识别了。如果要测试多个VS版本，只要在每个测试用例里单独指定对应的PowerShell环境/VS路径就行，完全不冲突。