¿Qué pueden ser medidas alternativas a la cobertura del código?

Question

La cobertura de código es probablemente la métrica de código más controvertida. Algunos dicen que debe alcanzar una cobertura de código del 80%, es decir, es superficial y no dice nada acerca de la calidad de su prueba. (Consulte Jon Limjap's good answer on "What is a reasonable code coverage % for unit tests (and why)?".)

Las personas tienden a medir todo. Necesitan comparaciones, puntos de referencia, etc.
Los equipos de proyectos necesitan un puntero, qué tan buenas son sus pruebas.

¿Cuáles son las alternativas a la cobertura del código? ¿Cuál sería una buena métrica que diga más que "Toqué esta línea de código"?
¿Hay alternativas reales?

Answer 1

Si usted está buscando algunas métricas útiles que le dicen acerca de la calidad (o falta de ella) de su código, usted debe buscar en las siguientes mediciones:

1. Ciclomática Complejidad
   • Este es una medida de cuán complejo es un método.
   • Generalmente 10 y menos es bueno, 11-25 es malo, más alto es terrible.
2. profundidad de anidamiento
   • Esta es una medida de cómo muchos ámbitos anidados están en un método.
   • Normalmente 4 y menos es bueno, 5-8 es malo, más alto es terrible.
3. relacional Cohesión
   • Esta es una medida de qué tan bien los tipos relacionados en un paquete o de montaje son.
   • La cohesión relacional es algo así como una medida relativa, pero útil, no obstante.
   • Los niveles aceptables dependen de la fórmula. Dada la siguiente:
     • R: número de relaciones en paquete/conjunto
     • N: número de tipos de paquete/conjunto
     • H: Cohesión de la relación entre los tipos de
   • Fórmula: H = (R + 1)/N
   • Dada la fórmula anterior, un rango aceptable es de 1,5 - 4,0
4. falta de cohesión de Métodos (LCO M)
   • Esta es una medida de qué tan cohesiva es una clase.
   • La cohesión de una clase es una medida de la cantidad de campos a los que hace referencia cada método.
   • Buena indicación de si su clase cumple con el Director de Responsabilidad Individual.
   • Fórmula: LCOM = 1 - (sum (MF)/M * F)
     • M: número de métodos en la clase
     • F: número de campos de instancia en la clase
     • MF: número de métodos en la clase de acceso a un campo particular ejemplo
     • suma (MF): la suma de MF sobre toda ejemplo campos
   • una clase que es totalmente coherente tendrá un LCOM de 0.
   • Una clase que no sea cohesiva tendrá un LCOM de 1.
   • Cuanto más cerca se acerque a 0, más cohesivo y mantenible será su clase.

Estas son sólo algunas de las métricas clave que NDepend, una utilidad métricas .NET y mapeo de dependencia, puede proporcionar para usted. Recientemente trabajé mucho con las métricas de código, y estas 4 métricas son las métricas clave clave que hemos encontrado que son más útiles. Sin embargo, NDepend ofrece varias otras métricas útiles, incluido Efferent & Acoplamiento aferente y Abstractidad & Inestabilidad, que combinados proporcionan una buena medida de cómo mantener su código (y si su no en qué NDepen llama la Zona de dolor o la Zona de Inutilidad.)

Incluso si no está trabajando con la plataforma .NET, le recomiendo echar un vistazo al NDepend metrics page. Hay una gran cantidad de información útil allí que puede utilizar para calcular estas métricas en cualquier plataforma en la que desarrolle.

Answer 2

métricas de errores también son importantes:

• número de errores que entra
• Número de errores resueltos

Para detectar por ejemplo si los errores no se resuelven tan rápido como nuevo entra.

Answer 3

Crap4j es una medida bastante buena que conozco ...

Es una implementación Java de la métrica del software Change Risk Analysis and Predictions que combina la complejidad ciclomática y la cobertura de códigos de pruebas automatizadas.

Answer 4

Cobertura de código es solo un indicador y ayuda a señalar las líneas que no se ejecutan en absoluto en las pruebas, lo cual es bastante interesante. Si alcanza una cobertura de código del 80%, comienza a tener sentido observar el 20% restante de las líneas para identificar si le falta algún caso de uso. Si ve "aha, esta línea se ejecuta si paso un vector vacío", entonces puede escribir una prueba que pase un vector vacío.

Como alternativa puedo pensar, si tiene un documento de especificaciones con Casos de uso y requisitos funcionales, debe asignarles las pruebas de unidad y ver cuántas UC están cubiertas por FR (por supuesto debe ser 100%) y cuántos FR están cubiertos por UT (de nuevo, debería ser 100%).

Si usted no tiene especificaciones, ¿A quién le importa? Cualquier cosa que suceda estará bien :)

Answer 5

¿Qué tal (líneas de código)/(número de casos de prueba)? No es extremadamente significativo (ya que depende de LOC), pero al menos es fácil de calcular.

Otro podría ser (número de casos de prueba)/(número de métodos).

Answer 6

SQLite es una biblioteca extremely well-tested, y puede extraer todo tipo de métricas de ella.

A partir de la versión 3.6.14 (todas las estadísticas en el informe están en contra de esa versión de SQLite), la biblioteca SQLite consta de aproximadamente 63.2 KSLOC de código C. (KSLOC significa miles de "Líneas de código fuente" o, en otras palabras, líneas de código que excluyen líneas en blanco y comentarios). En comparación, el proyecto tiene 715 veces más código de prueba y scripts de prueba: 45261.5 KSLOC.

Al final, lo que siempre me parece más significativo es que ninguna de esas posibles métricas parece ser tan importante como la simple declaración, "cumple con todos los requisitos". (Así que no pierda de vista ese objetivo en el proceso de lograrlo.)

Si quiere algo para juzgar el progreso de un equipo, entonces debe establecer requisitos individuales. Esto le da algo para señalar y decir "esto está hecho, este no". No es lineal (resolver cada requisito requerirá trabajo variable), y la única forma en que puede linealizarse es si el problema ya se ha resuelto en otro lugar (y por lo tanto puede cuantificar el trabajo por requisito).

Answer 7

Como regla general, la inyección de defectos proporciona proporcionalmente el rendimiento del código de ruta y ambos siguen una curva de distribución de Rayleigh.
En algún momento su tasa de detección de defectos alcanzará su punto máximo y luego comenzará a disminuir.
Este vértice representa el 40% de los defectos descubiertos.
Avanzando con el análisis de regresión simple puede estimar cuántos defectos quedan en su producto en cualquier momento después del pico.
Este es un componente del modelo de Lawrence Putnam.

Answer 8

¿Qué hay de ver la tendencia de la cobertura de código durante su proyecto?

Como es el caso con muchas otras métricas, un solo número no dice mucho.

Por ejemplo, es difícil decir si hay un problema si "tenemos un cumplimiento de las normas Checkstyle del 78.765432%". Si el cumplimiento de ayer fue del 100%, definitivamente estamos en problemas. Si ayer fue 50%, probablemente estemos haciendo un buen trabajo.

Siempre me pongo nervioso cuando la cobertura del código se ha reducido cada vez más con el tiempo. Hay casos en que esto está bien, por lo que no puede apagar su cabeza cuando mira gráficos y números.

BTW, sonar (http://sonar.codehaus.org/) es una gran herramienta para ver las tendencias.

Answer 9

El uso de la cobertura de código en sí mismo es casi inútil, solo le da una idea si está buscando un código innecesario.

Utilizándolo junto con pruebas unitarias y apuntando al 100% de cobertura, le dirá que todas las partes "probadas" (suponiendo que todo fue exitoso también) funcionan como se especifica en la prueba unitaria.

Escribir pruebas unitarias de un diseño técnico/funcional, con una cobertura del 100% y pruebas 100% exitosas, le dirá que el programa está funcionando como se describe en la documentación.

Ahora, lo único que necesita es una buena documentación, especialmente el diseño funcional, un programador no debe escribir eso a menos que sea un experto en ese campo específico.

Answer 10

Me gustan los ingresos, los números de ventas, los beneficios. Son muy buenos parámetros de una base de código.

Answer 11

Cobertura del escenario.

No creo que realmente quiera tener una cobertura de código del 100%. Las pruebas dicen que los getters y setters simples parecen una pérdida de tiempo.

El código siempre se ejecuta en algún contexto, por lo que puede enumerar tantos escenarios como sea posible (dependiendo de la complejidad del problema, a veces, incluso todos) y probarlos.

Ejemplo:

// parses a line from .ini configuration file 
// e.g. in the form of name=value1,value2 
List parseConfig(string setting) 
{ 
    (name, values) = split_string_to_name_and_values(setting, '=') 
    values_list = split_values(values, ',') 
    return values_list 
} 

Ahora, usted tiene muchos escenarios para poner a prueba. Algunos de ellos:

• Pasando valor correcto

• elemento de la lista

• Pasando nula

• Pasando cadena vacía

• paso de parámetros

mal formateado

Al pasar cadena con comas inicial o final, p. Ej. name = value1, or name =, value2

La ejecución de la primera prueba puede proporcionarle (según el código) una cobertura del 100% del código. Pero no ha considerado todas las posibilidades, por lo que la métrica en sí misma no le dice mucho.

Answer 12

Escribí una publicación en el blog sobre por qué High Test Coverage Ratio is a Good Thing Anyway.

Acepto que: cuando una parte del código se ejecuta mediante pruebas, esto no significa que la validez de los resultados producidos por esta parte del código se verifique mediante las pruebas.

Pero aún así, si está utilizando en gran medida los contratos para verificar la validez de los estados durante la ejecución de las pruebas, una cobertura de prueba alta significará mucha verificación de todos modos.

Answer 13

El valor de la cobertura del código es que le da una idea de lo que han realizado las pruebas. La frase "cobertura de código" se usa a menudo para indicar cobertura de extracto, por ejemplo, "cuánto de mi código (en líneas) se ha ejecutado", pero de hecho hay más de cien variedades de "cobertura". Estas otras versiones de cobertura intentan proporcionar una visión más sofisticada de lo que significa el ejercicio del código.

Por ejemplo, la cobertura de condición mide cuántos de los elementos separados de las expresiones condicionales se han ejercido. Esto es diferente a la cobertura de extracto.MC/DC "condición modificada/cobertura de decisión" determina si los elementos de todas las expresiones condicionales se han demostrado para controlar el resultado del condicional, y es requerido por la FAA para el software de la aeronave. La cobertura de ruta mide cuántas de las posibles rutas de ejecución a través de su código se han ejercido. Esta es una mejor medida que la cobertura de enunciados, en el sentido de que las rutas representan esencialmente casos diferentes en el código. Cuál de estas medidas es mejor usar depende de cuán preocupado esté con respecto a la efectividad de sus pruebas.

Wikipedia discute muchas variaciones de la cobertura de la prueba razonablemente bien. http://en.wikipedia.org/wiki/Code_coverage

Answer 14

Esto no se ha mencionado, pero la cantidad de cambios en un archivo de código o método dado (mirando el historial de control de versiones) es interesante, especialmente cuando se está creando un conjunto de pruebas para código poco probado . Enfoca tus pruebas en las partes del código que cambias mucho. Deja los que no quieres para después.

Tenga cuidado con la inversión de causa y efecto. Puede evitar cambiar el código no probado y puede tender a cambiar más el código probado.