Articolo
12/22/2016

Connect(); 2016

Volume 31 Numero 12

Il presente articolo è stato tradotto automaticamente.

Connect();: Test per dispositivi mobili - Nuove dimensioni per i test per le app per dispositivi mobili automatizzate con Xamarin Test Cloud

Da Justin Raczak; 2016

Negli ultimi anni si è verificato un cambiamento sostanziale nel modo team build e offrire soluzioni software. Se si era ritenuto una volta lungo i processi di raccolta dei requisiti si assicurerebbero che il recapito di un prodotto perfetto con la prima versione, ora è noto che un rapido apprendimento associata con rapida iterazione è la chiave del successo. Nonché le modifiche di pensare, pertanto, anche i flussi di lavoro. Cicli di sviluppo per la durata di mesi o anni seguite da fasi di controllo di Qualità a cascata di lunga durata non facilitano l'apprendimento rapido. Cicli di commenti devono essere abbreviati e piccole modifiche implementate rapidamente e rilasciati agli utenti. Per distribuire facilmente, è necessario conoscere che software è in uno stato valido in qualsiasi momento. Automazione di test in questo modo possibile.

Il test automatico consente di testare le applicazioni in modi che utilizzato per richiedere diversi giorni o settimane. Anziché attendere fino alla fine di uno sprint costituita da centinaia di righe di nuovo codice, è possibile testare piccole modifiche aggiunte con ogni commit. Questa aree di test continuo escluso non appena si sono introdotte e riduce il tempo necessario per eseguirne il debug. E poiché il comportamento dell'applicazione viene convalidato continuamente, è necessario il livello di confidenza per distribuire agli utenti ogni volta che si è pronti. I test automatizzati rende possibile un mondo in cui individuare difetti e fornire una correzione all'interno dello stesso giorno. Ma l'ecosistema mobile presenta difficoltà specifiche con un panorama diverso di dispositivi mobili e ai responsabili del sistema operativo.

Xamarin Test Cloud rendono veloce e semplice ridimensionare i test automatizzati con modifiche minime al flusso di lavoro esistente. Che offre più di 400 configurazioni univoco del dispositivo, Test Cloud consente di convalidare il comportamento dell'applicazione nei modelli di dispositivi e versioni del sistema operativo che sono importanti per gli utenti senza la spesa overhead di gestione fornito con la compilazione e gestione di laboratorio il proprio dispositivo. Nella maggior parte dei casi, è possibile accedere a questo valore elevato e poche su Nessuna modifica al codice.

Test Cloud supporta la creazione di test in c# (test dell'interfaccia utente), Ruby (Calabash) e Java (Appium ed Espresso). Nella parte di modifica di progetto di questo articolo, verrà concentrarsi sul nostro inoltre framework di test più richieste, Appium con JUnit e illustra le modifiche è necessario apportare al progetto per eseguire i test esistenti nel Cloud di Test. Verrà inoltre dare un'occhiata all'interfaccia Web in cui verranno esaminati i risultati del test e risoluzione dei test non superati. Le modifiche specifiche necessarie potrebbero cambiare nel tempo. È possibile trovare la versione più recente di queste istruzioni in bit.ly/2dhp2VQ.

In questo esempio presuppongono le seguenti condizioni preliminari:

Un account di Test Cloud attivo (iscrizione bit.ly/2e3YgTy)
Uno strumento da riga di comando installato (le istruzioni sono bit.ly/2dcrbXS)
Un progetto di applicazione Android native
Un gruppo esistente di Appium test scritti in Java con JUnit (almeno versione 4.9) conforme a Appium 1.5
Sistema di compilazione Maven (almeno versione 3.3.9)

Modifiche al sistema di compilazione

Prima di utilizzare Test Cloud, è necessario aggiungere la dipendenza per verificare le attività per preparare i file necessari sono disponibili per la compilazione.

Aggiungere la dipendenza Cloud Test per includere Test Cloud nel progetto e verificare i driver iOS e Android avanzati sono disponibili in fase di compilazione, aggiungere la dipendenza seguente al file POM. XML:

<dependency>
  <groupId>com.xamarin.testcloud</groupId>
  <artifactId>appium</artifactId>
  <version>1.0</version>
</dependency>

Aggiungere il profilo caricare aggiungere il profilo da figura 1 il file POM. XML all'interno di <profiles>tag.</profiles> Se dispone già di un <profiles>sezione, crearne uno e aggiungere il profilo.</profiles> Questo profilo verrà pack tutte le dipendenze e le classi di test nella cartella di destinazione/caricamento in cui è possibile quindi caricarli Test cloud.

Figura 1 Test Cloud caricamento profilo

<profile>
  <id>prepare-for-upload</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <version>2.10</version>
        <executions>
          <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals>
              <goal>copy-dependencies</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/dependency-jars/</outputDirectory>
              <useRepositoryLayout>true</useRepositoryLayout>
              <copyPom>true</copyPom>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
          <execution>
            <id>copy-pom-file</id>
            <phase>package</phase>
            <goals>
              <goal>testResources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/</outputDirectory>
              <resources>
                <resource>
                  <directory>
                    ${project.basedir}
                  </directory>
                  <includes>
                    <include>pom.xml</include>
                  </includes>
                </resource>
              </resources>
            </configuration>
          </execution>
          <execution>
            <id>copy-testclasses</id>
            <phase>package</phase>
            <goals>
              <goal>testResources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/test-classes</outputDirectory>
              <resources>
                <resource>
                  <directory>
                    ${project.build.testOutputDirectory}
                  </directory>
                </resource>
              </resources>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

Modifiche ai test

Dopo avere configurato la compilazione, è necessario modificare le classi di test per sfruttare le estensioni del linguaggio Cloud Test.

Aggiungere le importazioni per le classi di Test importare le classi di test i pacchetti seguenti:

import com.xamarin.testcloud.appium.Factory;
import com.xamarin.testcloud.appium.EnhancedAndroidDriver;
import org.junit.rules.TestWatcher;
import org.junit.Rule;

Creare un'istanza di TestWatcher inserire la creazione di istanze in una delle classi di test:

@Rule
public TestWatcher watcher = Factory.createWatcher();

Aggiornare il Driver dichiarazioni sostituire ogni dichiarazione di AndroidDriver<MobileElement> con EnhancedAndroidDriver<MobileElement>, come illustrato di seguito:</MobileElement> </MobileElement>

private static EnhancedAndroidDriver<MobileElement> driver;

Aggiornare il Driver creazioni di istanze sostituire ogni istanza del driver di tale che le righe in forma di:

Driver = new AndroidDriver<MobileElement>(url, capabilities);

diventa:

Driver = new EnhancedAndroidDriver<MobileElement>(url, capabilities);

Il driver avanzato consente di passi di test utilizzando driver.label("myTestStepLabel") "label". Questo metodo genererà un'etichetta di passaggio test e una schermata di accompagnamento che possono essere visualizzato nel report di test nel Test Cloud. Consiglia di chiamare etichetta nel metodo @After, che acquisisce una schermata dell'applicazione nel suo stato finale prima che il completamento del test. Nella schermata verrà eseguita anche se il test ha esito negativo, che potrebbe fornire approfondimenti utili perché non riesce. In pratica, ciò può avere un aspetto simile:

@After
  public void tearDown(){
    driver.label("Stopping app");
    driver.quit();
  }

Carica nel Cloud di Test

Ora che il progetto è dotato di tutti i prerequisiti, si è pronti per preparare i file ed eseguire un'esecuzione nel Cloud di Test. Prima di procedere con la procedura di caricamento, è consigliabile provare un'esecuzione locale e verificare che tutto funziona come previsto. Se è necessario per la risoluzione dei problemi delle modifiche di configurazione che appena creata, è molto più veloce per eseguire questa operazione in locale.

Per comprimere le classi di test e tutte le dipendenze nella cartella di destinazione/caricare, eseguire il comando seguente:

mvn –DskipTests -P prepare-for-upload package

Si desidera verificare che la directory di destinazione/caricamento ora esista nella cartella radice del progetto per assicurarsi che si è pronti per il caricamento. Se si intende impostare una nuova app nel Cloud di Test, è necessario creare l'applicazione come parte dell'esecuzione del test. Seguire il flusso per creare un nuovo test per selezionare i dispositivi, impostare le preferenze e generare il comando che è necessario eseguire l'esecuzione. Per questo esercizio, consiglia di selezionare un numero ridotto di dispositivi dalla categoria di livello 1 in modo che i risultati sarà pronti per la revisione rapidamente. Copiare il comando generato ed eseguirlo dalla riga di comando.

Una volta negoziato e convalidato il caricamento del file correttamente, verranno eseguito il provisioning di dispositivi, verrà installata l'applicazione e i test verranno eseguiti. Il Cloud Test operativo modello è basato su concorrenza dispositivo o il numero di dispositivi fisici che può essere utilizzato in parallelo. Ad esempio, un utente con cinque dispositivi simultanei possa testare un'app su X Nexus 5, 6P, Nexus Samsung Galaxy S5, Samsung Galaxy S6 e M8 HTC nello stesso momento. Questa efficienza è uno dei vantaggi più significativi del Cloud di Test, rendendo più semplice aumentare la copertura per estendersi su più dispositivi durante l'aggiunta di poco alcun tempo di attesa aggiuntivo.

Lo strumento da riga di comando trasmetterà gli aggiornamenti in esecuzione dei test di stato e di fornire un collegamento al report di test una volta terminata l'esecuzione. Seguire il collegamento al report per esaminare i risultati dei test.

Esistono tre livelli di granularità con cui è possibile visualizzare i risultati:

Rapporto Panoramica.
Griglia di dispositivo.
Report dettagli dispositivo.

Mi occuperò ogni volta.

Il rapporto Panoramica la panoramica offre un'esecuzione dei test inclusi i dettagli di esito positivo o negativo, statistiche di errore dalla versione del sistema operativo, produttore e il fattore di forma, informazioni di riepilogo e i dettagli sull'esecuzione stesso, tra cui le configurazioni di dispositivi di destinazione e tempo di esecuzione totale (vedere figura 2).

Figura 2, il rapporto Panoramica

Se l'esecuzione dei test produce gli errori, è probabile che desidera un'analisi più approfondita per esplorare le cause principali e raccogliere dati per il debug. La griglia di dispositivo è il livello di dettaglio successivo.

La griglia dispositivo griglia dispositivo fornisce un meccanismo efficiente per l'esplorazione dei risultati del test dettagliata insieme le schermate acquisite a ogni passaggio. Con errori chiaramente indicati nei passi di test, è possibile rapidamente passare a un passaggio non riuscito ed esaminare lo stato di visualizzazione dell'app su ogni dispositivo. Per set di dispositivi più grandi, è possibile filtrare i dispositivi visualizzati solo a quelli che non è riuscito a creare un campo di pulizia per l'ispezione. Se la causa dell'errore non è visibile a questo livello di dettaglio, è possibile analizzare uno livello di più per visualizzare i dettagli del dispositivo (vedere figura 3).

Figura 3. il Report griglia del dispositivo

Il Report dettagli dispositivo la visualizzazione di dettagli dispositivo offre lo stesso accesso all'esplorazione di passaggio di test e le schermate ma fornisce dettagli aggiuntivi specifici per il dispositivo selezionato, incluso l'utilizzo della CPU e memoria. Da questa visualizzazione è anche possibile accedere ai registri del dispositivo e traccia dello stack, gli elementi che saranno probabilmente la più utile per analizzare un errore del test (vedere figura 4).

Figura 4 il Report dettagli dispositivo

A questo punto ho adottato il flusso di lavoro più comune in Test Cloud:

Eseguire test (manualmente o tramite l'integrazione continuata o elemento di configurazione).
Esaminare i risultati.
Recuperare gli elementi di debug.
Correzione.

Successivamente, illustrerò alcuni semplici metodi per considerare la strategia di dispositivo di destinazione e l'ottimizzazione del flusso di lavoro di test per le prestazioni per mantenere la pipeline di flusso rapidamente.

Alcune riflessioni sulla copertura del dispositivo

Selezionare i dispositivi dell'organizzazione verrà supportano e infine testare è quasi tanto importante quanto il test stesso. Sebbene esistano molte origini dei dati di mercato aggregate e generalizzato che consente di facilitare le evoluzioni quest'area, l'origine più importanti è dati sull'utilizzo di base di utenti. L'eccezione a questo, ovviamente, è un'applicazione distribuita solo internamente a un set di dispositivi noti e gestiti. Per esterni e consumer App e interni distribuiti in base a criteri bring-your-own device (BYOD), dati di utilizzo sono la fonte migliore.

Molti strumenti sul mercato consentono di acquisire approfondite i dispositivi che utilizza i gruppi di destinatari. Questo è il set di dati da cui è possibile estrapolare l'elenco dei dispositivi supportati. La metodologia esatta che è possibile determinare quali dispositivi per supportare l'aggregazione elenco spetta la propria organizzazione. Nella maggior parte dei casi, non non senso per supportare tutti i dispositivi da dati di utilizzo, come questo metodo diventa rapidamente difficile e costoso. È possibile decidere di coprire tutti i dispositivi come costituiscono una certa percentuale dell'utente di base. In alternativa, è possibile decidere di pensare in termini di numero di utenti e dispositivi tante come richiesto per lasciare i dispositivi meno di 500 utenti interessati. Se si dispone di un'applicazione di e-commerce, è possibile creare riferimenti incrociati i dati di utilizzo con i dati di transazione, garantendo i dispositivi che rappresentano la spesa più elevata e vengono presentate le transazioni più frequenti. Anche in questo caso, l'approccio specifico che necessari per sviluppare l'elenco di supporto di dispositivi basare le esigenze e obiettivi dell'azienda.

Tenere presente che sul mercato mobile si sposta rapidamente. Ciò significa, in ordine per l'elenco di supporto deve essere accurato e significativi, devono esaminare i dati di utilizzo regolarmente. Controllare le forze di mercato che suggeriscono che è il momento opportuno per esaminare i dati, ad esempio l'implementazione di un nuovo modello di dispositivo o del sistema operativo.

Ottimizzazione delle Pipeline di test

Il modo migliore per estrarre il maggior valore da automazione di test è test tempestivi e frequenti. Questo riduce i tempi e costi con la correzione di bug e garantisce che la pipeline di distribuzione rimane non crittografata. Ma come team e le operazioni di scalabilità, può aumentare la latenza nella pipeline e può ridurre la produttività degli sviluppatori. Esaminiamo modi per mantenere la pipeline non crittografato e la produttività elevata.

Non tutti i test sono uguali progetti l'aumento del tempo, i gruppi di test richiedono più tempi per l'esecuzione. C'è un punto di flesso che in cui in esecuzione il gruppo di test dopo che una semplice modifica diventa più complesso e complicato, causando spesso le cattive abitudini, ad esempio coloro eseguono i test. Questo priorità da considerare in anticipo percorsi critici dell'applicazione, vale a dire, cosa flussi o esperienze nell'applicazione devono assolutamente utilizzare? Utilizzando l'esempio di applicazione e-commerce precedente, ciò potrebbe indicare gli utenti possono sfogliare i prodotti, aggiungere prodotti al carrello e check-out. È meno importante che gli utenti possono impostare le preferenze di notifica. Con questa struttura sul posto, diventa molto più pratico eseguire test su ogni push o anche ogni commit. Invece di eseguire la suite di test completo per piccole modifiche, è possibile eseguire solo quelle che fanno parte dei percorsi critici. Come, esattamente, ottenere questo limite dipenderà dal framework di test che si utilizza.

I dispositivi di destra al momento destra ogni push in un branch di funzionalità di test può essere ideale dal punto di vista di qualità, questo metodo diventa rapidamente costoso per i team di grandi dimensioni, in particolare quelli che supportano molte diverse configurazioni dei dispositivi. È possibile ridurre l'overhead qui applicando una strategia progressiva al dispositivo di destinazione su queste esecuzioni di test. Una compilazione di un ramo non di produzione desidera essere testati su ogni dispositivo supportate? La risposta è no probabile. In alternativa, è possibile selezionare un numero ragionevole di dispositivi che consente di bilanciare test efficaci con tempi di attesa più brevi. Per una compilazione pre-produzione da elementi di configurazione, un campionamento di modelli di dispositivo più diffusi e versioni del sistema operativo dall'elenco di supporto dei dispositivi fornirà un livello prezioso di copertura senza aumentare il tempo di compilazione oltre un'ora. Per un singolo sviluppatore di test da una workstation locale, uno o due dispositivi di test potrebbe essere sufficiente.

Questi sono solo alcuni esempi dei modi per considerare la configurazione di test del flusso di lavoro. Il punto più ampio è investire del tempo alla domanda se il flusso della pipeline è ottimale. Anche se aver risposto a questa domanda prima, come con tutte le operazioni eseguite, è sempre buona norma controllare regolarmente e adattare.

Conclusioni

In questo articolo si è appreso come migrare facilmente dall'esecuzione dei test in un singolo dispositivo locale o il simulatore per tutta la potenza di centinaia di configurazioni dei dispositivi usando Xamarin Test Cloud. Inoltre trattato alcune strategie per organizzare il test del flusso di lavoro ed estrarre il maggior valore dalle risorse test. Se non è già in uso Test Cloud, è possibile iscriversi per una versione di valutazione gratuita bit.ly/2e3YgTy per iniziare a utilizzare subito con i progetti.

Justin Raczakè un senior program manager presso Microsoft, che il servizio di automazione di test per dispositivi mobili. Anche se solo recentemente è entrato in Microsoft, ha ha tentato di test automatizzati e il relativo ruolo nel progresso recapito continuo negli ultimi tre anni. È possibile contattarlo al justin.raczak@microsoft.com.

Grazie al seguente esperto tecnico Microsoft per la revisione dell'articolo: Simon Søndergaard
Simon Søndergaard è un software engineer presso Microsoft.

Viene illustrato in questo articolo nel forum di MSDN Magazine