性能断言检查系统的设计答案

【问题标题】：Design of an performance assertion checking system性能断言检查系统的设计
【发布时间】：2008-10-03 05:43:31
【问题描述】：

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

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

我当前的块是“有什么更好的方法可以将这些以指定语言编写的断言（将根据指定的日志或运行时工具进行检查）翻译成可以执行的 CLR 或程序集或字节码？ "

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

【问题讨论】：

标签： assertions

【解决方案1】：

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

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

【讨论】：

这也是我们在我参与的项目中的做法。设置测试的最大执行时间，并记录实际时间。

【解决方案2】：

与 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

（请原谅我的伪代码中的高亮显示）

【讨论】：

【解决方案3】：

现在许多语言都有assert 语句。可以利用它们来验证您生成的断言吗？它们易于编写且易于查找。问题是断言失败意味着您的程序停止。

如果您想在运行时提供断言失败的警告或日志条目，您可以尝试使用 if 语句。

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

【讨论】：