Condividi tramite

Parte 6 - Test e approvazioni per App Store

  • Articolo

Test in corso

Molte app (anche app Android, in alcuni negozi) dovranno superare un processo di approvazione prima della pubblicazione; quindi il test è fondamentale per garantire che l'app raggiunga il mercato (e non solo ha successo con i clienti). I test possono assumere molte forme, dagli unit test a livello di sviluppatore alla gestione dei test beta in un'ampia gamma di hardware.

Test su tutte le piattaforme

Esistono lievi differenze tra le funzionalità supportate da .NET nei dispositivi Windows Phone, tablet e desktop, nonché limitazioni su iOS che impediscono la generazione di codice dinamico in tempo reale. Pianificare il test del codice su più piattaforme durante lo sviluppo o pianificare il refactoring e aggiornare la parte del modello dell'applicazione alla fine del progetto.

È sempre consigliabile usare il simulatore/emulatore per testare più versioni del sistema operativo e anche diverse funzionalità/configurazioni del dispositivo.

È anche consigliabile eseguire test su tutti i diversi dispositivi hardware fisici che è possibile eseguire.

Dispositivi nel cloud

L'ecosistema di telefoni cellulari e tablet è in continua crescita, rendendo impossibile testare il numero sempre crescente di dispositivi disponibili. Per risolvere questo problema, numerosi servizi offrono la possibilità di controllare in remoto molti dispositivi diversi in modo che le applicazioni possano essere installate e testate senza dover investire direttamente in un sacco di hardware.

Il test di App Center offre un modo semplice per testare le applicazioni iOS e Android in centinaia di dispositivi diversi. Per altre informazioni, vedere Preparazione delle app Xamarin.Android e Preparazione delle app Xamarin.iOS.

Gestione test

Quando si testano le applicazioni all'interno dell'organizzazione o si gestisce un programma beta con utenti esterni, esistono due sfide:

  • Distribuzione : gestione del processo di provisioning (in particolare per i dispositivi iOS) e aggiornamento delle versioni del software ai tester.
  • Feedback : raccolta di informazioni sull'utilizzo dell'applicazione e informazioni dettagliate su eventuali errori che possono verificarsi.

Esistono diversi servizi che consentono di risolvere questi problemi, fornendo un'infrastruttura integrata nell'applicazione per raccogliere e segnalare l'utilizzo e gli errori e semplificando il processo di provisioning per consentire l'iscrizione e la gestione dei tester e dei relativi dispositivi.

Visual Studio App Center offre una soluzione a questi problemi, fornendo distribuzione delle versioni di test, segnalazione degli arresti anomali e informazioni sofisticate sull'utilizzo delle applicazioni.

Automazione dei test

Xamarin UITest può essere usato per creare script di test automatizzati dell'interfaccia utente che possono essere eseguiti localmente o caricati nel test di App Center.

Testing unità

Touch.Unit

Xamarin.iOS include un framework di unit test denominato Touch.Unit che segue i test di scrittura dello stile JUnit/NUnit.

Per informazioni dettagliate sulla scrittura di test e sull'esecuzione di Touch.Unit, vedere la documentazione di Unit Testing con Xamarin.iOS .

Andr.Unit

Esiste un equivalente open source di Touch.Unit per Android denominato Andr.Unit. È possibile scaricarlo da GitHub e leggere informazioni sullo strumento nel blog di @spouliot.

Approvazioni di App Store

Apple e Microsoft gestiscono rispettivamente l'unico store sulle loro piattaforme: App Store e Marketplace. Entrambi bloccano i dispositivi e implementano un rigoroso processo di revisione delle app per controllare la qualità delle applicazioni disponibili per il download. La natura aperta di Android significa che ci sono una serie di opzioni dello store che vanno da Google Play, che è ampiamente disponibile e non ha alcun processo di revisione, all'Appstore di Amazon per Android e gli sforzi specifici dell'hardware come Samsung Apps che hanno una distribuzione più limitata e implementano un processo di approvazione.

L'attesa di una revisione di un'app può essere molto stressante: le pressioni aziendali spesso indicano che le applicazioni vengono inviate per l'approvazione con un margine molto minimo per l'errore prima di una data di lancio "mirata". Il processo stesso può richiedere fino a due settimane e non è necessariamente trasparente: è disponibile un feedback limitato sullo stato di avanzamento dell'applicazione fino a quando non viene infine rifiutato o approvato. Il rifiuto può significare che manca una finestra di marketing dell'opportunità, soprattutto se si verifica più di una volta e le settimane passano tra la data di lancio originale e quando l'app viene finalmente approvata.

Preparati

Il primo suggerimento: pianificare il lancio della tua app in anticipo e prendere in considerazione un possibile rifiuto e ri-invio. Ogni store richiede di creare un account prima di inviare l'app. Eseguire questa operazione il prima possibile. Anche se l'iscrizione di Google Play richiede solo alcuni minuti se le tue app sono gratuite, il processo diventa molto più coinvolto se li vendi e hai bisogno di fornire informazioni bancarie e fiscali. I processi di Apple e Microsoft sono entrambi molto più coinvolti di Google, potrebbe richiedere una settimana o più per ottenere l'approvazione del tuo account, quindi fattore questa volta nei tuoi piani di lancio.

Dopo aver approvato l'account, sei pronto per inviare un'app. Il processo effettivo per l'invio di app è illustrato nella documentazione seguente:

La parte restante di questa sezione illustra gli aspetti da prendere in considerazione per assicurarsi che l'app venga approvata senza interruzioni.

Qualità

Sembra ovvio, ma le applicazioni vengono spesso rifiutate perché non soddisfano un certo livello di qualità: dopo tutto, questo è il motivo per cui i negozi curati hanno un processo di approvazione in primo luogo!

Gli arresti anomali sono un motivo comune per il rifiuto. Se è troppo facile causare l'arresto anomalo dell'app, è garantito che venga rifiutato. La maggior parte degli sviluppatori non invia le proprie app con le aspettative che si arrestano in modo anomalo, ma spesso lo fanno. Testare attentamente l'app prima di inviarla, concentrandosi non solo sull'assicurarsi che tutto funzioni, ma anche per gestire scenari di errore di dispositivi mobili comuni, ad esempio problemi di rete e vincoli di risorse come memoria o spazio di archiviazione. Usare sia il simulatore che i dispositivi fisici per testare, indipendentemente dalla modalità di esecuzione del codice in un simulatore, solo un dispositivo può dimostrare le prestazioni reali di un'app. Usare tutti i dispositivi diversi disponibili e integrare un team di beta-tester, se possibile: i servizi di terze parti possono aiutare a gestire la distribuzione beta e il feedback.

Tutti i sistemi operativi mobili uccideranno un'applicazione che non viene avviata abbastanza rapidamente. L'intervallo di tempo consentito varia, ma in generale le app devono essere reattive in pochi secondi e usare le attività in background per eseguire qualsiasi operazione che richiederebbe più tempo. Le app che richiedono troppo tempo per il caricamento o non sono sufficientemente reattive nell'uso normale verranno rifiutate. Fornisci sempre commenti e suggerimenti degli utenti quando si verifica qualcosa in background o l'app sembra che si arresti in modo anomalo e, ancora una volta, venga rifiutato.

Controllare i casi perimetrali

Una trap comune per gli sviluppatori non risolve i casi perimetrali, in particolare quelli che richiedono la riconfigurazione del simulatore o del dispositivo per il test corretto. Può essere facile dimenticare che non tutti i clienti stanno andando a "Consenti" all'app di accedere alla loro posizione perché dopo che lo sviluppatore ha accettato la richiesta una sola volta, non verrà più richiesto. Le autorizzazioni e l'utilizzo della rete sono incentrati specificamente su durante il processo di approvazione, il che significa che una piccola supervisione in queste aree può comportare il rifiuto.

L'elenco seguente è un buon punto di partenza per controllare i casi limite che potrebbero non essere stati superati:

  • I clienti possono "negare" l'accesso ai servizi , in particolare in iOS, l'accesso ai dati, ad esempio le informazioni sulla posizione geografica, viene fornito solo se l'utente concede l'autorizzazione all'applicazione. I tester di applicazioni devono spesso reinstallare l'applicazione nello stato iniziale e non consentire le richieste di autorizzazione per garantire che l'applicazione si comporti in modo appropriato. Attivare e disattivare l'autorizzazione per verificare il comportamento corretto quando i clienti cambiano idea.
  • I clienti sono ovunque : non presupporre che un'app verrà usata solo nella città o nel paese in cui è stato sviluppato! Il codice che funziona con coordinate GPS, valori di data e ora e valute può essere interessato dalle impostazioni locali e della posizione del cliente. Tutte le piattaforme offrono un simulatore che consente di specificare posizioni e impostazioni locali diverse: usarle per testare le posizioni in altri emisferi e con impostazioni cultura che formattano le date e le valute in modo diverso. I valori di latitudine e longitudine possono essere positivi o negativi, il separatore decimale può essere un punto o una virgola e le date possono essere formattate in una miriade di modi: gestirli!
  • Connessioni di rete lente: gli sviluppatori di app spesso lavorano in un "mondo ideale" di connettività di rete veloce e sempre funzionante, che ovviamente non è il caso nel mondo reale. Il test con connettività di rete lenta (ad esempio una connessione 3G scadente) e senza accesso alla rete è fondamentale per garantire che non venga spedita un'app buggy. Il processo di approvazione includerà sempre un test con il dispositivo in modalità aereo, quindi assicurarsi di aver testato per se stessi.
  • L'hardware varia : ricordarsi di testare l'hardware meno recente e più lento che si prevede di supportare. Ci sono due aspetti che potrebbero influire sulla tua app: prestazioni, che potrebbero non essere utilizzabili in un dispositivo meno recente e supporto per funzionalità hardware come una fotocamera, microfono, GPS, giroscopio o altro componente facoltativo. Le applicazioni devono degradare normalmente (e non arrestarsi in modo anomalo) quando un componente non è disponibile.

Le linee guida sono più che una "guida"

Apple è famosa per essere rigorosamente sulla conformità alle linee guida dell'interfaccia umana come uno dei punti di forza chiave della loro piattaforma è la coerenza (e il percepito aumento dell'usabilità). Microsoft ha adottato un approccio simile con le applicazioni Windows che implementano il sistema Fluent Design. Il processo di approvazione per entrambe le piattaforme implica la valutazione dell'app per la conformità alla filosofia di progettazione pertinente.

Ciò non significa che l'innovazione dell'interfaccia utente non sia supportata o incoraggiata, ma ci sono alcune cose che non dovresti fare" o che la tua app verrà rifiutata.

In iOS, questo include errori di utilizzo delle icone predefinite o l'uso di altre metafore ben stabilite in modo non coerente; ad esempio usando l'icona "compose" per qualsiasi elemento diverso dalla creazione di nuovo contenuto.

Gli sviluppatori di Windows devono prestare attenzione allo stesso modo; un errore comune non è in grado di supportare correttamente il pulsante Indietro hardware in base alle linee guida di Microsoft.

Incoraggiare i progettisti a leggere e seguire le linee guida di progettazione per ogni piattaforma.

Implementazione di funzionalità specifiche della piattaforma

Le cose sono un po' più rigide quando si tratta di implementare servizi specifici della piattaforma, soprattutto in iOS. Per evitare il rifiuto automatico da Parte di Apple, esistono alcune regole da seguire con le funzionalità iOS seguenti:

  • Acquisti in-app : le applicazioni non devono implementare meccanismi di pagamento esterni per prodotti digitali, tra cui valuta in gioco, funzionalità dell'applicazione, abbonamenti a riviste e molto altro ancora. Le app iOS devono usare il servizio basato su iTunes di Apple per questo tipo di funzionalità. C'è una scappatoia: le app come Kindle Reader e alcune app basate su abbonamento ti consentono di acquistare contenuto altrove che viene collegato a un "account" che puoi quindi accedere tramite l'app, tuttavia in questo caso l'app non deve contenere collegamenti o riferimenti al processo di acquisto out-of-app (o, ancora una volta, verrà rifiutato).
  • Backup di iCloud: con l'avvento di iCloud, i revisori di Apple sono molto più rigorosi riguardo al modo in cui le app usano lo spazio di archiviazione (per garantire che l'esperienza di backup remoto del cliente sia piacevole). Le app che sprecano spazio di archiviazione in grado di eseguire il backup possono essere rifiutate, quindi usare la cartella Cache in modo appropriato e seguire le altre linee guida relative all'archiviazione di Apple.
  • Merge – Le app di giornali e riviste sono un'ottima soluzione per l'Apple, ma le app devono implementare almeno un abbonamento che rinnova automaticamente e supportano il download in background per essere approvato.
  • Mappe : è sempre più comune aggiungere sovrapposizioni e altre funzionalità alle mappe per dispositivi mobili, ma prestare attenzione a non nascondere le informazioni sui "crediti" della mappa (ad esempio il logo Google in iOS5) come in questo modo comporterà il rifiuto.

Gestire i metadati

Oltre ai problemi tecnici evidenti che possono comportare il rifiuto di un'applicazione, ci sono alcuni aspetti più sottili dell'invio che potrebbero comportare il rifiuto, soprattutto intorno ai metadati (descrizione, parole chiave e immagini di marketing) che invii con la tua applicazione per la visualizzazione all'interno dell'App Store o del Marketplace.

  • Immagini: seguire le linee guida della piattaforma per le icone dell'applicazione e archiviare immagini. Non usare immagini con marchio, abbiamo visto che le app vengono rifiutate perché le loro icone presentavano un disegno di un i Telefono!
  • Marchi: evitare di utilizzare marchi diversi dal proprio. Le app sono state negate per aver menzionato marchi nella descrizione dell'app o anche nelle parole chiave nell'App Store di Apple.
  • Descrizione : non usare la parola "beta" o in alcun modo indicare che l'app non è pronta per la prima volta. Non menzionare altre piattaforme mobili (anche se l'app è multipiattaforma). Soprattutto, assicurarsi che l'app faccia esattamente quello che si dice. Se si elencano alcune funzionalità nella descrizione, è meglio che sia ovvio come usare ognuna di queste funzionalità o si otterrà un rifiuto "funzionalità menzionata nella descrizione dell'applicazione non viene implementata".

Eseguire il massimo sforzo nei metadati dell'applicazione in fase di sviluppo e test. Le applicazioni DO vengono rifiutate per violazioni minori nei metadati, quindi è opportuno prendere il tempo necessario per ottenere il giusto.

App Store: non per tutti

L'obiettivo principale dei negozi su ogni piattaforma è la distribuzione consumer: la possibilità di raggiungere il maggior numero possibile di clienti. Tuttavia, non tutte le applicazioni sono destinate ai consumatori, esiste una base in rapida crescita di applicazioni interne ed extranet simili che richiedono una distribuzione limitata a dipendenti, fornitori o clienti. Queste app non sono "in vendita" e non richiedono l'approvazione, perché lo sviluppatore controlla la distribuzione a un gruppo chiuso di utenti. Il supporto per questo tipo di distribuzione varia in base alla piattaforma.

Android offre la massima flessibilità in questo senso: le applicazioni possono essere installate direttamente da un URL o da un allegato di posta elettronica (purché la configurazione del dispositivo lo consenta). Ciò significa che è semplice creare e distribuire applicazioni aziendali interne o pubblicare applicazioni a clienti o fornitori specifici.

Apple offre agli sviluppatori un'opzione di distribuzione interna registrata nel programma iOS Developer Enterprise, che ignora il processo di approvazione dell'App Store e consente alle aziende di distribuire le app interne ai dipendenti. Purtroppo questa licenza non risolve la necessità di una distribuzione di app extranet-like ad altri gruppi chiusi di clienti o fornitori. Distribuzione aziendale (e ad hoc)

Riepilogo di App Store

Il processo di revisione può risultare scoraggiante, ma come il resto del ciclo di vita di sviluppo, è possibile garantire un successo con una pianificazione e un'attenzione particolare. Tutto dipende da alcuni semplici passaggi: leggere e comprendere le linee guida dell'interfaccia utente a cui è necessario rispettare, seguire le regole se si implementano funzionalità specifiche della piattaforma, testare accuratamente (quindi testare alcuni altri) e infine assicurarsi che i metadati dell'applicazione siano corretti prima dell'invio.

Un'ultima parola di consigli per gli sviluppatori che pubblicano su Google Play: la mancanza di processo di approvazione può sembrare che il tuo lavoro sia più facile, ma i tuoi clienti saranno ancora più esigenti di un team di revisione. Segui queste linee guida come se la tua app potesse essere rifiutata, altrimenti sarà che i tuoi clienti eseguiranno il rifiuto.