65.000.000.000 тестов для запуска

Меня спросили о том, как выполнить набор из 65 000 000 000 тестов, и мне интересно, нормально ли иметь проект с таким огромным количеством тестов.

Вы работали в проектах с этой характеристикой?

С 65 миллиардами тестов кажется, что вас просят проверить все возможные входные данные. Это бесполезно - вы, по сути, будете проверять правильность работы вашего процессора, а не правильность кода.

Вместо этого вы должны тестировать классы эквивалентности . Это резко сократит диапазон тестовых входов.

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

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

Если это настоящий набор тестов, то вам не захочется работать над ним.

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

Многие тесты могут быть абстрагированы в «классы эквивалентности», что означает, что вместо запуска 3 миллиардов тестов, вы запускаете 1, что дает вам разумную уверенность в том, что все остальные тесты в этом классе эквивалентности будут выполнены успешно, если вы решите тратить впустую время их запуска.

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

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

Это не то, как пишутся реальные тесты, потому что, как указывали другие авторы и комментаторы, техническая мощность, необходимая для выполнения 65 миллиардовтесты ошеломляют. Это похоже на написание теста, в котором используется метод добавления двух целых чисел путем подключения каждой возможной перестановки двух 32-битных значений и проверки результата. Это полное безумие. Вы должны нарисовать линию и определить подмножество всех возможных тестовых случаев, которые между ними будут гарантировать, что система будет вести себя так, как ожидается, во всем диапазоне входных данных. Например. вы тестируете добавление нескольких «обычных» чисел, вы тестируете несколько сценариев с отрицательными числами, вы проверяете технические ограничения, такие как сценарии переполнения, и тестируете любые сценарии, которые могут привести к ошибке. Как уже упоминалось, эти различные типы тестов осуществляют "классы эквивалентности"; они позволяют вам взять репрезентативную выборку возможных входных данных, наряду с любыми известными «выбросами»,

Рассмотрим один из основных кодовых катов, генератор римских цифр. Задача, которая должна выполняться с использованием методов TDD в стиле «додзё», состоит в том, чтобы написать функцию, которая может принимать любое число от 1 до 3000 и производить правильную римскую цифру для этого числового значения.

Вы не решаете эту проблему, написав 3000 модульных тестов, по одному, и проходя их по очереди. Это безумие; упражнение обычно занимает от одного до двух часов, и вы проведете там несколько дней, проверяя каждое отдельное значение. Вместо этого вы становитесь умным. Вы начинаете с самого простого базового случая (1 == «I»), реализуете его, используя стратегию «наименьшего кода» ( return "I";), а затем ищите, как ваш код будет вести себя неправильно в другом ожидаемом сценарии (2 == » II "). Промыть и повторить; скорее всего, вы заменили свою первоначальную реализацию чем-то, что повторяет символ «I» так часто, как это необходимо (например return new String('I',number);). Это, очевидно, пройдет испытание на III, так что вы не беспокойтесь; вместо этого вы пишете тест для 4 == "IV", который, как вы знаете, выиграл в текущей реализации '

Или, в более аналитическом стиле, вы изучаете каждое условное решение, которое принимается кодом (или должно быть), и пишете тест, предназначенный для ввода кода для каждого возможного результата каждого решения. Если у вас есть 5 операторов if (каждый из которых имеет ветви true и false), каждый из которых полностью независим от другого, вы кодируете 10 тестов, а не 32. Каждый тест будет разработан, чтобы утверждать две вещи относительно конкретного возможного решения; сначала, что правильное решение принято, и затем, что код, введенный при условии, что условие является правильным. Вы не пишете тест для каждой возможной перестановки независимых решений. Если решения являются зависимыми, то вам нужно проверить больше из них в комбинации, но таких комбинаций меньше, потому что некоторые решения принимаются только тогда, когда другое решение имело определенный результат.

Это "нормально"? Нет. Где «нормальный» определяется как средний или типичный опыт. Не могу сказать, что мне когда-либо приходилось работать над таким проектом, но я был в проекте, где один из каждых нескольких миллионов битов был бы перевернут. Проверка этого была ... проблемой.

Это потенциально требуется? Ну, это зависит от гарантий и специфики проекта. Поначалу это немного странно, но ваш вопрос не лишен специфики.

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

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

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

Эта ссылка на arstechnica может или не может пролить свет на ваши соображения по поводу тестирования. Кластеры GPU обычно используются для взлома паролей. Тот, который приведен в статье, может can cycle through as many as 350 billion guesses per second, так что ваш вид тестов 65B в перспективе. Вероятно, это другая область, но она показывает, как подход к задаче под разными углами может дать жизнеспособное решение.

Я не думаю, что целесообразно поддерживать тесты 6.5e + 10 на первом месте, поэтому их запуск может быть спорным. Даже самые крупные проекты, такие как Debian со всеми его пакетами, имеют всего несколько сотен миллионов SLOC.

Но если вам все равно нужно выполнить огромное количество тестов, есть несколько стратегий.

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

• Запустите их параллельно. С такой огромной базой кода у вас, вероятно, есть огромная ферма сборки (в JetBrains, относительно небольшой операции, у нас было 40-50 агентов сборки, работающих только на ферме непрерывной сборки / интеграции IDEA). Поскольку модульные тесты независимы, а интеграционные тесты могут повторно использовать уже созданный код, их сравнительно легко распараллелить.

• Хватит бегать рано. Если вы знаете, что конкретный набор тестов зависит от его правильного функционирования от правильности другого набора тестов, вы можете обрезать всю цепочку, если увидите, что одна ссылка не работает.

Отказ от ответственности: я не профессиональный инженер по тестированию. Возьмите вышеупомянутое зерно соли.

Хотя здесь было несколько хороших предложений о том, как попытаться ускользнуть с меньшим количеством тестов, я серьезно сомневаюсь, что ваша система имеет только 65 миллиардов входных комбинаций. Это менее 36 бит ввода. Предположим, вы уже приняли все советы, данные выше.

Если на выполнение каждого теста уходит около миллисекунды, и вы распределяете тесты только по 10 процессорам (одному обычному ПК), тест будет выполняться чуть более 69 дней. Это какое-то время, но не совсем необоснованно. Распределите их по 100 процессорам (дюжине обычных ПК или одному разумному серверному ПК), и тесты пройдут менее чем за 7 дней. Вы можете запускать их каждую неделю для проверки регрессий.