Какие могут быть альтернативные метрики для покрытия кода?

Question

Покрытие кода является Propably наиболее спорным код метрики. Некоторые говорят, что вы должны достичь 80% покрытия кода, другие говорят, что это поверхностно и ничего не говорит о качестве вашего тестирования. (См. хороший ответ Джона Лимджапа «Какой разумный охват кода% для модульных тестов (и почему)?» .)

Люди стремятся все измерить. Они нуждаются в сравнениях, тестах и ​​т. Д.
Проектным командам нужен указатель, насколько хорошо их тестирование.

Так, каковы альтернативы покрытию кода? Что может быть хорошим показателем, который говорит больше, чем «Я коснулся этой строки кода»?
Есть ли реальные альтернативы?

Answer 1

Если вы ищете некоторые полезные метрики, которые говорят вам о качестве (или отсутствии такового) вашего кода, вам следует изучить следующие метрики:

1. Цикломатическая Сложность
   • Это показатель сложности метода.
   • Обычно 10 и ниже - хорошо, 11-25 - плохо, выше - ужасно.
2. Глубина вложения
   • Это показатель количества вложенных областей в методе.
   • Обычно 4 и ниже - хорошо, 5-8 - плохо, выше - ужасно.
3. Реляционная сплоченность
   • Это показатель того, насколько хорошо связаны типы в пакете или сборке.
   • Реляционная сплоченность является в некоторой степени относительной метрикой, но тем не менее полезна.
   • Допустимые уровни зависят от формулы. Учитывая следующее:
     • R: количество связей в упаковке / сборке
     • N: количество типов в упаковке / сборке
     • H: сплоченность отношений между типами
   • Формула: H = (R + 1) / N
   • Учитывая приведенную выше формулу, допустимый диапазон составляет 1,5 - 4,0
4. Отсутствие сплоченности методов (LCOM)
   • Это показатель того, насколько сплочен класс.
   • Сплоченность класса - это показатель количества полей, на которые ссылается каждый метод.
   • Хорошее указание на то, соответствует ли ваш класс принципу единой ответственности.
   • Формула: LCOM = 1 - (сумма (MF) / M * F)
     • M: количество методов в классе
     • F: количество полей экземпляра в классе
     • MF: количество методов в классе, обращающихся к конкретному полю экземпляра
     • сумма (MF): сумма MF по всем полям экземпляра
   • Класс, который является полностью связным, будет иметь LCOM 0.
   • Класс, который является полностью несвязным, будет иметь LCOM 1.
   • Чем ближе к 0 вы подходите, тем более сплоченным и обслуживаемым ваш класс.

Это лишь некоторые из ключевых метрик, которые NDepend, утилита для отображения метрик и .NET, может предоставить вам. Недавно я много работал с метриками кода, и эти 4 метрики являются основными ключевыми метриками, которые мы сочли наиболее полезными. Тем не менее, NDepend предлагает несколько других полезных метрик, включая Efferent и Afferent сцепление и Abstractness & Instability, которые в совокупности обеспечивают хорошую меру того, насколько легко будет поддерживать ваш код (и независимо от того, называете ли вы в том, что NDepend называет Zone of Pain или Zone of Бесполезность.)

Даже если вы не работаете с платформой .NET, я рекомендую взглянуть на страницу NDepend metrics . Там есть много полезной информации, которую вы можете использовать для расчета этих метрик на любой платформе, на которой вы разрабатываете.

Answer 2

Crap4j - это одна довольно хорошая метрика, о которой я знаю ...

Это реализация Java метрики программного обеспечения для анализа рисков и прогнозирования изменений, которая сочетает в себе цикломатическую сложность и охват кода автоматическими тестами.

Answer 3

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

Использование его вместе с юнит-тестами и стремление к 100% охвату скажут вам, что все «проверенные» детали (предполагается, что все было успешно) работают так, как указано в юнит-тесте.

Написание юнит-тестов из технического проекта / функционального проекта, со 100% охватом и 100% успешными тестами скажет вам, что программа работает так, как описано в документации.

Теперь единственное, что вам нужно, это хорошая документация, особенно функциональный дизайн, программист не должен писать, что, если он (а) не является экспертом в этой конкретной области.

Answer 4

Как насчет отслеживания тенденции покрытия кода во время вашего проекта?

Как и во многих других метриках, одно число мало что говорит.

Например, трудно сказать, есть ли проблема, если «у нас соответствие правилам Checkstyle 78,765432%». Если вчерашнее соблюдение было 100%, у нас определенно проблемы. Если вчера было 50%, мы, вероятно, делаем хорошую работу.

Я всегда нервничаю, когда покрытие кода становится все меньше и меньше с течением времени. Есть случаи, когда это нормально, поэтому вы не можете выключить голову, глядя на диаграммы и цифры.

Кстати, сонар (http://sonar.codehaus.org/) - отличный инструмент для отслеживания трендов.

Answer 5

Code Coverage - это всего лишь индикатор, который помогает указать на строки, которые вообще не выполняются в ваших тестах, что довольно интересно. Если вы достигаете 80% покрытия кода или около того, имеет смысл взглянуть на оставшиеся 20% строк, чтобы определить, пропускаете ли вы какой-либо вариант использования. Если вы видите «ага, эта строка будет выполнена, если я пропущу пустой вектор», тогда вы можете написать тест, который пройдет пустой вектор.

В качестве альтернативы, о которой я могу подумать, если у вас есть документ с техническими характеристиками с вариантами использования и функциональными требованиями, вы должны сопоставить им модульные тесты и посмотреть, сколько UC покрыто FR (конечно, это должно быть 100%) и сколько FR покрывается UT (опять же, это должно быть 100%).

Если у вас нет спецификаций, кого это волнует? Все, что случится, будет в порядке:)

Answer 6

Метрики ошибок также важны:

• Количество ошибок, поступающих
• Количество исправленных ошибок

Например, чтобы определить, устраняются ли ошибки не так быстро, как появляются новые

Answer 7

Это не было упомянуто, но количество изменений в данном файле кода или метода (глядя на историю контроля версий) особенно интересно, когда вы создаете набор тестов для плохо протестированного кода. Сосредоточьте свое тестирование на тех частях кода, которые вы сильно изменили. Оставьте те, которые вы не делаете, на потом.

Не упустите причину и следствие. Вы можете избежать изменения непроверенного кода и можете изменить проверенный код больше.

Answer 8

Значение в покрытии кода - это дает вам некоторое представление о том, что было выполнено тестами. Фраза «покрытие кода» часто используется для обозначения покрытия заявления, например, «сколько моего кода (в строках) было выполнено», но на самом деле существует более сотни разновидностей «покрытия». Эти другие версии охвата пытаются дать более сложное представление о том, что значит использовать код.

Например, условие покрытия измеряет, сколько отдельных элементов условных выражений было выполнено. Это отличается от покрытия заявления. MC / DC «измененное условие / покрытие решения» определяет, были ли продемонстрированы все элементы всех условных выражений для контроля результата условного выражения, и требуется ли FAA для программного обеспечения самолета. Покрытие пути измеряет, сколько возможных путей выполнения в вашем коде было использовано. Это лучшая мера, чем охват операторов, поскольку пути по сути представляют разные случаи в коде. Какую из этих мер лучше всего использовать, зависит от того, насколько вы обеспокоены эффективностью ваших тестов.

Википедия достаточно хорошо обсуждает многие варианты тестового покрытия. http://en.wikipedia.org/wiki/Code_coverage

Answer 9

Я написал сообщение в блоге о том, почему Высокий коэффициент охвата тестами - хорошая вещь в любом случае .

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

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

Answer 10

Сценарий покрытия.

Не думаю, что вы действительно хотите иметь 100% покрытие кода. Тестирование говорит, что простые геттеры и сеттеры выглядят как пустая трата времени.

Код всегда выполняется в каком-то контексте, поэтому вы можете перечислить как можно больше сценариев (в зависимости от сложности проблемы, иногда даже всех) и протестировать их.

Пример:

// parses a line from .ini configuration file
// e.g. in the form of name=value1,value2
List parseConfig(string setting)
{
    (name, values) = split_string_to_name_and_values(setting, '=')
    values_list = split_values(values, ',')
    return values_list
}

Теперь у вас есть много сценариев для тестирования. Некоторые из них:

• Передача правильного значения

• Элемент списка

• Passing null

• Передача пустой строки

• Передача неформатированного параметра

• Передача строки с запятой или концом, например. имя = значение1 или имя =, значение2

Запуск только первого теста может дать вам (в зависимости от кода) 100% покрытия кода. Но вы не учли все возможности, так что сама по себе метрика мало о чем говорит.