什么是代码覆盖率的替代指标？ [英] What can be alternative metrics to code coverage?

问题描述

代码覆盖率可能是最具争议的代码指标。有人说，您必须达到80％的代码覆盖率，而有人说，这是肤浅的，并且没有说明您的测试质量。 （请参阅 Jon Limjap对什么是单元测试的合理代码覆盖率百分比（以及为什么）？ 。）

Code coverage is propably the most controversial code metric. Some say, you have to reach 80% code coverage, other say, it's superficial and does not say anything about your testing quality. (See Jon Limjap's good answer on "What is a reasonable code coverage % for unit tests (and why)?".)

人们倾向于衡量一切。他们需要比较，基准测试等。

项目团队需要一个指针，他们的测试水平如何。

People tend to measure everything. They need comparisons, benchmarks etc.
Project teams need a pointer, how good their testing is.

那么代码覆盖率的替代方法是什么？哪个指标比我接触过这行代码还要好？

是否有其他替代方案？

So what are alternatives to code coverage? What would be a good metric that says more than "I touched this line of code"?
Are there real alternatives?

推荐答案

如果您正在寻找一些有用的指标来告诉您有关代码质量（或缺少指标）的信息，则应研究以下指标：

If you are looking for some useful metrics that tell you about the quality (or lack there of) of your code, you should look into the following metrics:

1. 循环复杂度
   
   
   
   
   • 这是一种方法的复杂程度的度量。
   
   
   • 通常10岁以下的人是好人，11-25岁的人是穷人，更高的人则很糟糕。
   
   

• 这是一个方法中嵌套范围的度量。


• 通常小于等于4是好，5-8是差，更高是可怕的。

• 这是衡量包或程序集中的类型之间相关性的度量。


• 关系内聚在某种程度上是相对度量，但仍然很有用。 / li>
  
• 可接受的水平取决于公式。给定以下内容：
  
  
  
  
  • R：包/组合中的关系数
  
  
  • N：包/中的类型数程序集
  
  
  • H：类型之间关系的内聚力
  
  
  • This is a measure of how well related the types in a package or assembly are.
  • Relational cohesion is somewhat of a relative metric, but useful none the less.
  • Acceptable levels depends on the formula. Given the following:
    • R: number of relationships in package/assembly
    • N: number of types in package/assembly
    • H: Cohesion of relationship between types
    
    
    • 这是一个类的凝聚力的量度。
    
    
    • 一个类的凝聚力是对每种方法引用多少个字段的度量。
    
    
    • 很好地表明您的类是否符合单一职责原则。
    
    
    • 公式：LCOM = 1-（sum（MF）/ M * F）
      
      
      
      
      • M：类中方法的数量
      
      
      • F：类中实例字段的数量
      
      
      • MF：类中访问特定实例字段的方法的数量
      
      
      • sum（MF）：MF的总和所有实例字段
      
      
      • This is a measure of how cohesive a class is.
      • Cohesion of a class is a measure of how many fields each method references.
      • Good indication of whether your class meets the Principal of Single Responsibility.
      • Formula: LCOM = 1 - (sum(MF)/M*F)
        • M: number of methods in class
        • F: number of instance fields in class
        • MF: number of methods in class accessing a particular instance field
        • sum(MF): the sum of MF over all instance fields

        这些方法，使您的课程更具凝聚力和可维护性。 .NET指标和依赖项映射实用程序NDepend可以为您提供的一些关键指标。我最近在代码指标方面做了很多工作，这4个指标是我们发现最有用的核心关键指标。 NDepend提供了其他几个有用的指标，包括Efferent和传入耦合与抽象性不稳定，综合起来可以很好地衡量代码的可维护性（以及您是否处于NDepend所称的痛苦区或无用区内。）

        These are just some of the key metrics that NDepend, a .NET metrics and dependency mapping utility, can provide for you. I recently did a lot of work with code metrics, and these 4 metrics are the core key metrics that we have found to be most useful. NDepend offers several other useful metrics, however, including Efferent & Afferent coupling and Abstractness & Instability, which combined provide a good measure of how maintainable your code will be (and whether or not your in what NDepend calls the Zone of Pain or the Zone of Uselessness.)

        即使您不使用.NET平台，我也建议您查看 NDepend指标页面。在任何开发平台上，您都可以使用很多有用的信息来计算这些指标。

        Even if you are not working with the .NET platform, I recommend taking a look at the NDepend metrics page. There is a lot of useful information there that you might be able to use to calculate these metrics on whatever platform you develop on.

        这篇关于什么是代码覆盖率的替代指标？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！