【问题标题】:Performance Testing Versus Unit Testing性能测试与单元测试
【发布时间】:2010-05-20 00:24:32
【问题描述】:

我正在阅读 Osherove 的“单元测试的艺术”,虽然我还没有看到他谈论性能测试,但我仍然有两个想法:

  • 性能测试一般不能是单元测试,因为性能测试一般需要运行很长时间。
  • 性能测试通常不能是单元测试,因为性能问题经常出现在集成或系统级别(或者至少重新创建集成环境性能所需的单个单元测试的逻辑也会太涉及到一个单元测试)。

尤其是上述第一个原因,我怀疑由单元测试框架(例如 NUnit)处理性能测试是否有意义。

我的问题是:我的发现/倾向是否符合社区的想法?

【问题讨论】:

    标签: performance unit-testing


    【解决方案1】:

    我同意您的发现/学习。真正的单元测试只测试系统的一部分,必要时忽略、模拟或伪造其余部分。集成测试(或回归测试)测试大部分或所有单元一起工作,这是衡量性能的真正标准。

    【讨论】:

    • 我经常将系统范围的测试称为“功能测试”。我不知道这与“行业”有什么关系,但在我的公司里,白话一直存在。不过,要到位有点棘手,因为我们需要一些“外部”系统来驱动应用程序。该应用程序在专用硬件上运行,输入来自无法直接从主机 PC 驱动的自定义端口。不过,这绝对是值得的。
    【解决方案2】:

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

    【讨论】:

      【解决方案3】:

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

      a) 单元测试

      b) 集成测试

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

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

      我遇到了JunitPerf,这可能有助于我实现这一目标。

      【讨论】:

        【解决方案4】:

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

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

        【讨论】:

          【解决方案5】:

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

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

          因此,如果您使用 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 总是在成功构建后调用,而 Test:Performance 在每天上午 12 点调用一次。

          【讨论】:

          • 我喜欢你所说的,但我需要运行的性能测试实际上是集成测试——例如客户端和服务器之间的通信速度。纠正我,但我不认为单元测试框架准备好部署客户端和服务器代码,分别启动它们,并给出客户端在服务器上跳动时看到的结果。
          • 您可以构建服务器实现并将其部署到指定位置(虚拟机或远程服务器),然后针对该位置执行所有性能/集成测试。有用于部署安装的包。
          【解决方案6】:

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

          确实有多种不同级别和不同目的的性能测试(重载压力测试、分析、微优化)。您在问题中所说的性能测试似乎处于功能测试级别。您可能无论如何都不会使用单元测试框架的级别。

          【讨论】:

            【解决方案7】:

            我记得几年前微软提倡程序员使用 Visual Studio Net Application Center Test (ACT) 来测试他们的个人 asp 的性能。有(可能仍然存在)对单个 asp 执行交易成本分析 (TCA) 的完整方法。也就是说,这些 asp 可以使用 Web 驱动程序和可能的模拟对象进行测试,以隔离被测代码(如果未开发,则模拟 DB 访问)。

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

            在成本和价值方面:我发现早期的 UNIT 性能测试,适当地使用模拟对象,将在 SDLC 早期识别内存泄漏和过多的 CPU 使用率和磁盘 IO,但我会“挑选”被测代码用于风险较高的项目。

            【讨论】:

              【解决方案8】:

              单元测试和性能测试之间存在对比差异。首先,单元测试是针对应用程序的功能需求进行测试。例如,您要确保在单击主页选项卡时网页导航到主页,而性能测试是一种非功能测试。在这里,您关注的是应用程序在特定用户负载下一段时间内的稳定性和响应能力。

              【讨论】:

                猜你喜欢
                • 2012-12-13
                • 1970-01-01
                • 2011-07-07
                • 1970-01-01
                • 1970-01-01
                • 2016-05-05
                • 1970-01-01
                • 1970-01-01
                • 2010-09-21
                相关资源
                最近更新 更多