昨天我正在与质量部门进行一些正式的测试。在他们的过程中，他们正在验证测试计算机上的所有文件是否已从发行版中删除。他们验证这些文件相同的方式是通过检查Windows资源管理器中文件的大小和日期/时间戳窗口。这些碰巧由于另一个原因而消失了，我能够找出原因。

这是验证文件相同的有效方法吗？我不这么认为，因此开始争论，但是我在这里还年轻，所以我不应该把它推得太远。我想说他们应该对文件进行二进制比较以验证其内容正确。根据我的经验，时间/日期戳和大小属性并不总是按预期方式工作。有什么想法吗？？？

解决方案

回答

我们应该对每个文件进行CRC检查...来自Wiki：

循环冗余校验，一种用于生成校验和的哈希函数，以检测传输或者存储中的错误。

它根据文件的内容产生几乎唯一的值。

回答

我会在文件上执行类似md5sum哈希的操作，并将其与发行版中已知的哈希进行比较。它们不仅比日期/时间比较更准确，而且应该能够实现更多自动化。

回答

通常的方法是计算两个文件的哈希值并进行比较。 MD5和SHA1是典型的哈希算法。默认情况下，应在大多数unix类型的计算机上安装md5sum，而Wikipedia的md5sum文章具有指向某些Windows实现的链接。

回答

找出两个文件是否相等的唯一100％方法是对两个文件进行二进制比较。

如果我们可能会遭受误报的风险(例如，两个文件不是100％相同，但代码说它们是相同的)，则摘要和校验和算法可用于减少工作量，尤其是当文件存在时两台不同的机器，它们的带宽不足最佳带宽，因此无法进行二进制比较。

摘要和校验和算法都有误报的机会，但是确切的机会会因算法而异。一般规则是，密码制得越多，输出的位数越多，误报的机会就越少。

甚至CRC-32算法也相当好用，应该很容易在实现它的互联网上找到代码示例。

如果我们仅进行大小/时间戳比较，那么很遗憾地说，这很容易绕开，实际上并不能给我们太大的确定文件相同或者不同。

但是，这取决于我们是否知道自己的世界中的时间戳会保留，并且只有在修改文件后才更改时间戳，然后才能使用它，否则就无法保证。

回答

散列非常好。但是另一种技术含量稍低的替代方法是运行诸如WinMerge或者TextWrangler之类的差异工具，并比较每个文件的两个版本。无聊，还有人为错误的余地。

最重要的是，使用版本控制来确保要测试的文件是已编辑的文件以及将要启动的文件。我们从存储库中拥有登台文件夹，作为登台站点和活动站点，因此一旦我们从工作副本中提交了更改，就可以100％确保测试的文件，推送到登台然后处于活动状态的文件是相同的，因为我们只需在每个框中运行" svn更新"并检查修订号。

哦，如果我们需要快速回滚(有时会发生在我们身上)，我们只需使用-r开关再次运行svn update并立即立即返回到以前的版本。