Scrittura casi di test di accettazione

Naviga le tue risposte
14

Stiamo integrando un processo di test nel nostro processo SCRUM. Il mio nuovo ruolo è scrivere test di accettazione delle nostre applicazioni web per automatizzarle in un secondo momento. Ho letto molto su come devono essere scritti i test, ma nessuno mi ha dato consigli pratici per scrivere casi di test per applicazioni web complesse, e invece hanno lanciato principi contrastanti che ho trovato difficili da applicare:

  • I casi di test dovrebbero essere brevi: prendi l'esempio di un CMS. Brevi casi di test sono facili da mantenere e identificare gli input e gli output. Ma cosa succede se voglio testare una lunga serie di operazioni (ad esempio l'aggiunta di un documento, l'invio di una notifica a un altro utente, l'altro utente risponde, il documento cambia stato, l'utente riceve una notifica). Mi sembra piuttosto che i casi di test debbano rappresentare scenari completi. Ma posso vedere come questo produrrà documenti di test apertamente complessi.

  • I test dovrebbero identificare input e output: : cosa succede se ho una forma lunga con molti campi interagenti, con comportamenti diversi. Scrivo un test per tutto, o uno per ciascuno?

  • I casi di test dovrebbero essere indipendenti: Ma come posso applicare che se testare l'operazione di caricamento richiede che l'operazione di connessione abbia esito positivo? E come si applica alla scrittura di casi di test? Devo scrivere un test per ogni operazione, ma ogni test dichiara le sue dipendenze, o dovrei riscrivere l'intero scenario per ogni test?

  • I casi di test dovrebbero essere leggermente documentati: questo principio è specifico per i progetti Agile. Quindi hai qualche consiglio su come implementare questo principio?

Anche se pensavo che scrivere i casi di test di accettazione sarebbe stato semplice, mi sono trovato sopraffatto da ogni decisione che dovevo prendere (FYI: sono uno sviluppatore e non un tester professionale). Quindi la mia domanda principale è: quali passi o consigli hai per scrivere casi di test di accettazione mantenibili per applicazioni complesse. Grazie.

Modifica : per chiarire la mia domanda: sono consapevole che il test di accettazione dovrebbe iniziare dal requisito e considerare l'intera applicazione come una scatola nera. La mia domanda riguarda le fasi pratiche per scrivere il documento di test, identificare i casi di test, trattare le dipendenze tra i test ... per le applicazioni Web complesse

    
posta H-H 12.02.2011 - 00:02
fonte

4 risposte

5

Nelle mie suite di accettazione sono rimasto lontano dall'utilizzo di controlli specifici della tecnologia, ad esempio per le applicazioni Web non utilizzare css non utilizzare gli elementi html se è necessario compilare un modulo, fare le specifiche nei passaggi per configurare il SUT non l'effettivo test di accettazione

Uso cetriolo per la mia accettazione e ho il seguente 

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

questo esempio è tornato da un'applicazione web, ma posso ancora usare il test per testare un'applicazione desktop poiché i passaggi sono usati per impostare SUT e non i test di accettazione

questo test si trova alla fine di un acquisto che va

Genera - > Conferma - > Pagamento - > Stampa ricevuta

il test sopra è per la fase di pagamento, gli altri passaggi sono impostati in altri test poiché l'applicazione è in grado di configurare in questi stati con azioni di dati o http in questo caso il pagamento ha un dato che fa i passi di conferma e la conferma genera i passaggi in modo che siano un po 'fragili al minuto

    
risposta data 12.02.2011 - 15:11
fonte
2

Per prima cosa devi definire Test di accettazione .

Ciò che sembra descrivere è integrazione o test di sistema .

Quindi anche se non sono al 100% d'accordo con le definizioni su wikipedia, sono ancora ampiamente valide.

Fondamentalmente lo scopo dei test di accettazione è verificare che i processi di "business" che fanno uso del software che hai costruito funzionino effettivamente come previsto e siano adatti allo scopo - con dati di vita reale. Quindi in quanto tale non costruisci casi come test unitari o il resto. Non dovrebbe essere progettato allo stesso modo.

La domanda da porsi è "come viene utilizzato il sistema?". Quindi provalo come deve essere usato. Ovviamente ora ti rimetti il cappello di ingegneria e rispondi in modo religioso ai requisiti aziendali per ricavare i tuoi casi di test. Ciò presuppone che tu abbia requisiti aziendali ben scritti.

Se non lo fai, non è troppo tardi, devi sederti con l'utente (i) oi loro rappresentanti (e l'analista di business e la persona di progettazione tecnica) e annotare ciò che si aspettano che il software fornisca termini commerciali (con l'ovvia avvertenza che è troppo tardi, ma è meglio iniziare in ritardo che mai, e ovviamente non introdurre nuove funzionalità). Questo è ciò che saranno i tuoi casi di test.

Un altro modo di procedere (di nuovo se si dispone di un documento di questo tipo) è di consultare il manuale dell'utente. Anche se questo è un passo rimosso dai reali requisiti di business, quindi deve essere utilizzato solo se tutto il resto fallisce.

Quando vai a comprare una macchina, in genere non vai molto in profondità sotto il cofano (a meno che tu non sia un meccanico automobilistico). Ti siedi al volante e controlli il comfort, l'usabilità, l'aspetto, i suoni ... cioè le cose generali. Generalmente ti fidi che se l'auto dovesse essere in mano in primo luogo (almeno per una nuova auto), è generalmente sicura e ben costruita (c'è una garanzia, hai fatto il tuo lavoro a casa e hai guardato le specifiche ...). Quindi ora controlli se questa è l'auto che vorresti guidare per i prossimi anni.

Uguale al software.

    
risposta data 12.02.2011 - 06:39
fonte
1

Le informazioni contrastanti possono essere frustranti e difficili da generalizzare e applicare alla tua situazione specifica. Ergo, potresti dover fare ciò che funziona meglio nel tuo contesto.

Non sono un grande fan dei lunghi documenti di prova, e ho usato la grafica in modo abbastanza efficace per alcuni progetti più piccoli. Prova questo? Come un diagramma di flusso (o qualsiasi altro diagramma UML come un diagramma di stato, ecc.) Invece di usare solo il testo? Indicare input, output, condizioni, loop, corsie, stati, interazioni con altri componenti ecc. E quindi indicare se hanno esito positivo, fallito, trasferito, altro (?) In base ai propri criteri.

Potrebbe essere un po 'di lavoro all'inizio, ma potrebbe aiutarti a mantenerti sano di mente a lungo termine. Qualunque sia il metodo che scegli, più lavori con esso, meglio riuscirai a farlo.

HTH, e buona fortuna!

KM

    
risposta data 12.02.2011 - 01:33
fonte
0

Penso che tu abbia già individuato alcuni buoni criteri. Il secondo punto è un buon modo per definire gli ambiti per i test e suggerisco anche di testare condizioni di errore e bufix (sostengo che ogni correzione di bug abbia almeno un nuovo test di unità). Può sembrare travolgente ora, ma immergiti e dopo aver fatto un po 'di esperienza, riconoscere ciò che rende buoni i test sarà più facile.

    
risposta data 12.02.2011 - 01:32
fonte

Leggi altre domande sui tag

Dinamico vs lingue tipizzate staticamente per siti web [chiuso] Dovresti promettere di fornire una funzionalità che non sei sicuro se sia implementabile?