Оценка модульных тестов, необходимых в большой кодовой базе - PullRequest
Новая
       4

Оценка модульных тестов, необходимых в большой кодовой базе

2 голосов
/ 23 февраля 2012

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

Кодовая база работает в основном так: 

class SNR_15_UNR extends Rule {
    public double getValue(RuleContext context) {
        double snr_15_ABK = context.getValue(SNR_15_ABK.class);
        double UNR = context.getValue(GLOBAL_UNR.class);
        if(UNR <= 0) // if UNR value would reduce snr, apply the reduction
          return snr_15_ABK + UNR;
        return snr_15_ABK;
    }
}

Когда вызывается context.getValue(Class<? extends Rule>), она просто оценивает конкретное правилои возвращает результат.Это позволяет создавать граф зависимостей во время оценки правила, а также обнаруживать циклические зависимости.

Существует около 500 таких классов правил.Теперь мы хотим внедрить тесты для проверки правильности этих правил.

Наша цель - реализовать список тестирования следующим образом: 

TEST org.project.rules.SNR_15_UNR
INPUT org.project.rules.SNR_15_ABK = 50
INPUT org.project.rules.UNR = 15
OUTPUT SHOULD BE 50

TEST org.project.rules.SNR_15_UNR
INPUT org.project.rules.SNR_15_ABK = 50
INPUT org.project.rules.UNR = -15
OUTPUT SHOULD BE 35

Вопрос: сколько тестовых сценариев необходимо?Можно ли использовать статический анализ кода, чтобы определить, сколько уникальных путей кода существует по всему коду?Существует ли какой-либо такой инструмент, или я должен начать заниматься Eclipse JDT?

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

Ответы [ 2 ]

2 голосов
/ 27 февраля 2012

(РЕДАКТИРОВАТЬ 2/25, сфокусировано на усилиях по тестированию):

У вас есть 500 подклассов, и у каждого появляется (на основе вашего примера с одним условным условием) 2 случая. Я думаю, вам нужно 500 * 2 теста.

Если ваш код не является регулярным, как вы предполагаете, обычный (охват) инструмент покрытия кода может не быть тем ответом, который вы считаете нужным в качестве отправной точки, но на самом деле он может помочь вам сделать оценку. Код T <50 проверяет случайно выбранные классы и собирает данные покрытия кода P (в процентах) по любой части кодовой базы, которую вы считаете нуждающейся в тестировании (особенно ваши классы). Тогда вам нужно примерно (1-P) * 100 * T тестов. </p>

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

(ОРИГИНАЛЬНЫЙ ОТВЕТ, ориентированный на инструменты покрытия трассы)

Большинство инструментов покрытия кода являются инструментами покрытия "линии" или "ветви"; они не учитывают уникальные пути через код. В лучшем случае они считают основные блоки.

Инструменты покрытия пути существуют; люди создавали их для исследовательских демонстраций, но коммерческие версии встречаются относительно редко. Вы можете найти один в http://testingfaqs.org/t-eval.html#TCATPATH. Я не думаю, что это обрабатывает Java.

Одна из проблем заключается в том, что видимые пути в коде, как правило, экспоненциальны в количестве решений, поскольку каждое обнаруженное решение генерирует Истинный путь и Ложный путь на основе результата условного (1 решение -> 2 пути, 2 решения -> 4 пути, ...). Хуже петли фактически являются решением, повторяемым столько раз, сколько повторяется цикл; цикл, который повторяется 100 раз, имеет 2 ** 100 путей. Чтобы решить эту проблему, более интересные инструменты покрытия пути пытаются определить осуществимость пути: если символически объединенные предикаты из условных выражений в префиксе этого пути фактически ложны, путь невозможен и может быть проигнорированным, так как это не может действительно произойти. Другим стандартным приемом является обработка циклов как 0, 1 и N итераций, чтобы уменьшить количество видимых путей. Для управления количеством путей требуется довольно много оборудования, значительно превышающего то, что требуется большинству инструментов тестирования покрытия ветвей, что помогает объяснить, почему реальные инструменты покрытия путей встречаются редко.

0 голосов
/ 23 февраля 2012

сколько тестовых сценариев необходимо?

Много. 500 может быть хорошим началом.

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

Да. Это называется инструментом покрытия кода. Вот несколько бесплатных. http://www.java -sources.com / с открытым исходным кодом / код-покрытие

...