L'integrazione Automated Testing Web Into processo di generazione

StackOverflow https://stackoverflow.com/questions/1240057

Domanda

sto cercando suggerimenti per migliorare il processo di automatizzare il collaudo funzionale di un sito web. Ecco quello che ho provato in passato.

Ho usato per avere un progetto di test utilizzando WATIN . È efficace scrivere quello che sembra "unit test" e utilizzare WATIN per automatizzare un browser per fare clic intorno al vostro sito, ecc.

Naturalmente, è necessario un sito per essere in esecuzione. Così ho fatto il test in realtà copiare il codice dal mio progetto web in una directory locale e ha iniziato un server web che punta a quella directory prima di tutti i test eseguiti.

In questo modo, qualcuno di nuovo potrebbe ottenere semplicemente più recente dal nostro controllo del codice sorgente ed eseguire il nostro script di build, per vedere tutte le prove vengono completate. Essi potrebbero anche semplicemente eseguire tutti i test dalla IDE.

Il problema che ho incontrato è stato che ho passato un sacco di tempo a mantenere il codice per impostare l'ambiente di prova più che i test. Senza contare che c'è voluto molto tempo per correre a causa di tutto ciò che la copia. Inoltre, avevo bisogno di testare diversi scenari, tra cui l'installazione, nel senso avevo bisogno di essere in grado di impostare il database per diversi stati iniziali.

ero curioso su quello che hai fatto per automatizzare i test funzionali per risolvere alcuni di questi problemi ed ancora mantenere le cose semplici.

maggiori informazioni Dal momento che le persone hanno chiesto maggiori dettagli, qui è. Sono in esecuzione ASP.NET utilizzando Visual Studio e Cassini (il costruito nel web server). I miei unit test eseguiti in MbUnit (ma non è così importante. Potrebbe essere NUnit o XUnit.NET). In genere, ho un framework di test un'unità separata eseguito tutti i miei test Watin. Nella fase AssemblyLoad, comincio il server web e copiare tutto il mio codice di applicazioni web a livello locale.

Sono interessato a soluzioni per qualsiasi piattaforma, ma posso avere bisogno di più descrizioni su ciò che significa ogni cosa. :)

È stato utile?

Soluzione

Phil,

L'automazione può solo essere difficile da mantenere, ma più si utilizza l'automazione per la distribuzione, tanto più è possibile sfruttare per configurazione di prova (e viceversa).

Francamente, è più facile far evolvere il codice di automazione, di factoring e refactoring in specifici, piccole unità di funzionalità quando si utilizza un tool di creazione che non è
guidando solo staticamente compilati, unità di pre-ceduti di funzionalità, come è il caso con NAnt e MSBuild. Questo è uno dei motivi per cui molte persone che erano relativamente primi utenti di Toole come NAnt sono spostati fuori Rake. La libertà di trattare costruire codice come qualsiasi altro codice - per cotinually evolversi il suo contenuto e la forma - è maggiore con Rake. Non si finisce con lo stesso stasi in manufatti di automazione con la stessa facilità e più velocemente con il rastrello, ed è molto più facile per script nel Rake di NAnt o MSBuild.

Quindi, una parte della tua lotta è intrinsecamente legata negli strumenti. Per mantenere la vostra automazione sensibile e mantenuto, si dovrebbe diffidare di ostruzioni che costruire strumenti statici, come NAnt e MSBuild impongono.

Vorrei suggerire che non accoppiare il vostro ambiente di test di boot-reggette da carico di assemblaggio. Questo è un attacco dentro-fuori che serve solo brevi convenienza. Non c'è niente di sbagliato (e, probabilmente tutto a destra) con l'andare alla riga di comando e l'esecuzione del compito di compilazione che imposta l'ambiente prima di eseguire test sia dal IDE o dalla riga di comando, o da una console interattiva, come il C # REPL da Progetto Mono, oppure da IRB.

configurazione dei dati di test è semplicemente un dolore a volte il culo. Essa deve essere fatto.

Si sta andando ad avere bisogno di una libreria che è possibile chiamare per creare e ripulire lo stato del database. È possibile effettuare le chiamate direttamente dal tuo codice di prova, ma io personalmente tendono ad evitare di fare questo perché non v'è più di un buon uso dei dati di test o di codice di controllo dei dati di esempio.

I drive tutto il controllo dati di esempio da HTTP. Scrivo regolatori con azioni specificamente per il controllo dei dati di esempio e questione ottiene contro quelle azioni attraverso selenio. Io uso questi per creare e ripulire i dati. Posso comporre arriva a queste azioni per creare scenari comuni di dati di configurazione, e posso passare valori specifici per dati come parametri di richiesta (o parametri di modulo se necessario).

Continuo a questi controller in una zona che di solito chiamo "test_support".

Il mio automazione per la distribuzione del sito web non distribuire l'area test_support o suoi circuiti e la mappatura. Come parte del mio schieramento automazione di verifica, faccio in modo che il codice test_support non è in app di produzione.

Io uso anche il codice test_support per automatizzare il controllo su tutto l'ambiente - la sostituzione dei servizi con falsi, disattivando i sottosistemi per simulare guasti e failover, attivare o disattivare il controllo di autenticazione e di accesso per i test funzionali, che non si occupa di questi aspetti, ecc

C'è un grande valore secondario a controllare i dati di esempio il vostro web di app o dati di test dal Web: quando demoing l'applicazione, o quando si fa il test esplorativo, è possibile creare gli scenari di dati è necessario solo mediante l'emissione di alcuni ottiene contro la nota (o indovinabili) gli URL nella zona test_support. Davvero facendo uno sforzo disciplinato per attenersi a percorsi rilassanti e delle risorse-orientamento qui sarà davvero pagare.

C'è molto di più a questa automazione funzionale (tra cui prova, distribuzione, provare le canzoni, ecc) in modo che il meglio progettate queste risorse sono, migliore è il tempo sarete li hai il mantenimento nel lungo corridoio, e più opportunità' troverete di sfruttare in modi imprevedibili, ma benefico.

Per esempio, la scrittura di codice modello di dominio rispetto al modello semantico delle tue pagine web contribuirà a creare molto più comprensibile il codice di prova e diminuire la fragilità. Se fate questo bene, è possibile utilizzare questi stessi modelli con una varietà di diversi driver in modo dali può sfruttare in stress test e prove di carico e prova funzionale, nonché il loro utilizzo da linea di comando come strumenti esplorativi. Tra l'altro, questo genere di cose è più facile da fare quando non sei destinato a tipi di driver come sei quando si utilizza un linguaggio statico. C'è un motivo per cui molti pensatori di test leader e coloro che fanno lavorare in Ruby, e perché Watir è scritto in Ruby. Il riutilizzo, la composizione, e l'espressività è molto più facile da raggiungere in Ruby di codice C # di prova. Ma questa è un'altra storia.

Diamo recuperare il ritardo qualche volta e comunicare di più circa il restante 90% di questa roba:)

Altri suggerimenti

plasma su un progetto. Emula un web server nel processo - basta puntare alla radice del vostro progetto di applicazione web.

E 'stato sorprendentemente stabile - non la copia di file o l'avvio di un processo di server di

.

Ecco come un test utilizzando plasma sembra per noi ... 

    [Test]
    public void Can_log_in() {
        AspNetResponse response = WebApp.ProcessRequest("/Login.aspx");
        AspNetForm form = response.GetForm();

        form["UserName"] = User.UserName;

        form["Password"] = User.Password;

        AspNetResponse loggedIn = WebApp.ProcessRequest(Button.Click(form, "LoginUser"));


        Assert.IsTrue(loggedIn.IsRedirect());

        AspNetResponse homePage = WebApp.ProcessRequest(loggedIn.GetRedirectUrl());

        Assert.AreEqual(homePage.Status, 200);
    }

Tutte le classi e le "AspNetResponse" "AspNetForm" sono inclusi con plasma.

Al momento stiamo utilizzando un processo di generazione automatica per la nostra applicazione mvc asp.net.

Usiamo i seguenti strumenti:

  • TeamCity
  • SVN
  • NUnit
  • Il selenio

Usiamo uno script MSBuild che gira su un agente di accumulo che può essere qualsiasi quantità di macchine. Lo script msbuild ottiene l'ultima versione di codice da SVN e costruisce.

In caso di successo li distribuisce i manufatti ad una macchina data / cartella e crea il sito virtuale in IIS.

Abbiamo quindi utilizzare compiti contrib MSBuild di eseguire script SQL per installare i dati del database e di carico, si potrebbe anche fare un ripristino.

In caso di successo si dà il via i test NUnit. La configurazione di prova assicura che il selenio è in esecuzione e quindi aziona i test selenio molto nello stesso modo che Watin fa. Il selenio ha un buon registratore per le prove che possono essere esportati a C #.

La cosa buona di selenio è che si può guidare FF, Chorme e IE piuttosto che essere limitato a IE, che è stato il caso con Watin l'ultima volta che ho guardato. È inoltre possibile utilizzare selenio di fare test di carico con il Selenio griglia quindi è possibile riutilizzare gli stessi test.

In caso di successo msbuild poi tag la configurazione in svn. TeamCity ha un lavoro che viene eseguito durante la notte che implementerà l'ultimo tag per un ambiente di staging pronto per gli utenti aziendali per controllare lo stato del progetto la mattina seguente.

In una vita precedente che avevamo script Nant e MSBuild per gestire completamente l'ambiente (l'installazione di Java, il selenio, ecc) ma questo ci vuole un sacco di tempo in modo da req pre ci assumere ogni agente di compilazione ha queste installati. Nel tempo includeremo questi compiti.

Perché è necessario il codice copiare? Fosso Cassini e lasciare che Visual Studio creare una directory virtuale per voi. Certo gli sviluppatori devono ricordare di costruire prima di eseguire i test web, se l'applicazione web è cambiato. Abbiamo scoperto che questo non è un grosso problema, soprattutto se si esegue i test web in CI.

Dati è una grande sfida. Per quanto posso vedere, è necessario scegliere tra alternative imperfette. Ecco come abbiamo gestirlo. In primo luogo, vorrei spiegare che stiamo lavorando con un grande complesso WebForms legacy app. Inoltre devo dire che il codice di dominio non è adatto per la creazione di dati di test all'interno del progetto di test.

Questo ci ha lasciato con un paio di scelte. Potremmo: (a) script di installazione dei dati eseguito con l'accumulo, o (b) creare tutti i dati tramite i test Web utilizzando il sito web vero e proprio. Il problema con l'opzione (a) è che i test diventano accoppiato con script a livello minuto. Mi fa pulsare la testa per pensare a sincronizzare il codice di prova web con T-SQL. Così siamo andati con (b).

Uno dei vantaggi di (b) è che la configurazione convalida inoltre il comportamento delle applicazioni. Il problema è ... tempo .

Idealmente test devono essere indipendenti, senza accoppiamento temporale (può essere eseguito in qualsiasi ordine) e non condividere qualsiasi contesto (ad esempio, dati di prova comuni). Il modo più comune per gestirle è di impostare e abbattere dati con ogni test. Dopo un po 'attenta riflessione, abbiamo deciso di rompere questa regola.

Usiamo Gallio (MbUnit 3), che fornisce alcune funzioni che supportano la nostra strategia. In primo luogo, consente di specificare l'ordine di esecuzione a livello di dispositivo e di prova. Abbiamo quattro apparecchi "Setup" che vengono ordinati -4, -3, -2, -1. Questi eseguito nell'ordine specificato e prima di tutti gli apparecchi "non SETUP", che di default hanno un ordine pari a 0.

Il nostro progetto di test web dipende lo script di build per una cosa sola: un unico ben noto nome utente / password. Si tratta di un accoppiamento posso vivere con. Come i test Eseguire l'installazione di costruire un oggetto "contesto dati" che tiene identificatori di dati (aziende, utenti, fornitori, clienti, etc.) che viene successivamente utilizzato (ma mai cambiato) in tutto altri tutti gli apparecchi. (Da identificatori, io non intendo necessariamente le chiavi. Nella maggior parte dei casi la nostra interfaccia utente web non espone chiavi univoche. Dobbiamo navigare l'applicazione utilizzando nomi o altri proxy per i veri identificatori. Più su questo sotto).

Gallio consente anche di specificare che un test o dispositivo dipende da un altro test o dispositivo. Quando un precedente fallisce, il dipendente viene saltata. Questo riduce il male di accoppiamento temporale impedendo "errori a catena" che possono trarre molta confusione.

La creazione di dati di test della linea di base, una volta, invece di prima di ogni prova, accelera le cose un sacco. Tuttavia, i test di impostazione ancora potrebbero richiedere 10 minuti per l'esecuzione. Quando sto lavorando a nuovi test Voglio correre e rieseguire frequentemente. Inserisci un'altra caratteristica fredda Gallio: Ambiente. L'atmosfera è un involucro intorno DB4 che fornisce un modo molto semplice per persistere oggetti. L'usiamo per persistere il contesto dati automaticamente. Così le prove di setup deve essere eseguito solo una volta tra le ricostruzioni del database. Dopo di che è possibile eseguire una o tutte le altri dispositivi più volte.

E per quanto riguarda la pulizia dei dati di test? Non abbiamo bisogno di partire da uno stato conosciuto? Questa è una regola che abbiamo trovato opportuno di rompere. Una strategia che sta lavorando per noi è quello di utilizzare i valori lunghi casuali per cose come il nome della società, nome utente, ecc Abbiamo scoperto che non è molto difficile mantenere un giro di prova all'interno di uno "spazio di dati" logico tale da non urtare in altri dati. Certo, temo il giorno che trascorro ore inseguire un test non riuscendo fantasma solo per scoprire che si tratta di qualche collisione di dati. Si tratta di un compromesso che sta lavorando per noi al momento.

Stiamo usando Watin. Mi piace abbastanza. Un'altra chiave del successo è qualcosa di Scott Bellware alluso. Come creiamo i test che stiamo costruendo un modello astratto della nostra interfaccia utente. Così, invece di questo: 

browser.TextField("ctl0_tab2_newNote").TypeText("foo");

will vedere questo nei nostri test: 

User.NotesTab.NewNote.TypeText("foo");

Questo approccio offre tre vantaggi. In primo luogo, non abbiamo mai ripetiamo una stringa magica. Questo riduce notevolmente fragilità. In secondo luogo, i test sono molto più facili da leggere e capire. Ultimo, nascondiamo la maggior parte del quadro Watin dietro le nostre astrazioni. Nel secondo esempio, solo TypeText è un metodo Watin. In questo modo sarà più facile cambiare come i cambiamenti quadro.

Spero che questo aiuti.

E 'stato difficile, ma non impossibile, per costruire una fase di test di integrazione nel processo di generazione usando Maven. Quello che è successo era essenzialmente questa:

  • Ignora tutti i test JUnit in una directory specifica a meno che i fuochi fase di integrazione-test.
  • Aggiungi un profilo di Maven per eseguire i test di integrazione.

  • Per la fase di test di pre-integrazione -

  • Avvia Jetty che esegue l'applicazione di colpire un database di test.

  • Avvia il server di selenio
  • test di integrazione di selenio eseguito in fase di test di integrazione
  • Arresta server selenio
  • Smettere di selenio

La difficoltà di questo passaggio era davvero la creazione di banchina - non siamo riusciti a farlo per lanciare solo da una guerra, quindi in realtà avere pontile disimballare la guerra, quindi eseguire il server - ma funziona, bene, e è automatizzato -. tutto ciò che dovete fare è digitare mvn -PintegrationTest (che era la nostra integrazione di prova nome del profilo) e fuori è andato

Vuoi dire automaticamente a partire test dopo la generazione finito? Si potrebbe scrivere script automatici per copiare i file di build a un IIS di lavoro, mentre la build rispettato con successo. E quindi avviare il BVT automatizzato dalla chiamata MSTest.exe o altri metodi.

Si potrebbe ottenere una prova con autoitx o qualche lingua funzione, come Python, Ruby.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top