Test dei dati in un sistema distribuito

Recentemente ho affrontato una domanda simile. La risposta finora è stata un mix di entrambi. Alcuni dati condivisi in un unico posto, altri dati creati da componenti / test rilevanti.

Ho trovato dati condivisi e centralizzati convenienti quando riduce lo standard comune, ma è più costoso da mantenere perché deve essere riconciliato con tutti i miriadi di servizi.

I dati specializzati sono stati più adatti per i test di servizio ristretti e spesso presentano test (se non occupano troppi servizi). Le persone focalizzate sullo sviluppo o sulla sperimentazione di particolari servizi potrebbero essere più adatte a curare questi dati.

Tuttavia, con sufficiente complessità, ritengo che i dati possano meritare un'attenzione specialistica significativa, in particolare una persona o un gruppo che è almeno un po 'dedito al compito di generare dati, strumenti di dati e strategia. Questa persona / ruolo guiderebbe in particolare la storia dei dati condivisi, quando i dati sono distribuiti e i casi di utilizzo si estendono su più servizi. Se fatto bene, i dati di test e / o gli strumenti di generazione dei dati possono essere utilizzati per diverse esigenze: sviluppo, test, gestione del prodotto e dimostrazioni. Ho visto situazioni di successo in cui un reparto di automazione o di strumenti responsabile degli strumenti e dell'infrastruttura di automazione dei test è anche responsabile per i dati e gli strumenti di dati.

Tentare di eseguire il provisioning per un sistema ampiamente distribuito è una cosa difficile da fare.

Assunzione 1: non hai il controllo sui database al livello in cui puoi ripristinarli prontamente. I database di test istituzionali tendono ad essere utilizzati, spesso pesantemente, da un numero di gruppi separati di sviluppo / manutenzione. Quindi, non è possibile cancellare / ripristinare tutti i database senza un coordinamento completo.

Assunzione 2: il supporto dei responsabili dei dati di ciascun repository per il test necessario; di conseguenza, puoi chiedere a data manager di lavorare con te sui set di dati. Il gestore dati potrebbe allocare un intervallo di codici ZIP di prova, nomi utente o simili.

Assunzione 3: sei in grado di gestire i set di dati con cui stai lavorando in ogni dominio del repository. Ad esempio, in un database di contatti, potresti essere in grado di aggiungere un indirizzo di "1234 Testers Lane" o, forse "Suite CamoTester1, 1234 Birch Street" quando viene effettuato il controllo del codice postale.

Assunzione 4: è possibile stabilire associazioni chiare tra sistemi che scambiano dati. Anche se non è completamente necessario, lascerà dei buchi nei tuoi test se non riesci a sistemarlo.

Imposta i fogli di provisioning (MS Excel è tuo amico) con i fogli di lavoro per ciascun repository. Potresti finire con centinaia di casi di dati per ogni repository. Nessuno ha detto che sarebbe stato facile! Ora devi trovare un modo per i tuoi dati di non esplodere in modo combinatorio su di te - vedi ipotesi 4. Prendere i dati dal foglio 1 per il repository 1, determinare se si tratta di un source o sink per il repository 2, se ha bisogno di coordinare con repository 2. Continuare in linea.

Ho esperienza nella configurazione dei test per la connessione tra due sistemi ERP. Probabilmente, la dimensione del problema era simile a quella che stai affrontando, anche se la tua è più complessa.

Se i tuoi ambienti prod, dev e test sono separati, questo dovrebbe essere relativamente facile. Il database dovrebbe anche essere in prova, che consente di importare un set di dati noto nel database per il test. Invece di importare, puoi ripristinare un'istantanea db dal backup prima di iniziare il test.

In passato, ho raggruppato i dati di test nella suite di test delle applicazioni. Questo è un insieme di script SQL per inserire dati o un backup db da ripristinare. La mia suite di test era un progetto separato ma corrispondeva sempre alla versione dell'applicazione. Quindi, non utilizzerei i test v1.7 contro l'app v1.9, a meno che non volessi esplicitamente simulare uno scenario di aggiornamento.