Código porcentagem de cobertura não é bom

Question

Eu tenho instalado no meu computador de teste C ++ somente com licença UnitTest (somente licença de teste de unidade) como um Studio 2005 plug-in Visual (cpptest_7.2.11.35_win32_vs2005_plugin.exe).

Eu tenho uma amostra semelhante ao seguinte:

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

No meu caso depois de executar a ferramenta de cobertura Eu tenho os seguintes resultados (para uma função semelhante ao mencionado anteriormente):

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

Eu realmente não entendo por que eu não tenho 100% de cobertura quando se trata de PathCoverage (PC). Além disso, se alguém que tem experiência com C ++ Teste Parasoft poderia explicar a baixa cobertura MCDC para mim isso seria ótimo.

O que devo fazer para aumentar a cobertura? como eu estou fora de ideias neste caso. Indicações para (algumas partes) a documentação são bem-vindos.

Obrigado,

Iulian

Answer 1

Esta é uma boa referência sobre os vários tipos de cobertura de código: http: //www.bullseye. com / coverage.html .

MCDC : Para melhorar a cobertura MCDC você precisa olhar para some_condition. Assumindo que é uma expressão booleana complexo, você precisa olhar para saber se você está se exercitando as combinações necessárias de valores. Especificamente, cada um boolean necessidades sub-expressão deve ser exercida verdadeiro e falso.

Caminho : Uma das coisas mencionadas no link acima como sendo uma desvantagem de cobertura do trajeto é que muitos caminhos são impossíveis de exercício. Esse pode ser o caso com o seu exemplo.

Answer 2

Eu não posso ajudar com a ferramenta específica que você está usando, mas a idéia geral com cobertura caminho é que cada caminho possível através do código deve ser executado.

Se você desenhar um fluxograma através do programa, ramificando em cada caso / break / continue, etc. você deve ver quais caminhos os testes estão tomando através do programa. Para obter 100% (que não é totalmente necessário, nem assegura um teste perfeito) o ensaio terá de ir para baixo todos os ramos do código, a execução de cada linha.

Espero que ajude.

Answer 3

Você precisa de pelo menos dois casos de teste para obter uma cobertura de 100%. Um onde some_condition é verdadeiro e aquele em que não é. Se você tiver que você deve obter uma cobertura de 100%.

Embora você deve ver 100% de cobertura tão perfeita. Você precisaria de 3 testes para que, neste caso, para todas as combinações podem ser testadas. Olhe para cima complexidade ciclomática para saber mais sobre isso.

Answer 4

Há quatro caminhos hipotéticos através dessa função. Cada cláusula se dobra o número de caminhos. Cada-instrução se é um ramo onde você pode ir de duas maneiras diferentes. Assim, sempre que a sua ferramenta encontra um "se", ele assume o código pode tomar o ramo "verdadeiro" ou o ramo "false". No entanto, isso nem sempre é possível. Considere o seguinte:

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

O ramo "false" da instrução if é inacessível. Este é um exemplo óbvio, mas quando você leva em conta vários se-declarações, torna-se cada vez mais difícil para ver se um caminho é possível ou não.

Existem apenas três caminhos possíveis em seu código. O caminho que leva o ramo "false" na primeira instrução if e o "verdadeiro" ramo no segundo é inacessível.

A sua ferramenta não é inteligente o suficiente para perceber isso.

Dito isto, mesmo que a ferramenta é perfeita, obtendo 100% de cobertura caminho é pouco provável em uma aplicação real. No entanto, muito baixa cobertura caminho é um sinal certo de que seu método tem muito alta complexidade ciclomática.

Answer 5

Pessoalmente, eu acho que é má forma para iniciar qualquer função com

bool RETCODE = true;

Você está fazendo uma suposição explícita de que ele vai ter sucesso por padrão, e depois falhar sob certas condições.

Os programadores vindo atrás de você não vai fazer isso mesmo pressuposto.

falhar rapidamente, falhar cedo.

E, como já foi dito, se você quiser casos de falha de teste, você tem que testes de código que falham.