Para iniciar, debemos tener claro el termino de cobertura, la cual es un concepto relacionado con la medición de la relación entre factores, y se la define como el grado en el cual un elemento específico es sometido a una batería de pruebas, donde el "elemento" de la cobertura puede ser cualquier cosa que debamos cubrir durante las pruebas.[1]
Es decir, se debe determinar cómo se vincula lo que se esta probando con el pedido del cliente y expresado en el requerimiento original, convertido tal vez en especificación funcional.
Es por esto que, de la medición que se realice, resultará el grado de cobertura en la que las pruebas están dando respuesta a todo lo que se necesita cubrir.
Un primer análisis que resulta de esta medición es conocer en qué área hace falta agregar más cobertura, como por ejemplo:
- Para las pruebas basadas en requisitos, se debe planificar medir contra las especificaciones.
- Para las pruebas basadas en riesgos, debemos planificar medir contra aquellos eventos de amenazas que podamos detectar.
- Para las pruebas basadas en ínter-operabilidad, se debe planificar medir la cobertura de las configuraciones y las interfaces.
Si se logra alcanzar una cobertura de caja negra del 100%, y una cobertura de sentencias del 100%, por lo tanto podemos pasar a la siguiente fase: la cual es prueba de condiciones.
Otra forma de que pueda suceder es de que partes del código no hayan sido ejecutadas jamás (cobertura de sentencias inferior al 100%), por lo que para estos casos habrá que realizar más pruebas buscando que se ejecuten todas y cada una de las sentencias del programa. En este sentido, puede que hayamos conseguido una cobertura elevada de sentencias. pero tal ves nos estemos contemplando las ramas condicionales.
ramas condicionales: x=0; if(y<100){x++}
Si se considera durante las pruebas un valor de "y" inferior a 100, se habrán ejecutado todas las líneas; pero nunca la variante de que x no se incremente.
Se habla de una cobertura de ramas al 100% cuando se ha ejercido todas y cada una de las posibles vías de ejecución controladas por condiciones.
La cobertura de ramas es indiscutiblemente deseable; pero habitualmente es un objetivo excesivamente costoso de alcanzar en su plenitud, salvo que se haga con herramientas de automatización.
Por lo tanto, muchas personas recomiendan:
- Realizar pruebas de caja negra hasta alcanzar una cobertura funcional del 100% (idealmente).
- Inspeccionar código ejecutado y agregar condiciones para someter a prueba a aquellas partes del programa no ejecutadas.
- Inspeccionar condiciones con un cierto grado de complejidad "difíciles" del código para intentar forzar variedad.
La medición de la cobertura es algo muy común en las pruebas de unidad. El objetivo de los desarrolladores es agregar los casos de unidad necesarios para lograr un 100% de cobertura. sin embargo, no es algo muy habitual cuando se hacen pruebas funcionales. Algunos equipos de calidad mantienen un reporte de áreas donde cada probador marca que área probó, pero no hay seguridad de que probaron el 100% de las líneas de código que el desarrollador puso en esa área.[2]
Es por esto que el equipo de calidad requiere manejar un buid que les permita medir la cobertura, de la misma manera que lo hacen los desarrolladores en las pruebas unitarias.
BIBLIOGRAFÍA
[1] Terrera, G. (1 de 09 de 2014). Testing Baires. Obtenido
de https://testingbaires.com/sobre-cobertura-en-testing-parte-1/
[2] Guillén, C.
(17 de 11 de 2014). Testing Software . Obtenido de
http://www.testingsoft.com/espanol/2014/11/17/como-medir-la-cobertura-de-las-pruebas-funcionales-con-jacoco/
No hay comentarios:
Publicar un comentario