Azure Devops 2019 无法在 Visual Studio 测试任务中启用诊断
Azure Devops 2019 Cannot Enable Diagnostics in Visual Studio Test Task
我们使用 Azure Devops 2019 进行了本地 TFVC 设置。我们使用“经典编辑器”创建我们的管道,因为 YAML 不支持 TFVC 存储库:https://developercommunity.visualstudio.com/t/enable-yaml-for-tfvc/234618
我们在测试期间偶尔会发生崩溃 运行,导致整个套件崩溃。我们仅使用 MSTest 和 Visual Studio 测试任务,如下所示。如您所见,我启用了“收集高级诊断”选项:
但是,正如您在输出中看到的那样,该选项仅在 'Run the tests locally' 的第一遍 'true' 上启用,其中未找到程序集?在第二遍中,当它找到程序集时,选项是 'false' 并且命令行没有更新。
如何为第二遍启用诊断?管道中只有一个 Visual Studio 测试任务,它似乎可以很好地获取 /InIsolation 参数,所以我很惊讶地看到诊断选项被禁用。为什么无论如何都会发生两次传球?
谢谢。
更新 1
打开 system.debug 后,我注意到发现了一些包含单词“test”但不是测试程序集的 dll,因此我将 **\*test*.dll
更改为 **\*Tests.dll
以清理它向上。在此之后,我终于在日志文件中看到了以下内容:
/diag:"H:\visbuild2\_work\_temp\f7742940-b794-11eb-9d69-699b53f653ca.txt"
Starting test execution, please wait...
Logging Vstest Diagnostics in file: H:\visbuild2\_work\_temp\f7742940-b794-11eb-9d69-699b53f653ca.txt
Logging TestHost Diagnostics in file: H:\visbuild2\_work\_temp\f7742940-b794-11eb-9d69-699b53f653ca.host.21-05-17_22-53-21_51202_1.txt
...
Results File: H:\visbuild2\_work8\s\TestResults\tfsservice_VIS-BUILD_2021-05-17_22_53_25.trx
Total tests: Unknown. Passed: 353. Failed: 0. Skipped: 0.
Test Run Aborted.
所以这是进步,但现在的问题是 H:\visbuild2\_work\_temp
位置在当前构建位置之上,并且似乎在所有构建之间共享,因此文件很快被另一个构建删除。我尝试通过 'Other console options' 更改位置,如下所示:
/Blame:CollectDump;CollectAlways=true;DumpType=full /Diag:"$(BuildLocation)\testlog.txt";tracelevel=verbose
但这产生了 /Diag 不能指定两次的错误。然后我尝试取消选中“收集高级诊断”选项,但奇怪的是,我得到了 /Diag 被指定两次的相同错误。有没有办法更改生成诊断文件的位置?当然,尽管测试 运行 已中止,但我仍然没有迹象表明故障转储已创建。
更新 2
似乎 /diag 仅在 system.debug 设置为 true 时启用:
https://github.com/microsoft/vstest-docs/blob/master/docs/diagnose.md
尝试将“收集进程转储并附加到测试运行报告”字段的值设置为“Always" 看看是否可行。
经过反复试验,我终于启用了诊断功能。
首先,启用 system.debug
将启用 /diag
标志。 /diag
标志没有像我假设的那样通过检查“收集高级诊断”来启用。我已将 system.debug
设置为 false
。
其次,我使用“其他控制台选项”将诊断文件重定向到自定义位置,如下所示:
/Blame:CollectDump;CollectAlways=true;DumpType=full /Diag:"$(BuildLocation)\testlog.txt";tracelevel=verbose
/Blame
选项很有用,因为它会生成一个 XML 显示测试执行顺序,最后一个测试是崩溃期间的当前 运行 测试。
第三,我选中了“收集高级诊断”选项。
第四,在构建服务器上安装 procdump.exe (https://docs.microsoft.com/en-us/sysinternals/downloads/procdump) 并添加一个 PROCDUMP_PATH 环境变量以指向可执行文件以生成转储文件以供分析。
“其他控制台选项”对我不起作用。我最终不得不将以下内容添加到我的 运行 设置文件中:
<DataCollectionRunSettings>
<DataCollectors>
<!-- Configuration for blame data collector. -->
<DataCollector friendlyName="blame" enabled="True">
<Configuration>
<ResultsDirectory>C:\Temp\TestResults</ResultsDirectory>
<CollectDumpOnTestSessionHang TestTimeout="30m" DumpType="full" />
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
如果您随后转到 Azure Devops 中的 运行 摘要,您应该有包含 Sequence.xml
的附件
我们使用 Azure Devops 2019 进行了本地 TFVC 设置。我们使用“经典编辑器”创建我们的管道,因为 YAML 不支持 TFVC 存储库:https://developercommunity.visualstudio.com/t/enable-yaml-for-tfvc/234618
我们在测试期间偶尔会发生崩溃 运行,导致整个套件崩溃。我们仅使用 MSTest 和 Visual Studio 测试任务,如下所示。如您所见,我启用了“收集高级诊断”选项:
但是,正如您在输出中看到的那样,该选项仅在 'Run the tests locally' 的第一遍 'true' 上启用,其中未找到程序集?在第二遍中,当它找到程序集时,选项是 'false' 并且命令行没有更新。
如何为第二遍启用诊断?管道中只有一个 Visual Studio 测试任务,它似乎可以很好地获取 /InIsolation 参数,所以我很惊讶地看到诊断选项被禁用。为什么无论如何都会发生两次传球?
谢谢。
更新 1
打开 system.debug 后,我注意到发现了一些包含单词“test”但不是测试程序集的 dll,因此我将 **\*test*.dll
更改为 **\*Tests.dll
以清理它向上。在此之后,我终于在日志文件中看到了以下内容:
/diag:"H:\visbuild2\_work\_temp\f7742940-b794-11eb-9d69-699b53f653ca.txt"
Starting test execution, please wait...
Logging Vstest Diagnostics in file: H:\visbuild2\_work\_temp\f7742940-b794-11eb-9d69-699b53f653ca.txt
Logging TestHost Diagnostics in file: H:\visbuild2\_work\_temp\f7742940-b794-11eb-9d69-699b53f653ca.host.21-05-17_22-53-21_51202_1.txt
...
Results File: H:\visbuild2\_work8\s\TestResults\tfsservice_VIS-BUILD_2021-05-17_22_53_25.trx
Total tests: Unknown. Passed: 353. Failed: 0. Skipped: 0.
Test Run Aborted.
所以这是进步,但现在的问题是 H:\visbuild2\_work\_temp
位置在当前构建位置之上,并且似乎在所有构建之间共享,因此文件很快被另一个构建删除。我尝试通过 'Other console options' 更改位置,如下所示:
/Blame:CollectDump;CollectAlways=true;DumpType=full /Diag:"$(BuildLocation)\testlog.txt";tracelevel=verbose
但这产生了 /Diag 不能指定两次的错误。然后我尝试取消选中“收集高级诊断”选项,但奇怪的是,我得到了 /Diag 被指定两次的相同错误。有没有办法更改生成诊断文件的位置?当然,尽管测试 运行 已中止,但我仍然没有迹象表明故障转储已创建。
更新 2
似乎 /diag 仅在 system.debug 设置为 true 时启用: https://github.com/microsoft/vstest-docs/blob/master/docs/diagnose.md
尝试将“收集进程转储并附加到测试运行报告”字段的值设置为“Always" 看看是否可行。
经过反复试验,我终于启用了诊断功能。
首先,启用 system.debug
将启用 /diag
标志。 /diag
标志没有像我假设的那样通过检查“收集高级诊断”来启用。我已将 system.debug
设置为 false
。
其次,我使用“其他控制台选项”将诊断文件重定向到自定义位置,如下所示:
/Blame:CollectDump;CollectAlways=true;DumpType=full /Diag:"$(BuildLocation)\testlog.txt";tracelevel=verbose
/Blame
选项很有用,因为它会生成一个 XML 显示测试执行顺序,最后一个测试是崩溃期间的当前 运行 测试。
第三,我选中了“收集高级诊断”选项。
第四,在构建服务器上安装 procdump.exe (https://docs.microsoft.com/en-us/sysinternals/downloads/procdump) 并添加一个 PROCDUMP_PATH 环境变量以指向可执行文件以生成转储文件以供分析。
“其他控制台选项”对我不起作用。我最终不得不将以下内容添加到我的 运行 设置文件中:
<DataCollectionRunSettings>
<DataCollectors>
<!-- Configuration for blame data collector. -->
<DataCollector friendlyName="blame" enabled="True">
<Configuration>
<ResultsDirectory>C:\Temp\TestResults</ResultsDirectory>
<CollectDumpOnTestSessionHang TestTimeout="30m" DumpType="full" />
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
如果您随后转到 Azure Devops 中的 运行 摘要,您应该有包含 Sequence.xml
的附件