Как тестировать код обработки изображения?

Я работаю в области обработки изображений (в основном OCR), и мне интересно, как мне интегрировать модульные тесты в мою разработку.

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

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

— rold2007
источник

Можете ли вы набросать пример функции, где у вас возникают проблемы при создании модульного теста?

— Док Браун

Слишком коротко для реального ответа, а не для юнит-тестирования: мы обрабатываем данные вручную (как в случае: пройти большое количество выборок - я обычно беру больше 1000 для таких задач классификации, но это зависит от вашего общего размера выборки ) и автоматически сравнивает окончательные результаты с данными, обработанными вручную. Для этого я создал небольшой фреймворк, через несколько недель он станет открытым, но это описание - вы можете клонировать этот процесс: birgitplays.wordpress.com/2012/09/15/…

— Birgit P.

Для вашего примера вы можете легко проверить вращение, масштабирование и т. Д. В виде небольших единиц тестов. Поворот данного изображения на 45 градусов не должен сильно измениться. Это также касается масштабирования и морфологических операций. Однако проверить что-то, где ожидаемый результат развивается во время реализации, сложно. Вы можете попытаться измерить качество и сказать качество> = some_quality. Чтобы убедиться, что ваше качество не ухудшается, но это также может быть сложно. Кроме этого, все, что вы можете сделать, это иметь тесты, которые доказывают, что ваши основные части не сломаны. Как масштабировать / повернуть / и т. Д.

— Мартиерт

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

— rold2007

@ Биргит П .: Интересное решение. Как вы говорите, это все еще интеграционное тестирование. Наличие такой инфраструктуры, как ваша, поможет быстрее настроить эти тесты, но они не будут работать быстрее ...

— rold2007

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

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

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

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

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

— DXM
источник

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

— Кемода

Если вы выполняете какой-либо ввод по всей цепочке обработки и затем проверяете вывод, вы не юнит-тестирование, а интеграционное тестирование.

— tdammers

@tdammers: я никогда не говорил, чтобы запустить его через всю цепочку. Запустите некоторый ввод через один «блок», а не всю цепочку. И, конечно же, если на выходе это что-то отличное от изображений, то вам нужно только сохранить входные данные как ресурсы изображений.

— ДХМ

@DXM: я понимаю ваше решение, но думаю, что у нас могут быть разные ограничения. Мои входные / выходные данные сильно меняются в процессе разработки алгоритма. Как вы справляетесь с этими регулярными изменениями? В OCR я могу иметь точность более 99%, поэтому тестирование только на нескольких изображениях может дать мне ложное ощущение успеха, в то время как интеграционные тесты могут позже сказать мне, что я действительно ухудшил алгоритм ...

— rold2007