Sissejuhatus käsitsi testimisse

Käsitsi testimine on tarkvara testimise vorm, kus testid viiakse läbi käsitsi, ilma automatiseerimisinstrumente kasutamata. Kõigist testitüüpidest on kõige primitiivsem käsitsi testimine ja see aitab kasutajatel tarkvarasüsteemis vigu avastada. Enne testimise automatiseerimist tuleb kõiki värskeid rakendusi käsitsi testida. Selle testimisega on vaja rohkem vaeva näha, kuid seda on vaja automatiseerimise teostatavuse kontrollimiseks. Testija koostab katseplaani paberi, mis kirjeldab tarkvararakenduse testimise kõikehõlmavat ja süsteemset lähenemist. Testi esinemisjuhud hõlmavad peaaegu 100% tarkvara juurutamisest. See on aeganõudev test, kuna käsitsi tehtavad testid hõlmavad kõiki testijuhtumeid. Tegelike ja soovitud tulemuste eristamisel on puudusi. Seejärel parandab tarkvaraarendaja puudused. Vigade parandamise tagamiseks hindab testija defekte. Selle testimise eesmärk on veenduda, et rakendusel pole defekte ja et vead töötaksid hästi, et pakkuda klientidele suurepärase kvaliteediga tööd.

Tarkvara käsitsi testimine

Inimesed saavad tarkvara testida kahel viisil käsitsi ja automaatselt arvuti abil. Igal tehnikal on oma plussid ja miinused, kuid selle põhieesmärk on säilitada tarkvara kvaliteet. Selles artiklis keskendume käsitsi katsetamisele.

Käsitsi testimise tüübid

Allpool on toodud 6 manuaalse testimise tüüpi:

1. Valge kasti testimine

  • Tarkvara testimisstrateegia hõlmab musta kasti ja valge kasti testimist. Siin käsitleme nn valge kasti katseid, mida nimetatakse ka “klaaskarbi” testideks, konstruktsioonikatseid, samuti selge kasti ja avatud kasti katseid. See testib sisemist kodeerimist ja tarkvara infrastruktuuri, et kontrollida eelmääratud sisendeid eeldatavatel ja soovitud väljunditel. See põhineb rakenduse sisemisel toimimisel ja keerleb sisemise raamistiku testimise ümber.
  • Selliseks testimiseks vajalikud programmeerimisvõimed on testimisnäidete kujundamine. Valge kasti testimise peamine eesmärk on keskenduda sisendite ja väljundite voole tarkvara kaudu ning tugevdada tarkvara ohutust. Süsteemi sisemise vaate tõttu kasutatakse sõna “valge kast”. Valge kasti tühjendamine või nimi näitab suutlikkust vaadata tarkvara välist kesta.

2. Musta kasti testimine

  • Musta kasti testimine on tarkvara testimismeetod, mis uurib tarkvara funktsionaalsust, uurimata selle sisemist ülesehitust ega kodeeringut. Musta kasti testimise peamine põhjus on kliendi nimetatud vajaduste täpsustamine. Seda tehnikat kasutatakse funktsiooni valimiseks ja sisendväärtuse pakkumiseks, et kontrollida, kas funktsioon pakub eeldatavat jõudlust või mitte.
  • Kui funktsioon annab õige väljundi, testitakse seda, kui muidu, siis see ebaõnnestub. Testimeeskond teatab tulemustest ja testib seejärel järgmist ülesannet. Lõppude lõpuks on funktsioone testitud, kui ilmnevad tõsised probleemid, tagastatakse arendusmeeskond parandamiseks.

3. Integratsiooni testimine

  • Integratsiooni testimine on teine ​​etapp pärast tarkvara testimismeetodi üksuse testimist. Selle testi käigus hinnatakse rühmas ühikuid või üksikuid tarkvarakomponente. Integreerimistesti tase keskendub puuduste paljastamisele, kui osad või üksused interakteeruvad.
  • Üksuse testimisel kasutatakse testmooduleid, mis ühendatakse ja testitakse integratsioonitestide ajal. Tarkvara on loodud paljude tarkvarakomponentide abil, mille on kirjutanud erinevad programmeerijad või kodeerijad. Integreerimistestide eesmärk on kontrollida, kas kõigi moodulite vaheline suhtlus on korrektne.

4. Vastuvõtu testimine

  • Vastuvõtutestid on ametlikud testid, mis põhinevad kasutajate nõudmistel ja funktsioonide käsitsemisel. See määrab, kas tarkvara vastab kliendi konkreetsetele nõudmistele või mitte. Seda tehakse omamoodi Black Boxi testina, kus süsteemi aktsepteerimise testis osaleb vajalik arv kliente. See on tarkvara testimise neljas ja viimane tase.
  • Kuid endiselt on väiksemaid vigu, et tuvastada, millal süsteem on praeguses stsenaariumis, mida lõppkasutaja kasutab. Tarkvara on nüüd läbinud kolm etappi (üksuse testimine, integratsiooni testimine ja süsteemi testimine). Kui kehtivad muutunud nõuded ja neid ei saa projekti kasvu ajal arendusmeeskonnale tõhusalt edastada.

5. Üksuse testimine

  • Seadme testimine hõlmab iga tarkvaraüksuse või elemendi kontrollimist. See on esimene tarkvara testimise tase. Ühiktestide eesmärk on ühikuelemendi efektiivsuse valideerimine. Seade on arvutiskeemi üks testkomponent ja seda on testitud rakendustarkvara väljatöötamise etapis. Selle testiga kontrollitakse eraldatud koodi õigsust. Üks funktsioon või rakenduskood on ühiku element.
  • Testimismeetod Valge kast, mida disainerid kasutasid ühiku testimiseks. Ühiktestid on testide esimese taseme tase, mis viiakse läbi enne lisamist ja muud testikontsentratsioonid katsetaseme struktuuris. Testimismeetodis kasutatakse moodulite testimisel abiks mooduleid, mis vähendavad sõltuvust üksuse testimisraamidest, tugipostidest, draiveritest ja pilkeüksustest.

6. Süsteemi testimine

  • Süsteemi testimine hõlmab tarkvarasüsteemi täielikku integreerimist. Tarkvara integreerimine toimub tavaliselt arvutisüsteemi abil (iga tarkvara on ainult üks arvutisüsteemi komponent). Tarkvara luuakse ühikutes ja seejärel liidestega, et toota täielik arvutisüsteem koos muu tarkvara ja riistvaraga. Teisisõnu, süsteem koosneb tarkvararühmast mitmesuguste funktsioonide täitmiseks, kuid tarkvara üksi ei suuda seda ülesannet täita.
  • Süsteemi testimine on erinevat tüüpi katsetuste jada manustatud tarkvara arvutisüsteemi täieliku toimimise nõudmiste läbiviimiseks ja testimiseks. Süsteemi testimist testitakse Black Boxis, kuna see hõlmab tarkvara testimist väliselt. Väiksemate defektide testimisel järgitakse kasutaja vaatenurka.

Kuidas käsitsi testimist sooritada?

Lugege projekti dokumentatsiooni / juhenditarkvara ja mõistke seda. Uurige ka testrakendust (AUT), kui see on saadaval. Testdokumentide kavandid, mis hõlmavad kõiki dokumenteerimisnõudeid. Kontrollige ja viige meeskonna juhtkond, kliendi testijuhtumid (vastavalt vajadusele) Kui vead on parandatud, käivitage ebaõnnestunud testi esinemisjuhud uuesti, et kinnitada nende läbimist. Musta kasti testimist ja valge kasti testimist kasutatakse kõigi katsejuhtumite käsitsi täitmiseks.

Erinevused käsitsi ja automaatika testimisel

Allpool toodud punktides selgitatakse manuaalset ja automatiseeritud testimist:

  • Automaatikatestimine hõlmab testimisvahendite kasutamist. Manuaalne testimine vajab testimiseks inimeste sekkumist. Kui käsitsi testimine nõuab kvalifitseeritud tööjõudu, pikka aega ja kulusid.
  • Automaatika testimine säästab aega, kulusid ja tööjõudu. Salvestamise korral on automatiseeritud testkomplekti kasutamine lihtsam.
    Mõned katsetüübid, näiteks ad hoc ja ahvide testimine, sobivad rohkem käsitsi täitmiseks ja kõiki taotlusi saab testida käsitsi. Automatiseeritud teste soovitatakse kasutada ainult stabiilsete süsteemide jaoks ja neid kasutatakse peamiselt regressioontestide jaoks
  • Automatiseerimise testimiseks kasutatavat automatiseerimistarkvara kasutatakse igava osa jaoks samade testimisnäidete kordamiseks ikka ja jälle. Korduvaks ja igavaks manuaalseks testimiseks võib saada.

Eelised ja puudused

Allpool on käsitsi testimise plussid ja miinused:

Eelised

• Musta kasti meetod ei vaja programmeerimisest arusaamist.
• Seda kasutatakse dünaamiliselt muutuvate GUI-kujunduste testimiseks.
• Tõelise kasutajana suhtlevad testijad tarkvaraga, et leida kasutatavust ja kasutajaliidese probleeme.
• See tagab 100% veavaba tarkvara olemasolu.
• Uus kasutaja saab õppida väga lihtsalt

Puuduseks

• Vaja on palju inimressursse.
• Väljundi leidmine võtab rohkem aega.
• Testid põhinevad nende teadmistel ja teadmistel. Puuduvad tõendid selle kohta, et kõiki ülesandeid kaeti või ei kaeta.
• Testide juhtumeid ei saa uuesti kasutada. Vajadus iga värske tarkvara järele, et luua erinevad testnäited.
• Kuna kaks meeskonda teevad koostööd, võib teineteise kavatsustest olla mõnikord raske aru saada, nad võivad protsessi eksitada.

Tööriistad käsitsi testimise teostamiseks

Nüüd näeme allpool käsitsi testimise tööriistu:

  • Seleen
  • Appium
  • TestLink
  • Postiljon
  • Jmeter

Millal testida käsitsi?

Manuaalne testimine nõuab palju pingutusi. Lihtne on öelda lihtsalt „laseme libiseda“ või „laseme automatiseerida“. Tõde on aga see, et tarkvara on hädavajalik, kuna automatiseeritud testimine ei saa kõike hõlmata. Lõppude lõpuks kasutavad inimesed teie tarkvara, nii et inimesed peaksid teie tarkvara testimises osalema. Manuaalsed testid on tegelike kasutatavusprobleemide tuvastamiseks ja parandamiseks tõenäolisemad kui automaatne testimine. See muudab testri paindlikuks ja võimaldab proovida mitmesuguseid asju lennult. Automatiseeritud testimist ei tohiks pidada kahjumlikuks. Automatiseeritud testimine pakub oma eeliseid ja väärtust valdkondades, kus käsitsi testimist ei tehta. Kuid veel ühe artikli jaoks salvestame selle.

Järeldus

Ehkki vaja on palju töökohti, on vaja kõrgetasemelise kliendikogemuse ja kvaliteedi tagamiseks käsitsi testimist. Inimese testija leiab alati asju, mida ei saa automaatselt testida. Tõhusa käsitsi testimise võti sisaldab teadmisi tarkvaranõuete kohta, suurepäraste testimisjuhtude kirjutamist ja põhjalike veateadete logimist. Nii oleme selles artiklis näinud, mis on käsitsi testimine koos selle eeliste ja puudustega.

Soovitatavad artiklid

See on olnud juhend käsitsi testimiseks. Siin käsitleme tüüpe, tööriistu, erinevusi käsitsi ja automaatika testimisel, eeliseid ja puudusi. Lisateavet leiate ka meie antud artiklitest -

  1. Stabiilsuse testimine
  2. Turvalisuse testimine
  3. GUI testimine
  4. Staatiline testimine
  5. 8 Oluline ülesanne testiplaani malli kirjutamine

Kategooria:

Tarkvaraarendus