Isolamento dei dati di test nei test di accettazione

5

Sto cercando una guida su come mantenere isolati i miei test di accettazione. In questo momento il problema che sto avendo con la possibilità di eseguire i test in parallelo sono i record del database che vengono manipolati nei test. Ho scritto degli helper che si occupano di fare inserimenti ed eliminazioni prima dell'esecuzione dei test, per assicurarsi che lo stato sia corretto. Ma ora non posso eseguirli in parallelo sullo stesso database senza generare in modo univoco i campi dei dati di test per ogni test. Ad esempio.

Provando a creare una riga cancellerò tutto dove colonna A = pippo e colonna B = barra Quindi passerò attraverso l'interfaccia utente nel test e creerò un record con la colonna A = foo e la colonna B = bar.

Verifica che non sia possibile creare una riga duplicata. Inserirò una riga con la colonna A = foo e la colonna B = bar e quindi userò l'interfaccia utente per provare a fare esattamente la stessa cosa. Ciò visualizzerà un messaggio di errore nell'interfaccia utente come previsto.

Questi test funzionano perfettamente quando sono eseguiti separatamente e in serie. Ma non posso eseguirli allo stesso tempo per paura che si crei o si elimini un record che l'altro si aspetta. Qualche consiglio su come strutturarli meglio in modo che possano essere eseguiti in parallelo?

    
posta Matt Phillips 06.11.2012 - 03:16
fonte

2 risposte

9

Suona personalmente come se i tuoi test di accettazione comprendessero le proprietà dei test di integrazione e che tu stia cercando di "uccidere due piccioni con una fava" come dice il proverbio.

Nel modello tradizionale a cascata un singolo test di accettazione dovrebbe determinare se un singolo requisito è stato soddisfatto. Se si sviluppa in base a un rigoroso documento SRS, è possibile che anche la convalida dell'input di base sia definita in modo esplicito e in base alla natura del test di accettazione deve essere testato manualmente per essere verificato.

Nel modello Agile, tuttavia, i Test di accettazione verificano una singola storia utente, un test di alto livello per verificare l'esigenza di un alto livello degli stakeholder dell'utente. In genere, nel modello Agile, è necessario comprendere il controllo e le specifiche a grana fine su aspetti quali la convalida dell'input, a meno che tale convalida non sia univoca o specifica per le esigenze aziendali.

In ogni caso, nell'esempio in cui si desidera verificare che un record duplicato non sia stato inserito in un database è di gran lunga troppo basso per un utente, si potrebbe dire che è uno spreco di tempo prezioso per elevarsi al importanza di un test di accettazione. La garanzia di qualità o il tester per tale funzione dovrebbero essere in grado di verificare che il requisito di alto livello sia stato rispettato senza difetti evidenti.

I tuoi test devono essere suddivisi:

Test unità automatizzati

Per i test di livello più basso, tipicamente scritti e eseguiti dallo sviluppatore per verificare tutte le funzionalità di uno specifico componente o livello di applicazione a parte, indipendente di altre aree di l'applicazione e riproducibile da eseguire più volte.

Test di integrazione

Questi test, come i test unitari, possono verificare situazioni come la creazione di un nuovo record Persona, su tutti i livelli di sistema, la verifica dell'integrazione di tutte le dipendenze dell'applicazione mentre si verifica che la creazione di un nuovo record Persona o la creazione di un record Persona duplicato venga creato correttamente.

Il caso per i test di integrazione

Uno degli aspetti più importanti di questo tipo di test è che le loro sono varie strategie non solo per Automatizzare questi test, ma possono anche utilizzare le transazioni del database per farle funzionare in parallelo e non in conflitto, e anche questa transazione di database può essere ripristinata quando il test ha terminato di riportare il database su una lavagna pulita e renderlo riproducibile .

Considero che sulla base della tua domanda la maggior parte dei tuoi "Test di accettazione" non sono terribilmente interessanti e sarebbero meglio automatizzati. Questo non vuol dire che il test di accettazione non dovrebbe verificarsi, ma dovrebbe essere fatto su un livello molto più elevato a dove questi problemi non sono più importanti.

    
risposta data 06.11.2012 - 03:58
fonte
0

In Intelliware, utilizziamo lo "home state switching" per risolvere questo problema. Abbiamo un framework sviluppato internamente chiamato Runway che astrae la complessità, ma ecco come funziona in poche parole:

  1. All'avvio di un test, fa in modo che una chiamata remota a un controller di stato home ottenga un database da utilizzare per il test.
    1. Il controller dello stato iniziale crea un nuovo database dagli script, o ne usa uno dal pool di homestates disponibili (creati, ma non attualmente in uso)
    2. L'UUID univoco viene restituito al test
  2. Il test include l'UUID come intestazione su tutte le richieste
  3. Il system-under-test rileva l'intestazione UUID e instrada tutte le chiamate al database sul db di test. Ecco come si ottiene la parallelizzazione: richieste diverse vengono indirizzate a database diversi a seconda dell'intestazione.
  4. Al suo completamento, il test restituisce il database al "pool disponibile".

Questo approccio dipende dalla possibilità di avviare nuovi schemi di database in modo rapido e affidabile. Solitamente utilizziamo Flyway per questo, ma alla fine potrebbe essere necessario esportare un'istantanea se la migrazione inizia a richiedere molto tempo.

Il summenzionato controller dello stato di casa è un'applicazione web leggera e autonoma che non viene mai distribuita all'esterno di un ambiente di test.

Vedi anche

risposta data 15.06.2015 - 17:25
fonte

Leggi altre domande sui tag