Definicija sprejemnega testa. Izdelava dokumentacije, izdelava in testiranje prototipov. Nabor standardov za avtomatizirane sisteme

Običajno to testiranje opravi druga ekipa, ki ročno ali z drugim orodjem ponovi veliko tega, kar je zajeto v samodejnem sprejemnem testiranju. To je mogoče storiti, ker sprejemnih testov ni mogoče enostavno izvajati v različnih okoljih ali pa razvojna ekipa ne more zlahka razumeti, kaj testi počnejo, in uporabljeni podatki so skriti v kodi, zaradi česar jih je težko najti ali spremeniti. Skrivanje namena testa v kodi otežuje razumevanje, kaj test poskuša narediti.

To tudi pomeni, da člani netehnične ekipe ne morejo zlahka prispevati k testiranju, tehnični ljudje pa porabijo več časa za avtomatizirano testno kodo. Ko je treba teste preoblikovati, kar je neizogibno, da ločijo namen od izvedbenih sredstev, se lahko osredotočite na preureditev izvedbe testa in ne na tisto, kar naj bi test naredil.

Ločitev namena, izvedbe in podatkov

Spodaj je diagram, ki ponazarja idejo ločevanja namena, izvedbe in podatkov. Vključeno je tudi okolje, saj je pomembno razumeti, v katerem okolju se bodo izvajali testi in po potrebi spremeniti podatke in zagnati test. Ustvarjanje namena lahko izvedejo netehnični člani ekipe v jeziku, ki je neodvisen od izvedbe. To je pomembno, ker pomeni, da je implementacijo mogoče preoblikovati, ne da bi bilo treba spremeniti namen testa. Velja tudi obratno; mogoče je spremeniti namen testa, ne da bi to vplivalo na izvedbo, pod pogojem, da obstaja izvedba, ki izpolnjuje vse besede v odstavku o namenu.

Če se v najslabšem primeru odločite, da zavržete celotno implementacijo in začnete znova, lahko še vedno obdržite testno namero in zato ne izgubite najpomembnejšega dela avtomatiziranih testov, kar testi poskušajo narediti. Podatke je treba ločiti tudi na namere in implementacije, s tem pa je mogoče podatke v testu podati z abstrakcijo in nato implementacijo odstraniti. Test lahko na primer kaže, da "zlati odjemalec", kot je identificiran odjemalec, ni del testa, ampak je del podatkovne plasti.

Ustvarjanje podatkovne plasti in abstrakcija podatkov nista novi tehniki; običajno se uporabljajo za kodo aplikacije in jih je treba uporabiti za avtomatizirane teste, saj koristi še vedno veljajo. V testnem primeru je podatkovna plast poklicana, da pridobi podatke iz vira podatkov za ustrezen tip odjemalca.

Testni primer nato ponovi vse vnose na seznamu in izvede test za vsak vnos stranke. Sistemski testi ustrezajo eni od stopenj testiranja programske opreme v kombinaciji z različnimi testi, kot so obnovitev, varnost, odpornost, zmogljivost, povezljivost, glasnost, napetost, razpoložljivost podatkov, enostavna uporaba, delovanje, okolje, shranjevanje, konfiguracija, namestitev in dokumentacija. Vsak ima drugačen namen in ima skupen namen, ki izkazuje sistematično vizijo projekta. Sprejemno testiranje je še ena vrsta ravni, ki jo dopolnjujejo testne ravni programske opreme, ti testi so zelo temeljni, saj so tisti, ki nam bodo omogočili, da dobimo izdelek, ki ustreza zahtevanim standardom in hkrati izpolnjuje zahteve uporabnikov v skladu s predpisi. zahteve, ki so jih postavljali od samega začetka. To prisili sistem, da preizkusi pomemben proces testiranja, saj je glede na izdelek, število napak in resnost teh hroščev ta korak v razvoju običajno nagnjen k večini napak. Slika 1: Preverjanje iterativnih sistemov Sistemski testi niso procesi za preverjanje funkcionalnosti sistema oz celoten program, saj bi bilo pri postopku funkcionalnega testiranja odveč. Sistemski testi imajo poseben namen: primerjati sistem ali program z njegovimi prvotnimi cilji. V ta namen sta predstavljeni dve vrednosti. Sistemsko testiranje ni omejeno na sisteme. Če je izdelek program, je testiranje sistema poskus dokazati, kako program popolnoma ne izpolnjuje svojih ciljev ali zahtev. Sistemski testi po definiciji niso možni, razen če obstajajo pisne zahteve, ki so merljive za izdelek. Testiranje sistema je faza raziskave, v kateri zagotavlja, da vsaka komponenta ali modul sodeluje z drugimi komponentami ali moduli, kot je predvideno. Sistemski testi so namenjeni poglobljeni implementaciji sistema, preverjanju integracije informacijskega sistema po svetu, preverjanju pravilnosti delovanja vmesnikov med različnimi podsistemi, ki ga sestavljajo, in z drugimi informacijskimi sistemi, s katerimi komunicira. Klasični problem sistemskega testa je »kazal s prstom«. To se zgodi, ko se odkrije napaka in razvijalec vsakega sistemskega elementa krivi druge. Namesto da bi zapadel v ta absurd, bi moral programski inženir predvideti možne težave z vmesnikom:  pot za obravnavo napak pri načrtovanju, ki preverja vse informacije, ki prihajajo iz drugih elementov sistema. Sistemsko testiranje in testiranje 6  Uporabite vrsto testov, ki simulirajo slabe podatke ali drugo možne napake v vmesniku programske opreme.  Registrirajte rezultate testov kot dokaz v primeru krivde.  Sodelujte pri načrtovanju in razvoju sistemskega testiranja, da zagotovite, da je bila programska oprema ustrezno preizkušena. Pravzaprav sistemski test zajema vrsto različnih testov, katerih glavni namen je globoko izračunati sistem med računanjem. Čeprav ima vsak test drugačen namen, se vsi trudijo zagotoviti, da so vsi elementi sistema pravilno integrirani in da opravljajo ustrezne funkcije. 2 Sistemski pregled testa. Pri izvajanju testiranja je potrebno vzdrževati sistemski, torej celosten pristop k razvoju programske opreme. Uporaba teh konceptov pri preizkusu programske opreme daje niz načel, ki bodo služila kot osnova za test: prepričati se morate, da natančno poznate cilje programske opreme, ki se preizkuša, in tudi vaše stopnje uspešnosti. Te elemente najdemo v dokumentih, pridobljenih v fazi zbiranja zahtev, kot tudi v specifikacijah programske opreme. Te informacije bodo potrebne za pripravo testnega načrta in bodo osnova za začetek razvoja testnega primera. Določiti je treba vhode in izhode odobrenega sistema. Ta vidik je nujen pri pripravi testnih primerov, pa tudi pri oblikovanju testnih postopkov, predvsem tistih, ki so usmerjeni v testni primer, ki kažejo izpolnjevanje ciljev. Razmislite o glavnem sistemu, v katerem se izvaja testirana programska oprema. Običajno gre za organizacijsko okolje, ki ga sestavljajo strojna oprema, programska oprema in ljudje. Vsi ti elementi imajo velik vpliv na sistem in predvsem pomagajo pri pripravi testnih primerov nezaželenih situacij, povezanih z neustreznimi podatki, pomanjkanjem potrebnih elementov in pojav izjem. 3 Pregled testiranja sistema Postopek testiranja sistema je sestavljen iz dveh faz, ki sta lahko sčasoma zelo ločeni: priprava testa in uporaba testa. Prvi je tesno povezan z zahtevami, tako da se zgodi zgodaj v projektu, drugi pa zahteva celoten sistem ali vsaj eno integracijo, saj naj bi delni izdelek bil neizdan, da bi lahko uporabil teste, tako da se to zgodi v naprednih fazah projekta. projekt. Natančna situacija s temi deli je odvisna od izbranega modela. življenski krog. Za izvedbo druge in tretje dejavnosti je potreben dokument z zahtevami. Prva faza testiranja zagotavlja povratne informacije za analizo zahtev, ugotavljanje vrzeli, nejasnosti in drugih vprašanj. Zagotavlja tudi dragocene nasvete o načrtovanju in implementaciji sistema, če ga šele razvijate. Faza testne aplikacije zahteva testni načrt in izvedljivo različico sistema. V tem primeru bodo uporabljeni testni primeri, ki so bili pripravljeni, rezultati analizirani in ugotovljene morebitne napake. Ta drugi korak zagotavlja povratne informacije o izvedbi in načrtovanju ter prikazuje možne napake, ki jih je treba odpraviti. Zagotavlja tudi informacije, ki bodo koristne pri izdaji sistema, njegovem prevzemu, ocenjevanju njegove zanesljivosti in vzdrževanju. Slika 1 prikazuje postopek testiranja sistema in njegov odnos z drugimi procesi. Druga točka je pomembna, ker se včasih sistemski test zamenjuje s testom vmesnika. Prvi preverja interakcijo vseh delov, drugi pa analizira elemente vmesnika in po možnosti obdelavo povezanih dogodkov. Vendar pa lahko za izvajanje sistemskih testov uporabite orodja, ki pomagajo pri testiranju vmesnika. Postavlja se več vprašanj: koliko primerov bo dovolj? Kako ustvariti čim manj? Katere vrednosti so primerne? Testiranje in testiranje sistema 9 1 Testni načrt Načrt testiranja je zelo pomemben dokument med testiranjem programske opreme. Pojasnjuje cilje in pristope k testiranju, delovni načrt, operativne postopke, potrebna orodja in odgovornosti. Preizkušanje in testiranje sistema 10 Dokument z zahtevami mora vsebovati seznam funkcij, ki jih mora izvajati programska oprema, ter jih opisati in določiti prednost; vključevati mora tudi nefunkcionalne zahteve, ki lahko vključujejo organizacijske, operativne in druge vidike. Dobro pripravljen dokument z zahtevami bi moral zagotavljati način, kako za vsako zahtevo preveriti, ali je izpolnjena. V primeru funkcij bi bil to opis, v primeru nefunkcionalnih zahtev pa bi lahko bile zelo natančne specifikacije, kot je odzivni čas. Za zdaj se bomo osredotočili na funkcionalne zahteve, ostalo pa pustimo za kasnejši razdelek. Sistemski testi so pomembni zaradi naslednjih dejavnikov:  To je sistem, ki se testira kot celota v življenjskem ciklu razvoja sistema.  Sistem se preverja glede skladnosti s svojim delovanjem in tehnične zahteve .  Sistem je testiran v okolju, ki je čim bližje produkcijskemu okolju.  Sistemski testi vam omogočajo, da testirate, potrdite in potrdite tako poslovne zahteve kot arhitekturo aplikacij. 6Vrsta sistemskih testov Funkcionalni testi  Integracijski test. - v katerem ima preskusna oprema dostop do izvorne kode sistema. Ko se odkrije težava, integracijska ekipa poskuša najti vir težave in določiti komponente, ki jih je treba odpraviti. Integracijsko testiranje se ukvarja predvsem z iskanjem napak v sistemu.  Dokazilo o dostavi. Tukaj je različica sistema, ki jo je mogoče dostaviti uporabniku. Tukaj se skupina za testiranje ukvarja s preverjanjem, ali sistem izpolnjuje njegove zahteve in zagotavlja zanesljivost sistema. Preizkusi dostave so običajno testiranje črne škatle, pri katerem se testna oprema preprosto ukvarja s tem, ali sistem pravilno deluje. Komponente, ki jih je mogoče integrirati, so lahko komercialne komponente, komponente za večkratno uporabo, prilagojene določenemu sistemu, ali na novo razvite komponente. Za številne velike sisteme bodo verjetno uporabljali vse tri vrste komponent. Integracijski test preveri, ali te komponente dejansko delujejo skupaj, se pravilno kličejo in posreduje pravilne podatke ob točnem času skozi njihove vmesnike. Sistemska integracija vključuje prepoznavanje skupin komponent, ki zagotavljajo nekatere sistemske funkcionalnosti, in njihovo integracijo z dodajanjem kod za skupno delovanje. Včasih se najprej razvije skelet celotnega sistema in dodajo komponente. To se imenuje postintegracija. To je integracija navzgor. V praksi je za številne sisteme strategija integracije kombinacija obojega, pri čemer se dodajo dodatne infrastrukturne in funkcionalne komponente. Oba pristopa integracije zahtevata dodatno kodo za modeliranje drugih komponent in omogočanje zagona sistema. Glavna težava, na katero naletimo med integracijskimi testi, je lokacija hroščev. Obstajajo zapletene interakcije med komponentami sistema in ko se odkrije anomalen izhod, je lahko težko ugotoviti, kje je prišlo do napake. Za lažjo izolacijo hroščev morate vedno uporabljati postopen pristop k integraciji in testiranju sistema. Glavni namen tega procesa je povečati zaupanje dobavitelja, da sistem izpolnjuje njegove zahteve. Če je tako, se lahko dostavi kot izdelek ali dostavljen kupcu. Če želite dokazati, da sistem izpolnjuje svoje zahteve, je treba dokazati, da zagotavlja določeno funkcionalnost, zmogljivost in zanesljivost ter da pri običajni uporabi ne odpove. Preskusi dostave so običajno postopek testiranja črne skrinjice, v katerem so testi izpeljani iz sistemske specifikacije. Sistem se obravnava kot črna skrinjica, katere obnašanje je treba določiti le s preučitvijo njegovih ustreznih vhodov in izhodov. Drugo ime za to je funkcionalno testiranje, ker testerja zanima samo funkcionalnost in ne implementacija programske opreme. Na naslednji sliki bomo videli ponazoritev modela sistema, ki ga omogoča pri preverjanju črne škatle. Tester predstavi vhode v komponento ali sistem in upošteva vhode. V nekaterih primerih mora biti sistem odporen na napake; to pomeni, da napake pri obdelavi ne smejo voditi v okvare sistema kot celote. Preizkusni sistemi in prevzemni preskusi 14 Odpoved sistema je treba odpraviti v določenem časovnem obdobju, sicer bo povzročila resno gospodarsko škodo. Preizkus obnovitve je sistemski preizkus, ki povzroči, da programska oprema ne uspe na več načinov in preveri, ali je obnovitev izvedena pravilno. Če se obnovitev zgodi samodejno, morate preveriti, ali so ponovna inicializacija, mehanizmi varnostnega kopiranja sistema, obnovitev podatkov in ponovni zagon pravilni. Če okrevanje zahteva človeško posredovanje, je treba določiti povprečni čas okrevanja, da se ugotovi, ali je v sprejemljivih mejah. Cilj je vzpostaviti končne točke, kjer sistem začne delovati pod določenimi zahtevami. Tega ne smemo zamenjevati s testom prostornine; visoka napetost je največja količina podatkov ali aktivnosti na kratek čas. Analogija bi bila ocenjevanje tipkarja. Preizkus obsega se določi, če se tipkarjev sooči z osnutkom velikega poročila; stresni test bo ugotovil, ali tipkarica zna tipkati s hitrostjo 50 besed na minuto. Kršitev vključuje širok nabor dejavnosti:  Heker, ki se poskuša prijaviti na igro. Varnostni test preveri, ali ga varnostni mehanizmi, vgrajeni v sistem, dejansko ščitijo pred neprimernimi vdori. "Sisteme je treba testirati glede varnosti sistema, da bo odporen na čelne napade, pa tudi na tiste, ki delajo boke ali zadaj." Med varnostnim testom vsak, ki ga uporabi, igra vlogo osebe, ki se želi prijaviti. Vse to je vredno! Poskusite pridobiti vsa gesla zunanja sredstva; lahko napade sistem s posebno programsko opremo, zasnovano tako, da zaobide katero koli zaščiteno arhitekturo; lahko nasiči sistem in s tem odreče storitve drugim; lahko privede do namernih napak v sistemu, da poskusite pridobiti dostop med obnovitvijo: podatke si lahko ogledate brez zaščite, z idejo, da iščete geslo za sistem. Če bo na voljo dovolj časa in sredstev, bo sistem sčasoma dober test za varnost. Vloga načrtovalca sistema je, da so stroški prekinitve večji od stroškov prejetih informacij. Vendar pa analiza človeških dejavnikov ostaja zelo subjektiven problem. Namen testnih primerov je pokazati, da teh ciljev za shranjevanje ni mogoče najti. Pogosto je število možnih konfiguracij preveliko, da bi lahko preizkusili vsako posebej, vendar če je mogoče, bi morali preizkusiti program z vsako vrsto strojne naprave ter z najmanjšo in največjo konfiguracijo. Če je mogoče sam program konfigurirati tako, da preskoči komponente, ali če se lahko izvaja na več računalnikih, je treba vsako konfiguracijo preizkusiti. Testiranje namestitvenih postopkov je pomemben del postopka testiranja sistema. To še posebej velja za sistem avtomatska namestitev vključeno v programski paket. Nepravilno zagnan namestitveni program lahko uporabniku prepreči uspešno izkušnjo s sistemom. Prva izkušnja uporabnika je, ko namesti aplikacijo. Eden od načinov za dosego tega je uporaba dokumentacije za definiranje pogleda prejšnjih sistemskih testnih primerov. To pomeni, da ko želite razviti primer preobremenitve, uporabite dokumentacijo kot vodilo za pisanje dejanskega testnega primera. Poleg tega je treba uporabniško dokumentacijo pregledati glede točnosti in jasnosti. Vsak od primerov, prikazanih v dokumentaciji, je treba preizkusiti in dodati na seznam opravil ter vključiti v program. Sistemsko testiranje in testiranje 17 stališča delovanja, po prevzemu sistema v dejanskem okolju in na podlagi skladnosti z določenimi nefunkcionalnimi zahtevami. Testiranje odpornosti je zasnovano za preprečevanje programov v nenormalnih situacijah. V bistvu bo oseba, ki izvaja test odpornosti, spraševala. Kako daleč prideš, preden ne uspe? Preizkus odpornosti izvaja sistem tako, da zahteva nenormalno količino, frekvenco ali količino virov. Na primer:  razviti so bili posebni testi, ki ustvarijo 10 prekinitev na sekundo, ko je povprečna skodelica ena ali dve.  Pogostost vnosa podatkov se poveča za količino, ki bo omogočila odzive na vnosne funkcije.  Zaženite testne primere, ki zahtevajo največ pomnilnika ali drugih virov.  Testni primeri so zasnovani za odpravljanje težav z upravljanjem pomnilnika. Ustvarjeni so testni primeri, ki povzročajo pretirano iskanje po disku. Slika je primer testa odpornosti. Preizkus delovanja se uporablja v vseh fazah postopka testiranja. Tudi na ravni enote. Učinkovitost posameznega modula je treba oceniti med testiranjem. Toda šele potem, ko so vsi elementi sistema popolnoma integrirani, je mogoče doseči resnično delovanje sistema. Preskusi zmogljivosti pogosto vključujejo testiranje odpornosti in pogosto zahtevajo navodila za programsko in strojno opremo. To pomeni, da je pogosto treba natančno izmeriti porabo virov. Z zunanjimi orodji lahko redno spremljate intervale izvajanja, zabeležene dogodke in stanje vzorcev strojne opreme. Ti testi se izvajajo tako, da naročnik potrdi, da sistem zanj velja. Podrobno načrtovanje teh testov je treba izvesti zgodaj v fazi razvoja z namenom, da se rezultati uporabijo kot pokazatelj njihove veljavnosti: če se dokumentirani testi izvajajo v zadovoljstvo kupca, se izdelek šteje za pravilnega in zato ustrezen za uporabo. proizvodnja. 6 Prejemni testi2 so v bistvu funkcionalni testi na celotnem sistemu in so namenjeni preverjanju, ali je uveljavljenih zahtev . Njegova izvedba je za odjemalca neobvezna in v primeru, da niso izrecno določena, se vključijo v sistemske teste. To pomeni, da so prevzemni testi pogosto odgovornost uporabnika ali stranke, čeprav jih lahko izvaja vsak, ki je vpleten v poslovanje. Preizkus sprejemanja zahteva testno okolje, ki predstavlja produkcijsko okolje. Ta faza ali raven kot izhodišče opredeljuje izhodišče za sprejem proizvoda, ki je že vzpostavljeno v certifikacijskem okolju. Preskušanje in sprejem sistema 19 Slika - Sprejemni nadzor. 1 Preučitev trenutnega stanja v sprejemnih testih. V okviru testov moramo preveriti programsko opremo, eno najpomembnejših je prevzemno testiranje. To so testi, ki jih razvija razvojna ekipa sama na podlagi funkcionalnih zahtev, določenih v fazi analize, da bi pokrili celoten spekter in jih izvedel končni uporabnik, vendar nimajo vsi, ampak nekaj uporabnikov pomembnega rezultata, ki daje veljavnost in skladnost z izdelkom, ki jim je dostavljen na podlagi prvotno dogovorjenega. Odvisno od zahtevnosti testiranega sistema, ne glede na to, ali je razdeljen na module itd. izvajanje teh testov poteka drugače. Če bi aplikacijo razdelili na module, bi se ti obravnavali kot podsistemi in bi bili dovolj zapleteni, da bi jih bilo mogoče obravnavati drugače, izvajati bi bilo treba različne seje sprejemnih testov. 2 Namen prevzemnega testiranja Cilj prevzemnega testiranja je pridobiti sprejem končnega kupca pred dostavo izdelka za začetek proizvodnje. Ko je organizacija izvedla sistemske teste in odpravila večino njegovih napak, bo sistem dostavljen uporabniku ali stranki v odobritev. Namen sprejemnega testiranja je preveriti, ali sistem izpolnjuje pričakovane zmogljivosti in omogoči uporabniku tega sistema, da ugotovi njegovo sprejemljivost glede na njegovo funkcionalnost in zmogljivost. Sprejemne teste določi uporabnik sistema in jih pripravi razvojna ekipa, končna izvedba in odobritev pa je odvisna od uporabnika. Potrditev sistema se doseže z izvajanjem testov črne škatle, ki dokazujejo skladnost in so vključeni v načrt testiranja, ki opredeljuje validacije, ki jih je treba izvesti, in z njimi povezane testne primere. Ta načrt je zasnovan tako, da zagotovi, da so izpolnjene vse funkcionalne zahteve, ki jih določi uporabnik, kot tudi nefunkcionalne zahteve, povezane z zmogljivostjo, varnostjo dostopa do sistema, podatkov in procesov ter različnih sistemskih virov, 3 Generacija sprejemnega testiranja. Uporabnik mora sistem sprejeti. Iz tega razloga analitik na podlagi strukturiranih specifikacij sistema ustvari niz testnih primerov, ki morajo zadovoljivo prestati. Ker je sprejemne teste mogoče razviti vzporedno z dejavnostmi načrtovanja in prakse, je normalno, da analitik začne te dejavnosti takoj, ko je aktivnost strukturirane analize zaključena. 4 Strategije testiranja sprejemljivosti Če je bil sistem zasnovan za množični trg, ga ne bi bilo praktično testirati za posamezne uporabnike ali stranke, v nekaterih primerih ne bi bilo mogoče. V teh primerih so potrebne povratne informacije, preden je izdelek dan v prodajo. Pogosto imajo takšni sistemi dve stopnji sprejemnega testiranja. Preskušanje alfa in beta Ko je programska oprema po meri izdelana za stranko, se izvede vrsta sprejemnih testov, ki stranki omogočijo, da preizkusi vse zahteve. Izvaja naročnik na razvojnem mestu. Programska oprema se naravno uporablja z razvijalcem kot opazovalcem uporabnika, skupaj z napakami pri registraciji in težavami pri uporabi. Alfa testi se izvajajo v nadzorovanem okolju. Delate v nadzorovanem okolju in stranka ima vedno strokovnjaka, ki vam pomaga pri uporabi sistema. Razvijalec spremlja najdene napake in težave z uporabo. Β-beta testi se izvajajo po testu α-alfa in so razviti v okolju odjemalca. V tem primeru naročnik ostane sam z izdelkom in poskuša najti hrošče, ki obvestijo razvijalca. Izvajajo jih končni uporabniki programske opreme na delovnih postajah naročnika. Za razliko od alfa testa razvijalec običajno ni prisoten. Tako je beta test uporaba programske opreme v živo v okolju, ki ga razvijalec ne more nadzorovati. Stranka beleži vse težave, ki se pojavijo med testiranjem beta, in v rednih časovnih presledkih poroča razvijalcem. 5 Vhodi, izhodi, naloge in vloge sprejemnega testa. Specifikacija zahtev za vstop. Naloge Pripravite testno okolje. Priporočamo, da imate za to vrsto testiranja posebno testno okolje. Namestitev v testnem okolju. Preizkušanje in testiranje sistema 22 Določite teste, ki jih je treba izvesti. Določene bodo možne odvisnosti, ki obstajajo med testi, in vrstni red ali zaporedje, v katerem se bodo testi izvajali, bo določeno na podlagi teh odvisnosti. Prejemanje in beleženje rezultatov. Odpravljene napake in napake. Ponavljajte nalogo, dokler ne opravite vseh testov. Priprava poročila o sprejemnem preizkusu. Pregled pravilne izvedbe in rezultatov vseh oddanih testov. Ustvarjanje proizvodne baze. Uradno zaprtje dejavnosti. Rezultati testov. Sprejeto poročilo o prevzemu izdelka. Vodja projekta. Poudarek na sprejemnem testiranju je povezan s poskusom utrjevanja mnenja, da bi uporabnik, vključen v tej fazi, v zgodnji fazi, pripomogel k izboljšanju tega procesa v fazi načrtovanja in oblikovanja testiranja, s kasnejšimi izboljšavami v številnih kvantitativnih in zaželenih vidikih. , kot so: Izboljšanje kakovosti integrirane zaščite programske opreme. Zmanjšanje stroškov. Povečana zanesljivost rezultatov projekta. Pri uporabi programske opreme z manj napakami se poveča zadovoljstvo strank. S tem se izboljša učinkovitost razvojnega procesa. 7 Merila za sprejemno testiranje. Sprejem programske opreme je dosežen z vrsto testov, ki dokazujejo, da izpolnjujejo zahteve. Testni načrt opisuje vrsto preskusa, ki ga je treba uporabiti, preskusni postopek pa opredeljuje posebne testne primere, načrt in postopek sta zasnovana tako, da zagotovita, da izpolnjujeta vse funkcionalne zahteve, da so dosežene vse vedenjske značilnosti, izpolnjene so vse zahteve glede zmogljivosti, dokumentacija je pravilen in upošteva vse zahteve za enostavno uporabo in drugo določene zahteve. 8 Orodja za sprejemne teste. To omogoča strankam, preizkuševalcem in programerjem, da vedo, kaj naj bi njihova programska oprema počela, in samodejno primerjajo, kaj dejansko počne. Omogoča vam pisanje testov, ki so enostavni za branje in vzdrževanje. Ta dejavnost je znana kot končni test ali test sprejemljivosti. To zahteva vnos podatkov o sprejemnih preskusih in integrirani sistem, ustvarjen med to dejavnostjo. Test bo izvedel nek član ali oddelek uporabnika ali celo neodvisen oddelek za nadzor kakovosti. Pomembno je omeniti, da je pri vsaki od prejšnjih analitičnih, projektantskih in izvedbenih aktivnosti pomembno izvajati aktivnosti nadzora kakovosti, da zagotovimo, da so bile izvedene na ustrezni ravni kakovosti. To zagotavlja, da analitik izdela specifikacije kakovosti, da oblikovalec izdela kakovostne načrte in da programer izdela kakovostne programe kodiranja. V računalništvu je izvedba tehnična specifikacija ali algoritmi, kot je program, komponenta programske opreme ali drug računalniški sistem. Številne izvedbe so na voljo v skladu s specifikacijo ali standardom. Povzemamo dosedanje delo avtorjev za pridobitev testnih ciljev, ki so izhodišče za razvoj avtomatiziranih testov. V kontekstu sistemskega testiranja iz primerov uporabe lahko cilj testiranja izrazimo kot primer uporabe. Ta scenarij bo sestavljen iz zaporedja korakov brez možne alternative in niza testnih vrednosti in predpogoji in pokonference, povezane s tem scenarijem. Za generiranje testnih scenarijev se najprej sestavi diagram aktivnosti iz glavnega zaporedja ter napak in alternativnih zaporedij primera uporabe. V diagramu aktivnosti so dejanja, ki jih izvaja sistem, in dejanja, ki jih izvajajo udeleženci, stereotipna. Nato se izvede analiza poti in vsaka pot diagrama aktivnosti bo scenarij uporabe in zato potencialni cilj testa. 2 Izvedba sistemskih testov. Arhitektura za testiranje sistema. Arhitektura za izvajanje in samodejno preverjanje sistemskih testov je prikazana na sliki 7. Ta arhitektura je podobna arhitekturi, ki je potrebna za avtomatizacijo drugih vrst testov, kot so testi enot. Glavna razlika je v tem, da pri testu enote sam test pokliče izvedljivo kodo, medtem ko funkcionalni test in sprejem testa testnega sistema 27 zahtevata posrednika, ki ve, kako manipulirati z njegovim zunanjim vmesnikom. Izvedba testnih primerov. Test-test je uresničitev cilja testiranja. Splošno vedenje za testni primer je navedeno v tabeli Splošno vedenje testnega primera. Vsak primer uporabe bo povezan s testno zbirko. Ta zbirka bo vsebovala teste za vse scenarije omenjenega primera uporabe. Kot je razvidno iz ciljev testa, mora biti vsak korak določen, ali ga izvaja akter ali sistem, ki se testira. Te informacije so zelo pomembne pri kodiranju testnih metod paketa. Vsa dejanja, ki jih izvede akter, pretvorijo kodo testne kode v interakcijo med testnim primerom in sistemom. Preizkušanje sistema in prevzemno testiranje 29 Za določitev zahtevanih preskusnih vrednosti bo uporabljena operativna in kategorijska spremenljivka metodologija. Trije so bili identificirani različne vrste operativne spremenljivke. Vsaka vrsta se bo v testnih primerih izvajala drugače. Prvo vrsto sestavljajo tiste operativne spremenljivke, ki označujejo prenos informacij v sistem s strani zunanjega subjekta. Za vsako spremenljivko te vrste bo definiran nov razred, katerega predmeti bodo vsebovali različne testne vrednosti za to spremenljivko. Primer te vrste delovne spremenljivke je prikazan v študiji primera. Drugo vrsto sestavljajo tiste operativne spremenljivke, ki kažejo na izbiro med več možnostmi, ki so na voljo zunanjemu akterju. Namesto tega bo takšna izbira implementirana neposredno kot del kode, ki izvaja interakcijo med akterjem in sistemom. Tretjo vrsto sestavljajo tiste operativne spremenljivke, ki označujejo stanje sistema. Za izvedbo metode nastavitve testnega primera napišite potrebno kodo za pravilno nastavitev vrednosti operativnih spremenljivk, ki opisujejo stanja sistema, ali za preverjanje, ali se vrednosti ujemajo. Podobno mora metoda break te vrednosti obnoviti v prvotna stanja. Poleg tega mora metoda sledenja po potrebi izključiti informacije, ki jih testni primer vnese v sistem med izvajanjem testnega primera. V študiji primera je prikazanih več primerov operativnih spremenljivk te vrste. V tem primeru je prva stvar, ki jo je treba narediti, uporabiti tisto, kar je bilo videno, da dobimo nabor ciljev testa iz primera uporabe. Nato se določijo značilnosti uporabljenega preskusnega pasu. Na koncu uporabimo tisto, kar smo videli prejšnjih razdelkih za izvedbo testnega primera iz testnega cilja. Artefakti v testiranem sistemu so bili identificirani na angleški jezik, zaradi španski ne podpirajo uporabljena orodja. Primer uporabe v tabeli 2 opisuje uvedbo nove povezave v sistem. Kot dodatek je prikazana tudi zahteva po shranjevanju informacij, ki opisujejo informacije, ki jih obravnava vsaka povezava. Iz primera uporabe in samodejno generiran nabor scenarijev, ki bodo tarča testiranja omenjenega primera uporabe. Glede na to, da ima primer uporabe neomejene zanke z neskončnim številom možnih ponovitev, je merilo pokritosti, izbrano za pridobivanje cest, merilo 01, ki preverja in testira teste sistema 30, sestoji iz pridobivanja vseh možnih poti za nobeno ali enkratno ponovitev vsaka od zank. Vse skripte, pridobljene po tem kriteriju in prevedene v španščino, so navedene v tabeli. Za to študijo primera smo izbrali scenarij 09, ki je za njegovo izvedbo podrobno prikazan v tabeli 5. Testiranje in testiranje pri testiranju 31 Tabela Zahteva po informacijah za reference. Uporabite lahko tudi metodo razdelitve kategorij. Razdelki za vsako od teh spremenljivk so navedeni v tabeli. Preizkušanje in testiranje sistema 32 Spremenljivke tabele, definirane za primer uporabe. Testiranje in testiranje pri testiranju 33 Tabela kategorij za identificirane spremenljivke. Kot je opisano na sliki 7, je test obremenitve zasnovan tako, da simulira vedenje uporabnika in ponuja niz stavkov za oceno rezultata. Ta prevod se trenutno izvaja ročno in je prikazan v tabeli. Testiranje in testiranje oddajno-sprejemnika 35 Slika Izvedba testnega primera. Prevod v izvedljivo kodo korakov, ki jih izvede uporabnik v glavnem scenariju. To pomeni, da se prepričate, da kategorije obstajajo in da ni nobenih okoliščin, ki bi povzročile napako pri obnavljanju kategorij ali vstavljanju nove povezave. Izvedba metode prekinitve je bila obnovitev prvotnega nabora povezav, shranjenih v sistemu. 2 Izvajanje sprejemnih testov. Preizkusi sprejemanja delujejo samo s podporo za stranke ali vsaj s proxyjem za stranko za določitev meril. Brez meril za sprejem gonilnikov postane težko preveriti, ali gradite pravo programsko opremo. Odjemalec, skupaj z vsemi člani razvojne ekipe, se mora združiti, da definira sistem v obliki serije "skriptov", ki opisujejo, kaj naj sistem počne in kako naj to naredi. Z ustvarjanjem testov z jasnimi zahtevami in merili za odobritev je večja verjetnost, da bo programska oprema izpolnila pričakovanja strank. Vendar to pomeni, da nekdo ročno preveri, ali so zahteve izpolnjene in ali aplikacija deluje po pričakovanjih. Tu se namesto zahtev v podedovanem dokumentu pojavijo samodejni sprejemni testi, zahteve so opredeljene kot primeri in scenariji, zaščiteni v nadzoru vira z artefakti razmestitve in jih je mogoče kadar koli zagnati, da preverimo, ali izpolnjujejo kakršne koli zahteve in delujejo pravilno. Enak pristop lahko uporabite za pisanje testov, vendar namesto da jih vnašate v programsko opremo za upravljanje testnih primerov ali preglednico, jih zapišite neposredno v kodo. Preizkušanje in testiranje sistema 37 1 Samodejno prevzemno testiranje. Zato je prvi korak pri implementaciji katere koli nove funkcionalnosti, da s testom opišete svoja pričakovanja. Drugi niso in se sčasoma spopadajo z nadzorom procesov, zlasti ko dokazi rastejo in se prožnost testiranja začne slabšati. Pristop, ki temelji na testih, temelji na tem, kateri testi naj vodijo razvoj programskega izdelka. V industrijskih programskih izdelkih, ko se uporabljajo metode inženiringa zahtev, so večinoma podprte z naravnim jezikom, kar pomeni dobro znano neprijetnost dvoumnosti. Vendar pa lahko potreba po validaciji odtehta prednosti, ki jih lahko ponudi bolj formalna in strožja specifikacija zahtev. Stranka mora biti sposobna prebrati in razumeti zahteve, da se lahko z njimi strinja. Najbolj priljubljene metode za definiranje zahtev so navedene v razdelku Primeri uporabe in uporabniške zgodbe. Opredelitev zahtev je ključna za privabljanje kupca. Zahteve - cilj dosežka, torej kaj naročnik pričakuje od programskega izdelka. Preizkušanje in testiranje sistema 38 vlog, povezanih s specifikacijo zahtev ter preverjanjem veljavnosti in sprejemljivosti. Koncept zahtev postane vsebnik sprejemnih testov in ti so tisti, ki so v središču pozornosti kot specifikacija vsake zahteve. Razmislite o zahtevi "Dvig denarja" v kontekstu bankomata. Tipična opisna specifikacija je lahko naslednja: Stranka mora imeti možnost dvigniti gotovino iz blagajne v izbranih zneskih. Če na blagajni ni več papirja, vedno dobite potrdilo. Ko gre za prednostno stranko, lahko umaknete več denarja kot imate na računu, vendar morate biti opozorjeni, da vam bomo zaračunali odstotek. Stranka mora imeti možnost, da kadar koli prekliče, preden potrdi umik. Zneski morajo biti omogočeni na računih, ki jih ima blagajnik takrat, drugi zneski pa se ne smejo sprejemati. Slika – Alternative specifikacije Slika 10 prikazuje nekatere možnosti specifikacije za to zahtevo. Ikone odražajo priročnost vsake specifikacije. Morda bi bilo zanimivo razviti diagram zaporedja za opredelitev vsakega scenarija za izpolnjevanje zahteve, vendar na splošno to ni primerno zaradi veliko število ustvarjene diagrame. Bolj zanimivo je identificirati scenarije kot ponazoriti vsakega posebej v diagramu. Opis pripovedi ni enkraten, vsaj za kratka definicija zahteve, ki se osredotoča na opredelitev vključenih konceptov. Vendar model uporabe ni primeren za ponazoritev podrobne strukture zahtev programskega izdelka v okolju dolgoročnega vzdrževanja, ker ima lahko povprečen programski izdelek na tisoče zahtev. Za vizualizacijo in upravljanje številnih zahtev so potrebni ustreznejši mehanizmi. Predloge so ena najpogosteje uporabljenih alternativ za uporabo v primerih uporabe. Predloge so elegantne in zagotavljajo občutek reda glede na specifikacijo. Vendar pa so na splošno kontraproduktivni, ker ponavadi zagotavljajo enotno raven obdelave podrobnosti za vse zahteve. V teh zelo preprostih primerih vključujejo stvari, ki so očitne ali nepomembne samo za pokrivanje vseh delov predloge. Kadar zahteva vključuje več skriptov, poskus sintetiziranja vseh skriptov v predlogi običajno povzroči zmedo specifikacij. Na ta način zahteve delujejo kot zabojniki za državo. Glede na zahtevo so lahko koristne druge dodatne oblike specifikacij. Na primer, diagram dejavnosti, če ima vedenje, povezano z zahtevo, algoritemski simbol, ali diagram stanja, če vedenje vključuje dejanja omogočanja ali onemogočanja v skladu s sistemskimi trditvami in sistemskimi testi sprejemljivosti. Bistveni predpogoj je pragmatizem glede specifikacije, ki ne izključuje delitve alternativ specifikaciji, vendar mora biti primarno merilo želja po dobičku in prispevanju k vzdrževanju specifikacije. Po drugi strani pa v smislu prizadevanj za vzdrževanje, zlasti kar zadeva doslednost, je pomembno, da ne pretiravate s podvajanjem ali podvajanjem specifikacij v različna sredstva zastopanje. Usmerjen graf je ustrezna predstavitev za izpopolnjevanje ravni. Ta graf vam omogoča vizualizacijo razmerij razgradnje in odvisnosti med zahtevami. Tako je vsako vozlišče funkcionalna ali nefunkcionalna zahteva. Loki med vozlišči vzpostavljajo odnose med starši in otroki ali odnose odvisnosti "vozlišč, ki vplivajo na vozlišča". Tako je v zgornjem primeru lahko zahteva "Dvig denarja" vozlišče strukture zahtev. Vrnite s količino, ki jo je vpisal kupec. Vstopnice niso na voljo. Ni papirja za prejem. Komunikacijski čas s centralnim sistemom je bil prekoračen. Obvestilo o notranjem poslovanju blagajne. Časovna omejitev za začetek dejanja je potekla. To je lahko povezano s funkcionalno zahtevo ali nefunkcionalno zahtevo. Ni obvezen in se uporablja za nastavitev predpogojev pred uporabo preskusnih korakov. To so interakcijska dejanja akterja s sistemom. Ko izvajajo več dejanj, jih je mogoče uvrstiti na oštevilčen seznam. To je učinek interakcije med akterji. Vsako dejanje lahko povzroči enega ali več rezultatov. Pomembno je, da je pri sporočilih uporabniku besedilo vključeno kot del pričakovanega izpisa, tako da ima programer te informacije že preverjene pri odjemalcu. To bo, kot bomo poudarili v nadaljevanju, vzpostavilo odvisnost med zahtevami. Pogoj Mora biti običajna stranka. Koraki  Poskusite vrniti denar običajni stranki in zahtevajte znesek, ki presega stanje.  Pričakovani rezultat. Preizkušanje in sprejem sistema 42  Prikaže se sporočilo "Zahtevana količina presega vaše trenutno stanje, ponovno vnesite količino" in se vrne v okno za vnos količine. Preizkus sprejemanja bo pomagal potrditi, da gradite aplikacijo, ki jo želi stranka, medtem ko vam avtomatizacija teh skriptov omogoča nenehno preizkušanje aplikacije skozi celoten razvojni proces in njihovo uporabo kot del zbirke za regresijsko testiranje, da zagotovite, da prihodnje spremembe ne bodo prekinile sedanjih. zahteve. Vendar pa, če je stranka povezana z zbiranjem dokazov, zlasti z avtomatskim testiranjem, predstavlja številne možne težave. Stranke so na splošno netehnične in se ponavadi distancirajo od samega razvoja programske opreme. Stranka lahko zagotovi podatke in primere, medtem ko lahko preizkuševalci ali razvijalci hitro kodirajo skripte in izvedljive specifikacije. Preizkusi sprejemljivosti uporabniškega vmesnika V primerih so se sprejemni testi osredotočili na poslovno logiko in objekte domene, da bi ugotovili, ali je logika uspešno delovala. Kaj pa način interakcije uporabnika z aplikacijo? Ti sprejemni testi bi morali biti tam, da preverijo pravilnost logike z vidika uporabnika, uporabnikovo stališče pa je uporabniški vmesnik. Če ima aplikacija dobro ločitev in dobro ločitev logike od kode uporabniškega vmesnika, bi moralo to olajšati izvajanje testov. Če testirate na tej ravni, se testi v uporabniškem vmesniku ne bodo spremenili. Čeprav bi se moralo testiranje osredotočiti samo na logiko, to ne pomeni, da ne bi smeli opraviti sprejemnih testov na celotnem uporabniškem vmesniku. Všeč mi je nabor dimnih testov, ki so namenjeni osnovnemu uporabniškemu vmesniku" srečna cesta". Osredotočajo se na dele aplikacije, ki jih uporabniki najverjetneje uporabljajo, da bi kar najbolje izkoristili svojo izkušnjo. najmanjša količina testiranje. Če poskušate pokriti vse možne načine in uporabo uporabniškega vmesnika, in če se uporabniški vmesnik spremeni, boste morali spremeniti vse teste. Če na primer preizkusite uporabniški vmesnik za spletno mesto za e-trgovino, bo cesta z veseljem izbrala artikel, ga dodala v košarico, preverila in videla potrditev nakupa. Če ta scenarij ne uspe, res želite izvedeti čim prej. Za nekatere aplikacije, odvisno od kompleksnosti in življenjske dobe, boste morda želeli imeti več testov sprejemljivosti v uporabniškem vmesniku, da zagotovite več zaupanja v sloj uporabniškega vmesnika. Vendar pa je uspešno testiranje uporabniškega vmesnika težko vprašanje in nimam prostora, da bi ga pokril. Testiranje in sprejem sistemov 43 3Inteligentni testi. Ko zgodbo in scenarije poveste v jasni in razumljivi obliki, je naslednji korak avtomatizacija zgodbe in scenarijev. To jim omogoča, da tečejo med razvojem, da spremljajo napredek in ujamejo napake regresije. Sklepi in priporočila. Po drugi strani pa imamo sistemske teste, ki so odgovorni za vrednotenje delovanja skozi celoten proces, za odkrivanje napak, ki se pri tem lahko pojavijo, je treba razviti strategijo s testi in ločiti razvoj kode od razvoja vmesnika, zato je najbolje je izvesti sistemske teste. Izvedba teh dveh testov programske opreme mora biti izvedena s rigoroznimi testi, ki ustrezajo določenim standardom, in ob koordinaciji deležnikov, vključenih v razvoj sistema. Sistemsko testiranje in sprejem 44 Bibliografija 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Kvantitativne metode upravljanja pri razvoju programske opreme. Alonso Amo, Loic Martinez Normand. Uvod v razvoj programske opreme. Testiranje sistemov in prevzemno testiranje 45 8. -Oddelek za računalniške jezike in sisteme. Strukturni sistemska analiza. Metode za identifikacijo bakterij v mikrobiološkem laboratoriju.