昨天我正在使用質量進行一些正式測試。在他們的程序中,他們正在驗證測試機器上的所有文件是從發佈版本中提取的。他們驗證這些文件的方式與在Windows資源管理器中查看大小和日期/時間戳窗口相同。這些碰巧是因爲我能夠找出原因的另一個原因。驗證文件以進行測試
這是驗證文件的有效方法是一樣的嗎?我不這麼認爲,並開始爭論,但我在這裏更年輕,所以認爲我不應該把它推得太遠。我想爭辯說他們應該對文件進行二進制比較來驗證其內容是否正確。根據我的經驗,時間/日期戳和尺寸屬性並不總是按預期行事。有什麼想法嗎???
昨天我正在使用質量進行一些正式測試。在他們的程序中,他們正在驗證測試機器上的所有文件是從發佈版本中提取的。他們驗證這些文件的方式與在Windows資源管理器中查看大小和日期/時間戳窗口相同。這些碰巧是因爲我能夠找出原因的另一個原因。驗證文件以進行測試
這是驗證文件的有效方法是一樣的嗎?我不這麼認爲,並開始爭論,但我在這裏更年輕,所以認爲我不應該把它推得太遠。我想爭辯說他們應該對文件進行二進制比較來驗證其內容是否正確。根據我的經驗,時間/日期戳和尺寸屬性並不總是按預期行事。有什麼想法嗎???
找出兩個文件是否相等的唯一100%方法是對二者進行二進制比較。如果你能承受誤報的風險(即兩個文件不是100%相同,但你的代碼表明它們是),那麼可以使用摘要和校驗和算法來減輕工作量,特別是如果這些文件存在於兩臺不同的機器上,帶寬不夠理想,因此二進制比較是不可行的。
摘要和校驗和算法都有誤報的機會,但確切的機會因算法而異。一般規則是,密碼越多,輸出的位越多,誤報的可能性就越小。
即使CRC-32算法的使用也相當好,應該很容易在互聯網上找到實現它的代碼示例。
如果你只做一個大小/時間戳比較,那麼我很抱歉地說這很容易規避,並且實際上不會給你很大的確定性,即這些文件是相同的或不同的。
這取決於,如果你知道在你的世界裏,時間戳是保留的,只有當文件被修改時纔會改變,那麼你可以使用它,否則它不能保證。
我會對文件執行類似於md5sum的散列操作,並將其與發行版中的已知散列進行比較。它們將比日期/時間比較更準確,並且應該能夠更加自動化。
散列非常好。但另一個稍微低一點的技術替代方法是運行像WinMerge或TextWrangler這樣的diff工具,並比較每個文件的兩個版本。無聊,有人的錯誤的空間。
最重要的是,使用版本控制來確保您正在測試的文件是您編輯的文件以及您要啓動的文件。我們的回購文件夾中有checkout文件夾作爲登臺和現場網站,因此,一旦您提交了工作副本中的更改,您可以100%確定所測試的文件,推送到現場,然後生活是相同的,因爲您只需在每個框上運行「svn update」並檢查版本號。
哦,如果你需要急匆匆地回滾(它發生在我們所有的時間或其他地方),你只需再次使用-r開關運行svn update,並立即回到以前的修訂版。
CRC-32對於相當小的文件(<128K)只有很好的海明距離,超過這個大小沒有足夠的熵可以可靠地用於文件比較。 – Epsilon 2008-10-01 03:08:02