Pieņemšanas testa definīcija. Dokumentācijas izstrāde, prototipu izgatavošana un testēšana. Standartu komplekts automatizētām sistēmām

Parasti šo testēšanu veic cita komanda, kas manuāli vai ar citu rīku atkārto daudz no tā, kas ir ietverts automātiskajā pieņemšanas pārbaudē. To var izdarīt tāpēc, ka pieņemšanas testus nevar viegli palaist dažādās vidēs vai arī izstrādes komanda nevar viegli saprast, ko veic testi, un izmantotie dati ir paslēpti kodā, tādējādi apgrūtinot to atrašanu vai mainīšanu. Pārbaudes nolūka paslēpšana kodā apgrūtina saprast, ko tests mēģina darīt.

Tas arī nozīmē, ka netehniskie komandas locekļi nevar viegli piedalīties testēšanā, un tehniskie cilvēki pavada vairāk laika automatizētam testa kodam. Ja testi ir jāpārveido, kas ir neizbēgami, jo tie nodala nolūku no ieviešanas līdzekļiem, varat koncentrēties uz testa ieviešanas pārstrukturēšanu, nevis uz to, kas testa veikšanai ir jādara.

Nolūka, ieviešanas un datu atdalīšana

Zemāk ir diagramma, kas ilustrē ideju par nolūka, ieviešanas un datu atdalīšanu. Ir iekļauta arī vide, jo ir svarīgi saprast, kādā vidē tiks palaisti testi un nepieciešamības gadījumā mainīt datus un palaist testu. Nodomu var izveidot netehniskie komandas locekļi valodā, kas ir neatkarīga no ieviešanas. Tas ir svarīgi, jo tas nozīmē, ka ieviešanu var pārveidot, nemainot testa nolūku. Ir arī otrādi; ir iespējams mainīt testa nolūku, neietekmējot ieviešanu, ja ir ieviešana, kas atbilst visiem nolūka rindkopas vārdiem.

Ja sliktākajā gadījumā nolemjat izmest visu ieviešanu un sākt no jauna, jūs joprojām varat saglabāt testa nolūku un tādējādi nepazaudēt vissvarīgāko automatizēto testu daļu, ko testi mēģina darīt. Dati ir arī jāsadala nodomos un implementācijās, to darot, testā datus var precizēt ar abstrakciju un pēc tam implementāciju noņemt. Piemēram, tests var norādīt, ka "Zelta klients", jo klients ir identificēts, nav testa daļa, bet ir daļa no datu slāņa.

Datu slāņa izveide un datu abstrakcija nav jaunas metodes; tos parasti izmanto lietojumprogrammas kodam, un tie būtu jāpiemēro automatizētiem testiem, jo ​​priekšrocības joprojām ir spēkā. Testa gadījumā datu slānis tiek izsaukts, lai izgūtu datus no datu avota atbilstošajam klienta tipam.

Pēc tam testa gadījums atkārto visus saraksta ierakstus un veic pārbaudi katram klienta ierakstam. Sistēmas testi atbilst vienam no programmatūras testēšanas līmeņiem, kas apvienoti ar dažādiem testiem, piemēram, atkopšanu, drošību, noturību, veiktspēju, savienojamību, skaļumu, spriegumu, datu pieejamību, lietošanas vienkāršību, darbību, Vide, uzglabāšana, konfigurēšana, uzstādīšana un dokumentācija. Katram no tiem ir atšķirīgs mērķis un kopīgs mērķis, kas parāda projekta sistemātisko redzējumu. Pieņemšanas testēšana ir vēl viens līmeņa līmenis, ko papildina programmatūras testēšanas līmeņi, šie testi ir ļoti būtiski, jo tie ļaus mums iegūt produktu, kas atbilst noteiktajiem standartiem un kas vienlaikus apmierina lietotāju prasības saskaņā ar prasības, ko viņi izvirzīja jau pašā sākumā. Tas liek sistēmai pārbaudīt vitāli svarīgo testēšanas procesu, jo produkta, kļūdu skaita un šo kļūdu nopietnības ziņā tas ir izstrādes posms, kas parasti ir pakļauts lielākajai daļai kļūdu. 1. attēls. Iteratīvo sistēmu pārbaude Sistēmas testi nav procesi sistēmas funkcionalitātes pārbaudei vai pilna programma, jo tas būtu lieki funkcionālās pārbaudes procesā. Sistēmas testiem ir īpašs mērķis: salīdzināt sistēmu vai programmu ar tās sākotnējiem mērķiem. Šim nolūkam tiek parādītas divas vērtības. Sistēmas testēšana neaprobežojas tikai ar sistēmām. Ja produkts ir programma, sistēmas testēšana ir mēģinājums parādīt, kā programma pilnībā neatbilst saviem mērķiem vai prasībām. Sistēmas testi pēc definīcijas nav iespējami, ja vien nav rakstisku prasību, kas ir izmērāmas produktam. Sistēmas testēšana ir izpētes fāze, kurā tā nodrošina, ka katrs komponents vai modulis mijiedarbojas ar citiem komponentiem vai moduļiem, kā paredzēts. Sistēmas testi ir vērsti uz sistēmas dziļu ieviešanu, pārbaudot informācijas sistēmas integrāciju visā pasaulē, pārbaudot, vai pareizi darbojas saskarnes starp dažādām apakšsistēmām, kas to veido, un ar citām informācijas sistēmām, ar kurām tā sazinās. Klasiskā sistēmas pārbaudes problēma ir "rādīšana ar pirkstu". Tas notiek, kad tiek atklāta kļūda un katra sistēmas elementa izstrādātājs vaino citus. Tā vietā, lai iekristu šajā absurdā, programmatūras inženierim vajadzētu paredzēt iespējamās problēmas ar interfeisu:  projektēšanas kļūdu apstrādes ceļš, kas pārbauda visu informāciju, kas nāk no citiem sistēmas elementiem. Sistēmas testēšana un testēšana 6  Izmantojiet virkni testu, kas simulē sliktus datus vai citus iespējamās kļūdas programmatūras saskarnē.  Pārbaužu rezultātus reģistrēt kā pierādījumu vainas gadījumā.  Piedalīties sistēmas testēšanas plānošanā un izstrādē, lai nodrošinātu, ka programmatūra ir pareizi pārbaudīta. Faktiski sistēmas tests aptver virkni dažādu testu, kuru galvenais mērķis ir padziļināti aprēķināt sistēmu skaitļošanas laikā. Lai gan katram testam ir atšķirīgs mērķis, tie visi strādā, lai pārliecinātos, ka visi sistēmas elementi ir pareizi integrēti un veic atbilstošās funkcijas. 2 Pārbaudes sistēmas apskats. Veicot testēšanu, ir jāuztur sistēmas, tas ir, integrēta pieeja programmatūras izstrādei. Lietojot šos jēdzienus programmatūras testā, tiek iegūts principu kopums, kas kalpos par testa pamatu: jums ir jāpārliecinās, ka precīzi zināt testējamās programmatūras mērķus, kā arī savus panākumu rādītājus. Šie elementi ir atrodami dokumentos, kas iegūti prasību apkopošanas posmā, kā arī programmatūras specifikācijās. Šī informācija būs nepieciešama, lai sagatavotu testa plānu, un tā būs pamats testa piemēra izstrādes uzsākšanai. Jādefinē apstiprinātās sistēmas ieejas un izejas. Šis aspekts ir nepieciešams testpiemēru sagatavošanā, kā arī testēšanas procedūru izveidē, īpaši uz testa gadījumu orientētu, kas parāda mērķu izpildi. Apsveriet galveno sistēmu, kurā darbojas testējamā programmatūra. Parasti tā ir organizatoriskā vide, kas sastāv no aparatūras, programmatūras un cilvēkiem. Visiem šiem elementiem ir liela ietekme uz sistēmu un īpaši tie palīdz sagatavot testa gadījumus nevēlamām situācijām, kas saistītas ar nepietiekamiem datiem, datu trūkumu. nepieciešamie elementi un izņēmumu rašanās. 3 Sistēmas testēšanas pārskats Sistēmas testēšanas process sastāv no divām fāzēm, kas laika gaitā var būt ļoti atšķirīgas: testa sagatavošana un testa piemērošana. Pirmais ir cieši saistīts ar prasībām, tāpēc tas notiek projekta sākumā, bet otrajam ir nepieciešama pilna sistēma vai vismaz viena integrācija, jo tiek uzskatīts, ka daļējais produkts nav izlaists, lai varētu piemērot testus, tāpēc tas notiek progresīvās projekta stadijās. projektu. Precīza situācija ar šīm daļām ir atkarīga no izvēlētā modeļa. dzīves cikls. Lai veiktu otro un trešo darbību, nepieciešams prasību dokuments. Pirmajā testēšanas fāzē tiek sniegta atgriezeniskā saite, lai analizētu prasības, identificētu nepilnības, neskaidrības un citas problēmas. Tas arī sniedz vērtīgus padomus par sistēmas izstrādi un ieviešanu, ja jūs to tikai izstrādājat. Testa lietojumprogrammas fāzei ir nepieciešams testa plāns un izpildāmā sistēmas versija. Šajā gadījumā tiks piemēroti sagatavotie testpiemēri, rezultāti tiks analizēti un konstatēti visi defekti. Šis otrais solis sniedz atgriezenisko saiti par ieviešanu un dizainu, parādot iespējamos defektus, kas ir jānovērš. Tā arī sniedz informāciju, kas noderēs sistēmas izlaišanā, pārņemšanā, uzticamības novērtēšanā un uzturēšanā. 1. attēlā parādīts sistēmas testēšanas process un tā saistība ar citiem procesiem. Otrais punkts ir svarīgs, jo dažreiz sistēmas pārbaude tiek sajaukta ar interfeisa pārbaudi. Pirmais pārbauda visu daļu mijiedarbību, bet otrais analizē saskarnes elementus un, iespējams, saistīto notikumu apstrādi. Tomēr rīkus, kas palīdz pārbaudīt saskarni, var izmantot sistēmas testu veikšanai. Rodas vairāki jautājumi: ar cik gadījumiem pietiks? Kā ģenerēt pēc iespējas mazāk? Kādas vērtības ir piemērotas? Sistēmas testēšana un testēšana 9 1 Testēšanas plāns Testēšanas plāns ir ļoti svarīgs dokuments programmatūras testēšanas laikā. Tajā ir izskaidroti testēšanas mērķi un pieejas, darba plāns, darbības procedūras, nepieciešamie instrumenti un pienākumi. Sistēmas testēšana un testēšana 10 Prasību dokumentā jāiekļauj programmatūras veicamo funkciju saraksts, aprakstot un nosakot prioritātes; tajā jāiekļauj arī nefunkcionālas prasības, kas var ietvert organizatoriskus, darbības un citus aspektus. Labi sagatavotam prasību dokumentam ir jānodrošina veids, kā katrai prasībai pārbaudīt, vai tā ir izpildīta. Funkciju gadījumā tas būtu apraksts, bet nefunkcionālu prasību gadījumā tas varētu būt ļoti precīzas specifikācijas, piemēram, reakcijas laiks. Pagaidām mēs koncentrēsimies uz funkcionālajām prasībām, pārējo atstājot vēlākai sadaļai. Sistēmas testi ir svarīgi šādu faktoru dēļ:  Tā ir sistēma, kas tiek testēta kopumā sistēmas izstrādes dzīves cikla ietvaros.  Tiek pārbaudīta sistēmas atbilstība tās funkcionālajai un tehniskajām prasībām .  Sistēma tiek testēta vidē, kas ir pēc iespējas tuvāka ražošanas videi.  Sistēmas testi ļauj pārbaudīt, apstiprināt un apstiprināt gan biznesa prasības, gan lietojumprogrammu arhitektūru. 6Sistēmas testu veids Funkcionālie testi  Integrācijas tests. - kurā testa iekārtai ir piekļuve sistēmas pirmkodam. Kad problēma tiek atklāta, integrācijas komanda mēģina atrast problēmas avotu un noteikt komponentus, kas ir jāatkļūdo. Integrācijas pārbaude galvenokārt ir saistīta ar sistēmas defektu atrašanu.  piegādes apliecinājums. Šeit ir sistēmas versija, kuru var piegādāt lietotājam. Šeit testa komanda ir norūpējusies, lai pārbaudītu, vai sistēma atbilst tās prasībām un garantē sistēmas uzticamību. Piegādes testi parasti ir melnās kastes testēšana, kurā testa aprīkojums vienkārši pārbauda, ​​vai sistēma darbojas pareizi. Komponenti, kurus var integrēt, var būt komerciāli komponenti, atkārtoti lietojami komponenti, kas pielāgoti konkrētai sistēmai, vai jaunizstrādāti komponenti. Daudzām lielām sistēmām, iespējams, tiks izmantoti visi trīs komponentu veidi. Integrācijas tests pārbauda, ​​vai šie komponenti patiešām darbojas kopā, tiek pareizi izsaukti un caur to saskarnēm precīzā laikā tiek nodoti pareizie dati. Sistēmas integrācija ietver komponentu grupu identificēšanu, kas nodrošina kādu sistēmas funkcionalitāti, un to integrēšanu, pievienojot kodus, lai tie darbotos kopā. Dažreiz vispirms tiek izstrādāts visas sistēmas skelets un pievienotas sastāvdaļas. To sauc par pēcintegrāciju. Tā ir augšupejoša integrācija. Praksē daudzām sistēmām integrācijas stratēģija ir abu kombinācija, pievienojot papildu infrastruktūras komponentus un funkcionālos komponentus. Abām integrācijas pieejām ir nepieciešams papildu kods, lai modelētu citus komponentus un nodrošinātu sistēmas palaišanu. Galvenās grūtības, kas radušās integrācijas testu laikā, ir kļūdu atrašanās vieta. Sistēmas komponentiem ir sarežģīta mijiedarbība, un, atklājot anomālu izvadi, var būt grūti noteikt, kur radusies kļūda. Lai atvieglotu kļūdu izolēšanu, vienmēr izmantojiet pakāpenisku pieeju sistēmas integrācijai un testēšanai. Šī procesa galvenais mērķis ir palielināt piegādātāja pārliecību, ka sistēma atbilst viņa prasībām. Ja tā, to var piegādāt kā produktu vai piegādāt klientam. Lai pierādītu, ka sistēma atbilst tās prasībām, ir jāpierāda, ka tā nodrošina norādīto funkcionalitāti, veiktspēju un uzticamību un ka tā nedarbojas normālā lietošanā. Piegādes testi parasti ir melnās kastes testēšanas process, kurā testi tiek iegūti no sistēmas specifikācijas. Sistēma tiek uzskatīta par melno kasti, kuras darbība ir jānosaka, tikai pārbaudot tās attiecīgās ievades un izvades. Cits nosaukums tam ir funkcionālā testēšana, jo testētāju interesē tikai programmatūras funkcionalitāte, nevis programmatūras ieviešana. Nākamajā attēlā mēs redzēsim sistēmas modeļa ilustrāciju, ko tas pieļauj melnajā kastē. Testētājs uzrāda komponentam vai sistēmai ievades datus un ņem vērā ievades datus. Dažos gadījumos sistēmai jābūt izturīgai pret defektiem; tas ir, apstrādes kļūmes nedrīkst izraisīt visas sistēmas kļūmes. Testēšanas sistēmas un pieņemšanas testi 14 Sistēmas kļūme ir jānovērš noteiktā laika periodā, pretējā gadījumā tā radīs nopietnus ekonomiskus zaudējumus. Atkopšanas tests ir sistēmas pārbaude, kas vairākos veidos izraisa programmatūras kļūmi un pārbauda, ​​vai atkopšana tiek veikta pareizi. Ja atkopšana notiek automātiski, jums jāpārbauda, ​​vai atkārtota inicializācija, sistēmas dublēšanas mehānismi, datu atkopšana un atsāknēšana ir pareiza. Ja atveseļošanai nepieciešama cilvēka iejaukšanās, jānosaka vidējais atveseļošanās laiks, lai noteiktu, vai tas ir pieļaujamās robežās. Mērķis ir noteikt galapunktus, kuros sistēma sāk darboties zem noteiktajām prasībām. To nevajadzētu jaukt ar tilpuma testu; augstspriegums ir maksimālais datu vai aktivitātes apjoms uz vienu īsu laiku. Analogija būtu mašīnrakstītāja novērtēšana. Apjoma pārbaude tiks noteikta, ja mašīnrakstītājs saskaras ar liela ziņojuma melnrakstu; stresa tests noteiks, vai mašīnrakstītājs var rakstīt ar ātrumu 50 vārdi minūtē. Pārkāpums ietver plašu darbību klāstu:  Hakeris, kurš mēģina pieteikties vienā spēlē. Drošības tests pārbauda, ​​vai sistēmā iebūvētie drošības mehānismi to patiešām pasargā no neatbilstošas ​​ielaušanās. "Sistēmas ir jāpārbauda, ​​lai sistēmas drošība būtu imūna pret frontāliem uzbrukumiem, kā arī tiem, kas veic sānus vai aizmuguri." Drošības pārbaudes laikā ikviens, kurš to pielieto, spēlē tā cilvēka lomu, kurš vēlas pieteikties. Tas viss ir tā vērts! Jums vajadzētu mēģināt iegūt jebkādas paroles ārējiem līdzekļiem; var uzbrukt sistēmai, izmantojot īpašu programmatūru, kas paredzēta jebkuras aizsargātas arhitektūras apiešanai; viņš var piesātināt sistēmu, tādējādi liedzot pakalpojumu citiem; var izraisīt apzinātas kļūdas sistēmā, lai mēģinātu piekļūt atkopšanas laikā: jūs varat skatīt datus bez aizsardzības, ar domu meklēt sistēmas paroli. Ja tiek piešķirts pietiekami daudz laika un resursu, sistēma galu galā to darīs labs tests drošībai. Sistēmas izstrādātāja loma ir tāda, ka pārtraukuma izmaksas ir lielākas nekā saņemtās informācijas izmaksas. Tomēr cilvēcisko faktoru analīze joprojām ir ļoti subjektīva problēma. Testa gadījumi ir paredzēti, lai parādītu, ka šie krātuves mērķi nav atrasti. Bieži vien iespējamo konfigurāciju skaits ir pārāk liels, lai pārbaudītu katru, taču, ja iespējams, jums vajadzētu pārbaudīt programmu ar katra veida aparatūras ierīci un ar minimālo un maksimālo konfigurāciju. Ja pašu programmu var konfigurēt, lai izlaistu komponentus, vai ja tā var darboties vairākos datoros, katra konfigurācija ir jāpārbauda. Instalēšanas procedūru pārbaude ir svarīga sistēmas testēšanas procesa sastāvdaļa. Tas jo īpaši attiecas uz sistēmu automātiska uzstādīšana iekļauts programmatūras pakotnē. Nepareizi palaists instalēšanas programma var neļaut lietotājam gūt veiksmīgu pieredzi ar sistēmu. Lietotāja pirmā pieredze ir tad, kad viņš vai viņa instalē lietojumprogrammu. Viens no veidiem, kā to panākt, ir izmantot dokumentāciju, lai definētu iepriekšējo sistēmas testa gadījumu skatu. Tas ir, ja vēlaties izstrādāt pārslodzes gadījumu, dokumentācija ir jāizmanto kā ceļvedis faktiskā testa gadījuma rakstīšanai. Turklāt lietotāja dokumentācija ir rūpīgi jāpārbauda, ​​lai nodrošinātu precizitāti un skaidrību. Jebkurš no dokumentācijā redzamajiem piemēriem ir jāpārbauda un jāpievieno uzdevumu sarakstam un jāiekļauj programmā. Sistēmas testēšana un testēšana 17 darbības viedokļa, pēc sistēmas pieņemšanas faktiskajā vidē un pamatojoties uz atbilstību noteiktajām nefunkcionālajām prasībām. Pretestības pārbaude ir paredzēta, lai novērstu programmas neparastās situācijās. Būtībā persona, kas veic pretestības pārbaudi, jautās. Cik tālu jūs veicat, pirms tas neizdodas? Pretestības tests veic sistēmu tā, ka tai ir nepieciešams neparasts daudzums, biežums vai resursu daudzums. Piemēram:  ir izstrādāti speciāli testi, kas ģenerē 10 pārtraukumus sekundē, kad vidējais kauss ir viens vai divi.  Datu ievades biežums tiek palielināts par tādu summu, kas ļaus reaģēt uz ievades funkcijām.  Palaist testa gadījumus, kuriem nepieciešama maksimāla atmiņa vai citi resursi.  Testa gadījumi ir paredzēti, lai novērstu atmiņas pārvaldības problēmas. Tiek izveidoti testa gadījumi, kas izraisa pārmērīgu diska meklēšanu. Attēls ir pretestības testa piemērs. Veiktspējas tests tiek piemērots visos testēšanas procesa posmos. Pat vienības līmenī. Atsevišķa moduļa veiktspēja ir jānovērtē testēšanas laikā. Tomēr tikai pēc tam, kad visi sistēmas elementi ir pilnībā integrēti, var sasniegt patiesu sistēmas veiktspēju. Veiktspējas testi bieži ietver pretestības pārbaudi, un bieži vien ir nepieciešamas programmatūras un aparatūras instrukcijas. Tas ir, bieži vien ir nepieciešams precīzi izmērīt resursu izmantošanu. Izmantojot ārējos rīkus, varat regulāri pārraudzīt izpildes intervālus, reģistrētos notikumus un aparatūras paraugu statusu. Šīs pārbaudes tiek veiktas, lai klients apstiprinātu, ka sistēma viņam ir derīga. Šo testu detalizēta plānošana jāveic agrīnā izstrādes fāzē, lai rezultātus izmantotu kā norādi uz to derīgumu: ja dokumentētie testi tiek veikti tā, lai klients būtu apmierināts, produkts tiek uzskatīts par pareizu un tāpēc adekvātu, lai to izmantotu. ražošanu. 6 Pieņemšanas testi2 būtībā ir visas sistēmas funkcionālie testi, un to mērķis ir pārbaudīt, vai noteiktās prasības . Tās izpilde klientam nav obligāta, un, ja tie nav skaidri norādīti, tie tiek iekļauti sistēmas testos. Tas ir, par pieņemšanas testiem bieži ir atbildīgs lietotājs vai klients, lai gan ikviens, kas ir iesaistīts uzņēmējdarbībā, var tos veikt. Pieņemšanas testēšanai ir nepieciešama testa vide, kas atspoguļo ražošanas vidi. Šī fāze vai līmenis kā sākumpunkts nosaka produkta pieņemšanas bāzes līniju, kas jau ir izveidota sertifikācijas vidē. Sistēmas pārbaude un akceptēšana 19 Attēls - Pieņemšanas kontrole. 1 Pašreizējās situācijas pārbaude pieņemšanas testos. Pārbaužu ietvaros mums ir jāpārbauda programmatūra, viena no svarīgākajām ir akcepttestēšana. Tie ir testi, kurus izstrādā pati izstrādes komanda, pamatojoties uz analīzes fāzē noteiktajām funkcionālajām prasībām, lai aptvertu visu spektru un ko veiktu gala lietotājs, taču ne visiem, izņemot dažus lietotājus, ir nozīmīgs rezultāts, kas dod derīgums un atbilstība precei, kas viņiem tiek piegādāta, pamatojoties uz sākotnēji saskaņoto. Atkarībā no pārbaudāmās sistēmas sarežģītības, neatkarīgi no tā, vai tā ir sadalīta moduļos utt. šo testu izpilde tiek veikta atšķirīgi. Ja lietojumprogrammu sadalītu moduļos, tās tiktu uzskatītas par apakšsistēmām un būtu pietiekami sarežģītas, lai tās apstrādātu atšķirīgi, būtu jāveic dažādas pieņemšanas pārbaudes sesijas. 2. Pieņemšanas pārbaudes mērķis Pieņemšanas testēšanas mērķis ir iegūt gala patērētāja akceptu pirms produkta piegādes, lai to sāktu ražošanā. Kad organizācija ir veikusi sistēmas testus un novērsusi lielāko daļu savu defektu, sistēma tiks piegādāta lietotājam vai klientam apstiprināšanai. Pieņemšanas pārbaudes mērķis ir pārbaudīt, vai sistēma atbilst sagaidāmajai veiktspējai, un ļauj šīs sistēmas lietotājam noteikt tās pieņemšanu tās funkcionalitātes un veiktspējas ziņā. Pieņemšanas testus nosaka sistēmas lietotājs un sagatavo izstrādes komanda, lai gan galīgā izpilde un apstiprināšana ir lietotāja ziņā. Sistēmas validācija tiek panākta, palaižot melnās kastes testus, kas parāda atbilstību un ir iekļauti testēšanas plānā, kas nosaka veicamās validācijas un ar tām saistītos testa gadījumus. Šis plāns ir izstrādāts, lai nodrošinātu visu lietotāja norādīto funkcionālo prasību izpildi, kā arī nefunkcionālās prasības, kas saistītas ar veiktspēju, sistēmas piekļuves, datu un procesu un dažādu sistēmas resursu drošību, 3 Pieņemšanas testēšanas ģenerēšana. Lietotājam sistēma ir jāpieņem. Šī iemesla dēļ, pamatojoties uz sistēmas strukturētajām specifikācijām, analītiķis izveido testa gadījumu kopu, kam ir jāiziet apmierinoši. Tā kā pieņemšanas testus var izstrādāt paralēli projektēšanas un prakses darbībām, ir normāli, ka šīs darbības sāk analītiķis, tiklīdz ir pabeigta strukturētās analīzes darbība. 4 Pieņemšanas testēšanas stratēģijas Ja sistēma būtu paredzēta masu tirgum, tad to testēt atsevišķiem lietotājiem vai klientiem nebūtu praktiski, atsevišķos gadījumos tas nebūtu iespējams. Šādos gadījumos pirms produkta laišanas pārdošanā ir nepieciešama atgriezeniskā saite. Bieži vien šādām sistēmām ir divas pieņemšanas pārbaudes stadijas. Alfa un beta testēšana Kad klientam tiek veidota pielāgota programmatūra, tiek veikta virkne pieņemšanas testu, lai klients varētu pārbaudīt visas prasības. Izstrādāšanas vietā veic klients. Programmatūra tiek dabiski izmantota kopā ar izstrādātāju kā lietotāja novērotāju, kā arī reģistrācijas kļūdām un lietošanas problēmām. Alfa testi tiek veikti kontrolētā vidē. Jūs strādājat kontrolētā vidē, un klientam vienmēr ir eksperts, kas palīdzēs izmantot sistēmu. Izstrādātājs seko līdzi atrastajām kļūdām un lietošanas problēmām. Β-beta testi tiek veikti pēc α-alfa testa un tiek izstrādāti klienta vidē. Šajā gadījumā klients tiek atstāts viens ar produktu un mēģina atrast kļūdas, kas informē izstrādātāju. Tos veic programmatūras galalietotāji klienta darbstacijās. Atšķirībā no alfa testa, izstrādātājs parasti nav klāt. Tādējādi beta tests ir programmatūras tiešraides lietojumprogramma vidē, kuru izstrādātājs nevar kontrolēt. Klients reģistrē visas problēmas, kas rodas beta testēšanas laikā, un regulāri ziņo izstrādātājiem. 5 Pieņemšanas testa ievadi, izvadi, uzdevumi un lomas. Iestāšanās prasību specifikācija. Uzdevumi Sagatavojiet testa vidi. Šāda veida testēšanai mēs iesakām izveidot īpašu testa vidi. Uzstādīšana testa vidē. Sistēmas testēšana un testēšana 22 Nosakiet veicamos testus. Tiks noteiktas iespējamās atkarības, kas pastāv starp testiem, un, pamatojoties uz šīm atkarībām, tiks noteikta secība vai secība, kādā tiks izpildīti testi. Rezultātu saņemšana un ierakstīšana. Izlabotas kļūdas un bugs. Atkārtojiet uzdevumu, līdz esat nokārtojis visus testus. Pieņemšanas pārbaudes protokola sagatavošana. Pārskats par visu iesniegto testu pareizu izpildi un rezultātiem. Ražošanas bāzes izveide. Oficiāla darbību slēgšana. Testa rezultāti. Akceptēts produkta pieņemšanas ziņojums. Projektu menedžeris. Uzsvars uz pieņemšanas testēšanu ir saistīts ar mēģinājumu nostiprināt uzskatu, ka šajā posmā integrētais lietotājs agrīnā stadijā palīdzētu uzlabot šo procesu testa plānošanas un izstrādes fāzē, ar sekojošiem uzlabojumiem daudzos kvantitatīvos un vēlamos aspektos. , piemēram: Integrētās programmatūras drošības kvalitātes uzlabošana. Izmaksu samazināšana. Paaugstināta projekta rezultātu ticamība. Lietojot programmatūru ar mazāku kļūdu skaitu, palielinās klientu apmierinātība. Tas uzlabo izstrādes procesa efektivitāti. 7 Pieņemšanas pārbaudes kritēriji. Programmatūras pieņemšana tiek panākta, veicot virkni testu, kas parāda, ka tā atbilst prasībām. Pārbaužu plānā ir aprakstīts piemērojamā testa veids un testa procedūra definē konkrētus testa gadījumus, gan plāns, gan procedūra ir izstrādāti tā, lai nodrošinātu, ka tie atbilst visām funkcionālajām prasībām, ka tiek sasniegti visi uzvedības raksturlielumi, izpildītas visas veiktspējas prasības, dokumentācija ir pareizs un ievērotas visas lietošanas ērtuma un citas prasības noteiktās prasības. 8 Pieņemšanas pārbaužu rīki. Tas ļauj klientiem, testētājiem un programmētājiem uzzināt, kas viņu programmatūrai ir paredzēts, un automātiski salīdzināt to, ko tā faktiski dara. Ļauj rakstīt testus, kas ir viegli lasāmi un viegli uzturami. Šī darbība ir pazīstama kā galīgā pārbaude vai pieņemšanas pārbaude. Tas prasa akcepttesta datu ievadi un šīs darbības laikā izveidoto integrēto sistēmu. Pārbaudi veiks kāds lietotāja dalībnieks vai nodaļa vai pat neatkarīga kvalitātes kontroles nodaļa. Ir svarīgi atzīmēt, ka ir svarīgi veikt kvalitātes kontroles darbības katrā no iepriekšējām analītiskajām, projektēšanas un ieviešanas darbībām, lai nodrošinātu, ka tās ir veiktas atbilstošā kvalitātes līmenī. Tas nodrošina, ka analītiķis izstrādā kvalitātes specifikācijas, dizaineris izstrādā kvalitatīvus dizainus un programmētājs izstrādā kvalitatīvas kodēšanas programmas. Datorzinātnē realizācija ir tehniska specifikācija vai algoritmi, piemēram, programma, programmatūras komponents vai cita datorsistēma. Daudzas ieviešanas tiek nodrošinātas saskaņā ar specifikāciju vai standartu. Mēs apkopojam autoru iepriekšējo darbu, lai iegūtu testa mērķus, kas ir sākumpunkts automatizēto testu izstrādei. Sistēmas testēšanas kontekstā no lietošanas gadījumiem testēšanas mērķi var izteikt kā lietošanas gadījumu. Šis scenārijs sastāvēs no darbību secības bez iespējamas alternatīvas un testa vērtību kopas, un priekšnosacījumi un pēckonferences, kas saistītas ar šo scenāriju. Lai ģenerētu testa scenārijus, vispirms no galvenās secības un lietošanas gadījuma kļūdu un alternatīvajām secībām tiek veidota darbības diagramma. Aktivitāšu diagrammā sistēmas veiktās darbības un dalībnieku veiktās darbības ir stereotipizētas. Pēc tam tiek veikta ceļa analīze, un katrs darbības diagrammas ceļš būs lietošanas gadījuma scenārijs un tādējādi potenciālais pārbaudes mērķis. 2 Sistēmas testu ieviešana. Sistēmas testēšanas arhitektūra. Sistēmas testu izpildes un automātiskās apstiprināšanas arhitektūra ir parādīta 7. attēlā. Šī arhitektūra ir līdzīga arhitektūrai, kas nepieciešama, lai automatizētu cita veida testus, piemēram, vienības testus. Galvenā atšķirība ir tā, ka vienības testā pats tests izsauc izpildāmo kodu, turpretim testa sistēmas funkcionālajai pārbaudei un testa pieņemšanai 27 ir nepieciešams starpnieks, kas zina, kā manipulēt ar tās ārējo saskarni. Testpiemēru ieviešana. Tests-tests ir testēšanas mērķa īstenošana. Pārbaudes gadījuma vispārīgā darbība ir norādīta tabulā Vispārīgā testa gadījuma uzvedība. Katrs lietošanas gadījums tiks saistīts ar testa komplektu. Šajā komplektā būs iekļauti testi visiem minētā lietošanas gadījuma scenārijiem. Kā redzams no testa mērķiem, katrs solis ir jāprecizē neatkarīgi no tā, vai to veic dalībnieks vai pārbaudāmā sistēma. Šī informācija ir ļoti svarīga, kodējot pakotnes pārbaudes metodes. Visas darbības, ko veic aktieris, pārveido testa koda kodu mijiedarbībā starp testa gadījumu un sistēmu. Sistēmas testēšana un akcepttestēšana 29 Lai noteiktu nepieciešamās testa vērtības, tiks izmantota operatīvā un kategorijas mainīgā metodoloģija. Trīs ir identificēti dažādi veidi darbības mainīgie. Katrs veids testa gadījumos tiks ieviests atšķirīgi. Pirmais veids sastāv no tiem darbības mainīgajiem, kas norāda uz informācijas nodošanu sistēmai, ko veic ārēja entītija. Katram šāda veida mainīgajam tiks definēta jauna klase, kuras objekti saturēs dažādas šī mainīgā testa vērtības. Šāda veida darba mainīgā piemērs ir parādīts gadījuma izpētē. Otrais veids sastāv no tiem darbības mainīgajiem, kas norāda izvēli starp vairākām iespējām, kas pieejamas ārējam dalībniekam. Tā vietā šāda izvēle tiks īstenota tieši kā daļa no koda, kas īsteno mijiedarbību starp dalībnieku un sistēmu. Trešais veids sastāv no tiem darbības mainīgajiem lielumiem, kas norāda sistēmas stāvokli. Lai ieviestu testa gadījuma iestatīšanas metodi, ierakstiet nepieciešamo kodu, lai pareizi iestatītu sistēmas stāvokļus aprakstošo darbības mainīgo vērtību vai pārbaudītu, vai vērtības atbilst. Tāpat pārtraukuma metodei šīs vērtības ir jāatjauno to sākotnējā stāvoklī. Turklāt izsekošanas metodei, ja nepieciešams, ir jāizslēdz informācija, ko testpiemērs ievadījis sistēmā testpiemēra izpildes laikā. Gadījuma izpētē ir parādīti vairāki šāda veida darbības mainīgo piemēri. Šajā gadījumā vispirms ir jāpiemēro redzētais, lai iegūtu testa mērķu kopu no lietošanas gadījuma. Pēc tam nosaka izmantotās testa siksnas īpašības. Visbeidzot, mēs pielietojam to, ko redzējām iepriekšējās sadaļas lai ieviestu testa gadījumu no testa mērķa. Pārbaudāmā sistēma artefakti tika identificēti angļu valoda, ciktāl spāņu valoda neatbalsta izmantotie rīki. Lietošanas gadījums 2. tabulā apraksta jaunas saites ieviešanu sistēmā. Kā papildinājums tiek parādīta arī prasība saglabāt informāciju, kas apraksta informāciju, ko apstrādā katra saite. No lietošanas gadījuma un automātiski ģenerēta scenāriju kopa, kas būs minētā lietošanas gadījuma pārbaudes mērķis. Ņemot vērā, ka lietošanas gadījumam ir neierobežotas cilpas ar bezgalīgu skaitu iespējamo atkārtojumu, ceļu iegūšanai izvēlētais pārklājuma kritērijs ir kritērijs 01, kas pārbauda un testē 30. sistēmas testus, sastāv no visu iespējamo ceļu iegūšanas, lai neatkārtotu nevienu vai vienu reizi. katra no cilpām. Visi skripti, kas iegūti, izmantojot šo kritēriju, un tulkoti spāņu valodā, ir norādīti tabulā. Šim gadījuma pētījumam esam izvēlējušies 09. scenāriju, kura īstenošanai ir sniegta informācija 5. tabulā. Testēšana un testēšana testēšanā 31 Tabulas informācija Prasība atsaucēm. Varat arī izmantot kategoriju sadalīšanas metodi. Sadaļas katram no šiem mainīgajiem lielumiem ir norādītas tabulā. Sistēmas testēšana un testēšana 32 Tabulas mainīgie, kas definēti lietošanas gadījumam. Testēšana un testēšana testēšanā 33 Identificēto mainīgo kategoriju tabula. Kā aprakstīts 7. attēlā, instalācijas tests ir izstrādāts, lai modelētu lietotāja uzvedību un piedāvātu paziņojumu kopu, lai novērtētu rezultātu. Šis tulkojums pašlaik tiek veikts manuāli un ir parādīts tabulā. Raiduztvērēja testēšana un testēšana 35 Attēls Testa gadījuma īstenošana. Galvenā scenārija lietotāja veikto darbību tulkošana izpildāmā kodā. Tas ir, lai pārliecinātos, ka kategorijas pastāv un ka, atjaunojot kategorijas vai ievietojot jaunu saiti, nav apstākļu, kas izraisa kļūdu. Pārtraukuma metodes ieviešana bija sākotnējā sistēmā saglabāto saišu kopas atjaunošana. 2 Pieņemšanas testu īstenošana. Pieņemšanas testi darbojas tikai ar klientu atbalstu vai vismaz starpniekserveri, lai klients noteiktu kritērijus. Bez draivera pieņemšanas kritērijiem kļūst grūti pārbaudīt, vai veidojat pareizo programmatūru. Klientam kopā ar visiem izstrādes komandas locekļiem ir jāsanāk kopā, lai definētu sistēmu, izmantojot virkni "skriptu", kas apraksta, kas sistēmai jādara un kā tas jādara. Izveidojot testus ar skaidrām prasībām un apstiprināšanas kritērijiem, programmatūra, visticamāk, attaisnos klientu vēlmes. Tomēr tas nozīmē, ka kāds manuāli pārbauda, ​​vai prasības ir izpildītas un vai lietojumprogramma darbojas, kā paredzēts. Šeit tiek izmantotas automatizētas pieņemšanas pārbaudes, nevis prasības mantotā dokumentā, prasības tiek definētas kā piemēri un scenāriji, aizsargātas avota kontrolē ar izvietošanas artefaktiem, un tos var palaist jebkurā laikā, lai pārbaudītu, vai tie atbilst prasībām un darbojas pareizi. Varat izmantot to pašu pieeju testu rakstīšanai, taču tā vietā, lai rakstītu tos testa gadījumu pārvaldības programmatūrā vai izklājlapā, ierakstiet tos tieši kodā. Sistēmas testēšana un testēšana 37 1 Automātiskā pieņemšanas pārbaude. Tāpēc pirmais solis jebkuras jaunas funkcionalitātes ieviešanā ir aprakstīt savas cerības ar testu. Citi to nedara, un laika gaitā viņiem ir grūtības ar procesa kontroli, jo īpaši tāpēc, ka pieaug pierādījumi un testēšanas elastība sāk pasliktināties. Uz pārbaudēm balstīta pieeja ir balstīta uz to, kuri testi jāvada programmatūras produkta izstrādē. Rūpnieciskajos programmatūras produktos, kad tiek izmantotas prasību inženierijas metodes, tos galvenokārt atbalsta dabiskā valoda, kas rada labi zināmo neskaidrību neērtības. Tomēr apstiprināšanas nepieciešamība var atsvērt priekšrocības, ko var piedāvāt formālāka un stingrāka prasību specifikācija. Klientam ir jāspēj izlasīt un saprast prasības, lai varētu tām piekrist. Populārākās prasību noteikšanas metodes ir norādītas sadaļā Lietošanas gadījumi un lietotāju stāsti. Prasību definēšana ir atslēga klienta piesaistīšanai. Prasības - sasnieguma mērķis, tas ir, ko klients sagaida no programmatūras produkta. Sistēmas testēšana un testēšana 38 lomas, kas saistītas ar prasību specifikāciju un validācijas un pieņemšanas testēšanu. Prasību jēdziens kļūst par pieņemšanas pārbaužu konteineru, un tie ir tie, kas ieņem galveno vietu kā katras prasības specifikācija. Apsveriet prasību "Izņemt naudu" saistībā ar bankomātu. Tipiska aprakstošā specifikācija varētu būt šāda: klientam ir jābūt iespējai izņemt skaidru naudu no kasiera noteiktās summās. Vienmēr saņemiet čeku, ja kasierim nav palicis papīrs. Ja runa ir par vēlamo klientu, varat to izņemt vairāk naudas nekā jums ir jūsu kontā, taču jābrīdina, ka no jums tiks iekasēta procentuālā summa. Klientam vajadzētu būt iespējai jebkurā laikā atcelt atteikumu pirms izņemšanas apstiprināšanas. Summas ir jāspēj apkalpot ar kontiem, kas tobrīd ir kasierim, un citas summas nedrīkst pieņemt. Attēls — specifikāciju alternatīvas 10. attēlā parādītas dažas specifikācijas alternatīvas šai prasībai. Ikonas atspoguļo katras specifikācijas ērtības. Var būt interesanti izstrādāt secības diagrammu, lai definētu katru prasības izpildes scenāriju, taču kopumā tas nav piemērots, jo liels skaitsģenerētās diagrammas. Ir interesantāk identificēt scenārijus, nevis ilustrēt katru no tiem diagrammā. Stāstījuma apraksts nav vienreizējs, vismaz īsa definīcija prasībām, kas koncentrējas uz iesaistīto jēdzienu definēšanu. Tomēr lietošanas modelis nav piemērots programmatūras produkta detalizētas prasību struktūras ilustrēšanai ilgstošas ​​uzturēšanas vidē, jo vidējam programmatūras produktam var būt tūkstošiem prasību. Ir vajadzīgi piemērotāki mehānismi, lai vizualizētu un pārvaldītu daudzas prasības. Veidnes ir viena no visbiežāk izmantotajām alternatīvām lietošanas gadījumiem. Veidnes ir elegantas un nodrošina specifikācijas kārtības sajūtu. Tomēr tie parasti ir neproduktīvi, jo tie parasti nodrošina vienotu detaļu apstrādes līmeni visām prasībām. Šajos ļoti vienkāršajos gadījumos tie ietver lietas, kas ir acīmredzamas vai nebūtiskas, lai aptvertu visas veidnes sadaļas. Ja prasībā ir iekļauti vairāki skripti, mēģinājums sintezēt visus veidnē esošos skriptus parasti rada neskaidras specifikācijas. Tādā veidā prasības valstij darbojas kā konteineri. Atkarībā no prasībām var būt noderīgi citi papildu specifikāciju veidi. Piemēram, darbības diagramma, ja darbībai, kas saistīta ar prasību, ir algoritmisks simbols, vai stāvokļa diagramma, ja darbība ietver darbību iespējošanu vai atspējošanu saskaņā ar sistēmas apgalvojumiem un sistēmas pieņemšanas testiem. Būtisks priekšnoteikums ir pragmatisms attiecībā uz specifikāciju, kas neizslēdz specifikācijas alternatīvu koplietošanu, bet primārajam kritērijam jābūt vēlmei būt rentabla un dot ieguldījumu šīs specifikācijas uzturēšanā. No otras puses, attiecībā uz centieniem, lai apkope, jo īpaši konsekvences ziņā, ir svarīgi neizmantot pārmērīgu specifikāciju dublēšanos vai dublēšanos dažādi līdzekļi pārstāvniecība. Virzīts grafiks ir atbilstošs attēlojums līmeņa uzlabošanai. Šis grafiks ļauj vizualizēt dekompozīcijas attiecības un atkarības starp prasībām. Tādējādi katrs mezgls ir funkcionāla vai nefunkcionāla prasība. Loki starp mezgliem veido attiecības starp vecākiem un bērniem jeb "mezgli, kas ietekmē mezglus" atkarības attiecības. Tādējādi iepriekš minētajā piemērā prasība "Izņemt naudu" var būt prasību struktūras mezgls. Atgriezt ar klienta ievadīto daudzumu. Biļetes nav pieejamas. Nav papīra, ko saņemt. Saziņas laiks ar centrālo sistēmu ir pārsniegts. Paziņojums par kases iekšējām darbībām. Iestājās noildze, lai sāktu darbību. Tas var būt saistīts ar funkcionālu prasību vai nefunkcionālu prasību. Tas nav obligāts un tiek izmantots, lai iestatītu priekšnosacījumus pirms testa darbību veikšanas. Tās ir dalībnieka mijiedarbības darbības ar sistēmu. Veicot vairākas darbības, tās var ievietot numurētā sarakstā. Tas ir aktieru mijiedarbības efekts. Katra darbība var izraisīt vienu vai vairākus rezultātus. Ir svarīgi, lai, runājot par ziņojumiem lietotājam, teksts tiktu iekļauts kā daļa no paredzamās izvades, tāpēc programmētājs jau ir pārbaudījis šo informāciju ar klientu. Tas, kā mēs norādīsim tālāk, noteiks atkarību starp prasībām. Stāvoklis Jābūt parastam klientam. Darbības  Mēģiniet atmaksāt parastam klientam un pieprasīt summu, kas pārsniedz atlikumu.  Paredzamais rezultāts. Sistēmas pārbaude un pieņemšana 42  Tiek parādīts ziņojums "Pieprasītais daudzums pārsniedz jūsu pašreizējo bilanci, ievadiet daudzumu atkārtoti" un atgriežas logā, lai ievadītu daudzumu. Pieņemšanas pārbaude palīdzēs apstiprināt, ka veidojat klientam vajadzīgo lietotni, savukārt šo skriptu automatizēšana ļauj nepārtraukti testēt lietotni visā izstrādes procesā un izmantot tos kā daļu no regresijas testēšanas komplekta, lai nodrošinātu, ka turpmākās izmaiņas nepārkāpj pašreizējo. prasības. Tomēr, ja klients ir saistīts ar pierādījumu apkopošanu, jo īpaši automatizēto testēšanu, rodas vairākas iespējamās problēmas. Klienti parasti nav tehniski un mēdz distancēties no programmatūras izstrādes. Klients var sniegt datus un piemērus, savukārt testētāji vai izstrādātāji var ātri kodēt skriptus un izpildāmās specifikācijas. Lietotāja interfeisa akceptēšanas testi Piemēros akceptēšanas testi koncentrējās uz biznesa loģiku un domēna objektiem, lai noskaidrotu, vai loģika darbojas veiksmīgi. Bet kā ir ar to, kā lietotājs mijiedarbojas ar lietojumprogrammu? Šiem pieņemšanas testiem vajadzētu būt, lai pārbaudītu loģikas pareizību no lietotāja viedokļa, un lietotāja skatījumā ir lietotāja saskarne. Ja lietojumprogrammai ir laba atsaiste un laba loģikas atdalīšana no lietotāja interfeisa koda, tam vajadzētu atvieglot testu ieviešanu. Ja pārbaudīsit šajā līmenī, lietotāja interfeisā testi nemainīsies. Lai gan testēšanai jākoncentrējas tikai uz loģiku, tas nenozīmē, ka nevajadzētu izturēt akceptēšanas testus visā lietotāja saskarnē. Man patīk dūmu testu komplekts, kas ir paredzēts pamata lietotāja interfeisam. laimīgs ceļš". Viņi koncentrējas uz tām lietotnes daļām, kuras lietotāji, visticamāk, izmantos, lai maksimāli izmantotu savu pieredzi. mazākais daudzums testēšana. Ja mēģināt aptvert visu iespējamie veidi un lietotāja interfeisa izmantošana, un, ja lietotāja saskarne mainīsies, jums būs jāmaina visi testi. Piemēram, ja pārbaudīsit e-komercijas vietnes lietotāja interfeisu, ceļš ar prieku atlasīs preci, pievienos to grozam, pārbaudīs to un redzēs pirkuma apstiprinājumu. Ja šis scenārijs neizdodas, jūs patiešām vēlaties to noskaidrot ASAP. Noteiktām lietojumprogrammām atkarībā no sarežģītības un darbības ilguma lietotāja interfeisā varat veikt vairāk akceptēšanas testu, lai pārliecinātos, ka jums ir lielāka pārliecība par lietotāja interfeisa slāni. Tomēr veiksmīga lietotāja saskarnes pārbaude ir grūts jautājums un man nav vietas, kur to piesegt. Sistēmu testēšana un pieņemšana 43 3Inteliģentie testi. Kad esat izstāstījis stāstu un scenārijus skaidrā un saprotamā formātā, nākamais solis ir stāsta un skriptu automatizācija. Tas ļauj tiem darboties izstrādes laikā, lai izsekotu progresam un uztvertu regresijas kļūdas. Secinājumi un ieteikumi. No otras puses, mums ir sistēmu testi, kas ir atbildīgi par darbības novērtēšanu visā procesā, lai atklātu kļūdas, kas var rasties šim nolūkam, ir nepieciešams izstrādāt stratēģiju ar testiem un nošķirt koda izstrādi no saskarnes izstrādes, tāpēc vislabāk ir ieviest sistēmas testus. Šo divu programmatūras testu ieviešana jāveic ar stingriem testiem, kas atbilst noteiktiem standartiem, un koordinējot sistēmas izstrādē iesaistītās puses. Sistēmas pārbaude un pieņemšana 44 Bibliogrāfija 1. Isabelle Ramos Roman, Hosē Havjers Dolado Kosins. Kvantitatīvās vadības metodes programmatūras izstrādē. Alonso Amo, Loiks Martiness Normands. Ievads programmatūras izstrādē. Sistēmu testēšana un akcepttestēšana 45 8. -Datorvalodu un sistēmu katedra. Strukturāls sistēmas analīze. Baktēriju identifikācijas metodes mikrobioloģijas laboratorijā.