Domanda

Il nostro team addetto al controllo qualità desidera concentrare i propri test sulla base di ciò che EXE e DLL hanno effettivamente cambiato tra le build. Abbiamo un bel rapporto sulle modifiche svn, ma la relazione tra sorgente e binari modificati non è sempre ovvia. Le build che stiamo confrontando sono sempre build pulite, quindi non possiamo usare i timestamp del file system. Sto cercando strumenti per confrontare i binari PE di Windows (e Windows CE) che ignoreranno i timestamp incorporati e altri cruft. Qualche consiglio per strumenti o altri modi per generare un rapporto affidabile "cosa i binari sono davvero cambiati"? Grazie.

chiarimento: grazie per le risposte finora, ma non possiamo generare il rapporto facendo confronti byte-per-byte semplici o confrontando checksum, perché tutti i file appaiono diversi ogni volta che costruiamo, anche se le fonti non hanno " t modificato, a causa dei timestamp inseriti dal compilatore. Il problema è come ignorare i falsi positivi. Lo smontaggio & amp; confrontare l'idea è più vicina a ciò di cui abbiamo bisogno, penso ...

risposto! Bindiff è proprio quello che stavo cercando. Mille grazie.

È stato utile?

Soluzione

Hai dato un'occhiata a Bindiff ?

Altri suggerimenti

Ho riscontrato questo problema prima. La mia soluzione era quella di scrivere uno strumento che impostasse tutti i timestamp in un .EXE / .DLL su un valore noto. Lo eseguirò come un passaggio post-build. Quindi i diff binari funzionerebbero bene.

Potresti forse disassemblare il binario e quindi fare una differenza sull'assieme ...

Sembra che il tuo team addetto al QA stia adottando un approccio sbagliato però ... Non dovrebbe importare a loro come appare il codice; solo che fa quello che dovrebbe fare.

Modifica: Oh! Dopo averlo letto di nuovo, mi sono reso conto di aver frainteso la tua domanda. Pensavo volessero testare i metodi che erano cambiati ...

In tal caso, perché non ottenere l'hash MD5 e confrontarli? La modifica più piccola causerà la generazione di un hash totalmente diverso.

Non sei sicuro del tipo di file binari (DLL? Solo file eseguibili PE / WinCE? Altro?) È possibile incorporare le informazioni sulla versione nei file binari, ad es. utilizzando un tag di controllo del codice sorgente che aggiorna la versione nel codice sorgente durante il commit. Quindi quando viene creata la nuova build, il binario dovrebbe aggiornare anche la sua stringa di versione. Invece di dover diff un file binario, puoi usare la stringa di versione e verificarne la presenza.

Guarda NDepend .

Quando stavo lavorando su " home cresciuto " strumento per la verifica dell'installazione presso la mia azienda, abbiamo usato Beyond Compare come backend per confronto.

Ha un ottimo confronto tra file / cartelle (anche binario) e capacità di scripting e può generare report XML.

Generatore di grafici di dipendenza del progetto e Dependency-Grapher for C ++ - Progetti entrambi usano GraphViz per visualizzare le dipendenze. Immagino che potresti usare uno di essi come base per le tue esigenze con una speciale evidenziazione dei rami nel grafico delle dipendenze dove sono cambiati i file sorgente o altre foglie.

Hash o checksum MD5 (come suggerito sopra), un semplice diff che ignora gli spazi bianchi e filtra le modifiche ai commenti o che le informazioni del changlist dal sistema di controllo della versione possono segnalare quali file sono stati modificati.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top