Capire come funziona il software di prova e quello di testare

Question

Intro: un sacco
che ho visto di argomenti qui su SO su test del software e altri termini non capisco.

Problema:
Come sviluppatore principianti Io, purtroppo, non ho idea di come funziona il test del software, nemmeno come testare una semplice funzione. Questo è un peccato, ma questa è la verità. Spero anche che questa domanda possa aiutare anche gli sviluppatori principianti.

Domanda:
Potete aiutarmi a capire questo argomento un po 'di più?

Forse alcune domande per iniziare aiuterebbe:

• Quando ho sviluppato una funzione, come devo provarlo? Ad esempio: quando si lavora con una funzione somma, dovrei testare ogni valore di input possibile o solo alcuni limiti? Che ne dici di testare le funzioni con stringhe come parametri?
• In un grande programma, devo testare ogni singolo pezzo di codice di esso? Quando programmate, testate tutti i codici scritti?
• Come funziona il test automatico e come posso provarne uno? Come funzionano gli strumenti per i test automatizzati e cosa fanno?
• Ho sentito parlare dei test unitari. Posso avere una breve spiegazione su questo?
• Che cos'è un framework di test?

Se possibile, si prega di inserire del codice con esempi per chiarire le idee.

Qualsiasi aiuto su questo argomento è molto benvenuto! Grazie.

Answer 1

Cominciamo con l'ovvio:

Come funziona il test? Nello sviluppo basato su test, si pensa prima alla funzionalità che si desidera implementare e quindi si scrive un test per questo. Nell'esempio che hai dato di una funzione somma è abbastanza ovvio che cosa dovrebbe fare. Quindi scrivi un test che assicura che la sommatoria abbia funzionato.

I test di unità dovrebbero essere il più leggeri possibile in modo da poterli eseguire ogni volta che si preme il pulsante di costruzione. Quando lo fai adesso in questo esempio, il tuo test fallirà, perché non hai ancora implementato una funzione di somma.

Ora si scrive la funzione effettiva e si continua a eseguire il debug e l'implementazione fino al termine del test. Allora sei sicuro di aver implementato la funzione che volevi.

Ora come si progetta il test? Non è possibile testare tutto, è impossibile. Ad esempio, supponiamo che tu prenda l'input dell'utente che devi convalidare. Quindi sarebbe una cosa naturale scrivere almeno due casi di test per quel codice di convalida: uno che si assicura che l'input valido sia analizzato come tale. Il secondo test case riceve input non validi e ci si assicura che fallisca, solleva un'eccezione o qualsiasi comportamento si desideri. Quindi in questo caso è bene avere un test positivo che dovrebbe passare e un test negativo che controlli se l'input non valido non è validato.

Quando è necessario eseguire un test? Come ho detto prima il test dovrebbe essere abbastanza leggero da poter essere eseguito su ogni build. E sì, gestiscili tutti. Questo assicura che non manchi una dipendenza del tuo codice che rompa cose lontane dal punto che hai modificato.

È possibile testare qualcosa? Beh, di solito i metodi che si basano su risorse esterne sono difficili da testare. Ciò che intendo sono i database, le connessioni di rete o hardware e driver specifici. Può essere fatto ma poi è necessario impostare una configurazione di test più ampia.

Bugfixing e test Uno scenario tipico in cui il test diventa davvero utile se si stanno stringendo i bug. Non letteralmente, ovviamente. Se hai un bug che devi correggere, prima prova a scrivere un test per questo. E poi correggi il tuo codice fino a quando il tuo test non sarà superato. Da questo punto in poi questo test "controlla il tuo codice" che questo bug non tornerà mai più.

Cosa guadagni testando? A mio parere ci sono molte cose

1. più modulare, facile da mantenere il codice perché deve essere testabile
2. fiducia. Avere una base di codice ampiamente testata ti dà la certezza che funziona come previsto e rimane così.
3. Trovate bug in anticipo. Ciò significa che puoi risolverli più facilmente.

Ci vuole un po 'per abituarsi all'utilizzo dei test, ma penso che ne valga la pena. Soprattutto se stai scrivendo delle librerie di qualche tipo.

Answer 2

Bene, Di solito, ci sono tre tipi di test. Test unitari, test di sistema e test QA. Test unitari, come suggerisce il nome, testano piccole unità - funzioni e classi separate.

Per tutti gli ambienti di sviluppo moderni ci sono framework di test unitari. C'è Nunit per .net, così come il framework di test delle unità MS in Visual Studio, CPPUnit per C++, JUnit, ecc. Tutto per una cosa: connettersi a parti del programma, eseguire gli script predefiniti e segnalare errori.

CPPUnit, ad esempio, si basa su macro come CPPUNIT_ASSERT_EQUAL, destinate ad essere utilizzate come qualcosa di simile: CPPUNIT_ASSERT_EQUAL (sum (arr), 17). E direbbe se non è uguale, nel qual caso il test sarà considerato fallito.

Si suppone che si sviluppino i test per ogni funzione e, successivamente, non si teme di modificare e ottimizzare il codice. Generalmente si riferisce a una "ripetibilità": capacità di eseguire un'azione complessa, come il test completo di tutti i codebase, con un solo clic.

I test di unità sono necessari per ogni sviluppo di moden software, poiché l'esperienza dimostra che migliorano la velocità di sviluppo. Si suggerisce anche che il codice di test unitario possa servire come una sorta di "documentazione" per la biblioteca.

I test di sistema sono test automatici di funzionalità di livello superiore. L'idea dei test di sistema è di alimentare input puliti (come database, input dell'utente, ecc.) Per testare l'intera cosa, convalidando l'output rispetto ai resutls predefiniti.È essenziale che l'output del sistema sia deterministico e dipende solo dall'input. Ogni volta che il sistema cambia, anche i test di sistema cambiano.

TDD è una pessima idea, suggerendo che non è necessario sviluppare nulla prima di implementare i test automatici appropriati e quindi scrivere il codice per soddisfare i test. È considerato fallimento, perché i cambiamenti nel design sono inevitabili durante lo sviluppo, e un piccolo cambiamento di design di solito causa cambiamenti drastici nei test unitari.

QA manuale è il tipo di test del software finale e più importante. L'idea è di preparare un piano di test, che è stato fatto durante le fasi di progettazione e codifica, raccogliendo tutte le idee sviluppate dagli sviluppatori durante la codifica di ogni istruzione if, in che modo rendere questa particolare istruzione se eseguita lungo il percorso del codice meno previsto. Il personale addetto al controllo qualità, che deve essere in grado di eseguire tutto ciò che può essere fatto con il programma senza ambiente di sviluppo, può seguire la procedura di test risultante e le proprie idee, per trovare altri bug.

Answer 3

Ho trovato il libro "JUnit Pocket Guide" di Kent Beck come un'eccellente (ed economica e compatta!) Introduzione al Test di unità: il libro è suddiviso grosso modo in sezioni sui meriti della programmazione testata e delle tecniche di test generali e poi entra nello specifico del framework JUnit (che ha co-creato).

http://www.amazon.co.uk/JUnit-Pocket-Guide-Kent-Beck/dp/0596007434/ref=sr_1_7?ie=UTF8&s=books&qid=1276811600&sr=8-7

Per quanto riguarda la vostra richiesta di alcuni esempi illustrativi di Unit Testing; questo JUnit Primer non è male:

http://www.clarkware.com/articles/JUnitPrimer.html#testcase

Answer 4

È possibile dividere i test in tre grandi rami (in realtà ci sono più, ma se sei un principiante si deve capire il prima base): Alpha, Beta , Codice di lavoro completo.

1. In alfa si prova ogni singolo valore per ogni singolo pezzo di codice.
2. In beta si dà l'applicazione presumibilmente funzionante al mondo, al fine di ottenere un feedback dai tester e migliorarlo.
3. Quando l'app è completamente funzionante, devi solo attendere il rapporto di errore (viene sempre) di un utente che ha scoperto il problema e lo risolve con una patch.

Quando sviluppo una funzione, come devo verificarla? Ad esempio: quando si lavora con una funzione somma, dovrei testare ogni valore di input possibile o solo alcuni limiti? Che ne dici di testare le funzioni con stringhe come parametri?

In alfa devi pensare a TUTTE le possibilità con cui il tuo codice può essere composto. Nel caso di una funzione sum(), sono pochi, ma se stai sviluppando diciamo una grande applicazione server database, devi prendere in considerazione ogni possibile input e gestire ogni possibile errore, pensa all'utente finale come una persona stupida o addirittura un cracker malizioso.

In un grande programma, devo testare ogni singolo pezzo di codice di esso? Quando programmate, testate tutti i codici scritti?

Sì, dovresti, microsoft no. (prendi la battuta;))

Come funziona il test automatico e come posso provarne uno?Come funzionano gli strumenti per i test automatizzati e cosa fanno?

No automazione in grado di superare l'intelligenza umana e un buon debugger (che è l'unico strumento si ha realmente bisogno!)

`ve sentito parlare di test di unità. Posso avere una breve spiegazione su questo?

http://en.wikipedia.org/wiki/Unit_testing

Che cosa è un framework di test?

http://en.wikipedia.org/wiki/Test_automation_framework

Answer 5

Cosa provare

Ci sono un paio di concetti realmente utili che mi ha aiutato a lavorare questo fuori:

• http://en.wikipedia.org/wiki/Equivalence_partitioning
• http://en.wikipedia.org/wiki/Boundary-value_analysis

equivalenza partizionamento dice "Correre il test in questo contesto con questi eventi è equivalente a questi altri tes qui, quindi non ho bisogno di fare entrambe le cose. "

L'analisi al contorno dice "Ecco il punto in cui un cambiamento nel contesto o un evento diverso causa un risultato diverso, quindi voglio test su entrambi i lati di questo limite."

Pensare a questi può davvero aiutare a ridurre al minimo il numero di test che è necessario scrivere.

Quando per testare

ho sempre prova manualmente il mio codice per assicurarsi che funzioni. Scrivo spesso un test unitario aggiuntivo che copre ogni riga di codice che sto per scrivere. Il test dell'unità fallisce prima di scrivere il codice per farlo passare. Se è qualcosa che un utente farà, allora scrivo spesso anche un test di accettazione o uno scenario automatizzato.

test automatizzati

test automatici significa o scripting o la registrazione di un test in modo che non c'è bisogno di farlo manualmente - lo script o il codice lo farà per voi. Esistono due tipi di strumenti di automazione: BDD o dispositivi di test di accettazione leggibili in inglese che consentono di scrivere script e wrapper di automazione che consentono di automatizzare più facilmente. Ad esempio, potresti scegliere di utilizzare GivWenZen o Fitnesse come dispositivo fisso e Selenium come strumento di automazione web.

Se hai Visual Studio 2008+ è possibile scaricare il codice sorgente da qui e provare lo scenario di vederlo funzionare:

http://code.google.com/p/wipflash/

Unit testing

Nella sua senso più stretto, Unit Testing significa testare un elemento di codice in isolamento da tutti gli altri elementi di codice. Utilizziamo mock al posto di veri pezzi di codice richiesti dal nostro codice in prova. In realtà siamo spesso pragmatici riguardo alla natura delle "unità" - per esempio, non derideremo gli oggetti del dominio.

Tuttavia, il test delle unità nel modo in cui viene utilizzato dalla maggior parte delle persone non riguarda realmente il test. Principalmente è un meccanismo per ottenere un design pulito e una separazione delle responsabilità, perché sei costretto a farlo cercando di testarlo.

Mi piace pensare ai test di unità come "scrivere un esempio di come userò il codice che sto per scrivere". L'esempio si verifica per risiedere in un framework di test unitario ed essere eseguibile.

test framework

• framework di unit test consentono di eseguire un sacco di test insieme.
• I framework di test di accettazione consentono di eseguire uno scenario più ampio e sono spesso leggibili in inglese.
• I framework di automazione di solito siedono sotto i vostri framework leggibili in inglese e vi aiutano a interagire con un'applicazione.

Buona fortuna!