Можно ли использовать TDD с алгоритмами обработки изображений?

Ответ 1

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

В истинном процессе Test Driven Development вы сначала напишите неудачный тест перед добавлением каких-либо новых функций в свое программное обеспечение, а затем напишите код что заставляет тест проходить, промывать и повторять.

Этот процесс дает большую библиотеку Unit Tests, иногда с более LOC тестов, чем функциональный код!

Поскольку ваши аналитические алгоритмы имеют структурированное поведение, они отлично подходят для подхода TDD.

Но я думаю, что вопрос, который вы действительно задаете, - "как мне пойти на выполнение набора Интеграционные тесты против программного обеспечения для обработки нечетких изображений?" Вы можете подумать, что я раскалываю волосы, но это различие между Unit Tests и Integration Tests действительно зависит от того, что означает Test Driven Development. Преимущества процесса TDD исходят от богатой поддерживающей ткани Unit Tests больше всего на свете.

В вашем случае я бы сравнил набор тестов интеграции с автоматизированными метриками производительности с веб-приложением. Мы хотим накапливать историческую запись времени выполнения, но мы, вероятно, не хотим явно отказываться от сборки для одного плохо выполняемого исполнения (на которое могли повлиять перегруженность сети, дисковый ввод-вывод и т.д.). Вы можете установить некоторые отклонения в производительности вашего тестового набора и сервер Continuous Integration выдает ежедневные отчеты, которые дают вам высокий уровень обзора производительность вашего алгоритма.

Ответ 2

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

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

Ответ 3

Всякий раз, когда я разрабатываю компьютерное зрение, разработка TDD является почти стандартной практикой. У вас есть изображения и то, что вы хотите измерить. Первый шаг - обозначить (большое) подмножество изображений. Это дает вам тестовые данные. Процесс (для полной корректности) состоит в том, чтобы разделить тестовый набор на два, "набор разработчика" и "набор проверки". Вы повторяете цикл разработки, пока ваш алгоритм не будет достаточно точным при применении к набору разработки. Затем вы проверяете результат в наборе верификации (чтобы вы не перетренировались в каком-то странном аспекте вашего набора разработчика. Это тестовая разработка на самом чистом уровне.

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

• Регулярные ошибки, которые вы получите в своем программном обеспечении. Они могут быть протестированы с использованием "обычных" методов TDD.
• Производительность вашего алгоритма, для которого вам нужна система, описанная выше.

Программа может быть ошибкой в ​​соответствии с (1), но не совсем согласно (2). Например, очень простой алгоритм сегментации изображений гласит: "левая половина изображения - это один сегмент, правая половина - еще один сегмент. Эта программа может быть легко выполнена в соответствии с (1). Это совсем другое дело он удовлетворяет вашим потребностям в производительности. Не путайте эти два аспекта и не позволяйте вмешиваться в другие.

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

Ответ 4

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

Для реального алгоритма, такого как сегментация изображения, TDD не имеет особого смысла IMHO. Я даже не думаю, что модульные тесты имеют смысл здесь. Конечно, вы можете писать тесты, но они всегда будут очень хрупкими. Типичному алгоритму обработки изображений требуется несколько параметров, которые необходимо скорректировать для желаемых результатов (процесс, который не может быть автоматизирован и не может быть выполнен до того, как алгоритм работает). Результаты алгоритма сегментации также не определены хорошо, но ваш unit test может тестировать только определенное свойство. Алгоритм может иметь это свойство, не делая того, что вы хотите, или наоборот, поэтому ваш результат теста не очень информативен. Кроме того, для проверки результатов алгоритма сегментации вам нужно написать много довольно жесткого кода, а проверка результатов визуально довольно проста, и вам все равно придется это делать.

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

Ответ 5

Я бы сказал, что TDD намного проще в таком приложении, чем в веб-приложении. У вас есть полностью детерминированный алгоритм, который вы должны проверить. Вам не нужно беспокоиться о нечетких вещах, таких как ввод пользователей и рендеринг HTML.

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

Ответ 6

TDD при обработке изображений имеет смысл только для детерминированных проблем, таких как:

• арифметика изображений
• генерация гистограмм
• и т.д.

Однако TDD не подходит для алгоритмов извлечения данных, таких как:

• обнаружение края
• сегментирование
• определение угла.

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

Ответ 7

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

Мы подошли к концу, что TDD в компьютерном зрении/обработке изображений (относительно глобальной цели сегментации, обнаружения или sth, как это) может быть:

• получить изображение/последовательность, которая должна быть обработана, и создать тест для этого изображения: желаемый результат и метрику, чтобы указать, насколько далеко ваш результат может отличаться от этой "истины".

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

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

• вернитесь к 2.

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

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

По-прежнему вы можете использовать традиционное модульное тестирование для детерминированных частей этих алгоритмов, но это не настоящая проблема обработки "TDD-in-signal"

Ответ 8

Я не вхожу в вашу проблему, поэтому я не знаю ее горячих точек. Однако конечный результат вашего алгоритма, надеюсь, детерминирован, поэтому вы можете выполнять функциональное тестирование на нем. Конечно, вам нужно будет определить "хорошо известный" результат. Я знаю, что TDD выполняется на графических библиотеках (точнее, VTK). Сравнение выполняется на изображении конечного результата, пиксель за пикселем. Не вдаваясь в подробности, если у вас есть хороший результат, вы можете выполнить md5 результата теста и сравнить его с md5 известного-хорошего.

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

Ответ 9

Можете взглянуть на этот документ

Ответ 10

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

Ответ 11

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

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

Затем вы можете использовать порог на уровне успеха, чтобы проверить, не прошел тест или нет.