Come affrontare la scrittura di un 'test' per una serie di insiemi di input-output, che verranno successivamente utilizzati per verificare la correttezza di un nuovo sistema?

Question

Come affrontare la scrittura di un 'test' per una serie di insiemi di input-output, che verranno successivamente utilizzati per verificare la correttezza di un nuovo sistema?

#1 da (3 voti)

-1

Ho un sistema ("un motore", che è un pezzo di codice) che accetta diversi parametri restituisce un po 'di output. I parametri di input sono diversi set distinti e vincolati. Posso enumerarli tutti (attualmente 1064 insiemi di input) ed eseguirli attraverso il motore per produrre lo stesso numero di output.

Il codice del motore verrà sostituito da un nuovo sistema, la cui codifica proviene da un reparto diverso. Lo scopo del test è di registrare e memorizzare la mappatura originale dell'input in uscita, e una volta che il motore è stato sostituito, rieseguire il test con il nuovo motore in posizione.

Sto avendo qualche problema nel capire come affrontarlo. È un "test unitario"? dovrebbe essere trattato come un test unitario? (Penso che sia quello che sto cercando di lanciare come se avesse problemi). Dovrebbe essere un "modulo" separato del codice? Dovrebbe essere uno script one-off che eseguo?

Poiché ci sono molti mapping di input e gt; probabilmente dovrò creare una tabella di database per il test e archiviare i risultati nella tabella.

Domanda:

Sto cercando un framework di test o un approccio a questo tipo di "test" che prima mi aiuterà a memorizzare "ciò che è previsto", e poi, in un momento molto diverso, testerò se il nuovo sistema si attiene al aspettative.

Oppure, potrei anche eseguire entrambi i sistemi contemporaneamente e confrontare i risultati in questo modo, probabilmente non sarà necessario memorizzare temporaneamente i risultati in questo caso. Tuttavia, nel mio caso il nuovo motore non è ancora pronto, quindi non posso fare riferimento ad entrambi contemporaneamente, poiché è disponibile solo il vecchio motore.

testing unit-testing php phpunit

posta Dennis 20.12.2017 - 17:45

fonte

1 risposta

Leggi altre domande sui tag testing unit-testing php phpunit

Salvataggio di set nei campi del database [duplicato] Hosting di un sito Web statico contenente JavaScript / jQuery

score 3 · Accepted Answer

Stai provando a preparare un test di regressione , per assicurarti che la nuova implementazione mostri il comportamento esistente.

Come metodo di test, un test end-to-end del tuo componente sembra essere quello che stai cercando di fare. È possibile memorizzare tutti i casi di test in un database. Nella mia esperienza, l'utilizzo di file di testo semplice è migliore, perché possono essere facilmente condivisi, inviati via email e controllati dalla versione. Questi file descrivono l'input e registrano le uscite, ad es. come documento JSON, YAML o XML.

Avresti quindi un test driver, che è un piccolo programma che legge il file del test case, fa girare il motore con gli input e confronta le uscite. In seguito è possibile reimplementare lo stesso driver di test per il nuovo motore o rendere configurabile il driver di prova.

Una volta che hai entrambi i motori, dovresti far funzionare entrambi i motori in parallelo per un po '. Entrambi sono alimentati tutti gli input di produzione del mondo reale. Se c'è una discrepanza, si registrano gli ingressi e le due uscite e la si rivede manualmente. Questa fase tende a scoprire molti bug nella vecchia implementazione, quindi la nuova implementazione potrebbe produrre un output "più corretto". Inizialmente preferirai continuare a utilizzare le uscite del vecchio motore. Dopo un po 'sarai abbastanza sicuro per passare al nuovo motore.

Il tuo spazio di input è probabilmente troppo grande per essere testato in modo esauriente (supponendo che siano 1064 variabili indipendenti, non solo 1064 valori di input). Pertanto, sarà necessario generare esempi. Un'ottima strategia consiste nel registrare gli input dalla produzione, disinfettarli / renderli anonimi e utilizzarli come test case. Tuttavia, questo non accetterà casi limite interessanti. In base agli esempi registrati, a eventuali specifiche o casi di test esistenti e in base all'input degli esperti del dominio, costruisci manualmente i casi di test per scenari importanti che non sono stati osservati durante la registrazione.