Database
 sql >> Database >  >> RDS >> Database

Test automatizzato dell'applicazione desktop:panoramica di convenienza e framework

Introduzione

Sicuramente hai sentito parlare di test di regressione e di accettazione. Ma sai quanto viene effettivamente speso per i test di accettazione in un progetto?
Possiamo ottenere rapidamente una risposta a questo con l'aiuto di un sistema di monitoraggio del tempo come TMetric.
Sul nostro progetto, test di accettazione un'applicazione desktop di circa 100 assiemi ha richiesto più di 2 settimane persona. I nuovi specialisti del controllo qualità che non conoscevano bene l'applicazione stavano incontrando le maggiori difficoltà. Rispetto a specialisti QA più esperti, hanno dedicato molto più tempo a ciascun test case.
Tuttavia, a mio avviso, la parte più spiacevole è stata questa:se vengono rilevati errori critici prima del rilascio, è necessario eseguire nuovamente i test di accettazione dopo che questi errori sono stati corretti.
Gli unit test scritti hanno aiutato un po', ma hanno comunque ridotto per lo più il tempo dedicato ai test di regressione. Con questo, quando la quantità di test manuali ha raggiunto un livello critico, abbiamo iniziato a passare all'automazione.

ROI

Prima di scrivere test automatizzati dell'interfaccia utente, dovevamo valutare quanto fossero redditizi i nostri investimenti. Lo abbiamo fatto con l'aiuto del ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Anche il calcolo del ROI dei test dell'interfaccia utente è diventato un compito interessante con più variabili sconosciute:

ROI =Profitto/Spese
o
ROI =(Profitto – Spese)/Spese

In questa fase, avevamo bisogno di un piccolo prototipo che ci aiutasse a stimare tutte le spese necessarie. Ha mostrato risultati molto peculiari:l'esecuzione dei test di accettazione richiede all'incirca lo stesso tempo dell'automazione di questo processo. All'inizio queste informazioni sembravano discutibili, ma quando abbiamo indagato ulteriormente, le ragioni sono diventate chiare:

  • I nuovi specialisti del controllo qualità potrebbero avere una comprensione limitata dei passaggi descritti nei casi di test. Quando ciò accade, alcune persone saranno coinvolte nei test di accettazione per aiutare a capire meglio la situazione. In questo caso, dovremmo anche tenere a mente la questione di quanto siano rilevanti le informazioni di cui disponiamo sulle impostazioni e i requisiti ambientali.
  • A volte le persone coinvolte nei test di accettazione dedicano del tempo all'apprendimento della documentazione tecnica.
  • L'app stessa interagisce con un insieme specifico di servizi. Se uno di questi non è disponibile, gli specialisti del QA meno esperti trascorreranno del tempo a descrivere i bug che gli sviluppatori, a loro volta, indagheranno. Di conseguenza, si perde tempo perché il servizio necessario non è stato eseguito correttamente dopo un blackout/aggiornamento hardware/riavvio del computer.
  • I computer dei tester QA non sono molto potenti. Se non c'è SSD, lo noterai già durante l'installazione. Inoltre, se l'app funziona con un carico pesante, è possibile che venga utilizzato un file di paging lento.
  • A essere onesti, ci siamo lasciati trasportare e ci siamo dimenticati che stiamo lavorando con l'automazione. A proposito, hai chiuso la scheda Youtube nel tuo browser?

Ora, torniamo al ROI. Per semplificare le cose, i calcoli sono stati eseguiti in base al tempo. Calcoliamo il profitto come risparmio sui test manuali e il periodo di tempo che esamineremo è di un anno:

Profitto =(X – Y) * N =(60 – 1) * 8 =472 giorni

X – tempo impiegato per i test manuali (60 giorni)
Y – tempo dedicato all'esecuzione dei test automatizzati (1 giorno)
N – il tempo in cui è stata eseguita l'accettazione

Successivamente, esamineremo le spese:

Spese =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80

A – Il costo della licenza dello strumento di automazione. Nel nostro caso è stato utilizzato uno strumento gratuito.
B – Formazione di uno specialista QA (10 giorni)
C – Preparazione dell'infrastruttura (5 giorni)
D – Sviluppo di test (50 giorni)
E – Esecuzione dei test e descrizione dei bug scoperti durante il processo (7 giorni)
F – Manutenzione del test (8 giorni)

Totale:

ROI =Profitto / Spese =472 / 80 =5,9

Naturalmente, alcuni degli aspetti qui sono stimati. Per valutare i nostri calcoli, abbiamo dedicato del tempo a studiare le capacità offerte dalle soluzioni a pagamento e da vari calcolatori del ROI. Con questo, abbiamo calcolato il valore medio del ROI di 2 o 3, che è un ottimo risultato.

Strutture esistenti

Dopo aver esaminato le questioni organizzative, concentriamoci su questioni di tipo tecnico. Il più importante di questi è stata la scelta di un framework per automatizzare il test della nostra applicazione desktop. Avevamo i seguenti requisiti in base alle caratteristiche del nostro progetto:

  • I test verranno sviluppati ed eseguiti su macchine Windows
  • Il framework dovrebbe essere adattato per testare le applicazioni desktop
  • Il test dell'interfaccia utente può essere integrato nel processo CI. Stavamo già usando Jenkins, quindi era preferibile qui
  • La possibilità di scrivere test in un IDE intuitivo:deve avere l'evidenziazione della sintassi, la navigazione degli script di test e il completamento del codice in stile IntelliSense
  • Spese minime per la formazione QA. Per alcuni motivi, i nostri specialisti del controllo qualità non volevano scrivere test in Brainfuck
  • È preferibile una community su Stack Overflow, MSDN, ecc.

Test completato

Questa piattaforma inizialmente ci ha attratto per la sua maturità, che ha dato speranze per quanto riguarda gli aspetti tecnici.
La prima cosa che abbiamo riscontrato è stato un IDE instabile e piuttosto obsoleto. L'ambiente ha gestito l'evidenziazione della sintassi in modo più o meno decente, ma c'erano problemi significativi con la navigazione (Vai alla definizione), la ricerca e il completamento automatico del codice:questa funzionalità non funzionava affatto circa il 60% delle volte. Il registratore integrato e un analogo Inspect hanno funzionato bene. Alla fine, l'IDE ci ha dato una spiacevole sorpresa quando ha iniziato a trasmettere argomenti all'applicazione. Ciò, prevedibilmente, ha causato errori nelle prestazioni dell'applicazione:

--no-sandbox
program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent

In questa fase, abbiamo coinvolto il supporto di TestComplete nella situazione per cercare di risparmiare tempo e valutare la qualità del supporto tecnico prima di acquistare potenzialmente una licenza. Dopo che alcune lettere sono state inviate al supporto tecnico, abbiamo ricevuto una risposta:dovremmo ignorare gli argomenti passati alla domanda. Strano, vero? Indagando ulteriormente, abbiamo scoperto che questi argomenti sono necessari per testare le applicazioni che utilizzano CEF. Nella nostra lettera successiva, abbiamo affermato che utilizziamo il CEF e gli specialisti del supporto ci hanno detto di non ignorare le argomentazioni. Quando abbiamo chiesto come usarli esattamente, la risposta è tornata a "Ignora gli argomenti".
Lasciando la nostra conversazione con il supporto tecnico, ci siamo rivolti alla documentazione dell'IDE (senza troppe speranze). Aveva più informazioni, ma non abbiamo trovato nulla attinente al caso in questione. Inoltre, secondo questa stessa documentazione, l'IDE avrebbe dovuto comportarsi in modo diverso dall'inizio.
Si presume che i test in TestComplete verranno scritti utilizzando VBScript.

Se lo guardi abbastanza a lungo, puoi sentire questo. Microsoft suggerisce di convertire questa "meraviglia" in script di PowerShell. In alternativa, è possibile utilizzare JavaScript e Python, il che aiuta la situazione.

Come strumento gratuito, TestComplete sarebbe sopportabile, ma il loro sito ha una pagina dei prezzi e i prezzi sono per utente. Di conseguenza, questo è ciò che otterremo dopo l'acquisto dello strumento:

  • IDE che vuoi chiudere
  • Compatibilità con gli script del 1996
  • Un registratore in modo da non scrivere tutto manualmente
  • Un altro Ispezionare, ma con campanelli e fischietti
  • 2 tipi di risposte di supporto tecnico
  • Documentazione che non rappresenta la realtà

Il peggior affare di sempre, andiamo avanti.

Interfaccia utente codificata

Ritirata tattica, raggruppamento e affianchiamo la questione. Da un lato, abbiamo imparato a usare Visual Studio come IDE. D'altra parte, il nostro approccio era basato sui componenti dell'interfaccia utente di DevExpress che stiamo utilizzando. Di conseguenza, abbiamo trovato alcune informazioni interessanti sul framework dell'interfaccia utente codificato che è ufficialmente utilizzato in DevExpress per automatizzare i test dell'interfaccia utente. Questo framework è integrato così tanto nel processo di test interno che esiste persino un'estensione di Visual Studio per esso.
C'era una vasta community, Microsoft ha promosso lo strumento sul proprio sito Web e questo prodotto è stato anche menzionato in "Microsoft Canale di Visual Studio”. Per farla breve, tutto sembrava promettente e abbiamo iniziato a preparare il framework.
Il primo requisito che abbiamo riscontrato è stato Visual Studio Enterprise. Inoltre, questa versione di Visual Studio non era necessaria solo per scrivere i test, ma anche per eseguirli. Ciò significa che anche mstest attraverso il quale verrà eseguito l'avvio in caso di CI dovrebbe far parte dell'edizione Enterprise.
Tutti gli strumenti dell'interfaccia utente codificati necessari possono essere installati abilitando le caselle di controllo corrispondenti quando VS viene installato o modificato.

L'approccio alla scrittura dei test è stato piuttosto piacevole:i comandi integrati nella shell hanno permesso di lanciare velocemente un registratore che genera uno unit test e una classe “map” che descrive l'interfaccia utente. Ulteriori strumenti integrati in VS fornivano la possibilità di creare classi di test separate senza chiamare il codice.
L'unica particolarità che abbiamo notato era una classe parziale che aveva la descrizione del controllo ed era divisa in due parti. Insieme a molte altre cose, è descritto nella documentazione. Questa documentazione è sufficiente per un comodo processo di lavoro:esempi di codice e screenshot rendono tutte le informazioni tecniche facilmente accessibili e di facile comprensione. Per dirla semplicemente, quando il registratore descrive l'interfaccia utente, viene generato un file "Designer.cs". Questo file è responsabile del riutilizzo del codice che descrive l'interfaccia utente. Tutto ciò che il registratore non è in grado di gestire deve essere scritto manualmente e salvato da qualche parte al di fuori della parte generata automaticamente dalla classe. Questo è molto simile alle classi parziali scritte da VS deigners durante la creazione dei controlli. La priorità delle operazioni eseguite sui controlli e dei relativi controlli di stato è descritta in un metodo a cui il registratore aggiunge utilmente un attributo TestMethod standard.
Le nuvole hanno iniziato a raccogliersi sul framework quando abbiamo iniziato a esaminare le cose generate dal registratore . Prima di tutto, ha oscurato alcuni dei problemi dell'applicazione:la proprietà Name di alcuni controlli non è stata specificata e il registratore ha ritenuto accettabile definire questa ridicola istanza di violazione delle regole e ha cercato i controlli attraverso il testo. Inoltre, ha gestito controlli complessi in modo molto inefficiente. Ad esempio, i nodi TreeView sono stati ricercati per indice di nodo che ha reso inutilizzabile la classe "mappa" creata in caso di espansione dell'interfaccia. E il valore del registratore è diminuito notevolmente ai nostri occhi:che senso ha generare automaticamente il codice se è necessario controllarlo in seguito?
Potremmo fare pace con tutte queste cose e trovare una soluzione lodevole, ma all'improvviso, il tuono ha colpito:Microsoft ha affermato che questa tecnologia è ormai obsoleta. Con questo, VS 2019 è diventata l'ultima versione di Visual Studio che supporta l'interfaccia utente codificata. La possibilità di dipendere da VS 2019 ora e con un paio di anni di anticipo non sembrava così spaventosa, ma il nostro progetto è piuttosto ampio, quindi le difficoltà potrebbero iniziare da qualche parte (2025, per esempio).
Riassumiamo. Con l'interfaccia utente codificata avremo:

  • Un potente IDE a pagamento
  • Tutta l'infrastruttura già creata per i test:sia dal lato dell'IDE che del nostro CI
  • La possibilità di chiedere aiuto a qualsiasi sviluppatore del nostro progetto perché stiamo scrivendo test in C# nello stesso IDE
  • Un'ampia quantità di documentazione di buona qualità
  • Alcuni tristi specialisti del controllo qualità che hanno inserito il loro codice nella parte autogenerata della classe e poi lo hanno perso durante il processo di autogenerazione
  • Molto codice generato che funziona e che è necessario sottoporre a una revisione rigorosa
  • Un approccio scandalosamente trasparente alla CI:puoi scrivere codice per avviare i test tramite mstest ad occhi chiusi
  • Un gigante rosso dell'automazione in lenta morte che cresce costantemente da nuovi test ed è pericolosamente vicino a trasformarsi o in una nana bianca in dissolvenza rappresentata da una macchina assolutamente isolata con un software irreversibilmente obsoleto o in un'esplosione di supernova quando il progetto implode sotto il pressione di nuovi aggiornamenti.

Tutto suonava bene tranne l'ultimo punto. Ecco perché dovevamo continuare la nostra ricerca.

TestStack.White

Stavamo lavorando ai test di prototipazione con l'aiuto di White, parallelamente allo studio della funzionalità dell'interfaccia utente codificata.
White stesso è un involucro attorno alle librerie "Microsoft.Automation" che sembravano molto promettenti e anche White è simile a Coded interfaccia utente. Tuttavia, a un esame più attento, abbiamo scoperto che era molto più austero e lo si poteva notare ovunque, dal fatto che non c'era un registratore all'effettiva struttura del test. Ad esempio, eseguire l'app, cercare una finestra e premere il pulsante "Esegui" ha il seguente aspetto:

var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);

var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);

var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();

app.WaitWhileBusy();

Anche se non ci sono lamentele quando si tratta di eseguire l'applicazione, la necessità di lavorare con la classe InvokePattern è molto discutibile. Anche la classe InitializeOption sembra strana perché ha accesso al membro statico WithCache, ma dovrebbe essere usata rigorosamente internamente:

public class InitializeOption {
//
// Summary:
//     This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }

//
// Summary:
//     Specify the unique identification for your window. White remembers the location
//     of UIItems inside a window as you find them. Next time when items inside the
//     same window is found they are located first based on position which is faster.
//
// Parameters:
//   identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}

Strane decisioni come questa sono ovunque e il framework risulta essere troppo astratto per il QA.

La documentazione è di discreta qualità e ha lasciato una buona impressione generale. Il codice sorgente del progetto era ospitato su github, ma l'ultimo commit risaliva all'8 gennaio 2016.
Riassumendo le informazioni su White, avremmo:

  • Documentazione decente
  • Accesso al codice sorgente
  • Una piccola comunità
  • La necessità di spiegare a tutti gli specialisti del QA che il comportamento del controllo è implementato attraverso la classe Pattern
  • Un vecchio repository da cui avremmo sicuramente bisogno di fork

La parte più spiacevole è stata la necessità di sviluppare una nostra struttura, che vorremmo evitare. Quindi dovevamo andare avanti.

Appio

Abbiamo già incontrato Appium nella nostra ricerca, ma abbiamo iniziato a prenderlo seriamente in considerazione solo dopo che Microsoft ha smesso di utilizzare l'interfaccia utente codificata.
A prima vista, i test con l'aiuto di Appium sembrano una slot machine con tre rulli. La prima mostra la lingua per la quale esiste un'API che consente l'interazione con il driver. Ciò offre la possibilità di scrivere test in qualsiasi linguaggio familiare:Python, C#, Java, ecc. La seconda bobina mostra l'app del driver che funge da livello intermedio tra i test e il prodotto che stiamo testando. Come descritto nella documentazione, l'interazione con i test viene eseguita utilizzando il protocollo JSON Wire:questo è ciò che ci dà effettivamente la possibilità di scrivere test in qualsiasi lingua. E la terza bobina mostra l'oggetto che stiamo testando. Non importa se si tratta di un sito Web, un'app mobile o un'app desktop purché il driver corrispondente sia in esecuzione. Come puoi vedere, i componenti sono elegantemente intercambiabili.
La stima della rilevanza del pacchetto è stata soddisfacente:nella pagina Github, abbiamo potuto vedere che il repository aveva nuovi commit. Durante l'esame del repository WinAppDriver, abbiamo appreso che conteneva persino un registratore.
Abbiamo iniziato a notare alcuni problemi durante la scrittura di un prototipo. Ad esempio, poiché il framework è troppo multiuso, il WindowsElement responsabile del controllo desktop ha un metodo FindElementByCssSelector che genera la seguente eccezione durante l'esecuzione:“Errore imprevisto. Comando non implementato:la strategia CSS selector locator non è supportata”. Nel prossimo articolo parleremo più in dettaglio dei problemi che abbiamo riscontrato lavorando con questo framework, ma per ora vorrei dire che siamo riusciti a gestirli tutti.

In sintesi, ecco cosa avremo durante l'utilizzo di Appium:

  • La possibilità di testare la funzionalità dell'applicazione che richiede l'interazione con un browser (apertura della pagina di feedback, attivazione online, controllo della consegna della posta elettronica) nell'ambito di un'infrastruttura e un test
  • La possibilità di lavorare con qualsiasi edizione di Visual Studio
  • La possibilità di testare un'applicazione desktop che utilizza un browser per eseguire il rendering dell'interfaccia utente. Un buon esempio potrebbe essere Azure Data Studio
  • Tutti i vantaggi che otteniamo con l'interfaccia utente codificata
  • Un framework gratuito che Microsoft consiglia di utilizzare
  • Infrastruttura familiare agli specialisti del controllo qualità che hanno lavorato con Selenium
  • Un repository aggiornato con nuovi commit
  • Una community abbastanza ampia che, tuttavia, non è grande quanto la community di Coded UI
  • Un registratore con funzionalità limitate
  • La necessità di eseguire un'applicazione driver per il test. Non molto conveniente, ma ha la sua funzionalità di registrazione
  • Molte opportunità per spararsi un piede a causa della sfortunata eredità di WindowsElement da AppiumWebElement

Esaminando tutti i punti con i requisiti per i framework e confrontando tutti i problemi riscontrati in ciascuno di questi framework, abbiamo finalmente scelto Appium.

Conclusione

È stato interessante lavorare con tutti questi framework perché ognuno di essi si basava su una filosofia unica di approccio ai test automatizzati. Una parte di loro ha iniziato il suo percorso solo mentre altri stavano raggiungendo l'eclissi o sono già svaniti. Puoi evitare di perderti nelle numerose soluzioni disponibili creando un elenco di requisiti specifici per lo strumento e disponendo di un team responsabile con un'interazione consolidata tra i suoi membri. E non dimenticare che i test futuri sono un progetto tanto quanto lo è il codice al solito, con un backlog, schede, CI, refactoring e tutto il resto.