Mis on rakenduste testimine?

Mis on rakenduste testimine?

Rakenduse testimine on defineeritud kui tarkvara testimise tüüp, mis viiakse läbi skriptide kaudu, mille eesmärk on leida tarkvarast vigu. See käsitleb kogu rakenduse teste.

See aitab tõsta teie rakenduste kvaliteeti, vähendades samal ajal kulusid, maksimeerib ROI-d ja säästab arendusaega.

Tarkvaratehnikas saab rakenduste testimist teha erinevates kategooriates, nagu GUI, funktsionaalsus, andmebaas (taustaprogramm), koormustest jne.

Rakenduse testimise puhul hõlmavad testimise elutsüklid erinevaid faase, mis hõlmavad nõuete analüüsi, testi planeerimist, testi analüüsi, testi kavandamist, testi täitmist ja veateadet jne.

Need faasid jagunevad lühikeseks, korduvaks elutsükliks, mida iga rakendus järgib.

Kuidas rakendust testida?

Tarkvararakendustel ja toodetel on mitmeid variatsioone nii toetatavate funktsioonide kui ka rakendatavate protsesside osas. Seega tagab rakenduse testimine, et konkreetne programm või rakendus töötab korralikult.

Rakenduse testimise elutsükkel hõlmab nelja etappi.

• 1. etapp) Rakendusnõuetel põhinevad katseplaanid
• 2. etapp) Arendage käsitsi testjuhtumeid ja automatiseeritud testskripte
• 3. etapp) Rakenduse nõuete kinnitamiseks tehke funktsionaalseid teste
• 4. etapp) Käivitage koormustestid ja häälestage rakenduse jõudlust

Läbiviidavate testide tüüp sõltub testitava rakenduse tüübist. Rakenduse testimine on jagatud 3 segmenti.

• Veebirakenduste testimine
• Töölauarakenduste testimine
• Mobiilirakenduste testimine

Rakenduse testimine	Läbiviidud testimise tüübid
Veebirakenduste testimine	Funktsionaalne ja Jõudluse testimine Brauseriülene testimine Koormus- ja stressitestid Regressiooni- ja vastavustest Vastuvõtu test Beetatestimine Uurimis- ja suitsutestimine Mitmekeelne tugi ja ühilduvuse testimine
Töölauarakenduste testimine	UI testimine Kasutatavuse testimine Jõudluse testimine Ühilduvuse testimine (tarkvara/riistvara) Funktsionaalne testimine Turvalisuse testimine
Mobiilirakenduste testimine	UI testimine Reeglipõhine testimine Regressioonitestimine Funktsionaalne testimine Turvalisuse testimine

Veebi-, laua- ja mobiilirakenduste testimise võrdlus

Need kolm segmenti jagavad elutsüklit, kuid erinevad järsult selle poolest, mis tegelikult katkeb. Teadmine, kuhu risk koondub, annab aimu, kuhu testimiseelarvet kulutada.

Erinevuspunkt	võrk	lauaarvuti	mobiilne
Jookseb edasi	Brauser võrgu kaudu	Üks paigaldatud masin	Mobiiltelefon või tahvelarvuti
Peamine muutuja	Brauser ja versioon	Operatingsüsteem ja riistvara	Seade, operatsioonisüsteemi versioon ja ekraani suurus
Võrgusõltuvus	Alati ühendatud	Sageli võrguühenduseta	Vahelduv ja peab kaotuse üle elama
Suurim risk	Brauseriteülene renderdamine ja laadimine	Paigaldamine ja ühilduvus	Seadmetevaheline killustatus
Katkestuste käsitlemine	Harva asjakohane	Harva asjakohane	Kõned, märguanded ja aku tühi
Uuenda teed	Serveripoolne, kohene kõigile	Kasutaja installib paranduse	Rakenduste poe ülevaade, etapiviisiline kasutuselevõtt

Mobiiltelefonidel on kõige rohkem kontrollimatuid muutujaid, mistõttu käsitletakse neid sellel lehel hiljem eraldi.

Rakenduste testimise metoodikad

Testimismetoodika on struktureeritud viis tarkvararakenduse täielikuks testimiseks. Korrastamata ja halb testimismetoodika võib viia ebastabiilse tooteni.

Testimiseks on kolm võimalust.

• Must Box Testimine
• Valge Box Testimine
• Hall Box Testimine

Must Box Testimine

Must Box Testimine testimiseks kasutatakse tavaliselt tehnikat Funktsionaalne testimine, mittefunktsionaalne testimine, ja regressioontestimine. Musta kasti testimisel kasutatavad strateegiad on

• Samaväärsuse klassi testimine
• Piirväärtuse testimine
• Otsustabelite testimine
• Olekute üleminekutabelid

Valge Box Testimine

Valge kasti testimine kasutatakse tavaliselt tarkvarakoodi testimiseks, et kontrollida sisemisi turvaauke, katkiseid või halvasti struktureeritud teid, tingimuslike tsüklite funktsionaalsust jne. Valge kasti testimisel kasutatavad strateegiad on

• Code Katvuse analüüs
• Tee katvus

Hall Box Testimine

See testimistehnika on kombinatsioon mõlemast mustast Box Testimine ja valge kasti testimine. Seda tehakse selleks, et leida Defektid põhinevad ebaõigel struktuuril või rakendusel.

Rakenduse testimise katseplaan

. Katseplaan dokument on tuletatud Tootest Descriptioon, tarkvaranõuete spetsifikatsioon SRS või kasutusjuhtumi dokumendid. Testi keskmes on see, mida testida, kuidas testida, millal testida ja kes testib. Testiplaani dokumenti kasutatakse suhtlusmeediumina testimeeskonna ja testijuhtide vahel.

Rakenduse testimise standardne testiplaan peaks määratlema järgmised funktsioonid;

• Määratlege testimise ulatus
• Määrake testimise eesmärk
• Lähenemisviis tegevuse testimiseks
• Testimise ajakava
• Bug trackuningas ja aruandlus

Rakenduste testimise sisenemis- ja väljumiskriteeriumid

Testiplaanis on parimate tavade kohaselt loetletud ametlikud sisenemis- ja väljumiskriteeriumid, kuid need tasub selgelt välja tuua. Ilma nendeta algab testimisfaas kas ebastabiilse järguga või triivib edasi ilma kokkulepitud lõppjooneta.

Riiki sisenemise kriteeriumid peab olema täidetud enne täitmise alustamist.

• Nõuded ja tervisekindlustuse aruanne (SRS) vaadatakse üle ning määratakse kindlaks nende baasväärtused.
• Testiplaan ja testijuhtumid kirjutatakse ja kinnitatakse.
• Järk juurutatakse stabiilsesse testimiskeskkonda ja see läbib suitsutesti.
• Testiandmed ja vajalikud kontod või seadmed on saadaval.
• Defekt tracKingi tööriist on konfigureeritud ja meeskonnal on juurdepääs.

Väljumiskriteeriumid näitab, et etapp on oma eesmärgi täitnud.

• Kõik planeeritud testid viiakse läbi ja tulemused registreeritakse.
• Kriitilisi ega kõrge raskusastmega defekte pole jäänud lahendamata.
• Kokkulepitud nõuete täitmine on saavutatud.
• Ülejäänud vähemtähtsad defektid dokumenteeritakse ja ettevõte aktsepteerib neid.
• Testi kokkuvõtte aruanne on allkirjastatud.

Rakenduste testimise tööriistad

Rakenduste testimiseks on erinevaid testimistööriistu. Tööriistade valik sõltub sellest, millist tüüpi testimist soovite läbi viia. Erinevate platvormide jaoks on soovitatav kasutada erinevaid tööriistu. Rakenduste testimise tööriistad tagavad rakenduste jõudluse, kasutatavuse ja funktsionaalsuse erinevates seadmetes.

Siin on mõned neist.

• Selenium
• IBM Rational Functional Tester (RFT)
• LoadRunner (nüüd OpenText LoadRunner, varem HP ja Micro Focus)
• Apache JMeter

💡 Märkus: IBM Rational Robot, mis oli pikka aega RFT kõrval müügil, on turult eemaldatud. Praegu on Rational Functional Tester. IBM pakkumine, seega ei tohiks uusi projekte Roboti ümber planeerida.

Rakenduste testimise põhinäitajad

Testide läbiviimine tõestab aktiivsust, mitte efektiivsust. Väike mõõdikute kogum näitab, kas testimine leiab tegelikult defekte ja kas rakenduse väljalaskekvaliteet läheneb.

• Testi ulatus: Nõuete osakaal, millel on vähemalt üks kaardistatud testjuhtum. Madal katvus tähendab testimata käitumist, olenemata läbimise määrast.
• Defektide tihedus: Defektide suurus, tavaliselt tuhande koodirea või mooduli kohta. See osutab komponentidele, mis vajavad ümbertegemist, mitte rohkem testimist.
• Defekti leke: Tootmises leitud defektide jagatuna leitud defektide koguarvuga. Kasvav leke on selgeim märk sellest, et väljalaskeeelses testimises on midagi puudu.
• Defektide eemaldamise efektiivsus: Enne väljaandmist leitud defektide osakaal kõigist defektidest. Levinud eesmärk on näitaja üle üheksakümne protsendi.
• Testi täitmiskiirus: Juhtumid jooksevad planeeritud juhtumite vastu tracked tsükli kohta, seega libisemine on nähtav varakult, mitte väljumisväravas.

TracJälgi trendi, mitte üksikut näitu. Üks tsükkel eraldi öeldes ütleb väga vähe.

Rakenduste testimise parimate tavade testimine

Rakenduse testimiseks õige strateegia valimine on garanteeritud viis rakenduse defektide tuvastamiseks. Seega on äärmiselt oluline, et kvaliteedikontrolli meeskond järgiks standardset protsessi, et tuvastada rohkem vigu ja vähem ajaga.

Rakenduse testimiseks on mõned parimad tavad

• Määratlege funktsionaalsed spetsifikatsioonid
• Revülevaated ja ülevaatused
• Ametlikud sisenemise ja lahkumise kriteeriumid
• Funktsionaalsete testide variatsioonid
• Mitme platvormi testimine
• Automatiseeritud testi täitmine

Rakenduste testimise väljakutsed

Rakenduse testimisel võib testija kokku puutuda paljude väljakutsetega

• Probleemid tuvastatakse ainult siis, kui kasutaja helistab
• Suutmatus ette näha muutuste mõju
• Puudub nähtavus rakenduse ja töövigade kohta
• Aega võttev

Mobiilirakenduste testimine

Nagu veebirakenduste testimine, mobiilne Rakenduste testimine põhineb samuti samal testimisstrateegial ja -metoodikal. Erinevus võib seisneda testimiseks kasutatavates tööriistades, mõned levinumad mobiilirakenduste testimise tööriistad on Appium, TestComplete, Robotiumja Espresso.

Mobiilirakenduste tüübid jagunevad kolmeks osaks

• Veebirakendus – kasutajad pääsevad sellele juurde võrgu, näiteks Interneti või sisevõrgu kaudu
• Native Application- See on välja töötatud konkreetse platvormi jaoks ja installitud arvutiseadmesse
• Hübriidrakendus – see ühendab endas nii veebi- kui ka natiivrakenduste elemente, näiteks Facebook.

Enamiku mobiiliplatvormide jaoks saate kasutada lihtsat CSS-i, HTML-i, JS-i jne.

Mobiilirakenduste testimise katsejuhtumite näidised

Täielik mobiilse testimise rakendusstrateegia sisaldab seadme ja võrgu infrastruktuuri, sihtseadmete valikut ning käsitsi ja automaatse testimise tööriistade tõhusat kombinatsiooni, mis hõlmab mõlemat. mittefunktsionaalne ja funktsionaalne testimine.

Mobiilirakenduse puhul on testitavad asjad

• paigaldamine
• OTA
• Wi-Fi
• Data kaabel
• Bluetooth
• Desinstallimine
• Rakenduse logo
• Splash
• Vähe mälu
• Visuaalne tagasiside
• Välju rakendusest
• Rakenduse käivitamine/taaskäivitamine

Mobiilseadmete testimise väljakutsed

Mobiilikasutajate ja -seadmete arvu suurenemisega muutub mobiilirakenduse testimine üha keerukamaks. Mobiilirakenduse testimine erineb oluliselt lauaarvutipõhise veebirakenduse testimisest. Mobiilirakenduse testimise käigus esinevad levinumad väljakutsed on järgmised:

• Põhjalik testi katvus
• Killustumise haldamine (erinevad OS-i versioonid, protsessor, mälu)
• Katseplaani puudumine
• Aja surve
• Füüsiliste seadmete puudumine
• Platvormi ja OS-i mitmekesisus

KKK