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

Question

Что я должен сделать

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

Проблема

Данные, хранящиеся в электронных таблицах, имеют непредсказуемый формат. Компания, создавшая эти таблицы, не имела фиксированного / документированного формата для экспорта этих файлов, и иногда появляются ошибочные данные. Например, большинство лет представлено как «2009», но есть случаи, когда год представлен как «20». Другой пример: данные в этих файлах не нормализованы, поэтому я использую разделители для разделения значений определенных ячеек. Иногда эти разделители меняются.

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

Вопрос

Как можно проверить правильность программы в такой ситуации? Или, скорее, как получить довольно стабильную версию продукта, не проверяя все доступные данные?

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

Каково ваше мнение? Как бы вы решили эту проблему?

Answer 1

Если не указано, какой формат данных, то все приемлемо.

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

Вы должны написать свою программу так, чтобы она либо генерировала исключение, либо регистрировала ошибку при работе с данными, которые не соответствуют спецификации. Затем запустите программу на ЧАСТИ доступных данных, пока она не запустится без исключения. Это можно рассматривать как учебный набор для разработки вашей программы. Затем используйте некоторые из сохраненных данных для использования в качестве набора TEST. Это даст вам оценку того, сколько исключений / ошибок ваша программа сгенерирует при работе.

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

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

Answer 2

Как проверить правильность программы в такой ситуации? Или, скорее, как получить довольно стабильную версию продукта, не запуская ее по всем доступным данным?

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

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

Answer 3

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

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

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

Answer 4

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

Итак, я составляю небольшой файл данных, который сначала содержит только несколько строк нормальных данных. Это юнит тест № 1.

Затем я делаю быстрый визуальный просмотр некоторых данных, чтобы обнаружить любые очевидные исключения. Модульные тесты со 2 по n.

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

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

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

Answer 5

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

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

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

Answer 6

Как насчет обработки каждого фрагмента данных (чтобы вам не приходилось проверять наличие дубликатов). Те, которые проходят, попадают в базу данных. Исключения попадают в файл исключений. Пользователь может открыть файл исключения и внести исправления / изменения в данные. Затем они могут запустить вашу программу в файле исключений.

Это изолирует необработанные данные для пользователя для исправления и не позволит вам обрабатывать одни и те же данные дважды (или более).