Sono unit test e le prove di accettazione abbastanza?

Question

Se ho unit test per ogni classe e/o di un membro di funzione e test di accettazione per ogni user story, non ho abbastanza prove per garantire che il progetto funzioni come dovrebbe?

Per esempio se ho unit test e le prove di accettazione per una caratteristica non ho ancora bisogno di test di integrazione o l'unità e test di accettazione coprire la stessa terra?C'è sovrapposizione tra i tipi di test?

Sto parlando di test automatizzati qui.So di test manuale è ancora necessario per cose come facilità di utilizzo, etc.

Answer 1

Mi raccomando di leggere i capitoli 20 - 22 nella 2 ° edizione del codice completo . Copre la qualità del software molto bene.

Ecco una rapida ripartizione di alcuni dei punti chiave (tutto il merito va a McConnell, 2004)

Capitolo 20 - Il Software-qualità del paesaggio:

• Nessuna singola tecnica di difetti di rilevamento è completamente efficace di per sé
• La prima si trova un difetto, meno intrecciate che diventerà con il resto del codice e meno danni che causerà

Capitolo 21 - costruzione collaborativa:

• pratiche di sviluppo di collaborazione tendono a trovare una più alta percentuale di difetti di test e di trovare in modo più efficiente
• pratiche di sviluppo di collaborazione tendono a trovare diversi tipi di errori rispetto test fa, il che implica che è necessario utilizzare entrambe le recensioni e test per garantire la qualità del software
programmazione
• pari tipicamente costa lo circa lo stesso come ispezioni e produce codice di qualità simile

Capitolo 22 - Developer Testing:

• testing automatizzato è utile, in generale, ed è essenziale per test di regressione
• Il modo migliore per migliorare il vostro processo di test è quello di rendere regolare, misurarlo, e utilizzare ciò che si impara per migliorarlo
• scrittura casi di test prima che il codice ha la stessa quantità di tempo e fatica, come scrivere i casi di test dopo il codice, ma si accorcia il debug di correzione cicli difetto di rilevamento-(Test Driven Development)

Per quanto riguarda come si stanno formulando il test di unità, si dovrebbe considerare il test base, l'analisi del flusso di dati, l'analisi di confine ecc Tutti questi sono spiegati in dettaglio nel libro (che comprende anche molti altri riferimenti per ulteriori letture ).

Forse questo non è esattamente quello che stavi chiedendo, ma direi test automatici non è sicuramente abbastanza di una strategia. Si dovrebbe anche prendere in considerazione cose come pair programming, revisioni formali (o giudizi informali, a seconda delle dimensioni del progetto) e test di ponteggi con il vostro test automatizzati (unit test, test di regressione, ecc.).

Answer 2

  

Se devo unit test per ogni test di funzionalità e di accettazione di classe e / o dei membri per ogni storia utente devo abbastanza prove per garantire le funzioni di progetto come previsto?

No. I test possono verificare solo quello che hai pensato. Non quello che non hai pensato.

Answer 3

L'idea di molteplici cicli di test è quello di catturare i problemi il più presto possibile quando le cose cambiano.

I test unitari dovrebbe essere fatto dagli sviluppatori per garantire il lavoro unità di in isolamento .

Prove di accettazione dovrebbe essere fatto dal cliente al fine di garantire il sistema soddisfa i requisiti.

Tuttavia, qualcosa è cambiato tra questi due punti che dovrebbero anche essere testati. Questo è l'integrazione di unità in un prodotto prima di essere dato al cliente.

Questo è qualcosa che deve prima essere testato dal creatore del prodotto, non il cliente. Nel momento in cui invlove il cliente, le cose rallentare in modo che i più correzioni si può fare prima che arrivino le loro piccole mani sporche su di esso, il migliore.

In un grande negozio (come la nostra), ci sono test di unità, test di integrazione, test di globalizzazione, master-costruire test e così via in ogni punto dove i consegnabili modifiche di prodotto. Solo una volta tutti i bug di gravità elevate sono fissi (e un piano per correggere i bug a bassa priorità è a posto) possiamo liberare il prodotto ai nostri clienti beta.

fare non vogliamo dare loro un prodotto rischioso, semplicemente perché la fissazione di un bug in questa fase è molto più costoso (soprattutto in termini di administrivia) di qualsiasi cosa che facciamo in casa.

Answer 4

E 'davvero impossibile sapere se non si dispone di prove sufficienti basati semplicemente su se si dispone di un test per ogni metodo e funzionalità. In genere io combinare il test con l'analisi di copertura al fine di garantire che tutti i miei percorsi di codice sono esercitati in mio test di unità. Anche questo non è davvero sufficiente, ma può essere una guida a dove si può avere il codice introdotto che non è esercitato dai test. Questo dovrebbe essere un'indicazione che più test devono essere scritto o, se si sta facendo TDD, è necessario rallentare e essere più disciplinati. : -)

I test dovrebbero coprire entrambi i percorsi positive e negative, specialmente in unit test. I suoi test di accettazione possono essere più o meno interessati con il comportamento percorso male, ma dovrebbe almeno affrontare gli errori comuni che possono essere fatte. A seconda di come completare le vostre storie sono, le prove di collaudo possono essere o non essere sufficiente. Spesso v'è una relazione molti-a-uno tra i test di accettazione e storie. Se si dispone di un solo test di accettazione automatizzati per ogni storia, probabilmente non si hanno abbastanza se non si ha storie diverse per percorsi alternativi.

Answer 5

Gli strati multipli di test possono essere molto utili. unit test per assicurarsi che i pezzi si comportano; integrazione per dimostrare che i gruppi di cooperanti unità cooperano come previsto, test "accettazione" per indicare che le funzioni del programma come previsto. Ciascuno può cogliere problemi durante lo sviluppo. Sovrapposizione per se non è una brutta cosa, ma troppo di esso diventa rifiuti.

Detto questo, la triste verità è che non si può mai garantire che il prodotto si comporta "come previsto", perché aspettativa è un volubile, cosa umana che viene tradotto molto male su carta. Buona copertura di test non impedirà un cliente dal dire "che non è proprio quello che avevo in mente ...". anelli di retroazione frequenti aiuto là. Considerare demo frequenti come un "test di sanità mentale" per aggiungere al vostro mix manuale.

Answer 6

Probabilmente no, a meno che il software è davvero, davvero semplice e ha un solo componente.

I test unitari sono molto specifici, e si dovrebbe coprire tutto accuratamente con loro. Andare per alta code-coverage qui. Tuttavia, essi coprono solo un pezzo di funzionalità alla volta e non come funzionano le cose insieme. Prove di accettazione dovrebbero coprire solo ciò che il cliente ha veramente a cuore a un livello elevato, e mentre si cattura alcuni bug nel modo in cui funzionano le cose insieme, non prenderà tutto come la persona che scrive tali test non sapere sul sistema in profondità.

La cosa più importante, questi test non possono essere scritti da un tester. I test unitari dovrebbero essere scritti dagli sviluppatori e molto frequenti (fino a ogni paio di minuti, a seconda della codifica stile) per gli sviluppatori (e dal sistema di compilazione anche, idealmente). Prove di accettazione sono spesso scritti da parte del cliente o qualcuno per conto del cliente, pensando a ciò che conta per il cliente. Tuttavia, è necessario anche prove scritte da un tester, a pensare come un tester (e non come un dev o cliente).

Si dovrebbe anche prendere in considerazione i seguenti tipi di test, che sono generalmente scritti da tester:

• I test funzionali, che copriranno pezzi di funzionalità. Ciò può includere una sperimentazione API e test a livello di componente. Si vuole in generale buon codice-coverage anche qui.
• test di integrazione, che ha messo insieme due o più componenti per assicurarsi che lavorano insieme. Se non si desidera un componente di mettere la posizione dell'array in cui l'oggetto è (0-based), quando l'altro componente si aspetta che il numero dell'oggetto ( "oggetto ennesima", che è basata su 1), per esempio. Qui, l'attenzione non è sulla copertura del codice, ma sulla copertura delle interfacce (interfacce generale, non interfacce di codice) tra i componenti.
• testing a livello di sistema, dove si mette tutto insieme e assicurarsi che funzioni end-to-end.
• di prova per funzioni non funzionali, come prestazioni, affidabilità, scalabilità, sicurezza e facilità d'uso (ce ne sono altri, non tutti saranno in relazione ad ogni progetto)
.

Answer 7

test di integrazione sono per quando il codice si integra con altri sistemi come applicazioni 3rd party, o altri in casa sistemi quali l'ambiente, database, ecc Utilizzare i test di integrazione per garantire che il comportamento del codice è ancora come previsto.

Answer 8

In breve no.

Per cominciare, le tue carte storia dovrebbe avere criteri di accettazione. Cioè, i criteri di accettazione specificati dal proprietario del prodotto in collaborazione con l'analista che specifica il comportamento richiesto e se si incontrano, sarà accettata la carta di storia.

I criteri di accettazione devono guidare il test automatico dell'unità (fatto via TDD) ei test automatizzati regressione / funzionali che devono essere eseguiti giornalmente. Ricordate che vogliamo spostare i difetti a sinistra, vale a dire, prima troviamo ‘em il più economico e più veloce sono da risolvere. Inoltre, test continuo ci permette di refactoring con fiducia. Questo è necessario per mantenere un ritmo sostenibile per lo sviluppo.

Inoltre, è necessario di test automatizzato delle prestazioni. Esecuzione di un profiler quotidiana o durante la notte fornirebbe comprensione del consumo di CPU e memoria e la presenza di eventuali perdite di memoria. Inoltre, uno strumento come LoadRunner vi permetterà di mettere un carico sul sistema che riflette l'utilizzo effettivo. Sarete in grado di misurare i tempi di risposta e della CPU e il consumo di memoria sulla produzione come la macchina LoadRunner in esecuzione.

Le prove di certificazione automatizzata deve riflettere l'effettivo utilizzo delle app. Si misura il numero di transazioni commerciali (vale a dire, se un'applicazione web il clic su una pagina e la risposta agli utenti o di andata e ritorno al server). e determinare il mix di tale operazione con il Reate arrivano al secondo. Tali informazioni vi permetterà di progettare correttamente il test automatizzato LoadRunner necessario per testare le prestazioni dell'applicazione. Come spesso accade, alcuni dei problemi di prestazioni si risalire alla implementazione dell'applicazione mentre altri saranno determinati dalla configurazione dell'ambiente server.

Ricordate, la vostra domanda verrà prestazioni testato. La domanda è, sarà il primo test delle prestazioni accadere prima o dopo il rilascio del software. Mi creda, il posto peggiore di avere un problema di prestazioni è in produzione. Problemi di prestazioni possono essere più difficili da correggere e possono causare un schierati a tutti gli utenti di fallire così l'annullamento del progetto.

Infine, c'è User Acceptance Testing (SVS). Questi sono test inteso da parte del partner proprietario / attività di produzione per testare il sistema nel suo complesso prima del rilascio. In genere, per tutti gli altri test, non è raro per l'applicazione per restituire zero difetti durante SVS.

Answer 9

Dipende da come complesso il sistema è. Se non i test di accettazione (che soddisfano le esigenze dei clienti) esercitare il vostro sistema da davanti a dietro, allora non si fa.

Tuttavia, se il prodotto si basa su altri livelli (come backend middleware / database), allora avete bisogno di una prova che dimostra che il vostro prodotto può tranquillamente collegarsi end-to-end.

Come altre persone hanno commentato, test non necessariamente dimostrano le funzioni di progetto come previsto, proprio come ci si aspetta che funzioni.

frequenti feedback loop per il cliente e / o prove che sono scritti / analizzabile in modo il cliente capisce (diciamo per esempio in un BDD stile ) può davvero aiutare.

Answer 10

Se ho unit test per ogni classe e/o funzione membro e l'accettazione le prove per ogni user story devo abbastanza prove per garantire che il progetto funzioni come dovrebbe?

Questo è sufficiente per mostrare il vostro software è funzionalmente corretto, almeno quanto la copertura del test è sufficiente.Ora, a seconda di ciò che si sta sviluppando, sicuramente ci sono i requisiti non funzionali che importa, pensare di affidabilità, prestazioni e scability.

Answer 11

Tecnicamente, un abito pieno di prove di collaudo dovrebbe coprire tutto. Detto questo, non sono "abbastanza" per la maggior parte delle definizioni di sufficienza. Avendo unit test e test di integrazione, si può prendere problemi / bug prima e in modo più localizzato, che li rende molto più facile da analizzare e correggere.

Si consideri che una tuta completa di test eseguiti manualmente, con le istruzioni scritte sulla carta, sarebbe sufficiente per verificare che tutto funzioni come previsto. Tuttavia, se è possibile automatizzare i test, si sarebbe molto meglio perché rende lo svolgimento di sperimentazioni che molto più facile. La versione cartacea è "completa", ma non "abbastanza". Allo stesso modo, ogni strato di test aggiungere di più per il valore di "abbastanza".

È anche interessante notare che i diversi set di test tendono a testare il prodotto / codice di un "punto di vista" diverso. Più o meno allo stesso modo QA può raccogliere bug che Dev mai pensato di testare, una serie di test possono trovare le cose l'altra serie non sarebbe.

Answer 12

test di accettazione può anche essere effettuata manualmente da parte del cliente, se il sistema in mano è piccola.

Test di unità e piccole di integrazione (che consiste di unità come test) sono lì per voi per costruire un sistema sostenibile.

Non provare a scrivere di prova per ogni parte del sistema. Questo è fragile (facile da rompere) e travolgente.

Decidere sulle parti critiche del sistema che richiede troppo tempo per testare e scrivere test di accettazione solo per quella parte di rendere le cose facili per tutti manualmente.