Как проверить данные, перенесённые из документа в таблицу?

Отделяйте проверку от преобразования файла

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

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

Свяжите каждую строку с исходным документом

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

Если в документе несколько таблиц, укажите раздел или расположение таблицы. Явно определите, входят ли заголовки, сноски и строки продолжения в данные. Сохраняйте связь, если один документ создаёт несколько выходных записей. Значение, которое нельзя объяснить обращением к источнику, требует проверки даже в заполненной таблице. В работе «Из документа в таблицу» такую прослеживаемость можно включить в условия сдачи.

Сопоставляйте поля по смыслу

Подготовьте короткую схему, где исходный заголовок стоит рядом с целевым столбцом. «Дата» означает дату документа, операции или окончания действия? Какая единица используется для «количества»? Похожие заголовки не обязательно обозначают одно и то же. Заранее определите, что происходит при отсутствии поля: оно остаётся пустым, попадает в исключения или останавливает обработку.

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

Проверяйте формат чисел и идентификаторов

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

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

Показывайте исключения понятно

В отчёте должны быть файл, страница, поле, ожидаемое значение и обнаруженное состояние. Нечитаемое поле, отсутствующая страница, повторный документ и неверный шаблон — разные причины. Сообщения «есть ошибка» недостаточно. Пользователь должен понимать, какая запись требует проверки, почему и что произойдёт дальше. После исправления в записи должно быть видно, что затронутая строка проверена повторно.

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

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

Внимание: защищайте документы и доступ

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

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

Частые вопросы

Заполненная таблица означает правильный перенос?

Нет. Нужно также проверить связь с источником, смысл полей, формат чисел и отношения между записями.

Нужно автоматически дополнять нечитаемое поле?

Без заранее согласованного правила нельзя угадывать значение; его показывают как исключение, требующее проверки.

Какие документы подходят для испытания?

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