Mobiilirakenduste testimine: näidisjuhtumid ja Teststsenaariumid

Lang L: none (table-of-contents):

Anonim

Meie õppija sagedane küsimus on Kuidas mobiilirakendusi testida? Selles õpetuses pakume mobiilirakenduse testimiseks proovitesti / stsenaariume.

Võite täita mõned või kõik testjuhtumid, lähtudes oma mobiilse testimise nõuetest. Testjuhtumid on korraldatud mobiilsete testimistüüpide põhjal.

  • Funktsionaalse testimise juhtumid
  • Jõudluse testimine
  • Turvalisuse testimise juhtumid
  • Kasutatavuse testimise juhtumid
  • Ühilduvuse testimise juhtumid
  • Taastatavuse testimise testjuhtumid
  • Tähtis kontrollnimekiri

Mobiilirakenduste funktsionaalne testimine

Funktsionaalne testimine Mobile Application on testimise protsess funktsioone mobiilside rakenduste nagu kasutajakoostoime samuti testimiseks tehingute et kasutajatel oleks täita. Mobiilirakenduste funktsionaalse testimise peamine eesmärk on tagada kvaliteet, vastata etteantud ootustele, vähendada riski või vigu ja klientide rahulolu.

Funktsionaalses testimises on olulised erinevad tegurid

  1. Rakenduse tüüp, mis põhineb ettevõtte funktsionaalsusel (pangandus, mängimine, sotsiaalne või äri)
  2. Sihtrühma tüüp (tarbija, ettevõte, haridus)
  3. Levitamiskanal, mida kasutatakse rakenduse levitamiseks (nt Apple App Store, Google Play, otselevi)

Funktsionaalse testimise kõige olulisemaid teststsenaariume võib pidada järgmisteks:

  1. Kontrollimaks, kas kõik kohustuslikud kohustuslikud väljad töötavad nõuetekohaselt.
  2. Kinnitamaks, et kohustuslikud väljad kuvatakse ekraanil eristamatul viisil kui mitte-kohustuslikud väljad.
  3. Kontrollige, kas rakendus töötab vastavalt nõudele alati, kui rakendus käivitub / peatub.
  4. Kontrollimaks, kas rakendus läheb sissetuleva telefonikõne korral minimeeritud režiimi. Sama kinnitamiseks peame seadmele helistamiseks kasutama teist telefoni.
  5. Kontrollimaks, kas telefon suudab rakenduse töötamise ajal SMS-e salvestada, töödelda ja vastu võtta. Sama kinnitamiseks peame kasutama teist telefoni, et saata sms seadmesse, mida testitakse ja kus testitav rakendus praegu töötab.
  6. Kontrollimaks, kas seade suudab täita nõutavaid multitegumtöötlusnõudeid, kui see on vajalik.
  7. Kinnitamaks, et rakendus võimaldab vajalikke suhtlusvõrgustike valikuid, nagu jagamine, postitamine ja navigeerimine jne.
  8. Kinnitamaks, et rakendus toetab kõiki makselüüsi tehinguid, nagu Visa, Mastercard, Paypal jne, nagu rakendus nõuab.
  9. Veendumaks, et lehel kerimise stsenaariumid on rakenduses vastavalt vajadusele lubatud.
  10. Selle kinnitamiseks, et navigeerimine rakenduse asjakohaste moodulite vahel vastab nõudele.
  11. Kinnitamaks, et kärpimisvead on täiesti taskukohase piirini.
  12. Selle kinnitamiseks, et kasutaja saab asjakohase tõrketeate, näiteks „Võrguviga. Palun proovige mõne aja pärast ”, kui võrguviga ilmneb.
  13. Kinnitamaks, et installitud rakendus võimaldab teistel rakendustel rahuldavalt töötada ja see ei söö teiste rakenduste mällu.
  14. Kinnitamaks, et rakendus taaskäivitub viimasel toimingul kõva taaskäivitamise või süsteemi krahhi korral.
  15. Selle kinnitamiseks, kas rakenduse installimine on sujuv, eeldusel, et kasutajal on vajalikud ressursid ja see ei too kaasa olulisi vigu.
  16. Kinnitamaks, et rakendus täidab automaatse käivitamise funktsiooni vastavalt nõuetele.
  17. Kontrollimaks, kas rakendus toimib vastavalt kõigi mobiilseadmete versioonide 2g, 3g ja 4g nõuetele.
  18. Regressioonitesti tegemine süsteemi olemasolevates piirkondades uute tarkvaravigade avastamiseks pärast muudatuste tegemist. Käivitage ka varem läbi viidud testid, et teha kindlaks, et programmi käitumine pole muudatuste tõttu muutunud.
  19. Kontrollimaks, kas rakendus pakub kättesaadavat kasutusjuhendit neile, kes pole rakendusega tuttavad

Jõudluskontrolli juhtumid

Seda tüüpi testimise põhieesmärk on tagada, et rakendus toimib vastuvõetavalt teatud toimivusnõuete kohaselt, nagu tohutu hulga kasutajate juurdepääs või infrastruktuuri võtmeosa, nagu andmebaasiserver, eemaldamine.

Mobiilirakenduse jõudluskontrolli üldised teststsenaariumid on järgmised:

  1. Et teha kindlaks, kas rakendus toimib vastavalt nõuetele erinevates koormustingimustes.
  2. Selleks, et teha kindlaks, kas praegune võrgu katvus on võimeline toetama rakendust kasutajate tipptasemel, keskmisel ja minimaalsel tasemel.
  3. Et teha kindlaks, kas olemasolev kliendi-serveri konfiguratsiooniseadistus tagab vajaliku optimaalse jõudlustaseme.
  4. Teha kindlaks erinevad rakenduse ja infrastruktuuri kitsaskohad, mis takistavad rakendust toimima nõutaval vastuvõetavustasemel.
  5. Kinnitamaks, kas rakenduse reageerimisaeg vastab nõuetele.
  6. Toote ja / või riistvara hindamiseks, et teha kindlaks, kas see suudab prognoositud koormusmahuga hakkama saada.
  7. Hindamaks, kas aku kasutusaeg suudab rakendust kavandatud koormusemahtude korral toetada.
  8. Rakenduse jõudluse kinnitamiseks, kui võrk on 2G / 3G-st asendatud WIFI-ga või vastupidi.
  9. Kõigi nõutavate protsessorite valideerimiseks on optimeerimine
  10. Selle kinnitamiseks, et aku tarbimine, mälu lekked, ressursid, näiteks GPS, on kaamera jõudlus vajalikes juhistes.
  11. Rakenduse pikaealisuse kinnitamiseks alati, kui kasutaja koormus on range.
  12. Võrgu jõudluse kinnitamiseks seadmega liikumisel.
  13. Rakenduse jõudluse kinnitamiseks, kui on vaja ainult vahelduvaid ühenduvusetappe.

Turvalisuse testimise juhtumid

Turvalisuse testimise põhieesmärk on tagada rakenduse andmete ja võrgu turvalisuse nõuete järgimine vastavalt juhistele.

Mobiilirakenduste turvalisuse kontrollimiseks on kõige olulisemad valdkonnad järgmised.

  1. Selle kinnitamiseks, et rakendus suudab vastu pidada igale jõulisele rünnakule, mis on automatiseeritud katse-eksituse protsess, mida kasutatakse inimese kasutajanime, parooli või krediitkaardinumbri äraarvamiseks.
  2. Kontrollimaks, kas rakendus ei luba ründajal ilma korraliku autentimiseta juurdepääsu tundlikule sisule või funktsioonidele.
  3. Selle kinnitamiseks, et rakendusel on tugev paroolikaitsesüsteem ja see ei luba ründajal teise kasutaja parooli hankida, muuta ega taastada.
  4. Kinnitamaks, et rakendus ei seansi ebapiisava aegumise tõttu.
  5. Dünaamiliste sõltuvuste kindlakstegemiseks ja meetmete võtmiseks, et mõni ründaja ei saaks nendele haavatavustele juurde pääseda.
  6. SQL-i süstimisega seotud rünnakute vältimiseks.
  7. Haldamata koodistsenaariumide tuvastamiseks ja taastamiseks.
  8. Kas sertifikaatide kinnitamise tagamiseks rakendab rakendus sertifikaatide kinnitamist või mitte.
  9. Rakenduse ja võrgu kaitsmiseks teenuse keelamise rünnakute eest.
  10. Andmete salvestamise ja valideerimise nõuete analüüsimiseks.
  11. Seansihalduse lubamiseks, et takistada volitamata kasutajatel juurdepääsu soovimatule teabele.
  12. Kontrollimaks, kas mõni krüptograafiakood on rikutud, ja veenduge, et see oleks parandatud.
  13. Kontrollimaks, kas äriloogika juurutamine on turvaline ja mitte haavatav väljastpoolt tulevate rünnakute suhtes.
  14. Failisüsteemi interaktsioonide analüüsimiseks määrake kõik haavatavused ja parandage need probleemid.
  15. Protokollikäsitlejate valideerimiseks proovitakse näiteks rakenduse vaikesihtlehte uuesti seadistada pahatahtliku iframe'i abil.
  16. Kliendi pahatahtlike süstide eest kaitsmiseks.
  17. Kaitsmiseks pahatahtlike käitussüstide eest.
  18. Failide vahemällu uurimiseks ja pahatahtlike võimaluste vältimiseks.
  19. Andmete ebaturvalise salvestamise vältimiseks rakenduste klaviatuuri vahemälus.
  20. Küpsiste uurimiseks ja igasuguste pahatahtlike tegude vältimiseks.
  21. Pakkuda regulaarselt andmekaitse analüüsi auditeid.
  22. Uurige kohandatud loodud faile ja vältige kohandatud loodud failide pahatahtlikke tegusid.
  23. Vältimaks puhvri ületäitumist ja mälu rikkumise juhtumeid.
  24. Erinevate andmevoogude analüüsimiseks ja nende võimalike haavatavuste vältimiseks.

Kasutatavuse testimise juhtumid

Mobiilirakenduse kasutatavuse testimise protsess viiakse läbi nii, et sellel oleks kiire ja lihtne etapirakendus, millel oleks vähem funktsionaalsust kui aeglasel ja keerulisel, paljude funktsioonidega rakendusel. Peamine eesmärk on tagada, et meil oleks lõpuks hõlpsasti kasutatavad, intuitiivsed ja sarnased tööstuses aktsepteeritud liidesed, mida kasutatakse laialdaselt.

  1. Tagamaks, et nupud oleksid nõutava suurusega ja sobivad suurtele sõrmedele.
  2. Nuppude paigutamise tagamiseks ekraani samasse sektsiooni, et vältida segadust lõppkasutajatele.
  3. Ikoonide loomulikkuse ja rakendusega vastavuse tagamiseks.
  4. Tagamaks, et sama funktsiooniga nuppudel oleks sama värv.
  5. Tagamaks, et puudutatava suumimise ja suumimise võimaluste valideerimine peaks olema lubatud.
  6. Selle tagamiseks, et klaviatuuri sisestust saaks asjakohasel viisil minimeerida.
  7. Selle tagamiseks, et rakendus pakuks vale üksuse puudutamisel vastuvõetava aja jooksul meetodit toimingu tagasitulekuks või tagasivõtmiseks.
  8. Tagamaks, et kontekstimenüüd ei oleks ülekoormatud, kuna neid tuleb kiiresti kasutada.
  9. Tagamaks, et tekst oleks lihtne ja selge, et see oleks kasutajatele nähtav.
  10. Tagamaks, et lühikesed laused ja lõik on lõpptarbijatele loetavad.
  11. Tagamaks, et fondi suurus oleks piisavalt loetav ja mitte liiga suur ega liiga väike.
  12. Rakenduse valideerimiseks palutakse kasutajal alati, kui kasutaja hakkab alla laadima suurt hulka andmeid, mis ei pruugi rakenduse jõudlust soodustada.
  13. Selle kinnitamiseks, et rakendus suletakse erinevatest olekutest, ja kontrollige, kas see avaneb uuesti samas olekus.
  14. Tagamaks, et kõik stringid teisendatakse sobivates keeltes, kui keelte tõlkimise võimalus on saadaval.
  15. Tagamaks, et rakenduse üksused on alati sünkroonitud vastavalt kasutaja toimingutele.
  16. Tagamaks, et lõppkasutajale antakse kasutusjuhend, mis aitab lõppkasutajal mõista rakendust ja seda hallata, kes ei pruugi olla kursis rakenduse menetlusega

Kasutatavuse testimist teostavad tavaliselt käsitsi kasutajad, kuna ainult inimesed saavad aru teiste kasutajate tundlikkusest ja mugavusest.

Ühilduvuse testimise juhtumid

Mobiilseadmete ühilduvuse testimine viiakse läbi tagamaks, et kuna mobiilseadmetel on erinev suurus, eraldusvõime, ekraan, versioon ja riistvara, tuleks rakendust testida kõigis seadmetes, et tagada rakenduse soovitud toimimine.

Järgmised on ühilduvuse testimise silmapaistvamad valdkonnad.

  1. Selle kinnitamiseks, et rakenduse kasutajaliides vastab seadme ekraanisuurusele, pole ükski tekst / juhtelement osaliselt nähtamatu või ligipääsmatu.
  2. Veendumaks, et tekst oleks kõigile rakenduse kasutajatele loetav.
  3. Selle tagamiseks, et kõne / häire funktsioon oleks lubatud, kui rakendus töötab. Rakendus minimeeritakse või peatatakse kõne korral ja seejärel jätkatakse rakendust alati, kui kõne peatub.

Taastatavuse testimise testjuhtumid

  1. Kokkupõrke taastamine ja tehingute katkestused
  2. Rakenduse tõhusa taastamise olukorra kinnitamine pärast ootamatuid katkestuse / krahhi stsenaariume.
  3. Kontrollimine, kuidas rakendus elektrikatkestuse ajal tehinguid käsitseb (st aku saab tühjaks või seade äkitselt käsitsi välja lülitub)
  4. Protsessi valideerimine, kus ühendus on peatatud, peab süsteem taastatud andmete taastamiseks, mida peatatud ühendus otseselt mõjutab.

Tähtis kontrollnimekiri

  1. Installimise testimine (kas rakendust saab installida mõistliku aja jooksul ja nõutava kriteeriumiga)
  2. Desinstallimise testimine (kas rakendust saab desinstallida mõistliku aja jooksul ja nõutava kriteeriumiga)
  3. Võrgutestide juhtumid (kontrollimine, kas võrk töötab nõutava koormuse korral või mitte, kas võrk suudab testiprotseduuride ajal toetada kõiki vajalikke rakendusi)
  4. Märkige märkeruudud võtmed
  5. Kontrollige rakenduse avakuva
  6. Jätkatakse klaviatuuri sisestamist katkestuste ajal ja muul ajal, näiteks võrguprobleemide korral
  7. Meetodid, mis käsitlevad rakendusest väljumist
  8. Laadija efekt, kui rakendus töötab taustal
  9. Madal aku ja kõrge jõudlusega nõudlus
  10. Aku eemaldamine rakenduse käivitamise ajal
  11. Aku tarbimine rakenduse järgi
  12. Kontrollige rakenduse kõrvaltoimeid