Функциональное тестирование выходных файлов, когда вывод недетерминирован (или с низким уровнем контроля)

Давным-давно мне пришлось тестировать программу, генерирующую изображение файла postscript. Одним из быстрых способов выяснить, выдает ли программа правильный ожидаемый результат, было выполнить md5 результата для сравнения с md5 «заведомо хорошего» вывода, который я проверил заранее.

К сожалению, Postscript содержит текущее время в файле. Это время, конечно, отличается в зависимости от того, когда выполняется тест, поэтому изменяется md5 результата, даже если получен ожидаемый результат. В качестве исправления я просто удалил дату с помощью sed.

Это хороший и простой сценарий. Нам не всегда так везет. Например, сейчас я программирую программу записи, которая создает большой толстый RDF-файл, содержащий кучу анонимных узлов и uuid. В принципе невозможно проверить функциональность всей программы с помощью простого md5, и единственным способом было бы прочитать файл с помощью ридера, а затем проверить вывод с помощью этого ридера. Как вы, вероятно, понимаете, это открывает новую банку червей: во-первых, вам нужно написать читатель (что может занять много времени), во-вторых, вы предполагаете, что читатель функционально корректен и в то же время синхронизирован с писателем. Если и читатель, и писатель синхронизированы, но исходят из неправильных предположений, читатель скажет «нет проблем», но формат файла на самом деле неправильный.

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


person Stefano Borini    schedule 09.12.2009    source источник


Ответы (2)


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

person Perry    schedule 09.12.2009

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

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

person Steve Rowe    schedule 12.12.2009
comment
Это зависит. В моем конкретном случае с файлом RDF я не могу точно знать, как объект будет сериализован в XML. Я могу замаскировать переменные части и сравнить остальные, но порядок может быть другим. Однако ваш ответ интересен. Очевидно, что тестирование MPEG-2 — это один случай. - person Stefano Borini; 12.12.2009