Interfacce / framework utente scriptable per il test UI automatizzato

Nella mia opzione la gui-scripting è molto utile se è combinata con un gui recorder che traduce le azioni di un gui-user in uno script riproducibile.

Il lato problematico della gui-scripting è che se la GUI cambia anche gli script devono essere aggiornati.

se ad esempio il logindialog cambia e hai 150 test che dipendono dal login allora nel caso peggiore hai 150 test di aggiornamento.

se sei fortunato hai script modulizzati con un metodo centrale "Login" che viene utilizzato da tutti gli script di test in modo che sia necessario aggiornare solo uno script.

ma non di meno non sottovalutare i costi di maintanace del test automatizzato.

se vuoi usare pagine html gui-script potrebbero esserci anche problemi con javascript / ajax.

Aggiornamento:

scrivere script di test manuali è noioso, ma usare un registratore di script porta a script che sono difficili da mantenere. Spesso è più facile registrare un nuovo test e quindi aggiornare un esistente: - (.

Che cosa farei per automatizzare i test html dell'applicazione utilizzando il software gratuito

• usa selenio per registrare e generare codice c # da esso.
• usa il linguaggio bdd leggibile per descrivere il testscenario che hai registrato (per ... come ... voglio ...: dato ... quando ... poi ....)
• usa specflow per implementare i test bdd
• rifattora il codice registrato / generato in metodi che si adattano ai passi di bdd-scenario. Passaggi comuni (come l'esempio di accesso) possono essere condivisi dai test bdd multipli.

Nota: non ho ancora fatto questa soluzione, ma ho letto molto e lavorato con due prodotti di registrazione commerciale. Se c'è qualcosa di sbagliato nella mia proposta di selenio / specflow, lascia un commento.

Se conosci altri strumenti gratuiti, ti preghiamo di aggiornare la wiki di stackoverflow most-useful-free-net -libraries

Dato che lavori in C #, perché non assicurarti che la tua applicazione rispetti l'esistente framework di automazione Microsoft ?

Con ciò, potresti essere in grado di sfruttare gli strumenti esistenti.

Se esponi le tue metodologie di scripting:

• Non creare la tua lingua. Ci sono un sacco di grandi linguaggi che abbracciano qualsiasi spettro di cui ti possa interessare.
• Ottieni un buon set di casi d'uso per capire cosa la maggior parte degli utenti vuole veramente controllare.
• Considera l'accesso esterno (entrando ed uscendo). Spesso, le persone vogliono scrivere un prodotto per integrarlo in un altro prodotto.

Se creerai un gui recorder, dovresti generare le azioni dello script direttamente dalla tua applicazione. In questo modo sei in grado di generare gli script più significativi e l'interfaccia di scripting può essere resa facile da usare.

Non è un'opzione per avere un registratore di script generico che ascolti tutti gli eventi dell'interfaccia utente e cerchi di generare uno script da loro.

Non penso ci siano buone ragioni per inventare il tuo linguaggio di scripting. Esistono diverse lingue progettate specificamente per essere incorporate in altre applicazioni (ad esempio: tcl, lua). Risparmia la fatica di inventare un'altra lingua e invece di adattare uno di questi.