Dove eseguire i test dell'interfaccia utente di automazione: crea server o macchina di prova

In genere una macchina di costruzione è pensata per i test di compilazione, compilazione e unità. Non ci dovrebbero essere dipendenze esterne.

Solitamente, l'automazione dell'interfaccia utente avviene come un passaggio successivo alla distribuzione dopo che il pacchetto è stato creato e distribuito in un ambiente. Pertanto, gli script di selenio devono essere eseguiti dopo che il pacchetto di codice è stato distribuito.

Uno potrebbe eseguirli sul tuo server di build, ma il tuo build server deve assomigliare al tuo ambiente. A volte la creazione e la distribuzione sulla stessa macchina possono causare problemi, quindi è consigliabile separarli.

Vorrei distribuire l'applicazione in un ambiente di test separato che fosse "simile" alla produzione (date un'occhiata a Docker o ad altre tecnologie simili). Esegui il test Gui, dopo che tutto è a posto, quindi esegui l'implementazione sul server QA affinché il vero tester dia un'occhiata.

Ho avuto la stessa domanda qualche settimana fa per il nostro prodotto.

Tradizionalmente, le macchine di costruzione sono bestie molto speciali, a causa dell'elevato numero di strumenti installati. L'aggiunta di più strumenti porta a conflitti e problemi di manutenzione, quindi la migliore pratica era quella di avere macchine diverse per compiti diversi. Ma ora, tutte le nostre macchine di compilazione stanno semplicemente eseguendo l'agente di creazione e la finestra mobile tfs: ci sono alcune differenze nell'hardware, ma questo non ha alcun impatto a parte i tempi di compilazione diversi. Ogni ambiente (ad esempio una build di python, una build di base di asp.net o un test) ha un proprio contenitore completamente separato dall'ambiente di tutti gli altri ambienti. La "bestia speciale" è contenuta nei contenitori. Quindi, dove eseguo i miei test è del tutto irrilevante per me, tranne che il test deve essere in grado di connettersi al sito Web target. Quindi non distinguiamo più le macchine di costruzione. Le macchine sacre "BUILD_01_CAn_BUILD_OLD_CRAP" e "TEST_CAN_EXECUTE_SELENIUM_TESTS" sono sparite, hanno smesso di essere animali domestici e sono bestiame come dovrebbero essere. ( link )

I nostri test sono anche contenitori (pytest-selenium in un contenitore e selenio / standalone-chrome come un altro contenitore). Inietto l'url di destinazione come parametro ambientale e questo è tutto. C'è una certa configurazione all'interno del contenitore pithest-selenio, ma non molto.

Abbiamo dovuto risolvere lo stesso problema. Siamo giunti alla soluzione che funziona molto bene.

Tutto il codice nel master deve avvenire tramite una richiesta pull. Per completare una richiesta di pull, deve essere compilata e approvata da un revisore richiesto. È importante che il sistema sia configurato per creare un commit temporaneo di unione dal ramo e dal master (simile al commit se il PR dovesse essere completato)

Una volta completata la compilazione, viene creata una versione con le risorse dalla build. Questa versione è distribuita ai server di sviluppo. Ogni distribuzione riceve un numero di porta in cui possiamo raggiungere questa versione specifica dell'app Web.

Diciamo che abbiamo i seguenti ambienti. DEV, RUNTESTS, UAT, PROD. Dopo la distribuzione su dev RUNTESTS, viene eseguito env per questa particolare versione. Se tutto va bene, il revisore richiesto dà al PR un approvare e può essere completato.

Questo assicura che sia molto difficile inserire codice spezzato nel master. Un altro vantaggio è che otteniamo un numero di porta per una versione specifica che può essere utilizzata per scopi dimostrativi (PO, parti interessate, analisti ...)

Ogni mattina una build da master è pianificata e distribuita su DEV e RUNTESTS e possiamo quindi scegliere di metterla in UAT e PROD se vogliamo. Poiché abbiamo la versione temporanea PRIMA che il codice colpisca il master, non è necessario attivare una build su ogni commit.