Free Press

Täydellinen opas mobiilisovellusten testaukseen syvällisten opetusohjelmien avulla:

Mobiiliteknologia ja älylaitteet ovat nyt trendi, ja ne tulevat muuttamaan maailman tulevaisuutta sellaisena kuin me sen tunnemme. Me kaikki voimme taata sen, eikö totta? Nyt olisi amatöörimäistä, jos luettelisin, mihin käytämme näitä mobiililaitteita. Te kaikki tiedätte sen – ehkä paremmin kuin me.

Käydään suoraan siihen, mistä tässä opetusohjelmassa on kyse.

Täydellinen luettelo 30+ mobiilitestauksen tutoriaaleista:

Mobiilitestauksen johdanto:

Tutoriaali #1: Johdatus mobiilitestaukseen
Tutoriaali #2: iOS-sovellusten testaus
Tutoriaali #3: Android-sovellusten testaus
Tutoriaali #4: Mobiilitestaushaasteet ja -ratkaisut
Tutoriaali #5: Miksi mobiilitestaus on vaikeaa?

Mobiililaitteiden testaus:

Tutorial #6: Android-version testaaminen, kun se otetaan pois markkinoilta
Tutorial #7: Mobiilisovellusten testaaminen edullisilla laitteilla
Tutorial #8: Mobiilisovellusten kenttätestaus
Tutorial #9: Puhelinmalli vs. käyttöjärjestelmän versio: Which Should Be Tested First?

Mobile UI Testing:

Tutorial #10: UI Testing of Mobile Apps
Tutorial #11: Mobile Responsive Test

Mobile Testing Services:

Tutorial #12: Cloud-Based Mobile Application Testing
Tutorial #13: Mobiilisovellusten testauspalvelut
Tutorial #14: Mobiilisovellusten beta-testauspalvelut
Tutorial #15: Mobiilisovellusten kehitysyhtiö
Tutorial #16: Pilvipohjaiset mobiilisovellusten testauspalveluiden tarjoajat

Mobiilisovellusten suorituskyvyn ja tietoturvan testaus:

Tutorial #17: Mobiilisovellusten suorituskyvyn testaus BlazeMeterin avulla
Tutorial #18: Mobiilisovellusten tietoturvatestausohjeet

Mobiilitestausvälineet:

Tutorial #19: Android-sovellusten testaustyökalut
Tutorial #20: Parhaat mobiilisovellusten tietoturvatestaustyökalut
Tutorial #21: 58 parasta mobiilitestaustyökalua

Mobiiliautomaatiotestaus:

Tutorial #22: Appium mobiiliautomaatiotyökalun opetusohjelma
Tutorial #23: Appium Studio tutorial
Tutorial #24: Android-sovellusten automatisointi TestComplete-työkalulla
Tutorial #25: Robotium tutorial – Android App UI Testing Tool
Tutorial #26: Selendroid tutorial: Mobile Automation Framework
Tutorial #27: pCloudy Tutorial: Mobile App Testing on Real Devices
Tutorial #28: Katalon Studio & Kobiton’s Cloud-Based Device Farm Tutorial

Mobile Testing Career:

Tutorial #29: How to Get a Mobile Testing Job Fast
Tutorial #30: Mobiilitestauksen haastattelukysymykset ja ansioluettelo
Tutoriaali #31: Mobiilitestauksen haastattelukysymykset osa 2

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

Aloitetaan sarjan 1. opetusohjelmasta.

Tutoriaali #1: Johdatus mobiilisovellusten testaukseen

Viimeiset ajat ovat ohi, jolloin puhelin oli laite, joka istui nurkassa ja jonka piti soida saadakseen huomiomme, tai tietokone oli kone, jota vain harvat käyttivät – nykyään ne ovat olemuksemme jatke – ikkuna maailmaan ja virtuaalisia palvelijoita, jotka tekevät niin kuin käsketään.

Tietokoneet saivat raivon valloilleen ja muuttivat sitä, miten me ihmiset ajattelemme, käyttäydymme, opimme ja olemme olemassa.

Tänä päivänä Mobility-ratkaisut ovat vallanneet markkinat. Ihmiset eivät halua kytkeä kannettavia tietokoneitaan/PC:tä kaikkeen, vaan he haluavat kämmenlaitteidensa suorittavan kaiken nopeasti.

Siten mobiiliratkaisut, joita toimitamme asiakkaillemme, on testattava hyvin. Tämä opetusohjelma on tarkoitettu niille henkilöille, jotka ovat jo mukana mobiilitestauksessa tai jotka ovat siirtyneet siihen viime aikoina. Koska meillä on jo monia opetusohjelmia mobiilitestaukseen liittyvien termien määritelmistä, käsittelemme suoraan tämän opetusohjelman laajuutta.

Tämä opetusohjelma on sekä johdanto että oppaasi mobiilitestaukseen. Lue siis läpi!

Mobiilitestauksen tyypit

Mobiililaitteilla tapahtuvaa testausta on pääpiirteittäin kahdenlaista:

#1. Laitteistotestaus:

Laite, mukaan lukien sisäiset prosessorit, sisäinen laitteisto, näytön koko, resoluutio, tila tai muisti, kamera, radio, Bluetooth, WIFI jne. Tähän viitataan joskus myös nimellä ”Mobiilitestaus”.

#2. Ohjelmistojen tai sovellusten testaus:

Testataan mobiililaitteissa toimivat sovellukset ja niiden toiminnallisuus. Sitä kutsutaan ”Mobiilisovellusten testaukseksi” erottamaan se aiemmasta menetelmästä. Mobiilisovelluksissakin on muutamia peruseroja, joiden ymmärtäminen on tärkeää:

a) Natiivit sovellukset: Natiivisovellus luodaan käytettäväksi alustalla, kuten matkapuhelimissa ja tableteissa.
b) Mobiiliverkkosovellukset ovat palvelinpuolen sovelluksia, joiden avulla verkkosivuja/-sivuja voidaan käyttää matkapuhelimessa erilaisilla selaimilla, kuten Chromella ja Firefoxilla, muodostamalla yhteys matkapuhelinverkkoon tai langattomaan verkkoon, kuten WIFI:hen.
c) Hybridisovellukset ovat natiivisovelluksen ja verkkosovelluksen yhdistelmiä. Ne toimivat laitteissa tai offline-tilassa, ja ne on kirjoitettu käyttäen web-tekniikoita, kuten HTML5:tä ja CSS:ää.

On muutamia peruseroja, jotka erottavat nämä toisistaan:

• Natiivisovelluksilla on yhden alustan affiniteetti, kun taas mobiileilla web-sovelluksilla on ristikkäisalustan affiniteetti.
• Natiivit sovellukset on kirjoitettu alustoille, kuten SDK:ille, kun taas mobiiliverkkosovellukset on kirjoitettu web-tekniikoilla, kuten HTML, CSS, asp.net, Java, PHP.
• Natiivisovellukseen tarvitaan asennus, mutta mobiiliverkkosovelluksiin ei tarvita asennusta.
• Natiivisovellus voidaan päivittää Play- tai sovelluskaupasta, kun taas mobiiliverkkosovellukset ovat keskitettyjä päivityksiä.
• Monet natiivisovellukset eivät vaadi internetyhteyttä, mutta mobiiliverkkosovelluksille se on välttämätön.
• Natiivisovellus toimii nopeammin verrattuna mobiiliverkkosovelluksiin.
• Natiivit sovellukset asennetaan sovelluskaupoista, kuten Google Play-kaupasta tai sovelluskaupasta, kun taas mobiiliverkkosovellukset ovat verkkosivuja ja niihin pääsee käsiksi vain Internetin kautta.

Artikkelin loppuosa käsittelee mobiilisovellusten testausta.

Mobiilisovellusten testauksen merkitys

Sovellusten testaaminen mobiililaitteilla on haastavampaa kuin web-sovellusten testaaminen työpöydällä johtuen

• Erilaisesta valikoimasta mobiililaitteita, joissa on erikokoiset näytöt ja laitteistokokoonpanot, kuten kovalevyinen näppäimistö, virtuaalilevyinen näppäimistö (kosketusvärinäyttö) ja raidepallo jne.
• Laaja valikoima mobiililaitteita, kuten HTC, Samsung, Apple ja Nokia.
• Erilaiset mobiilikäyttöjärjestelmät, kuten Android, Symbian, Windows, Blackberry ja IOS.
• Erilaisia käyttöjärjestelmäversioita, kuten iOS 5.x, iOS 6.x, BB5.x, BB6.x jne.
• Erilaisia matkaviestinverkko-operaattoreita, kuten GSM ja CDMA.
• Tiheät päivitykset – (kuten Android- 4.2, 4.3, 4.4, iOS-5.x, 6.x) – jokaisen päivityksen yhteydessä suositellaan uutta testaussykliä, jotta voidaan varmistaa, ettei sovelluksen toiminnallisuus kärsi.

Kuten minkä tahansa sovelluksen kohdalla, myös mobiilisovellusten testaaminen on erittäin tärkeää, sillä asiakaskunta on yleensä miljoonia ihmisiä, jotka haluavat tietyn tuotteen – ja tuotetta, jossa on virheitä, ei koskaan arvosteta. Se johtaa usein rahallisiin tappioihin, oikeudellisiin ongelmiin ja korjaamattomiin vahinkoihin tuotemerkin imagolle.

Mobiili- ja työpöytäsovellusten testauksen perusero:

Vähän ilmiselviä seikkoja, jotka erottavat mobiilisovellusten testauksen työpöytätestauksesta

• Työpöydällä sovellus testataan keskusyksikössä. Mobiililaitteessa sovellus testataan Samsungin, Nokian, Applen ja HTC:n kaltaisissa luureissa.
• Mobiililaitteen näytön koko on pienempi kuin työpöydän.
• Mobiililaitteissa on vähemmän muistia kuin työpöydässä.
• Mobiililaitteissa käytetään verkkoyhteyksiä, kuten 2G-, 3G-, 4G- tai WIFI-verkkoja, kun taas työpöydässä käytetään laajakaista- tai valintaradiolinkkejä.
• Työpöytäsovellusten testauksessa käytetty automatisointityökalu ei välttämättä toimi mobiilisovelluksissa.

Mobiilisovellusten testauksen tyypit:

Kaikkien edellä mainittujen teknisten näkökohtien huomioon ottamiseksi mobiilisovelluksille suoritetaan seuraavia testaustyyppejä.

• Käytettävyystestaus- Varmistetaan, että mobiilisovellus on helppokäyttöinen ja tarjoaa asiakkaille tyydyttävän käyttökokemuksen
• Yhteensopivuustestaus- Sovelluksen testaus eri mobiililaitteilla, selaimilla, näytön kooilla ja käyttöjärjestelmäversioilla vaatimusten mukaisesti.
• Käyttöliittymän testaus- Sovelluksen valikkovaihtoehtojen, painikkeiden, kirjanmerkkien, historian, asetusten ja navigointivirran testaaminen.
• Palveluiden testaus- Sovelluksen palveluiden testaaminen verkossa ja offline-tilassa.
• Matalan tason resurssien testaus: Muistin käytön, väliaikaistiedostojen automaattisen poistamisen ja paikallisen tietokannan kasvuun liittyvien ongelmien testaaminen tunnetaan nimellä matalan tason resurssien testaus.
• Suorituskyvyn testaus- Sovelluksen suorituskyvyn testaaminen vaihtamalla yhteys 2G:stä, 3G:stä WIFI:iin, jakamalla asiakirjoja, akun kulutusta jne.
• Toiminnallinen testaaminen- Varmuuskopiointien ja palautussuunnitelman testaaminen, jos akku menee rikki, tai tietojen menettäminen, kun sovellusta päivitetään kaupasta.
• Asennustestit- Sovelluksen validointi asentamalla/poistamalla se laitteisiin.
• Tietoturvatestaus- Sovelluksen testaus sen validoimiseksi, suojaako tietojärjestelmä tietoja vai ei.

Mobiilisovellusten testausstrategia

Testausstrategialla on varmistettava, että kaikki laatu- ja suorituskykyohjeet täyttyvät. Muutamia vinkkejä tällä alueella:

1) Laitteiden valinta – Analysoi markkinat ja valitse laitteet, jotka ovat laajasti käytössä. (Tämä päätös riippuu enimmäkseen asiakkaista. Asiakas tai sovelluksen rakentajat ottavat huomioon tiettyjen laitteiden suosiotekijän sekä sovelluksen markkinointitarpeet päättäessään, mitä puhelimia käytetään testaukseen.)

2) Emulaattorit – Niiden käyttö on erittäin hyödyllistä kehityksen alkuvaiheessa, sillä ne mahdollistavat sovelluksen nopean ja tehokkaan tarkistamisen. Emulaattori on järjestelmä, joka ajaa ohjelmistoa ympäristöstä toiseen muuttamatta itse ohjelmistoa. Se kopioi ominaisuudet ja toimii oikeassa järjestelmässä.

Kännykkäemulaattoreiden tyypit

• Laiteemulaattori- laitevalmistajien tarjoama
• Selainemulaattori- simuloi mobiiliselainympäristöjä.
• Käyttöjärjestelmäemulaattori- Apple tarjoaa emulaattoreita iPhoneille, Microsoft Windows-puhelimille ja Google Android-puhelimille

Suositeltava työkalu

#1) Kobiton

Kobiton on edullinen ja erittäin joustava pilvipohjainen mobiilikokemusalusta, joka nopeuttaa natiivien, verkko- ja hybridiapplikaatioiden testausta ja toimitusta sekä Androidilla että iOS:llä käyttäen oikeita laitteita. Heidän uusi skriptitön testiautomaatio auttaa tiimejä, joilla ei ole koodausosaamista, tuottamaan avoimen standardin mukaisia Appium-skriptejä helposti.

=> Käy Kobitonin verkkosivustolla

Luettelo muutamasta ilmaisesta ja helppokäyttöisestä mobiililaite-emulaattorista

i. Matkapuhelinemulaattori – Käytetään puhelimien, kuten iPhonen, Blackberryn, HTC:n, Samsungin jne. testaamiseen.

ii. MobiReady – Tämän avulla voidaan testata verkkosovelluksen lisäksi myös koodi.

iii. Responsivepx – Sillä tarkistetaan verkkosivujen vasteet, ulkonäkö ja toiminnallisuus.

iv. Screenfly – Se on muokattavissa oleva työkalu, ja sitä käytetään eri luokkiin kuuluvien verkkosivustojen testaamiseen.

3) Kun mobiilisovelluksen kehitys on saatu tyydyttävälle tasolle, voit siirtyä testaamaan fyysisillä laitteilla todellisempiin skenaarioihin perustuvaa testausta varten.

4) Harkitse pilvipohjaista testausta: Pilvilaskenta on periaatteessa laitteiden käyttämistä useissa järjestelmissä tai verkoissa Internetin kautta, jossa sovelluksia voidaan testata, päivittää ja hallita. Testausta varten se luo verkkopohjaisen mobiiliympäristön simulaattorilla, jotta mobiilisovellusta voidaan käyttää.

Pros:

• Varmuuskopiointi ja palautus – Pilvipohjainen tietojenkäsittely ottaa automaattisesti varmuuskopion tiedoistasi etäkohteesta, mikä tekee tietojen palautuksesta ja palauttamisesta helppoa. Lisäksi tallennuskapasiteetti on rajaton.
• Pilveä voi käyttää eri laitteista ja mistä tahansa.
• Pilvilaskenta on kustannustehokasta, helppokäyttöistä, ylläpidettävää ja päivitettävää.
• Nopea ja nopea käyttöönotto.
• Web-pohjainen käyttöliittymä.
• Voi ajaa samaa komentosarjaa useilla laitteilla rinnakkain.

Miinukset

• Vähemmän hallintaa- Koska sovellus toimii etäkäytössä tai kolmannen osapuolen ympäristössä, käyttäjällä on rajoitettu hallinta ja pääsy toimintoihin.
• Internet-yhteysongelmat- käyttöönotto tapahtuu Internetissä. Verkko-ongelmat vaikuttavat saatavuuteen ja toimintaan
• Turvallisuus- ja yksityisyyskysymykset- Pilvilaskenta on Internet-laskentaa, eikä mikään Internetissä ole täysin turvallista, joten tietojen hakkeroinnin mahdollisuudet ovat suuremmat.

5) Automaatio vs. Manuaalinen testaus

• Jos sovellus sisältää uutta toiminnallisuutta, testaa se manuaalisesti.
• Jos sovellus vaatii testausta kerran tai kahdesti, tee se manuaalisesti.
• Automatisoi regressiotestitapausten skriptit. Jos regressiotestejä toistetaan, automatisoitu testaus sopii siihen erinomaisesti.
• Automatisoi skriptit monimutkaisille skenaarioille, jotka ovat aikaa vieviä, jos ne suoritetaan manuaalisesti.

Mobiilisovellusten testaamiseen on saatavilla kahdenlaisia automatisointityökaluja:

objektipohjaiset mobiilitestausvälineet- automatisointi kartoittamalla laitteen näytön elementit objekteiksi. Tämä lähestymistapa on riippumaton näytön koosta ja sitä käytetään pääasiassa Android-laitteissa.

• Eg:- Ranorex, jamo solution

Kuvapohjaiset mobiilitestaustyökalut- luodaan automaatioskriptejä elementtien näyttökoordinaattien perusteella.

• Eg:- Sikuli, Egg Plant, RoutineBot

6) Verkkokonfigurointi on niin ikään välttämätön osa mobiilitestauksessa. On tärkeää validoida sovellus eri verkoissa, kuten 2G-, 3G-, 4G- tai WIFI-verkoissa.

Testitapaukset mobiilisovelluksen testaamiseen

Toiminnallisuuteen perustuvien testitapausten lisäksi mobiilisovelluksen testaaminen edellyttää erityisiä testitapauksia, joiden tulisi kattaa seuraavat skenaariot.

• Akun käyttö- On tärkeää seurata akun kulutusta sovelluksen ollessa käynnissä mobiililaitteissa.
• Sovelluksen nopeus- vasteaika eri laitteilla, eri muistiparametreilla, eri verkkotyypeillä jne.
• Datavaatimukset – Asennusta varten sekä sen tarkistamiseksi, pystyykö käyttäjä, jolla on rajallinen datapaketti, lataamaan sen.
• Muistivaatimus – taas lataamiseen, asentamiseen ja suorittamiseen
• Sovelluksen toimivuus – varmista, että sovellus ei kaadu verkkovian tai minkään muun takia.

Lataa joitakin esimerkkitestitapauksia mobiilisovellusten testaamiseen:

=> Lataa mobiilisovelluksen esimerkkitestitapauksia

Tyypillisiä toimintoja ja menettelyjä mobiilisovelluksen testauksessa

Testauksen laajuus riippuu tarkistettavien vaatimusten määrästä tai sovellukseen tehtyjen muutosten laajuudesta. Jos muutoksia on vähän, terveystestauskierros riittää. Jos muutokset ovat suuria ja/tai monimutkaisia, suositellaan täydellistä regressiotestausta.

Esimerkki sovelluksen testausprojektista: ILL (International Learn Lab) on sovellus, joka on suunniteltu auttamaan ylläpitäjää, julkaisijaa luomaan verkkosivustoja yhteistyössä. Web-selaimen avulla ohjaajat valitsevat joukosta ominaisuuksia luodakseen vaatimustensa mukaisen luokan.

Mobiilitestausprosessi:

Vaihe #1. Tunnista testaustyypit: Koska ILL-sovellus on sovellettavissa selaimiin, on pakollista testata tätä sovellusta kaikilla tuetuilla selaimilla eri mobiililaitteilla. Meidän on tehtävä käytettävyys-, toiminnallinen ja yhteensopivuustestaus eri selaimilla manuaalisten ja automatisoitujen testitapausten yhdistelmillä.

Vaihe #2. Manuaalinen ja automatisoitu testaus: Tässä projektissa noudatetaan ketterää menetelmää, jossa iteraatio kestää kaksi viikkoa. Joka toinen viikko kehitystiimi julkaisee uuden buildin testausryhmälle, ja testausryhmä suorittaa testitapaukset QA-ympäristössä. Automaatiotiimi luo skriptejä perustoiminnallisuuksia varten ja ajaa skriptejä, joiden avulla voidaan määrittää, onko uusi build tarpeeksi vakaa testattavaksi. Manuaalinen testausryhmä testaa uuden toiminnallisuuden.

JIRAa käytetään hyväksymiskriteerien kirjoittamiseen; testitapausten ylläpitoon ja vikojen kirjaamiseen / uudelleen tarkistamiseen. Kun iteraatio on ohi, pidetään iteraation suunnittelupalaveri, jossa dev. tiimi, tuoteomistaja, liiketoiminta-analyytikko ja QA-tiimi keskustelevat siitä, mikä meni hyvin ja mitä on parannettava.

Vaihe 3. Betatestaus: Kun QA-tiimi on saanut regressiotestauksen valmiiksi, build siirtyy UAT:iin. Käyttäjän hyväksymistestauksen tekee asiakas. He tarkistavat uudelleen kaikki virheet varmistaakseen, että jokainen virhe on korjattu ja että sovellus toimii odotetulla tavalla kaikilla hyväksytyillä selaimilla.

Vaihe #4. Suorituskykytesti: Suorituskykytestausryhmä testaa verkkosovelluksen suorituskyvyn JMeter-skriptien avulla ja sovelluksen eri kuormituksilla.

Vaihe #5. Selaintestaus: Web-sovellusta testataan useilla selaimilla – sekä erilaisilla simulointityökaluilla että fyysisesti todellisilla mobiililaitteilla.

Vaihe #6. Lanseeraussuunnitelma: Joka neljännen viikon jälkeen testaus siirtyy stagingiin, jossa suoritetaan viimeinen kierros päästä päähän -testausta näillä laitteilla, jotta varmistetaan, että tuote on valmis tuotantoon. Ja sitten se lähtee Live!

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

Miten testata mobiilisovelluksia sekä Android- että iOS-alustoilla

Sovelluksiaan sekä iOS- että Android-alustoilla testaavien testaajien on erittäin tärkeää tuntea molempien ero. iOS:llä ja Androidilla on paljon eroja ulkoasun, sovelluksen näkymien, koodausstandardien, suorituskyvyn jne. suhteen.

Perusero Androidin ja iOS:n testauksen välillä

Olet ehkä käynyt läpi kaikki opetusohjelmat, olen laittanut tähän joitain tärkeimpiä eroja, jotka puolestaan auttavat sinua osana testaustasi:

#1) Koska meillä on paljon Android-laitteita saatavilla markkinoilla ja kaikissa niissä on erilaiset näytön resoluutiot ja koot, joten tämä on yksi tärkeimmistä eroista.

Esimerkiksi Samsung S2:n koko on liian pieni verrattuna Nexus 6:een. On hyvin mahdollista, että sovelluksesi ulkoasu ja suunnittelu vääristyvät jommassakummassa laitteessa. Todennäköisyys on pieni iOS:ssä, koska markkinoilla on vain lukematon määrä laitteita ja niistä monilla puhelimilla on samanlainen resoluutio.

Esimerkiksi ennen iPhone 6:n ja sitä vanhempien versioiden syntymistä kaikilla vanhemmilla versioilla oli vain samanlainen koko.

#2) Esimerkki yllä olevan väitteen vahvistamiseksi on, että Androidissa kehittäjien on käytettävä 1x,2x,3x,4x ja 5x kuvia tukeakseen kuvien resoluutioita kaikissa laitteissa, kun taas iOS:ssä käytetään vain 1x,2x ja 3x. Testaajan vastuulle jää kuitenkin varmistaa, että kuvat ja muut käyttöliittymäelementit näkyvät oikein kaikilla laitteilla.

Kuvaresoluutioiden käsitteen voi ymmärtää alla olevasta kaaviosta:

#3) Koska markkinat tulvivat Android-laitteita, koodi on kirjoitettava siten, että suorituskyky pysyy tasaisena. On siis varsin todennäköistä, että sovelluksesi saattaa käyttäytyä hitaasti alemman hintaluokan laitteissa.

#4) Toinen Androidin ongelma on se, että ohjelmistopäivityksiä ei ole saatavilla kaikille laitteille kerralla. Laitevalmistajat päättävät, milloin laitteita päivitetään. On hyvin vaikea tehtävä testata kaikkea sekä uudella että vanhalla käyttöjärjestelmällä.

Kehittäjille tulee myös hankala tehtävä muokata koodiaan tukemaan molempia versioita.

Esimerkiksi Android 6.0:n ilmestyessä tapahtui suuri muutos, sillä tämä käyttöjärjestelmä alkoi tukea sovellustason käyttöoikeuksia. Selventääkseni lisää, käyttäjä pystyi muuttamaan käyttöoikeuksia (sijainti, yhteystiedot) myös sovellustasolla.

Nyt testaustiimin vastuulla on varmistaa, että käyttöoikeusnäyttö näytetään sovelluksen käynnistyksen yhteydessä Android 6.0:lla ja sitä uudemmilla versioilla eikä käyttöoikeusnäyttöä näytetä alemmilla versioilla.

#5) Testauksen näkökulmasta tarkasteltuna tuotantoa edeltävän rakennuksen (eli betaversion) testaaminen eroaa toisistaan molemmilla alustoilla. Androidissa, jos käyttäjä on lisätty beta-käyttäjien luetteloon, hän näkee päivitetyn beta-buildin Play-kaupassa vain, jos hän on kirjautunut sisään Play-kaupassa samalla sähköpostitunnuksella, joka on lisätty beta-käyttäjäksi.

Mobiilitestauksen avaintekijät

Olen työskennellyt mobiilitestauksen parissa viimeiset kaksi vuotta sekä iOS- että Android-alustalla ja kaikki tässä oppaassa alla mainitut avaintekijät ovat henkilökohtaisesta kokemuksestani ja osa on johdettu projektissa kohdatuista ongelmista.

Määrittele oma testauksen laajuutesi

Jokainen testaa omalla tyylillään. Jotkut testaajat keskittyvät vain siihen, mitä he näkevät silmillään ja loput ovat intohimoisesti kiinnostuneita kaikesta, mikä toimii minkä tahansa mobiilisovelluksen kulissien takana.

Jos olet iOS/Android-testaaja, suosittelen, että tutustut ainakin joihinkin Androidin tai iOS:n yleisiin rajoituksiin/perustoiminnallisuuksiin, koska se tuo aina lisäarvoa testaustyyliimme. Tiedän, että asioita on vaikea ymmärtää ilman esimerkkejä.

Alhaalla on muutama esimerkki:

• Emme voi muuttaa käyttöoikeuksia, kuten kameraa, tallennustilaa jne. sovellustasolla Android-laitteissa, jotka ovat alle 6.0.1-versiota.
• IOS:ssa alle 10.0-versiossa call kitiä ei ollut. Lyhyesti sanottuna soittosarjaa käyttää soittosovellus ja se näyttää koko näytön näkymän, kun käyttäjä saa puhelun soittosovelluksista, kuten WhatsAppista, Skypestä jne. Kun taas iOS-versioissa alle 10.0 näemme nämä puhelut ilmoitusbannerina.
• Monet teistä ovat ehkä törmänneet Paytmissä ongelmiin, joissa sovellus ei ohjaa sinua pankin maksusivulle, jos haluat lisätä rahaa lompakkoosi. Uskomme, että edellä mainittu on ongelma pankin tai Paytm-palvelimen kanssa, mutta se on vain se, että AndroidSystemWebView ei ole päivitetty. Pieni tieto ohjelmoinnista on aina hyödyllistä sinulle ja jaettavaksi tiimisi kanssa.
• Yksinkertaisesti sanottuna, aina kun sovellus avaa siinä minkä tahansa verkkosivun, AndroidSystemWebView pitäisi päivittää.

Älä rajoita testaustasi

Testauksen ei pitäisi rajoittua vain mobiilisovelluksen tutkimiseen ja virheiden kirjaamiseen. Meidän QA:na pitäisi olla tietoisia kaikista palvelimellemme tulevista pyynnöistä ja vastauksista, joita saamme niistä.

Konfiguroi Putty katsomaan lokeja tai tarkista sumo-logiikka lokien osalta riippuen siitä, mitä projektissasi käytetään. Se ei ainoastaan auta sinua tuntemaan sovelluksen End-to-End-virtausta, vaan tekee sinusta myös paremman testaajan, koska saat nyt enemmän ideoita ja skenaarioita.

Syy: Mikään ei tule tähän maailmaan ilman syytä. Jokaisella lausunnolla pitäisi olla pätevä syy takanaan. Syy lokien analysoinnin taustalla on se, että monia poikkeuksia havaitaan lokeissa, mutta ne eivät näytä mitään vaikutusta käyttöliittymään, joten emme huomaa sitä.

Selvä, pitäisikö meidän siis jättää se huomiotta?

Ei, meidän ei pitäisi. Sillä ei ole mitään vaikutusta käyttöliittymään, mutta se voi olla futuristinen huolenaihe. Voimme mahdollisesti nähdä sovelluksemme kaatuvan, jos tällaiset poikkeukset jatkavat hiipimistä. Kuten olemme maininneet App Crashista viimeisessä lauseessa, tämä johtaa siihen, että QA:lla on pääsy projektin crashlyticsiin.

Crashlytics on työkalu, jossa kaatumiset kirjataan ylös ajan ja laitemallin kera.

Kysymys tässä kohtaa on nyt se, että jos testaaja on nähnyt sovelluksen kaatuilevan, niin miksi hänen tarvitsee vaivautua crashlyticsin suhteen?

Vastaus tähän on varsin mielenkiintoinen. On joitakin kaatumisia, jotka eivät ehkä näy käyttöliittymässä, mutta ne kirjautuvat crashlyticsiin. Se voi olla muistin loppuminen tai joitakin kohtalokkaita poikkeuksia, jotka voivat vaikuttaa suorituskykyyn myöhemmin.

Yleisalustarajat ylittävä testaus

Yleisalustarajat ylittävä vuorovaikutustestaus on erittäin tärkeää.

Lainaa yksinkertainen esimerkki, sanotaan, että työskentelet WhatsAppin kaltaisen chattisovelluksen parissa, joka tukee kuvien ja videoiden lähettämistä ja sovellus on rakennettu sekä iOS- että Android-alustoille (kehitys voi olla tai olla menossa synkronoituna)

Varmista Androidin ja iOS:n kommunikaation testaaminen, syynä tähän on se, että iOS käyttää ”Objective C” -tekniikkaa, kun taas Android-ohjelmointi perustuu Java-pohjaiseen ohjelmointityyppiin, ja koska molemmat on rakennettu erilaisille alustoille, joskus sovelluksen puolella on tehtävä ylimääräisiä korjauksia, joiden avulla voidaan tunnistaa erilaisilta kielialustoilta tulevia merkkijonoja.

Pitäkää silmällä mobiilisovelluksenne kokoa

Toinen tärkeä neuvo mobiilitestaajille – Tarkistakaa sovelluksenne koko jokaisen julkaisun jälkeen.

Meidän tulisi varmistaa, että sovelluksen koko ei saavuta sellaista pistettä, jossa edes me loppukäyttäjinä emme halua ladata tätä sovellusta sen suuren koon vuoksi.

Sovelluksen päivitysskenaarioiden testaaminen

Mobiilitestaajille sovelluksen päivitystestaus on erittäin tärkeää. Varmista, että sovelluksesi ei kaadu päivityksen yhteydessä, koska kehitystiimi on saattanut tehdä versionumeron yhteensopimattomuuden.

Datan säilyttäminen on myös yhtä tärkeää, sillä mitä tahansa asetuksia käyttäjä on tallentanut edellisessä versiossa, ne pitäisi säilyttää, kun hän päivittää sovelluksen.

Käyttäjä on esimerkiksi saattanut tallentaa pankkikorttitietonsa sovelluksiin, kuten PayTm:iin jne.

Laite-käyttöjärjestelmä voi olla tukematta sovellusta

Asounds Interesting?

Joo, monet laitteet eivät välttämättä tue sovellustasi. Monet teistä varmasti tietävät, että toimittajat kirjoittavat omia kääreitä US:n päälle ja voi olla mahdollista, että mikä tahansa sovelluksesi SQL-kysely ei ole yhteensopiva laitteen kanssa ja näin ollen se heittää poikkeuksen ja se voi johtaa siihen, että sovellusta ei edes käynnistetä kyseisessä puhelimessa.

Point over here is – Yritä käyttää sovellustasi omilla laitteillasi lukuun ottamatta niitä, joita käytät toimistossa. On täysin mahdollista, että näet joitakin ongelmia sovelluksessasi.

Sovelluksen käyttöoikeustestaus

Seuraavana listalla on mobiilisovellusten käyttöoikeustestaus. Lähes joka toinen sovellus pyytää käyttäjiltään pääsyä puhelimen yhteystietoihin, kameraan, galleriaan, sijaintiin jne. Olen nähnyt muutamia testaajia, jotka tekevät virheen jättämällä testaamatta näiden käyttöoikeuksien oikeat yhdistelmät.

Muistan erään reaaliaikaisen esimerkin, kun testasimme chat-sovellusta, jossa oli kaikki kuvien ja äänitiedostojen jakamiseen liittyvät ominaisuudet. Säilytyslupa oli asetettu EI.

Nyt, kun käyttäjä napsautti Kamera-vaihtoehtoa, se ei koskaan avautunut, ennen kuin säilytyslupa oli asetettu KYLLÄ. Skenaario jätettiin huomiotta, koska Android Marshmallowissa oli tämä toiminto, että jos tallennuksen käyttöoikeus on asetettu EI, kameraa ei voi käyttää kyseisessä sovelluksessa.

Laajuus ulottuu pidemmälle kuin mitä olemme käsitelleet edellä olevassa kappaleessa. Meidän pitäisi varmistaa, että sovellus ei pyydä lupia, joita ei käytetä.

Kuka tahansa ohjelmistoteollisuuteen perehtynyt loppukäyttäjä ei välttämättä lataa sovellusta, jossa pyydetään liikaa lupia. Jos olet poistanut jonkin ominaisuuden sovelluksestasi, varmista, että poistat sen luparuudun.

Vertaile samankaltaisten ja suosittujen sovellusten kanssa markkinoilla

Tarinan moraali – Jos koskaan olet epäileväinen, älä vain päätä sitä itse. Vertailu muihin samankaltaisiin sovelluksiin samalla alustalla voi vahvistaa argumenttiasi siitä, toimiiko testattava toiminnallisuus vai ei.

Saa yleiskatsaus Applen Build-hylkäyskriteereihin

Viimeiseksi, suurin osa teistä on saattanut törmätä tilanteisiin, joissa Apple on hylännyt buildinne. Tiedän, että tämä aihe ei kiinnosta suurta osaa lukijoista, mutta on aina hyvä tietää Applen hylkäyskäytännöt.

Testaajana meidän on vaikea huolehtia teknisistä näkökohdista, mutta silti on olemassa joitakin hylkäyskriteereitä, joista testaajat voivat huolehtia.

Lisätietoa tästä saat klikkaamalla tästä.

Ole aina etusijalla

Testaajana älä anna asioiden siirtyä Dev-tiimiltä/johtajilta omalle puolellesi. Jos olet intohimoinen testausta kohtaan, niin ”Ole aina etulinjassa”. Yritä sitouttaa itsesi toimintaan, joka tapahtuu hyvissä ajoin ennen kuin koodi tulee ämpäriisi testattavaksi.

Tärkeintä on, että katsot jatkuvasti JIRA:sta, QC:stä, MTM:stä tai mitä tahansa projektissasi käytetäänkin, jotta saat viimeisimmät päivitykset asiakkailta ja liiketoiminta-analyytikolta tulleisiin tiketteihin. Ole myös valmis jakamaan näkemyksesi, jos tarvitset muutoksia. Tämä koskee kaikkia testaajia, jotka työskentelevät eri toimialueilla ja alustoilla.

Jos emme tunne tuotetta omaksemme, meidän ei pitäisi koskaan antaa ehdotuksia uusista parannuksista tai muutoksista olemassa olevaan toiminnallisuuteen.

Pitäkää sovelluksenne taustalla pitkään (12-24 tuntia)

Tiedän, että se kuulostaa oudolta, mutta kulissien takana on paljon logiikkaa, jota me kaikki emme ymmärrä.

Jaan tämän, koska olen nähnyt sovelluksen kaatuilevan sen käynnistämisen jälkeen, vaikkapa noin 14 tunnin kuluttua taustatilasta. Syy voi olla mikä tahansa riippuen siitä, miten kehittäjät ovat koodanneet sen.

Jaan reaaliaikaisen esimerkin:

Minun tapauksessani tokenin vanheneminen oli syynä sen takana. Jos yksi chattisovelluksista käynnistettiin 12-14 tunnin kuluttua, se juuttui yhteysbanneriin, eikä yhteys muodostunut ennen kuin se lopetettiin ja käynnistettiin uudelleen. Tällaisia asioita on hyvin vaikea saada kiinni, ja tavallaan se tekee mobiilitestauksesta haastavampaa ja luovempaa.

Sovelluksen suorituskykytestaaminen

Mobiilimaailmassa sovelluksen suorituskyky vaikuttaa siihen, missä määrin sovelluksesi saa tunnustusta maailmanlaajuisesti. Testausryhmänä on liian tärkeää tarkistaa sovelluksesi vaste ja ennen kaikkea se, miten se toimii, kun suuri määrä käyttäjiä käyttää sitä kaikki yhdessä.

Esimerkki:

Puhutaanpa PayTm:stä.

Olette varmasti kaikki napsauttaneet PayTm-sovelluksessa ADD MONEY -vaihtoehtoa, joka näyttää sitten lompakossasi olevan saldon. Jos tarkastelemme, mitä kulissien takana tapahtuu, niin se on pyyntö, joka on menossa palvelimelle PayTm-käyttäjätunnuksella, ja palvelin lähettää takaisin vastauksen, jossa on tilisi saldo.

Yllä oleva tapaus on vain silloin, kun yksi käyttäjä on osunut palvelimelle. Meidän on varmistettava, että vaikka 1000 käyttäjää osuisi palvelimelle, heidän pitäisi saada vastaus takaisin hyvissä ajoin, koska loppukäyttäjän käytettävyys on ensisijainen tavoitteemme.

Johtopäätös

Kiinnitän tämän opetusohjelman loppuun toistamalla vielä kerran, että mobiilitestaus näyttää alussa hyvin helpolta, mutta kun jatkat syventymistä, ymmärrät, että ei ole helppoa varmistaa, että kaikki kehitetyt sovellukset toimivat sujuvasti tuhansissa laitteissa kaikkialla maailmassa.

Voit useimmiten nähdä sovelluksia, joita tuetaan vain uusimmissa ja viimeisimmissä käyttöjärjestelmäversioissa. Testaajien velvollisuudeksi tulee kuitenkin varmistaa, että he eivät jätä mitään skenaarioita väliin. On monia muitakin seikkoja, jotka on otettava huomioon, mutta en ole maininnut niitä, jotka on jo mainittu muissa opetusohjelmissa.

Skenaariot, kuten akunkulutus, keskeytystestaus, testaus eri verkoissa (3G, Wi-Fi), testaus verkon vaihdon aikana, mobiilisovellusten apinatestaus jne. ovat kaikki hyödyllisiä, kun on kyse mobiilitestauksesta.

Testaajien asenteella on paljon väliä todellisessa testausympäristössä. Kunnes ja ellet rakasta työtäsi, et viitsi tehdä asioita, jotka mainitaan opetusohjelmassa.

Olen ollut tällä alalla nyt noin 6 vuotta ja olen hyvin tietoinen siitä, että työtehtävät muuttuvat ajoittain yksitoikkoisiksi, mutta on monia muita asioita, joita voimme tehdä itse, jotta voimme tehdä noista yksitoikkoisista tehtävistä hieman mielenkiintoisia.

Suunnittelemalla oikean testausstrategian, valitsemalla oikeat mobiilisimulaattorit, laitteet ja mobiilitestaustyökalut voimme varmistaa, että saamme 100-prosenttisen testikattavuuden, ja auttaa meitä sisällyttämään tietoturva-, käytettävyys-, suorituskyky-, toiminnallisuus- ja yhteensopivuuspohjaisia testejä testisarjoihimme.

Nyt tämä on ollut yrityksemme täyttää lukijoiltamme tulleet lukuisat pyynnöt, jotka koskivat mobiilisovellustestauksen testausoppaita.

Tekijät: Kiitos Swapnalle, Hasnetille ja monille muille mobiilitestauksen asiantuntijoille, jotka auttoivat meitä tämän sarjan kokoamisessa!

Seuraavassa artikkelissamme käsittelemme enemmän iOS-sovellusten testausta.