Menú

Prova d'aplicacions per a iOS: una guia per a principiants amb un enfocament pràctic

  • Principal
  • Altres
  • Prova d'aplicacions per a iOS: una guia per a principiants amb un enfocament pràctic

ios app testing beginners guide with practical approach

Proveu El Nostre Instrument Per Eliminar Problemes

Recopilació de coneixements bàsics per a les proves d'aplicacions per a iOS:

'Ja ho sabeu, tothom té un telèfon mòbil, però no conec una persona a qui li agradi el mòbil. Vull fer un telèfon que a la gent li agradi ”. - Steve Jobs.

Això va ser sobre l'iPhone de Steve Jobs. Steve realment va fer que Apple treballés per convertir el seu dispositiu mòbil en un dels preferits de tots els temps per a tothom.

Als usuaris sempre els han encantat els dispositius mòbils d’Apple, ja sigui l’iPhone, l’iPod Touch o l’iPad. Les dades actuals suggereixen que hi ha gairebé 1.000 milions de dispositius Apple operatius al món que funcionen amb iOS.

En són un milió.

Prova d

A continuació es mostra l’anàlisi de la quota de mercat dels iPhones el 2016:

Distribució iOS-Phone

(imatge font )

Què aprendreu:

iOS

iOS és un sistema operatiu mòbil dissenyat per Apple precisament per als seus dispositius, sovint anomenat iDevices. Des del 2007, quan l’iOS es va crear només per als iPhones, el sistema operatiu va evolucionar per donar suport als dispositius tàctils i als iPads.

La investigació actual informa que iOS és el segon sistema operatiu mòbil més popular del mercat. Android funciona amb dispositius construïts per diversos fabricants, però la bellesa d’IOS és que només es limita al maquinari d’Apple, cosa que indica clarament la popularitat del sistema operatiu.

iOS ha vist un total de 10 llançaments importants al llarg dels anys i ha ofert actualitzacions de funcions notables a cada llançament.

Distribució Android ios

Aquest sistema operatiu iOS és famós per la seva facilitat d’ús, fluïdesa en les operacions, aplicacions gratuïtes, etc. Mentre es discuteix sobre les aplicacions, la botiga d’aplicacions Apple iTunes per a iOS és bastant rica, amb un nombre d’aplicacions de fins a 2,2 milions. La descàrrega d'aplicacions ha augmentat ràpidament fins als 130.000 milions.

iOS és un sistema operatiu que no està restringit per cap barrera lingüística o zonal. Aquest és un dels principals factors d’aquest sistema operatiu que s’està convertint en tan famós en només deu anys del seu desenvolupament. Admet 40 idiomes diferents.

No només els idiomes, fins i tot la interfície d’usuari dels dispositius iOS també és molt atractiva i elegant en comparació amb els dispositius Android.

IU de iOS

Visió general de la IU Android

Mentre es parla detalladament de les aplicacions, a continuació s’esmenten algunes de les estadístiques que s’hi inclouen:

  • La botiga d'aplicacions iTunes d'Apple rep gairebé 1.000 noves sol·licituds cada dia.
  • Aproximadament 1/3rddel total d'aplicacions a la botiga d'aplicacions iTunes d'Apple es poden descarregar gratuïtament.
  • Els càrrecs de l’aplicació iOS de pagament oscil·len de mitjana entre 1,10 i 1,30 $.
  • El preu mitjà d’un joc per a iOS oscil·la entre 0,55 i 0,65 $.

Quantes aplicacions heu fet servir al vostre iPhone, iPod Touch o iPad?

Tot un grapat! Dret? Des de Gmail i Facebook fins a Clash of Clans and Asphalts. Aquest tipus d’aplicacions, el nombre i la varietat d’usuaris aporten problemes seriosos als provadors de programari. No?

Com a provador, també cal fer una prova de la IU en profunditat per verificar l'aplicació a l'iPhone, l'iPod i l'iPad a causa de la variació de les mides.

Proves d'iOS

Com s'ha comentat anteriorment, iOS només es limita al maquinari d'Apple o als dispositius fabricats per Apple. Això és un gran alleujament. Tot i això, hi ha nombrosos dispositius Apple i les seves versions que admeten iOS.

La conclusió és que Apple té un sistema tancat, a diferència d’Android que és un sistema obert. Les versions de sistemes operatius o dispositius estan ben planificades.

Aquest és un avantatge afegit perquè:

  • La mida dels dispositius disponibles o que es llançaran són fixes i, com a control de qualitat, hem de tenir una idea molt clara del que tots els dispositius estan fora del mercat. Es fa fàcil per a un control de qualitat decidir el banc de proves per a la prova
  • Igual que els dispositius, no necessitem fer una anàlisi profunda per al sistema operatiu, ja que es tracta d’un sistema tancat, consumeix menys temps (i esforç) per decidir sobre el banc de proves per a les proves del sistema operatiu.
  • Apple té una bona varietat de les seves pròpies eines d'automatització, tot i que són una mica difícils d'aprendre.
  • Recordo que per fer proves de GPS per a Android vaig haver de passar 2-3 dies per esbrinar com crear scripts falsos per enviar una ubicació falsa. Però va ser molt senzill i senzill a iOS, ja que té una funcionalitat incorporada per enviar GPS falsos per caminar, córrer, anar en bicicleta, etc.
  • Per a les proves inicials, no es recomana provar el GPS mitjançant una prova de camp; és recomanable enviar dades de GPS falses i també estalvia temps.
  • Apple té directrius estrictes per enviar una sol·licitud, és una gran ajuda en lloc de rebutjar-la després de la presentació i té moltes possibilitats d’èxit, a diferència d’altres sistemes operatius on no hi ha directrius estrictes.
  • La funcionalitat del dispositiu i del sistema operatiu en si és fixa i senzilla, de manera que redueix les possibilitats de perdre la forma en què pot funcionar una aplicació. A iOS, no hi ha manera de forçar l’aturació d’una aplicació mentre podem matar i forçar les aplicacions a Android. Per tant, es redueixen les complexitats per provar-les aquí.

Aquests són alguns dels avantatges que obtenim dels productes d'Apple, però no necessàriament que siguin els avantatges de tots els productes o aplicacions. Mentre que per a les aplicacions que es desenvolupen en multiplataforma, iOS és difícil de manejar.

El alt nivell la classificació és la següent:

Classificació de proves

El primer pas per entrar a provar les aplicacions d’IOS és considerar el tipus d’implementació.

La implementació de l'aplicació pot ser qualsevol dels tres tipus següents:

1) Aplicacions basades en web: Aquestes són les aplicacions que es comporten de manera similar a la compilació en aplicacions iOS. Aquests són els llocs web normals als quals accedeix un usuari al navegador Safari de l’iPhone.

2) Sol·licitud nativa: Una aplicació desenvolupada amb l’SDK d’IOS (Software Development Kit) s’executa de forma nativa en els dispositius iOS compatibles com VLC, Flipboard, Uber, etc.

3) Aplicació híbrida: Es tracta de la barreja o híbrid dels dos tipus esmentats anteriorment. Això dóna accés al contingut web a través d’una àrea de visualització de contingut web i també té alguns elements de la interfície d’usuari per a iOS. Per exemple. Zomato, Twitter, Gmail, etc.

Tipus de proves d'aplicacions per a iOS

Els diferents tipus de proves d'aplicacions per a iOS (com es fa en condicions típiques) poden ser els següents:

  • Prova manual: utilització del dispositiu
    • Proves del sistema
    • Proves UI / UX
    • Proves de seguretat
    • Proves de camp
  • Prova manual: utilitzant l'emulador
    • Proves unitàries
    • Proves d’integració
    • Proves d’interfície d’usuari
  • Proves d'automatització
    • Proves de regressió
    • Proves BVT
    • Proves de compatibilitat
    • Proves de rendiment

Exemple d'aplicació:

Abans de passar als diversos aspectes dels processos de proves d’IOS, posem un exemple d’una aplicació típica d’IOS.

Tinguem en compte una sol·licitud de recaptació de fons per a equips esportius. L’aplicació tindrà un compte d’accés social (Google / Facebook) i una pàgina de pagament.

Abans d’anar a la pàgina de pagament, hi hauria d’haver una opció per seleccionar els imports definits pel sistema o un camp personalitzat per introduir l’import. Un cop finalitzat el pagament, s’ha de mostrar un certificat PDF a la pantalla i, al mateix temps, també s’ha d’enviar el PDF al compte de correu electrònic de l’usuari que té la sessió iniciada.

Aplicació iOS

Prova manual: utilització del dispositiu

a) Prova del sistema:

Aquest tipus de proves de iOS es realitzen al sistema per comprovar si els diferents components del sistema funcionen junts.

En aquest procés de prova, l'aplicació iOS es llança en un dispositiu Apple real, seguit de la seva interacció amb la interfície d'usuari per activar un conjunt o conjunts específics d'accions de l'usuari. Les accions típiques de l'usuari poden ser una operació tàctil o una operació de lliscament a la pantalla.

Finalment, el resultat es posa a prova amb el resultat esperat.

Per als nostresExempleindicat anteriorment, una prova de sistema típica pot comprendre els passos següents:

  • Inicieu sessió a l’equip esportiu d’IOS i a l’aplicació de recaptació de fons mitjançant l’inici de sessió del compte de Facebook mitjançant l’autenticació oberta.
  • Seleccioneu una quantitat predefinida del sistema de 10 € entre les opcions indicades.
  • Aneu a la passarel·la de pagament.
  • Seleccioneu l'opció de cartera mòbil PayTm per al procés de pagament.

Les proves del sistema són les operacions que cobreixen principalment els diversos fluxos d’extrem a extrem del sistema. Cada prova s'ha d'executar amb les diverses configuracions disponibles. I també depèn del dispositiu i de la versió d'iOS en què estigui instal·lada l'aplicació.

b) Proves d’interfície d’usuari d’IOS

La IU / UX dels dispositius iOS ha estat un element clau en la seva història d’èxit.

Les proves UI / UX en dispositius iOS es poden classificar en les categories següents:

  • Entrades: Les proves de les funcions de la pantalla tàctil (com ara tacte llarg / curt, tacte 3D, desplaçament), mides de botons, posicionament dels botons, color de les fonts i la seva mida, etc., pertanyen a aquesta categoria.
  • Tecles dures: Les aplicacions natives funcionen perfectament amb les tecles de maquinari / tecles dures incorporades al dispositiu, com ara la tecla d'inici, els botons de so, etc. L'aplicació que es prova també hauria d'interactuar amb les tecles dures de manera similar.
  • Tecles suaus / Teclat suau: Què molesta quan el teclat no apareix quan sou a la pàgina de missatges de Whatsapp? És necessari l’aparició d’un teclat, la possibilitat d’amagar-se quan no el necessiteu, el suport per a emoticones, símbols, tots els caràcters / símbols, etc.
  • En la nostra Exemple , el teclat pot aparèixer a la imatge en diversos llocs, com ara introduir l'import personalitzat, introduir les dades de la credencial / targeta a la passarel·la de pagament, etc.
  • Pantalla: L'aplicació, si és compatible amb diversos dispositius, s'ha de provar de la seva orientació en tots els dispositius. Hi pot haver alguns canvis de resolució en funció del dispositiu que es triï per al procés de prova. Al mateix temps, també s’haurien de fer proves de modes vertical / horitzontal i l’ús del teclat en cadascun dels casos.

Si la vostra aplicació no es crea només per a iOS, hi ha alguns indicadors que cal provar específicament per a iOS, com ara:

  • Llistes: A iOS, quan hi ha una llista que es mostrarà, sempre apareix una pantalla completament nova, a diferència d’Android en què apareix una finestra emergent.

El següent és un exemple del mateix:

Llista d’opcions d’Android

implementació de l'arbre binari c ++

( font )

Llista d’opcions d’iOS

  • Missatges: Quan una aplicació es bloqueja, el missatge que es mostra a iOS és diferent al d'un Android. A més, si ho heu observat, els missatges petits parpellegen als telèfons Android quan allibereu memòria com ara 'S'ha alliberat la memòria #GB', però mai no podem veure missatges flash a iOS.

A continuació es mostra un exemple:

L

Imatge de bloqueig d

( font )

  • Suprimeix la confirmació: Si observeu de prop una aplicació per a iOS, en una finestra emergent de confirmació de supressió, l'acció Cancel·la es troba a l'esquerra de l'opció Suprimeix. Mentre que en Android o en altres sistemes operatius, és viceversa.

Confirmació de supressió d

Confirmació d

Aquests són alguns exemples que necessiten proves i proves independents, ja que iOS té la seva interfície d’usuari, missatges, etc. predeterminats, que no es poden canviar.

c) Proves de seguretat:

En la nostra exemple , tenim una aplicació amb una passarel·la de pagament i una pàgina d'inici de sessió compatible amb la integració de pàgines socials.

Per exemple , suposem que teniu una aplicació ICICI al telèfon i quan inicieu la sessió en lloc de la informació del compte si es mostra la informació d'una altra persona o si feu una transferència de diners i l'aplicació envia l'OTP a algun altre número de telèfon que no sigui vostre , us podeu imaginar què passarà. Per tant, les proves de seguretat són imprescindibles.

Les dades en termes d’inici de sessió a les xarxes socials i la passarel·la de pagament s’han de xifrar o protegir per tal de protegir l’aplicació dels pirates informàtics.

d) Prova de camp:

Es fa una prova de camp per verificar el comportament de l’aplicació a la xarxa de dades del telèfon.

Aquesta prova sol fer-se quan l’aplicació arriba a una fase estable i no s’estavella quan es prova a casa i s’han solucionat tots els problemes de funcionalitat. Això es fa principalment per provar el rendiment de l'aplicació a la xarxa de dades lenta.

Prova manual: utilitzant l'emulador

a) Proves unitàries:

Ho fa principalment l’equip de desenvolupament / desenvolupador individual. Aquesta prova comprova si un mòdul concret del codi font funciona o no tal com s’esperava.

Els desenvolupadors dissenyen casos de prova d’unitat per a un sol component, és a dir, un mòdul aïllat en què treballen. Aquesta prova demostra que el mòdul individual funciona i després s'injecta al codi font perquè funcioni com a element de l'arquitectura integrada. Com diu la capçalera, es tracta principalment d’una prova manual que es fa mitjançant emulació de prova.

b) Proves d'integració:

En els passos anteriors, vam discutir més sobre les proves d’unitats. Ara, com que estem segurs de la funcionalitat de les unitats / mòduls individuals, es fa necessari comprovar també la integració. Aquesta prova es realitza per esbrinar els problemes relacionats amb diversos punts d’integració.

En la nostra Exemples , podem trucar a l'inici de sessió com a un mòdul i a la passarel·la de pagament com a un altre mòdul.

Les proves unitàries cobriran les proves de tots dos individualment. Tot i això, les proves d’integració posaran a prova la integritat dels dos mòduls.

c) Proves d’interfície d’usuari:

Com s’ha explicat anteriorment, cal fer una prova d’interfície d’usuari per a una aplicació, ja que és un factor clau per a l’èxit de l’aplicació.

Practicar la compra de tots els models de telèfons per fer proves pràcticament no és possible, ja que costaria molt. Per tant, l’ús de l’emulador és la millor opció, ja que és gratuït i també es detecten fàcilment errors d’interfície d’usuari obvis als emuladors.

Automatització iOS

a) Proves de regressió:

En un entorn en constant canvi, els canvis es realitzen contínuament per millorar l'aplicació o per solucionar els problemes que es van trobar a la versió anterior de la mateixa. Mentre s’implementen els canvis, hi ha la possibilitat que els canvis realitzats a l’aplicació puguin alterar la funcionalitat existent.

En termes senzills, els canvis fets poden introduir un nou conjunt de problemes a l'aplicació.

Per verificar si l'aplicació funciona de la mateixa manera, fins i tot després d'implementar els canvis, cal realitzar proves de regressió. I, com que es tracta d’una activitat repetitiva, l’automatització és útil per a aquest tipus de proves.

b) Proves BVT:

És un bon costum que s’executi una suite automàtica a la nova versió per provar-la, ja que estalvia molt de temps i, si les funcionalitats bàsiques s’estavellen, s’informa immediatament. En comparació amb un esforç manual, es poden prendre els resultats de les proves de verificació bàsica automatitzades per acceptar o rebutjar una compilació en qüestió de minuts.

c) Proves de compatibilitat:

Com es va comentar, hi ha nombrosos dispositius / tipus que Apple publica. Per ser exactes, hi ha 15 tipus diferents d’iPhones, 6 models d’iPod Touch, 10 models d’iPad i 2 models d’iPad Pro al mercat.

Ara, quan es desenvolupi una aplicació com la nostra (aplicació de recaptació de fons per a equips esportius), hauria de ser compatible amb tots els dispositius esmentats anteriorment. Això implica una cosa que: tots els casos de prova s’executen en tots aquests dispositius.

Ara, l’esforç manual no és possible quan el nombre de dispositius és enorme. Per a la compatibilitat, es prefereixen les proves d'automatització.

d) Proves de rendiment:

Alguns dels que es posen a prova a les proves de rendiment són:

  • Com es comporta l'aplicació quan es fa operativa o s'executa durant molt de temps. Durant el període operatiu, feu que l'aplicació es comuniqui / interactuï / quedi inactiva.
  • Cal realitzar la mateixa operació amb la quantitat de càrregues diferent cada vegada.
  • Com es comporta el sistema quan la transferència de dades és realment enorme.

Aquests casos tenen un caràcter repetitiu i es fan principalment mitjançant automatització.

Pràctiques recomanades per provar aplicacions per a iOS

Provar aplicacions d’IOS pot ser difícil, complicat i difícil, tret que es faci correctament.

Per tal de moure les proves de l'aplicació iOS en la direcció correcta, es poden implementar les pràctiques següents:

# 1) Oblida els emuladors: En la majoria dels casos, els emuladors es prefereixen als dispositius reals. Però, aquest no és el cas ideal. Coses com les interaccions dels usuaris, el consum de bateria, la disponibilitat de la xarxa, el rendiment en l’ús i l’assignació de memòria no es poden provar als emuladors. Per tant, proveu de provar en dispositius reals tot el temps.

# 2) Automatitzeu les coses en lloc de fer-les manualment: Quina rapidesa teniu en fer una tasca específica? Al món actual, tothom es preocupa principalment pel temps dedicat. L’automatització no només redueix el temps d’execució, sinó que també augmenta l’eficàcia, l’eficiència i la cobertura de les proves de programari.

# 3) Comparteix la feina: Comparteix les proves entre equips, inclòs l’equip de desenvolupament. Podem obtenir ajuda en termes d’execució manual dels casos de prova, així com obtenir l’ajuda de l’equip de desenvolupament per automatitzar els casos de prova manuals.

# 4) Agafeu els registres de bloqueig: És possible que l'aplicació per a iOS estigui congelant o bloquejant-se en determinades circumstàncies. Per solucionar el problema, els registres de bloqueig tenen un paper fonamental.

Es poden realitzar els passos següents per capturar els registres de bloqueig:

  • Per a MacOS:
    • Sincronitzeu el dispositiu iOS amb l'ordinador (Mac).
    • Per a Mac OS, manteniu premuda la tecla Opció per obrir la barra de menú.
    • Aneu al menú Vés i feu clic a Biblioteca.
    • Aneu a ~ / Library / Logs / CrashReporter / MobileDevice //.
    • El nom del fitxer de registre hauria de començar amb el nom de l’aplicació.
  • Per al sistema operatiu Windows:
    • Sincronitzeu el dispositiu iOS amb l'ordinador (Windows).
    • Aneu a C: Users AppData Roaming Applecomputer Logs CrashReporter MobileDevice \
    • El nom del fitxer de registre hauria de començar amb el nom de l’aplicació.

# 5) Captura dels registres de la consola:

Els registres de consola proporcionen la informació general de les aplicacions al dispositiu iOS.

Això es pot fer mitjançant eines com iTools. A l'aplicació iTools, feu clic a la icona 'Caixa d'eines' quan el dispositiu iOS estigui connectat al sistema en què s'executa iTools. En fer clic a 'Registre en temps real' es visualitza el registre de la consola en temps real.

# 6) Pantalla de captura: Es fa fàcil entendre el problema i, per tant, és fàcil de solucionar si els passos són visuals.

És recomanable enregistrar la pantalla o fer captures de pantalla dels problemes per fer que l'equip de desenvolupament els entengui millor. La captura de pantalla es pot fer mitjançant la funció integrada prement els botons d’engegada i Inici.

La gravació d’una pantalla es pot fer mitjançant la gravació del reproductor de temps ràpid mentre el dispositiu iOS està connectat a Mac mitjançant el cable llamp.

Marcs d’automatització d’IOS

A continuació s’enumeren alguns dels marcs d’automatització més utilitzats:

# 1) èpoques;

Appium utilitza el controlador Selenium Web per automatitzar les proves d'aplicacions per a iOS.

Aquesta plataforma és independent i es pot utilitzar tant al web com als dispositius mòbils (tant Android com iOS). Aquest és de codi obert i no està restringit per l'idioma. No es requereixen canvis d’aplicacions ni accés al codi font per automatitzar amb Appium.

Appium funciona perfectament independentment del tipus d’aplicació: sigui nativa, híbrida o web.

# 2) Calabassa:

Calabash és un framework multiplataforma de codi obert que admet les proves d'automatització d'Android i iOS.

Les proves de calabaza s’escriuen en cogombre, que és similar a la d’una especificació i és fàcil d’entendre. Calabash consisteix en biblioteques que permeten a l'usuari interactuar amb aplicacions natives i híbrides. Admet interaccions com gestos, afirmacions, captures de pantalla, etc.

# 3) Earl Grey:

Earl Gray és el marc de proves intern de la interfície d’usuari propi de Google. S'ha utilitzat per provar YouTube, Google Photos, Google Play Music, Google Calendar, etc.

Earl Grey s'ha creat de codi obert recentment. Alguns dels principals avantatges d’Earl Grey són: sincronització integrada, comprovacions de visibilitat abans de les interaccions, interacció real de l’usuari (puntejar, lliscar, etc.). És molt similar a Espresso de Google, que s’utilitza per a l’automatització de la interfície d’usuari d’Android.

# 4) Automatització de la IU:

UI Automation és desenvolupat per Apple i és molt similar a UI Automator a Android. Apple defineix les API i les proves s’escriuen en JAVA.

# 5) COM:

KIF significa 'Keep it Functional'. Es tracta d'un marc de codi obert i de tercers.

Es tracta d’un marc de proves d’integració d’IOS que està estretament relacionat amb els objectius de prova XCTest i s’utilitza per a aquest. El KIF és fàcil de configurar o integrar amb el projecte Xcode i, per tant, no cal un servidor web addicional ni paquets addicionals. KIF té una àmplia cobertura en termes de versions d'iOS.

Conclusió

La prova d'aplicacions iOS pot ser una tasca molt difícil de fer. Espero que tingueu una bona comprensió de les proves d'aplicacions per a iOS a través d'aquest article.

Tanmateix, si seleccioneu l'enfocament adequat, el millor procés de proves possible, metodologies, eines, emuladors / dispositius, etc., les proves d'aplicacions iOS seran molt reeixides.

El nostre proper tutorial us informarà de tots els conceptes bàsics implicats Tutorial de proves d'aplicacions d'Android .

Lectura recomanada

^