Phenquestions
Üksuse testimine
Üksuse testimine on üksikute funktsioonide, klasside või moodulite testimine iseseisvalt kui täielikult töötava tarkvara testimine. Kasutades üksuse testimise raamistikku, saab programmeerija luua sisendi ja eeldatava väljundiga testjuhtumeid. Kui suurte tarkvaraprojektide jaoks on sadu, tuhandeid või kümneid tuhandeid ühikute testimisjuhtumeid, tagab see, et kõik üksused töötavad vastavalt ootustele, kui jätkate koodi muutmist. Testijuhtumeid omava üksuse vahetamisel tuleks uurida selle mooduli testijuhte ja teha kindlaks, kas on vaja uusi testijuhtumeid, väljund on muutunud või saab praegused testjuhtumid eemaldada, kuna need pole enam asjakohased. Suure hulga ühikutestide loomine on lihtsaim viis tarkvarakoodibaasi katsejuhtumite katmiseks, kuid see ei taga, et lõpptoode töötab ootuspäraselt süsteemina.
Funktsionaalne testimine
Funktsionaalne testimine on testimise kõige levinum vorm. Kui inimesed viitavad tarkvara testimisele ilma palju üksikasju, tähendavad nad sageli funktsionaalset testimist. Funktsionaalne testimine kontrollib tarkvara töö põhifunktsioone ootuspäraselt. Kõigi testitavate funktsionaalsete testijuhtude kirjeldamiseks võiks kirjutada testimiskava, mis vastab tarkvara peamistele omadustele ja võimalustele. Esmane funktsionaalsuse testimine onõnnelik tee ” testimine, mis ei püüa tarkvara rikkuda ega kasutada seda üheski väljakutsuvas stsenaariumis. See peaks olema tarkvarade absoluutne miinimum mis tahes tarkvaraprojekti jaoks.
Integratsiooni testimine
Pärast üksuste testimist ja funktsionaalset testimist võib olla mitu moodulit või kogu süsteem, mida pole veel tervikuna testitud. Või võib olla komponente, mis on suures osas sõltumatud, kuid mida kasutatakse aeg-ajalt koos. Iga kord, kui komponente või mooduleid testitakse iseseisvalt, kuid mitte tervikuna, tuleks integreerimiskatse teha, et valideerida komponendid toimiksid koos toimiva süsteemina vastavalt kasutaja nõuetele ja ootustele.
Stressitestimine
Mõelge stressitestidele, nagu katsetaksite kosmosesüstikut või lennukit. Mida tähendab oma tarkvara või süsteemi seadmine stressi alla? Stress pole midagi muud kui konkreetse tüübi intensiivne koormus, mis tõenäoliselt rikub teie süsteemi. See võib sarnaneda koormuse testimisega selles mõttes, et asetate oma süsteemi suure samaaegsesse olukorda, kus süsteemile pääsevad paljud kasutajad. Kuid süsteemi rõhutamine võib juhtuda ka teiste vektorite puhul. Näiteks püsivara käitamine riistvarakomponendil, kui riistvara on füüsiliselt rikutud ja töötab halvenenud režiimis. Stress on omane igat tüüpi tarkvarale ning süsteemide ja stressitestide kavandamisel tuleks kaaluda, millised looduslikud või ebaloomulikud põhjused võivad teie tarkvara või süsteemi kõige tõenäolisemalt stressida.
Koormuse testimine
Koormustestimine on teatud tüüpi stressitestimine, nagu eespool arutletud, kus automatiseeritakse suur hulk samaaegseid kasutajaühendusi ja juurdepääsu, et tekitada simulatsioon suure hulga teie tarkvarasüsteemile samal ajal juurde pääsevate autentsete kasutajate mõjust. Eesmärk on välja selgitada, mitu kasutajat saavad teie süsteemile korraga juurde pääseda, ilma et teie tarkvarasüsteem puruneks. Kui teie süsteem saab hõlpsasti hakkama 10 000 kasutaja tavapärase liiklusega, siis mis juhtub, kui teie veebisait või tarkvara läheb viirusesse ja kogub miljon kasutajat? Kas see on ootamatu „LOAD“ oma veebisaidi või süsteemi rikkumine? Koormuste testimine simuleerib seda, nii et olete rahul tulevase kasutajate kasvuga, sest teate, et teie süsteem saab suurenenud koormusega hakkama.
Jõudluse testimine
Kui tarkvara ei vasta nende jõudlusnõuetele, võivad inimesed olla täiesti pettunud ja meeleheitel. Jõudlus tähendab üldiselt seda, kui kiiresti saab olulisi funktsioone täita. Mida keerukamad ja dünaamilisemad funktsioonid süsteemis on saadaval, seda olulisemaks ja ilmsemaks muutub selle jõudluse testimine, võtame näiteks põhinäite, Windowsi või Linuxi operatsioonisüsteem. Operatsioonisüsteem on väga keeruline tarkvaratoode ja selle süsteemi jõudlustestide tegemine võib hõlmata selliste funktsioonide kiirust ja ajastamist nagu Bootup, rakenduse installimine, faili otsimine, arvutite käitamine GPU-l ja / või mõni muu miljoneid toiminguid, mida saab teha. Jõudluskontrolli juhtumite valimisel tuleks olla ettevaatlik, et tagada testitud oluliste ja tõenäoliselt talitlushäiretega toimivusfunktsioonide olemasolu.
Mastaapsuse testimine
Sülearvuti testimine on hea, kuid pole piisavalt hea, kui loote sotsiaalvõrgustikku, e-posti süsteemi või superarvuti tarkvara. Kui teie tarkvara on ette nähtud juurutamiseks 1000 serverisse, mis kõik toimivad ühtselt, siis ühes süsteemis kohapeal tehtav testimine ei paljasta vigu, mis ilmnevad tarkvara juurutamisel sadadel tuhandetel juhtudel. Tegelikkuses ei saa teie testimine tõenäoliselt enne tootmisse laskmist täies mahus töötada, kuna see oleks liiga kallis ja otstarbekas ehitada 1000 miljonit serverit maksev testisüsteem, mis maksab miljoneid dollareid. Seetõttu viiakse mastaapsuse testimine läbi mitme serveri, kuid tavaliselt mitte kogu tootmisserverite arv, et proovida paljusid defekte, mis võivad ilmneda, kui teie süsteeme kasutatakse suuremas infrastruktuuris.
Staatilise analüüsi testimine
Staatiline analüüs on testimine, mis tehakse tarkvarakoodi kontrollimisega, ilma et seda tegelikult käivitataks. Staatilise analüüsi tegemiseks kasutaksite tavaliselt tööriista, neid on palju, üks kuulus tööriist on Coverity. Staatilist analüüsi on enne tarkvara väljaandmist lihtne käivitada ja see võib teie koodist leida palju kvaliteediprobleeme, mida saab enne väljaandmist parandada. Leidub mäluvigu, andmetüüpide käitlemise vigu, nullkursori kõrvalekaldeid, initsialiseerimata muutujaid ja palju muud defekti. Sellistele keeltele nagu C ja C ++ on staatilisest analüüsist palju kasu, sest keeled pakuvad programmeerijatele suure jõu eest suurt vabadust, kuid see võib tekitada ka suuri vigu ja vigu, mida võib leida staatilise analüüsi testimise abil.
Vigade süstimise testimine
Mõningaid veatingimusi on väga raske simuleerida või käivitada, seetõttu saab tarkvara kavandada süsteemi või probleemi tõrke kunstlikuks sisestamiseks ilma looduslikult esineva defektita. Rikkesüstimise testimise eesmärk on näha, kuidas tarkvara nende ootamatute riketega toime tuleb. Kas see reageerib olukorrale graatsiliselt, kukub kokku või annab ootamatuid ja ettearvamatuid probleemseid tulemusi? Oletame näiteks, et meil on pangandussüsteem ja seal on moodul raha sisemiseks ülekandmiseks kontolt A kontole B. Seda ülekandetoimingut kutsutakse aga alles pärast seda, kui süsteem on enne ülekandetoimingule helistamist juba kontrollinud nende kontode olemasolu. Isegi kui eeldame, et mõlemad kontod on olemas, on ülekandetoimingul ebaõnnestumise juhtum, kus ühte sihtmärki või lähtekontot pole ja see võib põhjustada vea. Kuna tavaolukordades ei esine me seda viga kunagi sisendite eelkontrolli tõttu, siis süsteemi käitumise kontrollimiseks, kui ülekanne ebaõnnestub olematu konto tõttu, süstime võltsvea süsteemi, mis tagastab olematu konto ja testige, kuidas ülejäänud süsteem sellisel juhul reageerib. On väga oluline, et vea sissepritse kood on saadaval ainult testimise stsenaariumide korral ja seda ei avaldata tootmises, kus see võib tekitada kaose.
Mälu ületamise testimine
Selliste keelte nagu C või C ++ kasutamisel on programmeerijal suur vastutus otse mälu poole pöörduda ja see võib vigade tegemisel tarkvaras põhjustada vigu. Näiteks kui osuti on null ja viidatud, siis tarkvara jookseb kokku. Kui objektile eraldatakse mälu ja seejärel kopeeritakse stringi objekti mäluruumi, võib objektile viitamine põhjustada krahhi või isegi täpsustamata vale käitumise. Seetõttu on kriitiline kasutada tööriista, et proovida mälupääsuvigu vigadest tarkvara abil, mis kasutab selliseid keeli nagu C või C ++, millel võivad olla need võimalikud probleemid. Tööriistad, mis suudavad seda tüüpi testimist teha, on näiteks avatud lähtekoodiga Valgrind või omandatud tööriistad nagu PurifyPlus. Need tööriistad võivad päästa päeva, kui pole selge, miks tarkvara kokku jookseb või käitub valesti, ja osutada otse vea sisaldavas koodis olevale asukohale. Äge, eks?
Piiriüleste juhtumite testimine
Koodimisel on lihtne vigu teha, kui olete piiril. Näiteks panga automaat ütleb, et saate välja võtta maksimaalselt 300 dollarit. Kujutage ette, et kodeerija kirjutas selle nõude loomisel loomulikult järgmise koodi:
Kui (amt < 300)startWithdrawl ()
veel
tõrge („Te saate% s tagasi võtta”, amt);
Kas saate viga märgata? Kasutaja, kes üritab 300 dollarit välja võtta, saab vea, kuna see pole vähem kui 300 dollarit. See on viga. Seetõttu tehakse piiride testimine loomulikult. Nõuete piirid tagavad siis, et tarkvara toimib mõlemal pool piiri ja piiri korralikult.
Fuzzi testimine
Tarkvara sisendi kiire genereerimine võib toota võimalikult palju sisendikombinatsioone, isegi kui need sisendkombinatsioonid on täielik jama ja tegelik kasutaja ei pakuks neid kunagi. Seda tüüpi fuzz-testimine võib leida vigu ja turvaauke, mida muul viisil ei leitud, kuna sisendite ja stsenaariumide arv on kiiresti testitud ilma käsitsi testimisjuhtumite loomiseta.
Uurimuslik testimine
Sulgege silmad ja visualiseerige, mida tähendab sõna „Avasta”. Jälgite ja uurite süsteemi, et teada saada, kuidas see tõeliselt toimib. Kujutage ette, et saate uue laua tooli postimüügis ja sellel on 28 osa eraldi kilekottides ilma juhisteta. Peate uurima oma uut saabumist, et teada saada, kuidas see toimib ja kuidas see on kokku pandud. Selle vaimu abil saate saada uurimistestijaks. Teil puudub täpselt määratletud testjuhtumite testimise kava. Uurite ja uurite oma tarkvara, otsides asju, mis panevad teid ütlema suurepärase sõna: „HUVITAV!”. Pärast õppimist uurite edasi ja leiate võimalusi tarkvara purustamiseks, mida disainerid pole kunagi mõelnud, ja esitate seejärel aruande, milles on üksikasjalikult esitatud arvukad tarkvara halvad eeldused, vead ja riskid. Lisateavet selle kohta leiate raamatust nimega Explore It.
Tungimistestimine
Tarkvaraturvalisuse maailmas on penetratsiooni testimine üks peamisi testimisvahendeid. Kõigil süsteemidel, nii bioloogilistel, füüsikalistel kui ka tarkvaralistel süsteemidel, on piirid ja piirid. Need piirid on mõeldud süsteemi sisenemiseks ainult konkreetsetele sõnumitele, inimestele või komponentidele. Konkreetsemalt kaalume Interneti-pangasüsteemi, mis kasutab saidi sisestamiseks kasutaja autentimist. Kui saiti saab häkkida ja taustaprogrammi sisestada ilma korraliku autentimiseta, oleks see läbitungimine, mida tuleb kaitsta. Tungimiskatse eesmärk on teadaolevate ja eksperimentaalsete tehnikate abil tarkvarasüsteemi või veebisaidi tavapärasest turvaribast mööda minna. Tungimistestimine hõlmab sageli kõigi kuulavate pordide kontrollimist ja proovimist süsteemi siseneda avatud pordi kaudu. Muud levinud tehnikad hõlmavad SQL-i sisestamist või parooliga krakkimist.
Regressioonitestimine
Kui olete töötanud tarkvara, mis on sellel väljal juurutatud, on ülitähtis takistada vigade sissetoomist juba toiminud funktsionaalsustesse. Tarkvaraarenduse eesmärk on suurendada teie toote võimekust, tutvustada vigu või põhjustada vana funktsionaalsuse lõpetamine, mida nimetatakse regressiooniks. Regressioon on viga või defekt, mis võeti kasutusele siis, kui varem see funktsioon ootuspäraselt töötas. Miski ei saa teie tarkvara või kaubamärgi mainet rikkuda kiiremini kui regressioonivigade lisamine oma tarkvarasse ja tegelike kasutajate leidmine pärast vea leidmist.
Regressioonitestimise juhtumid ja testiplaanid peaksid olema üles ehitatud põhifunktsioonide ümber, mis peavad tööd jätkama, et tagada kasutajate hea kogemus teie rakendusega. Kõigil teie tarkvara põhifunktsioonidel, mida kasutajad eeldavad teatud viisil töötama, peaks olema regressioonitesti juhtum, mida saab käivitada, et takistada funktsionaalsuse purunemist uuel versioonil. See võib olla vahemikus 50-50 000 testimisjuhtu, mis hõlmavad teie tarkvara või rakenduse põhifunktsionaalsust.
Lähtekoodi poolitamise testimine
Tarkvaras tutvustati viga, kuid pole ilmne, millise versiooni versiooniga uus viga tutvustati. Kujutage ette, et viimasest teadaolevast ajast, kui tarkvara ilma veata töötas, oli 50 tarkvara toimingut kuni praeguseni, kui…
Lokaliseerimise testimine
Kujutage ette ilmastikurakendust, mis näitab teie asukoha hetke- ja prognoositavat ilma, samuti ilmaolude kirjeldust. Lokaliseerimistesti esimene osa on tagada õige keele, tähestiku ja tähemärkide korralik kuvamine, sõltuvalt kasutaja geograafilisest asukohast. Ühendkuningriigi rakendus peaks olema kuvatud inglise keeles ladina tähtedega; sama rakendus Hiinas peaks olema kuvatud hiina tähtedega hiina keeles. Keerukam lokaliseerimistestimine on tehtud, laiem geograafilistest asukohtadest pärit inimeste arv seondub rakendusega.
Juurdepääsetavuse testimine
Mõnedel meie kogukonna kodanikel on puue ja seetõttu võib neil olla probleeme loodava tarkvara kasutamisega, mistõttu tehakse juurdepääsetavuse testimine, et tagada puuetega elanikele endiselt juurdepääs süsteemi funktsionaalsusele. Näiteks kui eeldame, et 1% elanikkonnast on värvipime ja meie tarkvaraliides eeldab, et kasutajad saavad eristada punast ja rohelist, kuid need värvipimedad EI SAA vahet teha. Seetõttu on tarkvaraliideses tähenduse tähistamiseks lisaks värvile täiendavad vihjed. Lisaks värvipimeduse testimisele kaasatakse tarkvara juurdepääsetavuse testimisse ka muid stsenaariume, nagu täielik nägemispimedus, kurtus ja paljud teised stsenaariumid. Hea tarkvaratoode peaks olema juurdepääsetav maksimaalselt potentsiaalsetele kasutajatele.
Uuendamise testimine
Lihtsad rakendused telefonis, operatsioonisüsteemid nagu Ubuntu, Windows või Linux Mint ja tarkvara, mis käitab tuumaallveelaevu, vajavad sageli täiendamist. Uuendamise protsess ise võib tuua sisse vigu ja defekte, mida värskel installimisel ei eksisteeriks, kuna keskkonnaseisund oli erinev ja uue tarkvara vanale kohale toomise protsess oleks võinud vigu tuua. Võtame lihtsa näite: meil on sülearvuti, milles töötab Ubuntu 18.04 ja me tahame uuendada versioonile Ubuntu 20.04. See on opsüsteemi installimisel erinev protsess kui kõvaketta otsene puhastamine ja Ubuntu 20 installimine.04. Seetõttu ei pruugi see pärast tarkvara või mõne selle tuletatud funktsiooni installimist töötada 100% ootuspäraselt või sama mis tarkvara värskelt installimisel. Seega peaksime kõigepealt kaaluma värskenduse enda katsetamist paljude erinevate juhtumite ja stsenaariumite korral, et tagada värskenduse täielik toimimine. Ja siis peame kaaluma ka süsteemi tegeliku täiendamise testimist, et tarkvara oleks loodud ja toimiks ootuspäraselt. Me ei kordaks kõiki värskelt installitud süsteemi testijuhtumeid, mis oleks aja raiskamine, kuid mõtleme oma süsteemiga teadlikult hoolikalt läbi, mida VÕIB uuendamise ajal katkestada ja lisame strateegiliselt nende funktsioonide testjuhtumid.
Musta kasti ja valge kasti testimine
Must ja valge kast on vähem spetsiifilised katsemetoodikad ja rohkem kategooriatesse kuuluvate testide tüüpe. Põhimõtteliselt musta kasti testimine, mis eeldab, et testija ei tea tarkvara sisemisest toimimisest midagi, ning koostab testimiskava ja testjuhtumid, mis süsteemi funktsiooni kontrollimiseks vaatavad lihtsalt väljastpoolt. Valge kasti testimist teevad tarkvaraarhitektid, kes mõistavad tarkvarasüsteemi sisemist tööd ja kavandavad juhtumeid teadmisega, mis võiks, peaks, peaks ja tõenäoliselt puruneks. Nii musta kui valge kasti testimisel leitakse tõenäoliselt erinevat tüüpi defekte.
Blogid ja artiklid tarkvara testimise kohta
Tarkvaratestimine on dünaamiline valdkond ja paljud huvitavad väljaanded ja artiklid, mis värskendavad kogukonda tarkvaratestimisele mõtlemisel. Me kõik võime sellest teadmisest kasu saada. Siin on näide huvitavatest artiklitest erinevatest ajaveebiallikatest, mida võiksite jälgida:
- 7 nõuannet, mida enne nõueteta testimist järgida; http: // www.ajakirjade testimine.com /
- 60 parimat automaatika testimise tööriista: ülim nimekirja juhend; https: // testguild.com /
- Avatud lähtekoodiga andmebaaside testimise tööriistad; https: // www.pehmekõneajakiri.com /
- 100 protsendi ühiku testi katet pole piisavalt; https: // www.pulgakommid.com /
- Pehmed testid Google'is ja kuidas me neid leevendame; https: // testimine.googleblogi.com /
- Mis on regressioonitestimine? ; https: // test.io / ajaveeb /
- 27 parimat Chrome'i laiendust arendajatele 2020. aastal; https: // www.lambdatest.com /
- 5 peamist tarkvara testimise etappi, mida iga insener peaks tegema; https: // techbeacon.com /
Tooted tarkvara testimiseks
Suurema osa väärtuslikest testimisülesannetest saab automatiseerida, mistõttu ei tohiks olla üllatav, et tööriistade ja toodete kasutamine tarkvara kvaliteedi tagamise lugematute ülesannete täitmiseks on hea mõte. Allpool loetleme mõned olulised ja väga väärtuslikud tarkvaratestimise tarkvaratööriistad, mida saate uurida ja vaadata, kas need aitavad.
JUnit
Java-põhise tarkvara testimiseks pakub JUnit terviklikku testikomplekti Java-keskkonnasõbraliku koodi ühikute ja funktsionaalsete testide jaoks.
Seleen
Veebirakenduste testimiseks pakub Selenium võimalust veebibrauseritega interaktsioonide automatiseerimiseks, sealhulgas brauserite ühilduvuse testimiseks. See on veebitestimise automatiseerimise peamine testimise infrastruktuur.
Kurk
Käitumispõhine testimisraamistik võimaldab ärikasutajatel, tootejuhtidel ja arendajatel selgitada loodetavas keeles eeldatavat funktsionaalsust ja seejärel testkäikudel selle käitumise määratleda. See muudab loetavamad testjuhtumid ja selge kaardistamise eeldatava kasutaja funktsionaalsusega.
Puhastage
Leidke töötamise ajal mälulekked ja mäluprobleemid, käivitades oma tarkvara sisseehitatud seadmega Purify Plus, mis jälgib teie mälukasutust ja juhib tähelepanu vigadele koodis, mida pole ilma seadmeteta lihtne leida.
Valgrind
Avatud lähtekoodiga tööriistad, mis käivitavad teie tarkvara ja võimaldavad teil sellega suhelda, osutades samal ajal vigade aruandele kodeerimisvigadest, nagu mälulekked ja rikutud. Koosteprotsessi pole vaja kompileerida ega lisada, kuna Valgrindil on intelligentsust teie masinakoodi dünaamiliseks mõistmiseks ja instrumentide sujuvaks süstimiseks, et leida kodeerimisvead ja aidata teil oma koodi täiustada.
Katvus
Staatilise analüüsi tööriist, mis leiab teie tarkvarast kodeerimisvead juba enne koodi koostamist ja käivitamist. Coverity võib leida nii turvaauke, kodeerimiskonventsioonide rikkumisi kui ka vigu ja defekte, mida kompilaator ei leia. Leidub surnud kood, initsialiseerimata muutujad ja tuhandeid muid defektitüüpe. Enne tootmisse andmist on oluline oma kood staatilise analüüsiga puhastada.
JMeter
Java-põhistele arendajatele orienteeritud avatud lähtekoodiga raamistik jõudlustestimiseks, sellest ka J. Veebisaidi testimine on JMeteri üks peamisi kasutusjuhtumeid lisaks andmebaaside, meilisüsteemide ja paljude teiste serveripõhiste rakenduste jõudluskontrollile.
Metasploit
Turvalisuse ja levitamise testimiseks on Metasploit tuhandete funktsioonide ja võimalustega üldine raamistik. Kasutage suhtluskonsooli, et pääseda juurde eelkodeeritud ekspluateerimistele ja proovige oma rakenduse turvalisust kontrollida.
Tarkvara testimise akadeemiline uurimistöö
- Sheffieldi ülikooli testimise uurimisrühm
- Kentucky ülikooli tarkvara kontrollimise ja valideerimise labor
- Põhja-Dakota osariigi ülikooli tarkvara testimise uurimisrühm
- Süsteemi testimine Intelligent Lab; Tšehhi tehnikaülikool Praha
- NASA: Jon McBride tarkvara testimine ja uurimine (JSTAR)
- McMasteri ülikool; Tarkvara kvaliteedi uurimise labor
- Ontario tehnikaülikool; Tarkvara kvaliteedi uurimislabor
- Texase ülikool @ Dallas; STQA
Järeldus
Tarkvara roll ühiskonnas kasvab jätkuvalt ja samal ajal muutub maailma tarkvara keerukamaks. Maailma toimimiseks peavad meil olema meetodid ja strateegiad meie loodud tarkvara testimiseks ja valideerimiseks funktsioonide täitmiseks, mida see on ette nähtud. Iga keeruka tarkvarasüsteemi jaoks peaks olema paika pandud testimisstrateegia ja testimiskava, et jätkata tarkvara funktsionaalsuse valideerimist, kuna need muutuvad jätkuvalt paremaks ja tagavad selle funktsiooni.
