어제 정식 테스트를 수행하면서 품질과 관련하여 작업 중이었습니다. 테스트 과정에서 테스트 머신의 모든 파일이 릴리스에서 제거되었는지 확인했습니다. Windows 탐색기에서 크기 및 날짜/시간 스탬프 창을 확인하여이 파일을 확인하는 방식이 동일했습니다. 이것들은 내가 왜 그 이유를 발견 할 수 있었는지 또 다른 이유 때문에 사라졌습니다.테스트 용 파일 확인
파일을 확인하는 올바른 방법입니까? 나는 그렇게 생각하지 않고 논쟁하기 시작했다. 그러나 나는 여기에서 더 젊다. 그래서 나는 너무 멀리 밀지 말아야한다고 생각했다. 필자는 내용이 정확한지 확인하기 위해 파일에서 이진 비교를 수행해야한다고 주장하고 싶었습니다. 내 경험상 시간/날짜 스탬프 및 크기 특성이 항상 예상대로 작동하지는 않습니다. 이견있는 사람???
두 파일이 동일한 지 알아내는 유일한 100 % 방법은 두 파일을 이진 비교하는 것입니다.
가양 성 (false positive)의 위험 (예 : 100 % 동일하지 않지만 코드에 있음을 나타내는 두 파일)으로 살아갈 수 있으면 다이제스트 및 체크섬 알고리즘을 사용하여 작업을 줄입니다. 특히 파일은 2 진 비교가 실행 불가능하도록 최적 대역폭보다 적은 두 개의 다른 시스템에 있습니다.
다이제스트 및 체크섬 알고리즘은 모두 오탐 (false positive) 가능성이 있지만 정확한 기회는 알고리즘에 따라 다릅니다. 일반적 규칙은 암호화 된 암호가 많을수록 출력량이 많을수록 거짓 긍정의 가능성이 적어집니다.
심지어 CRC-32 알고리즘을 사용하는 것이 좋으며 코드 예제를 구현하는 인터넷에서 코드 예제를 쉽게 찾을 수 있어야합니다.
크기/타임 스탬프 비교를 수행하는 경우 이는 쉽게 회피 할 수 있으며 파일이 동일하거나 다른 확실성을 실제로주지는 못합니다.
세상에서 타임 스탬프가 보관되어 있고 파일이 수정되었을 때만 변경된 다음 사용할 수 있습니다. 그렇지 않으면 보장 할 수 없습니다.
각 파일에 CRC 체크를해야 ... 위키에서 :
, 위해, 체크섬을 생성하는 데 사용되는 해쉬 함수의 종류는 전송 또는 저장에서의 오류를 감지 할 수 있습니다.파일의 내용에 따라 거의 고유 한 값을 생성합니다.
파일에 md5sum 해시를 사용하고 릴리스의 알려진 해시와 비교합니다. 날짜/시간 비교보다 정확하며 더 자동화 될 수 있어야합니다.
해싱이 매우 좋습니다. 그러나 약간 다른 기술 대안은 WinMerge 나 TextWrangler와 같은 diff 도구를 실행하고 각 파일의 두 버전을 비교하는 것입니다. 지루하고 인간적인 실수를위한 여지가 있습니다.
가장 중요한 것은 버전 관리를 사용하여 테스트중인 파일이 편집 한 파일과 실행하려는 파일인지 확인하십시오.저장소에있는 체크 아웃 폴더를 스테이징 및 라이브 사이트로 사용할 수 있으므로 작업 복사본의 변경 내용을 커밋하면 테스트 할 파일을 준비하고 스테이징 한 다음 살 수 있다는 것을 100 % 확신 할 수 있습니다. 각 상자에서 "svn update"를 실행하고 개정 번호를 확인하십시오.
아, 서둘러 롤백해야하는 경우 (우리 모두에게 언젠가는 발생합니다) -r 스위치를 사용하여 svn update를 다시 실행하고 거의 즉시 이전 버전으로 돌아갑니다.
CRC-32는 파일 크기를 비교할 때 엔트로피가 충분하지 않은 비교적 작은 파일 (<128K)에 대해서만 좋은 해밍 거리를 가지고 있습니다. – Epsilon