blocks|key|2013413|text|如果您想检查时间是否增加，那么不同机器的硬件应该不重要，如果您不检查绝对值，而是检查相对变化。还是我在这里漏掉了什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2013414|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you want to check if the time increases, the hardware of different machines should not matter, if you don't check for absolute values, but for relative change. Or am I missing something here?

blocks|key|774478|text|我认为您可以对单元测试运行时数据进行回归检查。使用大量的单元测试框架，您通常可以得到一份报告，上面写着testname、executiontime。我知道junit/万无一失是这样的。因此，基本上您可以将其与以前的运行进行比较，并确定是否发生了任何重大更改。如果将所有这些都保存在数据库(带有主机名)中，则可以将相同运行时环境的执行时间与以前的测试运行进行比较。这样，您就不会真正为性能编写测试，而只是单独断言执行时间没有发生重大变化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|774479|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think you could do regression checks over unit-test runtime figures. With a lot of the unit test frameworks you can typically get a report that says testname, executiontime. I know junit/surefire does it. So basically you can compare this to previous runs and establish if any significant changes have taken place. If you keep all of this in a database (with the hostname) you can compare execution times for the same run-time environment to previous test-runs. In this way you don't really write tests for performance
but you just assert separately that there have been no significant changes to execution-time.

blocks|key|2013440|text|我所知道的最接近于单元测试框架的是定时测试，它是在JUnit+4中添加的，可以用来确保算法的性能不会随着输入大小的增加而下降。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2013441|entityMap|0|LINK|mutability|MUTABLE|url|http://www-128.ibm.com/developerworks/java/library/j-junit4.html#N101C0^0|H|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

The closest thing that I know of that's built in to a unit testing framework is <a href="http://www-128.ibm.com/developerworks/java/library/j-junit4.html#N101C0" rel="nofollow noreferrer">timed tests</a> that were added in JUnit 4. This could be used to ensure that an algorithm's performance doesn't degrade as input size increases.

blocks|key|2013458|text|只是根据我的经验..。我们关心我们许多组件的性能，并且有一个非常统一的框架来执行和计时它们(事后看来，我们应该像在单元测试中一样使用CppUnit或boost::test+)。我们称这些为“组件基准测试”而不是单元测试。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2013459|我们不指定时间上限，然后通过/失败.我们只是记录时间(这在一定程度上与客户不愿意实际提供严格的性能要求有关，尽管性能是他们非常关心的事情！)(我们过去曾尝试过通过/失败，而且经验很糟糕，特别是在开发人员机器上.太多的错误警报，因为一封电子邮件到了，或者背景中有索引)|unordered-list-item|2013460|从事优化工作的开发人员只需降低相关的基准测试时间，而不必构建整个系统(就像单元测试一样，您可以专注于代码库的一部分)。|2013461|大多数基准测试一些东西的迭代的迭代。延迟创建资源可能意味着组件的第一次使用可以有更多的“设置时间”与其相关联。我们注销“1”、“平均后继”和“所有平均”次数。确保您理解这些差异的原因。在某些情况下，我们将设置时间显式地作为单个案例进行基准测试。|2013462|应该是显而易见的，但是:只需计时您真正关心的代码，而不是测试环境设置时间！|2013463|对于基准测试，与单元测试相比，最终测试“真实”情况的情况要多得多，因此测试设置和测试运行时往往要长一些。|2013464|我们有一台自动测试机器，每晚运行所有的基准测试，并发布所有结果的日志。理论上，我们可以绘制它，或者让它标记低于目标性能的组件。在实践中，我们没有时间设置这样的东西。|2013465|您确实希望这样一台自动测试机器完全不承担其他职责(例如，如果它也是您的SVN服务器，那么做一个大的检查就会使它看起来像一个巨大的性能倒退)。|2013466|考虑其他标量量，除了时间之外，您可能还想对其进行基准测试，并计划从一开始就支持它们。例如，“实现压缩比”，“天网人工智能智商”.|2013467|不要让人们在次最小规格硬件上对基准数据进行任何分析。我见过浪费时间的原因是，当在目标平台(高端服务器)上运行基准时，会显示出完全不同的东西，这是由于基准运行在某人的垃圾日志上而造成的。|2013468|entityMap^0|1U|7|22|B|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|15|8|@]|D|@]|E|$]]|$1|I|3|J|5|H|7|16|8|@]|D|@]|E|$]]|$1|K|3|L|5|H|7|17|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|18|8|@]|D|@]|E|$]]|$1|O|3|P|5|H|7|19|8|@]|D|@]|E|$]]|$1|Q|3|R|5|H|7|1A|8|@]|D|@]|E|$]]|$1|S|3|T|5|H|7|1B|8|@]|D|@]|E|$]]|$1|U|3|V|5|H|7|1C|8|@]|D|@]|E|$]]|$1|W|3|X|5|H|7|1D|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|Z|$]]

Just some notes from my experience... We care about the performance of many of our components and have a very unittest-like framework to exercise and time them (with hindsight, we should have just used <code>CppUnit</code> or <code>boost::test</code> like we do for unittests). We call these "component benchmarks" rather than unittests.

<ul>
<li>We don't specify an upper limit on time and then pass/fail... we just log the times (this is partly related to a customer reluctance to actually give hard performance requirements, despite performance being something they care about a lot!). (We have tried pass/fail in the past and had a bad experience, especially on developer machines... too many false alarms because an email arrived or something was indexing in the background)</li>
<li>Developers working on optimisation can just work on getting the relevant benchmark times down without having to build a whole system (much the same as unittests let you focus on one bit of the codebase).</li>
<li>Most benchmarks test several iterations of iterations of something. Lazy creation of resources can mean the first use of a component can have considerably more "setup time" associated with it. We log out "1st", "average subsequent" and "average all" times. Make sure you understand the cause of any significant differences between these. In some cases we benchmark setup times explicitly as an individual case. </li>
<li>Ought to be obvious, but: just time the code you actually care about, not the test environment setup time!</li>
<li>For benchmarks you end up testing "real" cases a lot more than you do in unittests, so test setup and test runtime tend to be a lot longer.</li>
<li>We have an autotest machine run all the benchmarks nightly and post a log of all the results. In theory we could graph it or have it flag components which have fallen below target performance. In practice we haven't got around to setting anything like that up.</li>
<li>You do want such an autotest machine to be completely free of other duties (e.g if it's also your SVN server, someone doing a big checkout will make it look like you've had a huge performance regression).</li>
<li>Think about other scalar quantities you might want to benchmark besides time and plan to support them from the start. For example, "compression ratio achieved", "Skynet AI IQ"...</li>
<li>Don't let people do any analysis of benchmark data on sub minimum spec hardware. I've seen time wasted 'cos of a design descision made as a result of a benchmark run on someone's junk lappy, when a run on the target platform - a high end server - would have indicated something completely different!</li>
</ul>

blocks|key|480484|text|如果你在C%2B%2B工作，可以看看http://unittest-cpp.sourceforge.net/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|480485|我没有使用时间，但它是我发现的最好(最简洁)的单元测试框架。|480486|entityMap|0|LINK|mutability|MUTABLE|url|http://unittest-cpp.sourceforge.net/^0|E|10|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

If you're working in C++ have a look at <a href="http://unittest-cpp.sourceforge.net/" rel="nofollow noreferrer">http://unittest-cpp.sourceforge.net/</a>

I've not used the time stuff but it is the best (most concise) unit test framework I've found.

Has anyone done temporal unit-testing? 

I'm not even sure if such lingo has been coined or not, but the point is to test that operations perform within temporal limits. I have a few algorithms and I want to test that their execution time increases as expected, and I guess similar testing could be used for IO, and what not, kind of like test_timeout or something. 

However because the hardware affects the speed of execution it doesn't seem trivial. So I was wondering if anyone has tried this sort of thing before, and if they would could share their experience.

Thanks

Edit: Trying to compile a list of stuff that needs to be taken care of in this kind of situation

Ideas and tips for temporal unit-testing?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有人做过时间单元测试吗？我甚至不确定这种术语是否被创造出来，但重点是测试操作在时间范围内的执行情况。我有几个算法，我想测试它们的执行时间是否如预期的那样增加，我想类似的测试可以用于IO或者其他类似于test_timeout之类的测试。但是，由于硬件会影响执行的速度，所以看起来并不简单。因此，我想知道是否有人曾经尝试过这...

问时间单元测试的想法和提示？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问时间单元测试的想法和提示？EN