【问题标题】:How to determine which code in a project/solution is the most often used?如何确定项目/解决方案中最常用的代码?
【发布时间】:2009-10-16 15:19:53
【问题描述】:

如果我有一个包含多个 c# 项目的现有解决方案,是否有任何静态分析工具可以帮助我确定哪些代码区域最常用?

我想使用此信息来确定应首先提高哪些区域的测试覆盖率。

我已经看过一些静态分析工具,但它们似乎主要关注复杂性、编码约定、代码重复等问题。

或者,如果没有任何可用的分析工具可以做到这一点,您对如何确定我应该首先关注哪些代码进行测试有什么建议吗?

谢谢!

编辑: 澄清一下,我正在寻找的不是代码覆盖率。我想了解一下我的应用程序的哪些部分最常用,这样我就可以专注于提高这些领域的覆盖率。我试图避免只为还没有任何测试的区域编写测试,因为它们可能是不经常执行的边缘情况。

【问题讨论】:

  • 在回复您的编辑时,您确定建议的代码覆盖工具不会同时进行分析吗?当通过检测获得时,提供分析信息与提供覆盖信息一样容易,因此这些工具可以两者兼得。只是说,我不熟悉他们......
  • 在我看来,某个方法被引用的次数与该方法中错误的严重程度无关。如果一个方法被引用并且只调用一次,例如在启动期间,该方法的错误执行可能会使您的应用程序崩溃,而调用 1000 次的错误方法仍可能使您的系统处于稳定状态。
  • @Pascal:(嗨!)我们分别提供测试覆盖率和分析工具,尽管仪器与您观察到的非常相似,至少在执行计数方面。显示要求有很大不同(请参阅我的答案并查看显示示例),并且配置文件的开销更高。

标签: c# visual-studio testing integration-testing


【解决方案1】:

即使是试图弄清楚运行时发生了什么的静态分析工具通常也不会尝试估计一段代码的执行频率。这个主题已经够难了!

但是 动态分析 工具(例如,依赖于代码的透明检测或使用采样的 分析 工具)可以在一次或多次“典型”执行后告诉您(你提供你认为典型的条目),这个或那个函数的执行频率。

见Profiling (computer programming) on Wikipedia。

【讨论】:

    【解决方案2】:

    如果我对问题的理解正确,那么您正在寻找分析器。试试EQATEC Profiler。它是免费的。

    它最初的目的是在交付之前对应用程序进行分析(通过测量方法的执行时间等来检测瓶颈),所以我不确定它是否适合生产环境中的应用程序。至少它会更改您的代码以进行分析,这可能是不需要的。你应该看看这个。

    【讨论】:

    • 这也是我的第一个想法。分析器会告诉你一个函数被调用的次数(相对)以及每个函数花费的时间。
    【解决方案3】:

    Code coverage 似乎是你想要的。

    NCover 是一个流行的 .NET 代码覆盖工具,如果你负担得起的话。

    【讨论】:

      【解决方案4】:

      您所要求的根本不可能准确地做到。执行某事的次数可以而且通常取决于在运行时输入的数据。您可以从静态分析工具中获得的最大希望是

      1. 静态确定时的直接答案
      2. 否则为 O(N) 风格分析
      即使是后者也很难在整体上做到正确。例如,它需要了解(庞大且不断扩展的).NET 库中基本上每个函数的复杂性。其中一些甚至难以描述。

      例如,分配一块内存需要多长时间?好吧,通常它通常是几乎恒定的时间——但分配总是有可能触发垃圾收集周期,在这种情况下,所花费的时间将(大致)与自上次分配以来仍在使用的对象数量成正比GC 周期...

      【讨论】:

        【解决方案5】:

        “Profiler”就是您要找的;您选择哪个取决于您。

        我使用 HP 的诊断服务器来执行此操作,尽管它需要花钱。它会告诉我哪些方法被调用了多少次,以及在这些方法中花费的平均时间和最坏情况时间。

        作为一个重要的安全提示,运行分析器会减慢代码的执行速度;它不适合长期安装到生产环境中。

        【讨论】:

          【解决方案6】:

          如果您只想查看 使用了什么: SD C# Test Coverage Tool

          如果您想查看使用频率: SD C# Profiler Tool

          【讨论】:

            【解决方案7】:

            如果覆盖范围不是您所寻找的,那么您可以考虑使用两件事:

            1. 建议使用分析器并运行预测测试场景。
            2. 使用性能计数器会以更持久的解决方案结束。这些很难实现,但有助于通过分析计数器报告来诊断性能差异。实现它们的一种方法是包装边界并管理这些包装中的计数器。请注意,与现有项目相比,在新项目中集成要容易得多。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2014-03-09
              • 1970-01-01
              • 2016-12-15
              • 2010-11-18
              • 1970-01-01
              • 1970-01-01
              • 2018-02-10
              • 1970-01-01
              相关资源
              最近更新 更多