Testiranje programskih izdelkov. Kako preveriti funkcionalnost funkcije, ki v njej uporablja druge funkcije? Testiranje, povezano s spremembami

Tudi če ste tako tolerantni, da lahko program po okvari v pol ure ponovno zaženete 18-krat in šele nato vržete monitor točno v okno, se strinjate, da bi bilo delo s tem programom bolj udobno, če ne bi “ padec«.

Kako narediti tako, da postanejo primeri padca, zmrzovanja, neizvajanja potrebnih dejanj programa, ki ste ga razvili, zelo redki?

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

In to orodje se imenuje Testiranje programskih izdelkov.

Po mnenju modrih ljudi je testiranje eden najbolj uveljavljenih načinov zagotavljanja kakovosti razvoja. programsko opremo in je vključen v nabor učinkovitih orodij sodoben sistem zagotavljanje 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, podpora inženirji, marketing, usposabljanje in prodajalci. 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 iz postavitve problema zagotavljanja kakovosti izdelka izhaja naloga identifikacije deležnikov, njihovih kriterijev kakovosti in nato iskanje 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 kraljevski posel. Programski izdelek naj testirajo posebej usposobljeni zaposleni, imenovani preizkuševalci, saj tudi najbolj izkušen razvijalec ne bo mogel videti svoje napake, tudi z uporabo najnovejših optičnih instrumentov.

Kljub temu se vsi razvijalci strinjajo, da je treba testiranje programskega izdelka glede na razvrstitev po ciljih razdeliti na dva razreda:

• Funkcionalno testiranje
• Nefunkcionalno testiranje

Funkcionalno testiranje

Funkcionalno testiranje se razume kot preverjanje skladnosti programskega izdelka s funkcionalnimi zahtevami, določenimi v projektni nalogi za izdelavo tega izdelka. Poenostavljeno povedano, funkcionalno testiranje preveri, ali programski izdelek opravlja vse funkcije, ki bi jih moral.

Torej ste se odločili za izvedbo funkcionalnega testiranja. Pogledate referenčno nalogo, preberete funkcionalne zahteve in razumete, da vsaj niso v vrstnem redu, v katerem lahko testirate. Presenečeni boste, da so drugi že zdavnaj opazili to neskladje in ugotovili, kako ga preseči.

Za izvedbo funkcionalnega testiranja osebje službe tehničnega nadzora razvije dokumentni program in metodo za testiranje funkcionalnosti aplikacije (API). Dokument PMI vsebuje seznam scenarijev testiranja izdelkov programske opreme (testnih primerov) s natančen opis koraki. Za vsak korak testnega scenarija so značilna dejanja uporabnika (strokovnjaka za testiranje) in pričakovani rezultati - odziv programa na ta dejanja. Program in testna metodologija morata simulirati delovanje programskega izdelka v realnem načinu. To pomeni, da mora biti testni skript zgrajen na podlagi analize operacij, ki jih bodo izvajali prihodnji uporabniki sistema, in ne sme biti umetno sestavljeno zaporedje manipulacij, ki so razumljive le 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 takšne lastnosti programskega izdelka, kot sta na primer 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 pove že ime, nefunkcionalno testiranje preverja, ali izdelek programske opreme izpolnjuje nefunkcionalne zahteve projektna naloga njegovemu ustvarjanju. In, tako kot v primeru funkcionalnega testiranja, sta za nefunkcionalno testiranje razvita program in testna metodologija.

Testiranje in skladnost vgrajene programske opreme v dobi Agile

Skladnost z industrijskimi standardi ni nekaj, kar bi lahko zanemarili ali naredili pozneje; je sestavni del procesa razvoja vgrajene programske opreme (SW). Za nekatere industrije - kot so letalska elektronika, avtomobilska industrija in zdravstvo - postaja dosledno upoštevanje standardov kakovosti pri razvoju kompleksnih in brezhibnih vgrajenih sistemov ključen pogoj za dajanje izdelka na trg. Tradicionalno je imelo testiranje pomembno vlogo pri razvoju vgrajenih sistemov za industrije, ki temeljijo na standardih. Vendar so se v zadnjih letih ustaljene prakse in procesi testiranja, njihovo mesto in vloga v tovrstnih projektih močno spremenili. Dramatično je spremenila vsa pravila igre in ko se pravila igre spremenijo, se moraš z njimi spremeniti tudi ti, da zmagaš.

Z novimi, najsodobnejšimi tehnologijami, ki se nenehno razvijajo, morajo podjetja hitro dati na trg izdelke, ki so zanesljivi, varni, enostavni za uporabo in interoperabilni – samo da se ne izgubijo v hitrem tempu tehnološki svet. V takšnih razmerah tradicionalni slapni model, kjer je proces razvoja programske opreme strogo zaporeden in se testiranje izvaja čisto na njegovem koncu, postaja preteklost. Metode DevOps in Agile postajajo vse bolj priljubljene, saj inženirjem omogočajo izvajanje nalog, ki so si sledile hkrati.

Testiranje delovanja

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

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 – volumetrijsko 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 zmožnost vrnitve v normalno delovanje po kratkih obdobjih stresnih obremenitev.

Dokumentacija za testiranje

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

Razvito za testiranje testni primer, ki naj vsebuje dovolj podatkov za preverjanje vseh načinov delovanja programskega izdelka. Običajno testni primer izdelata skupaj naročnik in izvajalec na podlagi realnih podatkov.

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

Med testiranjem se sestavi protokol testiranja, v katerega se vnesejo podatki o prehodu vseh faz in korakov testiranja ter pripombe, prejete med preskusi.

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

Raziskovalno testiranje

Eksploratorno 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. Eksploratorno testiranje je vrhunec testiranja programske opreme. Na voljo je visokokakovostno testiranje visoko usposobljenim strokovnjakom in je skoraj popolnoma odvisna od izvajalca, njegovih izkušenj, znanja (tako na predmetnem področju kot v metodah testiranja), sposobnosti hitrega prodiranja v bistvo.

Stresno testiranje

Obremenitveno testiranje je proces analiziranja delovanja preskušanega sistema pod vplivom obremenitev. Cilj testiranja obremenitve je ugotoviti sposobnost aplikacije, da prenese zunanje obremenitve. Običajno se testi izvajajo v več fazah.

1. Generiranje 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 izpostaviti kriterije za ocenjevanje uspešnosti (hitrost odziva, čas obdelave zahtevka itd.).

3. Izvedba testnega testa

Pri izvajanju testov je pomembno, da pravočasno spremljamo izvajanje skript in odzivnost testiranega sistema. Za posnemanje velikih obremenitev je potrebna resna strojna in programska infrastruktura. 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 Worksoft) 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 vzdrževanja avtomatizacije testiranja približno 50 % podjetij še vedno uporablja večinoma ročno testiranje.

Testiranje uporabnosti

Vsaka aplikacija je narejena 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, kar pomeni za največje število uporabnikov. Za spletne aplikacije se običajno izbere testiranje združljivosti med brskalniki. Za Windows aplikacije - testiranje na različnih operacijski sistemi in bitno (x86, x64). Pomemben sestavni del testiranja konfiguracije je testna infrastruktura: za testiranje 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 interakcije med deli programa. Testiranje se doseže z razvojem in izvajanjem "skozi" primerov. 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, sistem preide v stanje stresa in bistveno spremeni svoje obnašanje. Stresno testiranje preverja delovanje aplikacije v pogojih preseganja meja normalnega delovanja. To je še posebej pomembno za "kritične" programe: bančniško programje, programe letalske industrije in medicino. Stresno testiranje se izvaja ne le 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.

Recimo, 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, da dobi tri različne vrste zemljevidov. Zdaj bomo vse te zemljevide združili v en zemljevid in se vrnili iz get-data.

Ko testiram get-data, naj preverim obstoj 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 funkcije thats združevanje podatkov in jih tudi počne, bi moralo biti to dovolj, kajne?

1

2 odgovora

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

Super. Potem bi morali preveriti. Ali vračate pravilne podatke za navedeni ID?

zdaj ta funkcija uporablja 3 funkcije izvor-a, izvor-b in izvor-c, da dobi 3 različne vrste zemljevidov.

Katere podrobnosti implementacije morate zanemariti pri preizkusu. Vse, kar preizkušate, je, da vaša delovna enota (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 preuredite izvedbo metode in test bo preveril, ali ste jo naredili pravilno.

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

Navsezadnje je to pomembna koda. Obstajajo testi za varnostno kopiranje dejanske kode, poraba veliko časa in težav s preverjanjem poliranja pa ni tako uporabna kot testi izdelava .

Pri testiranju enote bi morali testirati samo funkcionalnost enega razreda, če vaše metode izvor-a, izvor-b in izvor-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 seboj, 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 podatki so pravilno združeni).

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

Tudi če ste tako tolerantni, da lahko program po okvari v pol ure ponovno zaženete 18-krat in šele nato vržete monitor točno v okno, se strinjate, da bi bilo delo s tem programom bolj udobno, če ne bi “ padec«.

Kako narediti tako, da postanejo primeri padca, zmrzovanja, neizvajanja potrebnih dejanj programa, ki ste ga razvili, zelo redki?

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

In to orodje se imenuje Testiranje programskih izdelkov.

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 programske opreme.

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, podpora inženirji, marketing, usposabljanje in prodajalci. 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 iz postavitve problema zagotavljanja kakovosti izdelka izhaja naloga identifikacije deležnikov, njihovih kriterijev kakovosti in nato iskanje 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 kraljevski posel. Programski izdelek naj testirajo posebej usposobljeni zaposleni, imenovani preizkuševalci, saj tudi najbolj izkušen razvijalec ne bo mogel videti svoje napake, tudi z uporabo najnovejših optičnih instrumentov.

Kljub temu se vsi razvijalci strinjajo, da je treba testiranje programskega izdelka glede na razvrstitev po ciljih razdeliti na dva razreda:

• Funkcionalno testiranje
• Nefunkcionalno testiranje

Funkcionalno testiranje

Funkcionalno testiranje se razume kot preverjanje skladnosti programskega izdelka s funkcionalnimi zahtevami, določenimi v projektni nalogi za izdelavo tega izdelka. Poenostavljeno povedano, funkcionalno testiranje preveri, ali programski izdelek opravlja vse funkcije, ki bi jih moral.

Torej ste se odločili za izvedbo funkcionalnega testiranja. Pogledate referenčno nalogo, preberete funkcionalne zahteve in razumete, da vsaj niso v vrstnem redu, v katerem lahko testirate. Presenečeni boste, da so drugi že zdavnaj opazili to neskladje in ugotovili, kako ga preseči.

Za izvedbo funkcionalnega testiranja osebje službe tehničnega nadzora razvije dokumentni program in metodo za testiranje funkcionalnosti aplikacije (API). Dokument PMI vsebuje seznam scenarijev testiranja programskih izdelkov (testnih primerov) s podrobnim opisom korakov. Za vsak korak testnega scenarija so značilna dejanja uporabnika (strokovnjaka za testiranje) in pričakovani rezultati - odziv programa na ta dejanja. Program in testna metodologija morata simulirati delovanje programskega izdelka v realnem načinu. To pomeni, da mora biti testni skript zgrajen na podlagi analize operacij, ki jih bodo izvajali prihodnji uporabniki sistema, in ne sme biti umetno sestavljeno zaporedje manipulacij, ki so razumljive le 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 takšne lastnosti programskega izdelka, kot sta na primer 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 projektne naloge za njegovo izdelavo. In, tako kot v primeru funkcionalnega testiranja, sta za nefunkcionalno testiranje razvita program in testna metodologija.

Testiranje in skladnost vgrajene programske opreme v dobi Agile

Skladnost z industrijskimi standardi ni nekaj, kar bi lahko zanemarili ali naredili pozneje; je sestavni del procesa razvoja vgrajene programske opreme (SW). Za nekatere industrije - kot so letalska elektronika, avtomobilska industrija in zdravstvo - postaja dosledno upoštevanje standardov kakovosti pri razvoju kompleksnih in brezhibnih vgrajenih sistemov ključen pogoj za dajanje izdelka na trg. Tradicionalno je imelo testiranje pomembno vlogo pri razvoju vgrajenih sistemov za industrije, ki temeljijo na standardih. Vendar so se v zadnjih letih ustaljene prakse in procesi testiranja, njihovo mesto in vloga v tovrstnih projektih močno spremenili. Dramatično je spremenila vsa pravila igre in ko se pravila igre spremenijo, se moraš z njimi spremeniti tudi ti, da zmagaš.

Z novimi, najsodobnejšimi tehnologijami, ki se nenehno razvijajo, morajo podjetja hitro dati na trg izdelke, ki so zanesljivi, varni, enostavni za uporabo in interoperabilni – samo da se ne izgubijo v hitrem tempu tehnološki svet. V takšnih razmerah tradicionalni slapni model, kjer je proces razvoja programske opreme strogo zaporeden in se testiranje izvaja čisto na njegovem koncu, postaja preteklost. Metode DevOps in Agile postajajo vse bolj priljubljene, saj inženirjem omogočajo izvajanje nalog, ki so si sledile hkrati.

Testiranje delovanja

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

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 – volumetrijsko 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 zmožnost vrnitve v normalno delovanje po kratkih obdobjih stresnih obremenitev.

Dokumentacija za testiranje

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

Za testiranje se razvije testni primer, ki mora vsebovati dovolj podatkov za testiranje vseh načinov delovanja programskega izdelka. Običajno testni primer izdelata skupaj naročnik in izvajalec na podlagi realnih 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, v katerega se vnesejo podatki o prehodu vseh faz in korakov testiranja ter pripombe, prejete med preskusi.

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

Raziskovalno testiranje

Eksploratorno 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. Eksploratorno testiranje je vrhunec testiranja programske opreme. Na voljo je visokokakovostno testiranje visoko usposobljenim strokovnjakom in je skoraj popolnoma odvisna od izvajalca, njegovih izkušenj, znanja (tako na predmetnem področju kot v metodah testiranja), sposobnosti hitrega prodiranja v bistvo.

Stresno testiranje

Obremenitveno testiranje je proces analiziranja delovanja preskušanega sistema pod vplivom obremenitev. Cilj testiranja obremenitve je ugotoviti sposobnost aplikacije, da prenese zunanje obremenitve. Običajno se testi izvajajo v več fazah.

1. Generiranje 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 izpostaviti kriterije za ocenjevanje uspešnosti (hitrost odziva, čas obdelave zahtevka itd.).

3. Izvedba testnega testa

Pri izvajanju testov je pomembno, da pravočasno spremljamo izvajanje skript in odzivnost testiranega sistema. Za posnemanje velikih obremenitev je potrebna resna strojna in programska infrastruktura. 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 podjetja Worksoft) so večja kadrovska učinkovitost, zgodnejše odkrivanje napak in večja kakovost poslovnih procesov. Te prednosti odtehta pomembna pomanjkljivost: visoki stroški – zaradi visokih stroškov implementacije in vzdrževanja avtomatizacije testiranja približno 50 % podjetij še vedno uporablja večinoma ročno testiranje.

Testiranje uporabnosti

Vsaka aplikacija je narejena 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, kar pomeni za največje število uporabnikov. Za spletne aplikacije se običajno izbere testiranje združljivosti med brskalniki. Za Windows aplikacije - testiranje na različnih operacijskih sistemih in bitnosti (x86, x64). Pomemben sestavni del testiranja konfiguracije je testna infrastruktura: za testiranje 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 interakcije med deli programa. Testiranje se doseže z razvojem in izvajanjem "skozi" primerov. 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 normalnega delovanja. Ko je meja presežena, sistem preide v stanje stresa in bistveno spremeni svoje obnašanje. Stresno testiranje preverja delovanje aplikacije v pogojih preseganja meja normalnega delovanja. To je še posebej pomembno za "kritične" programe: bančniško programje, programe letalske industrije in medicino. Stresno testiranje se izvaja ne le 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 funkcionalnega testiranja upravičeno zaseda vodilni položaj, saj mora program najprej pravilno delovati, sicer ne bo nobenega smisla zaradi enostavnosti uporabe, varnosti in zadostne hitrosti. Poleg obvladovanja različnih tehnik testiranja mora vsak specialist razumeti, kako pravilno testirati, da bi dosegli 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 ;

Na "negativnih" ali "pozitivnih" testih.

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«, s testom pa ugotavljajo okoliščine, v katerih obnašanje programa ne bo v skladu s specifikacijo. Vse napake ugotavlja upravljanje podatkov, ki se izvaja s pomočjo izčrpnega testiranja, torej z uporabo vseh možnih

Če je za program izvajanje ukaza odvisno od dogodkov pred njim, bo potrebno preveriti vsa možna zaporedja. Povsem očitno je, da je v večini 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 odsotnost odstopanj od specifikacij.

Funkcionalno testiranje vključuje pravilno izbiro testa. Hkrati je običajno razlikovati med takšnimi metodami oblikovanja sklopov zanje:

Analiza mejnih vrednosti;

Enakovredna particija;

Ugibanje o napaki;

Analiza odnosov 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 specialista določeno ustvarjalnost, pa tudi specializacijo na tem 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 zazna napako, jo bodo pokazali tudi enakovredni razredi. Funkcionalno testiranje s strani ta metoda poteka v dveh fazah: v prvi se izberejo ekvivalenčni razredi, v drugi pa se že oblikujejo posebni testi.

Analiza odnosov vzroka in posledice. Sistem lahko zaradi takih preverjanj izbere teste z visoko zmogljivostjo. V tem primeru je ločen vhodni pogoj vzet kot vzrok, izhodni pogoj pa 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 posledic.

• nenamerno odstopanje razvijalcev od delovnih standardov ali izvedbenih načrtov;
• specifikacije funkcionalnih in vmesnikovskih zahtev se izvajajo brez upoštevanja razvojnih standardov, kar vodi do motenj v delovanju programov;
• organizacija razvojnega procesa - nepopolno ali nezadostno upravljanje z viri (človeškimi, tehničnimi, programskimi itd.) s strani vodje projekta ter vprašanja testiranja in integracije elementov projekta.

Oglejmo si postopek testiranja na podlagi priporočil standarda ISO/IEC 12207 in naštejmo vrste napak, ki jih najdemo pri posameznem procesu življenjskega cikla.

Proces razvoja zahtev. Pri določanju začetnega koncepta sistema in začetnih zahtev za sistem se med specifikacijo pojavljajo analitične napake. najvišji nivo sistemov in izgradnja konceptualnega modela predmetnega področja.

Tipične napake tega postopka so:

• neustreznost specifikacije zahtev za končne uporabnike, - nepravilna specifikacija interakcije programske opreme z operacijskim okoljem ali z uporabniki;
• neskladje med zahtevami strank glede individualnih in splošnih lastnosti programske opreme;
• napačen opis funkcionalnih značilnosti;
• pomanjkanje orodij za vse vidike implementacije zahtev kupca itd.

Proces oblikovanja.Napake pri načrtovanju komponent se lahko pojavijo pri opisovanju algoritmov, krmilne logike, podatkovnih struktur, vmesnikov, logike za modeliranje podatkovnih tokov, vhodno-izhodnih formatov itd. Te napake temeljijo na napakah v specifikacijah analitikov in pomanjkljivostih oblikovalcev. 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 kompleksa komponent);
• z opredelitvijo procesa procesiranja informacij in interakcije med procesi (posledica napačne definicije odnosov med komponentami in procesi);
• z nepravilno dodelitvijo podatkov in njihovih struktur pri opisu posameznih komponent in PS kot celote;
• z napačnim opisom algoritmov modula;
• z opredelitvijo pogojev za nastanek morebitnih napak v programu;
• v nasprotju s standardi in tehnologijami, sprejetimi za projekt.

Stopnja kodiranja.Na tej stopnji se pojavljajo napake, ki so posledica konstrukcijskih napak, napak programerjev in vodij v procesu razvoja in odpravljanja 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 istega imena za označevanje različnih objektov ali različna imena istega 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 paketov in testnih scenarijev itd. Napake programske opreme, ki jih povzročijo takšne napake, je treba zaznati, odpraviti in se ne odražati v statistiki napak komponent in programske opreme. na splošno.

Postopek vzdrževanja.Med postopkom vzdrževanja se odkrijejo napake, ki so posledica pomanjkljivosti in napak 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 v 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;
• I/O in napake pri 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 poizvedbe ali časa obnovitve programa.

V/I napake in manipulacije s podatki so posledica nekvalitetne priprave podatkov za izvajanje programa, napak pri vnosu v bazo ali pri pridobivanju iz nje.

Napake vmesnika se nanašajo na napake v medsebojnem povezovanju posameznih elementov med seboj, kar se kaže pri prenosu podatkov med njimi, pa tudi pri interakciji z delujočim 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. Torej, pri delu z bazo podatkov prihaja do napak pri predstavitvi in ​​manipulaciji podatkov, logične napake pri nalogi aplikativnih postopkov obdelave podatkov itd. V programih računske narave 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 obsega so običajne 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 sedanji stopnji razvoja podpornih orodij za razvoj programske opreme (CASE-tehnologije, objektno orientirane metode in orodja za načrtovanje modelov in programov) se izvaja takšna zasnova, pri kateri je programska oprema zaščitena pred najpogostejšimi napakami in s tem onemogočena pojav programskih napak.

Povezovanje napake z napako.Prisotnost napake v programu praviloma vodi do okvare 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, ki so nastale v določenem razvojnem procesu, in napak na objektu, ki so 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 vzročnosti med napakami in napakami je opredeliti metode in orodja za testiranje in odkrivanje napak določenih razredov, kot tudi merila za dokončanje testiranja na nizu nizov podatkov; pri določanju načinov za izboljšanje organizacije procesa razvoja, testiranja in vzdrževanja programske opreme.

Podajamo naslednjo klasifikacijo vrst okvar:

• strojna oprema, v kateri sistemska programska oprema ne deluje;
• informacijske, ki nastanejo zaradi napak v vhodnih podatkih in prenosu podatkov po komunikacijskih kanalih, pa tudi ob okvarah vhodnih naprav (posledica okvar strojne opreme);
• ergonomski, ki ga povzročajo napake operaterja pri interakciji s strojem (ta okvara je sekundarna okvara, ki lahko povzroči informacijske ali funkcionalne napake);
• programske opreme, če so napake v komponentah itd.

Nekatere napake so lahko posledica napak v definiciji zahtev, oblikovanju, ustvarjanju izhodne kode ali dokumentaciji. Po drugi strani pa nastanejo med razvojem programa ali med razvojem vmesnikov za posamezne elemente programa (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 napak v definiciji zahtev, načrtovanju, ustvarjanju kode ali dokumentaciji. Po drugi strani pa napake nastanejo 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 pojav napak je nerazumevanje zahtev kupca; netočne specifikacije zahtev v projektni dokumentaciji ipd. To vodi do tega, da so implementirane nekatere sistemske funkcije, ki ne bodo delovale tako, kot predlaga naročnik. V zvezi s tem poteka skupna razprava med stranko in razvijalcem o nekaterih podrobnostih zahtev za njihovo pojasnitev.

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