Quali sono le migliori pratiche per la gestione dei risultati dei test

I risultati del test devono essere gestiti nello stesso repository git. Non è necessario salvare i risultati di ogni corsa, è sufficiente salvare i risultati per una singola corsa. Tutte le altre esecuzioni dovrebbero confrontarsi con questa versione "dorata" dei dati. Se un test genera risultati diversi, avrà esito negativo.

In altre parole, questo file .csv non è un output di test, è un input di test. Generalo una volta, quindi i tuoi test dovrebbero usarlo per convalidare se il sistema attuale funziona come dovrebbe. Poiché si tratta di un input, deve essere controllato in base alla versione come qualsiasi altro asset di test.

Quando esegui i test, puoi creare un rapporto giornaliero che mostra solo i guasti. Non sarebbe necessario archiviarlo a meno che non sia necessario fare analisi sulla frequenza in cui determinati test falliscono o superano.

Dalla tua domanda:

We want to be able to keep a record of these test results, so we can go back and run the same test again with the same Inputs and verify the results – @user3711455

Dal tuo commento:

The .CSV changes daily. The test script's input is the output of a legacy system. It takes that, gets equivalent data from New system, and then compares to see if they both match. Resulting with a CSV that has: Legacy System Results, New System Results Total Differences: – @user3711455

Questi non sono lo stesso test. Eseguire lo stesso test, con gli stessi input, contro lo stesso codice dovrebbe essere un esercizio ridondante. Se ciò non produce sempre lo stesso risultato hai permesso la magia nel tuo sistema.

Questo è utile solo per verificare che non stia accadendo nulla di magico. Più tipicamente riesegui questi test assicurandoti che solo una cosa sia cambiata. Di solito il codice refactored. In questo modo quando il test si rompe sai cosa incolpare, l'unica cosa che è cambiata.

L'esecuzione di due sistemi affiancati alla duplicazione del lavoro per il confronto non è un test. È un sistema di voto. Quando non sono d'accordo, devi decidere a chi credere. Il sistema legacy non dovrebbe essere considerato affidabile per essere perfetto per quanti anni ha sotto la cintura. In effetti, più è vecchio il più probabile che alcuni errori facciano così bene che tutti li ignorano da quando sono attesi e potrebbero non averti mai detto a nessuno di loro, dato che tutti lo sanno. Potresti ricavarne un valore in tal senso, a dimostrazione che il nuovo sistema è pronto per la transizione, ma questi non sono test poiché richiedono che il vecchio sistema esista.

Tuttavia, immetti l'input nel vecchio sistema e registra l'output e disponi di un output di base. Ma solo per quell'input e solo per quella versione del sistema legacy. Che si spera non sia bacato da solo. Da questo puoi costruire un test sul nuovo sistema. Ma se i tuoi input non esercitano ogni caso d'uso e ogni bit di codice, speri solo di essere fortunato.

Se, come sospetto, il tuo custom written test cases che causa i casi di test a change daily sta semplicemente facendo funzionare entrambi i sistemi dallo stesso feed di input operativo, non ho molta fiducia che tu abbia una buona copertura del codice .

Se, tuttavia, il tuo input viene modificato manualmente per esercitare diverse parti del tuo codice, allora quegli input e il codice che automatizza il test e il confronto dei loro output dovrebbero essere organizzati in maniera strutturalmente simile al codice che testano in questo modo che è molto facile navigare da uno all'altro. Fallo e mantieni la versione controllata e avrai un bel sistema di sviluppo.

Sebbene risponda a una domanda diversa, ritengo la mia risposta a una domanda sull'archiviazione dei risultati dell'analisi statica può essere utile anche qui.

Devi controllare la versione dei test case e l'input del test. Data una versione del software, dovresti essere in grado di riprodurre esattamente i test che hai eseguito e i dati di input associati in quel momento. Tuttavia, potresti anche voler eseguire test più recenti sul codice precedente. Mantenere i tuoi test (codice di test, dati di test di input, procedure di test) nel tuo sistema di controllo della versione e taggarli è essenziale.

Una volta che sei in grado di eseguire nuovamente gli stessi test con gli stessi dati su un'istantanea del software in qualsiasi momento, non penso sia necessario conservare tutti i risultati del test.

Se senti la necessità di rendere disponibili alcuni dati, puoi raggruppare i risultati del test come parte di una versione ufficiale. Se si includono i risultati del test, è possibile vedere come si desidera impacchettarlo, inclusi tutti i risultati e i risultati del test o scrivere un rapporto di riepilogo che descriva i risultati del test.

Utilizziamo tre tipi di test:

• Il selenio
• NUnit
• Interfaccia utente del sapone

Tutti questi producono file di risultati (XML). Per i test Selenium, si tratta di flussi di alto livello, quindi inviamo un'email a un gruppo che può visualizzare i risultati poiché sono meno di 10. Questi sono test di verifica tecnici (test fumo). L'XML viene convertito in HTML e inserito nell'e-mail.

Per i test dell'interfaccia utente nUnit e SOAP, abbiamo 100 se non 1000. Entrambi questi test producono file XML che sono formati di risultati di test nUnit. Da lì, forniamo questi risultati a una semplice pagina Web (Unità di rapporto) che converte l'XML e quindi inserisce i risultati in una pagina Web.

Non ci interessano i risultati passati, ma è possibile inserire ogni "esecuzione" in una cartella di archivio per la revisione, ma i risultati di alcuni giorni fa sono obsoleti dal nostro punto di vista e potrebbero non essere più validi se ci sono molte modifiche al codice. Questi risultati vengono inviati a un monitor (TV) in modo che l'intero team possa vedere lo stato dei test. I test che diventano rossi vengono esaminati e risolti.

I meccanismi per produrre i risultati sono sotto il controllo del codice sorgente, ma i risultati effettivi stessi non sono nel controllo del codice sorgente.

La migliore pratica consente a uno sviluppatore di eseguire la suite di test da una nuova copia di lavoro senza dipendenze esterne.

Il tuo scenario sembra già divergere dal tipico scenario di test. Ma, ciò che probabilmente significa per te è la memorizzazione dei risultati "target" nel repository. Il tuo strumento di test non dovrebbe memorizzare i suoi risultati immediati ovunque; dovrebbe confrontare i risultati immediati con i risultati "target" per la convalida e segnalare singoli guasti.

Da lì, ogni singolo errore dovrebbe spingere lo sviluppatore a o correggere il bug o convalidare la modifica dei requisiti e regolare il "target" "dati di conseguenza prima di iniziare.