Come posso testare file collegabili / eseguibili che richiedono re-hosting o retargeting?

1

A causa della protezione dei dati, non posso discutere i minimi dettagli del lavoro stesso quindi scuse

CASE DI PROBLEMA

A volte i miei progetti software richiedono l'integrazione / integrazione con software di terze parti (clienti o altri fornitori). questi software sono spesso in eseguibili collegabili o codice oggetto (richiede che il mio codice sorgente sia retargeted e collegato ad esso). Quando ottengo gli eseguibili o il codice oggetto, non posso validare completamente la sua operazione senza integrarla con il mio sistema.

La mia idea iniziale è che i file eseguibili non sono pensati per essere testati su unità, sono pensati per essere collegabili ad altri sistemi, ma qual è la garanzia che il post-linkage e il comportamento di integrazione andranno bene? Non è inoltre disponibile una documentazione sufficiente (dal cliente) per indicare come procedere per l'integrazione dei file eseguibili o degli oggetti.

So che questa è una domanda filosofica, ma a quanto pare non si possono trovare sufficienti ricerche in questo momento per giungere a una soluzione. Speravo che le persone potessero aiutarmi ad andare nella direzione giusta suggerendo approcci. Per iniziare, ho scoperto che il software OEM Avionics è spesso reimpostato e reindirizzato da terze parti, ad es. produttori di simulatore. Mi chiedo come li mettono alla prova. Sicuramente, il codice sorgente non verrà fornito a causa delle rgolazioni IPR.

Aggiorna

Ho ricevuto suggerimenti ragionevoli e molto utili su quest'area. La mia attuale lotta si è spostata sul test del codice OBJECT di terze parti che deve essere collegato al mio codice sorgente (retargeted) sulla mia macchina host. Come posso persino testare il codice oggetto? Sicuramente, ho bisogno di collegarli prima per pensare di fare qualsiasi cosa. È il comportamento post-link che deve essere determinato e programmato (usando perl, Tcl, ecc.) In modo che gli input e gli output possano essere verificati? Nessun indizio!! :(

grazie,

    
posta hagubear 21.06.2013 - 12:19
fonte

1 risposta

1

Tratta l'eseguibile come una scatola nera. Assicurati di disporre di un'imbracatura di test del software che puoi collegare all'eseguibile e verificare che soddisfi le tue aspettative. Quella imbracatura di test non ha bisogno di rappresentare la suite di codice completa. Ha solo bisogno di gestire i casi che ti interessano.

Guardandolo da un livello più ampio, ti è stata data una libreria che pretende di soddisfare un contratto o un'API. Devi essere in grado di verificare che l'eseguibile soddisfi il contratto nel modo che ti aspetti. Dato che non hai il codice sorgente per ispezionare visivamente l'implementazione, devi considerare qualcos'altro. Per me, questo urla per avere una suite di test di test di unità / integrazione per convalidare il comportamento.

Assumere semplicemente che l'eseguibile della scatola nera si comporti come promesso è un'assunzione folle. Se l'eseguibile è maturo, allora è una proposta meno rischiosa ma c'è ancora qualche rischio. I tuoi utenti finali / clienti non si preoccuperanno se il tuo software fallisce o se la scatola nera fallisce. Per loro, è la stessa cosa. Dal loro punto di vista, il tuo software è in errore.

Avere un'imbracatura di prova. Creare un passo nelle procedure di accettazione per eseguire nuovi eseguibili attraverso l'imbracatura. Idealmente, nulla sarà mai sbagliato. Però devo ancora vedere la situazione ideale nello sviluppo del software.

    
risposta data 21.06.2013 - 15:16
fonte

Leggi altre domande sui tag