Phenquestions
Jedinstveno ispitivanje
Jedinstveno testiranje je testiranje provedeno na nekoj funkciji, klasi ili modulu neovisno od testiranja potpuno funkcionalnog softvera. Koristeći okvir za jedinstveno testiranje, programer može stvoriti test slučajeve s ulazom i očekivanim izlazom. Kada imate stotine, tisuće ili desetke tisuća jedinica testnih slučajeva za veliki softverski projekt osigurava da sve pojedinačne jedinice rade kako se očekuje dok nastavljate s promjenom koda. Prilikom promjene jedinice koja ima test slučajeve, treba proučiti test slučajeve za taj modul i utvrditi jesu li potrebni novi test slučajevi, je li se promijenio izlaz ili se trenutni test slučajevi mogu ukloniti kao više nevažni. Stvaranje velike količine jedinstvenih testova najlakši je način za postizanje velike pokrivenosti testnim slučajem za bazu softverskog koda, ali neće osigurati da konačni proizvod funkcionira kao sustav kako se očekuje.
Ispitivanje funkcionalnosti
Funkcionalno testiranje najčešći je oblik testiranja. Kad se ljudi pozivaju na testiranje softvera bez puno detalja, često misle na funkcionalno testiranje. Funkcionalnim testiranjem provjerit će se primarne funkcije softverskog rada kako se očekivalo. Mogao bi se napisati plan ispitivanja koji bi opisao sve funkcionalne ispitne slučajeve koji će se testirati, a koji odgovara glavnim značajkama i mogućnostima softvera. Primarno testiranje funkcionalnosti bit će „sretan put ” testiranje, koje ne pokušava razbiti softver ili ga koristiti u bilo kojim izazovnim scenarijima. Ovo bi trebao biti apsolutni minimum za testiranje bilo kojeg softverskog projekta.
Ispitivanje integracije
Nakon jediničnog testiranja i funkcionalnog ispitivanja, može postojati nekoliko modula ili cijeli sustav koji još nije testiran u cjelini. Ili možda postoje komponente koje su uglavnom neovisne, ali se povremeno koriste zajedno. Bilo kada vremenske komponente ili moduli testiraju se neovisno, ali ne kao cjelovit sustav, tada bi trebalo provesti integracijsko testiranje kako bi se potvrdilo funkcioniranje komponenata kao radni sustav u skladu sa zahtjevima i očekivanjima korisnika.
Ispitivanje naprezanja
Razmislite o testiranju otpornosti na stres kao da ispitujete svemirski brod ili avion. Što znači staviti svoj softver ili sustav pod “STRESS”? Stres nije ništa drugo nego intenzivno opterećenje određene vrste koje će najvjerojatnije slomiti vaš sustav. To bi moglo biti slično "Ispitivanju učitavanja" u smislu stavljanja vašeg sustava u visoku istovremenost s mnogim korisnicima koji pristupaju sustavu. Ali naglašavanje sustava moglo bi se dogoditi i na drugim vektorima. Na primjer, pokretanje firmvera na hardverskoj komponenti kada je hardver fizički oštećen i radi u pogoršanom načinu rada. Stres je jedinstven za sve vrste softvera, a sustavi i dizajniranje testova otpornosti na stres trebaju biti uzeti u obzir koji su prirodni ili neprirodni uzroci najvjerojatnije stres vašeg softvera ili sustava.
Ispitivanje opterećenja
Ispitivanje opterećenja specifična je vrsta stresnog testiranja, kao što je gore spomenuto, pri čemu se velik broj istovremenih korisničkih veza i pristupa automatizira kako bi se generirala simulacija učinka velikog broja autentičnih korisnika koji istovremeno pristupaju vašem softverskom sustavu. Cilj je otkriti koliko korisnika može istovremeno pristupiti vašem sustavu, a da vam se softverski sustav ne pokvari. Ako vaš sustav može lako podnijeti uobičajeni promet od 10.000 korisnika, što će se dogoditi ako vaše web mjesto ili softver postane viralan i prikupi milijun korisnika? Hoće li ovo biti neočekivano "OPTEREĆENJE" razbiti vaše web mjesto ili sustav? Testiranje opterećenja to će simulirati, tako da vam je ugodno buduće povećanje broja korisnika jer znate da vaš sustav može podnijeti povećano opterećenje.
Ispitivanje performansi
Ljudi mogu postati krajnje frustrirani i očajavati kad softver ne ispunjava njihove zahtjeve za izvedbu. Izvedba, općenito, znači koliko brzo se mogu dovršiti važne funkcije. Što su funkcije složenije i dinamičnije dostupne u sustavu, to važnije i ne očiglednije postaje testiranje njegovih performansi, uzmimo osnovni primjer, Windows ili Linux operativni sustav. Operativni sustav vrlo je složen softverski proizvod, a testiranje izvedbe na njegovom sustavu moglo bi uključivati brzinu i vremensko određivanje funkcija kao što je pokretanje, instaliranje aplikacije, traženje datoteke, pokretanje izračuna na GPU-u i / ili bilo koji drugi milijuni radnji koje se mogu izvršiti. Pri odabiru slučajeva ispitivanja performansi treba voditi računa kako bi se osigurale važne značajke performansi performansi i koje bi mogle kvariti.
Ispitivanje skalabilnosti
Testiranje na prijenosnom računalu je dobro, ali ne baš dovoljno dobro kada gradite društvenu mrežu, sustav e-pošte ili superračunarski softver. Kada je vaš softver namijenjen implementaciji na 1000 poslužitelja, a svi funkcioniraju složno, tada testiranje koje radite lokalno na jednom sustavu neće otkriti greške koje se javljaju kada se softver instalira "U mjerilu" na stotinama tisuća primjeraka. U stvarnosti, vaše testiranje vjerojatno nikada neće biti moguće izvesti u punoj mjeri prije puštanja u proizvodnju, jer bi bilo preskupo i nepraktično napraviti testni sustav s 1000 poslužitelja koji koštaju milijune dolara. Stoga se ispitivanje skalabilnosti vrši na više poslužitelja, ali obično ne na punom broju proizvodnih poslužitelja da bi se pokušalo otkriti neke nedostatke koji bi se mogli naći dok se vaši sustavi koriste na većoj infrastrukturi.
Ispitivanje statičke analize
Statička analiza je ispitivanje koje se vrši inspekcijom softverskog koda, a da se zapravo ne pokrene. Da biste radili statičku analizu, općenito biste koristili alat, ima ih mnogo, jedan poznati alat je Coverity. Statičku analizu lako je pokrenuti prije izdavanja softvera, a u vašem kodu mogu se pronaći mnogi problemi s kvalitetom koji se mogu popraviti prije izdavanja. Mogu se pronaći memorijske pogreške, pogreške pri rukovanju tipovima podataka, preusmjeravanja nultog pokazivača, neinicijalizirane varijable i mnogi drugi nedostaci. Jezici poput C i C ++ uvelike imaju koristi od statičke analize jer jezici pružaju veliku slobodu programerima u zamjenu za veliku snagu, ali to također može stvoriti velike greške i pogreške koje se mogu pronaći korištenjem testiranja statičke analize.
Ispitivanje ubrizgavanja kvarova
Neke je uvjete pogreške vrlo teško simulirati ili pokrenuti, stoga softver može biti dizajniran za umjetno ubrizgavanje problema ili kvara u sustav bez da se kvar prirodno pojavi. Svrha ispitivanja ubrizgavanja kvara je vidjeti kako softver rješava te neočekivane kvarove. Reagira li graciozno na situaciju, pada li ili daje neočekivane i nepredvidive problematične rezultate? Na primjer, recimo da imamo bankarski sustav i da postoji modul za interni prijenos sredstava s RAČUNA A na RAČUN B. Međutim, ova se operacija prijenosa poziva tek nakon što je sustav već potvrdio da ti računi postoje prije pozivanja operacije prijenosa. Iako pretpostavljamo da oba računa postoje, operacija prijenosa ima slučaj neuspjeha kada jedan ciljni ili izvorni račun ne postoji i da može dovesti do pogreške. Budući da u normalnim okolnostima ovu pogrešku nikad ne dobijemo zbog prethodnog testiranja ulaza, pa da bismo provjerili ponašanje sustava kada prijenos ne uspije zbog nepostojećeg računa, u sustav ubrizgavamo lažnu pogrešku koja vraća nepostojeći račun za prijenos i testirajte kako ostatak sustava reagira u tom slučaju. Vrlo je važno da je kôd ubrizgavanja kvara dostupan samo u scenarijima ispitivanja i ne pušta se u proizvodnju, gdje bi mogao stvoriti pustoš.
Ispitivanje prekoračenja memorije
Kada koristi jezike poput C ili C ++, programer ima veliku odgovornost izravno se obraćati memoriji, a to može uzrokovati fatalne pogreške u softveru ako se naprave pogreške. Na primjer, ako je pokazivač null i dereferenciran, softver će se srušiti. Ako se memorija dodijeli objektu, a zatim se niz kopira preko memorijskog prostora objekta, referenciranje objekta može uzrokovati pad ili čak neodređeno pogrešno ponašanje. Stoga je presudno koristiti alat za pokušaj hvatanja pogrešaka u pristupu memoriji u softveru koji koristi jezike poput C ili C ++, koji bi mogli imati ove potencijalne probleme. Alati koji mogu izvršiti ovu vrstu testiranja uključuju otvoreni izvor Valgrind ili zaštićene alate poput PurifyPlus. Ovi alati mogu uštedjeti dan kada nije jasno zašto se softver ruši ili se loše ponaša i izravno ukazuju na mjesto u kodu u kojem se nalazi programska pogreška. Super, zar ne?
Ispitivanje graničnih slučajeva
Lako je pogriješiti u kodiranju kad ste na onome što se naziva granicom. Na primjer, bankovni automat kaže da možete podići najviše 300 USD. Dakle, zamislite da je koder prilikom izrade ovog zahtjeva kod napisao prirodno sljedeći kod:
Ako (amt < 300)startWithdrawl ()
drugo
pogreška ("Možete povući% s", amt);
Možete li uočiti pogrešku? Korisnik koji pokuša podići 300 USD dobit će pogrešku jer nije manja od 300 USD. Ovo je greška. Stoga se granično ispitivanje vrši prirodno. Granice zahtjeva tada osiguravaju da softver na obje strane granice i granice funkcionira ispravno.
Fuzz testiranje
Brzo generiranje ulaza u softver može proizvesti što više mogućih kombinacija unosa, čak i ako su te kombinacije unosa potpuna glupost i stvarni ih korisnik nikada ne bi dostavio. Ova vrsta fuzz testiranja može pronaći programske pogreške i sigurnosne ranjivosti koje nisu pronađene drugim sredstvima zbog velikog broja ulaznih podataka i scenarija koji se brzo testiraju bez ručnog generiranja testnih slučajeva.
Istraživačko ispitivanje
Zatvorite oči i zamislite što znači riječ "Istražiti". Promatrate i ispitujete sustav kako biste otkrili kako on uistinu funkcionira. Zamislite da novu stolnu stolicu primate poštom, a ima 28 dijelova u zasebnim plastičnim vrećicama bez uputa. Morate istražiti svoj novi dolazak da biste shvatili kako funkcionira i kako je sastavljen. Ovim duhom možete postati istraživački ispitivač. Nećete imati dobro definiran plan ispitivanja slučajeva. Istražit ćete i istražiti svoj softver tražeći stvari zbog kojih izgovarate divnu riječ: „ZANIMLJIVO!". Nakon učenja, dalje istražujete i pronalazite načine da razbijete softver na koji dizajneri nikada nisu pomislili, a zatim dostavite izvješće u kojem se detaljno navode brojne loše pretpostavke, greške i rizici u softveru. Saznajte više o tome u knjizi pod nazivom Explore It.
Ispitivanje prodiranja
U svijetu softverske sigurnosti testiranje penetracije je jedno od primarnih sredstava testiranja. Svi sustavi, bilo biološki, fizički ili softverski, imaju granice i granice. Te granice trebaju omogućiti ulazak samo određenih poruka, ljudi ili komponenata u sustav. Konkretnije, razmotrimo sustav internetskog bankarstva koji koristi autentifikaciju korisnika za ulazak na web mjesto. Ako se web lokacija može hakirati i unijeti u pozadinu bez odgovarajuće provjere autentičnosti, to bi bio prodor, koji treba zaštititi od. Cilj testiranja penetracije je uporaba poznatih i eksperimentalnih tehnika za zaobilaženje normalne sigurnosne granice softverskog sustava ili web mjesta. Testiranje prodora često uključuje provjeru svih priključaka koji slušaju i pokušaj ulaska u sustav putem otvorenog priključka. Ostale uobičajene tehnike uključuju SQL ubrizgavanje ili probijanje lozinke.
Ispitivanje regresije
Nakon što imate radni softver koji je postavljen na terenu, presudno je spriječiti uvođenje bugova u funkcionalnost koja je već radila. Svrha razvoja softvera je povećati sposobnost vašeg proizvoda, uvesti programske pogreške ili uzrokovati prestanak rada starih funkcija, što se naziva REGRESIJA. Regresija je greška ili kvar koji je uveden kada je prethodno sposobnost radila kako se očekivalo. Ništa ne može pokvariti reputaciju vašeg softvera ili robne marke brže od uvođenja regresijskih programskih pogrešaka u vaš softver i ako stvarni korisnici pronađu te pogreške nakon izdanja.
Slučajevi regresijskog testiranja i planovi ispitivanja trebali bi se graditi oko osnovne funkcije koja treba nastaviti raditi kako bi korisnici imali dobro iskustvo s vašom aplikacijom. Sve osnovne funkcije vašeg softvera za koje korisnici očekuju da rade na određeni način trebale bi imati regresijski test koji se može izvršiti kako bi se spriječilo prekidanje funkcionalnosti novog izdanja. To može biti od 50 do 50 000 testnih slučajeva koji pokrivaju osnovnu funkcionalnost vašeg softvera ili aplikacije.
Ispitivanje presjeka izvornog koda
U softveru je uvedena greška, ali nije očito koja je verzija izdanja uvela novu grešku. Zamislite da je bilo 50 softverskih izvršavanja od posljednjeg poznatog vremena kada je softver radio bez programske pogreške, do sada kada ..
Ispitivanje lokalizacije
Zamislite vremensku aplikaciju koja prikazuje trenutno i projicirano vrijeme na vašem mjestu, kao i opis vremenskih uvjeta. Prvi dio testiranja lokalizacije je osigurati pravilno prikazivanje ispravnog jezika, abecede i znakova, ovisno o geolokaciji korisnika. Aplikacija u Ujedinjenom Kraljevstvu trebala bi biti prikazana na engleskom jeziku s latiničnim znakovima; ista aplikacija u Kini trebala bi biti prikazana kineskim znakovima na kineskom jeziku. Ako se izvrše detaljnija ispitivanja lokalizacije, širi spektar ljudi s različitih lokacija smjestit će se u aplikaciju.
Ispitivanje pristupačnosti
Neki od građana u našoj zajednici imaju invaliditet i stoga mogu imati problema s korištenjem softvera koji se kreira, pa se provodi testiranje pristupačnosti kako bi se osiguralo da populacije s invaliditetom i dalje mogu pristupiti funkcionalnosti sustava. Na primjer, ako pretpostavimo da je 1% stanovništva slijepo za boje, a naše softversko sučelje pretpostavlja da korisnici mogu razlikovati crvenu od zelene, ali te osobe koje slijepe za boje NE MOGU razlikovati. Stoga će dobro softversko sučelje imati dodatne znakove izvan boje koji ukazuju na značenje. Ostali scenariji, osim ispitivanja sljepoće u boji, također bi bili uključeni u testiranje pristupačnosti softvera, poput potpune vidne sljepoće, gluhoće i mnogih drugih scenarija. Dobar softverski proizvod trebao bi biti dostupan maksimalnom postotku potencijalnih korisnika.
Ispitivanje nadogradnje
Jednostavne aplikacije na telefonu, operativni sustavi kao što su Ubuntu, Windows ili Linux Mint i softver koji pokreće nuklearne podmornice trebaju česte nadogradnje. Sam postupak nadogradnje mogao bi uvesti programske pogreške i nedostatke koji ne bi postojali pri novoj instalaciji, jer je stanje okoliša bilo drugačije, a postupak uvođenja novog softvera povrh starog mogao je unijeti pogreške. Uzmimo jednostavan primjer, imamo prijenosno računalo sa Ubuntu 18.04, a želimo nadograditi na Ubuntu 20.04. Ovo je drugačiji postupak instaliranja operativnog sustava od izravnog čišćenja tvrdog diska i instaliranja Ubuntu-a 20.04. Stoga, nakon što je softver instaliran ili bilo koja od njegovih izvedenih funkcija, možda neće raditi 100% kako se očekivalo ili isto kao kad je softver bio svježe instaliran. Dakle, prvo bismo trebali razmotriti testiranje same nadogradnje u mnogim različitim slučajevima i scenarijima kako bismo osigurali da nadogradnja funkcionira do kraja. Zatim moramo razmotriti i testiranje stvarnog sustava nakon nadogradnje kako bismo osigurali da je softver postavljen i funkcionira kako se očekivalo. Ne bismo ponovili sve testne slučajeve svježe instaliranog sustava, što bi bilo gubljenje vremena, ali dobro ćemo razmisliti sa svojim znanjem o tome što MOŽEM razbiti tijekom nadogradnje i strateški dodati testne slučajeve za te funkcije.
Testiranje crne kutije i bijele kutije
Crna kutija i bijela kutija su manje specifične metodologije ispitivanja i više vrsta kategorizacije ispitivanja. U osnovi, testiranje crne kutije, koje pretpostavlja da ispitivač ne zna ništa o unutarnjem radu softvera i gradi plan ispitivanja i slučajeve koji sustav samo gledaju izvana da bi provjerili njegovu funkciju. Testiranje bijele kutije rade softverski arhitekti koji razumiju unutarnji rad softverskog sustava i dizajniraju slučajeve sa znanjem što bi moglo, što bi trebalo, a što bi vjerojatno moglo propasti. Testiranje crne i bijele kutije vjerojatno će otkriti različite vrste nedostataka.
Blogovi i članci o testiranju softvera
Testiranje softvera dinamično je područje, a mnoštvo zanimljivih publikacija i članaka koji ažuriraju zajednicu na najmodernija razmišljanja o testiranju softvera. Svi mi možemo imati koristi od ovog znanja. Evo primjera zanimljivih članaka iz različitih izvora na blogu koje biste možda željeli slijediti:
- 7 savjeta koje treba slijediti prije testiranja bez zahtjeva; http: // www.ispitivanje dnevnika.com /
- 60 najboljih alata za automatizaciju: Vodič za krajnji popis; https: // testguild.com /
- Alati za testiranje baze podataka otvorenog koda; https: // www.softvertestingmagazine.com /
- Pokrivenost testnim jedinicama od 100 posto nije dovoljna; https: // www.stickyminds.com /
- Laki testovi na Googleu i kako ih ublažavamo; https: // testiranje.googleblog.com /
- Što je regresijsko ispitivanje? ; https: // test.io / blog /
- 27 najboljih Chromeovih proširenja za programere u 2020 .; https: // www.lambdatest.com /
- 5 ključnih koraka za testiranje softvera koje bi svaki inženjer trebao obaviti; https: // techbeacon.com /
Proizvodi za testiranje softvera
Većina vrijednih ispitnih zadataka može se automatizirati, pa ne treba čuditi da je dobra upotreba alata i proizvoda za izvršavanje bezbrojnih zadataka osiguranja kvalitete softvera. U nastavku ćemo navesti neke važne i vrlo vrijedne softverske alate za testiranje softvera koje možete istražiti i vidjeti mogu li vam pomoći.
JUNIT
Za testiranje softvera temeljenog na Javi, JUnit nudi sveobuhvatan paket za jedinstveno i funkcionalno testiranje koda koji je prilagođen Java okruženju.
Selen
Za testiranje web aplikacija, Selenium pruža mogućnost automatizacije interakcija s web preglednicima, uključujući ispitivanje kompatibilnosti s više preglednika. Ovo je vodeća infrastruktura za testiranje za automatizaciju web testiranja.
Krastavac
Okvir testiranja vođen ponašanjem omogućuje poslovnim korisnicima, upraviteljima proizvoda i programerima da objasne očekivanu funkcionalnost na prirodnom jeziku, a zatim definiraju to ponašanje u testnim slučajevima. To čini čitljiviji test slučajevi i jasno mapiranje očekivane korisničke funkcionalnosti.
Pročistiti
Pronađite curenje memorije i oštećenja memorije u vrijeme izvođenja izvršavanjem softvera s ugrađenim Purify Plus instrumentom koji prati upotrebu vaše memorije i ukazuje na pogreške u kodu koje nije lako pronaći bez instrumentacije.
Valgrind
Alati otvorenog koda koji će izvršiti vaš softver i omogućiti vam interakciju s njim, istodobno ukazujući na izvješće o pogreškama pogrešaka kodiranja kao što su curenje memorije i oštećenja. Nema potrebe za ponovnom kompilacijom ili dodavanjem instrumenata u proces kompilacije, jer Valgrind ima inteligenciju da dinamički razumije vaš strojni kôd i neprimjetno ubrizga instrumentaciju kako bi pronašao pogreške u kodiranju i pomogao vam u poboljšanju koda.
Pokrivenost
Alat za statičku analizu koji će pronaći pogreške kodiranja u vašem softveru prije nego što uopće sastavite i pokrenete svoj kôd. Pokrivanje može pronaći sigurnosne ranjivosti, kršenja konvencija kodiranja, kao i greške i nedostatke koje vaš prevodilac neće pronaći. Može se pronaći mrtvi kod, neinicijalizirane varijable i tisuće drugih vrsta nedostataka. Vitalno je očistiti kod statičkom analizom prije puštanja u proizvodnju.
JMeter
Okvir otvorenog koda za testiranje performansi orijentiran na programere temeljene na Javi, pa otud i J u nazivu. Testiranje web stranica jedan je od glavnih slučajeva upotrebe JMetera uz testiranje performansi baza podataka, sustava pošte i mnogih drugih poslužiteljskih aplikacija.
Metasploit
Za ispitivanje sigurnosti i prodiranja, Metasploit je generički okvir s tisućama značajki i mogućnosti. Upotrijebite interakcijsku konzolu za pristup unaprijed kodiranim exploitima i pokušajte provjeriti sigurnost svoje aplikacije.
Akademska istraživanja o ispitivanju softvera
- Istraživačka skupina sveučilišta u Sheffieldu
- Laboratorij za provjeru i provjeru softvera Sveučilišta u Kentuckyju
- Istraživačka skupina za ispitivanje softvera Državnog sveučilišta Sjeverne Dakote
- Ispitivanje sustava Inteligentni laboratorij; Češka tehnička sveučilišta u Pragu
- NASA: Ispitivanje i istraživanje softvera Jon McBride (JSTAR)
- Sveučilište McMaster; Laboratorij za istraživanje kvalitete softvera
- Sveučilište Ontario Tech; Laboratorij za istraživanje kvalitete softvera
- Sveučilište u Teksasu @ Dallas; STQA
Zaključak
Uloga softvera u društvu nastavlja rasti, a istovremeno svjetski softver postaje sve složeniji. Da bi svijet funkcionirao, moramo imati metode i strategije za testiranje i provjeru valjanosti softvera koji stvaramo izvršavanjem funkcija za koje je namijenjen. Za svaki složeni softverski sustav trebala bi postojati strategija testiranja i plan testiranja kako bi se i dalje potvrđivala funkcionalnost softvera dok se nastavlja poboljšavati i pružati njegovu funkciju.
