Le pourcentage de couverture de code n'est pas bon

Question

J'ai installé sur mon ordinateur le test C ++ uniquement avec la licence UnitTest (uniquement la licence Unit Test) en tant que plug-in Visual Studio 2005 (cpptest_7.2.11.35_win32_vs2005_plugin.exe).

J'ai un échantillon similaire au suivant:

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;
}

Dans mon cas, après avoir exécuté l'outil de couverture, j'ai les résultats suivants (pour une fonction similaire à celle mentionnée précédemment):

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

Je ne comprends vraiment pas pourquoi je n'ai pas une couverture de 100% en ce qui concerne PathCoverage (PC). Aussi, si quelqu'un qui a l'expérience du test C ++, Parasoft pourrait m'expliquer la faible couverture MCDC, ce serait formidable.

Que dois-je faire pour augmenter la couverture? comme je suis à court d'idées dans ce cas. Les instructions concernant certaines parties de la documentation sont les bienvenues.

Merci,

Iulian

Answer 1

C’est une bonne référence pour les différents types de couverture de code: http: //www.bullseye. com / coverage.html .

MCDC : pour améliorer la couverture MCDC, vous devez examiner some_condition . En supposant qu'il s'agisse d'une expression booléenne complexe, vous devrez déterminer si vous exercez les combinaisons de valeurs nécessaires. Plus précisément, chaque sous-expression booléenne doit être exercée vraie et fausse.

Chemin d'accès : l'un des éléments cités dans le lien ci-dessus en tant qu'inconvénient de la couverture de chemin d'accès est que de nombreux chemins sont impossibles à exercer. Cela peut être le cas avec votre exemple.

Answer 2

Je ne peux pas vous aider avec l'outil spécifique que vous utilisez, mais l'idée générale en matière de couverture de chemin est que chaque chemin possible dans le code doit être exécuté.

Si vous tracez un organigramme dans le programme, en créant une branche à chaque if / break / continue, etc., vous devriez voir les chemins empruntés par vos tests dans le programme. Pour obtenir 100% (ce qui n'est pas totalement nécessaire, cela ne garantit pas non plus un test parfait), votre test devra analyser chaque branche du code, en exécutant chaque ligne.

L’espoir que cela aide.

Answer 3

Vous avez besoin d'au moins deux tests pour obtenir une couverture à 100%. Une où une condition est vraie et une autre. Si vous en avez, vous devriez obtenir une couverture de 100%.

Bien que la couverture à 100% soit parfaite. Dans ce cas, vous aurez besoin de 3 tests pour que toutes les combinaisons puissent être testées. Recherchez la complexité cyclomatique pour en savoir plus à ce sujet.

Answer 4

Il existe quatre chemins hypothétiques à travers cette fonction. Chaque clause if double le nombre de chemins. Chaque instruction if est une branche où vous pouvez aller de deux manières différentes. Ainsi, chaque fois que votre outil rencontre un "si", il suppose que le code peut prendre la valeur "true". branche ou le "faux" " branche. Cependant, ce n'est pas toujours possible. Considérez:

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

Le " faux " la branche de l'instruction if est inaccessible. Ceci est un exemple évident, mais lorsque vous prenez en compte plusieurs instructions if, il devient de plus en plus difficile de savoir si un chemin est possible ou non.

Il n'y a que trois chemins possibles dans votre code. Le chemin qui emprunte le " faux " branche dans la première instruction if et le paramètre "true". branche dans la seconde est inaccessible.

Votre outil n’est pas assez intelligent pour le comprendre.

Cela étant dit, même si l'outil est parfait, obtenir une couverture de chemin à 100% est probablement improbable dans une application réelle. Cependant, une très faible couverture de chemin est un signe certain que votre méthode a une complexité cyclomatique trop élevée.

Answer 5

Personnellement, je pense que c'est une mauvaise forme de démarrer TOUTE fonction avec

bool retCode = true;

Vous supposez explicitement que le système réussira par défaut, puis échouera dans certaines conditions.

Les programmeurs venant après vous ne feront pas cette même hypothèse.

Échec rapide, échouez tôt.

Et comme d’autres l’ont dit, si vous souhaitez tester des cas d’échec, vous devez coder les tests qui échouent.