Problemi di prestazioni di ottimizzazione della matrice di test MBUnit nei test ui automatizzati

Question

Al momento stiamo utilizzando MBUnit sia per i test di unità che per i test dell'interfaccia utente.Per il test dell'interfaccia utente, i costi di configurazione per gli assi della matrice di test sono piuttosto elevati (accesso, istanza del browser, navigazione nella pagina, ecc.).Per evitare di impostarli per ogni caso di test, ci affidiamo in parte ad AssemblyFixture per gestirne alcuni.

Tuttavia, poiché non è possibile filtrare determinati casi in cui non sono applicabili a determinate combinazioni, non è possibile per noi utilizzare realmente tale ottimizzazione.Quindi attualmente stiamo eseguendo alcune delle impostazioni per caso di test, orribilmente inefficiente.

Potremmo inserire istruzioni if all'interno del codice di test per verificare la presenza di combinazioni corrette, ma non lo desideriamo neanche.Inquina il codice di prova.

Come fate a fare queste ottimizzazioni?o gestione della matrice di test?Esiste una pratica migliore, in un altro framework di test?

Answer 1

Fino a poco tempo fa, ho sempre pensato all'automazione dell'interfaccia utente come a un test black box in cui i miei test dell'interfaccia utente si basano su un'applicazione o un sito web completamente autonomo. Di conseguenza, i test vengono eseguiti sotto il vincolo della normale esecuzione e sono soggetti a una serie di problemi di sovraccarico ambientale.

Recentemente ho adottato il concetto di test dell'interfaccia utente "superficiale" e "profondo" in cui ogni serie di test viene eseguita in una configurazione ottimizzata per alleviare le differenze ambientali e velocizzare le cose. Ad esempio, il controller di accesso viene sostituito con un meccanismo che evita il sovraccarico di accesso OAuth ed è hardcoded con nomi utente fissi. Il catalogo dei prodotti salta la ricerca nel database ed è hardcoded con alcuni elementi fissi. Il backend dell'e-commerce viene sostituito per eseguire operazioni rapide che accettano / rifiutano le transazioni in base alla carta di credito e all'importo.

In una configurazione "superficiale" posso eseguire test "approfonditi" rispetto alla logica dell'interfaccia utente. Quando passo a una configurazione "profonda", assomiglia alla produzione e posso eseguire test "superficiali" di componenti completamente integrati come login, catalogo prodotti, ricerca, ecc.

È necessaria una combinazione di strategie di test.

Answer 2

Può essere il ui-test-automation-bestl'articolo sulle pratiche è utile per te.Ha alcuni esempi su come migliorare le prestazioni dell'automazione dei test dell'interfaccia utente riducendo al minimo gli accessi e le modifiche al contesto.