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

Question

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

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

Answer 1

Единственный 100% -ный способ выяснить, являются ли два файла равными, это выполнить двоичное сравнение этих двух.

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

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

Даже алгоритм CRC-32 достаточно хорош в использовании, и в нем должно быть легко найти примеры кода в Интернете, которые его реализуют.

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

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

Answer 2

Вы должны сделать проверку CRC для каждого файла ... из вики:

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

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

Answer 3

Я бы сделал что-то вроде хэша md5sum в файлах и сравнил его с известными хэшами из релиза. Они будут более точными, чем просто сравнение даты и времени и должны быть автоматизированы.

Answer 4

Обычный способ - вычислить hash двух файлов и сравнить их. MD5 и SHA1 являются типичными алгоритмами хеширования. md5sum должен быть установлен по умолчанию на большинстве машин типа Unix, а статья md5sum Wikipedia содержит ссылки на некоторые версии Windows.

Answer 5

Хешинг очень хороший. Но другая, немного более низкая технологическая альтернатива - запустить инструмент сравнения, такой как WinMerge или TextWrangler, и сравнить две версии каждого файла. Скучно, и есть место для человеческой ошибки.

Прежде всего, используйте контроль версий, чтобы файлы, которые вы тестируете, это файлы, которые вы редактировали, и те, которые вы собираетесь запускать.У нас есть контрольные папки из нашего репо в качестве промежуточных и живых сайтов, поэтому после того, как вы внесете изменения из своей рабочей копии, вы можете быть на 100% уверены, что файлы, которые вы тестируете, нажимаете на постановку, а затем живите, одинаковы, потому что вы просто запускаете «svn update» на каждом поле и проверяете номер версии.

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