Tutorials de proves d'aplicacions mòbils (una guia completa amb més de 30 tutorials)

mobile app testing tutorials

Proveu El Nostre Instrument Per Eliminar Problemes

Seleccioneu El Sistema Operatiu Trieu Un Programa De Projecció (Opcionalment)

Descriviu El Vostre Problema

Una guia completa per provar aplicacions mòbils amb tutorials en profunditat:

La tecnologia mòbil i els dispositius intel·ligents són la tendència actual i canviaran el futur del món tal com el coneixem. Tots ho podem assegurar no, no? Ara, serà aficionat si enumero per a què fem servir aquests dispositius mòbils. Ho sabeu tots: potser millor que nosaltres.

Anem directament a què tractarà aquest tutorial.

La llista completa de més de 30 tutorials sobre proves mòbils:

proves d

Introducció a les proves mòbils:

Tutorial # 1: Introducció a les proves mòbils
Tutorial # 2: Prova d'aplicacions per a iOS
Tutorial # 3: Proves d'aplicacions d'Android
Tutorial # 4 : Desafiaments i solucions per a proves mòbils
Tutorial # 5: Per què les proves per a mòbils són difícils?

Prova de dispositius mòbils:

Tutorial # 6: Proveu una versió d'Android quan es tregui del mercat
Tutorial # 7 : Com provar aplicacions mòbils en dispositius de gamma baixa
Tutorial # 8 : Prova de camp per a aplicacions mòbils
Tutorial # 9: Model de telèfon contra la versió del sistema operatiu: quina s'ha de provar primer?

Proves de la IU mòbil:

Tutorial # 10: Proves d'interfície d'usuari d'aplicacions mòbils
Tutorial # 11: Prova de resposta mòbil

Serveis de proves mòbils:

Tutorial # 12: Proves d'aplicacions mòbils basades en el núvol
Tutorial # 13: Serveis de proves mòbils
Tutorial # 14 : Serveis de proves beta d'aplicacions mòbils
Tutorial # 15: Empresa de desenvolupament d'aplicacions mòbils
Tutorial # 16: Proveïdors de serveis de proves d'aplicacions mòbils basades en el núvol

Proves de seguretat i de rendiment de les aplicacions mòbils:

Tutorial # 17: Proves de rendiment d'aplicacions mòbils mitjançant BlazeMeter
Tutorial # 18 : Directrius de proves de seguretat de les aplicacions mòbils

Eines de prova per a mòbils:

Tutorial # 19: Eines de prova d'aplicacions d'Android
Tutorial # 20: Les millors eines de proves de seguretat de les aplicacions mòbils
Tutorial # 21: 58 Millors eines de prova per a mòbils

Proves d'automatització mòbil:

Tutorial # 22: Tutorial de l'Appium Mobile Automation Tool
Tutorial # 23: Tutorial d'Appium Studio
Tutorial # 24: Automatitzeu les aplicacions d'Android mitjançant l'eina TestComplete
Tutorial # 25 : Tutorial de Robotium: eina de prova de la interfície d'usuari de l'aplicació Android
Tutorial # 26: Tutorial Selendroid: Mobile Automation Framework
Tutorial # 27: pCloudy Tutorial: proves d'aplicacions mòbils en dispositius reals
Tutorial # 28: Tutorial de Granja de dispositius basats en el núvol de Katalon Studio i Kobiton

Carrera de proves mòbils:

Tutorial # 29: Com aconseguir un treball de prova mòbil ràpidament
Tutorial # 30: Preguntes i currículum de les entrevistes de proves mòbils
Tutorial # 31: Preguntes d’entrevistes de proves mòbils, segona part

************************************************** ***********

Comencem pel primer tutorial de la sèrie.

Què aprendreu:

Tutorial núm. 1: Introducció a la prova d'aplicacions mòbils

Tutorial núm. 1: Introducció a la prova d'aplicacions mòbils

Enrere van quedar els temps en què el telèfon solia ser un electrodomèstic que estava assegut en un racó i que havia de sonar per cridar la nostra atenció o que l’ordinador era una màquina que només feien servir algunes poques persones - ara són una extensió del nostre ésser - una finestra al servidors mundials i virtuals que fan el que se’ls diu.

Els ordinadors tenien ràbia i van canviar la manera com els humans pensàvem, ens comportàvem, apreníem i existíem.

Actualment, les solucions de mobilitat s’han apoderat del mercat. La gent no vol engegar els seus ordinadors portàtils / PC per a tot, sinó que vol que els seus dispositius de mà ho facin tot ràpidament.

Per tant, les solucions mòbils que oferim als nostres clients s’han de provar molt bé. Aquest tutorial està pensat per a aquelles persones que ja estan fent proves per a mòbils o aquells que hi han canviat els darrers temps. Com que ja tenim molts tutorials sobre definicions de terminologies relacionades amb les proves mòbils, tractarem directament l’abast d’aquest tutorial.

Aquest tutorial serà tant una introducció com la vostra guia de proves per a mòbils. Per tant, llegiu-ho!

Tipus de proves per a mòbils

En general, hi ha dos tipus de proves que es fan en dispositius mòbils:

# 1. Proves de maquinari:

El dispositiu, inclosos els processadors interns, maquinari intern, mides de pantalla, resolució, espai o memòria, càmera, ràdio, Bluetooth, WIFI, etc.Prova mòbil'.

# 2. Proves de programari o d'aplicació:

Es proven les aplicacions que funcionen en dispositius mòbils i la seva funcionalitat. Es diu el 'Proves d'aplicacions mòbils”Per diferenciar-lo del mètode anterior. Fins i tot en aplicacions mòbils, hi ha poques diferències bàsiques que siguin importants per entendre:

a) Aplicacions natives: Es crea una aplicació nativa per utilitzar-la en una plataforma com ara mòbils i tauletes.
b) Aplicacions web per a mòbils són aplicacions del servidor per accedir als llocs web o mòbils mitjançant diferents navegadors com Chrome, Firefox connectant-se a una xarxa mòbil o a una xarxa sense fils com WIFI.
c) Aplicacions híbrides són combinacions d'aplicacions natives i d'aplicacions web. S’executen en dispositius o fora de línia i s’escriuen mitjançant tecnologies web com HTML5 i CSS.

Hi ha poques diferències bàsiques que les diferenciïn:

Les aplicacions natives tenen una afinitat de plataforma única, mentre que les aplicacions web per a mòbils tenen l’afinitat entre plataformes.
Les aplicacions natives s’escriuen en plataformes com a SDK, mentre que les aplicacions web per a mòbils s’escriuen amb tecnologies web com HTML, CSS, asp.net, Java, PHP.
Per a una aplicació nativa, cal instal·lar-la, però per a aplicacions web per a mòbils, no cal instal·lar-la.
Una aplicació nativa es pot actualitzar des de la botiga de jocs o aplicacions, mentre que les aplicacions web per a mòbils són actualitzacions centralitzades.
Moltes aplicacions natives no requereixen connexió a Internet, però per a aplicacions web per a mòbils és imprescindible.
Les aplicacions natives funcionen més ràpidament en comparació amb les aplicacions web per a mòbils.
Les aplicacions natives s’instal·len en botigues d’aplicacions com ara Google Play Store o bé Tenda d'aplicacions on els llocs web mòbils són llocs web i només són accessibles a través d'Internet.

La resta de l'article tractarà sobre les proves d'aplicacions mòbils.

La importància de les proves d'aplicacions mòbils

Provar aplicacions en dispositius mòbils és més difícil que provar aplicacions web a l’escriptori

Diversos dispositius mòbils amb diferents mides de pantalla i configuracions de maquinari, com ara un teclat dur, un teclat virtual (pantalla tàctil) i un trackball, etc.
Àmplia varietat de dispositius mòbils com HTC, Samsung, Apple i Nokia.
Diferents sistemes operatius mòbils com Android, Symbian, Windows, Blackberry i iOS.
Diferents versions del sistema operatiu com iOS 5.x, iOS 6.x, BB5.x, BB6.x, etc.
Diferents operadors de xarxes mòbils com GSM i CDMA.
Actualitzacions freqüents (com ara Android-4.2, 4.3, 4.4, iOS-5.x, 6.x): amb cada actualització es recomana un nou cicle de proves per assegurar-se que no afecti cap funcionalitat de l'aplicació.

Com passa amb qualsevol aplicació, les proves d'aplicacions mòbils també són molt importants, ja que la clientela sol ser en milions per a un determinat producte, i mai no s'aprecia un producte amb errors. Sovint provoca pèrdues monetàries, problemes legals i danys irreparables a la imatge de marca.

Diferència bàsica entre les proves d'aplicacions per a mòbils i d'escriptori:

Pocs aspectes obvis que diferencien les proves d'aplicacions mòbils de les proves d'escriptori

A l'escriptori, l'aplicació es prova en una unitat de processament central. En un dispositiu mòbil, l'aplicació es prova en telèfons mòbils com Samsung, Nokia, Apple i HTC.
La mida de la pantalla del dispositiu mòbil és més petita que l’escriptori.
Els dispositius mòbils tenen menys memòria que un escriptori.
Els mòbils utilitzen connexions de xarxa com 2G, 3G, 4G o WIFI, quan l’escriptori utilitza connexions de banda ampla o de connexió telefònica.
És possible que l'eina d'automatització que s'utilitza per provar aplicacions d'escriptori no funcioni en aplicacions mòbils.

Tipus de proves d'aplicacions mòbils:

Per abordar tots els aspectes tècnics anteriors, es realitzen els següents tipus de proves en aplicacions mòbils.

Proves d’usabilitat - Per assegurar-se que l’aplicació mòbil sigui fàcil d’utilitzar i proporcioni una experiència d’usuari satisfactòria als clients
Proves de compatibilitat - Prova de l'aplicació en diferents dispositius mòbils, navegadors, mides de pantalla i versions del sistema operatiu segons els requisits.
Proves d'interfície - Prova d’opcions de menú, botons, adreces d'interès, historial, configuració i flux de navegació de l'aplicació.
Proves de serveis - Prova dels serveis de l'aplicació en línia i fora de línia.
Proves de recursos de baix nivell : Proves d'ús de memòria, supressió automàtica de fitxers temporals, problemes de creixement de bases de dades locals coneguts com a proves de recursos de baix nivell.
Proves de rendiment - Provar el rendiment de l'aplicació canviant la connexió de 2G, 3G a WIFI, compartint els documents, el consum de bateria, etc.
Proves operatives - Proves de còpies de seguretat i pla de recuperació si la bateria cau o pèrdua de dades mentre actualitzeu l'aplicació des d'una botiga.
Proves d'instal·lació - Validació de l'aplicació instal·lant-la / desinstal·lant-la als dispositius.
Proves de seguretat - Prova d'una aplicació per validar si el sistema d'informació protegeix o no les dades.

Estratègia de proves d'aplicacions mòbils

L'estratègia de prova s'ha d'assegurar que es compleixin totes les pautes de qualitat i rendiment. Alguns consells sobre aquesta àrea:

1) Selecció dels dispositius - Analitzeu el mercat i trieu els dispositius que s’utilitzen àmpliament. (Aquesta decisió es basa principalment en els clients. El client o els creadors d'aplicacions tenen en compte el factor de popularitat de certs dispositius, així com les necessitats de màrqueting perquè l'aplicació decideixi quins telèfons utilitzar per provar-los).

2) Emuladors - L 'ús d' aquests és extremadament útil en fases inicials de desenvolupament, ja que permeten una comprovació ràpida i eficaç de l'aplicació. L'emulador és un sistema que executa programari d'un entorn a un altre sense canviar el propi programari. Duplica les funcions i funciona al sistema real.

Tipus d’emuladors mòbils

Emulador de dispositius: subministrat pels fabricants de dispositius
Emulador de navegador: simula entorns de navegadors mòbils.
Emulador de sistemes operatius: Apple proporciona emuladors per a iPhones, Microsoft per a telèfons Windows i Google Android

Eina recomanada

# 1) Kobiton

Kobiton és una plataforma d’experiència mòbil basada en el núvol assequible i altament flexible que accelera les proves i el lliurament d’aplicacions natives, web i híbrides en Android i iOS mitjançant dispositius reals. La seva nova automatització de proves sense scripts ajuda els equips sense experiència en codificació a generar scripts Appium estàndard oberts amb facilitat.

Kobiton Nou

=> Visiteu el lloc web de Kobiton

quin programa obriu el fitxer eps

Llista de pocs emuladors de dispositius mòbils gratuïts i fàcils d’utilitzar

jo. Emulador de telèfons mòbils - S’utilitza per provar telèfons com iPhone, Blackberry, HTC, Samsung, etc.

emulador de dispositius mòbils 2

ii. MobiReady - Amb això, no només podem provar l'aplicació web, també podem comprovar el codi.

emulador de dispositius mòbils 3

iii. Responsivepx - Comprova les respostes de les pàgines web, les aparicions i la funcionalitat dels llocs web.

emulador de dispositius mòbils 4

iv. Screenfly - És una eina personalitzable que s’utilitza per provar llocs web en diferents categories.

emulador de dispositius mòbils 5

3) Un cop s'hagi completat el nivell de desenvolupament satisfactori de l'aplicació mòbil, podeu passar a provar-lo a dispositius físics per obtenir proves basades en escenaris més reals.

4) Penseu en les proves basades en computació en núvol: La computació en núvol bàsicament executa dispositius en diversos sistemes o xarxes a través d’Internet on les aplicacions es poden provar, actualitzar i gestionar. A efectes de proves, crea l'entorn mòbil basat en web en un simulador per accedir a l'aplicació mòbil.

proves mòbils basades en el núvol

Pros:

Còpia de seguretat i recuperació: la computació en núvol realitza automàticament una còpia de seguretat de les vostres dades des d'una ubicació remota, cosa que facilita la recuperació i la restauració de les dades. A més, la capacitat d’emmagatzematge és il·limitada.
Es pot accedir als núvols des de diferents dispositius i des de qualsevol lloc.
La computació en núvol és rendible, fàcil d’utilitzar, mantenir i actualitzar.
Desplegament ràpid i ràpid.
Interfície basada en web.
Pot executar el mateix script en diversos dispositius en paral·lel.

Contres

Menys control - Atès que l'aplicació s'executa a l'entorn remot o de tercers, l'usuari té un control i accés limitat a les funcions.
Problemes de connectivitat a Internet - la configuració és a Internet. Els problemes de xarxa afecten la disponibilitat i el funcionament
Problemes de seguretat i privadesa - La computació en núvol és una informàtica a Internet i res a Internet és completament segur, de manera que les probabilitats de pirateria de dades són més grans.

5) Automatització vs. proves manuals

Si l'aplicació conté una nova funcionalitat, proveu-la manualment.
Si l'aplicació requereix proves una o dues vegades, feu-ho manualment.
Automatitzeu els scripts per a casos de proves de regressió. Si es repeteixen les proves de regressió, les proves automàtiques són perfectes per a això.
Automatitzeu els scripts per a escenaris complexos que requereixen molt de temps si s’executen manualment.

Hi ha dos tipus d'eines d'automatització disponibles per provar aplicacions mòbils:

Eines de proves mòbils basades en objectes - Automatització mitjançant el mapatge d’elements de la pantalla del dispositiu en objectes. Aquest enfocament és independent de la mida de la pantalla i s'utilitza principalment per a dispositius Android.

Per exemple: - Ranorex, solució de jamo

Eines de proves per a mòbils basades en imatges - crear scripts d'automatització basats en les coordenades de la pantalla dels elements.

Per exemple: - Sikuli, planta d’ous, RoutineBot

6) Xarxa configuració també és la part necessària de les proves mòbils. És important validar l’aplicació en diferents xarxes com 2G, 3G, 4G o WIFI.

Casos de prova per provar una aplicació mòbil

A més dels casos de prova basats en la funcionalitat, les proves d'aplicacions mòbils requereixen casos de prova especials que haurien de cobrir els següents escenaris.

Ús de la bateria - És important fer un seguiment del consum de bateria mentre s’executa l’aplicació als dispositius mòbils.
La velocitat de l’aplicació el temps de resposta en diferents dispositius, amb paràmetres de memòria diferents, amb diferents tipus de xarxa, etc.
Requisits de dades - Per a la instal·lació i per verificar si l'usuari amb el pla de dades limitat el podrà descarregar.
Requisit de memòria - de nou, per descarregar, instal·lar i executar
La funcionalitat de l'aplicació - Assegureu-vos que l'aplicació no es bloqueja a causa d'un error de xarxa o de qualsevol altra cosa.

descarregarAlguns exemples de casos de prova per provar aplicacions mòbils:

=> Baixeu casos de prova de mostra d'aplicacions mòbils

Activitats i procediments típics a Proves d'aplicacions mòbils

L'abast de les proves depèn d'una sèrie de requisits que cal verificar o de l'extensió dels canvis realitzats a l'aplicació. Si els canvis són pocs, una ronda de seny les proves ho faran. En cas de canvis importants i / o complexos, a regressió completa es recomana.

Un exemple de projecte de proves d'aplicacions : ILL (International Learn Lab) és una aplicació dissenyada per ajudar l'administrador i editor a crear llocs web en col·laboració. Mitjançant un navegador web, els instructors trien entre un conjunt de funcions per crear una classe que compleixi els seus requisits.

Procés de proves mòbils:

Pas 1. Identifiqueu el fitxer tipus de proves : Com que una aplicació ILL és aplicable als navegadors, és obligatori provar aquesta aplicació en tots els navegadors compatibles que utilitzin diferents dispositius mòbils. Ho hem de fer usabilitat, funcional i compatibilitat proves en diferents navegadors amb combinacions de manual i automatització casos de prova.

Pas 2. Proves manuals i automatitzades: La metodologia seguida per aquest projecte és Agile amb la iteració de dues setmanes. Cada dues setmanes dev. L'equip llança una nova versió per a l'equip de proves i l'equip de proves executarà els seus casos de prova en un entorn de control de qualitat. L’equip d’automatització crea scripts per al conjunt de funcionalitats bàsiques i executa els scripts que ajuden a determinar si la nova versió és prou estable per provar-la. L’equip de proves manuals provarà la nova funcionalitat.

JIRA s’utilitza per escriure criteris d’acceptació; manteniment de casos de prova i registre / verificació de defectes. Un cop finalitzada la iteració, iteració planificació reunió celebrada on dev. L’equip, el propietari del producte, l’analista de negocis i l’equip de control de qualitat discuteixen el que va anar bé i què cal millorar .

Pas 3. Prova beta: Un cop l'equip de control de qualitat realitza les proves de regressió, la compilació passa a UAT. El client fa les proves d’acceptació de l’usuari. Tornen a verificar tots els errors per assegurar-se que tots els errors s'han corregit i que l'aplicació funciona com s'esperava en tots els navegadors aprovats.

Pas 4. Prova de rendiment: L'equip de proves de rendiment prova el rendiment de l'aplicació web mitjançant scripts JMeter i amb diferents càrregues de l'aplicació.

quin és el millor descarregador de YouTube gratuït

Pas 5. Proves del navegador : L'aplicació web es prova en diversos navegadors, tant mitjançant diferents eines de simulació com físicament mitjançant dispositius mòbils reals.

Pas 6. Pla de llançament: Després de cada 4a setmana, les proves passen a la fase de prova, on es realitza una prova final de punta a punta en aquests dispositius per assegurar-se que el producte està llest per a la producció. I després, es posa en directe!

*****************************************

Com provar aplicacions mòbils en plataformes Android i iOS

Prova d

És molt important que els provadors que provin les seves aplicacions tant a iOS com a Android Platform coneguin la diferència entre ambdues. iOS i Android tenen moltes diferències respecte a l’aspecte, les visualitzacions de les aplicacions, els estàndards de codificació, el rendiment, etc.

Diferència bàsica entre les proves d'Android i iOS

És possible que hàgiu passat tots els tutorials, he posat algunes diferències importants aquí, que al seu torn us ajudaran com a part de les proves:

# 1) Com que tenim molts dispositius Android disponibles al mercat i tots ells presenten diferents resolucions i mides de pantalla, per tant, aquesta és una de les diferències principals.

Per exemple , La mida del Samsung S2 és massa petita en comparació amb Nexus 6. Hi ha moltes possibilitats que el disseny i el disseny de l'aplicació es distorsionin en un dels dispositius. La probabilitat és baixa a iOS, ja que només hi ha dispositius comptables disponibles al mercat i d’aquests molts telèfons tenen resolucions similars.

Per exemple, abans de l'iPhone 6 i versions posteriors, totes les versions anteriors només tenien la mateixa mida.

# 2) Un exemple per afirmar el punt anterior és que a Android els desenvolupadors han d’utilitzar imatges 1x, 2x, 3x, 4x i 5x per donar suport a resolucions d’imatges per a tots els dispositius, mentre que iOS només utilitza 1x, 2x i 3x. Tot i això, es fa responsable del verificador assegurar-se que les imatges i els altres elements de la interfície d’usuari es mostren correctament a tots els dispositius.

Podeu consultar el diagrama següent per entendre el concepte de resolucions d’imatges:

Resolucions mòbils

# 3) Com que el mercat està inundat de dispositius Android, el codi s'ha d'escriure de manera que el rendiment es mantingui constant. Per tant, és molt probable que la vostra aplicació es comporti lentament en dispositius de gamma baixa.

# 4) Un altre problema amb Android és que les actualitzacions de programari no estan disponibles per a tots els dispositius alhora. Els fabricants de dispositius decideixen quan actualitzen els seus dispositius. Es converteix en una tasca molt difícil provar-ho tot amb el sistema operatiu nou i el sistema operatiu antic.

A més, es fa una tasca feixuga per als desenvolupadors modificar el seu codi per admetre les dues versions.

Per exemple , quan va arribar Android 6.0, hi va haver un canvi important ja que aquest sistema operatiu va començar a admetre permisos a nivell d'aplicació. Per aclarir més, l’usuari podria també canvieu els permisos (ubicació, contactes) a nivell d'aplicació.

Ara l’equip de proves té la responsabilitat d’assegurar-se que es mostri la pantalla de permisos al llançament de l’aplicació a Android 6.0 i versions posteriors i no es mostri la pantalla de permisos a les versions inferiors.

# 5) Des de la perspectiva de les proves, les proves de compilació de preproducció (és a dir, versió beta) són diferents a les dues plataformes. A Android, si s’afegeix un usuari a la llista d’usuaris beta, pot veure la versió beta actualitzada a Play Store només si té la sessió iniciada a Play Store amb el mateix identificador de correu electrònic que s’afegeix com a usuari beta.

Factors clau en les proves mòbils

He estat treballant a Mobile Testing durant els darrers 2 anys, tant en iOS com en Android Platform, i tots els punts clau que s’esmenten a continuació en aquest tutorial provenen de la meva experiència personal i alguns s’han derivat dels problemes trobats al projecte.

Definiu el vostre propi abast de proves

Tothom té el seu propi estil de proves. Alguns provadors només se centren en el que veuen des dels seus ulls i la resta s’apassiona per tot el que funciona entre bastidors de qualsevol aplicació mòbil.

Si sou un iOS / Android Tester, us suggeriria que, com a mínim, us familiaritzeu amb algunes limitacions comunes / funcionalitats bàsiques d'Android o iOS, ja que sempre aporta valor al nostre estil de proves. Sé que les coses són difícils d’entendre sense citar exemples.

A continuació es detallen alguns exemples:

No podem canviar els permisos com ara càmera, emmagatzematge, etc. a nivell d'aplicació en dispositius Android que estiguin per sota de la versió 6.0.1.
Per a la versió iOS inferior a la versió 10.0, el kit de trucades no hi era. Només per informar-vos amb paraules senzilles, el joc de trucades l’utilitza una aplicació de trucades i mostra una visualització de pantalla completa quan un usuari rep una trucada des de les aplicacions de trucades com WhatsApp, Skype, etc. Mentre que per a versions d’iOS inferiors a 10.0, veiem aquestes trucades com a bàner de notificació.
És possible que molts de vosaltres us hagueu trobat amb problemes a Paytm, on la vostra aplicació no us redirigeix a la pàgina de pagaments del banc per si voleu afegir diners a la vostra cartera. Creiem que l’anterior és un problema amb el nostre banc o servidor Paytm, però és que el nostre AndroidSystemWebView no s’actualitza. El poc coneixement sobre programació sempre és útil per a vosaltres i per compartir amb el vostre equip.
En paraules simples, cada vegada que una aplicació obre qualsevol pàgina web, s'hauria d'actualitzar AndroidSystemWebView.

Abast de les proves

No limiteu les proves

Les proves no només s'han de limitar a explorar l'aplicació mòbil i registrar errors. Nosaltres, com a control de qualitat, hauríem de ser conscients de totes les sol·licituds que arribem al nostre servidor i de la resposta que en rebem.

Configureu Putty per veure els registres o verificar la lògica sumo per als registres en funció del que s’utilitzi al vostre projecte. No només us ajuda a conèixer el flux de punta a punta de l’aplicació, sinó que també us converteix en un millor provador a mesura que obteniu més idees i escenaris.

Diagrama Floe del servidor mòbil

Motiu: Res no entra al món sense cap motiu. Qualsevol afirmació hauria de tenir un motiu vàlid darrere. El motiu darrere de l’anàlisi dels registres és que s’observen moltes excepcions als registres, però que no mostren cap impacte a la interfície d’usuari, per tant no ho notem.

Per tant, l’hem d’ignorar?

No, no ho hauríem de fer. No té cap impacte en la interfície d’usuari, però pot ser una preocupació futurista. Podríem veure que la nostra aplicació es bloqueja si aquest tipus d’excepció continua arrossegant-se. Com hem esmentat sobre App Crash a la darrera frase, això fa que el control de qualitat tingui accés a crashlytics del projecte.

Crashlytics és una eina on es registren els bloquejos juntament amb el model de temps i de dispositiu.

Ara la pregunta aquí és que si el provador ha vist que l'aplicació es bloqueja, per què s'ha de preocupar dels crashlytics?

La resposta a això és força interessant. Hi ha alguns bloquejos que poden no ser visibles a la interfície d’usuari, però que estan registrats a crashlytics. Pot ser que no hi hagi cap bloqueig de memòria o algunes excepcions mortals que puguin afectar el rendiment més endavant.

Proves multiplataforma

Les proves d’interacció multiplataforma són molt importants.

Citant un simple Exemple , diguem que esteu treballant en una aplicació de xat com WhatsApp que admet l’enviament d’imatges i vídeos i que l’aplicació està basada en plataformes iOS i Android (el desenvolupament pot estar sincronitzat o no)

Assegureu-vos de provar la comunicació d'Android i iOS, la raó és que iOS fa servir 'Objective C', mentre que la programació d'Android es basa en Java i, a causa de que tots dos es construeixen en plataformes diferents, de vegades cal fer correccions addicionals a l'aplicació. per reconèixer cadenes provinents de diferents plataformes de llenguatge.

Vigileu la mida de la vostra aplicació mòbil

Un altre consell important per als provadors de mòbils. Seguiu revisant mida de la vostra aplicació després de cada llançament.

Hem d’assegurar-nos que la mida de l’aplicació no arriba a un punt en què ni nosaltres, com a usuari final, no voldríem baixar aquesta aplicació a causa de la seva gran mida.

Prova d’escenaris d’actualització d’aplicacions

Per als provadors mòbils, proves d'actualització d'aplicacions és molt important. Assegureu-vos que l'aplicació no es bloqueja a l'actualització, ja que és possible que l'equip de desenvolupadors no hagi coincidit un número de versió.

La retenció de dades també és igual d’important, ja que en qualsevol preferència que l’usuari hagi desat a la versió anterior s’hauria de conservar quan actualitzés l’aplicació.

Per exemple , és possible que un usuari hagi desat les dades de la seva targeta bancària en aplicacions com PayTm, etc.

És possible que el sistema operatiu del dispositiu no admeti l'aplicació

Sona interessant?

Sí, és possible que molts dispositius no admetin la vostra aplicació. Molts de vosaltres heu de saber que els proveïdors escriuen els seus propis embolcalls a la part superior dels Estats Units i és possible que qualsevol consulta SQL de la vostra aplicació no sigui compatible amb el dispositiu i, per tant, produeixi una excepció i pot resultar que ni tan sols iniciï la aplicació en aquest telèfon.

El punt aquí és: Intenteu fer servir la vostra aplicació als vostres propis dispositius, tret dels que utilitzeu a l'oficina. És molt possible que vegeu alguns problemes amb la vostra aplicació.

Proves de permisos d'aplicacions

El següent de la llista és Prova de permisos d'aplicacions mòbils . Gairebé cada segona aplicació demana als usuaris accés al contacte, a la càmera, a la galeria, a la ubicació del telèfon, etc. He vist pocs verificadors que cometen un error en no provar les combinacions adequades d’aquests permisos.

Puc recordar una en temps real Exemple quan provàvem una aplicació de xat que tenia totes les funcions per compartir imatges i fitxers d'àudio. El permís per emmagatzemar es va establir a NO.

Ara, quan un usuari faci clic a l'opció Càmera, mai no s'ha obert fins que el permís d'emmagatzematge no s'estableix en SÍ. L'escenari es va ignorar, ja que Android Marshmallow tenia aquesta funcionalitat que, si el permís d'emmagatzematge s'estableix en NO, la càmera no es pot utilitzar per a aquesta aplicació.

L’abast s’estén més enllà del que hem comentat al paràgraf anterior. Hem d’assegurar-nos que l’aplicació no sol·licita cap permís que no s’utilitzi.

Qualsevol usuari final familiaritzat amb la indústria del programari pot no descarregar l’aplicació en la qual es demanen massa permisos. Si heu eliminat alguna funció de la vostra aplicació, assegureu-vos d’eliminar la pantalla de permisos per a la mateixa.

convertir char en int c ++

Compareu amb aplicacions similars i populars del mercat

Moralitat de la història - Si teniu algun dubte, no ho conclogueu vosaltres mateixos. En comparar amb la resta d’aplicacions similars de la mateixa plataforma, podeu reforçar el vostre argument que diu que la funcionalitat sotmesa a prova funcionarà o no.

Obteniu una visió general del criteri de rebuig de compilació d'Apple

Per últim, és possible que la majoria de vosaltres us hàgiu trobat amb situacions en què Apple ha rebutjat les vostres versions. Sé que aquest tema no interessarà a la major part dels lectors, però sempre és bo conèixer les polítiques de rebuig d’Apple.

Com a provador, ens resulta difícil atendre els aspectes tècnics, però, tot i així, hi ha algun criteri de rebuig que els verificadors poden tenir en compte.

Per obtenir més informació, feu clic a aquí.

Estigueu sempre al peu davanter

Com a provador, no deixeu que les coses passin a la vostra pista per part de l'equip o gestors de desenvolupament. Si ets un apassionat de les proves, llavors 'Sigueu sempre al davant' . Intenteu participar en activitats que tenen lloc molt abans que el codi arribi al vostre dipòsit per provar-ho.

El més important és que continueu examinant JIRA, QC, MTM o el que s’utilitzi al vostre projecte per obtenir les últimes actualitzacions de bitllets dels clients i de Business Analyst. A més, estigueu preparat per compartir les vostres opinions si necessiteu modificacions. Això s'aplica a tots els verificadors que treballen en diversos dominis i plataformes.

Fins que i si no sentim el producte com a propi, mai no hauríem de donar suggeriments per a noves millores o canvis en la funcionalitat existent.

Mantingueu l'aplicació en segon pla durant molt de temps (12-24 hores)

Sé que sona estrany, però hi ha molta lògica entre bastidors que tots no entenem.

Ho comparteixo perquè he vist que l'aplicació es bloqueja després de llançar-la, per exemple, al cap d'unes 14 hores des de l'estat de fons. La raó pot ser qualsevol cosa en funció de com ho hagin codificat els desenvolupadors.

Permeteu-me compartir un exemple en temps real:

En el meu cas, la caducitat del testimoni va ser la causa. Per a una de les aplicacions de xat, si es llança després de les 12 i les 14 hores, es quedaria enganxada al bàner de connexió i mai no es connectaria fins que no es matés i es rellançés. Aquest tipus de coses són molt difícils d’atrapar i, en certa manera, fan que les proves mòbils siguin més difícils i creatives.

Proves de rendiment de la vostra aplicació

Al món mòbil, el rendiment de la vostra aplicació afecta la mesura en què la vostra aplicació és reconeguda a tot el món. Com a equip de proves, és massa important comprovar la resposta de l'aplicació i, sobretot, com funciona quan un gran nombre d'usuaris l'utilitzen junts.

Exemple:

Parlem de PayTm.

Tots heu d'haver fet clic a l'opció AFEGEIX DINERS a l'aplicació PayTm, que mostra el saldo que teniu a la cartera. Si tenim en compte què passa entre bastidors, és una sol·licitud que s’està enviant al servidor amb l’identificador d’usuari PayTm i el servidor us retorna la resposta amb el saldo del vostre compte.

Exemple

El cas anterior només és quan un usuari ha colpejat el servidor. Hem d’assegurar-nos que, fins i tot quan 1.000 usuaris arriben al servidor, haurien de recuperar la resposta a temps perquè la usabilitat de l’usuari final és el nostre objectiu principal.

Conclusió

Conclouria aquest tutorial repetint que les proves mòbils semblen ser molt fàcils al principi, però, a mesura que continueu aprofundint, comprendreu que no és fàcil assegurar-vos que qualsevol cosa desenvolupada funcioni sense problemes en milers de dispositius de tot el món. .

Veuríeu principalment les aplicacions que només són compatibles amb les darreres i darreres versions del sistema operatiu. Tanmateix, es converteix en el deure dels verificadors assegurar-se que no perden cap escenari. Són molts altres punts que cal tenir en compte, però no he esmentat els que ja estan iterats a la resta de tutorials.

Escenaris com el consum de bateria, proves d’interrupcions, proves en diferents xarxes (3G, Wi-Fi), proves mentre canvieu de xarxa, proves de mico d’aplicacions mòbils, etc., són útils quan es tracta de proves mòbils.

L’actitud dels verificadors importa molt quan es tracta de l’entorn real de proves. Fins que i si no us agrada la vostra feina, no us molestareu a fer les coses que s’esmenten al tutorial.

He estat en aquest camp des de fa uns 6 anys i sé molt bé que de vegades les tasques són monòtones, però hi ha moltes altres coses que podem fer per nosaltres mateixos per fer que aquestes tasques monòtones siguin una mica interessants.

Dissenyar l’estratègia de prova adequada, escollir els simuladors, dispositius i eines de proves mòbils adequats pot assegurar-nos que disposem d’un 100% de cobertura de proves i ens ajudi a incloure proves basades en seguretat, usabilitat, rendiment, funcionalitat i compatibilitat a les nostres proves.

Bé, aquest ha estat el nostre esforç per satisfer múltiples peticions dels nostres lectors en una guia de proves d'aplicacions mòbils.

Autors : Gràcies a Swapna, Hasnet i molts altres experts en proves mòbils per ajudar-nos a compilar aquesta sèrie.

En el nostre proper article, en parlarem més sobre Prova d'aplicacions per a iOS .