X
BLOG

Las dos grandes trampas de la cobertura del código

Las dos grandes trampas de la cobertura del código Tiempo de leer: 5 minutos
No desea cobertura por el mero hecho de la cobertura. Necesita una cobertura significativa que indique que ha hecho un buen trabajo probando el software.

La medición de la cobertura del código es una de esas cosas que siempre me llama la atención. Por un lado, a menudo encuentro que las organizaciones no necesariamente saben cuánto código están cubriendo durante las pruebas, ¡lo cual es realmente sorprendente! En el otro extremo del espectro de cobertura, hay organizaciones para las que el número es tan importante que la calidad y eficacia de las pruebas se ha vuelto casi irrelevante. Persiguen sin pensar al dragón 100% y creen que si tienen ese número, el software es bueno, o incluso el mejor que puede ser. Esto es al menos tan peligroso como no saber lo que ha probado, de hecho, quizás más, ya que puede darle una falsa sensación de seguridad.

La cobertura del código puede ser un número bueno e interesante para evaluar la calidad de su software, pero es importante recordar que es un medio, más que un fin. No queremos cobertura por el mero hecho de la cobertura, queremos cobertura porque es Supuesto para indicar que hemos hecho un buen trabajo probando el software. Si las pruebas en sí mismas no son significativas, entonces tener más de ellas ciertamente no indica un mejor software. El objetivo importante es asegurarse de que se pruebe cada fragmento de código, no solo se ejecute. Si no tiene suficiente tiempo y dinero para probar todo completamente, al menos asegúrese de que todo lo importante esté probado.

Lo que esto significa es que, si bien una cobertura baja significa que probablemente no estemos probando lo suficiente, la cobertura alta por sí sola no se correlaciona necesariamente con una alta calidad; la imagen es más complicada que eso.

Obviamente, tener un medio feliz en el que tenga la cobertura "suficiente" para sentirse cómodo al lanzar el software con un conjunto de pruebas bueno, estable y mantenible que tenga "suficientes pruebas" sería perfecto. Pero aún así, estas trampas de cobertura son comunes.

Trampa n. ° 1: "No conocemos nuestra cobertura"

No conocer su cobertura me parece irrazonable: las herramientas de cobertura son baratas y abundantes. Un amigo mío sugiere que las organizaciones saben que su número de cobertura no es bueno, por lo que los desarrolladores y evaluadores son reacios a exponer la cobertura deficiente a la administración. Espero que este no sea el caso habitual.

Un problema real que encuentran los equipos cuando intentan medir la cobertura es que el sistema es demasiado complicado. Cuando construye una aplicación a partir de piezas sobre piezas sobre piezas, saber dónde colocar los mostradores de cobertura puede ser una tarea abrumadora. Sugeriría que si realmente es difícil medir la cobertura en su aplicación, debería pensar dos veces en la arquitectura.

Una segunda forma de caer en esta trampa ocurre con organizaciones que pueden tener muchas pruebas, pero no un número de cobertura real porque no han encontrado una forma adecuada de agregar los números de diferentes ejecuciones de prueba. Si está realizando pruebas manuales, pruebas funcionales, pruebas unitarias y pruebas de extremo a extremo, no puede simplemente sumar los números. Incluso si cada uno de ellos está logrando una cobertura del 25%, es poco probable que sea del 100% cuando se combinan. De hecho, es más probable que esté más cerca del 25% que del 100% cuando lo analizas.

Resulta que, de hecho, existe una manera de medir y sumar la cobertura de manera significativa. En Parasoft, aprovechamos la gran cantidad de datos granulares capturados por nuestros informes y herramienta de análisis, Parasoft DTP, que podemos utilizar en este contexto para proporcionar una vista global y agregada de la cobertura del código. Nuestros monitores de aplicaciones pueden recopilar datos de cobertura de la aplicación directamente mientras se prueba y luego enviar esa información a Parasoft DTP, que agrega datos de cobertura en todas las prácticas de prueba, así como en equipos de prueba y ejecuciones de prueba.

Si eso suena como una cantidad de información bastante significativa, ¡tienes razón! DTP proporciona un panel interactivo para ayudarlo a navegar por estos datos y tomar decisiones sobre dónde enfocar los esfuerzos de prueba. Vea el panel de ejemplo a continuación:

Si varias pruebas han cubierto el mismo código, no se contará en exceso, mientras que las partes no probadas del código son rápidas y fáciles de ver. Esto le muestra qué partes de la aplicación se han probado bien y cuáles no. Puedes leerlo todo en un documento técnico gratuito.

Entonces, no más excusas para no medir la cobertura.

Trampa n. ° 2: "¡La cobertura lo es todo!"

Es común pensar erróneamente que la cobertura lo es todo. Una vez que los equipos pueden medir la cobertura, no es raro que los gerentes digan "aumentemos ese número". Eventualmente, el número en sí se vuelve más importante que la prueba. Quizás la mejor analogía es la que escuché del fundador de Parasoft, Adam Kolawa:

“Es como pedirle a un pianista que cubra el 100% de las teclas del piano en lugar de presionar solo las teclas que tienen sentido en el contexto de una pieza musical determinada. Cuando toca la pieza, obtiene la cantidad de cobertura clave que tenga sentido ".

Ahí radica el problema: la cobertura sin sentido es lo mismo que la música sin sentido. La cobertura debe reflejar el uso real y significativo del código; de lo contrario, es solo ruido.

Y hablando de ruido… el costo de la cobertura aumenta a medida que aumenta la cobertura. Recuerde que no solo necesita crear pruebas, sino que debe mantenerlas en el futuro. Si no planea reutilizar y mantener una prueba, probablemente no debería perder el tiempo en crearla en primer lugar. A medida que la suite de pruebas se hace más grande, la cantidad de ruido aumenta de manera inesperada. El doble de pruebas puede significar dos o incluso tres veces más ruido. Las pruebas sin sentido terminan creando más ruido que las buenas pruebas porque no tienen un contexto real, pero deben tratarse cada vez que se ejecutan las pruebas. ¡Habla de deuda técnica! Las pruebas inútiles son un peligro real.

Ahora, en ciertas industrias, industrias críticas para la seguridad, por ejemplo, la métrica de cobertura del 100% es un requisito. Pero incluso en ese caso, es muy fácil tratar cualquier ejecución de una línea de código como una prueba significativa, lo cual simplemente no es cierto. Tengo dos preguntas básicas que hago para determinar si una prueba es una buena prueba:

  1. ¿Qué significa cuando falla la prueba?
  2. ¿Qué significa cuando pasa la prueba?

Idealmente, cuando una prueba falla, sabemos algo sobre lo que salió mal, y si la prueba es realmente buena, nos indicará la dirección correcta para solucionarlo. Con demasiada frecuencia, cuando una prueba falla, nadie sabe por qué, nadie puede reproducirla y la prueba se ignora. Por el contrario, cuando se aprueba una prueba, deberíamos poder saber qué se probó; debería significar que una característica en particular o una parte de la funcionalidad está funcionando correctamente.

Si no puede responder una de esas preguntas, probablemente tenga un problema con su prueba. Si no puede responder a ninguno de ellos, probablemente la prueba sea más problemática de lo que vale la pena.

La forma de salir de esta trampa es, en primer lugar, comprender que el porcentaje de cobertura en sí no es el objetivo. El objetivo real es crear pruebas útiles y significativas. Por supuesto, esto lleva tiempo. En la escritura de código simple, las pruebas unitarias son simples, pero en aplicaciones complejas del mundo real significa escribir stubs y simulacros y usar frameworks. Esto puede llevar bastante tiempo y, si no lo hace todo el tiempo, es fácil olvidar los matices de las API involucradas. Incluso si se toma en serio las pruebas, el tiempo que lleva crear una prueba realmente buena puede ser más de lo esperado.

De hecho, tenemos una nueva tecnología para esto en Parasoft, que se encuentra dentro Parasoft Jtest, nuestra herramienta de prueba de desarrollo de Java. Unit Test Assistant se encarga de las tediosas tareas de conseguir simulacros y resguardos correctos. También puede ayudar a expandir las pruebas existentes de una manera útil para aumentar la cobertura, ayudándole a crear buenas pruebas unitarias, así como a hacer recomendaciones para mejorar la cobertura y la calidad de las pruebas.

Es de esperar que haya aprendido que la cobertura es importante y que mejorar la cobertura es un objetivo valioso. Pero tenga en cuenta que simplemente perseguir el porcentaje no es tan valioso como escribir pruebas significativas, estables y fáciles de mantener.

Nuevo llamado a la acción

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft