La percentuale di copertura del codice non è buona

Question

Ho installato C ++ Test sul mio computer solo con licenza UnitTest (solo licenza Unit Test) come plug-in Visual Studio 2005 (cpptest_7.2.11.35_win32_vs2005_plugin.exe).

Ho un campione simile al seguente:

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

Nel mio caso dopo aver eseguito lo strumento di copertura ho i seguenti risultati (per una funzione simile alla precedente):

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

Non capisco davvero perché non ho una copertura del 100% quando si tratta di PathCoverage (PC). Anche se qualcuno che ha esperienza con C ++ Test Parasoft potrebbe spiegare la bassa copertura MCDC per me sarebbe fantastico.

Cosa devo fare per aumentare la copertura? dato che sono senza idee in questo caso. Le istruzioni per (alcune parti della) documentazione sono benvenute.

Grazie

Iulian

Answer 1

Questo è un buon riferimento ai vari tipi di copertura del codice: http: //www.bullseye. com / coverage.html .

MCDC : per migliorare la copertura MCDC dovrai guardare some_condition . Supponendo che sia un'espressione booleana complessa, dovrai verificare se stai esercitando le combinazioni di valori necessarie. In particolare, ogni sottoespressione booleana deve essere esercitata su true e false.

Percorso : una delle cose menzionate nel link sopra come svantaggio della copertura del percorso è che molti percorsi sono impossibili da esercitare. Questo potrebbe essere il caso del tuo esempio.

Answer 2

Non posso aiutarti con lo strumento specifico che stai utilizzando, ma l'idea generale con la copertura del percorso è che ogni possibile percorso attraverso il codice dovrebbe essere eseguito.

Se tracciate un diagramma di flusso attraverso il programma, ramificandoli in ogni if ??/ break / continue, ecc. dovreste vedere quali percorsi stanno seguendo i vostri test attraverso il programma. Per ottenere il 100% (che non è del tutto necessario, né garantisce un test perfetto) il test dovrà scendere in ogni ramo del codice, eseguendo ogni riga.

Spero che sia d'aiuto.

Answer 3

Per ottenere una copertura del 100% sono necessari almeno due casi di prova. Uno in cui some_condition è vero e uno in cui non lo è. Se lo hai, dovresti ottenere una copertura del 100%.

Anche se dovresti vedere una copertura del 100% perfetta. In questo caso sono necessari 3 test per poter testare tutte le combinazioni. Cerca la complessità ciclomatica per saperne di più.

Answer 4

Esistono quattro percorsi ipotetici attraverso quella funzione. Ogni clausola if raddoppia il numero di percorsi. Ogni if-statement è un ramo in cui puoi andare in due modi diversi. Pertanto, ogni volta che il tuo strumento rileva un "if", presuppone che il codice possa prendere il "vero" ramo o il "falso" ramo. Tuttavia, questo non è sempre possibile. Prendere in considerazione:

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

Il " false " il ramo dell'istruzione if non è raggiungibile. Questo è un esempio ovvio, ma quando si tiene conto di diverse istruzioni if ??diventa sempre più difficile vedere se un percorso è possibile o meno.

Ci sono solo tre possibili percorsi nel tuo codice. Il percorso che prende il "falso" ramo nella prima istruzione if e nella "quotazione" vera " ramo nel secondo è irraggiungibile.

Il tuo strumento non è abbastanza intelligente da capirlo.

Detto questo, anche se lo strumento è perfetto, è probabilmente improbabile ottenere una copertura del percorso del 100% in un'applicazione reale. Tuttavia, una copertura del percorso molto bassa è un segno sicuro che il tuo metodo ha una complessità ciclomatica troppo elevata.

Answer 5

Personalmente, penso che sia una cattiva forma avviare QUALSIASI funzione con

bool retCode = true;

Stai assumendo esplicitamente che avrà successo per impostazione predefinita e quindi fallirà in determinate condizioni.

I programmatori che ti seguono non faranno la stessa ipotesi.

Fallisci velocemente, fallisci presto.

E come altri hanno già detto, se si desidera verificare i casi di errore, è necessario codificare i test che falliscono.