Test del modulo del sito web [chiuso]

1

Il mio capo ha tre siti web e ognuno di questi siti ha dei moduli su cui le persone possono registrarsi per locali notturni.

Mi ha chiesto di cercare i test di usabilità, tuttavia, non penso che sia ciò che effettivamente sta cercando. Infatti, vuole che le forme vengano testate frequentemente (ad esempio una volta al giorno) per assicurarsi che funzionino correttamente.

L'usabilità sta testando lo strumento giusto per questo? In caso contrario, qual è il modo giusto per farlo?

    
posta summerrenee 11.07.2015 - 06:11
fonte

1 risposta

2

Hai ragione, i test di usabilità hanno uno scopo molto diverso. Consiste nel chiedere a un utente di manipolare una parte del prodotto e osservare il modo in cui l'utente cerca di ottenere qualcosa. L'obiettivo è garantire che l'esperienza utente del tuo prodotto sia corretta e se ci sono elementi che potrebbero essere migliorati per rendere il prodotto più facile, più intuitivo o più veloce da usare.

Quello che stai cercando sono i test di regressione. Il test di regressione consiste nel controllare se le cose che funzionavano prima funzionino ancora dopo la modifica del codice. I test sui fumi, i test funzionali, i test unitari oi test di sistema fanno tutti parte dei test di regressione.

A seconda di cosa stai testando con precisione, il tipo di test e gli strumenti che utilizzerai saranno diversi. Ad esempio, un modulo su un sito web può essere testato in diversi modi:

  • Puoi testare il codice sottostante usando i test unitari. I test unitari sono brevi pezzi di codice che assicurano un codice molto breve nel codice base (di solito un metodo, anche se a volte potrebbe essere un'intera classe) funziona come previsto.

    Ad esempio, potresti avere un metodo che controlla che l'utente abbia inserito un indirizzo e-mail che ha un aspetto valido, e usa un gruppo di test unitari che chiamano questo metodo con indirizzi e-mail sapere di essere valido o non valido e verificare se il risultato del metodo corrisponde all'aspettativa.

  • Puoi anche verificare se il modulo stesso può essere inviato o che l'app web restituisce un errore (come HTTP 403) se il modulo contiene voci non valide. Questo viene fatto con i test di sistema e consisterà nel fare una richiesta POST con dati specifici e confrontare il codice di stato HTTP risultante. Tale test, quando si invia un input valido, può anche interrogare il database per verificare che il record associato sia stato creato correttamente.

  • Puoi anche verificare se il modulo HTML funziona come previsto (ad esempio, se inavvertitamente modifichi l'attributo action del modulo, non funzionerà più). Questo è il dominio dei test di sistema e funzionali, con strumenti come Selenium che possono aiutarti ad automatizzare i test.

  • Infine, potrebbe essere necessario assicurarsi che il modulo sia mostrato esattamente come è stato mostrato prima delle ultime modifiche, ovvero hai una corrispondenza perfetta tra pixel della pagina. Ad esempio, l'aggiunta di due pixel a padding sposterà l'intero modulo, interrompendo infine il layout.

    Poiché tali cambiamenti sono spesso appena visibili quando si guarda semplicemente la pagina, è possibile utilizzare pdiff per verificare le differenze visive.

Queste quattro modalità di test assicurano un'alta probabilità di trovare regressioni. Detto questo, ci sono due aspetti che sono estremamente importanti se si desidera che i test di regressione siano efficaci:

  • Ogni test dovrebbe essere automatizzato. Sempre. Nessuna eccezione. Non è necessario eseguire i test manualmente, riempiendo i campi del modulo, facendo clic sui pulsanti e controllando se il risultato è lo stesso richiesto dal test. Le macchine sono molto meglio di noi a compiti ripetitivi; lo fanno in millisecondi anziché ore, e non fanno errori.

  • I test dovrebbero essere eseguiti il più frequentemente possibile. una volta al giorno, come suggerito, potrebbe essere accettabile per alcuni progetti, ma perché non puoi fare di meglio ed eseguire tutti quei test dopo ogni impegno? Esecuzione di test più spesso assicura che trovi le regressioni prima, quando ricordi ancora cosa stai cambiando in questo momento. Se hai cambiato classe e cinque minuti dopo, il tuo server di build ti avvisa di una regressione, probabilmente troverai il bug più veloce di quando riceverai la notifica il mattino successivo, dopo aver trascorso sei ore a fare decine di altre modifiche.

risposta data 11.07.2015 - 09:14
fonte

Leggi altre domande sui tag