Come Abilitare la Riutilizzabilità con i Repository di Oggetti nei Test di Automazione
Come sviluppatori di automazione, non proviamo forse una certa soddisfazione quando sentiamo dal team di test manuali, o dal cliente, quanto hanno beneficiato utilizzando l’automazione che abbiamo realizzato? Per questo motivo, sosteniamo l’importanza di una suite di automazione di alta qualità, che sia non solo robusta, ma anche facilmente adattabile agli aggiornamenti richiesti da qualsiasi cambiamento di requisiti aziendali o tecnici. La manutenzione deve essere semplice—ce lo ricordiamo sempre. Ma quali sono i modi per garantirlo?
Tra i vari modi in cui possiamo garantire l’alta qualità di una suite di Test Automation, uno consiste nell’assicurare la riusabilità—non solo riutilizzando i passaggi di test comuni, ma anche riutilizzando gli oggetti UI utilizzati frequentemente. In questo articolo spiegherò come possiamo utilizzare i repository degli oggetti per migliorare la riusabilità riutilizzando gli oggetti in un progetto di test di automazione UI.
- Cosa è un Object Repository nei Test di Automazione?
- Perché è importante?
- Best practice da seguire nell’uso dei repository degli oggetti
- Come creare i repository degli oggetti (Esempi)
Cosa è un Object Repository nei Test di Automazione?
Quando inizi a progettare la suite di automazione dei test, la maggior parte di noi si assicura di non riscrivere blocchi di codice già esistenti. A tale scopo, creiamo funzioni riutilizzabili e rendiamo i blocchi di codice disponibili in librerie di codice. Tuttavia, hai mai riutilizzato gli oggetti UI più utilizzati? Se non lo hai fatto, lascia che ti spieghi come puoi farlo partendo da un object repository come base.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
L’object repository è una raccolta di oggetti UI che vengono comunemente associati tra loro. Questo non solo aumenta la riusabilità, ma assicura anche affidabilità e gestione degli elementi UI nella suite di automazione.
Durante la creazione degli script di test automation, collegherai i passaggi degli script di test a ciascuno di questi oggetti UI. Ad esempio, tramite –
- Digitare in un oggetto UI di tipo casella di testo
- Recuperare il testo da un oggetto UI di tipo etichetta (label)
- Fare clic sull’oggetto hyperlink ... e così via.
Ora, come puoi aumentare la riusabilità riutilizzando gli oggetti UI su cui lavorano i tuoi script?
Beh, se lo strumento di automazione dei test che utilizzi dispone di un “object repository”, è semplice. Utilizzando un object repository, puoi raggruppare gli oggetti UI e aggiungere, eliminare, gestire o aggiornare tali oggetti dal repository in modo organizzato. Puoi così riutilizzare gli oggetti semplicemente facendovi riferimento.
Vediamo una situazione in cui non hai utilizzato un OR nella tua suite di automazione dei test. In questo caso, per script di automazione differenti che usano lo stesso widget UI, aggiungeresti più copie dello stesso oggetto UI in ogni script per eseguire azioni su di esso.
Ora, immaginiamo una situazione in cui invece usi un OR. In questo caso, avresti un unico luogo/repository in cui archiviare gli oggetti UI. Così, in ogni script di test che deve agire sullo stesso oggetto/widget UI, avverrebbe il collegamento allo stesso oggetto UI conservato nell’OR. Ci sarebbe una sola copia dell’oggetto UI nella suite di test, mentre più script fanno riferimento/chiamano lo stesso oggetto. Ed è qui che entra in gioco la riusabilità!
Perché è importante?
La mia prima esperienza con un OR è stata quando l’ho utilizzato con IBM Rational Functional Test Automation tool. Da allora, ogni volta che imparo un nuovo strumento, sono curioso di vedere se offre o meno la funzionalità di OR.
La prima volta che ho usato un OR è stato quando il nostro team stava automatizzando una vasta console Web UI amministrativa composta da diverse pagine. Avevamo oltre 100 casi di test da automatizzare. Se non avessimo utilizzato l’OR, sarebbe stata una sfida enorme da automatizzare. Dopo un’analisi, abbiamo concluso che la suite di test automation che volevamo realizzare rappresentava il caso ideale d’uso per un OR.
Perché?
1. Ognuno dei casi di test da automatizzare presentava diversi sotto-flussi in comune, e di conseguenza aveva widget UI associati in comune.
Dato che c’erano sotto-flussi comuni, era evidente la presenza di oggetti UI comuni nei vari scenari. Non volevamo aggiungere copie degli stessi oggetti UI più e più volte, quindi abbiamo deciso di riutilizzarli.
Ad esempio, un gruppo di casi di test doveva navigare attraverso gli stessi link di menu prima di eseguire una serie di passaggi. Abbiamo quindi previsto un repository dedicato per archiviare e gestire tutti i link di navigazione. Successivamente, siamo stati in grado di riutilizzare questi link dal file OR.
2. Ci era stato comunicato che in futuro potevano esserci aggiornamenti dell’interfaccia—in termini di hyperlink, etichette, ecc.
Di conseguenza, volevamo assicurarci che, in caso di aggiornamento dell’interfaccia, la suite di automazione dei test fosse facilmente adattabile ai cambiamenti e che la manutenzione risultasse rapida e semplice.
Ed è qui che l’OR ci è venuto in aiuto: non dovevamo modificare i repository degli oggetti UI in ogni copia presente dello stesso oggetto. Ogni volta che c’era una modifica, bastava aggiornare l’oggetto associato nell’OR, e gli script di test avrebbero utilizzato l’oggetto UI aggiornato.
3. Dovevamo costruire una suite di automazione dei test con più di 100 script in un mese!
Ecco dove è emerso un altro vantaggio dell'utilizzo di un OR: adottando l'approccio di creare un OR e non dover tutti ri-aggiungere gli stessi oggetti UI, abbiamo risparmiato tempo. Abbiamo costruito un OR ben organizzato e tutto ciò che dovevamo fare era costruire il nostro codice attorno agli oggetti che avevamo strutturato nell'OR.
Ci siamo concentrati sull’obiettivo del caso di test e sulla logica di business dei test case invece di perdere tempo a reinventare la ruota aggiungendo oggetti per ogni script di test. Abbiamo risparmiato tempo e alla fine consegnato la suite di automazione dei test nel mese stabilito!
Best practice da seguire quando si utilizzano gli Object Repository
Ora che sai in quali situazioni un repository di oggetti UI può essere utile, non vuoi sapere cosa lo rende efficace?
1. Come team, costruite un obiettivo comune di riutilizzabilità. Capite insieme perché può aiutare il vostro team di automazione, il team di testing manuale e, infine, il cliente.
2. Durante lo sviluppo della suite di automazione dei test, come team rimanete sempre sincronizzati e informati sugli oggetti che state creando. Definite un insieme di regole di raggruppamento e convenzioni di denominazione da rispettare. Quando iniziate, potete stabilire un piano su come organizzare e archiviare ciascuno dei file OR. Ad esempio, oggetti del menu di navigazione in un file OR, oggetti della pagina di login in un altro file OR, ecc. Inoltre, potete decidere le convenzioni di denominazione per gli oggetti, così da trovarli facilmente.
3. Assicuratevi di nominare gli oggetti UI in modo che siano leggibili, facili da trovare e subito riconoscibili. Date ai vostri oggetti UI nomi tali che chiunque debba aggiornare il repository possa trovare facilmente ciò che cerca. Nell’esempio che segue mostrerò una situazione di questo tipo.
Come creare Object Repository (Esempi)
Vediamo ora concretamente come iniziare velocemente a lavorare con i repository di oggetti. Strumenti come UFT, IBM RFT, UiPath Test Automation Suite e Power Automate hanno i repository di oggetti integrati. Allora, cosa aspetti? Fidati, è davvero semplice!
Ecco un esempio in cui ho creato un OR in riferimento al sito QAL:
Osserva l’interfaccia UI sopra: ho raggruppato insieme tutti i widget collegati all’azione sui widget della login, visto che sono comuni a diversi casi di test. Ho poi raggruppato i link di navigazione. Se registriamo questi oggetti in un gruppo, allora quando tutti gli script di test useranno sicuramente questo gruppo di oggetti link, questi oggetti potranno essere riutilizzati invece di doverli ri-aggiungere nel repository.
Esempio di utilizzo dell'Object Repository in UiPath
Ecco come appare un object repository nello strumento UiPath:
In questo esempio di object repository, ho organizzato gli oggetti della “pagina di login” in un gruppo e quelli dei “Principali link di navigazione” in un altro gruppo. Così, se dovessi costruire diversi script per — per esempio — testare la pagina di login, avrei tutti gli script che "richiamano" gli stessi oggetti che ho inserito nella "Login Page".
Esempio di utilizzo dell'Object Repository in PowerAutomate
Ecco come appare l'object repository nello strumento PowerAutomate:
Come dicevo prima, la chiave del riutilizzo è anche nominare gli oggetti in modo che siano facilmente identificabili più avanti. Osserva l’oggetto UI “meprmath_quiz”. Al contrario degli altri campi, non è così facile capire a cosa faccia riferimento. Quindi, in un caso come sopra, anche se quando ho aggiunto l’oggetto UI per la casella di testo "quiz" è stato suggerito il nome campo "meprmath_quiz", potremmo magari chiamarlo "login_add" o simile, così da trovarlo facilmente durante la fase di automazione e manutenzione dell’OR.
Conclusione
Allora, tu come utilizzi l’OR nel tuo strumento preferito di automazione dei test? Ci piacerebbe saperlo.
Spero che questo articolo ti aiuti a capire quanto l’OR aiuti il team a lungo termine. Siamo fortunati a vivere in un’epoca in cui la maggior parte dei tool di automazione dei test dispone già della funzione OR. Quindi tutto ciò che devi fare è esplorare come funziona nel tuo strumento preferito!
Hai imparato qualcosa di nuovo in questo articolo? Se vuoi leggere altri articoli come questo, non dimenticare di iscriverti a The QA Lead Newsletter!
Articoli correlati:
Elenco correlato di strumenti: SOFTWARE DI TEST DELLE PRESTAZIONI PER TEAM QA
Da vedere anche:
