Definicija testa prihvatljivosti. Izrada dokumentacije, izrada i ispitivanje prototipova. Skup standarda za automatizirane sustave

Obično ovo testiranje obavlja drugi tim koji ručno ili drugim alatom ponavlja puno onoga što je pokriveno automatskim testiranjem prihvaćanja. To se može učiniti jer se testovi prihvatljivosti ne mogu lako izvoditi u različitim okruženjima ili razvojni tim ne može lako razumjeti što testovi rade, a korišteni podaci skriveni su u kodu, što otežava pronalaženje ili promjenu. Skrivanje namjere testa u kodu otežava razumijevanje onoga što test pokušava učiniti.

To također znači da članovi netehničkog tima ne mogu lako doprinijeti testiranju, a tehnički ljudi provode više vremena na automatiziranom testnom kodu. Kada se testovi trebaju refaktorirati, što je neizbježno jer odvajaju namjeru od načina implementacije, možete se usredotočiti na refaktoriranje provedbe testa, a ne na ono što bi test trebao učiniti.

Razdvajanje namjere, provedbe i podataka

Ispod je dijagram koji ilustrira ideju razdvajanja namjere, provedbe i podataka. Uključeno je i okruženje jer je važno razumjeti u kakvom će se okruženju izvoditi testovi te, ako je potrebno, promijeniti podatke i pokrenuti test. Stvaranje namjere mogu napraviti netehnički članovi tima na jeziku koji je neovisan o implementaciji. To je važno jer znači da se implementacija može refaktorirati bez promjene namjere testa. Vrijedi i obrnuto; moguće je promijeniti namjeru testa bez utjecaja na implementaciju, pod uvjetom da postoji implementacija koja zadovoljava sve riječi u odlomku o namjeri.

Ako, u najgorem slučaju, odlučite izbaciti cijelu implementaciju i početi ispočetka, još uvijek možete zadržati namjeru testiranja i stoga ne izgubiti najvažniji dio automatiziranih testova, ono što testovi pokušavaju napraviti. Podaci se također moraju razdvojiti u namjere i implementacije, na taj način se podaci mogu specificirati u testu apstrakcijom, a zatim se implementacija uklanja. Na primjer, test može ukazivati ​​da "zlatni klijent", kako je klijent identificiran, nije dio testa, već je dio podatkovnog sloja.

Stvaranje podatkovnog sloja i apstrakcija podataka nisu nove tehnike; obično se koriste za programski kod i trebaju se primijeniti na automatizirane testove jer se prednosti još uvijek primjenjuju. U testnom slučaju, podatkovni sloj se poziva da dohvati podatke iz izvora podataka za odgovarajući tip klijenta.

Testni slučaj zatim ponavlja sve unose na popisu i provodi test na svakom unosu korisnika. Testovi sustava odgovaraju jednoj od razina testiranja softvera u kombinaciji s različitim testovima kao što su oporavak, sigurnost, otpornost, performanse, povezanost, volumen, napon, dostupnost podataka, jednostavnost korištenja, rad, Okoliš, pohranu, konfiguraciju, instalaciju i dokumentaciju. Svaki ima drugačiju svrhu i zajedničku svrhu koja pokazuje sustavnu viziju projekta. Testiranje prihvatljivosti je još jedna vrsta razine koju nadopunjuju razine softverskog testiranja, ovi testovi su vrlo temeljni jer će nam omogućiti da dobijemo proizvod koji zadovoljava tražene standarde i koji istovremeno zadovoljava zahtjeve korisnika u skladu s zahtjeve koje su postavili od samog početka . To prisiljava sustav da testira vitalni proces testiranja, jer u smislu proizvoda, broja grešaka i ozbiljnosti tih bugova, to je korak u razvoju koji je obično sklon većini bugova. Slika 1: Provjera iterativnih sustava Testovi sustava nisu procesi za provjeru funkcionalnosti sustava ili cijeli program, jer bi to bilo suvišno s procesom funkcionalnog testiranja. Testovi sustava imaju specifičnu svrhu: usporediti sustav ili program s njegovim izvornim ciljevima. U tu svrhu prikazane su dvije vrijednosti. Testiranje sustava nije ograničeno na sustave. Ako je proizvod program, testiranje sustava je pokušaj da se pokaže kako program u potpunosti ne ispunjava svoje ciljeve ili zahtjeve. Testovi sustava, po definiciji, nisu mogući osim ako ne postoje pisani zahtjevi koji su mjerljivi za proizvod. Testiranje sustava je faza istraživanja u kojoj se osigurava da svaka komponenta ili modul komunicira s drugim komponentama ili modulima kako je predviđeno. Testovi sustava usmjereni su na dubinsku implementaciju sustava, provjeru integracije informacijskog sustava diljem svijeta, provjeru ispravnog funkcioniranja sučelja između različitih podsustava koji ga čine i s drugim informacijskim sustavima s kojima komunicira. Klasični problem testiranja sustava je "upiranje prstom". To se događa kada se otkrije greška i programer svakog elementa sustava krivi druge. Umjesto da padne u ovaj apsurd, softverski inženjer trebao bi predvidjeti mogući problemi sa sučeljem:  put rukovanja projektantskim pogreškama koji provjerava sve informacije koje dolaze iz drugih elemenata sustava. Testiranje i testiranje sustava 6  Primijenite niz testova koji simuliraju loše podatke ili drugo moguće pogreške u softverskom sučelju.  Registrirajte rezultate ispitivanja kao dokaz u slučaju krivnje.  Sudjelovati u planiranju i razvoju testiranja sustava kako bi se osiguralo da je softver ispravno testiran. Zapravo, test sustava pokriva niz različitih testova čija je glavna svrha dubinsko izračunavanje sustava tijekom računanja. Iako svaki test ima drugačiju svrhu, svi oni rade kako bi bili sigurni da su svi elementi sustava pravilno integrirani i da obavljaju odgovarajuće funkcije. 2 Pregled sustava testa. Prilikom testiranja potrebno je održavati sustav, odnosno cjelovit pristup razvoju softvera. Primjenom ovih koncepata na test softvera dobiva se skup principa koji će poslužiti kao osnova za test: morate biti sigurni da znate točno ciljeve softvera koji se testira, kao i stope uspjeha. Ti se elementi nalaze u dokumentima dobivenim tijekom faze prikupljanja zahtjeva, kao iu specifikacijama softvera. Ove informacije će biti potrebne za pripremu plana testiranja i predstavljat će osnovu za pokretanje razvoja testnog slučaja. Ulazi i izlazi odobrenog sustava moraju biti definirani. Ovaj aspekt je neophodan u pripremi test slučajeva, kao i u kreiranju testnih procedura, posebno orijentiranih test slučajeva koji pokazuju ispunjenost ciljeva. Razmislite o glavnom sustavu na kojem se testira softver koji se testira. Obično je to organizacijsko okruženje koje se sastoji od hardvera, softvera i ljudi. Svi ovi elementi imaju veliki utjecaj na sustav, a posebno pomažu u pripremi test slučajeva nepoželjnih situacija povezanih s neadekvatnim podacima, nedostatkom potrebnih elemenata i pojava izuzetaka. 3 Pregled testiranja sustava Proces testiranja sustava sastoji se od dvije faze koje mogu biti vrlo odvojene tijekom vremena: priprema testa i primjena testa. Prvi je usko povezan sa zahtjevima pa se događa u ranoj fazi projekta, a drugi zahtijeva cijeli sustav ili barem jednu integraciju jer se kaže da je djelomični proizvod neobjavljeni kako bi mogao primijeniti testove pa se to događa u naprednim fazama projekt. Točna situacija s ovim dijelovima ovisi o odabranom modelu. životni ciklus. Za obavljanje druge i treće aktivnosti potreban je dokument o zahtjevima. Prva faza testiranja daje povratne informacije za analizu zahtjeva, identificiranje praznina, nejasnoća i drugih problema. Također pruža vrijedne savjete o dizajnu i implementaciji sustava ako ga tek razvijate. Faza testne aplikacije zahtijeva plan testiranja i izvršnu verziju sustava. U tom slučaju će se primijeniti pripremljeni testni slučajevi, analizirati rezultati i identificirati sve nedostatke. Ovaj drugi korak daje povratne informacije o implementaciji i dizajnu, pokazujući moguće nedostatke koje je potrebno popraviti. Također pruža informacije koje će biti korisne za izdavanje sustava, njegovo usvajanje, procjenu njegove pouzdanosti i održavanje. Slika 1 prikazuje proces testiranja sustava i njegov odnos s drugim procesima. Druga je točka važna jer se ponekad test sustava miješa s testom sučelja. Prvi provjerava interakciju svih dijelova, a drugi analizira elemente sučelja i, eventualno, obradu povezanih događaja. Međutim, alati koji pomažu u testiranju sučelja mogu se koristiti za pokretanje testova sustava. Postavlja se nekoliko pitanja: koliko će slučajeva biti dovoljno? Kako generirati najmanje moguće? Koje su vrijednosti prikladne? Testiranje i testiranje sustava 9 1 Plan testiranja Plan testiranja je vrlo važan dokument tijekom testiranja softvera. Objašnjava ciljeve i pristupe testiranju, plan rada, operativne postupke, potrebni alati i odgovornosti. Testiranje i testiranje sustava 10 Dokument sa zahtjevima trebao bi sadržavati popis funkcija koje softver treba izvršiti, opisujući ih i postavljajući im prioritete; također bi trebao uključivati ​​nefunkcionalne zahtjeve, koji mogu uključivati ​​organizacijske, operativne i druge aspekte. Dobro pripremljen dokument sa zahtjevima trebao bi osigurati način na koji svaki zahtjev može potvrditi da je ispunjen. U slučaju značajki, to bi bio opis, a u slučaju nefunkcionalnih zahtjeva, to bi mogle biti vrlo precizne specifikacije kao što je vrijeme odziva. Za sada ćemo se usredotočiti na funkcionalne zahtjeve, a ostalo ćemo ostaviti za kasniji dio. Testovi sustava važni su zbog sljedećih čimbenika:  To je sustav koji se testira kao cjelina unutar životnog ciklusa razvoja sustava.  Sustav se provjerava usklađenost s njegovim funkcionalnim i tehnički zahtjevi .  Sustav se testira u okruženju koje je što bliže proizvodnom okruženju.  Testovi sustava omogućuju vam testiranje, provjeru valjanosti i validaciju poslovnih zahtjeva i arhitekture aplikacije. 6Vrsta testova sustava Funkcionalni testovi  Integracijski test. - U kojoj ispitna oprema ima pristup izvornom kodu sustava. Kada se otkrije problem, integracijski tim pokušava pronaći izvor problema i odrediti komponente koje je potrebno otkloniti. Integracijsko testiranje se uglavnom bavi pronalaženjem nedostataka u sustavu.  Dokaz o isporuci. Ovdje je verzija sustava koja se može isporučiti korisniku. Ovdje se testni tim bavi provjerom da sustav ispunjava svoje zahtjeve i jamči pouzdanost sustava. Testovi isporuke su obično testiranje crne kutije, u kojem se ispitna oprema jednostavno brine o tome radi li sustav ispravno. Komponente koje se mogu integrirati mogu biti komercijalne komponente, višekratne komponente prilagođene određenom sustavu ili novorazvijene komponente. Za mnoge velike sustave vjerojatno će koristiti sve tri vrste komponenti. Integracijski test potvrđuje da te komponente zapravo rade zajedno, da se ispravno pozivaju i da točne podatke u točno vrijeme prosljeđuje kroz njihova sučelja. Integracija sustava uključuje identificiranje skupina komponenti koje pružaju neke funkcije sustava i njihovu integraciju dodavanjem kodova za zajednički rad. Ponekad se prvo razvije kostur cijelog sustava, a komponente se dodaju. To se zove postintegracija. Ovo je integracija prema gore. U praksi, za mnoge sustave, strategija integracije je kombinacija oboje, dodavanjem dodatnih infrastrukturnih komponenti i funkcionalnih komponenti. Oba integracijska pristupa zahtijevaju dodatni kod za modeliranje drugih komponenti i omogućavanje pokretanja sustava. Glavna poteškoća s kojom se susreću tijekom integracijskih testova je lokacija bugova. Postoje složene interakcije između komponenti sustava, a kada se otkrije anomalan izlaz, može biti teško odrediti gdje se pogreška dogodila. Kako biste lakše izolirali greške, uvijek biste trebali koristiti inkrementalni pristup integraciji i testiranju sustava. Glavna svrha ovog procesa je povećati povjerenje dobavljača da sustav ispunjava njegove zahtjeve. Ako je tako, može se isporučiti kao proizvod ili isporučiti kupcu. Kako bi se pokazalo da sustav ispunjava svoje zahtjeve, mora se pokazati da isporučuje specificiranu funkcionalnost, performanse i pouzdanost te da ne pokvari pri normalnoj uporabi. Testovi isporuke obično su proces testiranja crne kutije u kojem su testovi izvedeni iz specifikacije sustava. Sustav se promatra kao crna kutija čije ponašanje treba utvrditi samo ispitivanjem njegovih odgovarajućih ulaza i izlaza. Drugi naziv za ovo je funkcionalno testiranje jer tester zanima samo funkcionalnost, a ne implementacija softvera. Na sljedećoj slici vidjet ćemo ilustraciju modela sustava koji omogućuje u provjeravanju crne kutije. Tester predstavlja ulaze za komponentu ili sustav i razmatra ulaze. U nekim slučajevima sustav mora biti otporan na greške; odnosno kvarovi u obradi ne bi trebali dovesti do kvarova sustava u cjelini. Ispitni sustavi i testovi prihvaćanja 14 Kvar sustava mora se ispraviti unutar određenog vremenskog razdoblja ili će uzrokovati ozbiljnu ekonomsku štetu. Test oporavka je test sustava koji uzrokuje neuspjeh softvera na nekoliko načina i provjerava je li oporavak ispravno izveden. Ako se oporavak dogodi automatski, morate provjeriti jesu li ponovna inicijalizacija, mehanizmi sigurnosnog kopiranja sustava, oporavak podataka i ponovno pokretanje ispravni. Ako oporavak zahtijeva ljudsku intervenciju, mora se odrediti prosječno vrijeme oporavka kako bi se utvrdilo je li ono unutar prihvatljivih granica. Cilj je uspostaviti krajnje točke na kojima sustav počinje raditi ispod specificiranih zahtjeva. Ovo se ne smije miješati s testom volumena; visoki napon je maksimalna količina podataka ili aktivnosti po kratko vrijeme. Analogija bi bila ocjenjivanje daktilografa. Test volumena će se odrediti ako se daktilograf suoči s nacrtom velikog izvješća; stres test će odrediti može li daktilograf tipkati s indeksom od 50 riječi u minuti. Kršenje uključuje širok raspon aktivnosti:  Haker koji se pokušava prijaviti po igri. Sigurnosni test potvrđuje da ga sigurnosni mehanizmi ugrađeni u sustav zapravo štite od neprikladnih upada. "Sustavi se moraju testirati na sigurnost sustava kako bi bili imuni na frontalne napade, ali i na one koji čine bokove ili straga." Tijekom sigurnosnog testa, svatko tko ga primijeni igra ulogu osobe koja se želi prijaviti. Sve ovo vrijedi! Trebali biste pokušati dobiti sve lozinke vanjskim sredstvima; može napasti sustav pomoću posebnog softvera dizajniranog da zaobiđe bilo koju zaštićenu arhitekturu; on može zasititi sustav, uskratiti služenje drugima; može dovesti do namjernih pogrešaka u sustavu kako biste pokušali dobiti pristup tijekom oporavka: možete pregledavati podatke bez zaštite, s idejom da tražite lozinku za sustav. Ako se da dovoljno vremena i resursa, sustav će na kraju dobar test za sigurnost. Uloga dizajnera sustava je da je trošak prekida veći od cijene primljene informacije. Međutim, analiza ljudskih čimbenika ostaje vrlo subjektivan problem. Testni slučajevi imaju za cilj pokazati da ti ciljevi pohrane nisu pronađeni. Često je broj mogućih konfiguracija prevelik za testiranje svake od njih, ali ako je moguće, trebali biste testirati program sa svakom vrstom hardverskog uređaja i s minimalnom i maksimalnom konfiguracijom. Ako se sam program može konfigurirati da preskače komponente ili ako se može izvoditi na više računala, svaka konfiguracija mora biti testirana. Testiranje instalacijskih postupaka važan je dio procesa testiranja sustava. To se posebno odnosi na sustav automatska instalacija uključeno u programski paket. Neispravno pokrenut instalacijski program može spriječiti korisnika u uspješnom radu sa sustavom. Prvo iskustvo korisnika je kada on ili ona instalira aplikaciju. Jedan od načina da se to postigne je korištenje dokumentacije za definiranje pogleda prethodnih testnih slučajeva sustava. To jest, nakon što želite razviti slučaj preopterećenja, trebali biste koristiti dokumentaciju kao vodič za pisanje stvarnog testnog slučaja. Osim toga, korisnička dokumentacija treba biti podvrgnuta ispitivanju točnosti i jasnoće. Bilo koji od primjera prikazanih u dokumentaciji treba testirati i dodati na popis obveza i uključiti u program. Ispitivanje i testiranje sustava 17 operativnog gledišta, nakon usvajanja sustava u stvarnom okruženju i na temelju usklađenosti s navedenim nefunkcionalnim zahtjevima. Testiranje otpornosti osmišljeno je za suzbijanje programa u nenormalnim situacijama. U biti će pitati osoba koja radi test otpornosti. Koliko ćete dogurati prije nego što ne uspije? Test otpora provodi sustav na takav način da zahtijeva nenormalnu količinu, učestalost ili količinu resursa. Na primjer:  razvijeni su posebni testovi koji generiraju 10 prekida u sekundi kada je prosječna šalica jedna ili dvije.  Učestalost unosa podataka povećava se za iznos koji će omogućiti odgovore na funkcije unosa.  Pokrenite testne slučajeve koji zahtijevaju maksimalnu memoriju ili druge resurse.  Testni slučajevi dizajnirani su za rješavanje problema s upravljanjem memorijom. Stvaraju se testni slučajevi koji uzrokuju prekomjerno pretraživanje diska. Slika je primjer testa otpornosti. Test izvedbe primjenjuje se u svim fazama procesa testiranja. Čak i na razini jedinice. Izvedbu pojedinog modula treba ocijeniti tijekom testiranja. Međutim, tek nakon što su svi elementi sustava potpuno integrirani mogu se postići istinske performanse sustava. Testovi performansi često uključuju testiranje otpornosti i često zahtijevaju softverske i hardverske upute. Odnosno, često je potrebno točno izmjeriti korištenje resursa. Koristeći vanjske alate, možete redovito pratiti intervale pokretanja, zabilježene događaje i status uzoraka hardvera. Ovi testovi se provode kako bi klijent potvrdio da sustav za njega vrijedi. Detaljno planiranje ovih testova trebalo bi biti provedeno u ranoj fazi razvoja s ciljem korištenja rezultata kao pokazatelja njihove valjanosti: ako se dokumentirani testovi izvode na zadovoljstvo korisnika, proizvod se smatra ispravnim i stoga prikladnim za stavljanje u proizvodnja. 6 Testovi prihvatljivosti2 su u osnovi funkcionalni testovi na cijelom sustavu i imaju za cilj provjeriti je li utvrđenim zahtjevima . Njegovo izvođenje je izborno za klijenta, a u slučaju da nisu eksplicitno specificirani, uključeni su u testove sustava. Odnosno, testovi prihvaćanja često su odgovornost korisnika ili kupca, iako ih može izvesti svatko tko je uključen u posao. Testiranje prihvaćanja zahtijeva testno okruženje koje predstavlja proizvodno okruženje. Ova faza ili razina kao početna točka definira osnovnu liniju prihvaćanja proizvoda već uspostavljenu u certifikacijskom okruženju. Ispitivanje i prihvaćanje sustava 19 Slika - Kontrola prihvaćanja. 1 Ispitivanje trenutnog stanja u testovima prihvatljivosti. U sklopu testova moramo provjeriti softver, jedno od najvažnijih je testiranje prihvatljivosti. Riječ je o testovima koje razvija sam razvojni tim na temelju funkcionalnih zahtjeva navedenih u fazi analize kako bi pokrili cijeli spektar i proveli ih krajnji korisnik, ali ne svi, nego nekoliko korisnika, imaju značajan rezultat koji daje valjanost i sukladnost s proizvodom koji im se isporučuje na temelju onoga što je prvotno ugovoreno. Ovisno o složenosti sustava koji se testira, bez obzira na to je li podijeljen na module itd. izvođenje ovih testova se izvodi drugačije. Kada bi se aplikacija podijelila na module, oni bi se smatrali podsustavima i bili bi dovoljno složeni da se njima može drugačije rukovati, morale bi se provoditi različite sesije testiranja prihvatljivosti. 2 Svrha testiranja prihvatljivosti Testiranje prihvaćanja ima za cilj dobiti konačno prihvaćanje od strane kupca prije isporuke proizvoda za početak proizvodnje. Kada organizacija provede testove sustava i popravi većinu njegovih nedostataka, sustav će biti isporučen korisniku ili kupcu na odobrenje. Svrha testiranja prihvaćanja je provjeriti zadovoljava li sustav očekivane performanse i omogućiti korisniku tog sustava da utvrdi njegovu prihvaćanje u smislu njegove funkcionalnosti i performansi. Testove prihvaćanja određuje korisnik sustava, a priprema ih razvojni tim, iako je konačna izvedba i odobrenje na korisniku. Provjera valjanosti sustava postiže se izvođenjem testova crne kutije koji pokazuju usklađenost i uključeni su u plan testiranja koji definira provjere valjanosti koje treba izvršiti i njihove pridružene testne slučajeve. Ovaj plan je osmišljen kako bi osigurao da su ispunjeni svi funkcionalni zahtjevi koje je odredio korisnik, kao i nefunkcionalni zahtjevi koji se odnose na performanse, sigurnost pristupa sustavu, podataka i procesa, te različitih resursa sustava, 3 Generacija testiranja prihvatljivosti. Korisnik mora prihvatiti sustav. Iz tog razloga, na temelju strukturiranih specifikacija sustava, analitičar kreira skup test slučajeva koji moraju proći na zadovoljavajući način. Budući da se testovi prihvatljivosti mogu razvijati paralelno s projektiranjem i aktivnostima u praksi, normalno je da analitičar započne te aktivnosti čim se završi aktivnost strukturirane analize. 4 Strategije testiranja prihvatljivosti Ako je sustav dizajniran za masovno tržište, onda ne bi bilo praktično testirati ga za pojedinačne korisnike ili kupce, u nekim slučajevima to ne bi bilo moguće. U tim slučajevima potrebna je povratna informacija prije nego što se proizvod stavi u prodaju. Često takvi sustavi imaju dvije faze testiranja prihvatljivosti. Alfa i Beta testiranje Kada je prilagođeni softver napravljen za klijenta, provodi se niz testova prihvaćanja kako bi se klijentu omogućilo testiranje svih zahtjeva. Izvodi klijent na mjestu razvoja. Softver se prirodno koristi s razvojnim programerom kao korisnikovim promatračem, zajedno s pogreškama pri registraciji i problemima s korištenjem. Alfa testovi se provode u kontroliranom okruženju. Radite u kontroliranom okruženju i klijent uvijek ima stručnjaka koji će vam pomoći u korištenju sustava. Programer prati pronađene greške i probleme s korištenjem. Β-beta testovi se provode nakon α-alfa testa i razvijaju se u okruženju klijenta. U tom slučaju, klijent ostaje sam s proizvodom i pokušava pronaći bugove koji obavještavaju programera. Izvode ih krajnji korisnici softvera na radnim stanicama korisnika. Za razliku od alfa testa, programer obično nije prisutan. Dakle, beta test je živa primjena softvera u okruženju koje razvojni programer ne može kontrolirati. Klijent bilježi sve probleme koji se javljaju tijekom beta testiranja i izvještava programere u redovitim intervalima. 5 Ulazi, izlazi, zadaci i uloge testa prihvatljivosti. Specifikacija zahtjeva za ulazak. Zadaci Pripremite testno okruženje. Preporučujemo da imate posebno testno okruženje za ovu vrstu testiranja. Instalacija u testnom okruženju. Testiranje i testiranje sustava 22 Odredite testove koje treba izvesti. Moguće ovisnosti koje postoje između testova bit će uspostavljene i redoslijed ili slijed u kojem će se testovi izvršavati bit će uspostavljeni na temelju tih ovisnosti. Primanje i bilježenje rezultata. Ispravljene greške i greške. Ponavljajte zadatak dok ne položite sve testove. Priprema izvješća o prihvatnom ispitivanju. Pregled ispravnosti izvođenja i rezultata svih dostavljenih testova. Stvaranje proizvodne baze. Formalno zatvaranje aktivnosti. Rezultati ispitivanja. Prihvaćeno izvješće o prihvaćanju proizvoda. Voditelj projekta. Fokus na testiranju prihvatljivosti povezan je s pokušajem da se učvrsti mišljenje da bi korisnik integriran u ovoj fazi, u ranoj fazi, pomogao poboljšati ovaj proces u fazi planiranja i dizajna testiranja, uz naknadna poboljšanja u mnogim kvantitativnim i poželjnim aspektima , kao što su: Poboljšanje kvalitete integrirane softverske sigurnosti. Minimizacija troškova. Povećana pouzdanost rezultata projekta. Kada koristite softver s manje pogrešaka, povećava se zadovoljstvo korisnika. To poboljšava učinkovitost procesa razvoja. 7 Kriteriji za ispitivanje prihvatljivosti. Prihvaćanje softvera postiže se nizom testova koji pokazuju da zadovoljavaju zahtjeve. Plan ispitivanja opisuje vrstu testa koji će se primijeniti, a ispitni postupak definira specifične testne slučajeve, i plan i postupak su osmišljeni kako bi osigurali da ispunjavaju sve funkcionalne zahtjeve, da su postignute sve karakteristike ponašanja, da su ispunjeni svi zahtjevi izvedbe, dokumentacija je ispravan i poštuje sve zahtjeve za jednostavnost korištenja i ostalo specificirani zahtjevi. 8 Alati za testove prihvatljivosti. To omogućuje kupcima, testerima i programerima da znaju što njihov softver treba raditi i da automatski uspoređuju ono što zapravo radi. Omogućuje vam pisanje testova koji se lako čitaju i održavaju. Ova aktivnost poznata je kao završni test ili test prihvaćanja. To zahtijeva unos podataka testa prihvatljivosti i integrirani sustav stvoren tijekom ove aktivnosti. Test će provesti neki član ili odjel korisnika, ili čak neovisni odjel za kontrolu kvalitete. Važno je napomenuti da je važno provesti aktivnosti kontrole kvalitete u svakoj od prethodnih analitičkih, projektnih i provedbenih aktivnosti kako bi se osiguralo da su provedene na odgovarajućoj razini kvalitete. To osigurava da analitičar proizvodi specifikacije kvalitete, da dizajner proizvodi kvalitetne dizajne i da programer proizvodi kvalitetne programe kodiranja. U informatici, implementacija je tehnička specifikacija ili algoritmi, kao što su program, softverska komponenta ili drugi računalni sustav. Mnoge implementacije pružaju se prema specifikaciji ili standardu. Sažimamo dosadašnji rad autora na dobivanju testnih ciljeva, koji su polazište za razvoj automatiziranih testova. U kontekstu testiranja sustava iz slučajeva korištenja, cilj testiranja može se izraziti kao slučaj korištenja. Ovaj će se scenarij sastojati od niza koraka bez moguće alternative i skupa testnih vrijednosti, i preduvjeti i postkonferencije vezane uz ovaj scenarij. Za generiranje testnih scenarija, najprije se gradi dijagram aktivnosti od glavnog slijeda i pogrešaka i alternativnih sekvenci slučaja upotrebe. U dijagramu aktivnosti, radnje koje izvodi sustav i radnje koje izvode sudionici su stereotipne. Zatim se provodi analiza puta i svaki put dijagrama aktivnosti bit će scenarij korištenja i stoga potencijalni cilj testiranja. 2 Provedba testova sustava. Arhitektura testiranja sustava. Arhitektura za izvođenje i automatsku provjeru valjanosti testova sustava prikazana je na slici 7. Ova arhitektura je slična arhitekturi potrebnoj za automatizaciju drugih vrsta testova, kao što su testovi jedinica. Glavna razlika je u tome što u jediničnom testu sam test poziva izvršni kod, dok funkcionalni test testnog sustava i prihvaćanje testa 27 zahtijeva posrednika koji zna kako manipulirati njegovim vanjskim sučeljem. Implementacija test slučajeva. Test-test je ostvarenje cilja testiranja. Općenito ponašanje za testni slučaj navedeno je u tablici Općenito ponašanje testnog slučaja. Svaki slučaj uporabe bit će povezan s testnim paketom. Ovaj paket će sadržavati testove za sve scenarije spomenutog slučaja upotrebe. Kao što se može vidjeti iz ciljeva testiranja, svaki korak mora biti specificiran da li ga izvodi akter ili sustav koji se testira. Ove informacije su vrlo važne za kodiranje metoda ispitivanja paketa. Sve akcije koje izvrši akter pretvaraju kod testnog koda u interakciju između testnog slučaja i sustava. Ispitivanje sustava i testiranje prihvatljivosti 29 Operativna i kategorička varijabla metodologija će se primijeniti za određivanje potrebnih vrijednosti ispitivanja. Troje je identificirano različite vrste operativne varijable. Svaki tip će se drugačije implementirati u testnim slučajevima. Prvi tip se sastoji od onih operativnih varijabli koje ukazuju na prijenos informacija u sustav od strane vanjskog entiteta. Za svaku varijablu ovog tipa bit će definirana nova klasa čiji će objekti sadržavati različite testne vrijednosti za ovu varijablu. Primjer ove vrste radne varijable prikazan je u studiji slučaja. Drugi tip se sastoji od onih operativnih varijabli koje ukazuju na izbor između više opcija dostupnih vanjskom akteru. Umjesto toga, takav izbor bit će implementiran izravno kao dio koda koji implementira interakciju između aktera i sustava. Treću vrstu čine one operativne varijable koje ukazuju na stanje sustava. Da biste implementirali metodu postavljanja testnog slučaja, napišite potreban kod za ispravno postavljanje vrijednosti operativnih varijabli koje opisuju stanja sustava ili za provjeru da se vrijednosti podudaraju. Slično, metoda break mora vratiti ove vrijednosti u njihova izvorna stanja. Osim toga, metoda praćenja mora isključiti, ako je potrebno, informacije koje je testni slučaj unio u sustav tijekom izvođenja testnog slučaja. Nekoliko primjera operativnih varijabli ovog tipa prikazano je u studiji slučaja. U ovom slučaju, prva stvar koju treba učiniti je primijeniti ono što je viđeno kako biste dobili skup ciljeva testa iz slučaja upotrebe. Zatim se određuju karakteristike korištenog ispitnog pojasa. Na kraju primjenjujemo ono što smo vidjeli prethodni odjeljci za implementaciju testnog slučaja iz testnog cilja. U sustavu koji je testiran identificirani su artefakti Engleski jezik, Ukoliko španjolski jezik nije podržano od korištenih alata. Slučaj korištenja u tablici 2 opisuje uvođenje nove veze u sustav. Kao dodatak, također je prikazan zahtjev za pohranjivanje informacija koje opisuju informacije kojima rukuje svaka poveznica. Iz slučaja upotrebe i automatski generiran skup scenarija koji će biti cilj testiranja navedenog slučaja upotrebe. S obzirom na to da slučaj korištenja ima neograničene petlje s beskonačnim brojem potencijalnih ponavljanja, kriterij pokrivenosti odabran za dobivanje cesta je kriterij 01, koji provjerava i testira testove sustava 30, sastoji se od dobivanja svih mogućih puteva za ponavljanje niti jednog ili jednog puta. svaka od petlji. Sve skripte dobivene korištenjem ovog kriterija i prevedene na španjolski su navedene u tablici. Za ovu studiju slučaja odabrali smo scenarij 09, koji je detaljno prikazan u tablici 5 za njegovu provedbu. Testiranje i testiranje u testiranju 31 Tablica Informacijski zahtjevi za reference. Također možete primijeniti metodu dijeljenja kategorija. Odjeljci za svaku od ovih varijabli navedeni su u tablici. Testiranje i testiranje sustava 32 Varijable tablice definirane za slučaj upotrebe. Testiranje i testiranje u testiranju 33 Tablica kategorija za identificirane varijable. Kao što je opisano na slici 7, test pojasa je dizajniran da simulira ponašanje korisnika i ponudi skup izjava za procjenu rezultata. Ovaj prijevod trenutno se radi ručno i prikazan je u tablici. Testiranje i testiranje primopredajnika 35 Slika Implementacija testnog slučaja. Prijevod u izvršni kod koraka koje je izvršio korisnik u glavnom scenariju. Odnosno, kako bismo bili sigurni da kategorije postoje i da ne postoje okolnosti koje uzrokuju pogrešku prilikom vraćanja kategorija ili umetanja nove veze. Implementacija metode prekida bila je vraćanje izvornog skupa veza pohranjenih u sustavu. 2 Provedba testova prihvatljivosti. Testovi prihvaćanja rade samo s korisničkom podrškom ili barem proxyjem za korisnika za određivanje kriterija. Bez kriterija prihvaćanja upravljačkih programa, postaje teško provjeriti izrađujete li pravi softver. Klijent se, zajedno sa svim članovima razvojnog tima, mora okupiti kako bi definirali sustav u smislu niza "skripti" koji opisuju što sustav treba raditi i kako to treba učiniti. Izradom testova s ​​jasnim zahtjevima i kriterijima odobrenja, veća je vjerojatnost da će softver ispuniti očekivanja kupaca. Međutim, to znači da netko ručno provjerava da li su zahtjevi ispunjeni i da aplikacija radi kako se očekuje. Ovdje dolaze automatizirani testovi prihvaćanja umjesto zahtjeva u naslijeđenom dokumentu, zahtjevi su definirani kao primjeri i scenariji, zaštićeni u kontroli izvora s artefaktima implementacije i mogu se pokrenuti u bilo kojem trenutku kako bi se provjerilo zadovoljavaju li zahtjeve i rade li ispravno. Isti pristup možete koristiti za pisanje testova, ali umjesto da ih upisujete u softver za upravljanje testnim slučajevima ili proračunsku tablicu, zapišite ih izravno u kod. Ispitivanje i testiranje sustava 37 1 Automatsko testiranje prihvaćanja. Stoga je prvi korak u implementaciji svake nove funkcionalnosti testom opisati svoja očekivanja. Drugi nisu, i s vremenom se bore s kontrolom procesa, pogotovo kako dokazi rastu i fleksibilnost testiranja počinje pogoršavati. Pristup vođen testom temelji se na tome koji testovi trebaju voditi razvoj softverskog proizvoda. U industrijskim softverskim proizvodima, kada se koriste metode inženjeringa zahtjeva, one su uglavnom podržane prirodnim jezikom, što podrazumijeva dobro poznatu neugodnost dvosmislenosti. Međutim, potreba za provjerom valjanosti može nadmašiti prednosti koje formalnija i rigoroznija specifikacija zahtjeva može ponuditi. Klijent mora biti sposoban pročitati i razumjeti zahtjeve kako bi mogao pristati na njih. Najpopularnije metode za definiranje zahtjeva navedene su u odjeljku Slučajevi korištenja i korisničke priče. Definiranje zahtjeva je ključ za privlačenje klijenta. Zahtjevi - cilj postignuća, odnosno ono što klijent očekuje od softverskog proizvoda. Testiranje i testiranje sustava 38 uloga povezanih sa specifikacijom zahtjeva i testiranjem valjanosti i prihvaćanja. Koncept zahtjeva postaje Spremnik testova prihvatljivosti, a to su oni koji zauzimaju središnje mjesto kao specifikacija svakog zahtjeva. Razmotrite zahtjev "Podignite novac" u kontekstu bankomata. Tipična opisna specifikacija može biti sljedeća: Kupac mora imati mogućnost podizanja gotovine od blagajne u odabranim iznosima. Uvijek uzmite potvrdu ako blagajnik nema papira. Kada je u pitanju Preferred Client, možete se povući više novca nego što imate na svom računu, no trebali biste biti upozoreni da će vam biti naplaćen postotak. Klijent bi trebao moći otkazati u bilo kojem trenutku prije nego što potvrdi povlačenje. Iznosi se moraju moći servisirati na računima koje blagajnik u tom trenutku ima, a drugi iznosi se ne smiju prihvaćati. Slika - Alternative specifikacije Slika 10 prikazuje neke specifikacijske alternative za ovaj zahtjev. Ikone odražavaju praktičnost svake specifikacije. Može biti zanimljivo razviti dijagram slijeda za definiranje svakog scenarija za ispunjavanje zahtjeva, međutim, općenito, to nije prikladno zbog veliki broj generirani dijagrami. Zanimljivije je identificirati scenarije nego svaki od njih ilustrirati dijagramom. Narativni opis nije jednokratan, barem za kratka definicija zahtjevi, koji se usredotočuje na definiranje uključenih koncepata. Međutim, model korištenja nije prikladan za ilustriranje detaljne strukture zahtjeva softverskog proizvoda u okruženju dugotrajnog održavanja jer prosječni softverski proizvod može imati tisuće zahtjeva. Potrebni su prikladniji mehanizmi za vizualizaciju i upravljanje mnogim zahtjevima. Predlošci su jedna od najčešće korištenih alternativa za korištenje u slučajevima. Predlošci su elegantni i pružaju osjećaj reda prema specifikaciji. Međutim, općenito su kontraproduktivni jer nastoje pružiti jednu razinu obrade detalja za sve zahtjeve. U ovim vrlo jednostavnim slučajevima, oni uključuju stvari koje su očite ili nevažne samo da pokriju sve dijelove predloška. Kada zahtjev uključuje više skripti, pokušaj sintetiziranja svih skripti u predlošku obično rezultira zbunjujućim specifikacijama. Na taj način zahtjevi djeluju kao kontejneri za zemlju. Ovisno o zahtjevu, drugi dodatni oblici specifikacije mogu biti korisni. Na primjer, dijagram aktivnosti ako ponašanje povezano sa zahtjevom ima algoritamski simbol ili dijagram stanja ako ponašanje uključuje radnje omogućavanja ili onemogućavanja prema tvrdnjama sustava i testovima prihvaćanja sustava. Bitan preduvjet je pragmatizam u odnosu na specifikaciju, koji ne isključuje dijeljenje alternativa specifikaciji, ali primarni kriterij treba biti želja da se bude profitabilan i doprinosi održavanju te specifikacije. S druge strane, u smislu nastojanja da se održavanje, osobito u pogledu dosljednosti, važno je ne prekomjerno koristiti dupliciranje ili umnožavanje specifikacija u različita sredstva reprezentacija. Usmjereni graf je adekvatan prikaz za pročišćavanje razine. Ovaj vam grafikon omogućuje vizualizaciju odnosa dekompozicije i ovisnosti između zahtjeva. Stoga je svaki čvor funkcionalni ili nefunkcionalni zahtjev. Lukovi između čvorova uspostavljaju odnose između roditelja i djece, ili odnose ovisnosti "čvorovi koji utječu na čvorove". Dakle, u gornjem primjeru, zahtjev "Povlačenje novca" može biti čvor strukture zahtjeva. Povratak s količinom koju je unio kupac. Nema dostupnih ulaznica. Nema papira za primanje. Vrijeme komunikacije sa središnjim sustavom je prekoračeno. Obavijest o internom poslovanju blagajnika. Isteklo je vrijeme za pokretanje radnje. To može biti povezano s funkcionalnim zahtjevom ili nefunkcionalnim zahtjevom. Neobavezno je i koristi se za postavljanje preduvjeta prije primjene testnih koraka. To su interakcijske akcije aktera sa sustavom. Kada izvode više radnji, mogu se staviti na numerirani popis. To je učinak interakcije glumaca. Svaka radnja može uzrokovati jedan ili više rezultata. Važno je da kada su u pitanju poruke korisniku, tekst bude uključen kao dio očekivanog izlaza, tako da programer već ima tu informaciju provjerenu kod klijenta. To će, kao što ćemo istaknuti u nastavku, uspostaviti ovisnost između zahtjeva. Stanje Mora biti normalan klijent. Koraci  Pokušajte vratiti novac normalnom kupcu i zatražite iznos veći od salda.  Očekivani rezultat. Ispitivanje i prihvaćanje sustava 42  Prikazuje se poruka "Tražena količina premašuje vaše trenutno stanje, ponovno unesite količinu" i vraća se u prozor za unos količine. Testiranje prihvaćanja pomoći će potvrditi da gradite aplikaciju koju klijent želi, dok vam automatizacija ovih skripti omogućuje kontinuirano testiranje aplikacije tijekom procesa razvoja i korištenje kao dio vašeg paketa za regresijsko testiranje kako biste osigurali da buduće promjene ne prekinu postojeće one.zahtjevi. Međutim, imati klijenta koji je povezan s prikupljanjem dokaza, posebno s automatskim testiranjem, predstavlja niz potencijalnih problema. Klijenti, općenito, nisu tehnički i skloni su se distancirati od samog razvoja softvera. Klijent može pružiti podatke i primjere, dok testeri ili programeri mogu brzo kodirati skripte i izvršne specifikacije. Testovi prihvaćanja korisničkog sučelja U primjerima su se testovi prihvaćanja usredotočili na poslovnu logiku i objekte domene kako bi vidjeli je li logika uspješno funkcionirala. Ali što je s načinom na koji korisnik komunicira s aplikacijom? Ovi testovi prihvaćanja trebali bi biti tu da testiraju ispravnost logike s korisničke točke gledišta, a korisničko sučelje je korisničko sučelje. Ako aplikacija ima dobro razdvajanje i dobro odvajanje logike od UI koda, to bi trebalo olakšati implementaciju testova. Ako testirate na ovoj razini, testovi se neće promijeniti u korisničkom sučelju. Iako se testiranje treba usredotočiti isključivo na logiku, to ne znači da ne biste trebali proći testove prihvaćanja na cijelom korisničkom sučelju. Volim imati skup testova dima koji su usmjereni na osnovno korisničko sučelje" sretan put". Usredotočuju se na dijelove aplikacije koje će korisnici najvjerojatnije koristiti kako bi izvukli maksimum iz svog iskustva. najmanju količinu testiranje. Ako pokušate sve pokriti mogući načini i korištenje korisničkog sučelja, a ako se korisničko sučelje promijeni, morat ćete promijeniti sve testove. Na primjer, ako testirate korisničko sučelje za web-mjesto e-trgovine, cesta će rado odabrati artikl, dodati ga u košaricu, provjeriti i vidjeti potvrdu kupnje. Ako ovaj scenarij ne uspije, stvarno želite saznati što prije. Za određene aplikacije, ovisno o složenosti i životnom vijeku, možda ćete htjeti imati više testova prihvaćanja u korisničkom sučelju kako biste bili sigurni da imate više povjerenja u sloj korisničkog sučelja. Međutim, uspješno testiranje korisničkog sučelja jest teško pitanje i nemam prostora da to pokrijem. Ispitivanje i prihvaćanje sustava 43 3Inteligentni testovi. Nakon što ste ispričali priču i scenarije u jasnom i razumljivom formatu, sljedeći korak je automatizacija priče i scenarija. To im omogućuje pokretanje tijekom razvoja kako bi pratili napredak i uhvatili greške u regresiji. Zaključci i preporuke. S druge strane, imamo testove sustava koji su odgovorni za evaluaciju rada tijekom cijelog procesa, kako bi se otkrile greške koje se mogu pojaviti za to, potrebno je razviti strategiju s testovima i odvojiti razvoj koda od razvoja sučelja, tako da se najbolje je provesti sistemske testove. Implementacija ova dva softverska testa mora se provoditi uz rigorozne testove koji zadovoljavaju određene standarde i uz koordinaciju dionika uključenih u razvoj sustava. Ispitivanje i prihvaćanje sustava 44 Bibliografija 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Kvantitativne metode upravljanja u razvoju softvera. Alonso Amo, Loic Martinez Normand. Uvod u razvoj softvera. Ispitivanje sustava i testiranje prihvatljivosti 45 8. -Odsjek za računalne jezike i sustave. Strukturni analiza sustava. Metode identifikacije bakterija u mikrobiološkom laboratoriju.