性能测试与单元测试

我同意你的发现/学习。真正的单元测试只测试系统的一部分,忽略、嘲笑或在必要时伪造其余部分。集成测试(或回归测试)测试大多数或所有单元一起工作,这是性能的真正度量。

在某些情况下,您可以使用单元测试来确保操作在特定的时间段内完成。如果您想为您的操作添加更多的特性,但不想牺牲性能,您可以使用单元测试来断言这一点。当然,这些类型的单元测试依赖于机器,但是您可以将一些额外的变量或配置抛到等式中。

我同意性能测试不能是单元测试,但是我们没有理由不能有另一组称为性能测试的测试。 一般来说,测试分为两类

a)单元测试

b)集成测试

我们再次对真实数据库(而不是内存)运行集成测试,以确保SQL脚本、休眠存储库按预期工作。

我的想法是我们可以添加另一组称为性能测试的测试,这是夜间构建的一部分,用于测试某些函数的性能。这对于在代码重新分解后跟踪统计信息或评估应用程序某个部分的更改是否会对另一个部分产生意外的结果很重要。

我遇到过 JunitPerf 这可能有助于我实现这个目标。

性能测试很可能由单元测试组成。

例如,单元测试可能会向一个方法中抛出几个不同的参数,并验证该方法是否返回预期的输出。性能测试可能会执行该单元测试1000次(或任何对您有意义的值),同时记录从CPU和内存计数器到每个测试所用时间的所有内容。

单元测试应该不会花时间执行,因为您只测试一个非常特定的单元/系统。就像被测试的系统是ClassA:IClassa一样,您进行模拟/存根测试,只测试ClassA的行为,不应该测试ClassA以外的行为,例如ClassA使用ClassB。为了实现这一点,您应该注入一个ClassB的模拟,而不是具体的。

在性能测试方面,仍然使用像nunit/mbunit/maventhould这样的测试框架是有意义的,只需将这些测试保存在单独的程序集中,不要将它们作为单元测试的一部分调用。

因此,如果您使用rake来调用测试,那么您的一些任务可能如下所示:

Rake Test:All         #Run all unit tests
Rake Test:Acceptance  #Run all acceptance tests
Rake Test:Performance #Run all performance tests
Rake Test:Integration #Run all integration tests

然后,通过持续集成,test:all始终在成功构建之后调用,其中as test:performance每天在12点调用一次。

所有这些都取决于你所说的性能测试。当微优化特定代码时,我通常使用与单元测试非常相似的东西(我应该称之为它吗? 单元性能测试 ?)基本上我就是这么做的 question (尽管不关心真正使用单元测试框架)。但我也会在Boost单元测试框架中做这样的事情来优化我的C++生产代码。

实际上,在不同的层次和不同的目的上有很多种性能测试(重载应力测试、剖面分析、微观优化)。您所讨论的性能测试似乎处于功能测试级别。您可能无论如何都不会使用单元测试框架的级别。

我记得几年前,微软提倡程序员使用Visual Studio NET应用程序中心测试(ACT)来测试他们个人的ASP。有(可能仍然存在)一种对单个ASP执行事务成本分析(TCA)的完整方法。也就是说,可以使用Web驱动程序和可能的模拟对象来测试这些ASP,以隔离测试中的代码(如果没有开发,则模拟数据库访问)。

如果您有一个驱动程序和一个模拟对象框架(可选)来处理任何尚未编写的依赖关系,那么可以使用这种方法进行任何单元测试。这种方法在soapui\loadui中也很流行。此外,我建议隔离可以针对给定数据库设计测试(优化)的单个SQL语句。这种(DB)SQL单元性能测试可以在SDLC的早期完成,它将发现查询优化的机会。

在成本和价值方面:我发现,早期的单元性能测试,使用适当的模拟对象,将在SDLC早期识别内存泄漏和过度的CPU使用和磁盘IO,但我将“切取”测试中的代码,以获得更高风险的项目。

单元测试和性能测试之间存在差异。首先,单元测试是根据其功能需求测试应用程序。例如,您希望确保在单击“主页”选项卡时,网页导航到主页,而性能测试是一种非功能测试。在这里,您关心应用程序在特定用户负载下在一定时间内的稳定性和响应性。