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

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

Начиная с версии 3.6.14 (все статистика в отчете относится к этому выпуску SQLite), библиотека SQLite состоит примерно из 63,2 KSLOC кода C. (KSLOC означает тысячи «исходных строк кода» или, другими словами, строки кода, исключая пустые строки и комментарии.) Для сравнения, в проекте в 715 раз больше тестового кода и тестовых скриптов - 45261,5 KSLOC.

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

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

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

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

Я не думаю, что вы действительно хотите иметь 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% покрытие кода. Но вы не учли все возможности, поэтому сама по себе метрика мало что вам скажет.

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

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

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

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

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

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

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

А как насчет наблюдения за тенденцией покрытия кода во время вашего проекта?

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

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

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

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

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

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

Для обнаружения, например, того, что ошибки не устраняются так же быстро, как появляются новые.

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

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

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

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

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

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

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

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

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

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

I wrote a blog post about why High Test Coverage Ratio is a Good Thing Anyway.

I agree that: when a portion of code is executed by tests, it doesn’t mean that the validity of the results produced by this portion of code is verified by tests.

But still, if you are heavily using contracts to check states validity during tests execution, high test coverage will mean a lot of verification anyway.