Menú

Tutorial de proves d'aplicacions d'Android: una guia per a principiants

  • Principal
  • Altres
  • Tutorial de proves d'aplicacions d'Android: una guia per a principiants

android app testing tutorial

Proveu El Nostre Instrument Per Eliminar Problemes

Recopilació de coneixements bàsics abans de provar les aplicacions d'Android:

Com el seu propi títol suggereix, en aquest tutorial parlarem més sobre el procés de proves d'Android.

Però, abans d’entrar en els diversos detalls del procés de proves d’Android, voldria plantejar-vos un parell de preguntes.

Tens un telèfon mòbil?

Ara, quina tonteria és aquesta pregunta! Per descomptat, ho fem tots. Tothom té un telèfon mòbil. Actualment, els telèfons mòbils s’han convertit en una necessitat bàsica de l’existència humana.

Em podeu dir el sistema operatiu que hi ha al vostre telèfon?

Si heu comprat el telèfon entre 2014-16, les possibilitats que el vostre telèfon funcioni a Android ronden el 80-85%.

Proves d

Què aprendreu:

Creixement d'Android

Les estadístiques següents descriuen més sobre el creixement d'Android d'una manera fàcilment comprensible.

  • El 2009, Android era un novell i només representava el 3,9% del mercat total.
  • El principal col·laborador aleshores va ser el sistema operatiu Symbian, amb una xifra enorme del 47% (Golden days of Nokia).
  • Aquesta tendència va començar a canviar amb els anys i Android ja va arribar al 85,2% el 2016.

BasicAndorid ios

( font de la imatge )

  • Els números anteriors només són per a telèfons mòbils. El sistema operatiu Android també té un gran impacte en la indústria de les tauletes. Del 4,4% de quota de mercat el 2011 al 35,7% el 2015 es parla de l’interès que la gent ha anat desenvolupant cap als dispositius amb tauletes que funcionen amb Android.

Quota de mercat de les tauletes Android Basic

( font de la imatge )

  • La botiga de Google Play també ha vist augmentar ràpidament el nombre de descàrregues. Del 2010 al 2016 les xifres han passat de 1.000 milions de descàrregues al mes a 65.000 milions de descàrregues al mes.
  • Les baixades de preus (Mitjana: 0,06 $ / aplicació) de les aplicacions per a Android també afecten molt les baixades d’aplicacions en comparació amb les aplicacions per a iOS.

Per què només et vaig fer arribar tots aquests números?

Va ser només per fer-vos conscients de l’extensió d’Android, del complicat que s’ha convertit en el desenvolupament de l’aplicació i de la quantitat de mercat que ha captat aquest sistema operatiu en l’última dècada.

Ara tots els llocs web, aplicacions de Windows i aplicacions per a Mac tenen un germà Android. Tothom opta per desenvolupar una aplicació per a Android tan aviat com tingui previst desenvolupar una pàgina web / aplicació de Windows. Ara s’ha convertit en necessari, ja que els clients també han començat a preferir les aplicacions mòbils per sobre d’aplicacions per a ordinadors o llocs web en els darrers anys.

Algunes de les aplicacions que s’utilitzen amb més freqüència en les nostres activitats quotidianes són Flipkart, Amazon, Zomato, DeliveryHero, Citi Bank, TrueCaller, Facebook, Gmail, Whatsapp, etc.

El motiu de l’augment del mercat d’Android és que:

  • És un sistema obert, per tant, és fàcil de personalitzar, fàcil d'aprendre i fins i tot el desenvolupament d'aplicacions és més fàcil.
  • Publicar una aplicació a Google Play Store és molt fàcil si es compara amb la resta de Play Store.
  • Hi ha diversos fabricants al mercat de telèfons Android com Sony, HTC, Samsung, Motorola, etc.
  • Hi ha un gran nombre de funcions a Android com DualSIM, microSD, bateria extraïble, etc., cosa que suposa un avantatge addicional.
  • El preu dels telèfons Android no és massa alt i és assequible, etc.

Juntament amb el requisit de desenvolupament de les aplicacions d'Android, també hi ha hagut un augment del requisit per als provadors que tenen coneixements en les proves d'Android.

Com a provador, abans de començar a provar qualsevol aplicació integrada per Android, heu de fer molts deures. El primer que cal fer és estudiar el sistema operatiu i la seva història. Si no coneixeu el sistema operatiu, no podeu provar l'aplicació amb les diferents versions. La funcionalitat bàsica de la versió del sistema operatiu, la interfície d’usuari, el GPS, l’assistència del tipus de xarxa, la durada de la bateria, etc., són algunes de les facetes importants que afecten una aplicació.

Amb Android, no només cal fer un estudi del sistema operatiu, sinó de la gran quantitat de dispositius.

Hi ha una gran quantitat de dispositius disponibles al mercat, per tant, abans de finalitzar i congelar el vostre banc de proves, heu de conèixer la quota de dispositius de públic objectiu. Els diferents dispositius que ofereixen diferents funcions, com ara DualSIM, càmera dual, resolució de pantalla, temes, etc., afecten una aplicació i cal provar-los.

Per tant, és molt important que un control de qualitat reuneixi un coneixement exhaustiu sobre l’ecosistema complet d’Android.

Introducció a l'aplicació d'Android

Hi ha diversos mètodes de prova que se segueixen certificant amb èxit una aplicació per a Android.

Una arquitectura d'aplicació d'Android típica tindria un aspecte similar al diagrama que es mostra a continuació:

preguntes i respostes de l'entrevista de l'enginyer de garantia de qualitat

Arquitectura d

Segons la figura anterior, hi ha dues possibilitats per a una aplicació:

1) Aplicació mòbil per a l'aplicació web: És possible que el client tingui una aplicació web i vulgui crear una aplicació mòbil per a la mateixa. Amazon, Jabong, Myntra, etc., van fer el mateix, i en el moment en què les aplicacions mòbils van començar a crear un boom al mercat, aquestes empreses comercials es van adonar que aviat la gent passarà d’aplicacions web a aplicacions mòbils.

2) Aplicació mòbil com a entitat comercial independent: Vaig provar una aplicació logística similar, per tal d’augmentar el negoci, va crear una aplicació independent per als seus conductors per facilitar un lliurament sense problemes i vaig eliminar els tràmits.

Els conductors tenien instal·lada l’aplicació als telèfons per traslladar l’enviament a diferents fases de lliurament i el seu estat corresponent, i les actualitzacions de lliurament es reflectien a la seva aplicació web existent.

Altres tals Exemples on l'aplicació mòbil és una entitat independent són WhatsApp, aplicacions de seguiment de la salut com S Health, etc.

Llista de tasques pendents abans de començar el procés de prova

A diferència d’un cicle de proves normal, per a la primera versió d’una aplicació per a mòbils, hi ha alguns elements que necessiten una investigació i una planificació addicionals per a l’èxit de l’aplicació.

A continuació es detallen algunes de les activitats que cal dur a terme per a un control de qualitat abans de començar les proves reals:

# 1) Investigació sobre sistemes operatius i dispositius:

A part d’entendre el requisit de l’aplicació, també heu d’entendre l’impacte de les diverses versions del sistema operatiu i dels models de dispositius. Heu de crear casos o escenaris de prova amb els sistemes operatius i els models de dispositius.

# 2) Llit de proves:

A diferència de les aplicacions d’escriptori, web i iOS, la creació de bancs de proves per a aplicacions per a Android és molt complicada a causa del sistema Android obert. La decisió s'hauria de prendre després de discutir amb BA, els desenvolupadors i els propietaris del producte per trobar el públic objectiu.

# 3) Pla de proves:

Com que és la primera versió, s’hauria d’instal·lar un pla aprovat amb un banc de proves aprovat, tipus de proves, etc. Si es requereix un temps separat per investigar les funcionalitats o les regles empresarials o si les proves seran complicades, etc., tot hauria d'estar cobert al pla.

# 4) Eines d'automatització:

Les eines d’automatització necessàries per a les aplicacions mòbils són molt diferents de les aplicacions d’escriptori o web. Per tant, és possible que hagueu de dedicar més temps i esforç a aprendre l'eina. El propietari o el client ha d’aprovar el temps i l’esforç necessari per fer-ho.

# 5) Tècniques o mètodes de prova:

A diferència de les proves convencionals que fem normalment, hi ha poques proves que siguin molt específiques de les aplicacions per a mòbils. És a dir, prova de camp, prova GPS, prova de captura d’imatges, etc. Cal documentar-los en els casos de prova juntament amb la manera com es provaran aquests tipus.

Tipus de proves per a aplicacions mòbils

Es realitzen els següents tipus de proves per certificar una aplicació d'Android:

1) Proves funcionals:

Normalment, les proves s’aconsegueixen mitjançant fluxos de prova iniciats per la interfície d’usuari. No només es prova el flux d’un cas d’ús, sinó que també es posen a prova les diferents regles de negoci. Les proves es fan certificant els requisits. és a dir, si l’aplicació funciona en funció dels requisits.

Agafem el Exemple de l'aplicació Zomato.

Quan inicieu l'aplicació, en funció de la ubicació, apareix la llista de restaurants. Ara, com a control de qualitat, heu de provar la llista de restaurants.

Es tracta de proves de funcionalitat i aquí provareu funcionalitats com:

  • Verifiqueu si es mostren les targetes del restaurant a la ubicació.
  • Verifiqueu si els restaurants que es mostren es troben a l’interval determinat (km) de la ubicació.
  • Verifiqueu si el recompte de ressenyes de cada targeta està sincronitzat amb les ressenyes donades.
  • Comproveu si afegir un restaurant nou per a una ubicació es reflecteix a la llista.
  • Verifiqueu si els restaurants apareixen en funció de la regla de filtratge de Zomato, etc.

BasicAndroid zomato

2) Proves de la IU d'Android:

Es tracta d'una prova centrada en l'usuari de l'aplicació. En aquesta fase de prova, es comproven elements com ara la visibilitat del text en diverses pantalles de l’aplicació, missatges interactius, alineació de dades, l’aspecte de l’aplicació per a diferents pantalles, la mida dels camps, etc.

Per al mateix exemple de Zomato anterior, les proves de la IU serien:

  • Verifiqueu si les targetes es mostren correctament alineades amb la mida de la pantalla del mòbil.
  • Verifiqueu si la imatge del restaurant es mostra tal com s’esperava.
  • Verifiqueu si les dades de la targeta, la classificació del restaurant, el tipus de cuina, l'adreça, etc. es mostren correctament alineades.
  • Verifiqueu si el desplaçament de la llista no té problemes i si les cartes no es mostren desalineades quan es desplaça una llista llarga de cartes, etc.

3) Proves de compatibilitat:

Aquesta prova es realitza principalment en forma de dues matrius de l'aplicació OS Vs i l'aplicació Model de dispositiu Vs. Normalment, el propietari del producte o el client proporciona una llista de sistemes operatius compatibles (i de vegades de dispositius).

La necessitat d’aquestes proves és:

  • Quan es té en compte un sistema operatiu com Android, es troben 7 versions bàsiques que descuiden el nombre de versions de patch / EP.
  • Podeu endevinar els tipus de dispositius Android que funcionen actualment a tot el món? 1000? 2000? Mal! La resposta correcta és 24000. Hi ha 24000 tipus de dispositius Android únics presents i actius al món.
  • Amb variacions com aquestes, les proves de compatibilitat tenen un paper vital en la certificació d’una aplicació per a Android.
  • No només hem de validar el sistema operatiu i el tipus del dispositiu, sinó que també hem de validar algunes altres funcions que entren en proves de compatibilitat. Les funcions inclouen:
    • Mida de la pantalla
    • Resolució de la pantalla
    • Connectivitat de xarxa

4) Proves d'interfície:

Dit d’una altra manera, també s’anomena prova d’integració. Aquesta prova es realitza després de desenvolupar completament tots els mòduls de l'aplicació, provar-los individualment i verificar tots els errors.

Les proves d'interfície inclouen proves com una prova completa de l'aplicació, interacció amb altres aplicacions com Maps, aplicacions socials, etc., l'ús del micròfon per introduir text, l'ús de la càmera per escanejar un codi de barres o fer una foto, etc.

Considerant de nou Zomato, les proves d’integració serien com:

  • Verifiqueu si l'usuari pot reservar una taula per a un restaurant.
  • Verifiqueu si l'usuari pot veure el menú i demanar menjar en línia.
  • Verifiqueu si l'usuari pot obtenir un cupó PayTM mentre demana menjar.
  • Verifiqueu si l'usuari pot veure la ubicació del restaurant a Google Maps.
  • Verifiqueu si l'usuari pot obrir el marcador i trucar al restaurant, etc.

5) Prova de xarxa:

Les funcions clau de les proves de xarxa inclouen:

  • L'aplicació hauria de parlar amb el servei intermedi per dur a terme el procés.
  • Durant aquesta prova, la sol·licitud / resposta al / del servei es prova per a diverses condicions.
  • Aquesta prova es fa principalment per verificar el temps de resposta en què es realitza l'activitat, com ara actualitzar dades després de la sincronització o carregar dades després d'iniciar la sessió, etc.
  • Això es fa tant per a una connexió wifi forta com per a la xarxa de dades mòbils.
  • Es tracta d’una prova interna.

6) Proves de rendiment:

Es comprova el rendiment de l'aplicació en algunes condicions peculiars.

Aquestes condicions inclouen:

  • Poca memòria al dispositiu.
  • La bateria està molt baixa.
  • Recepció de xarxa deficient / dolenta.

El rendiment es prova bàsicament des de 2 extrems, el final de l'aplicació i el final del servidor d'aplicacions

7) Proves d'instal·lació:

Hi ha dos tipus d’aplicacions en un dispositiu Android, és a dir, les aplicacions preinstal·lades i les aplicacions que l’usuari instal·la més endavant.

Per a les dues situacions anteriors, cal realitzar proves d’instal·lació. Es tracta d’assegurar una instal·lació fluida de l’aplicació sense acabar amb errors, instal·lació parcial, etc.

Les proves d’actualització i desinstal·lació es realitzen com a part de les proves d’instal·lació.

8) Proves de seguretat:

La privadesa i la seguretat són els dos requisits principals d’una aplicació. Tot i això, a la banca, la sanitat, es converteix en el requisit principal.

En aquesta fase s'ha de provar el flux de dades per al mecanisme de xifratge i desxifratge. L’accés a les dades emmagatzemades també es prova en aquesta fase.

9) Prova de camp:

Les proves de camp es fan específicament per a la xarxa de dades mòbils i no a casa, sinó sortint i utilitzant l'aplicació com a usuari normal. Aquestes proves es fan 'només' després que tota l'aplicació s'hagi desenvolupat, provat i retrocedit (per a errors i casos de prova).

Bàsicament es fa per verificar el comportament de l'aplicació quan el telèfon té una connexió 2G o 3G. Les proves de camp verificen si l'aplicació es bloqueja amb connexió de xarxa lenta o si triga massa a carregar la informació.

Podeu obtenir més informació sobre les proves de camp al nostre article 'Importància i necessitat de les proves de camp per a aplicacions mòbils'

10) Proves d'interrupció:

Aquest tipus de proves també es coneix com a verificació d’escenaris fora de línia. Les condicions en què la comunicació es trenca pel mig es denominen condicions fora de línia.

Algunes de les condicions en què es poden provar les interrupcions d’una xarxa són les següents:

Com puc veure un fitxer EPS
  • Eliminació del cable de dades durant el procés de transferència de dades.
  • Interrupció de la xarxa durant la fase de publicació de transaccions.
  • Recuperació de la xarxa després d'una interrupció.
  • Extracció de la bateria o encès / apagat quan es troba en fase transaccional.

Bones pràctiques en proves d'aplicacions per a Android

Hi ha alguns factors a tenir en compte a l’hora de posar una estratègia per provar aplicacions mòbils.

Ells són:

1) Selecció de dispositius:

  • Aquest és un dels passos més crítics abans d’iniciar el procés de prova d’aplicacions per a Android.
  • Decidiu quins dispositius s'han de tenir en compte per al procés de prova.
  • La selecció s'ha de fer per maximitzar el nombre de clients objectiu.
  • Factors com la versió del sistema operatiu, les resolucions de pantalla i els factors de forma (tauletes o telèfons intel·ligents) juguen un paper vital en la fase de selecció.
  • Si cal, fins i tot es pot tenir en compte l'ajuda dels emuladors.
  • Però els emuladors no haurien de substituir el procés de prova del dispositiu físic.
  • Els emuladors de dispositius són rendibles i són útils durant la fase de desenvolupament inicial.
  • Però, per provar els escenaris de la vida real, els dispositius físics són imprescindibles. Tant els emuladors com els dispositius físics s’utilitzaran de manera equilibrada per obtenir un resultat optimitzat.

2) Prova beta de l'aplicació:

  • Les proves beta són molt efectives per provar amb usuaris del món real, dispositius reals, xarxes reals i aplicacions instal·lades en una àmplia geografia.
  • Això proporciona una imatge clara de la densitat de la xarxa, les variacions de xarxa (Wi-Fi, 4G, 3G i 2G) i l’impacte sobre l’aplicació.
  • Les proves beta al món real són d’aquestes característiques i no es poden reproduir en un entorn controlat.

3) Connectivitat:

  • Normalment, les aplicacions d'Android estan connectades a Internet per a diversos requisits.
  • La connectivitat en diferents dispositius juga un paper clau a l’hora d’elaborar l’estratègia.
  • Majoritàriament, la connectivitat està controlada per un programari de simulació que ajuda a regular la velocitat de la xarxa, la latència i la connectivitat limitada durant les proves.
  • Es diu que sempre es recomana provar en connexions de xarxa reals per obtenir resultats o dades en temps real.

4) Proves manuals o automatitzades:

  • Tot i que les proves d'automatització necessiten molt de temps per a la primera tirada, és útil quan s'ha de repetir la prova. Això també redueix el període de temps global de les proves durant les diferents etapes de desenvolupament.
  • L'Automatització d'Android s'hauria de combinar amb proves manuals quan la repetició de proves de regressió sigui elevada en la fase de desenvolupament d'aplicacions, s'hagin de fer proves de compatibilitat per a la mateixa aplicació en diferents versions del sistema operatiu, punts de control de compatibilitat inversa, etc.

Marc de proves d'Android

Hi ha un grapat de marcs de proves d'Android disponibles.

En aquest tutorial, parlarem de tres tipus diferents de marcs més utilitzats:

  • Marc de proves de Robotium
  • Marc de proves robo-elèctriques
  • Marc de prova Appium

1) Marc de proves de Robotium:

  • Aquest marc s'utilitza per escriure casos de prova de caixa negra sofisticats i robustos per a aplicacions d'Android.
  • Admet clients tant natius com híbrids.
  • Les funcions, els casos de prova del sistema i els casos de prova d’acceptació de l’usuari es poden escriure mitjançant aquest marc.
  • Robotium és compatible amb Android 1.6 i versions posteriors i també és compatible amb diàlegs, menús, activitats, etc.
  • Aquest marc gestiona diverses activitats d'Android automàticament.
  • Es donen un grapat de mètodes com a part de Robotium per interactuar amb diferents components gràfics de l'aplicació Android. Alguns d’ells són els següents:
    • torna();
    • getButton ();
    • isRadioButtonChecked ();
    • searchText ('Usuari');
    • feu clic al botó ('Tancar sessió');

2) Marc de proves robo-elèctriques:

  • Aquest marc ajuda a provar aplicacions d'Android a la JVM basades en el marc JUnit4.
  • Utilitza l'API d'Android.
  • Això ajuda a escriure casos de prova i executar-los a la JVM.
  • Sota això, totes les classes són substituïdes per una cosa anomenada objectes ombra.
  • Sempre que s’implementa un mètode, Robo-electric envia internament la trucada a l’objecte ombra.
  • Basat en la implementació, si un mètode és implementat per l'objecte shadow, es torna un valor. En cas contrari, es torna NULL.
  • A causa dels objectes ombra i JVM, l'execució es fa més ràpida.

3) èpoques de Test Framework;

  • Aquest marc funciona per a aplicacions web natives, híbrides i mòbils per a dispositius Android.
  • Appium és gratuït per utilitzar la utilitat.
  • L'API única funciona tant per a Android com per a la plataforma iOS. Aquest és un dels marcs que admet les proves multiplataforma.
  • Utilitza el controlador Selenium Web per interactuar amb l’aplicació Android.
  • Appium admet l'escriptura de seqüències amb molts llenguatges de programació com Java, C #, Python, PHP, Ruby, etc.

Conclusió

L'automatització d'aplicacions d'Android es pot combinar manualment segons la necessitat. Tanmateix, si la prova d’Androind Automation s’afegeix a l’estratègia, seleccionar una eina correcta és una tasca important. En seleccionar els factors de l’eina d’automatització com l’assistència multiplataforma, el flux de treball de proves, el preu de l’eina, el servei / assistència, etc., s’ha de tenir en compte.

Hi ha diversos reptes relacionats amb les proves d'aplicacions d'Android. Hi ha diferents factors a tenir en compte abans que el procés de proves d'Android es pugui implementar realment, però un cop fet això es converteix en una tasca molt interessant.

Mireu el proper tutorial per obtenir més informació Desafiaments i solucions de proves de mòbil.

Lectura recomanada

^