Tutorial de proves de la interfície d'usuari mòbil (proves GUI d'aplicacions per a iOS i Android)

mobile ui testing tutorial gui testing ios

Guia de proves de la interfície d’usuari de l’aplicació mòbil: obteniu informació sobre com realitzar proves de la interfície d’usuari per a iOS i Android

Amb el florent mercat dels mòbils, les proves d'aplicacions mòbils s'han convertit en emocionants dia a dia.

com escriure scripts de prova d'automatització

Només amb l'execució de proves funcionals en una aplicació mòbil, no podeu tancar l'aplicació. Hi ha pocs tipus de proves com ara proves de camp, proves de xarxa, proves d’interfície d’usuari, proves de durada de la bateria, etc., que cal fer.

Les proves d’interfície d’usuari són una de les proves importants en les proves d’aplicacions mòbils i no s’han de prendre a la lleugera.

La interfície gràfica d'usuari crea una gran diferència en la forma d'interessant i interactiva que troba un usuari per a la vostra aplicació. La importància d’una interfície gràfica d’usuari decent i atractiva es pot sentir de manera més significativa en un entorn de dispositiu intel·ligent on la mida de la pantalla és molt menor en comparació amb la pantalla d’un ordinador portàtil o d’escriptori.

Què aprendreu:

• Importància de les proves d’interfície d’usuari de les aplicacions mòbils
• Com decidir quant es requereixen proves d’interfície d’usuari?
• Directrius: què cal provar a la prova de la interfície d’usuari de l’aplicació mòbil
  • # 1) Resolució de pantalla
  • # 2) Mida de la pantalla
  • # 3) Diferents elements de la IU
  • # 4) Estil: esquema de colors i temes del dispositiu
  • # 5) Tacte múltiple o senzill
  • # 6) Premsa llarga o curta
  • # 7) Ubicació
• Com provar les variacions de la interfície d’usuari en diferents versions del sistema operatiu?
• Dispositius o emuladors reals: què escollir per provar la interfície d'usuari?
  • Pros
  • Contres
• Proves d’interfície d’usuari manuals o automatitzades?
• Eines de prova de la IU de l'aplicació mòbil
• Llista de comprovació per provar la interfície d'usuari de l'aplicació mòbil
• 5 mites sobre les proves automatitzades d’interfície d’usuari per a mòbils
  • Mite 1: la velocitat
  • Mite 2: Cobertura
  • Mite 3: Cost
  • Mite 4: coherència
  • Mite 5: reticències
• El mite i la realitat
• Conclusió
• Lectura recomanada

Importància de les proves d’interfície d’usuari de les aplicacions mòbils

Com a usuari, tindrà ganes d’utilitzar una aplicació que no tingui interacció amb l’usuari i que faci difícil entendre com utilitzar-la?

Quan els usuaris utilitzen una aplicació mòbil per primera vegada, no només el rendiment roba l’atenció, sinó també la atractiva interfície d’usuari. Una aplicació compatible amb la interfície d’usuari es ven més en comparació amb una aplicació millor desenvolupada però amb una interfície d’usuari desagradable.

Si una aplicació té una interfície d’usuari perfecta i esplèndida en un dispositiu, però en l’altre dispositiu està completament retorçada només perquè té una mida diferent o un sistema operatiu diferent, deixarà molt mala impressió. L'èxit comercial de l'aplicació es veurà molt afectat.

Promocionareu una aplicació en què el botó sigui massa petit per fer clic i bloquegi tot el conjunt de funcions?

No són aquestes experiències desagradables per als usuaris? A causa dels casos esmentats, es fa molt important provar la interfície d’usuari d’una aplicació. Les dues principals verificacions que cal fer per a aplicacions mòbils són la facilitat d’ús i l’aspecte dels diferents models i versions del sistema operatiu.

A continuació es mostra un exemple de com la IU hauria de ser perfecta en diferents mides de pantalla:

Com decidir quant es requereixen proves d’interfície d’usuari?

El gràfic següent indica les diverses verticals en què es poden classificar les aplicacions per a mòbils:

(imatge font )

A la gràfica anterior, es pot veure que les aplicacions de jocs ocupen la major part de la quota de mercat del 24,43% aproximadament i, seguidament, les aplicacions empresarials i educatives.

• Les aplicacions desenvolupades com a aplicacions de jocs necessiten proves exhaustives en tots els aspectes, ja que la interfície d’usuari és el que més contribueix a obtenir èxit, independentment de si es tracta d’una aplicació nativa o híbrida.
• És possible que una aplicació empresarial no confiï completament en la IU perquè tingui èxit perquè, en la majoria dels casos, el públic objectiu està format per utilitzar-la. Per tant, aquestes aplicacions poden tenir una interfície d’usuari senzilla.
• Les aplicacions desenvolupades amb finalitats educatives necessiten proves d’interfície d’usuari exhaustives.
• Les aplicacions comercials com ara compres, viatges, etc. també necessiten proves d’interfície d’usuari completes en diversos dispositius i diverses versions del sistema operatiu.

En resum, segons el propòsit de l’aplicació, es pot decidir la profunditat de les proves d’interfície d’usuari, però les proves d’interfície d’usuari sempre s’han de fer en almenys 3 versions del sistema operatiu diferents.

Directrius: què cal provar a la prova de la interfície d’usuari de l’aplicació mòbil

Mentre es prova la IU en una aplicació mòbil, cal verificar diverses característiques.

A continuació es mostren algunes de les característiques que s’han de provar per a cada aplicació:

# 1) Resolució de la pantalla

A continuació, es mostren algunes de les resolucions de pantalla habituals que es tenen en compte en crear testbeds:

• 640 × 480
• 800 × 600
• 1024 × 768
• 1280 × 800
• 1366 × 768
• 1400 × 900
• 1680 × 1050

Totes aquestes resolucions són imprescindibles per provar quan teniu un disseny de diverses columnes a la vostra aplicació.

Per tant, cal fer la verificació començant des de la resolució més petita fins a la més gran. A part d’això, si la vostra aplicació té una llarga llista de targetes amb informació, també cal provar-les amb una resolució diferent per a l’ajust de la informació.

( font de la imatge )

# 2) Mida de la pantalla

Hi ha massa variacions en les mides de pantalla i en les resolucions disponibles. Especialment en dispositius intel·ligents, les mides dels controls no són estàtiques, sinó que tenen relació amb la mida de pantalla disponible.

Durant les proves, assegureu-vos que la mida dels controls sigui estèticament bona i que el control sigui completament visible a la pantalla sense cap desplaçament. Proveu la interfície gràfica d’usuari en diferents dispositius amb mides i resolucions de pantalla diferents.

Els emuladors són bons per a aquest propòsit, però res coincideix amb el dispositiu real. Assegureu-vos, doncs, que proveu en almenys dos o tres dispositius reals. A més, no oblideu provar orientacions horitzontals i verticals si el dispositiu ho admet.

Heu de provar l'aplicació amb resolucions d'ús habitual per assegurar-ne la usabilitat.

Poques coses que heu d’entendre aquí són:

La diferència entre la mida i la resolució de la pantalla: La mida de la pantalla és la longitud de la pantalla en polzades mesurada en diagonal o d’un cantó a un altre cantó de la pantalla. La resolució de la pantalla és l’amplada i l’alçada, Exemple 640w × 480h que representa el nombre de píxels que travessen la pantalla multiplicat per diversos píxels que baixen.

# 3) Diferents elements de la IU

Els elements de la IU, com ara botons, encapçalaments, icones, imatges, camps de selecció, camps de text, caselles de selecció, etc., són alguns dels diferents elements que cal verificar per la seva aparença i mida a la pantalla.

Específicament per als camps de text, si el teclat suau apareix al tocar en el camp de text, s'ha de provar i verificar.

El més important és que es facin proves exhaustives de les mides dels botons perquè recordo que a la nostra aplicació mentre provàvem amb el telèfon Galaxy S, vam trobar un bloqueig on un botó havia bloquejat tota l’aplicació només perquè el botó semblava massa petit per fer-hi clic.

La posició dels elements de la interfície d’usuari també s’hauria de verificar en funció del requisit, és a dir, si s’han d’alinear al centre o a l’esquerra, etc.

# 4) Estil: esquema de colors i temes del dispositiu

La interfície d’usuari i l’esquema de colors de l’aplicació haurien de ser coherents amb els diferents colors i esquemes temàtics del telèfon. El color i el tema d’un telèfon Samsung són molt diferents del de Nokia o del telèfon MI .

Per tant, heu de verificar si l’aplicació és coherent en aquests telèfons.

La vostra aplicació té un disseny específic. I l'estil dels controls ha de coincidir amb aquest disseny. És possible que hàgiu vist moltes aplicacions en què alguns controls, p. els panells tenen vores rodones i altres controls, p. els quadres de text tenen vores esmolades.

Tot i que aquest tipus de problemes no afecten la usabilitat ni la funcionalitat de l’aplicació, tot i que un aspecte coherent de l’aplicació ajuda a establir una relació amigable entre l’aplicació i l’usuari.

Una de les coses més importants de l’estil és el tipus de lletra de les diferents pàgines. El tipus de lletra s'ha de provar bé per evitar incoherències en l'aparença de l'aplicació.

La majoria de les vegades ens centrem en el text que és visible en situacions normals i ignorem el text que apareix en situacions específiques. Els missatges d’èxit i d’error són un exemple d’aquest tipus de text.

Un altre factor que té un estil important és la relació entre el color de la font i la situació en què es mostra el text.

Per exemple, El color vermell s’utilitza per als missatges d’error, el verd per tenir èxit, el groc per als avisos i el blau per als enllaços.

# 5) Tacte múltiple o senzill

Si la vostra aplicació admet la funció multitàctil, com pessigar per fer zoom o pessigar per reduir, etc., haureu de provar a fons aquesta funció i crear-ne molts casos per a totes les pantalles aplicables.

# 6) Premsa llarga o curta

Si premeu molt de temps sobre una icona es mostra el menú contextual mentre un toc curt realitza la primera acció del menú. Si aquesta funció es proporciona a la vostra aplicació, haureu de verificar aquesta funcionalitat i totes les funcions que l’envolten.

# 7) Ubicació

Ubicació i posició són les dues paraules que s’utilitzen alternativament i, curiosament, s’utilitzen per transmetre dos conceptes diferents que s’expliquen a continuació:

1) De vegades és la zona de la pantalla on apareix un control.

Per exemple, La capçalera es troba a superior de la pàgina, les etiquetes són Esquerra alineada , i les caixes de text ho són Alineat a la dreta, etc. Aquí, 'superior', 'alineat a l'esquerra' i 'alineat a la dreta' són posicions relatives dels controls.

2) De vegades és l'ordre de control entre els altres controls.

Per exemple, mentre obteniu informació personal, el nom és seguit pel cognom. O bé, el format dels controls per sol·licitar una adreça dels Estats Units hauria de ser el mateix ordre - ZIP, ciutat, estat.

En ambdues situacions, estem parlant de la ubicació dels controls.

Mentre proveu la localització i la posició dels controls, assegureu-vos que tot està col·locat lògicament a la pantalla i que mostra un bon sentit estètic.

Hi ha situacions en què apareixen un o més controls a més d'una pantalla. En aquesta situació, heu d'assegurar-vos que apareguin a la mateixa ubicació i al mateix ordre relatiu a totes les pàgines.

Com provar les variacions de la interfície d’usuari en diferents versions del sistema operatiu?

La interfície d’usuari varia amb la versió del sistema operatiu i, amb el llançament d’una nova versió, es realitzen millores a la interfície d’usuari.

Observem la interfície d’usuari dels 3 darrers sistemes operatius disponibles actualment i comprenem com aquestes variacions afecten una aplicació mòbil.

Ells són:

1. Piruleta
2. Malví
3. Torró

Veient la llista anterior de noves funcions d’interfície d’usuari o de funcionalitat, com a control de qualitat, heu de dissenyar casos de prova al voltant d’això.

1) Piruleta:

• Creeu casos de prova per a l’efecte del nou disseny a la vostra aplicació.
• No necessàriament per a totes les pantalles, sinó que creeu casos de prova per accedir a les dreceres noves de la vostra aplicació.

2) Malví:

• Si la vostra aplicació tracta els emojis, creeu casos de prova per verificar els nous emojis. Les aplicacions que permeten als usuaris escriure ressenyes o xatejar són les que fan servir emojis amb freqüència.
• Quan la vostra aplicació es publiqui i s’instal·li per primera vegada, és possible que hagueu de demanar permís, de manera que cal fer la prova d’interfície d’usuari de la nova pantalla de permisos. I creeu casos de prova per al mateix.
• Si l'aplicació utilitza Google Now, heu de crear casos de prova per provar la interfície d'usuari de la funció de Google Now actualitzada.

3) Torró:

• Cal fer proves exhaustives de la vostra aplicació per al mode de realitat de somni despert i, per tant, crear casos de prova en conseqüència.
• Creeu casos de prova per verificar les opcions de menú de la vostra aplicació.
• Si la vostra aplicació tracta emojis i GIF, creeu casos de prova per verificar els nous emojis i l'opció d'enviar GIF.

Dispositius o emuladors reals: què escollir per provar la interfície d'usuari?

Quan haureu de provar una aplicació mòbil, podríeu pensar quin ha de ser el banc de proves?

Ja sigui per provar en un dispositiu o emulador real o tots dos? No hi ha cap resposta ferma perquè l'elecció depèn del que vulgueu provar.

Per provar la funcionalitat, el rendiment, la resposta de la xarxa, la prova de camp, etc., sempre heu de preferir un dispositiu real. Però per a coses com la interfície d’usuari, heu de triar emuladors juntament amb alguns dispositius reals.

Pros

Els avantatges de l’ús d’emuladors per a proves d’interfície d’usuari són:

1) No és pràcticament possible recollir els dispositius de totes les resolucions i això també costaria una enorme quantitat de diners. Però els emuladors no costen res.
2) Amb un emulador, podeu crear totes les combinacions de resolució de pantalla i SO.
3) Si només teniu un conjunt de dispositius reals, però l’equip de control de qualitat és de més d’una persona, tots els controladors de qualitat no poden provar el mateix banc de proves en paral·lel. Amb un emulador, cada control de qualitat pot crear la mateixa combinació a la seva màquina i provar-lo en paral·lel.
4) Les proves en un emulador consumeixen menys temps i són més ràpides en comparació amb un dispositiu real.
5) Els errors habituals relacionats amb la interfície d’usuari, com l’alineació, etc., es poden detectar fàcilment als emuladors.

Contres

Els inconvenients inclouen:

1) Els gestos no es poden provar en emuladors. Només es pot emular un gest alhora.
2) Tampoc no es poden provar les entrades físiques del GPS, de la xarxa que cau o de la xarxa feble, etc.
3) No hi ha manera de crear un emulador per a telèfons Sony, LG, Nexus, etc.
4) No és possible crear un entorn real amb poca bateria o poca memòria, etc., a l’emulador.

Per tant, la decisió s’ha de prendre en funció de la vostra aplicació i dels requisits de prova.

Proves d’interfície d’usuari manuals o automatitzades?

Cap producte, ja sigui una aplicació d'escriptori, una aplicació web o una aplicació mòbil, no es pot publicar sense fer proves. Com a control de qualitat, lluitem per trobar i informar de tots els defectes, però els clients els informen.

Saps per què?

Perquè proves llargues que sovint s’eviten o es perden deixant així errors no detectats. Tampoc no es pot fer una cobertura del 100% i no es pot executar en profunditat amb les proves manuals.

Les proves d’interfície d’usuari són força senzilles i senzilles i només heu de mirar com us apareix. Ara, si es fa manualment, requereix molt de temps. A més, la majoria de les vegades que necessitem crear dades enormes per provar la interfície d’usuari, com ara un desplaçament, només apareixeran si les files de cartes creuen un recompte concret.

Crear big data requereix molt de temps. Disposar d’una suite automatitzada pot resoldre tots dos problemes.

Per contra, si les funcionalitats o la interfície d’usuari de l’aplicació encara estan canviant, no té sentit invertir en automatització. De la mateixa manera, si les funcions de l’aplicació són vitals, és millor provar-les manualment.

Per tant, segons els indicadors següents, heu de decidir si voleu provar manualment o automatitzar:

• La naturalesa de la vostra aplicació.
• L'estabilitat de la vostra aplicació.
• Els recursos disponibles com la mà d'obra per estudiar les eines i comparar-les.
• Quant de temps s’inverteix en estudi i ampliació d’una eina d’automatització que es requereix?
• El client està preparat per invertir temps en la recuperació i l'estudi?

Eines de prova de la IU de l'aplicació mòbil

A continuació es mostra una llista de cinc eines que es poden utilitzar per provar la interfície d’usuari d’una aplicació mòbil per a Android i / o iOS.

(Per a eines de prova de funcionalitat y Podeu consultar la llista d'eines d'automatització del nostre automatisme eines per provar aplicacions d'Android pàgina).

# 1) Selendroid

Selendroid és una de les millors eines més recomanades per a l’automatització d’aplicacions mòbils per a proves d’interfície d’usuari.

Es pot utilitzar tant per a aplicacions natives com híbrides. Es pot utilitzar només per a aplicacions d'Android i les proves de l'API del client s'escriuen amb Selendroid 2. També es pot utilitzar amb més d'un dispositiu i és totalment compatible amb JSON.

# 2) Testdroid

Aquesta és una eina basada en el núvol i es pot utilitzar per a diversos dispositius, diferents resolucions de pantalla i versions de SO tant d'Android com d'iOS. La prova de dispositius paral·lels és un gran avantatge d’aquesta eina i és una bona eina per provar la interfície d’usuari. Ajuda els desenvolupadors a millorar el temps de comercialització.

# 3) VeureTest

obertura de fitxers .jar de Windows 10

És una eina de pagament i es pot utilitzar per a Android, iOS, Windows, Symbian, etc.

És una eina multiplataforma i, per tant, l’avantatge és que es pot executar la mateixa prova en totes les plataformes. Es pot utilitzar per a totes les aplicacions mòbils i les proves es poden executar en paral·lel en més d’un dispositiu.

# 4) Automatització de la IU

Aquesta és l'eina oficial de proves de la interfície d'usuari d'Apple i és la millor eina per automatitzar les aplicacions iOS. Tot i que és difícil d’aprendre, ofereix un gran avantatge amb biblioteques, rendiment, proves d’interfície d’usuari, etc.

# 5) Calabassa

Es pot utilitzar tant per a proves Android com per a iOS per a aplicacions natives o híbrides. És una eina multiplataforma i s’utilitza millor per automatitzar gestos, captures de pantalla, afirmacions, etc. Es pot utilitzar en dispositius de pantalla tàctil reals. També té suport per al cogombre.

Quan els desenvolupadors proven l'aplicació per unitats, també poden fer proves d'interfície d'usuari mitjançant Android Studio, però només es pot utilitzar per a aplicacions d'Android.

Lectura recomanada => Automatitzeu les proves de la interfície d'usuari

Llista de comprovació per provar la interfície d'usuari de l'aplicació mòbil

A continuació es mostra la llista de comprovació dels verificadors per assegurar-se que la GUI es prova completament bé en dispositius intel·ligents:

5 mites sobre les proves automatitzades d’interfície d’usuari per a mòbils

La prova automàtica d’interfície d’usuari mòbil es considera molt crucial quan es planteja la qüestió de l’èxit de l’aplicació. Però hi ha alguns mites relacionats amb les proves automatitzades.

Aquests mites poden no ser certs perquè poden ser superficials. Aprofundir en el procés de proves automatitzades fa que desaparegui. Aprofundim-hi.

Mite 1: la velocitat

Aquest mite és molt comú. La majoria de les persones relacionades amb les indústries de TI tenen el mite que la realització de 'proves d'automatització' requereix més temps en comparació amb les 'proves manuals'. Aquest fet és cert fins a cert punt en alguns escenaris.

El motiu és que les proves manuals produeixen resultats ràpids en comparació amb les proves automatitzades d’interfície d’usuari per a mòbils. Però aquest és el cas només en les fases preliminar i inicial.

Amb proves de tipus repetit, cal afegir moltes més funcions de prova o disminuir les qualitats de les proves. Mentre que amb les proves automàtiques, sempre executeu nivells de proves similars cada cop, cosa que permet estalviar temps a la llarga.

Mite 2: Cobertura

En l’escenari actual, els nous dispositius Android es publiquen regularment als mercats. I el nombre d'aplicacions d'aquests sistemes operatius (SO) està augmentant. A més, hi ha sistemes operatius com iOS que tenen encara més aplicacions pensades per a l’ús diari.

Les proves manuals de tantes aplicacions es fan molt difícils. Però en els casos de proves automàtiques n’hi haurà prou amb el manteniment dels servidors en el núvol. Amb l'ajut de proves automàtiques, és possible una cobertura total i completa de les aplicacions.

Mite 3: Cost

És cert que la prova automatitzada de les aplicacions costa més en comparació amb els costos de la prova manual. Tanmateix, això només és cert si s’estan fent proves dels elements bàsics de l’aplicació. A mesura que l'entorn de l'aplicació i el programari es compliquen, les proves manuals són més costoses.

Això es deu al fet que es necessiten eines més sofisticades per obtenir uns resultats òptims de les proves. Juntament amb aquestes sofisticades eines de prova, hi ha una necessitat de personal altament capacitat que pugui gestionar aquestes eines. Per a això caldrà formar-los.

Per tant, les proves manuals esdevenen més costoses en comparació amb una de automatitzada.

Mite 4: coherència

En el cas de les proves manuals, sempre hi ha espai per a percepcions diferents que varien d’un provador a un altre. Això també depèn de les proves considerades, dels entorns i de les aplicacions juntament amb el sistema operatiu (SO).

Quan apliqueu proves manuals al programari, hi ha forats pels quals podrien passar pocs errors. Per tant, les proves manuals només són bones per detectar errors bàsics. Les proves automatitzades s’executen als scripts sense cap marge per a la percepció variable, cosa que fa que sigui infal·lible.

classificació de l’arbre de decisions en l’explotació de dades

Mite 5: reticències

No és cert que les proves automàtiques hagin reemplaçat els éssers humans, sinó per millorar-ne el provador manual. Les proves automatitzades proporcionen resultats automatitzats repetidament, diverses vegades amb la màxima precisió. Per tant, sorgeix la consulta, per què hi ha necessitat d’éssers humans?

Les proves automatitzades necessiten escriptura de guions i tota la planificació del procediment de proves. Aquesta tasca requereix un esforç humà. El procediment de proves automàtiques ajuda a estalviar temps i diners de manera que utilitzeu aquests recursos per millorar els procediments de proves manuals. El desenvolupament de millors eines al seu torn ajudarà a avançar en els procediments de proves automatitzades ja existents.

S’han esmentat alguns dels mites més populars existents en la indústria de les proves automatitzades. Cal eradicar-ho per millorar les proves automàtiques d’interfície d’usuari mòbil.

El mite i la realitat

El fet és que fins i tot les empreses de desenvolupament més sofisticades utilitzen proves manuals per a mòbils o no realitzen proves completes. Segons les enquestes de Xamarin de 2014, el 13,2% dels desenvolupadors de mòbils realitzen proves de la IU automatitzada. Segons els estudis de Forrester Research, només el 53% dels desenvolupadors realitzen proves superficials en dispositius individuals.

Els cinc factors més habituals per què els equips de mòbils no han automatitzat les qualitats de les aplicacions per a mòbils i cinc motius pels quals aquestes no només tenen un sentit real són els següents:

a) La velocitat és el primer mite.

Una persona no pot trigar l’automatització. L’any 2014, els proveïdors havien introduït 7.000 nous tipus de dispositius Android. Després hi va haver 10.000 API específiques per a mòbils. L'aplicació dels mòbils s'envia més ràpidament i es modifica ràpidament. Amb l'assegurament de la qualitat (QA) en modes de restricció constant, no hi ha temps per crear scripts de prova, al seu torn, mantenint-los sincronitzats amb funcions que canvien regularment.

L’escenari pràctic del primer mite:

Actualment es perd un temps preciós. És molt cert. Provar manualment és més ràpid que provar per automatització. Però això és per a la primera prova. En les proves posteriors, qualsevol benefici marginal que aporti la prova manual provoca erosions. Això és gairebé immediat. Juntament amb totes les proves repetides o addicions de funcions, els desenvolupadors d'aplicacions haurien de reduir l'abast de la prova o els recursos de prova addicionals.

Juntament amb un pressupost finit, això condueix en última instància als cicles viciosos de les qualitats que disminueixen. Com a resposta als compromisos de dades i a les ressenyes negatives dels usuaris de dispositius que no s’han provat, els equips desitgen una ampliació de la cobertura del dispositiu. Això augmenta encara més l'estrès dels departaments de control de qualitat ja com a capacitats.

És que el negoci lluita per mantenir, investigar i adquirir dispositius mentre realitza proves d’execució. Fins i tot els programes manuals de proves d’interfície d’usuari millor finançats es redueixen cap a la cobertura completa.

Als Estats Units, els equips de mòbils requereixen proves en 188 dispositius per cobrir el 100% de les accions de màrqueting. Segons la investigació de Xamarin del 2014, la majoria dels equips de desenvolupament fan proves amb freqüència en 25 o menys dispositius.

Més d’una quarta part d’aquestes comunitats de desenvolupadors s’orienten a cinc o menys dispositius. En situacions reals de proves, l’automatització paga gairebé de manera instantània i immediata. En la primera prova de proves, es constata que els consumidors acceleren quatre vegades els terminis de proves. Es tracta de proves manuals senceres quan es corre contra cinquanta o dispositius més que això.

Les curses que estan en la seqüència posteriors han estat molt més ràpides. Tot i això, hi ha escurçament durant una setmana de proves gairebé completa fins a usos de poques hores.

b) La cobertura és el segon mite.

La fragmentació és la causa que no hi hagi cap possibilitat d’ampliar la cobertura del dispositiu. Juntament amb més de 19.000 dispositius Android únics i permutació de dotzenes per formar sistemes operatius i factors per a iOS, molts equips creuen que no és possible cobrir la majoria de dispositius en els mercats proporcionats.

Per tant, hi ha una prova predeterminada en un grapat d’aquests dispositius que és prou bona.

La realitat del segon mite:

Es podria haver completat la cobertura del dispositiu. En cas que la gent mantingui dispositius interns en grapat, ho estan fent molt. L’adquisició de dispositius és difícil.

Mantenir els seus diners, costos i temps, al seu torn, fer que els provadors tinguin disponibilitat quan i quan se senti la seva necessitat crea logjams logístics. Gartner havia afirmat que els desenvolupadors de mòbils haurien de trobar maneres d’aconseguir taxes d’automatització elevades per mantenir-se al dia amb el ritme i la difusió del canvi de la plataforma. Això havia estat en allotjament. Les diferents funcions van utilitzar la gestió interna.

El camí cap a aquesta automatització és a través dels serveis al núvol de tercers. Els serveis de núvol de tercers ajuden a l’automatització dels processos de càrrega d’aplicacions, a l’execució de scripts de prova, als informes de resultats i a restablir de forma segura les còpies de seguretat de dispositius per als estàndards de les fàbriques. Els subconjunts de proves d'aplicacions s'executen en paral·lel i, per tant, acceleren els resultats.

Tot i provar en una àmplia gamma de dispositius reals, els núvols de prova permeten que tots els equips puguin saber amb precisió com funciona l'aplicació, al seu torn, eliminant les suposicions típiques dels desenvolupaments mòbils.

Exemple: Els administradors de productes estableixen menys requisits del sistema juntament amb confidències que es justifiquen en el rendiment dels dispositius. Els desenvolupadors reben confirmacions objectives visuals de la correcció d’errors abans del compromís de les versions més recents. Això és independentment d'on i quan operin.

c) El cost és el tercer mite.

Les persones només es poden permetre les proves manuals. Les proves d'automatització necessiten la creació de scripts de prova, corbes d'aprenentatge per al personal de control de qualitat i infraestructura. Molts equips han lluitat ja per complir els terminis. Ja han superat el pressupost. Per tant, les proves d'automatització semblen estar a gran distància.

L’escenari pràctic del tercer mite:

Les proves manuals només estalvien diners en cas que la gent sacrifiqui cobertures. Les proves manualment semblen menys costoses només a la majoria d’entorns amb ossos nus.

En cas que les proves incloguin una 'comprovació ràpida' de les funcionalitats bàsiques de menys dispositius, les proves manuals semblen ofertes. Però qualsevol semblança amb la cobertura de proves i el dispositiu que sigui complet farà que les proves manualment siguin molt més costoses que les proves d'automatització. Això pot ser ràpid fins i tot.

Les proves manuals només s’escalen afegint més persones i masses. Els costos no tenen una veritable linealitat. L’ampliació del personal per satisfer les demandes comporta enormes despeses generals en formes de coordinació i formació. La divisió de casos de prova redueix, per tant, l’eficiència de tots els verificadors mitjançant l’eliminació de perspectives.

A més, els provadors que tinguin prou sofisticació per aprofundir en els comportaments dels usuaris, explorant i anticipant els motius pels quals poden fallar les aplicacions, no poden ser ni abundants ni econòmics. Les proves d'automatització sempre requereixen una mica més de despeses generals en el moment de la configuració inicial.

Però, com s’ha dit anteriorment, pot produir guanys i beneficis de manera espectacular en les velocitats de prova. També produeix la reducció de personal corresponent en un parell de dies. Els entorns de prova basats en el núvol han reduït encara més els costos. Això passa per l’eliminació de la infraestructura de proves locals premisses i poc utilitzades.

d) La coherència serà el quart mite.

Cal dur, executar i operar prou bé. Per a diferents equips de proves, els desplegaments preparats són decisions subjectives basades en les percepcions de molts provadors manuals variats. Saben que el significat és que els insectes cauen a través d’esquerdes.

Les cobertures de proves superposades han de detectar els problemes més habituals i crítics abans de les versions. La resta d'errors esperen versions de manteniment.

L’escenari real del quart mite:

Les qualitats no són qualitatives. La preparació de les produccions no ha de ser un factor i una qüestió d’opinió. En un entorn pur de proves manuals, les percepcions varien d’una prova a una altra i d’un provador a un altre. Això condueix a resultats erràtics de proves i documentacions poc coherents.

Les decisions es compliquen quan hi ha consideracions sobre la preparació dels productes. Condueix a fracassos de compliments, desencant de masses i pèrdua d’ingressos. A més, hi ha la creació de butxaques d’enteniments tribals no capturats que es perden quan la gent i els empleats surten de la porta.

L’automatització, al seu torn, crea mètriques quantificables. Això serveix com a fonts objectives de la veritat per informar de decisions sobre la justificació de la decisió empresarial, la preparació del producte i el progrés dels equips gràfics.

e) La reticència és el cinquè mite.

Les proves manuals s'han substituït per proves d'automatització. Molts desenvolupadors diferents poden accedir a l’automatització de proves perquè esperen substituir els provadors manuals per màquines.

En el cas que l’automatització de les proves repeteixi proves similars 1000 vegades amb una precisió del 100%, es plantegen preguntes sobre el motiu pel qual hi ha necessitats dels humans a efectes de proves. Les màquines també poden automatitzar els scripts de prova.

La imatge en temps real del cinquè mite:

Els provadors manuals són millors amb les proves d’automatització. Les màquines i els éssers humans posseeixen bons escenaris de moltes coses i factors diversos. Els provadors, que fan proves manuals, sempre poden provar de manera més creativa.

Les proves d'automatització els alliberen de fer-ho. Tot i que els humans esperem amb interès noves maneres de trencar aplicacions, l’automatització garanteix el compliment de l’àmplia gamma de dispositius. Això va des de les proves d’unitat fins a les proves de regressió completes. No cal que 2 enfocaments es desenvolupin de forma aïllada.

Per realitzar proves, és un manual exploratori, mentre que els sistemes posteriors no han estat sotmesos a càrregues provades de proves automatitzades. Són maneres excel·lents de descobrir errors que apareixen en entorns de produccions. Les proves d'automatització no substitueixen els verificadors que són humans. Això els permet dur a terme treballs gratificants i interessants.

Una millor consistència, cobertura, cost i velocitat se sumen a les qualitats millorades. Estalviar diners i temps significa que es poden fer més proves i no menys. És el cas quan s’arriba a fites essent crítics. Això permet que les proves mantinguin el ritme junt amb equips de desenvolupaments àgils en lloc de plantar-se de maneres.

Per tant, les organitzacions publiquen codi amb molta més freqüència. D’aquesta manera es redueixen els impactes i es produeixen versions de defectes. Això significa que els desenvolupadors treballen amb codis nets. La correcció d'errors ha estat menys complicada dramàticament. Això allibera els provadors mitjançant l'única actuació de porters enfocats a la creativitat. Les proves exploratòries milloren així les qualitats dels productes.

La prova d'automatització de les interfícies mòbils ofereix avantatges quant a temps i qualitats. Eines automatitzades que permeten als provadors avaluar fàcilment les interfícies d’usuari de les aplicacions a través d’ampli rang de dispositius mòbils i fer modificacions per augmentar fàcilment les experiències dels usuaris.

Conclusió

Una interfície gràfica d’usuari incorrecta és una experiència desagradable per a l’usuari. Les proves de la GUI són molt recomanables i importants, sobretot quan es tracta de dispositius intel·ligents, perquè la mida de la pantalla és relativament petita i hi ha moltes variacions disponibles als dispositius del mercat.

La vostra aplicació pot tenir un aspecte i un comportament diferents en diferents dispositius. Per tant, és important provar l'aplicació en almenys algunes mides i variacions estàndard de dispositius.

Totes les aplicacions mòbils necessiten proves d’interfície d’usuari, però la profunditat de les proves necessàries està definida per la categoria o el propòsit de l’aplicació. Abans de finalitzar el banc de proves, hauríeu de fer una anàlisi completa de les funcions de la interfície d’usuari de l’aplicació en relació amb el model o el sistema operatiu del telèfon.

Basat en aquesta anàlisi, heu de crear els casos de prova per provar-los. Utilitzeu l’automatització sempre que sigui possible per estalviar temps.

Mantingueu un ull obert mentre proveu la interfície d’usuari perquè és senzill, però té un gran efecte en la venda de la vostra aplicació.

Mireu el nostre proper tutorial per obtenir informació detallada sobre Prova de resposta mòbil .

Lectura recomanada

• Tutorial d'Appium per provar aplicacions mòbils Android i iOS
• TOP 15 de les millors eines de proves mòbils el 2021 per a Android i iOS
• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Serveis de proves beta d'aplicacions mòbils (eines de prova beta per a iOS i Android)
• Per què les proves per a mòbils són difícils?
• Introducció a Robotium: l'eina de prova de la interfície d'usuari d'aplicacions d'Android més popular
• Prova de descàrrega de llibres electrònics
• 11 millors eines d'automatització per provar aplicacions d'Android (eines de prova d'aplicacions d'Android)