El porcentaje de cobertura del código no es bueno

Question

He instalado en mi computadora C ++ Test solo con la licencia de UnitTest (solo licencia de Unit Test) como un complemento de Visual Studio 2005 (cpptest_7.2.11.35_win32_vs2005_plugin.exe).

Tengo una muestra similar a la siguiente:

bool MyFunction(... parameters... )
{
    bool bRet = true;

        // do something
    if( some_condition )
    {
        // do something
        bRet = CallToAFunctionThatCanReturnBothTrueAndFalse....
    }
    else
    {
        bRet = false;
        // do something
    }

    if(bRet == false)
    {
        // do something
    }

    return bRet;
}

En mi caso, después de ejecutar la herramienta de cobertura, tengo los siguientes resultados (para una función similar a la mencionada anteriormente):

[LC=100 BC=100 PC=75 DC=100 SCC=100 MCDC=50 (%)]

Realmente no entiendo por qué no tengo una cobertura del 100% cuando se trata de PathCoverage (PC). Además, si alguien con experiencia en C ++ Test Parasoft pudiera explicarme la baja cobertura de MCDC para mí, sería genial.

¿Qué debo hacer para aumentar la cobertura? ya que no tengo ideas en este caso. Las instrucciones para (algunas partes de) la documentación son bienvenidas.

Gracias,

Iulian

Answer 1

Esta es una buena referencia sobre los diversos tipos de cobertura de código: http: //www.bullseye. com / coverage.html .

MCDC : para mejorar la cobertura de MCDC, deberá consultar some_condition . Suponiendo que es una expresión booleana compleja, deberá ver si está ejerciendo las combinaciones de valores necesarias. Específicamente, cada subexpresión booleana debe ejercerse verdadero y falso.

Ruta : una de las cosas mencionadas en el enlace anterior como una desventaja de la cobertura de ruta es que muchas rutas son imposibles de ejercer. Ese puede ser el caso con su ejemplo.

Answer 2

No puedo ayudar con la herramienta específica que está utilizando, pero la idea general con la cobertura de ruta es que cada ruta posible a través del código debe ejecutarse.

Si dibuja un diagrama de flujo a través del programa, bifurcando en cada if / break / continue, etc., debería ver qué caminos están tomando sus pruebas a través del programa. Para obtener el 100% (que no es totalmente necesario, ni asegura una prueba perfecta), su prueba tendrá que pasar por cada rama del código, ejecutando cada línea.

Espero que eso ayude.

Answer 3

Necesita al menos dos casos de prueba para obtener una cobertura del 100%. Uno donde alguna_condición es verdadera y otra donde no lo es. Si tiene eso, debe obtener una cobertura del 100%.

Aunque debería ver una cobertura del 100% como perfecta. Necesitaría 3 pruebas para eso en este caso, de modo que se puedan probar todas las combinaciones. Busque la complejidad ciclomática para obtener más información al respecto.

Answer 4

Hay cuatro caminos hipotéticos a través de esa función. Cada cláusula if duplica el número de rutas. Cada instrucción if es una rama donde puede ir de dos maneras diferentes. Entonces, cada vez que su herramienta encuentre un "si", se supone que el código puede tomar el "verdadero" rama o el "falso" rama. Sin embargo, esto no siempre es posible. Considere:

bool x = true;
if (x) {
    do_something();
} 

El " falso " La rama de la instrucción if no es accesible. Este es un ejemplo obvio, pero cuando tiene en cuenta varias declaraciones if, se hace cada vez más difícil ver si una ruta es posible o no.

Solo hay tres rutas posibles en su código. El camino que toma el '' falso '' bifurcarse en la primera declaración if y el " verdadero " rama en el segundo es inalcanzable.

Su herramienta no es lo suficientemente inteligente como para darse cuenta de eso.

Dicho esto, incluso si la herramienta es perfecta, obtener una cobertura de ruta del 100% probablemente no sea probable en una aplicación real. Sin embargo, una cobertura de ruta muy baja es una señal segura de que su método tiene una complejidad ciclomática demasiado alta.

Answer 5

Personalmente, creo que es una mala forma de iniciar CUALQUIER función con

bool retCode = true;

Está asumiendo explícitamente que tendrá éxito de forma predeterminada y luego fallará bajo ciertas condiciones.

Los programadores que vienen después de ti no harán esta misma suposición.

Falla rápido, falla temprano.

Y como otros han dicho, si desea probar casos de falla, debe codificar las pruebas que fallan.