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

Question

Итак, я не уверен, каковы плюсы и минусы du-path покрытия (или, например, каких-либо критериев покрытия потока данных) в сравнении с критериями предикатов или критериями ветвления / узла.

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

void m();
void n();

void method(boolean b) {
    if (b) {
        m();
    } else {
        n();
    }
}

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

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

• График
• Поток данных
• Логика
• Ввод
• Синтаксис

виды критериев покрытия (в основном, те, которые можно найти в Введение в тестирование программного обеспечения ).То есть я в основном ищу общую эвристику для общего случая.

Спасибо

Answer 1

По общему признанию, я не провел много исследований в этой области и не обязательно буду следовать за вами полностью (в основном из-за моего отсутствия опыта в этой области).Но, надеюсь, это не слишком далеко от базы.

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

Вы можете начать с наглядных методов и написания тестовых примеров, но это быстро становится ненадежным, так как вы гарантированно НЕ увидите все возможные пути выполнения независимо от типа алгоритма.Даже очень маленькие программы будут приводить к ошибкам, которые не были учтены, так как тестировщик не задумывался о том, чтобы «пробовать» таким образом.

Что вам действительно нужно, так это инструмент покрытия кода, который сообщает вам, какие пути выполнения были охвачены вашими юнит-тестами, а какие - нет.На этом этапе вы можете принимать логические решения о погоде или не покрывать эти пропущенные случаи (поскольку не все случаи могут не стоить вашего времени).Без такого инструмента я бы подумал, что вы потратили бы бесчисленное количество человеко-часов, построчно и отслеживая, какие тестовые случаи охватывали что ... Даже если инструмент стоит несколько сотен долларов (или даже нескольких тысяч долларов), я думаю, выбы быстро окупить эти средства в сэкономленное время.

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

Некоторые инструменты покрытия кода (не исчерпывающие)):

• .NET - NCover
• PHP - PHP Покрытие
• JAVA - EMMA
• Рубин - CoverMe
• JavaScript - JSCoverage