Nel test funzionali, dovrei confrontare tutti i dati tabulari resi nel browser con quello proveniente dal DB?

Question

Sto lavorando su un piano di test per un sito web in cui alcune prove stanno prendendo il seguente percorso:

1. Hit l'URI richiesta e ottenere i dati resi all'interno di alcuni tabella (20 righe per pagina).
2. Fare una query di database per ottenere i dati che dovrebbe essere reso in tale tabella.
3. Confronto riga di dati 2 per riga, essi devono corrispondere.

E 'questo un modo corretto di fare test funzionali? Se tale richiesta era una richiesta Ajax, quale sarà anche la risposta? Se la soluzione diversa per il test di integrazione?

Ho qualche ragione che mi fa credere che questo è sbagliato in qualche modo .... ancora bisogno tue opinioni ragazzi!

Answer 1

Sì, questo potrebbe essere un test produttivo. O avete un dato fisso impostare o non fare.

Se si dispone di un set di dati fissi, questo è molto più facile da testare, perché tutto quello che stai facendo è il confronto contro un'uscita fissa.

Se non si dispone di un insieme di dati fissi, allora avete bisogno di duplicare la logica di business, duplicando in modo efficace il lavoro già svolto dallo sviluppatore. Poi ci sono due serie di logica per mantenere.

Il secondo è l'approccio migliore, perché si ottiene due modi di fare la stessa cosa, di fatto una revisione tra pari delle specifiche e il codice. E 'anche molto costoso in termini di tempo e risorse, che è il motivo per cui la maggior parte delle persone scelgono di avere un set di dati fissa.

Per rispondere alla tua domanda, se la logica di business nella query è semplice, allora si può ottenere un test molto facilmente. Tuttavia, il valore che il test porta non è grande, perché non sta testando molto.

Se la logica di business è complesso, si sono sempre più valore dalla prova, ma che sta per essere più difficile da mantenere nel lungo termine.

Per quanto mi riguarda, ciò che il vostro test non portare è un test di integrazione semplice che dimostra che il sistema legge correttamente dal database, e visualizza correttamente i dati. Questo è un buon test, meglio ancora se è automatizzato.

Answer 2

Questo sembra che vada bene per i test funzionali. test di integrazione nella mia mente ha a che fare con la sperimentazione di diverse tecnologie o componenti che dovrebbero lavorare insieme che è generalmente più ampia di test funzionali. Ma, naturalmente, questo tipo di test potrebbe anche essere presa in considerazione test di integrazione, a seconda di come l'applicazione è mettere insieme e dove la sperimentazione sta accadendo nel ciclo di vita del vostro sviluppo. Per esempio può essere che in ordine per questo sito per lavorare devi mettere insieme un paio di componenti che sono stati sviluppati in modo indipendente; questo potrebbe essere uno dei test per verificare che l'integrazione funziona.

Non vedere come questo sia l'Ajax o non ha nulla a che fare con fare la risposta diversa.

Answer 3

I sarà probabilmente un parere dissenziente qui, ma non ritengo che questo sia un test produttivo. Quello che state facendo è semplicemente duplicare il codice che produce la pagina. E ogni volta che si introduce codice duplicato (anche tra i reparti) sarete alla ricerca di difetti a saltar fuori a lungo termine.

E 'molto meglio per caricare il DB con i dati noti (sia attraverso l'applicazione, o direttamente) e quindi controllare che l'uscita corrisponde a quello che ci si aspetterebbe. Questo assicura anche che il livello DB o DB per sé, non ha modificato i dati in un modo che non ti aspetti.

Cioè:

1. carico noto dati (preferibilmente tramite l'applicazione stessa)
2. Caricare l'URI richiesto
3. Verificare che i dati visualizzati corrisponde alla tua dati noti

Answer 4

Questo tipo di test potrebbe essere buono per testare un ampio insieme di dati con relativamente poco sforzo tester, se non c'è una logica molto sviluppatore tra il database e il display per l'utente finale. Il nostro team ha fatto questo su una serie di occasioni, ed è particolarmente utile per l'esecuzione di grandi quantità di dati di produzione reali attraverso i nostri test per essere sicuri che gli scenari attuali sono gestite come previsto. Non dimenticate di fare almeno un po 'di ingresso fissa test per gli scenari rari che potrebbero essere particolarmente suscettibili di essere gestita in modo diverso nel DB e sulla pagina web - i valori nulli, caratteri speciali e altre stranezze.

Personalmente, vorrei chiamare questo "test di integrazione", dal momento che si sta testando l'integrazione del DB e il sito web, e non "testing funzionale". Per "testing funzionale", probabilmente sarei voglio fare un mock del origine dati (ad esempio, il database) che fornirà set di pre-scritto dei dati nel formato che ci si aspetta.

Dopo aver detto che, se avessi alta fiducia nella validità dei dati di DB e se la logica tra la query DB e la visualizzazione della pagina web era molto piccola e basso rischio, probabilmente, non perdete tempo con la finta e sarebbe lasciare che il test di integrazione coprire la funzionalità pure. Non so che testare la funzionalità e l'integrazione separatamente sarebbe una vittoria grande qualità in questo caso, e ci sono cose che probabilmente meglio si potrebbe fare con il tempo di test a disposizione. Se c'è un sacco di logica in tutto questo dato, probabilmente si dovrebbe verificare l'integrazione separatamente dalla funzionalità. Ulteriori test di integrazione sarebbe probabilmente includere cose come, "E se il database non può essere raggiunto?" e "Che cosa succede se il database è lento?".

Mentre questa tecnica funziona con l'Ajax, assicurarsi che i strumenti di test lavoreranno con l'Ajax. In particolare, pensare a come si catturare i risultati della query di database e come si intende raccogliere i risultati visualizzati sulla pagina web.

Sto assumendo che la validità dei dati nella query viene testato altrove, dal momento che lei ha detto che questo era solo un tipo di test nel piano di prova. Sto anche solo discutere l'integrazione con il database e questo rapporto e non le altre caratteristiche o componenti, e non anche per altri aspetti di test (prestazioni, sicurezza ecc.), Dal momento che che è stato l'ambito della tua domanda.