为什么单元测试结果的持续时间不等于开始时间和结束时间之间的差值？
我已经为长时间运行的过程编写了一个测试。当它完成时，我在测试结果中显示以下内容：
Test Run: [blah]
Test Name: PopulateDataTest
Result: Passed
Duration: 00:03:17.0017261
Computer Name: [name here]
Start Time: 3/8/2011 12:54:18 PM
End Time: 3/8/2011 1:02:31 PM
对开始日期和结束日期进行一些数学计算，我得到大约 8 分钟，而不是 3 分钟。我错过了什么？
I've written a test for a long running process. when it completes, I get the following displayed in the test results:
Test Run: [blah]
Test Name: PopulateDataTest
Result: Passed
Duration: 00:03:17.0017261
Computer Name: [name here]
Start Time: 3/8/2011 12:54:18 PM
End Time: 3/8/2011 1:02:31 PM
Doing some math on the start and end dates, I get about 8 minutes, not 3. What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除了 @Matt Spinelli 所说的之外，我怀疑报告的持续时间值还反映了 CPU 实际执行测试所花费的时间，而不是测试的结束时间 - 开始时间。也就是说，我认为 CPU 时间是报告的指标，因为这是更重要的事情。如果您的计算机在测试期间碰巧开始更新 Adobe Acrobat（或其他内容），则这可能会不适当地反映在“结束时间 - 开始时间”值中。
另一方面，我对Visual Studio测试框架知之甚少。例如，我不知道测试机制如何处理多线程进程的执行时间。所以从我看来，这只是猜测。
In addition to what @Matt Spinelli said, I suspect that the reported duration value also reflects the amount of time that the CPU actually spent executing the test, rather than the End Time - Start Time of the test. That is, I think that CPU time is the metric being reported, since that is the more important thing. If your computer happens to start updating Adobe Acrobat (or whatever) during the test then that could inappropriately be reflected in the End Time - Start Time value.
On the other hand, I have little knowledge of Visual Studio testing framework. I do not know how the test mechanism would deal with the execution time of multi-threaded processes, for example. So coming from me, this is all just speculation.
每次运行测试套件时，MSTest 都会进行一些初始化（即为测试运行创建文件夹、复制文件/程序集、启动和更新单元测试窗格等）。
我同意这很令人恼火，因为我也见过这种行为。我认为您有相当多的测试、文件和/或程序集。如果您使用 Microsoft Moles，这似乎也会减慢启动速度。
MSTest has some initialization that goes on each time you run the test suite (i.e. creating folders for the test run, copying files/assemblies, starting and updating the unit testing pane, etc).
I agree that this is irritating as I've seen this behavior too. I presume you have a pretty good number of tests, files, and/or assemblies. If you are using Microsoft Moles, this too seems to slow down the initiation speed.