Процент покрытия кода не очень хороший - PullRequest
1 голос
/ 18 июня 2009

Я установил на свой компьютер C ++ Test только с лицензией UnitTest (только лицензия Unit Test) в качестве плагина Visual Studio 2005 (cpptest_7.2.11.35_win32_vs2005_plugin.exe).

У меня есть образец, подобный следующему:

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

В моем случае после запуска инструмента покрытия у меня есть следующие результаты (для функции, аналогичной ранее упомянутой):

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

Я действительно не понимаю, почему у меня нет 100% покрытия, когда дело доходит до PathCoverage (PC). Также, если бы кто-то, имеющий опыт работы с C ++ Test, Parasoft мог бы объяснить для меня низкий охват MCDC, это было бы здорово.

Что я должен сделать, чтобы увеличить охват? как у меня нет идей в этом деле. Направления (некоторые части) документации приветствуются.

Спасибо,

Юлианский

Ответы [ 5 ]

3 голосов
/ 18 июня 2009

Я не могу помочь с конкретным инструментом, который вы используете, но общая идея с охватом пути состоит в том, что каждый возможный путь через код должен быть выполнен.

Если вы рисуете потоковую диаграмму через программу, разветвляетесь на каждый if / break / continue и т. Д., Вы должны увидеть, какие пути проходят ваши тесты через программу. Чтобы получить 100% (что не является абсолютно необходимым и не гарантирует идеального теста), ваш тест должен пройти каждую ветвь кода и выполнить каждую строку.

Надеюсь, это поможет.

2 голосов
/ 18 июня 2009

Это хороший справочник по различным типам покрытия кода: http://www.bullseye.com/coverage.html.

MCDC : Чтобы улучшить охват MCDC, вам нужно взглянуть на some_condition. Предполагая, что это сложное логическое выражение, вам нужно посмотреть, используете ли вы необходимые комбинации значений. В частности, каждое логическое подвыражение должно выполняться как истинное и ложное.

Путь : Одна из вещей, упомянутых в приведенной выше ссылке как недостаток покрытия пути, состоит в том, что многие пути невозможно использовать. Это может быть в вашем примере.

1 голос
/ 18 июня 2009

Есть четыре гипотетических пути через эту функцию. Каждое условие if удваивает количество путей. Каждый оператор if - это ветка, в которой вы можете пойти двумя разными путями. Поэтому, когда ваш инструмент встречает «если», он предполагает, что код может принять «истинную» ветвь или «ложную» ветвь. Однако, это не всегда возможно. Рассмотрим:

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

Ложная ветвь оператора if недоступна. Это очевидный пример, но когда вы учитываете несколько операторов if, становится все сложнее увидеть, возможен ли путь.

В вашем коде только три возможных пути. Путь, который принимает «ложную» ветвь в первом операторе if и «истинную» ветвь во второй, недоступен.

Ваш инструмент недостаточно умен, чтобы понять это.

При этом, даже если инструмент идеален, получение 100% покрытия пути, вероятно, маловероятно в реальном приложении. Однако очень низкий охват тракта является верным признаком того, что ваш метод имеет слишком высокую цикломатическую сложность.

1 голос
/ 18 июня 2009

Вам нужно как минимум два тестовых случая, чтобы получить 100% охват. Тот, где some_condition является истинным, и тот, где его нет. Если у вас есть, вы должны получить 100% покрытие.

Хотя вы должны увидеть 100% покрытие как идеальное. В этом случае вам потребуется 3 теста, чтобы можно было проверить все комбинации. Посмотрите цикломатическую сложность, чтобы узнать больше об этом.

0 голосов
/ 18 июня 2009

Лично я считаю, что начинать ЛЮБУЮ функцию с

- плохая идея.

bool retCode = true;

Вы делаете явное предположение, что по умолчанию он будет успешным, а затем потерпит неудачу при определенных условиях.

Программисты, которые придут за вами, не сделают этого предположения.

Неудачи быстро, неудачи рано.

И, как уже говорили другие, если вы хотите тестировать случаи сбоев, вы должны кодировать тесты, которые не проходят.

...