Priėmimo testo apibrėžimas. Dokumentacijos kūrimas, prototipų gamyba ir testavimas. Automatizuotų sistemų standartų rinkinys

Paprastai šį testavimą atlieka kita komanda, kuri daug ką pakartoja automatiniuose priėmimo testuose rankiniu būdu arba su kitu įrankiu. Taip gali būti, nes priėmimo testai negali būti lengvai vykdomi skirtingose ​​aplinkose arba kūrimo komanda negali lengvai suprasti, ką atlieka testai, o naudojami duomenys yra paslėpti kode, todėl juos sunku rasti ar pakeisti. Paslėpus testo tikslą kode, sunku suprasti, ką bandymas bando padaryti.

Tai taip pat reiškia, kad netechniniai komandos nariai negali lengvai prisidėti prie testavimo, o techniniai žmonės daugiau laiko praleidžia prie automatinio testavimo kodo. Kai testus reikia pertvarkyti, o tai neišvengiamai atskiria tikslą nuo įgyvendinimo priemonių, galite sutelkti dėmesį į testo įgyvendinimo pertvarkymą, o ne į tai, ką testas turėtų atlikti.

Ketinimo, įgyvendinimo ir duomenų atskyrimas

Žemiau yra diagrama, iliustruojanti ketinimo, įgyvendinimo ir duomenų atskyrimo idėją. Aplinka taip pat yra įtraukta, nes svarbu suprasti, kokioje aplinkoje bus vykdomi testai ir, jei reikia, pakeisti duomenis ir vykdyti testą. Sukurti ketinimą gali netechniniai komandos nariai kalba, kuri nepriklauso nuo įgyvendinimo. Tai svarbu, nes tai reiškia, kad įgyvendinimą galima pertvarkyti nekeičiant testo tikslo. Ir atvirkščiai; galima pakeisti testo tikslą nedarant įtakos įgyvendinimui, jei yra įgyvendinimas, kuris atitinka visus ketinimų pastraipos žodžius.

Jei blogiausiu atveju nuspręsite mesti visą diegimą ir pradėti iš naujo, vis tiek galite išlaikyti bandymo tikslą ir neprarasti svarbiausios automatizuotų testų dalies, ką testai bando atlikti. Duomenys taip pat turi būti suskirstyti į ketinimus ir įgyvendinimus, tai darant duomenis teste galima nurodyti abstrahuojant ir tada įgyvendinimas pašalinamas. Pavyzdžiui, testas gali parodyti, kad „Auksinis klientas“, nes klientas identifikuojamas, nėra testo dalis, bet yra duomenų sluoksnio dalis.

Duomenų sluoksnio kūrimas ir duomenų abstrakcija nėra nauji metodai; jie paprastai naudojami programos kodui ir turėtų būti taikomi automatizuotiems testams, nes privalumai vis tiek taikomi. Bandomuoju atveju duomenų sluoksnis iškviečiamas, kad gautų duomenis iš duomenų šaltinio atitinkamam kliento tipui.

Tada bandomasis atvejis kartojasi per visus sąrašo įrašus ir atlieka kiekvieno kliento įrašo testą. Sistemos testai atitinka vieną iš programinės įrangos testavimo lygių kartu su įvairiais testais, tokiais kaip atkūrimo, saugumo, atsparumo, našumo, jungiamumo, apimties, įtampos, duomenų prieinamumo, naudojimo paprastumo, veikimo, Aplinka, saugojimas, konfigūravimas, diegimas ir dokumentacija. Kiekvienas iš jų turi skirtingą tikslą ir turi bendrą tikslą, kuris parodo sistemingą projekto viziją. Priėmimo testavimas yra dar vienas lygių tipas, kurį papildo programinės įrangos testavimo lygiai, šie testai yra labai svarbūs, nes jie leis mums gauti gaminį, atitinkantį reikiamus standartus ir tuo pačiu tenkinantį vartotojų reikalavimus pagal reikalavimai, kuriuos jie kėlė nuo pat pradžių. Tai verčia sistemą išbandyti gyvybiškai svarbų testavimo procesą, nes kalbant apie produktą, klaidų skaičių ir tų klaidų rimtumą, tai yra kūrimo žingsnis, kuris paprastai yra linkęs į daugumą klaidų. 1 pav. Pakartotinių sistemų tikrinimas Sistemos testai nėra procesai, skirti sistemos funkcionalumui patikrinti arba pilna programa, nes tai būtų nereikalinga atliekant funkcinio testavimo procesą. Sistemos testai turi konkretų tikslą: palyginti sistemą ar programą su jos pradiniais tikslais. Šiuo tikslu pateikiamos dvi vertės. Sistemos testavimas neapsiriboja sistemomis. Jei produktas yra programa, sistemos testavimas yra bandymas parodyti, kaip programa visiškai neatitinka savo tikslų ar reikalavimų. Sistemos bandymai pagal apibrėžimą neįmanomi, nebent yra rašytinių reikalavimų, kuriuos būtų galima išmatuoti gaminiui. Sistemos testavimas yra tyrimo etapas, kurio metu užtikrinama, kad kiekvienas komponentas arba modulis sąveikauja su kitais komponentais ar moduliais, kaip numatyta. Sistemos bandymai yra skirti giliai įdiegti sistemą, patikrinti informacinės sistemos integraciją visame pasaulyje, patikrinti, ar tinkamai veikia sąsajos tarp įvairių ją sudarančių posistemių ir su kitomis informacinėmis sistemomis, su kuriomis ji bendrauja. Klasikinė sistemos testavimo problema yra „rodymas pirštu“. Taip nutinka, kai aptinkama klaida ir kiekvieno sistemos elemento kūrėjas kaltina kitus. Užuot papuolęs į šį absurdą, programinės įrangos inžinierius turėtų numatyti galimų problemų su sąsaja:  projektavimo klaidų apdorojimo kelias, kuris tikrina visą informaciją, gaunamą iš kitų sistemos elementų. Sistemos testavimas ir testavimas 6  Taikykite testų seriją, imituojančią blogus duomenis ar kt galimų klaidų programinės įrangos sąsajoje.  Tyrimo rezultatus registruokite kaip įrodymą kaltės atveju.  Dalyvauti planuojant ir plėtojant sistemos testavimą, siekiant užtikrinti, kad programinė įranga buvo tinkamai išbandyta. Tiesą sakant, sistemos testas apima daugybę skirtingų testų, kurių pagrindinis tikslas yra giliai apskaičiuoti sistemą skaičiuojant. Nors kiekvienas testas turi skirtingą paskirtį, jie visi stengiasi įsitikinti, kad visi sistemos elementai buvo tinkamai integruoti ir atlieka atitinkamas funkcijas. 2 Testo sistemos peržiūra. Atliekant testavimą, būtina palaikyti sistemas, tai yra integruotas požiūris į programinės įrangos kūrimą. Taikant šias sąvokas programinės įrangos testavimui, gaunamas principų rinkinys, kuris bus testo pagrindas: turite įsitikinti, kad tiksliai žinote testuojamos programinės įrangos tikslus ir sėkmės rodiklius. Šiuos elementus galima rasti dokumentuose, gautuose reikalavimų rinkimo etape, taip pat programinės įrangos specifikacijose. Ši informacija bus reikalinga rengiant bandymo planą ir bus pagrindas pradėti rengti bandomąjį atvejį. Turi būti apibrėžti patvirtintos sistemos įėjimai ir išėjimai. Šis aspektas būtinas ruošiant testavimo atvejus, taip pat kuriant testavimo procedūras, ypač orientuotas į bandomuosius atvejus, kurios parodo tikslų įvykdymą. Apsvarstykite pagrindinę sistemą, kurioje veikia bandoma programinė įranga. Paprastai tai yra organizacinė aplinka, kurią sudaro techninė įranga, programinė įranga ir žmonės. Visi šie elementai daro didelę įtaką sistemai ir ypač padeda paruošti nepageidaujamų situacijų, susijusių su nepakankamais duomenimis, nebuvimu, bandomuosius atvejus. būtini elementai ir išimčių atsiradimą. 3 Sistemos testavimo apžvalga Sistemos testavimo procesą sudaro du etapai, kurie laikui bėgant gali būti labai skirtingi: paruošimas bandymui ir bandymo taikymas. Pirmasis yra glaudžiai susijęs su reikalavimais, todėl tai įvyksta projekto pradžioje, o antrajam reikia visos sistemos arba bent vieno integravimo, nes sakoma, kad dalinis produktas nėra išleistas, kad būtų galima taikyti bandymus, todėl tai įvyksta pažengusiuose projekto etapuose. projektą. Tiksli situacija su šiomis dalimis priklauso nuo pasirinkto modelio. gyvenimo ciklas. Antrajai ir trečiajai veiklai atlikti reikalingas reikalavimų dokumentas. Pirmajame testavimo etape pateikiamas grįžtamasis ryšys, siekiant analizuoti reikalavimus, nustatyti spragas, dviprasmybes ir kitas problemas. Jame taip pat pateikiama vertingų patarimų dėl sistemos kūrimo ir diegimo, jei tik ją kuriate. Bandomosios programos etapas reikalauja bandymo plano ir vykdomosios sistemos versijos. Tokiu atveju bus taikomi parengti testavimo atvejai, išanalizuoti rezultatai ir nustatyti defektai. Šis antrasis žingsnis suteikia grįžtamąjį ryšį apie įgyvendinimą ir dizainą, parodydamas galimus defektus, kuriuos reikia taisyti. Taip pat pateikiama informacija, kuri bus naudinga išleidžiant sistemą, ją pritaikant, įvertinant jos patikimumą ir prižiūrint. 1 paveiksle parodytas sistemos testavimo procesas ir jo ryšys su kitais procesais. Antras punktas yra svarbus, nes kartais sistemos testas painiojamas su sąsajos testu. Pirmasis tikrina visų dalių sąveiką, o antrasis analizuoja sąsajos elementus ir, galbūt, susijusių įvykių apdorojimą. Tačiau įrankius, padedančius išbandyti sąsają, galima naudoti sistemos bandymams vykdyti. Kyla keli klausimai: kiek bylų užteks? Kaip sugeneruoti kuo mažiau? Kokios vertės yra tinkamos? Sistemos testavimas ir testavimas 9 1 Bandymo planas Bandymo planas yra labai svarbus dokumentas programinės įrangos testavimo metu. Jame paaiškinami bandymų tikslai ir metodai, darbo planas, veiklos procedūros, reikalingų įrankių ir pareigas. Sistemos testavimas ir testavimas 10 Reikalavimų dokumente turi būti programinės įrangos atliekamų funkcijų sąrašas, jas aprašant ir nustatant prioritetus; ji taip pat turėtų apimti nefunkcinius reikalavimus, kurie gali apimti organizacinius, veiklos ir kitus aspektus. Gerai parengtas reikalavimų dokumentas turėtų suteikti galimybę kiekvienam reikalavimui patikrinti, ar jis laikomas. Funkcijų atveju tai būtų aprašymas, o nefunkcinių reikalavimų atveju tai galėtų būti labai tikslios specifikacijos, pavyzdžiui, atsako laikas. Kol kas daugiausia dėmesio skirsime funkciniams reikalavimams, likusią dalį paliksime vėlesniam skyriui. Sistemos testai svarbūs dėl šių veiksnių:  Sistema yra testuojama kaip visuma sistemos kūrimo gyvavimo ciklo metu.  Patikrinama, ar sistema atitinka jos funkcines ir Techniniai reikalavimai .  Sistema testuojama aplinkoje, kuri yra kuo artimesnė gamybinei aplinkai.  Sistemos testai leidžia išbandyti, patvirtinti ir patvirtinti tiek verslo reikalavimus, tiek taikomųjų programų architektūrą. 6Sistemos testų tipas Funkciniai testai  Integracijos testas. - Kurioje bandymo įranga turi prieigą prie sistemos šaltinio kodo. Kai aptinkama problema, integravimo komanda bando rasti problemos šaltinį ir nustatyti komponentus, kuriuos reikia derinti. Integracijos testavimas daugiausia susijęs su sistemos defektų nustatymu.  Pristatymo įrodymas. Čia yra sistemos versija, kurią galima pristatyti vartotojui. Čia testavimo komandai rūpi patikrinti, ar sistema atitinka jos reikalavimus ir garantuoja sistemos patikimumą. Pristatymo testai paprastai yra juodosios dėžės bandymai, kurių metu bandymo įranga tiesiog rūpinasi, ar sistema veikia tinkamai. Komponentai, kuriuos galima integruoti, gali būti komerciniai komponentai, daugkartinio naudojimo komponentai, pritaikyti konkrečiai sistemai, arba naujai sukurti komponentai. Daugeliui didelių sistemų greičiausiai bus naudojami visų trijų tipų komponentai. Integravimo testas patikrina, ar šie komponentai iš tikrųjų veikia kartu, yra tinkamai iškviečiami ir tiksliu laiku perduoda teisingus duomenis per jų sąsajas. Sistemos integravimas apima komponentų grupių, kurios teikia tam tikras sistemos funkcijas, identifikavimą ir jų integravimą pridedant kodus, kad jie veiktų kartu. Kartais pirmiausia sukuriamas visos sistemos karkasas, pridedami komponentai. Tai vadinama postintegracija. Tai integracija į viršų. Praktiškai daugelio sistemų integravimo strategija yra abiejų derinys, pridedant papildomų infrastruktūros komponentų ir funkcinių komponentų. Abu integravimo metodai reikalauja papildomo kodo, kad būtų galima modeliuoti kitus komponentus ir paleisti sistemą. Pagrindinis sunkumas, su kuriuo susiduriama atliekant integravimo testus, yra klaidų vieta. Tarp sistemos komponentų yra sudėtinga sąveika, o aptikus anomalią išvestį gali būti sunku nustatyti, kur įvyko klaida. Kad būtų lengviau išskirti klaidas, visada turėtumėte naudoti laipsnišką sistemos integravimo ir testavimo metodą. Pagrindinis šio proceso tikslas – padidinti tiekėjo pasitikėjimą, kad sistema atitinka jo keliamus reikalavimus. Jei taip, jis gali būti pristatytas kaip produktas arba pristatytas klientui. Norint įrodyti, kad sistema atitinka jos reikalavimus, turi būti įrodyta, kad ji užtikrina nurodytą funkcionalumą, našumą ir patikimumą ir kad ji nesugenda normaliai naudojant. Pristatymo testai paprastai yra juodosios dėžės testavimo procesas, kurio metu testai nustatomi pagal sistemos specifikaciją. Į sistemą žiūrima kaip į juodąją dėžę, kurios elgseną reikėtų nustatyti tik ištyrus atitinkamas įvestis ir išvestis. Kitas pavadinimas yra funkcinis testavimas, nes testuotoją domina tik programinės įrangos funkcionalumas, o ne įdiegimas. Toliau pateiktame paveikslėlyje pamatysime sistemos modelio, kurį jis leidžia patvirtinti juodojoje dėžėje, iliustraciją. Testeris pateikia įvestis komponentui ar sistemai ir atsižvelgia į įvestis. Kai kuriais atvejais sistema turi būti atspari gedimams; tai yra, apdorojimo gedimai neturėtų sukelti visos sistemos gedimų. Bandymo sistemos ir priėmimo testai 14 Sistemos gedimas turi būti ištaisytas per tam tikrą laikotarpį, kitaip jis turės rimtos ekonominės žalos. Atkūrimo testas yra sistemos testas, dėl kurio programinė įranga sugenda keliais būdais ir patikrinama, ar atkūrimas atliktas tinkamai. Jei atkūrimas vyksta automatiškai, turite patikrinti, ar teisingas inicijavimas, sistemos atsarginių kopijų kūrimo mechanizmai, duomenų atkūrimas ir perkrovimas. Jei pasveikimui reikalingas žmogaus įsikišimas, reikia nustatyti vidutinį atsigavimo laiką, kad būtų galima nustatyti, ar jis neviršija priimtinų ribų. Tikslas yra nustatyti galinius taškus, kuriuose sistema pradeda veikti žemiau nurodytų reikalavimų. Tai neturėtų būti painiojama su tūrio testu; aukšta įtampa yra didžiausias duomenų arba veiklos kiekis vienam trumpam laikui. Analogija būtų vertinti mašininkę. Apimties testas bus nustatytas, jei mašininkė susiduria su didelės ataskaitos juodraščiu; testavimas nepalankiausiomis sąlygomis nustatys, ar mašininkė gali spausdinti 50 žodžių per minutę greičiu. Pažeidimas apima daugybę veiksmų:  įsilaužėlis, kuris bando prisijungti per žaidimą. Saugumo testas patikrina, ar sistemoje įmontuoti apsaugos mechanizmai tikrai apsaugo ją nuo netinkamų įsilaužimų. „Sistemos turi būti išbandytos, kad sistemos saugumas būtų atsparus priekinėms atakoms, bet ir tiems, kurie daro šonus ar užpakalį. Saugumo testo metu kiekvienas, kuris jį taiko, atlieka norinčio prisijungti asmens vaidmenį. Visa tai verta! Turėtumėte pabandyti gauti bet kokius slaptažodžius išorinėmis priemonėmis; gali atakuoti sistemą naudodamas specialią programinę įrangą, skirtą apeiti bet kokią apsaugotą architektūrą; jis gali prisotinti sistemą, taip atsisakydamas tarnauti kitiems; gali sukelti tyčinių klaidų sistemoje bandant gauti prieigą atkūrimo metu: galite peržiūrėti duomenis be apsaugos, turėdami mintį ieškoti sistemos slaptažodžio. Jei bus suteikta pakankamai laiko ir išteklių, sistema galiausiai tai padarys geras testas saugumui. Sistemos kūrėjo vaidmuo yra tas, kad nutraukimo kaina yra didesnė nei gautos informacijos kaina. Tačiau žmogiškųjų veiksnių analizė tebėra labai subjektyvi problema. Bandomieji atvejai skirti parodyti, kad šie saugyklos objektai nerandami. Dažnai galimų konfigūracijų skaičius yra per didelis, kad būtų galima išbandyti kiekvieną, tačiau jei įmanoma, turėtumėte išbandyti programą su kiekvieno tipo aparatūros įrenginiu ir su minimalia bei maksimalia konfigūracija. Jei pačią programą galima sukonfigūruoti praleisti komponentus arba jei ji gali veikti keliuose kompiuteriuose, kiekviena konfigūracija turi būti išbandyta. Diegimo procedūrų testavimas yra svarbi sistemos testavimo proceso dalis. Tai ypač pasakytina apie sistemą automatinis montavimas įtraukta į programinės įrangos paketą. Netinkamai paleista diegimo programa gali neleisti vartotojui sėkmingai naudotis sistema. Pirmoji vartotojo patirtis yra tada, kai jis įdiegia programą. Vienas iš būdų tai pasiekti yra naudoti dokumentaciją, kad būtų galima apibrėžti ankstesnių sistemos bandymų atvejų vaizdą. Tai yra, kai norite sukurti perkrovos atvejį, turėtumėte naudoti dokumentaciją kaip vadovą, kaip parašyti tikrąjį bandomąjį atvejį. Be to, naudotojo dokumentacijos tikslumas ir aiškumas turėtų būti tikrinami. Bet kuris iš dokumentacijoje pateiktų pavyzdžių turi būti išbandytas ir įtrauktas į darbų sąrašą bei įtrauktas į programą. Sistemos testavimas ir testavimas 17 veikimo požiūriu, po sistemos priėmimo faktinėje aplinkoje ir remiantis atitikimu nurodytiems nefunkciniams reikalavimams. Atsparumo bandymas skirtas kovoti su programomis neįprastose situacijose. Iš esmės žmogus, atliekantis pasipriešinimo testą, paklaus. Kiek nuveiki, kol nepavyks? Atsparumo testas atlieka sistemą taip, kad jai reikia neįprastai daug, dažnai ar daug išteklių. Pavyzdžiui:  sukurti specialūs testai, kurie generuoja 10 pertraukimų per sekundę, kai vidutinis puodelis yra vienas ar du.  Duomenų įvedimo dažnis padidinamas tokiu kiekiu, kuris leis reaguoti į įvesties funkcijas.  Vykdykite bandomuosius atvejus, kuriems reikia maksimalios atminties ar kitų išteklių.  Bandomieji atvejai yra skirti atminties valdymo problemoms pašalinti. Sukuriami bandomieji atvejai, dėl kurių per daug ieškoma diske. Paveikslas yra atsparumo bandymo pavyzdys. Veiklos testas taikomas visuose testavimo proceso etapuose. Net vieneto lygiu. Atskiro modulio veikimas turėtų būti įvertintas testavimo metu. Tačiau tik tada, kai visi sistemos elementai yra visiškai integruoti, galima pasiekti tikrą sistemos veikimą. Veikimo testai dažnai apima atsparumo bandymus ir dažnai reikalauja programinės įrangos ir aparatinės įrangos instrukcijų. Tai yra, dažnai reikia tiksliai išmatuoti išteklių naudojimą. Naudodami išorinius įrankius galite reguliariai stebėti paleidimo intervalus, registruojamus įvykius ir aparatinės įrangos pavyzdžių būseną. Šie testai atliekami tam, kad klientas patvirtintų, jog sistema jam tinka. Išsamus šių bandymų planavimas turėtų būti atliktas ankstyvoje kūrimo fazėje, siekiant panaudoti rezultatus kaip jų pagrįstumo požymį: jei dokumentais pagrįsti testai atliekami taip, kad klientai būtų patenkinti, produktas laikomas teisingu ir todėl tinkamas naudoti. gamyba. 6 Priėmimo testai2 iš esmės yra visos sistemos funkciniai testai ir jais siekiama patikrinti, ar nustatytų reikalavimų . Jo vykdymas yra neprivalomas klientui, o jei jie nėra aiškiai nurodyti, jie įtraukiami į sistemos testus. Tai reiškia, kad už priėmimo testus dažnai atsako vartotojas arba klientas, nors juos atlikti gali bet kas, dalyvaujantis versle. Priėmimo testavimui reikalinga bandymo aplinka, atitinkanti gamybos aplinką. Šis etapas arba lygis, kaip atskaitos taškas, apibrėžia produkto priėmimo pradinę liniją, jau nustatytą sertifikavimo aplinkoje. Sistemos testavimas ir priėmimas 19 pav. Priėmimo valdymas. 1 Esamos situacijos analizė priėmimo testuose. Vykdydami testus turime patikrinti programinę įrangą, vienas iš svarbiausių yra priėmimo testavimas. Tai yra testai, kuriuos pati kūrėjų komanda kuria remdamasi analizės etape nurodytais funkciniais reikalavimais, kad apimtų visą spektrą ir būtų atliekami galutinio vartotojo, tačiau ne visi, išskyrus keletą vartotojų, turi reikšmingą rezultatą, kuris suteikia galiojimas ir atitiktis gaminiui, kuris jiems pristatomas remiantis tuo, kas buvo sutarta iš pradžių. Priklausomai nuo testuojamos sistemos sudėtingumo, neatsižvelgiant į tai, ar ji suskirstyta į modulius ir pan. šių testų vykdymas atliekamas skirtingai. Jei programa būtų padalinta į modulius, jie būtų laikomi posistemiais ir būtų pakankamai sudėtingi, kad juos būtų galima tvarkyti skirtingai, reikėtų atlikti skirtingas priėmimo testų sesijas. 2 Priėmimo bandymo tikslas Priėmimo bandymo tikslas – gauti galutinio pirkėjo sutikimą prieš pristatant gaminį pradėti gaminti. Organizacijai atlikus sistemos bandymus ir pašalinus daugumą jos defektų, sistema bus pristatyta vartotojui ar klientui patvirtinti. Priėmimo testavimo tikslas – patikrinti, ar sistema atitinka numatytą veikimą, ir leidžia tos sistemos vartotojui nustatyti, ar ji yra priimtina pagal jos funkcionalumą ir veikimą. Priėmimo testus nustato sistemos vartotojas, o rengia kūrėjų komanda, nors galutinis vykdymas ir patvirtinimas priklauso nuo vartotojo. Sistemos patvirtinimas pasiekiamas vykdant juodosios dėžės testus, kurie parodo atitiktį ir yra įtraukti į bandymų planą, kuriame apibrėžiami atliktini patvirtinimai ir su jais susiję bandymų atvejai. Šis planas skirtas užtikrinti, kad būtų įvykdyti visi vartotojo nurodyti funkciniai reikalavimai, taip pat nefunkciniai reikalavimai, susiję su našumu, sistemos prieigos, duomenų ir procesų bei įvairių sistemos išteklių saugumu, 3 Priėmimo testavimo generavimas. Sistemą turi priimti vartotojas. Dėl šios priežasties, remdamasis struktūrizuotomis sistemos specifikacijomis, analitikas sukuria bandomųjų atvejų rinkinį, kuris turi būti patenkinamas. Kadangi priėmimo testai gali būti rengiami lygiagrečiai su projektavimo ir praktikos veikla, normalu, kad analitikas šią veiklą pradeda iškart, kai tik baigiama struktūrinės analizės veikla. 4 Priėmimo testavimo strategijos Jei sistema būtų sukurta masinei rinkai, tai būtų nepraktiška ją išbandyti atskiriems vartotojams ar klientams, kai kuriais atvejais tai būtų neįmanoma. Tokiais atvejais prieš pateikiant gaminį pardavimui būtina pateikti atsiliepimą. Dažnai tokios sistemos turi du priėmimo testavimo etapus. Alfa ir beta versijos testavimas Kai klientui kuriama pasirinktinė programinė įranga, atliekama daugybė priėmimo testų, kad klientas galėtų patikrinti visus reikalavimus. Atlieka klientas kūrimo vietoje. Programinė įranga natūraliai naudojama kartu su kūrėju kaip naudotojo stebėtoju, taip pat atsiranda registracijos klaidų ir naudojimo problemų. Alfa testai atliekami kontroliuojamoje aplinkoje. Dirbate kontroliuojamoje aplinkoje, o klientas visada turi ekspertą, kuris padės jums naudotis sistema. Kūrėjas seka rastas klaidas ir naudojimo problemas. Β-beta testai atliekami po α-alfa testo ir kuriami kliento aplinkoje. Tokiu atveju klientas lieka vienas su produktu ir bando rasti klaidų, kurios informuoja kūrėją. Juos atlieka galutiniai programinės įrangos vartotojai kliento darbo vietose. Skirtingai nuo alfa testo, kūrėjo paprastai nėra. Taigi beta versijos testas yra tiesioginė programinės įrangos taikymas aplinkoje, kurios kūrėjas negali valdyti. Klientas registruoja visas problemas, kylančias atliekant beta versijos testavimą, ir reguliariai praneša kūrėjams. 5 Priėmimo testo įėjimai, išėjimai, užduotys ir vaidmenys. Įstojimo reikalavimų specifikacija. Užduotys Paruoškite bandymo aplinką. Rekomenduojame tokio tipo testavimui turėti specialią testavimo aplinką. Diegimas bandomojoje aplinkoje. Sistemos testavimas ir testavimas 22 Nurodykite atliktinus testus. Galimos priklausomybės, kurios egzistuoja tarp testų, bus nustatytos ir testų vykdymo tvarka arba seka bus nustatyta remiantis šiomis priklausomybėmis. Rezultatų gavimas ir registravimas. Ištaisytos klaidos ir klaidos. Kartokite užduotį tol, kol išlaikysite visus testus. Priėmimo bandymo ataskaitos ruošimas. Visų pateiktų testų teisingo vykdymo ir rezultatų apžvalga. Gamybos bazės sukūrimas. Formalus veiklos uždarymas. Testo rezultatai. Priimta produkto priėmimo ataskaita. Projekto vadovas. Dėmesys priimtinumo testavimui yra susijęs su bandymu sustiprinti nuomonę, kad į šį etapą įtrauktas vartotojas ankstyvoje stadijoje padėtų pagerinti šį procesą bandymo planavimo ir projektavimo etape, o vėliau patobulintų daug kiekybinių ir pageidaujamų aspektų. , pvz.: Integruotos programinės įrangos saugumo kokybės gerinimas. Išlaidų sumažinimas. Padidėjęs projekto rezultatų patikimumas. Naudojant programinę įrangą su mažiau klaidų, didėja klientų pasitenkinimas. Tai pagerina kūrimo proceso efektyvumą. 7 Priėmimo tikrinimo kriterijai. Programinės įrangos priėmimas pasiekiamas atliekant daugybę testų, kurie parodo, kad ji atitinka reikalavimus. Bandymų plane aprašomas taikytino testo tipas, o bandymo procedūra apibrėžiami konkretūs bandymo atvejai, tiek planas, tiek procedūra yra sukurti taip, kad atitiktų visus funkcinius reikalavimus, kad būtų pasiektos visos elgsenos charakteristikos, visi veiklos reikalavimai, dokumentacija. yra teisinga ir atitinka visus naudojimo paprastumo ir kitus reikalavimus nurodytus reikalavimus. 8 Priėmimo testų įrankiai. Tai leidžia klientams, testuotojams ir programuotojams žinoti, ką jų programinė įranga turi daryti, ir automatiškai palyginti, ką ji iš tikrųjų daro. Leidžia rašyti testus, kuriuos būtų lengva skaityti ir lengva prižiūrėti. Ši veikla žinoma kaip galutinis bandymas arba priėmimo testas. Tam reikia įvesti priėmimo testo duomenis ir šios veiklos metu sukurtą integruotą sistemą. Testą atliks koks nors vartotojo narys ar skyrius arba net nepriklausomas kokybės kontrolės skyrius. Svarbu pažymėti, kad kiekvienoje ankstesnėje analizės, projektavimo ir įgyvendinimo veikloje svarbu atlikti kokybės kontrolės veiksmus, siekiant užtikrinti, kad jie buvo atlikti iki tinkamo kokybės lygio. Taip užtikrinama, kad analitikas parengs kokybės specifikacijas, dizaineris – kokybiškus dizainus, o programuotojas – kokybiškas kodavimo programas. Informatikos moksle įgyvendinimas yra techninė specifikacija arba algoritmai, pavyzdžiui, programa, programinės įrangos komponentas ar kita kompiuterinė sistema. Daugelis diegimų pateikiami pagal specifikaciją arba standartą. Apibendriname ankstesnį autorių darbą, kad gautume testo tikslus, kurie yra atspirties taškas kuriant automatinius testus. Sistemos testavimo iš naudojimo atvejų kontekste testavimo tikslas gali būti išreikštas kaip naudojimo atvejis. Šį scenarijų sudarys veiksmų seka be galimos alternatyvos ir bandymo verčių rinkinys ir prielaidas ir po konferencijų, susijusių su šiuo scenarijumi. Norint sukurti bandymo scenarijus, pirmiausia iš pagrindinės sekos ir klaidų bei alternatyvių naudojimo atvejo sekų sudaroma veiklos diagrama. Veiklos diagramoje sistemos atliekami veiksmai ir dalyvių atliekami veiksmai yra stereotipiniai. Tada atliekama kelio analizė ir kiekvienas veiklos diagramos kelias bus naudojimo atvejo scenarijus, taigi ir galimas bandymo tikslas. 2 Sistemos testų įgyvendinimas. Sistemos testavimo architektūra. Sistemos testų vykdymo ir automatinio tikrinimo architektūra parodyta 7 paveiksle. Ši architektūra yra panaši į architektūrą, reikalingą kitų tipų testams, pavyzdžiui, vienetiniams testams, automatizuoti. Pagrindinis skirtumas yra tas, kad vienetinio testo metu pats testas iškviečia vykdomąjį kodą, o bandomosios sistemos funkciniam testui ir testo priėmimui 27 reikalingas tarpininkas, žinantis, kaip manipuliuoti išorine sąsaja. Bandomųjų atvejų įgyvendinimas. Testas-testas yra testavimo tikslo įgyvendinimas. Bendra bandomojo atvejo elgsena yra pateikta lentelėje Bendra bandymo atvejo elgsena. Kiekvienas naudojimo atvejis bus susietas su bandymų rinkiniu. Šiame rinkinyje bus visų minėto naudojimo atvejo scenarijų bandymai. Kaip matyti iš bandymo tikslų, kiekvienas veiksmas turi būti nurodytas, ar jį atlieka veikėjas, ar bandoma sistema. Ši informacija yra labai svarbi koduojant paketų bandymo metodus. Visi veikėjo atliekami veiksmai paverčia bandomojo kodo kodą į sąveiką tarp bandomojo atvejo ir sistemos. Sistemos testavimas ir priėmimo testavimas 29 Reikalingoms bandymo reikšmėms nustatyti bus taikoma operacinė ir kategorijos kintamųjų metodika. Nustatyti trys įvairių tipų operatyviniai kintamieji. Kiekvienas tipas bandomaisiais atvejais bus įgyvendintas skirtingai. Pirmąjį tipą sudaro tie operaciniai kintamieji, kurie rodo išorinio subjekto informacijos perdavimą į sistemą. Kiekvienam šio tipo kintamajam bus apibrėžta nauja klasė, kurios objektuose bus skirtingos šio kintamojo testo vertės. Šio tipo darbo kintamojo pavyzdys parodytas atvejo tyrime. Antrasis tipas susideda iš tų operatyvinių kintamųjų, kurie rodo pasirinkimą tarp kelių išorinio veikėjo galimų variantų. Vietoj to, toks pasirinkimas bus tiesiogiai įgyvendintas kaip kodo, įgyvendinančio veikėjo ir sistemos sąveiką, dalis. Trečiasis tipas susideda iš tų veikimo kintamųjų, kurie rodo sistemos būseną. Norėdami įgyvendinti bandomojo atvejo nustatymo metodą, parašykite reikiamą kodą, kad teisingai nustatytumėte operacinių kintamųjų, apibūdinančių sistemos būsenas, reikšmes arba patikrintumėte, ar reikšmės sutampa. Panašiai pertraukos metodas turi atkurti šias vertes į pradines būsenas. Be to, sekimo metodas turi, jei reikia, neįtraukti informacijos, kurią bandomoji byla įveda į sistemą vykdant bandomąjį atvejį. Atvejo tyrime pateikti keli tokio tipo operacinių kintamųjų pavyzdžiai. Šiuo atveju pirmiausia reikia pritaikyti tai, kas buvo matyta, norint gauti testo tikslų rinkinį iš naudojimo atvejo. Tada nustatomos naudojamo bandymo diržų charakteristikos. Galiausiai pritaikome tai, ką matėme ankstesnes dalisįgyvendinti bandomąjį atvejį iš bandymo tikslo. Bandoma sistema buvo identifikuota artefaktai Anglų kalba, kiek Ispanų kalba nepalaikoma naudojamų įrankių. Naudojimo atvejis 2 lentelėje aprašo naujos nuorodos įvedimą sistemoje. Be to, taip pat rodomas reikalavimas saugoti informaciją, apibūdinančią kiekvienos nuorodos tvarkomą informaciją. Iš naudojimo atvejo ir automatiškai sugeneruotas scenarijų rinkinys, kurio tikslas bus išbandyti minėtą naudojimo atvejį. Atsižvelgiant į tai, kad naudojimo atvejis turi neribotas kilpas su begaliniu galimų pasikartojimų skaičiumi, aprėpties kriterijus pasirinktas 01 kriterijus, kuris tikrina ir testuoja 30 sistemos testus, susideda iš visų galimų kelių, kad nebūtų kartojamas nė vienas arba vienas kartas. kiekviena iš kilpų. Visi pagal šį kriterijų gauti ir į ispanų kalbą išversti scenarijai pateikti lentelėje. Šiam atvejo tyrimui pasirinkome 09 scenarijų, kuris išsamiai aprašytas 5 lentelėje. Testavimas ir testavimas testuojant 31 Lentelė Informacijos reikalavimas nuorodoms. Taip pat galite taikyti kategorijų padalijimo metodą. Kiekvieno iš šių kintamųjų skyriai yra išvardyti lentelėje. Sistemos testavimas ir testavimas 32 Lentelės kintamieji, apibrėžti naudojimo atvejui. Testavimas ir testavimas testuojant 33 Identifikuotų kintamųjų kategorijų lentelė. Kaip aprašyta 7 paveiksle, diržų testas skirtas imituoti vartotojo elgesį ir pasiūlyti teiginių rinkinį rezultatui įvertinti. Šis vertimas šiuo metu atliekamas rankiniu būdu ir rodomas lentelėje. Siųstuvo-imtuvo testavimas ir testavimas 35 pav. Bandymo atvejo įgyvendinimas. Vertimas į vykdomąjį veiksmų kodą, kurį vartotojas atlieka pagrindiniame scenarijuje. Tai yra, įsitikinkite, kad kategorijos egzistuoja ir ar nėra aplinkybių, sukeliančių klaidą atkuriant kategorijas arba įterpiant naują nuorodą. Pertraukos metodo įgyvendinimas buvo atkurti pradinį sistemoje saugomų nuorodų rinkinį. 2 Priėmimo testų vykdymas. Priėmimo testai veikia tik su klientų palaikymo tarnyba arba bent jau įgaliotuoju klientu, kad nustatytų kriterijus. Neturint tvarkyklės priėmimo kriterijų tampa sunku patikrinti, ar kuriate tinkamą programinę įrangą. Klientas, kartu su visais kūrimo komandos nariais, turi susiburti, kad apibrėžtų sistemą kaip „scenarijų“, apibūdinančių, ką ir kaip turi daryti sistema. Sukūrus testus su aiškiais reikalavimais ir patvirtinimo kriterijais, programinė įranga labiau pateisins klientų lūkesčius. Tačiau tai reiškia, kad kažkas rankiniu būdu patikrina, ar laikomasi reikalavimų ir ar programa veikia taip, kaip tikėtasi. Čia atliekami automatiniai priėmimo testai, o ne reikalavimai sename dokumente. Reikalavimai apibrėžiami kaip pavyzdžiai ir scenarijai, saugomi šaltinio valdyme su diegimo artefaktais ir gali būti vykdomi bet kuriuo metu siekiant patikrinti, ar jie atitinka kokius nors reikalavimus ir ar tinkamai veikia. Galite naudoti tą patį metodą, norėdami rašyti testus, bet užuot įvedę juos į bandomųjų atvejų valdymo programinę įrangą ar skaičiuoklę, įrašykite juos tiesiai į kodą. Sistemos testavimas ir testavimas 37 1 Automatinis priėmimo tikrinimas. Todėl pirmasis žingsnis diegiant bet kokį naują funkcionalumą – testu aprašyti savo lūkesčius. Kiti to nedaro, o laikui bėgant susiduria su proceso kontrole, ypač kai daugėja įrodymų, o testavimo lankstumas pradeda prastėti. Bandymu pagrįstas metodas grindžiamas tuo, kurie testai turėtų vadovautis kuriant programinės įrangos produktą. Pramoniniuose programinės įrangos produktuose, kai naudojami reikalavimų inžineriniai metodai, jie dažniausiai palaikomi natūralia kalba, o tai sukelia visiems žinomą dviprasmiškumo nepatogumą. Tačiau patvirtinimo poreikis gali nusverti naudą, kurią gali pasiūlyti formalesnė ir griežtesnė reikalavimų specifikacija. Klientas turi mokėti perskaityti ir suprasti reikalavimus, kad galėtų su jais sutikti. Populiariausi reikalavimų apibrėžimo metodai yra išvardyti skyriuje Naudojimo atvejai ir naudotojų istorijos. Apibrėžti reikalavimus yra raktas į kliento pritraukimą. Reikalavimai – pasiekimo tikslas, tai yra, ko klientas tikisi iš programinės įrangos produkto. Sistemos testavimas ir testavimas 38 vaidmenys, susiję su reikalavimų specifikacija ir patvirtinimo bei priėmimo testavimu. Reikalavimų sąvoka tampa Priėmimo testų konteineriu, o būtent jie užima svarbiausią vietą kaip kiekvieno reikalavimo specifikacija. Apsvarstykite reikalavimą „Išsiimti pinigus“ bankomato kontekste. Tipiška aprašomoji specifikacija gali būti tokia: Klientas turi turėti galimybę iš kasos pasiimti grynųjų tam tikromis sumomis. Visada gaukite kvitą, jei kasininkė neturi popieriaus. Kalbant apie pageidaujamą klientą, galite atsiimti Daugiau pinigų nei turite savo paskyroje, tačiau turėtumėte būti įspėti, kad būsite apmokestinti procentais. Prieš patvirtindamas atšaukimą, klientas turi turėti galimybę bet kada atšaukti. Sumas turi būti galima aptarnauti tuo metu kasininko turimomis sąskaitomis, o kitos sumos nepriimamos. Paveikslas – specifikacijų alternatyvos 10 paveiksle parodytos kai kurios šio reikalavimo specifikacijos alternatyvos. Piktogramos atspindi kiekvienos specifikacijos patogumą. Gali būti įdomu sukurti sekos diagramą, kad būtų galima apibrėžti kiekvieną reikalavimo įvykdymo scenarijų, tačiau apskritai tai netinka dėl didelis skaičius sukurtos diagramos. Įdomiau nustatyti scenarijus, nei iliustruoti kiekvieną diagramoje. Pasakojimo aprašymas nėra vienkartinis, bent jau trumpas apibrėžimas reikalavimus, kuriuose pagrindinis dėmesys skiriamas susijusių sąvokų apibrėžimui. Tačiau naudojimo modelis netinka iliustruoti išsamią programinės įrangos produkto reikalavimų struktūrą ilgalaikės priežiūros aplinkoje, nes vidutinis programinės įrangos produktas gali turėti tūkstančius reikalavimų. Norint įsivaizduoti ir valdyti daugelį reikalavimų, reikalingi tinkamesni mechanizmai. Šablonai yra viena iš dažniausiai naudojamų alternatyvų naudojimo atvejams. Šablonai yra elegantiški ir suteikia specifikacijos tvarkos pojūtį. Tačiau jie paprastai yra neproduktyvūs, nes jie paprastai užtikrina vienodą detalių apdorojimą visiems reikalavimams. Šiais labai paprastais atvejais jie apima dalykus, kurie yra akivaizdūs arba nesvarbūs, kad apimtų visas šablono dalis. Kai reikalavimas apima kelis scenarijus, bandymas sintezuoti visus šablono scenarijus paprastai sukelia painias specifikacijas. Tokiu būdu reikalavimai šaliai veikia kaip konteineriai. Atsižvelgiant į poreikį, gali būti naudingos kitos papildomos specifikacijos formos. Pavyzdžiui, veiklos diagrama, jei elgsena, susijusi su reikalavimu, turi algoritminį simbolį, arba būsenos diagrama, jei elgsena apima veiksmų įjungimą arba išjungimą pagal sistemos tvirtinimus ir sistemos priėmimo testus. Esminė sąlyga yra pragmatiškumas specifikacijos atžvilgiu, kuris netrukdo dalytis specifikacijos alternatyvomis, tačiau pagrindinis kriterijus turėtų būti noras būti pelningu ir prisidėti prie tos specifikacijos išlaikymo. Kita vertus, kalbant apie pastangas priežiūra, ypač nuoseklumo požiūriu, svarbu nepersistengti dubliuoti ar nesidubliuoti specifikacijų skirtingomis priemonėmis atstovavimas. Nukreiptas grafikas yra tinkamas lygiui patikslinti. Šis grafikas leidžia vizualizuoti skilimo ryšius ir priklausomybes tarp reikalavimų. Taigi kiekvienas mazgas yra funkcinis arba nefunkcinis reikalavimas. Lankai tarp mazgų sukuria ryšius tarp tėvų ir vaikų, arba „mazgų, turinčių įtakos mazgams“, priklausomybės ryšius. Taigi aukščiau pateiktame pavyzdyje reikalavimas „Išsiimti pinigus“ gali būti reikalavimų struktūros mazgas. Grąžinti su kliento įvestu kiekiu. Bilietų nėra. Nėra popieriaus gauti. Viršytas ryšio su centrine sistema laikas. Pranešimas apie vidines kasos operacijas. Baigėsi laikas pradėti veiksmą. Tai gali būti susiję su funkciniu arba nefunkciniu reikalavimu. Jis neprivalomas ir naudojamas išankstinėms sąlygoms nustatyti prieš taikant bandymo veiksmus. Tai veikėjo sąveikos su sistema veiksmai. Kai jie atlieka kelis veiksmus, jie gali būti įtraukti į sunumeruotą sąrašą. Tai yra aktorių sąveikos poveikis. Kiekvienas veiksmas gali sukelti vieną ar daugiau rezultatų. Svarbu, kad kalbant apie pranešimus vartotojui, tekstas būtų įtrauktas į laukiamą išvestį, todėl programuotojas jau turi šią informaciją patikrinęs su klientu. Tai, kaip nurodysime toliau, nustatys reikalavimų priklausomybę. Būklė Turi būti įprastas klientas. Veiksmai  Pabandykite grąžinti pinigus įprastam klientui ir paprašykite sumos, viršijančios likutį.  Laukiamas rezultatas. Sistemos patikrinimas ir priėmimas 42  Rodomas pranešimas „Prašomas kiekis viršija esamą likutį, įveskite kiekį iš naujo“ ir grįžta į langą, kuriame reikia įvesti kiekį. Priėmimo testavimas padės patvirtinti, kad kuriate kliento pageidaujamą programą, o automatizuodami šiuos scenarijus galėsite nuolat tikrinti programą viso kūrimo proceso metu ir naudoti juos kaip regresijos testavimo rinkinio dalį, kad užtikrintumėte, jog būsimi pakeitimai nepažeis dabartinių. vienų reikalavimų. Tačiau kliento susiejimas su įrodymų rinkimu, ypač automatizuotu testavimu, kelia nemažai galimų problemų. Paprastai klientai yra netechniniai ir linkę atsiriboti nuo paties programinės įrangos kūrimo. Klientas gali pateikti duomenis ir pavyzdžius, o bandytojai ar kūrėjai gali greitai koduoti scenarijus ir vykdomąsias specifikacijas. Vartotojo sąsajos priėmimo testai Pavyzdžiuose priėmimo testai buvo skirti verslo logikai ir domeno objektams, siekiant išsiaiškinti, ar logika sėkmingai veikia. O kaip vartotojas sąveikauja su programa? Šie priėmimo testai turėtų būti naudojami norint patikrinti logikos teisingumą vartotojo požiūriu, o vartotojo požiūriu yra vartotojo sąsaja. Jei programa gerai atsiejama ir logika gerai atskirta nuo vartotojo sąsajos kodo, tai turėtų palengvinti testų įgyvendinimą. Jei testuosite šiame lygyje, vartotojo sąsajoje testai nepasikeis. Nors testavimas turėtų būti sutelktas tik į logiką, tai nereiškia, kad neturėtumėte išlaikyti visos vartotojo sąsajos priėmimo testų. Man patinka turėti dūmų testų rinkinį, skirtą pagrindinei vartotojo sąsajai. laimingas kelias“. Jie sutelkia dėmesį į tas programos dalis, kurias naudotojai dažniausiai naudoja, kad išnaudotų visas savo naudojimo galimybes. mažiausias kiekis testavimas. Jei bandysite viską aprėpti galimi būdai ir vartotojo sąsajos naudojimas, o pasikeitus vartotojo sąsajai teks keisti visus testus. Pavyzdžiui, jei išbandysite elektroninės prekybos svetainės vartotojo sąsają, kelias mielai pasirinks prekę, įdės ją į krepšelį, patikrins ir pamatys pirkimo patvirtinimą. Jei šis scenarijus nepavyks, tikrai norite kuo greičiau tai išsiaiškinti. Tam tikroms programoms, atsižvelgiant į sudėtingumą ir naudojimo trukmę, gali reikėti atlikti daugiau NS priėmimo testų, kad įsitikintumėte, jog labiau pasitikite vartotojo sąsajos sluoksniu. Tačiau sėkmingas UI testavimas yra sunkus klausimas ir aš neturiu vietos jo uždengti. Sistemų testavimas ir priėmimas 43 3Pažangūs testai. Papasakoję istoriją ir scenarijus aiškiu ir suprantamu formatu, kitas žingsnis yra automatizuoti istoriją ir scenarijus. Tai leidžia jiems paleisti kūrimo metu, kad būtų galima stebėti pažangą ir užfiksuoti regresijos klaidas. Išvados ir rekomendacijos. Kita vertus, turime sistemų testus, kurie yra atsakingi už veikimo įvertinimą viso proceso metu, norint aptikti dėl to galinčias atsirasti klaidas, būtina sukurti strategiją su testais ir atskirti kodo kūrimą nuo sąsajos kūrimo, todėl geriausia įgyvendinti sistemos testus. Šių dviejų programinės įrangos testų įgyvendinimas turi būti atliekamas atliekant griežtus testus, atitinkančius tam tikrus standartus ir derinant su sistemos kūrimu susijusias suinteresuotąsias šalis. Sistemos testavimas ir priėmimas 44 Bibliografija 1. Isabelle Ramos Roman, José Javier Dolado Cosin. Kiekybiniai valdymo metodai programinės įrangos kūrime. Alonso Amo, Loicas Martinezas Normandas. Įvadas į programinės įrangos kūrimą. Sistemų testavimas ir priėmimo testavimas 45 8. - Kompiuterinių kalbų ir sistemų katedra. Struktūrinis sistemos analizė. Bakterijų identifikavimo mikrobiologijos laboratorijoje metodai.