Каковы альтернативные показатели для покрытия кода?

Ответ 1

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

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

Это лишь некоторые из ключевых показателей, которые могут предоставить вам NDepend, метрика .NET и функция сопоставления зависимостей. Недавно я много работал с метриками кода, и эти 4 метрики являются ключевыми ключевыми метриками, которые мы считаем наиболее полезными. Однако NDepend предлагает несколько других полезных показателей, включая Efferent и Afferent, а также абстрактную и нестабильность, которые в совокупности обеспечивают хорошую оценку того, насколько ваш код будет поддерживаться (и независимо от того, вызывает ли ваша NDepend зона Зоны боли или Зона Бесполезность.)

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

Ответ 2

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

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

Ответ 3

Важные показатели ошибок также важны:

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

Чтобы обнаружить, например, если ошибки не разрешены так быстро, как новые.

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

Как насчет (строк кода)/(количество тестовых случаев)? Не очень значимо (поскольку это зависит от LOC), но, по крайней мере, легко вычислить.

Другой может быть (количество тестовых случаев)/(количество методов).

Ответ 8

Как правило, коэффициент доходности дефектов дефектов составляет пропорциональный результат, и оба они обычно следуют кривой распределения Рэлея.
В какой-то момент ваша скорость обнаружения дефектов будет максимальной, а затем начнет уменьшаться.
Эта вершина представляет 40% обнаруженных дефектов.
Двигаясь вперед с помощью простого регрессионного анализа, вы можете оценить, сколько дефектов осталось в вашем продукте в любой момент после пика.
Это один из компонентов модели Лоуренса Путнэма.

Ответ 9

Покрытие сценария.

Я не думаю, что вы действительно хотите иметь 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
}

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

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

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

• Передача null

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

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

• Передача строки с ведущей или конечной запятой, например. name = value1 или name=, value2

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

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

SQLite - это чрезвычайно хорошо протестированная библиотека, и вы можете извлекать из нее всевозможные показатели.

Начиная с версии 3.6.14 (вся статистика в отчете противоречит выпуску SQLite), библиотека SQLite состоит из приблизительно 63,2 KSLOC кода C. (KSLOC означает тысячи "Source Lines Of Code" или, другими словами, строки кода, исключая пустые строки и комментарии.) Для сравнения, проект имеет в 715 раз больше тестового кода и тестовых скриптов - 45261.5 KSLOC.

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

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

Ответ 13

Мне нравится доход, продажи, прибыль. Они довольно хорошие показатели базы кода.

Ответ 14

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

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

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