且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

Visual Studio Community 2015中的性能分析测试

更新时间:2023-02-27 11:19:01

这就是我今天早些时候能够在VS Community 2015中描述NUnit测试的方式.

将NUnit Test Runner作为可执行文件进行分析

  1. 确保您以管理员的身份运行VS2015.
  2. 点击工具栏中的 Analyze> Performance Profiler ... .
  3. 选择性能向导,然后单击开始.
  4. 第1页:以我为例,我想查看分配情况,因此我单击了 .NET内存分配.
  5. 第2页:保留选项可执行文件(.EXE文件)并继续.
  6. 页面3:在此页面上,您必须定义要运行的可执行文件.

    这将是NUnit的测试运行程序nunit3-console.exe,或与您的测试框架等效的测试程序.

    • 可执行文件的完整路径是什么? C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe
    • 命令行参数:bin\Debug\Test.dll --inprocess --test TestNamespace.TestClassName.Test_Method_Name
    • 工作目录:\\MAC\Home\Documents\GitHub\ApplicationName\Test

您将需要用对您的系统有意义的路径替换这些路径. --inprocess开关使测试从NUnit进程内联运行.如果没有该开关,则将生成一个子进程,即使探查器似乎可以正常工作,您也只能对nunit3-console.exe进行性能分析,而不是自己的代码.

  1. 第4页:点击完成.

    请记住,探查器将生成报告文件并将其保存到您的工作目录中.就我而言,由于我的工作目录是UNC共享,因此它需要我选择一个本地文件夹路径,以便在启动分析器之前将报告保存到该路径.

    终端窗口应短暂出现,其中包含NUnit运行器输出.该窗口会自动关闭,因此,如果看到闪烁的红色文本,则您将没有时间阅读错误.您可以将命令从第3页复制到命令提示符中,以便更轻松地阅读.

  2. 命令运行后(无论成功与否),您都应该获得一个报告,可以在其中跟踪测试导致的分配数量.

不幸的是,在小型测试中的分配可能会由于 NUnit.Framework 本身引起的分配而被遮盖.我四处单击以查看是否有一种方法可以将它们从结果中排除,但找不到解决方法,因此我只是忽略了它们.

如果要分析其他测试,可以打开 Performance Explorer ,然后右键单击nunit3-console.exe > Properties更改命令行参数,然后单击Actions > Start Profiling刷新报告./p>

结论

此解决方案成功地分析了单个NUnit测试的结果,但是该声明带有一些警告.

与创建一个单独的可执行文件进行概要分析相比,它仅稍嫌令人讨厌,并且如果您需要进行一些非常敏感的分析,那么NUnit分配出现在报告中的事实可能会使它成为初学者.

也许有更多VS 2015经验的人可以通过一些技巧将有关从报告中排除 NUnit.Framework dll的提示帮助我改善此答案?

Posts on the web suggest that you can profile tests in Visual Studio by right-clicking and selecting "Profile Test": http://adamprescott.net/2012/12/12/performance-profiling-for-unit-tests/ But I only see "Run Test" and "Debug Test" for my NUnit tests, and the same for xUnit.NET. What am I missing in order to profile tests? Is this just not supported in Community edition, or I am missing some configuration or component?

(It would seem odd if it's not supported in Community, given I can profile executables in Community, and thus could painfully work around this issue by creating an executable that runs the test, and profile that. Why support profiling executables but not profiling tests?)

Steps to reproduce for NUnit: created new C# library project in Visual Studio Community 2015, pasted content of http://nunit.org/index.php?p=quickStartSource&r=2.6.4 into new file, installed NuGet packages as follows:

<packages>
  <package id="NUnit" version="2.6.4" targetFramework="net452" />
  <package id="NUnit.Runners" version="2.6.4" targetFramework="net452" />
  <package id="NUnitTestAdapter" version="2.0.0" targetFramework="net452" />
</packages>

Even restarted Visual Studio. Tests show up in Test Explorer and can be run, but no "Profile Test" option available on right-click menu. Also tried equivalent steps for xUnit.net, but no joy.

This ishow I was able to profile an NUnit test in VS Community 2015 earlier today.

Profiling the NUnit Test Runner as an executable

  1. Be sure you're running VS2015 as Administrator.
  2. Click Analyze > Performance Profiler... from the Toolbar.
  3. Choose Performance Wizard and click Start.
  4. Page 1: In my case, I wanted to see allocations so I clicked .NET memory allocation.
  5. Page 2: Leave the option An executable (.EXE file) checked and continue.
  6. Page 3: On this page you have to define the executable to run.

    This will be the test runner nunit3-console.exe for NUnit, or whatever the equivalent is for your test framework.

    • What is the full path to the executable? C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe
    • Command-line arguments: bin\Debug\Test.dll --inprocess --test TestNamespace.TestClassName.Test_Method_Name
    • Working directory: \\MAC\Home\Documents\GitHub\ApplicationName\Test

You will need to substitute these paths with ones that make sense for your system. The --inprocess switch causes the tests to be run inline from the NUnit process. Without that switch, a child process is spawned and even though the profiler will appear to work, you'll just be profiling nunit3-console.exe, not your own code.

  1. Page 4: Click Finish.

    Keep in mind that the profiler will generate report files and save them to your working directory. In my case, since my working directory was a UNC share, it required me to pick a local folder path to save the reports to before the profiler would start.

    A terminal window should appear briefly with the NUnit runner output in it. The window auto-closes, so if you see a flash of red text, you won't have time to read the error before it is gone. You can copy the command from Page 3 into a command prompt for more leisurely reading.

  2. After the command runs (whether it succeeded or not), you should get a report where you can track how many allocations your test caused.

Unfortunately, allocations in a small test will probably get overshadowed by the allocations caused by the NUnit.Framework itself. I clicked around to see if there was a way to exclude them from the results, but didn't find a way to do it, so I just ignored them.

If you want to profile a different test, you can open the Performance Explorer and right-click nunit3-console.exe > Properties to change the command line arguments and then click Actions > Start Profiling to refresh the report.

Conclusion

This solution succeeds at profiling the results of a single NUnit test, but that statement comes with some caveats.

It was only marginally less obnoxious than creating a separate executable to profile, and that fact that the NUnit allocations appear in the report could make it a non-starter if you need to do some really sensitive profiling.

Maybe someone with more VS 2015 experience can help me improve this answer with some tips on how to exclude the NUnit.Framework dll from the report?