Есть ли у нас какие-нибудь правила большого пальца для оценки человеко-дней для тестовых случаев JUnit?

Question

У нас есть проект, которому 10 лет, с более чем 10 миллионами строк Java-кода.Теперь по ряду причин организация решила написать тестовые примеры JUnit для старого кода.Мы используем тестовые примеры Mockito JUnit.В рамках этого изменения мы должны оценить трудозатраты.Его очень сложно оценить по существующему коду и, более того, я новичок в проекте.Просто хочу знать, есть ли какое-нибудь правило большого пальца для оценки на основе количества строк кода.

Answer 1

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

c = t / (t + e)

Где

• t - это усилия, необходимые для разработки тестов,
• e - усилия, затраченные на разработку кода, и
• t + e = общее усилие по разработке (тесты + код)
• c охват.

Например:

• для покрытия 0%,Требуется 0% от ваших общих усилий по разработке, очевидно,
• для 20% покрытия, 20% от ваших общих усилий по разработке требуется для написания тестов
• для 50% покрытия, 50% от общего количествадля написания тестов требуется
• для 80% покрытия, для написания тестов требуется 80% от общего объема ваших усилий

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

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

Таким образом, формула для оценки на основе затраченных усилий и целевого охвата составляет

t = e*c / (1-c)

Так что, если вы уже потратили 1000 человеко-дней (ПД), вам потребуется еще 1000человеко-дней, чтобы получить 50% покрытия.Или 500 ПД на 33%, или 250 ПД на 20%.Или 4000 PD на 80%.

По сравнению с оценкой нижней границы Йоханнеса:

• Предположение: 500 LoC / PD -> 10 млн. LOC = 20.000 PD
• Оценка нижнего предела Йоханнеса:
  • 20.000 PD для 80%
• Моя (верхняя граница?) Оценка:
  • 20.000 PD для 50%
  • 80.000 PD на 80% (не забывайте, что код может плохо проверяться)

Правда, вероятно, где-то посередине.

Answer 2

Я не могу дать вам реалистичную оценку, но я могу дать вам оценку нижней границы, которая, надеюсь, покажет, что поставленная задача не должна быть выполнена.Чтобы охватить более 80 процентов полезной строки, вам понадобится примерно столько же строк созданного вручную тестового кода, сколько у вас есть рабочий код;так что это 10 миллионов лотов.Имея 20-летний опыт работы с TDD, я не думаю, что когда-либо писал более 500 LOC кода за один день (на самом деле это, вероятно, менее 50 строк в большинстве дней).Таким образом, нижняя граница составляет 10000000/500 = 20000 дней или 100 человек, которые не делают ничего, кроме написания тестов в течение всего года.

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