Dall'era glaciale ai Vendicatori usando Appium

Lezioni di avvicinamento al robot di Kite

Vorrei iniziare qui con un gancio noioso: la mia esperienza personale nel testare un'app manualmente. Poiché lo sviluppo del prodotto include la consegna in frammenti, diventa monotono per un membro del team QA eseguire le stesse azioni ancora e ancora. Ogni volta che dovevo provare qualcosa, avevo bisogno di un nuovo utente e quindi dovevo iscrivere un nuovo utente manualmente. È più noioso di quanto sembri.

È qui che entra in gioco l'automazione. E se passassimo del tempo a scrivere un codice che avrebbe fatto tutto questo noioso lavoro per noi? E se anche questo ha funzionato con precisione?

Il team QA di Kite ha svolto un bel po 'di ricerca e sviluppo per trovare gli strumenti giusti. Abbiamo deciso su Appium, poiché:

  1. È open source
  2. Non richiede il codice sorgente
  3. Non ha bisogno di alcuna strumentazione
  4. Ha tonnellate di materiale di supporto facilmente disponibili

Appium potrebbe, a prescindere, sembrare la scienza missilistica per la maggior parte di noi. Tuttavia, se segui un approccio adeguato, è possibile sfruttare appieno le sue capacità.

In questo post, metterò in evidenza gli svantaggi di un approccio classico ad Appium e in che modo il nostro approccio Robot in Kite rende Appium un'esperienza relativamente senza problemi. Abbiamo usato l'approccio Robot sulla prima app di Kite, Kite Cash. È stato lanciato a scopo di sperimentazione e si è trasformato organicamente in una rete di oltre 100.000 utenti in oltre 1.100 città.

Approccio classico

In generale, un approccio classico rende il codice strettamente accoppiato, che non è mantenibile, aumenta le ridondanze, rende difficile il refactoring e non è scalabile.

Con queste limitazioni in mente, affrontiamo Appium come una storia.

Scenario classico

Prendi in considerazione una schermata di accesso con un nome utente, una schermata della password e un pulsante di accesso. Se inserisco le credenziali corrette e faccio clic su "Accedi", dovrei essere in grado di accedere e vedere la schermata successiva.

Mentre pensiamo a un test, poniamo le seguenti domande: Cosa vogliamo ottenere? e come lo raggiungeremo? Il nostro approccio precedente associava strettamente questa coppia What and How. Tuttavia, se questa coppia viene mantenuta insieme, è difficile per un QA mantenere e ridimensionare gli script. Il problema è, inevitabilmente, che cambiano i requisiti aziendali e dobbiamo andare a cambiare il nostro test a causa di questo accoppiamento. Ecco un esempio:

Cosa si deve ottenere: passare il nome utente / la password corretti dovrebbe portare l'utente alla schermata del dashboard.

  • Inserisci il nome utente "hulk@spiderman.com"
  • Immettere la password "HS @ 1235"
  • Premi il pulsante "Accedi"
  • Verificare che sia visualizzata la schermata del dashboard

Considera il codice:

Vediamo quali problemi esistono in questo approccio:

  1. Esiste un elevato livello di duplicazione del codice, che peggiora ulteriormente le prestazioni di automazione.
  2. Il codice sopra non è leggibile. In aziende in rapida crescita come Kite (e molte altre), i nuovi membri si uniscono ai singoli team in ogni momento. Un nuovo membro non capirà questo codice e il suo scopo se si sono uniti dopo che il codice è stato scritto.
  3. Non ci sentiremo a nostro agio nel gestire questo tipo di codice nel prossimo futuro, quando aumenteranno i flussi di lavoro delle applicazioni.
  4. Qualsiasi nuova modifica dell'interfaccia utente incorporata è difficile da includere in questo tipo di codice, poiché molti refactoring - in più punti - devono essere effettuati affinché funzioni nuovamente.

Chiaramente, l'approccio classico potrebbe sembrare semplice, ma non appena le funzionalità di un'applicazione aumentano, diventa un mal di testa gestire questo codice.

Approccio robotico

E se seguissimo un approccio in cui ci concentriamo solo su Cosa vogliamo ottenere? e non Come vogliamo raggiungerlo? Vorremmo quindi creare diverse classi per come e cosa. In questo modo le categorie How e What saranno indipendenti le une dalle altre.

Il modello di test Robot è simile al Page Object Model ampiamente utilizzato, che è un modello di progettazione pensato per la creazione di un repository di oggetti per gli elementi dell'interfaccia utente per piattaforme basate sul Web.

Attualmente, facciamo affidamento su un utente manuale per eseguire azioni. E se i robot facessero tutto questo per noi? Nell'approccio Robot, sappiamo che lo schermo ci consente di inserire un nome utente / password senza preoccuparci di dove stanno andando questi valori.

Scenario di robot

Esiste un robot su UsernamePasswordScreenBot, che passa i valori nei campi nome utente / password e fa clic su "Accedi". Ora, la schermata cambia e questo robot ha il controllo solo sulla classe UsernamePasswordScreenBot. Da qui, un altro bot assume, per esempio, un ResultScreenBot per eseguire ulteriori azioni nella schermata successiva.

In altre parole, crea un robot per schermo e eseguirà le azioni richieste.

Siediti, rilassati e lascia che i robot lavorino per te.

Questo codice spiega ciò che vogliamo, cioè, essere in grado di inserire un nome utente e una password che dovrebbero accedere all'utente.

Confronto

Confrontiamo le metriche e i cambiamenti delle prestazioni nell'approccio classico e nell'approccio Robot:

  1. La duplicazione del codice è ridotta al minimo, poiché inseriamo gli ID elemento in una classe e utilizziamo sempre la stessa classe.
  2. La leggibilità del codice è migliorata, poiché un nuovo membro che si unisce al team può capire cosa sta facendo questo codice in modo più intuitivo.
  3. La gestione di tale codice e l'adattamento alle modifiche dell'interfaccia utente sono ora entrambi più facili. Cambia codice in un unico posto e questo cambiamento si riflette ovunque. Considera un esempio: nel flusso di accesso, l'ID di un elemento cambia o viene aggiunto un nuovo campo. Nell'approccio classico, dobbiamo apportare modifiche in ogni punto in cui stiamo accedendo un utente. Nell'approccio Robot, aggiungeremo o modificheremo semplicemente gli elementi nella classe UsernamePasswordScreenBot e lo chiameremo direttamente da lì.

Ambito di test dei robot

Inizialmente, potremmo pensare che i robot non siano abbastanza intelligenti da completare un test di integrità o coprire flussi negativi. Tuttavia, i tuoi robot eseguiranno test negativi, di integrità e di regressione attraverso un codice come quello qui sotto, dandoti qualche minuto in più prezioso da trascorrere durante la pausa pranzo. Per questo dobbiamo creare metodi diversi e trasmettere contenuti.

Il codice sopra mostra come è possibile creare metodi per tutti i tipi di dati che si desidera passare in una singola classe. L'approccio classico si è concentrato su cosa raggiungere e su come raggiungere del tutto. Dobbiamo liberarci di questo componente "How" per semplificare le cose.

Risparmio di tempo e sviluppo di capacità

Abbiamo risparmiato una notevole quantità di tempo e aumentato le nostre capacità passando all'approccio Robot.

  1. La nostra copertura dei test è aumentata rispetto ai test manuali.
  2. Abbiamo ridotto il tempo necessario per completare un sanità mentale da un giorno intero a 5-10 minuti.
  3. Abbiamo ridotto del 50% i tempi di creazione degli script e abbiamo risolto il problema della scalabilità.
  4. Con l'approccio dello script, possiamo creare una suite di regressione che rende i test più semplici e accurati.

Conclusione

Essendo in una startup come Kite, ho avuto la flessibilità di provare nuove cose e investire tempo nella ricerca - è per questo che sono stato in grado di trovare un nuovo approccio per l'utilizzo di Appium. Mi imbatto in pratiche migliori ogni giorno grazie al team di supporto con cui lavoro in Kite. Attraverso scambi aperti, siamo stati in grado di innovare in modo da rendere il nostro lavoro più efficace, efficiente e divertente. Se il tuo posto di lavoro lo supporta, ti incoraggio a organizzare sessioni di condivisione delle conoscenze e a creare ore dedicate ogni settimana per sperimentare nuove tecniche; è il modo più efficace per sviluppare strategie a lungo termine per mantenere i team uniti e costantemente innovativi.