对"性能断言检查"系统的设计有何看法？

这个想法是，开发人员会对他/她的代码做出一些断言，并使用这些断言来测试代码性能的演变。这样的系统有什么经验？

我当前的块是"将这些以特定语言(将根据指定的日志或者运行时工具进行检查的语言)编写的断言转换为可以执行的CLR，汇编或者字节码的更好方法是什么？"

目前，我已经编写了一个解析器，用于解析规范并将其保存在数据结构中。

解决方案

我们是否将性能检查嵌入到我们的应用程序中？否。原因是性能检查本身需要时间，并且我们的应用程序对性能非常敏感。

相反，我们将性能检查作为一项测试。为此，我们使用NUnit。对于我们的夜间构建，我们运行测试，生成日志，其中包含详细的时序数据以及给定要求的通过/失败指示。由于我们将日志保留一段时间(永久用于beta和生产版本)，因此我们也可以随时间跟踪性能。

与Kevin相似，我在自动回归测试中添加了性能日志，以便有效地对性能和功能进行回归测试。我们使用TestComplete进行自动回归，并且它会自动完成很多工作。手动添加它的主要原因是在每个检查点比较此运行与上次运行的结果。这就像

StartTest
InitialiseCounter
'
'
Do some testing
'
'
CheckPoint
GetElapsedTime
Compare ElapsedTime with stored elapsed time from last run
If difference is outside tolerence log an error

(对我的伪代码高亮显示不好意思)

如今，许多语言都有" assert"语句。可以利用它们来验证我们生成的断言吗？它们易于编写和查找。问题是断言失败意味着程序停止了。

如果要在运行时提供警告或者断言失败的日志条目，则可以尝试执行if语句。

对于这种代码生成，人们经常使用简单的模板工具来生成可以插入到应用程序中的适当源代码。我们可以查看Java的Velocity或者Python的Mako为断言条件生成源。