Testiranje programskih izdelkov. Kako preizkusiti funkcionalnost funkcije, ki uporablja druge funkcije znotraj nje? Testiranje, povezano s spremembami

Tudi če ste tako tolerantni, da lahko program po sesutju v pol ure ponovno zaženete 18-krat in šele nato vržete monitor naravnost v okno, se strinjate, da bi bilo delo s tem programom udobnejše, če se ne bi “sesulo” ”.

Kako lahko zagotovite, da bodo primeri zrušitev, zamrznitev ali neuspešnega izvajanja potrebnih dejanj programa, ki ste ga razvili, postali zelo redki?

Natančen odgovor na to vprašanješt. Toda skozi stoletja so najmodrejši znanstveniki leta razmišljali o tej temi in uspeli najti zdravilo, ki če že ne odpravi vseh programskih napak, pa vsaj ustvari iluzijo ukrepanja za njihovo odpravo.

In to zdravilo se imenuje TESTIRANJE programski izdelek .

Po mnenju modrih ljudi je testiranje eden najbolj uveljavljenih načinov zagotavljanja kakovosti razvoja programsko opremo in je vključen v kompletu učinkovita sredstva sodoben sistem zagotavljanje kakovosti programskega izdelka.

Kakovost programskega izdelka je označena z nizom lastnosti, ki določajo, kako "dober" je izdelek z vidika zainteresiranih strani, kot so kupec izdelka, sponzor, končni uporabnik, razvijalci in preizkuševalci izdelkov, podporni inženirji, marketing , usposabljanje in prodajno osebje. Vsak od udeležencev ima lahko drugačno predstavo o izdelku in o tem, kako dober ali slab je, torej kako kakovosten je izdelek. Tako postavitev problema zagotavljanja kakovosti izdelka rezultira v nalogi identifikacije deležnikov, njihovih kriterijev kakovosti in nato iskanju optimalne rešitve, ki tem kriterijem ustreza.

Kdaj in kdo?

Po mnenju izkušenih razvijalcev je treba programski izdelek testirati že od samega začetka njegovega ustvarjanja. Toda hkrati izkušeni razvijalci sami ne bi smeli sodelovati pri testiranju, saj to ni kraljevska zadeva. Programski izdelek morajo testirati posebej usposobljeni zaposleni, imenovani preizkuševalci, saj tudi najbolj izkušen razvijalec ne bo mogel uvideti svoje napake, tudi z uporabo najnovejših optičnih instrumentov.

Vendar se vsi razvijalci strinjajo, da je treba testiranje programskega izdelka z vidika razvrščanja po namenu razdeliti v dva razreda:

• Funkcionalno testiranje
• Nefunkcionalno testiranje

Funkcionalno testiranje

Funkcionalno testiranje pomeni preverjanje skladnosti programskega izdelka s funkcionalnimi zahtevami, določenimi v tehničnih specifikacijah za izdelavo tega izdelka. Poenostavljeno povedano, funkcionalno testiranje preveri, ali programski izdelek opravlja vse funkcije, ki bi jih moral.

Torej ste se končno odločili za izvedbo funkcionalnega testiranja. Pogledate v tehnične specifikacije, preberete funkcionalne zahteve in ugotovite, da vsaj te niso v vrstnem redu, v katerem je mogoče opraviti testiranje. Presenečeni boste, da so že pred časom drugi opazili to neskladje in ugotovili, kako ga preseči.

Za izvedbo funkcionalnega testiranja sodelavci službe tehničnega nadzora razvijajo dokument program in metodologijo za testiranje funkcionalnosti aplikacije (API). Dokument PMI vsebuje seznam scenarijev testiranja izdelkov programske opreme (testnih primerov) s natančen opis koraki. Za vsak korak scenarija testiranja so značilna dejanja uporabnika (strokovnjaka za testiranje) in pričakovani rezultati - odziv programa na ta dejanja. Testni program in metodologija morata simulirati delovanje programskega izdelka v realnem načinu. To pomeni, da mora biti scenarij testiranja zgrajen na podlagi analize operacij, ki jih bodo izvajali prihodnji uporabniki sistema, in ne sme biti umetno sestavljeno zaporedje manipulacij, razumljivih samo razvijalcu.

Običajno se funkcionalno testiranje izvaja na dveh ravneh:

• Testiranje komponent (enot). Testiranje posameznih komponent programskega izdelka, osredotočeno na njihove specifike, namen in funkcionalne lastnosti.
• Integracijsko testiranje. Ta vrsta testiranje se izvaja po testiranju komponent in je namenjeno ugotavljanju napak v interakciji različnih podsistemov na nivoju krmilnih tokov in izmenjave podatkov.

Nefunkcionalno testiranje

Nefunkcionalno testiranje ocenjuje lastnosti programskega izdelka, kot sta ergonomija ali zmogljivost.

Mislim, da je pomen tovrstnega testiranja jasen in ne zahteva utemeljitve. Navsezadnje vsi razumejo, da če na primer zmogljivost sistema ni zadostna, bodo morali uporabniki čakati pol dneva na odgovor na svoja dejanja, kar lahko privede do njihove množične mirovanja.

Kot že ime pove, nefunkcionalno testiranje preverja, ali izdelek programske opreme izpolnjuje nefunkcionalne zahteve projektna naloga za njeno ustvarjanje. In, tako kot v primeru funkcionalnega testiranja, sta za nefunkcionalno testiranje razvita testni program in metodologija.

Testiranje in skladnost vgrajene programske opreme v agilni dobi

Skladnost z industrijskimi standardi ni nekaj, kar bi lahko zanemarili ali naredili pozneje; je sestavni del procesa razvoja vgrajene programske opreme (programske opreme). Za nekatere industrije - kot so letalska elektronika, avtomobilska industrija in zdravstvo - je strogo upoštevanje standardov kakovosti pri razvoju kompleksnih in brezhibnih vgrajenih sistemov bistvenega pomena za uvedbo izdelka na trg. Tradicionalno je imelo testiranje pomembno vlogo pri razvoju vgrajenih sistemov za industrije, ki jih urejajo standardi. Vendar so se v zadnjih letih ustaljene prakse in procesi testiranja, njihovo mesto in vloga v tovrstnih projektih močno spremenili. To je spremenilo igro in ko se spremenijo pravila igre, se moraš spremeniti z njimi, da zmagaš.

Z nenehnim razvojem novih, najsodobnejših tehnologij morajo podjetja trgu hitro ponuditi izdelke, ki so zanesljivi, varni, enostavni za uporabo in združljivi z drugimi sistemi – samo da se ne izgubijo v hitro spreminjajočem se tehnološkem svetu. V takšnih razmerah postane tradicionalni model slapa, kjer je proces razvoja programske opreme strogo zaporeden in se testiranje izvaja čisto na koncu, stvar preteklosti. Metode DevOps in Agile postajajo vse bolj priljubljene, saj inženirjem omogočajo dokončanje nalog, ki so si prej sledile hkrati.

Testiranje delovanja

V fazi testiranja delovanja je prvi korak obremenitveno testiranje, katerega namen je preveriti, ali se bo sistem ustrezno odzival na zunanje vplive v načinu, ki je blizu realnemu delovanju.

Poleg obremenitvenega testiranja se izvajajo testi v pogojih minimalne strojne opreme in maksimalne obremenitve - stresno testiranje ter testi v pogojih maksimalnih količin obdelanih informacij - volumetrično testiranje.

Obstaja še ena vrsta testiranja: testiranje stabilnosti in zanesljivosti, ki ne vključuje le dolgotrajnega testiranja programskega izdelka v normalnih pogojih, temveč tudi njegovo sposobnost, da se po kratkih obdobjih stresnih obremenitev vrne v normalno delovanje.

Dokumentacija za testiranje

Kot je navedeno zgoraj, se testiranje izvaja v skladu s programom in preskusno metodologijo, ki je razvita v skladu z GOST 34.603-92.

Za izvedbo testiranja se razvije testni primer, ki mora vsebovati dovolj podatkov za testiranje vseh načinov delovanja programskega izdelka. Običajno preskusni primer skupaj ustvarita naročnik in izvajalec na podlagi dejanskih podatkov.

Za izvedbo vseh vrst testiranja zmogljivosti se najpogosteje ustvari tako imenovani generator podatkov, ki omogoča avtomatski način ustvariti zadostno količino podatkov za doseganje objektivnega rezultata pri ocenjevanju uspešnosti.

Med testiranjem se sestavi protokol testiranja, ki vsebuje podatke o zaključku vseh faz in korakov testiranja ter pripombe, prejete med testiranjem.

Če je rezultat testa negativen, se pomanjkljivosti odpravijo in ponovno testirajo.

Raziskovalno testiranje

Raziskovalno testiranje (ad hoc testiranje je podvrsta funkcionalnega testiranja. Uporablja se pri hitro rastočih projektih s fleksibilnimi razvojnimi metodami, kjer ni jasne dokumentacije in zahtev. Raziskovalno testiranje je najvišja akrobatika pri testiranju programske opreme. Kvalitativno testiranje je na voljo visoko usposobljeni strokovnjaki in je skoraj v celoti odvisna od izvajalca, njegovih izkušenj, znanja (tako s področja kot tudi metod testiranja) in sposobnosti hitrega prehajanja do bistva.

Stresno testiranje

Obremenitveno testiranje je postopek analiziranja delovanja testiranega sistema pod obremenitvijo. Namen testiranja obremenitve je ugotoviti sposobnost aplikacije, da prenese zunanje obremenitve. Običajno se testi izvajajo v več fazah.

1. Ustvarjanje testnih skriptov

Za učinkovito analizo morajo biti scenariji čim bližje dejanskim primerom uporabe. Pomembno je razumeti, da so izjeme vedno možne in tudi najbolj podroben načrt testiranja morda ne bo zajemal enega samega primera.

2. Razvoj testne konfiguracije

Ob testnih scenarijih je pomembno porazdeliti vrstni red naraščajoče obremenitve. Za uspešno analizo je potrebno določiti merila za ocenjevanje uspešnosti (hitrost odziva, čas obdelave zahtevka itd.).

3. Izvedba testnega preizkusa

Pri izvajanju testov je pomembno pravočasno spremljanje izvajanja scenarijev in odziva testiranega sistema. Posnemanje visokih obremenitev zahteva resno strojno in programsko infrastrukturo. V nekaterih primerih se za znižanje stroškov dela uporabljajo metode matematičnega modeliranja. Podatki, pridobljeni pri nizkih obremenitvah, so vzeti kot osnova in približni. Višja kot je stopnja simulirane obremenitve, nižja je točnost ocene. Vendar pa ta metoda bistveno zmanjša stroške.

Avtomatizacija testiranja

Glavna značilnost avtomatiziranega testiranja je zmožnost hitrega izvajanja regresijskih testov. Glavne prednosti avtomatizacije (po poročilu Worksofta) so povečana učinkovitost osebja, zgodnejše odkrivanje napak in drugo. visoka kvaliteta poslovnih procesov. Te prednosti odtehta pomembna pomanjkljivost: visoki stroški – zaradi visokih stroškov implementacije in podpore avtomatizaciji testiranja približno 50 % podjetij še vedno uporablja predvsem ročno testiranje.

Testiranje uporabnosti

Vsaka aplikacija je ustvarjena za uporabo. Enostavnost uporabe je pomemben pokazatelj kakovosti programa. Industrija IT pozna veliko primerov projektov, ki so se začeli razvijati po uspešnem popravku uporabnosti. Širše kot je občinstvo, pomembnejši je faktor uporabnosti. Testiranje uporabnosti vključuje podrobno analizo vedenja uporabnikov. Za oceno ergonomije je pomembno imeti podatke ne le o hitrosti opravljanja poslovne naloge, temveč tudi o čustvih, obrazni mimiki in tembru glasu uporabnika.

Testiranje konfiguracije

Testiranje konfiguracije daje zaupanje, da bo aplikacija delovala na različnih platformah in s tem za največje število uporabnikov. Za spletne aplikacije se običajno izbere testiranje med brskalniki. Za Windows aplikacije - testiranje na različnih operacijski sistemi in bitne velikosti (x86, x64). Pomemben sestavni del testiranja konfiguracije je testna infrastruktura: za izvajanje testov morate stalno vzdrževati floto testnih strojev. Njihovo število se giblje od 5 do več deset.

Integracijsko testiranje

Če ima vaš projekt več kot eno komponento, potrebuje integracijsko testiranje. Pri kompleksni arhitekturi aplikacije je nujen pogoj za zagotavljanje kakovosti preverjanje medsebojnega delovanja programskih delov. Testiranje se doseže z razvojem in izvajanjem primerov »od konca do konca«. Testiranje integracije se izvede po testiranju komponent. Zato je zelo pomembno upoštevati izkušnje pri testiranju komponent ob spoštovanju poslovne naravnanosti testnih primerov.

Stresno testiranje

Vsak sistem ima mejo normalno delovanje. Ko je meja presežena, gre sistem v stanje stresa in bistveno spremeni svoje obnašanje. Stresno testiranje testira delovanje aplikacije v pogojih, ki presegajo normalne meje delovanja. To je še posebej pomembno za "kritične" programe: programska oprema za bančništvo, programi za letalsko industrijo, medicina. Testiranje izjemnih situacij se izvaja ne samo v fazi razvoja programske opreme, ampak tudi skozi celoten cikel delovanja, da bi pridobili in obdelali podatke o obnašanju sistema v daljšem časovnem obdobju.

Predpostavimo, da obstaja funkcija get-data, ki vrne zemljevid informacij o ID-ju uporabnika, ki je opravil. Zdaj ta funkcija uporablja 3 funkcije source-a, source-b in source-c za izdelavo treh različnih vrst zemljevidov. Zdaj bomo vse te zemljevide združili v en zemljevid in se vrnili iz get-data.

Ko testiram get-datanaj preverim razpoložljivost podatkov za ključe? Ali je smiselno, da ta funkcija ne uspe preizkusiti enote, če eden od izvor-a, izvor-b in izvor-c ne uspe? Če je naloga te funkcije združevanje podatkov, in jih tudi počne, bi moralo biti to dovolj, kajne?

1

2 odgovora

Predpostavimo, da obstaja funkcija get-data, ki vrne zemljevid informacij o posredovanem ID-ju uporabnika.

Super. Potem bi morali preveriti. Ali za določen ID vrnete pravilne podatke?

zdaj ta funkcija uporablja 3 funkcije izvor-a, vir-b in izvor-c za izdelavo treh različnih vrst zemljevidov.

Katero podrobnost izvedbe morate zanemariti pri preizkusu. Vse, kar preizkušate, je, da vaša enota dela (ta metoda) počne tisto, kar naj bi naredila (vzemite ID in vrnite podatke XYZ za ta ID). kako ta metoda v resnici ni pomembna – navsezadnje je ključna prednost tega testa enote ta, da lahko refaktorirate implementacijo metode in test bo preveril, ali ste jo naredili pravilno.

Vendar se boste verjetno morali posmehovati virom podatkov, zato bo na neki točki preizkus verjetno moral vedeti, kako ta koda deluje. Tu morate uravnotežiti tri konkurenčne cilje: narediti test izoliran (z norčevanjem iz podatkov), medtem ko se test osredotoča na zahteve in pragmatizem.

Navsezadnje je to pomembna koda. Obstajajo testi za podporo dejanske kode, ki porabijo veliko časa in težave s preverjanjem poliranja niso tako uporabni kot testi izdelava .

Pri testiranju enote bi morali testirati samo funkcionalnost enega razreda, če vaše metode source-a, source-b in source-c kličejo druge razrede, se jim posmehujte (enotno jih je treba testirati v svojih razredih).

Pri integracijskem testiranju preizkušate vedenje več razredov, ki medsebojno delujejo med njimi, kar pomeni, da mora vaša funkcija get-data preveriti, ali so podatki, ki jih pridobivate, pravilni (source-a, source-b in source-c so pravilni in so podatki pravilno povezani).

Preizkusi enot so preprostejši in bolj osredotočeni in bi jih morali napisati razvijalci. Integracijski testi običajno razmeroma hitro zastarijo (če sploh notranja komponenta je bilo spremenjeno), zaradi česar jih je težje izvesti. Ustvariti ga mora QA profil.

Tudi če ste tako tolerantni, da lahko program po sesutju v pol ure ponovno zaženete 18-krat in šele nato vržete monitor naravnost v okno, se strinjate, da bi bilo delo s tem programom udobnejše, če se ne bi “sesulo” ”.

Kako lahko zagotovite, da bodo primeri zrušitev, zamrznitev ali neuspešnega izvajanja potrebnih dejanj programa, ki ste ga razvili, postali zelo redki?

Točnega odgovora na to vprašanje ni. Toda skozi stoletja so najmodrejši znanstveniki leta razmišljali o tej temi in uspeli najti zdravilo, ki če že ne odpravi vseh programskih napak, pa vsaj ustvari iluzijo ukrepanja za njihovo odpravo.

In to zdravilo se imenuje TESTIRANJE programskega izdelka.

Po mnenju modrcev je testiranje eden najbolj uveljavljenih načinov zagotavljanja kakovosti razvoja programske opreme in je vključen v nabor učinkovitih orodij sodobnega sistema zagotavljanja kakovosti programskih izdelkov.

Kakovost programskega izdelka je označena z nizom lastnosti, ki določajo, kako "dober" je izdelek z vidika zainteresiranih strani, kot so kupec izdelka, sponzor, končni uporabnik, razvijalci in preizkuševalci izdelkov, podporni inženirji, marketing , usposabljanje in prodajno osebje. Vsak od udeležencev ima lahko drugačno predstavo o izdelku in o tem, kako dober ali slab je, torej kako kakovosten je izdelek. Tako postavitev problema zagotavljanja kakovosti izdelka rezultira v nalogi identifikacije deležnikov, njihovih kriterijev kakovosti in nato iskanju optimalne rešitve, ki tem kriterijem ustreza.

Kdaj in kdo?

Po mnenju izkušenih razvijalcev je treba programski izdelek testirati že od samega začetka njegovega ustvarjanja. Toda hkrati izkušeni razvijalci sami ne bi smeli sodelovati pri testiranju, saj to ni kraljevska zadeva. Programski izdelek morajo testirati posebej usposobljeni zaposleni, imenovani preizkuševalci, saj tudi najbolj izkušen razvijalec ne bo mogel uvideti svoje napake, tudi z uporabo najnovejših optičnih instrumentov.

Vendar se vsi razvijalci strinjajo, da je treba testiranje programskega izdelka z vidika razvrščanja po namenu razdeliti v dva razreda:

• Funkcionalno testiranje
• Nefunkcionalno testiranje

Funkcionalno testiranje

Funkcionalno testiranje pomeni preverjanje skladnosti programskega izdelka s funkcionalnimi zahtevami, določenimi v tehničnih specifikacijah za izdelavo tega izdelka. Poenostavljeno povedano, funkcionalno testiranje preveri, ali programski izdelek opravlja vse funkcije, ki bi jih moral.

Torej ste se končno odločili za izvedbo funkcionalnega testiranja. Pogledate v tehnične specifikacije, preberete funkcionalne zahteve in ugotovite, da vsaj te niso v vrstnem redu, v katerem je mogoče opraviti testiranje. Presenečeni boste, da so že pred časom drugi opazili to neskladje in ugotovili, kako ga preseči.

Za izvedbo funkcionalnega testiranja sodelavci službe tehničnega nadzora razvijajo dokument program in metodologijo za testiranje funkcionalnosti aplikacije (API). Dokument PMI vsebuje seznam scenarijev testiranja programskih izdelkov (testnih primerov) s podrobnim opisom korakov. Za vsak korak scenarija testiranja so značilna dejanja uporabnika (strokovnjaka za testiranje) in pričakovani rezultati - odziv programa na ta dejanja. Testni program in metodologija morata simulirati delovanje programskega izdelka v realnem načinu. To pomeni, da mora biti scenarij testiranja zgrajen na podlagi analize operacij, ki jih bodo izvajali prihodnji uporabniki sistema, in ne sme biti umetno sestavljeno zaporedje manipulacij, razumljivih samo razvijalcu.

Običajno se funkcionalno testiranje izvaja na dveh ravneh:

• Testiranje komponent (enot). Testiranje posameznih komponent programskega izdelka, osredotočeno na njihove specifike, namen in funkcionalne lastnosti.
• Integracijsko testiranje. Ta vrsta testiranja se izvaja po testiranju komponent in je namenjena ugotavljanju napak v interakciji različnih podsistemov na ravni krmilnih tokov in izmenjave podatkov.

Nefunkcionalno testiranje

Nefunkcionalno testiranje ocenjuje lastnosti programskega izdelka, kot sta ergonomija ali zmogljivost.

Mislim, da je pomen tovrstnega testiranja jasen in ne zahteva utemeljitve. Navsezadnje vsi razumejo, da če na primer zmogljivost sistema ni zadostna, bodo morali uporabniki čakati pol dneva na odgovor na svoja dejanja, kar lahko privede do njihove množične mirovanja.

Kot že ime pove, nefunkcionalno testiranje preverja skladnost programskega izdelka z nefunkcionalnimi zahtevami iz tehničnih specifikacij za njegovo izdelavo. In, tako kot v primeru funkcionalnega testiranja, sta za nefunkcionalno testiranje razvita testni program in metodologija.

Testiranje in skladnost vgrajene programske opreme v agilni dobi

Skladnost z industrijskimi standardi ni nekaj, kar bi lahko zanemarili ali naredili pozneje; je sestavni del procesa razvoja vgrajene programske opreme (programske opreme). Za nekatere industrije - kot so letalska elektronika, avtomobilska industrija in zdravstvo - je strogo upoštevanje standardov kakovosti pri razvoju kompleksnih in brezhibnih vgrajenih sistemov bistvenega pomena za uvedbo izdelka na trg. Tradicionalno je imelo testiranje pomembno vlogo pri razvoju vgrajenih sistemov za industrije, ki jih urejajo standardi. Vendar so se v zadnjih letih ustaljene prakse in procesi testiranja, njihovo mesto in vloga v tovrstnih projektih močno spremenili. To je spremenilo igro in ko se spremenijo pravila igre, se moraš spremeniti z njimi, da zmagaš.

Z nenehnim razvojem novih, najsodobnejših tehnologij morajo podjetja trgu hitro ponuditi izdelke, ki so zanesljivi, varni, enostavni za uporabo in združljivi z drugimi sistemi – samo da se ne izgubijo v hitro spreminjajočem se tehnološkem svetu. V takšnih razmerah postane tradicionalni model slapa, kjer je proces razvoja programske opreme strogo zaporeden in se testiranje izvaja čisto na koncu, stvar preteklosti. Metode DevOps in Agile postajajo vse bolj priljubljene, saj inženirjem omogočajo dokončanje nalog, ki so si prej sledile hkrati.

Testiranje delovanja

V fazi testiranja delovanja je prvi korak obremenitveno testiranje, katerega namen je preveriti, ali se bo sistem ustrezno odzival na zunanje vplive v načinu, ki je blizu realnemu delovanju.

Poleg obremenitvenega testiranja se izvajajo testi v pogojih minimalne strojne opreme in maksimalne obremenitve - stresno testiranje ter testi v pogojih maksimalnih količin obdelanih informacij - volumetrično testiranje.

Obstaja še ena vrsta testiranja: testiranje stabilnosti in zanesljivosti, ki ne vključuje le dolgotrajnega testiranja programskega izdelka v normalnih pogojih, temveč tudi njegovo sposobnost, da se po kratkih obdobjih stresnih obremenitev vrne v normalno delovanje.

Dokumentacija za testiranje

Kot je navedeno zgoraj, se testiranje izvaja v skladu s programom in preskusno metodologijo, ki je razvita v skladu z GOST 34.603-92.

Za izvedbo testiranja se razvije testni primer, ki mora vsebovati dovolj podatkov za testiranje vseh načinov delovanja programskega izdelka. Običajno preskusni primer skupaj ustvarita naročnik in izvajalec na podlagi dejanskih podatkov.

Za izvedbo vseh vrst testiranja zmogljivosti se najpogosteje ustvari tako imenovani generator podatkov, ki vam omogoča samodejno ustvarjanje zadostne količine podatkov za doseganje objektivnega rezultata pri ocenjevanju uspešnosti.

Med testiranjem se sestavi protokol testiranja, ki vsebuje podatke o zaključku vseh faz in korakov testiranja ter pripombe, prejete med testiranjem.

Če je rezultat testa negativen, se pomanjkljivosti odpravijo in ponovno testirajo.

Raziskovalno testiranje

Raziskovalno testiranje (ad hoc testiranje je podvrsta funkcionalnega testiranja. Uporablja se pri hitro rastočih projektih s fleksibilnimi razvojnimi metodami, kjer ni jasne dokumentacije in zahtev. Raziskovalno testiranje je najvišja akrobatika pri testiranju programske opreme. Kvalitativno testiranje je na voljo visoko usposobljeni strokovnjaki in je skoraj v celoti odvisna od izvajalca, njegovih izkušenj, znanja (tako s področja kot tudi metod testiranja) in sposobnosti hitrega prehajanja do bistva.

Stresno testiranje

Obremenitveno testiranje je postopek analiziranja delovanja testiranega sistema pod obremenitvijo. Namen testiranja obremenitve je ugotoviti sposobnost aplikacije, da prenese zunanje obremenitve. Običajno se testi izvajajo v več fazah.

1. Ustvarjanje testnih skriptov

Za učinkovito analizo morajo biti scenariji čim bližje dejanskim primerom uporabe. Pomembno je razumeti, da so izjeme vedno možne in tudi najbolj podroben načrt testiranja morda ne bo zajemal enega samega primera.

2. Razvoj testne konfiguracije

Ob testnih scenarijih je pomembno porazdeliti vrstni red naraščajoče obremenitve. Za uspešno analizo je potrebno določiti merila za ocenjevanje uspešnosti (hitrost odziva, čas obdelave zahtevka itd.).

3. Izvedba testnega preizkusa

Pri izvajanju testov je pomembno pravočasno spremljanje izvajanja scenarijev in odziva testiranega sistema. Posnemanje visokih obremenitev zahteva resno strojno in programsko infrastrukturo. V nekaterih primerih se za znižanje stroškov dela uporabljajo metode matematičnega modeliranja. Podatki, pridobljeni pri nizkih obremenitvah, so vzeti kot osnova in približni. Višja kot je stopnja simulirane obremenitve, nižja je točnost ocene. Vendar pa ta metoda bistveno zmanjša stroške.

Avtomatizacija testiranja

Glavna značilnost avtomatiziranega testiranja je zmožnost hitrega izvajanja regresijskih testov. Glavne prednosti avtomatizacije (po poročilu Worksofta) so povečana učinkovitost zaposlenih, zgodnejše odkrivanje napak in večja kakovost poslovnih procesov. Te prednosti odtehta pomembna pomanjkljivost: visoki stroški – zaradi visokih stroškov implementacije in podpore avtomatizaciji testiranja približno 50 % podjetij še vedno uporablja predvsem ročno testiranje.

Testiranje uporabnosti

Vsaka aplikacija je ustvarjena za uporabo. Enostavnost uporabe je pomemben pokazatelj kakovosti programa. Industrija IT pozna veliko primerov projektov, ki so se začeli razvijati po uspešnem popravku uporabnosti. Širše kot je občinstvo, pomembnejši je faktor uporabnosti. Testiranje uporabnosti vključuje podrobno analizo vedenja uporabnikov. Za oceno ergonomije je pomembno imeti podatke ne le o hitrosti opravljanja poslovne naloge, temveč tudi o čustvih, obrazni mimiki in tembru glasu uporabnika.

Testiranje konfiguracije

Testiranje konfiguracije daje zaupanje, da bo aplikacija delovala na različnih platformah in s tem za največje število uporabnikov. Za spletne aplikacije se običajno izbere testiranje med brskalniki. Za Windows aplikacije - testiranje na različnih operacijskih sistemih in bitnih hitrostih (x86, x64). Pomemben sestavni del testiranja konfiguracije je testna infrastruktura: za izvajanje testov morate stalno vzdrževati floto testnih strojev. Njihovo število se giblje od 5 do več deset.

Integracijsko testiranje

Če ima vaš projekt več kot eno komponento, potrebuje integracijsko testiranje. Pri kompleksni arhitekturi aplikacije je nujen pogoj za zagotavljanje kakovosti preverjanje medsebojnega delovanja programskih delov. Testiranje se doseže z razvojem in izvajanjem primerov »od konca do konca«. Testiranje integracije se izvede po testiranju komponent. Zato je zelo pomembno upoštevati izkušnje pri testiranju komponent ob spoštovanju poslovne naravnanosti testnih primerov.

Stresno testiranje

Vsak sistem ima mejo svojega normalnega delovanja. Ko je meja presežena, gre sistem v stanje stresa in bistveno spremeni svoje obnašanje. Stresno testiranje testira delovanje aplikacije v pogojih, ki presegajo normalne meje delovanja. To je še posebej pomembno za "kritične" programe: programska oprema za bančništvo, programi za letalsko industrijo, medicina. Testiranje izjemnih situacij se izvaja ne samo v fazi razvoja programske opreme, ampak tudi skozi celoten cikel delovanja, da bi pridobili in obdelali podatke o obnašanju sistema v daljšem časovnem obdobju.

Med vsemi vrstami funkcionalno testiranje upravičeno zavzema vodilno mesto, saj mora program najprej delovati pravilno, sicer enostavnost uporabe, varnost in zadostna hitrost ne bodo koristili. Poleg obvladovanja različnih tehnik testiranja mora vsak specialist razumeti, kako pravilno opraviti test, da bi dosegel najučinkovitejši rezultat.

Funkcionalno testiranje: kam usmeriti glavna prizadevanja?

Za testiranje enot in sistemov;

Če želite označiti "belo" ali "črno" polje;

Za ročno testiranje in avtomatizacijo;

Za testiranje nove funkcionalnosti ali;

Za "negativne" ali "pozitivne" teste.

Med vsemi temi področji delovanja je pomembno najti pravo pot, ki bo »sredina«, da uravnotežimo prizadevanja in maksimalno izkoristimo prednosti vsakega od področij.

Izvaja se preverjanje programske opreme različne poti, od katerih je ena črna skrinjica ali testiranje na podlagi podatkov.

Program je v tem primeru predstavljen z vidika »črne skrinjice«, test pa se izvede za določitev okoliščin, v katerih vedenje programa ne bo v skladu s specifikacijo. Vse napake ugotavljamo z upravljanjem podatkov, ki poteka z izčrpnim testiranjem, torej z uporabo vseh možnih

Če je pri programu izvedba ukaza odvisna od dogodkov pred njim, potem bo zahteval preverjanje vseh možnih zaporedij. Povsem očitno je, da je za večino primerov preprosto nemogoče izvesti izčrpno testiranje, zato pogosteje izberejo sprejemljivo ali razumno možnost, ki je omejena na izvajanje programa na majhni podmnožici vseh vhodnih podatkov. Ta možnost v celoti zagotavlja brez odstopanj od specifikacij.

Funkcionalno testiranje vključuje izbiro pravega testa. Hkrati je običajno razlikovati med naslednjimi metodami za ustvarjanje sklopov zanje:

Analiza mejnih vrednosti;

Enakovredna particija;

Predpostavka o napaki;

Analiza povezav med vzroki in posledicami.

Vsako od njih lahko obravnavate ločeno.

Analiza mejnih vrednosti. Mejne vrednosti se običajno razumejo kot tiste, ki se nahajajo na mejah enakovrednih razredov. Na takih mestih je najverjetneje najti napako. Uporaba takšne metode zahteva od strokovnjaka določeno ustvarjalnost, pa tudi specializacijo na tem specifičnem obravnavanem problemu.

Enakovredna particija. Vse možne množice vhodnih parametrov so razdeljene v več ekvivalentnih razredov. Podatki se združujejo po principu odkrivanja podobnih napak. Splošno sprejeto je, da če nabor enega razreda pokaže napako, jo bodo pokazali tudi enakovredni razredi. Funkcionalno testiranje s strani ta metoda poteka v dveh fazah: v prvi se identificirajo ekvivalenčni razredi, v drugi pa se že oblikujejo posebni testi.

Analiza vzročno-posledičnih razmerij. Sistem lahko z izvajanjem takih preverjanj izbere teste z visoko zmogljivostjo. V tem primeru se ločen vhodni pogoj vzame kot vzrok, izhodni pogoj pa se obravnava kot posledica. Metoda temelji na ideji pripisovanja vseh vrst vzrokov določenim posledicam, torej na razjasnitvi teh istih vzročno-posledičnih razmerij. Testiranje programskega izdelka poteka v več fazah, rezultat pa je seznam vzrokov in posledičnih posledic.

• nenamerna odstopanja razvijalcev od delovnih standardov ali izvedbenih načrtov;
• specifikacije funkcionalnih in vmesnikovskih zahtev so izdelane brez upoštevanja razvojnih standardov, kar vodi v motnje delovanja programov;
• organizacija razvojnega procesa - nepopolno ali nezadostno upravljanje z vodjevimi viri (človeškimi, tehničnimi, programskimi itd.) ter vprašanja testiranja in integracije elementov projekta.

Oglejmo si postopek testiranja, ki temelji na priporočilih standarda ISO/IEC 12207, in navedimo vrste napak, ki so odkrite v posameznem procesu življenjskega cikla.

Proces razvoja zahtev. Pri določanju začetnega koncepta sistema in začetnih zahtev za sistem analitiki delajo specifikacijske napake najvišji nivo sistemov in izgradnja konceptualnega modela predmetnega področja.

Tipične napake v tem procesu so:

• neustreznost specifikacije zahtev za končne uporabnike, - nepravilna specifikacija interakcije programske opreme z operacijskim okoljem ali uporabniki;
• neskladnost z zahtevami strank glede posameznih in splošnih lastnosti programske opreme;
• napačen opis funkcionalnih značilnosti;
• pomanjkanje razpoložljivosti orodij za vse vidike izvajanja zahtev kupcev ipd.

Proces oblikovanja.Napake pri oblikovanju komponent se lahko pojavijo pri opisovanju algoritmov, krmilne logike, podatkovnih struktur, vmesnikov, logike modeliranja pretoka podatkov, vhodno-izhodnih formatov itd. Te napake temeljijo na napakah v specifikacijah analitikov in napakah v načrtovanju. Sem spadajo napake, povezane z:

• z opredelitvijo uporabniškega vmesnika z okoljem;
• z opisom funkcij (neustreznost ciljev in ciljev komponent, ki se odkrijejo pri preverjanju sklopa komponent);
• z opredelitvijo procesa obdelave informacij in interakcije med procesi (posledica nepravilnega določanja razmerij komponent in procesov);
• z napačno specifikacijo podatkov in njihovih struktur pri opisu posameznih komponent in programske opreme kot celote;
• z napačnim opisom algoritmov modula;
• z določitvijo pogojev nastanka možne napake v programu;
• v nasprotju s standardi in tehnologijami, sprejetimi za projekt.

Stopnja kodiranja.Na tej stopnji se pojavijo napake, ki so posledica konstrukcijskih napak, napak programerjev in upravljavcev pri razvoju in odpravljanju napak v sistemu. Vzroki za napake so:

• pomanjkanje nadzora nad vrednostmi vhodnih parametrov, matričnih indeksov, parametrov zanke, izhodnih rezultatov, deljenja z 0 itd.;
• nepravilno obravnavanje nepravilnih situacij pri analizi povratnih kod iz klicanih podprogramov, funkcij itd.;
• kršitev standardov kodiranja (slabi komentarji, neracionalni dodeljevanje modulov in komponento itd.);
• uporaba enega imena za označevanje različnih objektov ali različna imena enega predmeta, slaba mnemotehnika imen, - nedosledne spremembe programa s strani različnih razvijalcev itd.

Postopek testiranja.V tem procesu programerji in preizkuševalci naredijo napake pri izvajanju tehnologije sestavljanja in testiranja, izbiri testnih nizov in testnih scenarijev itd. Napake v programski opremi, ki jih povzročijo tovrstne napake, je treba identificirati, odpraviti in ne smejo vplivati ​​na statistiko komponent in programske napake na splošno.

Postopek vzdrževanja.Med postopkom vzdrževanja se odkrijejo napake, ki so posledica pomanjkljivosti in pomanjkljivosti v operativni dokumentaciji, nezadostnih indikatorjev spremenljivosti in čitljivosti ter neusposobljenosti oseb, odgovornih za vzdrževanje in/ali izboljšavo programske opreme. Glede na naravo izvedenih sprememb se lahko na tej stopnji pojavijo skoraj vse napake, podobne prej navedenim napakam na prejšnjih stopnjah.

Vse napake, ki se pojavijo v programih, so običajno razdeljene v naslednje razrede [7.12]:

• logične in funkcionalne napake;
• napake pri izračunih in izvajanju;
• napake pri vhodu/izhodu in manipulaciji podatkov;
• napake vmesnika;
• napake količine podatkov itd.

Logične napake so vzrok za kršitev logike algoritma, notranja neskladnost spremenljivk in operatorjev, pa tudi programska pravila. Funkcionalne napake so posledica nepravilno definiranih funkcij, kršitve vrstnega reda njihove uporabe ali nepopolnosti njihovega izvajanja itd.

Računske napake nastanejo zaradi netočnosti izvornih podatkov in izvedenih formul, napak v metodi, nepravilne uporabe računskih operacij ali operandov. Napake med izvajanjem so povezane z neuspehom pri zagotavljanju zahtevane hitrosti obdelave zahtev ali časa obnovitve programa.

V/I napake in manipulacije podatkov so posledica nekvalitetne priprave podatkov za izvajanje programa, napak pri njihovem vnosu v baze podatkov ali pri pridobivanju iz njih.

Napake vmesnika se nanašajo na napake v medsebojnem odnosu posameznih elementov, ki se kažejo tako pri prenosu podatkov med njimi kot tudi med interakcijo z operacijskim okoljem.

Napake glasnosti se nanašajo na podatke in so posledica dejstva, da implementirani načini dostopa in velikosti baz podatkov ne zadovoljujejo realnih količin sistemskih informacij oziroma intenzivnosti njihove obdelave.

Navedeni glavni razredi napak so značilni za različne vrste programskih komponent in se v programih kažejo na različne načine. Tako se pri delu z bazo podatkov pojavljajo napake v predstavitvi in ​​manipulaciji podatkov, logične napake pri specifikaciji aplikativnih postopkov obdelave podatkov itd. V računskih programih prevladujejo računske napake, v programih za vodenje in obdelavo pa logične in funkcionalne napake. Programska oprema, ki je sestavljena iz številnih različnih programov, ki izvajajo različne funkcije, lahko vsebuje napake različni tipi. Napake vmesnika in kršitve glasnosti so značilne za katero koli vrsto sistema.

Analiza vrst napak v programih je predpogoj za izdelavo testnih načrtov in testnih metod za zagotavljanje pravilnosti programske opreme.

Na današnji stopnji razvoja podpornih orodij za razvoj programske opreme (tehnologije CASE, objektno orientirane metode in orodja za načrtovanje modelov in programov) se izvaja zasnova, pri kateri je programska oprema zaščitena pred najpogostejšimi napakami in s tem preprečuje nastanek programske napake.

Razmerje med napako in neuspehom.Prisotnost napake v programu praviloma povzroči okvaro programske opreme med njenim delovanjem. Za analizo vzročno-posledičnih razmerij "napaka-napaka" se izvedejo naslednja dejanja:

• odkrivanje napak v tehnologijah oblikovanja in programiranja;
• razmerje med napakami v procesu oblikovanja in človeškimi napakami;
• klasifikacija okvar, pomanjkljivosti in morebitnih napak ter napak na posamezni stopnji razvoja, - primerjava človeških napak v določenem razvojnem procesu in napak na objektu, kot posledica napak v projektni specifikaciji, programskih modelih;
• preverjanje in zaščita pred napakami v vseh fazah življenjskega cikla ter odkrivanje napak v vsaki fazi razvoja;
• Primerjava napak in napak v programski opremi za razvoj sistema medsebojnih povezav in metod za lokalizacijo, zbiranje in analizo informacij o napakah in okvarah;
• razvoj pristopov k procesom dokumentiranja in testiranja programske opreme.

Končni cilj vzroka napake-neuspeha je opredeliti metode in sredstva za testiranje in odkrivanje napak določenih razredov, kot tudi merila za dokončanje testiranja na več nizih podatkov; pri prepoznavanju načinov za izboljšanje organizacije procesa razvoja, testiranja in vzdrževanja programske opreme.

Tukaj je naslednja klasifikacija vrst napak:

• strojna oprema, v kateri sistemska programska oprema ne deluje;
• informacijske, ki jih povzročajo napake pri vnosu podatkov in prenosu podatkov po komunikacijskih kanalih ter okvara vnosnih naprav (posledica okvar strojne opreme);
• ergonomski, ki ga povzročajo napake operaterja med njegovo interakcijo s strojem (ta okvara je sekundarna okvara in lahko vodi do informacijskih ali funkcionalnih okvar);
• programske opreme, če so napake v komponentah itd.

Nekatere napake so lahko posledica pomanjkljivosti v definiciji zahtev, načrtovanju, ustvarjanju izhodne kode ali dokumentaciji. Po drugi strani pa nastanejo med razvojem programa ali med razvojem vmesnikov posameznih programskih elementov (kršitev vrstnega reda parametrov, manj ali več parametrov ipd.).

Viri napak.Napake lahko nastanejo med razvojem projekta, komponent, kode in dokumentacije. Praviloma se odkrijejo med izvajanjem ali vzdrževanjem programske opreme na najbolj nepričakovanih in različnih točkah.

Nekatere napake v programu so lahko posledica pomanjkljivosti v definiciji zahtev, oblikovanju, ustvarjanju kode ali dokumentaciji. Po drugi strani pa napake nastajajo med razvojem programa ali vmesnikov njegovih elementov (na primer, ko je kršen vrstni red nastavitev komunikacijskih parametrov - manj ali več od zahtevanega itd.).

Razlog za napake je nerazumevanje strankinih zahtev; netočna specifikacija zahtev v projektni dokumentaciji itd. To vodi do tega, da so implementirane nekatere sistemske funkcije, ki ne bodo delovale tako, kot je predlagal naročnik. V zvezi s tem poteka skupna razprava med stranko in razvijalcem nekaterih podrobnosti zahtev, da se jih razjasni.

Skupina za razvoj sistema lahko spremeni tudi sintakso in semantiko opisa sistema. Vendar pa nekatere napake morda ne bodo zaznane (na primer indeksi ali vrednosti spremenljivk teh stavkov so nepravilno nastavljeni).