手动调用dotnet test运行SpecFlow Playwright参数化测试报MSB1009错

你遇到的参数解析错误来自两个核心问题：

• 误用转义规则：URL编码（比如把逗号转成%2C）是旧版vstest.console.exe的参数规则，dotnet test CLI不会对传入参数做URL解码，这类转义完全无效
• 命令行参数拆分：你直接把完整测试名作为位置参数传入，没有显式指定.csproj路径；当测试名包含空格、双引号、逗号时，Shell会把未正确包裹的字符串拆成多个独立参数，空格后的User"%2Cnull)片段就被MSBuild识别为传入的项目文件路径，触发文件不存在的报错。

方案一：修正过滤参数写法（适配现有二次执行逻辑） #

保留你现有“记录失败用例->二次重跑生成跟踪”的逻辑，只需要调整dotnet test的命令写法即可：

1. 显式传入.csproj文件路径作为第一个位置参数，不要让dotnet从后续参数里猜项目路径
2. 用--filter参数指定要运行的测试，不要直接把测试名拼在命令后面
3. 放弃URL转义，只需要根据你用的Shell（Bash/PowerShell）做好参数包裹，避免字符串拆分：

• Bash环境下用单引号包裹整个filter表达式，内部的双引号、逗号不需要额外转义：

dotnet test ./YourTestProject.csproj --filter 'FullyQualifiedName=CheckSortingAndDataInHoverMenu("C, User",null)'

• PowerShell环境下用双引号包裹filter表达式，内部的双引号用反斜杠转义即可：

dotnet test .\YourTestProject.csproj --filter "FullyQualifiedName=CheckSortingAndDataInHoverMenu(\"C, User\",null)"

如果不需要100%精确匹配，也可以用模糊匹配规则降低转义成本，比如用~操作符匹配测试名的固定前缀，忽略参数部分：

dotnet test ./YourTestProject.csproj --filter 'FullyQualifiedName~CheckSortingAndDataInHoverMenu'

方案二：首次运行直接生成失败用例跟踪（推荐，无转义问题） #

二次重跑失败用例的方案本身存在执行效率低、转义逻辑复杂的问题，完全可以在首次测试执行时就实现“仅失败用例生成跟踪”的需求，完全绕开命令行解析问题：

• 方式1：直接使用Playwright内置的失败保留策略，配置TraceRetentionMode.RetainOnFailure，框架会自动在测试执行失败时保留跟踪文件，成功用例的跟踪会自动丢弃，不需要手写任何额外逻辑
• 方式2：在SpecFlow的[AfterScenario]生命周期钩子中判断当前场景执行状态：如果场景执行失败，就停止跟踪并将跟踪文件写入磁盘；如果场景执行成功，停止跟踪时直接丢弃记录内容即可。

方案三：用TestCase ID代替测试名做过滤 #

如果后续还遇到特殊字符转义问题，可以调整首次记录失败用例的逻辑：不记录容易出转义问题的测试显示名称，而是记录每个测试用例对应的唯一TestCase ID（纯GUID格式，无任何特殊字符），二次重跑时直接通过ID过滤：

dotnet test ./YourTestProject.csproj --filter "Id=0fa123b4-5678-90cd-ef12-3456789abcde"

这种写法完全不存在特殊字符解析问题，稳定性最高。

内容的提问来源于stack exchange，提问作者Rain Code