• Rezultati Niso Bili Najdeni

Primerjava ˇcelnega in zalednega testiranja v okolju neprekinjenega testiranja

N/A
N/A
Protected

Academic year: 2022

Share "Primerjava ˇcelnega in zalednega testiranja v okolju neprekinjenega testiranja"

Copied!
51
0
0

Celotno besedilo

(1)

Univerza v Ljubljani

Fakulteta za raˇ cunalniˇ stvo in informatiko

Andraˇz Sterle

Primerjava ˇ celnega in zalednega testiranja v okolju neprekinjenega

testiranja

DIPLOMSKO DELO

VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE

RA ˇCUNALNIˇSTVO IN INFORMATIKA

Mentor : viˇs. pred. dr. Igor Roˇ zanc

Ljubljana, 2022

(2)

Copyright. Rezultati diplomske naloge so intelektualna lastnina avtorja in matiˇcne fakultete Univerze v Ljubljani. Za objavo in koriˇsˇcenje rezul- tatov diplomske naloge je potrebno pisno privoljenje avtorja, fakultete ter mentorja.

Besedilo je oblikovano z urejevalnikom besedil LATEX.

(3)

Kandidat: Andraˇz Sterle

Naslov: Primerjava ˇcelnega in zalednega testiranja v okolju neprekinjenega testiranja

Vrsta naloge: Diplomska naloga na visokoˇsolskem programu prve stopnje Raˇcunalniˇstvo in informatika

Mentor: viˇs. pred. dr. Igor Roˇzanc

Opis:

Testiranje programskih sistemov, ki so sestavljeni iz heterogenih komponent, zahteva raznolika znanja in izkuˇsnje pri izbiri ustreznih orodij. Njihovo ne- prekinjeno testiranje se izvaja z vzpostavitvijo ustreznega cevovoda. V di- plomskem delu predstavite testiranje ˇcelnega in zalednega dela programskega sistema. V ta namen najprej kratko predstavite podroˇcje, nato pa z izbiro pri- mernih tehnologij in orodij izdelajte aplikacijo, ki bo sestavljena iz ˇcelnega in zalednega dela. Za oba dela izmed mnoˇzice uˇcinkovitih testnih ogrodij izbe- rite najprimernejˇsa in z njihovo pomoˇcjo pripravite teste. Na testni aplikaciji vzpostavite ˇse ustrezen cevovod za njihovo poganjanje. Na koncu analizirajte celoten postopek testiranja.

Title: Comparison of frontend and backend testing in a continuous testing environment

Description:

Testing software systems consisting of heterogeneous components requires diverse knowledge and experience in selecting the appropriate tools. Con- tinuous testing is carried out by means of an appropriate pipeline. In the diploma thesis, present the frontend and backend tests of the software sy- stem. First, briefly present the field, select the basic technologies and tools, and create an application that consists of a frontend and backend. Choose the most appropriate among the multitude of effective test tools for both

(4)

components and prepare tests. On the test application, establish a suitable pipeline to run all of the tests. Finally, analyze the entire testing process.

(5)

Zahvaljujem se mentorju viˇs. pred. dr. Igor Roˇzancu, ki me je vodil skozi proces pisanja diplomske naloge. Zahvaljujem se tudi starˇsema Mojci in Mar- kotu ter sestrama Ani in Tamari, ker so me podpirali ves ˇcas mojega ˇstudija.

(6)
(7)

Kazalo

Povzetek Abstract

1 Uvod 1

2 Orodja in tehnologije 3

2.1 Kljuˇcni pojmi . . . 3 2.2 Zaledni del . . . 5 2.3 Celni del . . . .ˇ 5 2.4 Streˇznik za graditev aplikacij . . . 6 2.5 Aplikacijski streˇznik . . . 6 2.6 Testna ogrodja . . . 7

3 Programiranje testne aplikacije 9

3.1 Zaledni del s Spring Framework ogrodjem . . . 9 3.2 Angular zaˇcelje . . . 11 4 Analiza testnih ogrodij in metodologij 15 4.1 Razliˇcne metodologije agilnega testiranja . . . 15 4.2 Testna ogrodja za zaledni del sistema . . . 17 4.3 Testna ogrodja za zaˇcelje . . . 18

5 Testni primeri za aplikacijo 21

5.1 Zaledni del sistema: JUnit z REST Assured . . . 21

(8)

5.2 Celni del sistema: Jasmine s poganjalcem testov Karma . . . .ˇ 22 6 Priprava in namestitev CI, CD in CT sistema in cevovoda 25 6.1 Izbira sistema . . . 25 6.2 Postavitev in konfiguracijaJenkins streˇznika . . . 26

7 Sklepne ugotovitve 31

Literatura 33

(9)

Seznam uporabljenih kratic

kratica angleˇsko slovensko

CI Continuous Integration neprekinjena integracija CT Continuous Testing neprekinjeno testiranje CD Continuous Deployment neprekinjeno uvajanje

FE frontend ˇcelni del sistema

BE backend zaledni del sistema

MVP Minimum Viable Product najmanjˇsi delujoˇc izdelek JSON JavaScript Object Notation JavaScript notacija za objekte TDD Test Driven Development testno voden razvoj

ATDD Acceptance Test Driven Deve- lopment

testno voden razvoj sprejemlji- vostnih testov

STDD Story Test Driven Develop- ment

testno voden razvoj upo- rabniˇskih zgodb

BDD Behaviour Driven Develop- ment

vedenjsko usmerjeni razvoj

E2E End to End od konca do konca

(10)
(11)

Povzetek

Naslov: Primerjava ˇcelnega in zalednega testiranja v okolju neprekinjenega testiranja

Avtor: Andraˇz Sterle

V diplomski nalogi smo se osredotoˇcili na primerjavo testiranja na ˇcelnem in zalednem delu sistema. Pregledali in izbrali smo potrebna orodja in tehno- logije, s katerimi smo ustvarili testno aplikacijo in ustrezni DevOps cevovod.

Pri tem smo se posebej posvetili razlikam in sposobnostim testnih ogrodij na ˇcelnem in zalednem delu sistema. Izbrali smo tista, ki so bila najbolje oce- njena glede na naˇse kriterije in naˇse poznavanje teh ogrodij. Nato smo preko cevovoda na testni aplikaciji pognali testne primere in opisali postopek ter de- lovanje cevovoda. Ob primerjavi rezultatov smo ugotovili, da nam pri testni aplikaciji za polno primerjavo testnih ogrodij in postopkov na ˇcelnem in zale- dnem delu, primanjkuje primerna zahtevnost in obseg aplikacije. Kljub temu smo priˇsli do zakljuˇcka, da je DevOps cevovod z neprekinjenim testiranjem neprecenljiv za podjetja vseh velikosti, ki razvijajo programsko opremo.

Kljuˇcne besede: DevOps, neprekinjeno testiranje, neprekinjena integracija, testi enot, integracijski testi, Jenkins, Docker.

(12)
(13)

Abstract

Title: Comparison of frontend and backend testing in a continuous testing environment

Author: Andraˇz Sterle

In this thesis we focused on the comparison of frontend and backend testing.

We reviewed and selected the necessary tools and technologies required to create a test application and the appropriate DevOps pipeline. We paid special attention to the differences and capabilities of both frontend and backend test frameworks. We selected the best rated according to our criteria and our knowledge of these frameworks. We then ran the test cases via our pipeline on the test application and described the process and operation of the pipeline. While comparing the results, we found that our test application lacks sufficient complexity and scope for a full comparison of frontend and backend test frameworks and procedures. Nevertheless, we have come to the conclusion that a DevOps pipeline with continuous testing is invaluable for all size companies developing software.

Keywords: Devops, continuous testing, continuous integration, unit testing, integration testing, Jenkins, Docker.

(14)
(15)

Poglavje 1 Uvod

Pri agilnem razvoju programske opreme je testiranje kode zelo pomembno, saj nam omogoˇca odkrivanje napak, preden te postanejo veˇcji problem. Pri tem se obiˇcajno napisani testi ne poganjajo pogosto, saj njihovo izvajanje upoˇcasni razvijalce in podaljˇsa ˇcas razvoja programske opreme. Ta problem podjetja reˇsujejo z uporabo DevOps naˇcel in procesov, ki zdruˇzujejo delovanje in razvoj. Eden od procesov je uporaba sistema za neprekinjeno testiranje (ang. Continous Testing - CT), ki nam omogoˇca testiranje ob vsaki zdruˇzitvi kode v repozitorij. Sistemi za neprekinjeno testiranje poganjajo cevovode, kjer so opisani koraki in orodja, ki jih sistem poˇzene na kodi. Ti cevovodi pa postajajo vse bolj zapleteni, ker tudi projekti postajajo vse veˇcji in zapleteni.

Recimo aplikacije napisane v veˇc jezikih potrebujejo tudi vse bolj zapletene cevovode.

Slika 1.1: Potek diplomske naloge

V okviru diplomske naloge smo se zato vpraˇsali, kakˇsne so obstojeˇce 1

(16)

2 Andraˇz Sterle reˇsitve v testnih ogrodjih, ki naslavljajo poveˇcano zapletenost projektov, ter kakˇsne so razlike med testnimi ogrodji v ˇcelnem in zalednem delu. Zanimalo nas je tudi, ˇce je sploh potrebno testirati vsako komponento posebej ali lahko testiramo vse skupaj?

Predstavitev tematike bomo zaˇceli z analizo orodij in postopkov, ki so uporabljeni pri testiranju in razvoju aplikacij. Pri tem bomo primerjali tudi razliˇcna testna ogrodja. Z izbranimi orodji bomo vzpostavili testno aplikacijo in izbrane cevovode, definirali in implementirali testne primere ter na koncu predstavili koristi in ugotovitve.

(17)

Poglavje 2

Orodja in tehnologije

Za zadano nalogo primerjave ˇcelnega in zalednega testiranja v okolju nepreki- njenega testiranja potrebujemo ˇsirok nabor orodij. Orodja so bila analizirana po veˇc merilih: cena, popularnost orodja, funkcionalnost in podobno.

Treba je bilo izbrati razvojna in testna ogrodja za zaˇcelje (ang. frontend - FE) in zaledje (ang. backend - BE), testna ogrodja za FE in BE, orodja za neprekinjeno integracijo (ang. continuous integration - CI), neprekinjeno uvajanje (ang. continuous deployment - CD) in neprekinjeno testiranje (ang.

continuous testing - CT), streˇznik za graditev aplikacij in tehnologijo za streˇzbo aplikacij.

2.1 Kljuˇ cni pojmi

Skozi celoten potek naloge uporabljamo veˇc strokovnih izrazov, ki so opisani v temu poglavju.

− Zaledni del sistema

Zaledni del sistema je uporabniku skrit in vsebuje veˇcino poslovne lo- gike. Podatke, ki jih potrebuje za procesiranje, dobi preko aplikacij- skega programskega vmesnika (ang. application programming interface - API).

3

(18)

4 Andraˇz Sterle

− Celni del sistemaˇ

Celni del sistema je sestavljen iz komponent, ki so neposredno na voljoˇ uporabniku. Obiˇcajno je to uporabniˇski vmesnik in vse komponente, ki so potrebne za prenos podatkov do zalednega dela.

− Neprekinjena integracija

Neprekinjena integracija (ang. continuous integration - CI) je praksa razvoja programske opreme, ki predlaga pogosto integracijo svojega dela [26]. Ta pristop vodi do znatno zmanjˇsanih teˇzav pri integraciji.

− Neprekinjeno testiranje

Neprekinjeno testiranje (ang. continuous testing - CT) je praksa ra- zvoja programske opreme, kjer se kodo testira ob vsaki gradnji pro- gramske opreme [9].

− Neprekinjeno uvajanje

Neprekinjeno uvajanje (ang. continuous deployment - CD) je pristop k razvoju programske opreme, kjer se programska oprema gradi, testira in uvaja na streˇznike v kratkih intervalih. Neprekinjeno uvajanje je zelo podobno neprekinjeni dostavi (ang. continuous delivery), pri kateri pa se programska oprema ne naloˇzi na streˇznik, kot del cevovoda [41].

− Cevovod

Cevovod je skupek pravil in zaporedje ukazov, ki jih izvede CI/CD sis- tem nad kodo programske opreme. Projekti imajo lahko veˇc cevovodov, ki se razlikujejo glede na ciljno okolje in konfiguracijo.

− REST Krmilnik

Ogrodje Spring Framework [46] za komunikacijo preko REST vme- snika uporablja krmilnike, ki glede na vrsto HTTP zahteve kliˇcejo in vrnejo rezultat ustrezne metode [1].

(19)

Diplomska naloga 5

− Testiranje od konca do konca

Testiranje od konca do konca (angl. end to end - E2E) je tehnika, ki preizkuˇsa celotno aplikacijo od zaˇcetka do konca in s tem zagotovi, da se delovanje aplikacije obnaˇsa po priˇcakovanjih [35].

2.2 Zaledni del

Zaledni del sistema je v naˇsem primeru zaradi preteklih izkuˇsenj napisan v Javi[39] z uporabo ogrodjaSpring Framework[46]. Javaje visoko-nivojski, objetkno-usmerjeni, sploˇsni programski jezik, ki ga razvija podjetje Oracle [40]. Javaaplikacije delujejo na Javanavideznem stroju (angl. Java Virtual Machine - JVM) neodvisno od arhitekture raˇcunalnika, na katerem se poga- njajo. To programerjem omogoˇca, da programsko opremo napiˇsejo enkrat in jo potem poganjajo na veˇc arhitekturah in operacijskih sistemih. S tem se cena razvoja programske opreme lahko obˇcutno zmanjˇsa.

Za hranjenje podatkov smo se odloˇcili za uporabo vgrajene podatkovne baze SQLite [47]. SQLite je v C-ju [23] napisana knjiˇznica, ki implementira pogon za relacijsko podatkovno bazo. Za razliko od veˇcine drugih podat- kovnih baz, SQLite ne uporablja arhitekture odjemalec-streˇznik, ampak je namenjena za hranjenje podatkov lokalno, znotraj individualne aplikacije ali naprave.

S podobnim razlogom smo se za streˇznik odloˇcili uporabitiApache Tomcat [8]. Apache Tomcatje odprto-kodna implementacijaJakarta EE[24] specifi- kacij, ki ga razvija fundacijaApache. Nudi HTTP streˇznik, ki lahko poganja programe napisane za JVM.

2.3 Celni del ˇ

Za ˇcelni del sistema je bil uporabljen Angular [29]. Angular je moderno ogrodje za razvoj spletnih aplikacij, zgrajen na jeziku TypeScript [36], ki ga razvijaGoogle[28]. Omogoˇca skaliranje projektov od enega razvijalca do

(20)

6 Andraˇz Sterle aplikacij na ravni veˇcjih podjetij, preproste nadgradnje in nudi ekosistem veˇc kot 1,7 miljona razvijalcev, avtorjev knjiˇznic in ustvarjalcev vsebin.

Tudi tu smo uporabili kar vgrajeni streˇznik, kar je v tem primeruWebpack DevServer [7]. Namenjen je predvsem uporabi med razvojem aplikacije in je zato vgrajen v zdruˇzevalniku JavaScript [42] modulov webpack[50].

2.4 Streˇ znik za graditev aplikacij

Za neprekinjeno testiranje potrebujemo tudi streˇznik za graditev aplikacij, ki bo kodo zGitHub [27] repozitorija zgradil in potem na aplikacijah pognal teste. Tukaj je kar nekaj zastonjskih in odprtokodnih projektov, kot so:

Drone.io [32], ki za poganjanje cevovodov uporablja Docker vsebovalnike in ga razvija podjetje Harness [31]; Jenkins [16], ki se ponaˇsa z bogatim naborom vtiˇcnikov s katerimi podpira praktiˇcno vse vrste projektov in ga v glavnem razvija podjetje CloudBees;GitLab [14], ki poleg repozitorija kode vsebuje ˇse implementacijo CI/CD cevovoda; in BuildBot[13], skalabilno CI ogrodje, napisano v jezikuPython . Zaradi preteklih izkuˇsenj in preprostosti smo izbrali Jenkins, Drone.io pa je bil na drugem mestu zaradi uporabe Docker [20] vsebovalnikov.

2.5 Aplikacijski streˇ znik

Zgrajene aplikacije je potrebno nekam naloˇziti in pognati. Zaradi prepro- stosti aplikacij in njihove uporabe smo se odloˇcili za vsebovalnike. Tu sta na voljo dve orodji: Docker in podman [19]. Odloˇcili smo se za Docker, predvsem zaradi veˇcje popularnosti, podpore za veˇc operacijskih sistemov (Windows, MacOS inLinux) in zaradi uporabe docker-compose datoteke, ki nam omogoˇca sprotno postavitev veˇc streˇznikov v eni sami datoteki (npr.

podatkovna baza, ˇcelni in zaledni del aplikacije) [21].

(21)

Diplomska naloga 7

2.6 Testna ogrodja

Pri zalednem delu sistema se za testiranje enot in integracijsko testiranje uporablja preprosto testno ogrodje JUnit 5 [48] ter knjiˇznico RestAssured [43] za testiranje in potrjevanje REST klicev.

Ogrodje za zaˇcelje Angular ima za teste ˇze vkljuˇceno ogrodje Jasmine [33], ogrodje za testiranje JavaScript kode. Za poganjanje testov smo upo- rabili poganjalec testov Karma [34], ki poˇzene teste z brezobliˇcnim Chrome brskalnikom, kar nam omogoˇca testiranje aplikacije na napravah brez upo- rabniˇskega vmesnika.

Pri zaˇcelju je vredno omeniti tudi E2E teste, pri katerih testiramo izkuˇsnjo konˇcnega uporabnika s simulacijo resniˇcnega uporabnika in testiranjem od- ziva sistema, glede na dejanja simuliranega uporabnika. Za E2E teste po- znamo orodjeProtractor [30], ki je bilo narejeno posebej za testiranje apli- kacij narejene z ogrodjemAngular.

(22)

8 Andraˇz Sterle

(23)

Poglavje 3

Programiranje testne aplikacije

Za analizo in primerjavo testnih ogrodij, smo postavili testno aplikacijo, na kateri se bodo potem izvajali testi. Da bi izpostavili razliko med ˇcelnim in za- lednim delom smo za funkcionalnost aplikacije izbrali upravljanje z binarnimi podatki in sicer preprosto spreminjanje slik (spreminjanje RGB vrednosti, podatkovnega formata slike in podobno) ter sistem za nalaganje poljubnih datotek.

Zaradi obseˇznosti je aplikacija narejena v obliki najmanjˇsega delujoˇcega izdelka (angl. Minimum Viable Product - MVP), kar nam je omogoˇcilo hitro postavitev aplikacije, je pa oteˇzilo primerjave testov, saj se ponavadi testirajo specifiˇcne funkcionalnosti, ki pa jih pri MVP ni veliko.

3.1 Zaledni del s Spring Framework ogrod- jem

Za delovanje naˇse aplikacije moramo postaviti preprost streˇznik, ki bo pre- jemal zahteve preko REST vmesnika, jih predelal in vrnil rezultat. Pri tem nam delo olajˇsa izbrano ogrodje Spring Framework. Zaledni del sistema je sestavljen iz REST krmilnikov, ki kliˇcejo pripadujoˇce storitve. Te preko shrambe podatkov komunicirajo s podatkovno bazo, obdelajo zahteve in vr- nejo rezultat (slika 3.1).

9

(24)

10 Andraˇz Sterle

Slika 3.1: Struktura zalednega dela sistema

Implementirali smo dve funkcionalnosti: preprosta obdelava slik in hra- njenje datotek.

3.1.1 Obdelava slik

Obdelava slik ne hrani podatkov in je zato arhitekturno dokaj preprosta.

Potrebuje samo REST krmilnik, storitev za obdelavo slik, vso poslovno logiko in model slike, v katerega preslikamo podatke, ki jih prejmemo v HTTP zahtevi.

Slika 3.2: Metoda convertImage, ki skrbi za obdelavo slik

(25)

Diplomska naloga 11 Ker podpiramo veˇc razliˇcnih posegov na sliki, ima REST krmilnik v poti veˇc razliˇcnih parametrov s katerimi lahko spremenimo delovanje metode. Do metode convertImage (slika 3.2) lahko dostopamo preko dveh poti: prva je za metode, ki potrebujejo dodatne parametre, druga pa za metode, ki parametrov ne potrebujejo.

3.1.2 Hranjenje datotek

Hranjenje datotek potrebuje za delovanje poleg REST krmilnika, storitve za hranjenje datotek in modela datoteke tudi shrambo podatkov in entiteto, ki jo shranimo v bazo. REST krmilnik za datoteke podpira dve funkciji: branje vseh datotek in ustvarjanje novih datotek.

Pri branju samo kliˇcemo storitev za hranjenje datotek. Ta od shrambe podatkov zahteva vse vnose v bazi, jih s preslikalnikom pretvori v seznam File modelov in vrne REST krmilniku za datoteke, ki rezultat klica vrne v JSON obliki.

Pri ustvarjanju novih datotek naredimo ravno obratno. REST krmilnik prejme JSON seznam datotek, ki jih ˇzelimo shraniti. Storitev jih s preslikal- nikom pretvori v seznamDatabaseFile entitet in shrani v bazo.

3.2 Angular zaˇ celje

Za zaledni streˇznik testne aplikacije je seveda potreben tudi nek odjemalec (angl. client), ki se z njem poveˇze in nam izriˇse uporabniˇski vmesnik, preko katerega lahko uporabljamo funckionalnosti zaledja. Zaˇcelje je sestavljeno iz komponent, storitev in modelov.

Funkcionalnost zaˇcelja se ujema z funkcionalnostjo zaledja, zato imamo dva zavihka: Files in Images.

(26)

12 Andraˇz Sterle

3.2.1 Nalaganje datotek

Pri zavihku Files je uporabniˇski vmesnik razdeljen na dva dela: na seznam datotek na streˇzniku in vmesnik za nalaganje novih datotek (slika 3.3).

Za pridobitev seznama datotek na streˇzniku ob tvorbi strani naredimo REST klic na zaledni del sistema in potem za vsako obstojeˇco datoteko izpiˇsemo njeno ime. Pri nalaganju datotek s storitvijo preslikamo HTML FileList v seznam datotek, zakodiramo njihovo vsebino v Base64, ki se uporablja za prenos binarnih podatkov med sistemi, ki podpirajo samo pre- nos podatkov v obliki besedila. Vse skupaj pretvorimo v JSON obliko in poˇsljemo na zaledni del sistema preko REST klica. Po prenosu se ponovno prenese seznam datotek, ki sedaj vsebuje tudi pravkar preneseno datoteko.

Slika 3.3: Uporabniˇski vmesnik za nalaganje datotek

3.2.2 Obdelava slik

Pri obdelavi slik imamo uporabniˇski vmesnik razdeljen na tri dele: izbira ˇzelenega naˇcina obdelave slike, vmesnik za nalaganje slik in vmesnik za iz- biro dodatnih parametrov (slika 3.4). Dodatne parametre lahko izbiramo

(27)

Diplomska naloga 13 le v primeru, ko smo izbrali tak naˇcin obdelave slike, ki potrebuje dodatne parametre.

Ko izberemo ˇzeljen naˇcin obdelave slike in vse potrebne parametre, pri- pnemo ˇse sliko in zaˇcnemo s prenosom podatkov. Naˇcin obdelave in parametri so doloˇceni ˇze preko HTTP poti, slika sama pa se zakodira vBase64, pretvori v JSON in se poˇslje kot telo zahteve. Zaledni del sistema obdela zahtevo in vrne rezultat, ki ga preberemo, preslikamo v HTML File in avtomatsko pre- nesemo na uporabnikovo napravo.

Slika 3.4: Uporabniˇski vmesnik za obdelavo slik

(28)

14 Andraˇz Sterle

(29)

Poglavje 4

Analiza testnih ogrodij in metodologij

Pred odloˇcitvijo za izbiro testnega ogrodja je seveda treba primerjati razliˇcne moˇznosti in izbrati najprimernejˇso za naˇs program. Za funkcionalnost pro- grama smo namenoma izbrali delo z binarnimi datotekami, ker nam to pre- preˇcuje testiranje delovanja zalednega dela sistema s testi na zaˇcelju. Tako se s zaˇcelnimi testi lahko testira samo zaˇcelje in z zalednimi testi samo zaledje.

Obiˇcajno testna ogrodja ne oglaˇsujejo preveˇc svojih posebnih funkcional- nosti, kar nam oteˇzi izbiro. Vseeno jih lahko razlikujemo vsaj glede metodo- logije agilnega testiranja.

4.1 Razliˇ cne metodologije agilnega testiranja

V svetu agilnega programiranja poznamo tri pogoste tehnike testiranja, ki jih je mogoˇce uporabiti za izboljˇsanje naˇsih praks testiranja in za pomoˇc pri omogoˇcanju avtomatiziranega testiranja. [2]

1. testno voden razvoj (angl. Test Driven Development - TDD) [3]

2. razvoj, ki temelji na sprejemljivosti (angl. Acceptance Test Driven Development - ATDD) [6]

15

(30)

16 Andraˇz Sterle 3. razvoj na podlagi vedenja (angl. Behaviour Driven Development -

BDD) [5]

TDD, ATDD in BDD so tehnike razvoja programske opreme, ki se si- cer lahko uporabljajo v kateri koli metodologiji, ˇceprav so vidiki vseh treh pogosto del pristopa agilnega testiranja ekipe.

4.1.1 Testno voden razvoj

TDD je pristop k razvoju programske opreme, kjer razvijalec napiˇse test pre- den napiˇse kodo. Test se nato uporabi za ustvarjanje in preoblikovanje kode.

Ko koda opravi test, jo ˇse preoblikujemo tako, da postane bolj performanˇcna in berljiva.

4.1.2 Razvoj, ki temelji na sprejemljivosti

Razvoj, ki temelji na sprejemljivosti, se imenuje tudi razvoj, ki temelji na preizkusu zgodbe (angl. Story Test Driven Development - STDD)

ATDD zagotavlja, da izdelek, sistem ali proces, ki se gradi, izpolnjuje priˇcakovanja, ki jih je doloˇcil lastnik izdelka, ta pa se nanaˇsajo na potrebe konˇcnih uporabnikov in drugih deleˇznikov. S tem zagotovi, da vsi ˇclani ekipe natanˇcno razumejo, kaj je potrebno razviti in implementirati. V Scrumu so ti testi merila za sprejem vsake uporabniˇske zgodbe.

4.1.3 Razvoj na podlagi vedenja

Razvoj na podlagi vedenja (angl. Behaviour Driven Development - BDD) je evolucija TDD in ATDD v obliki ogrodja, ki doloˇca postopke, korake in udeleˇzence testiranja. Cilj BDD je narediti testno voden razvoj bolj dostopen in intuitiven.

BDD opisuje cikel komunikacije in interakcije z razvijalci, testerji in ne- tehniˇcnimi oziroma poslovnimi udeleˇzenci v projektu. Skupaj spiˇsejo zgodbe uporabnikov, ki jih kasneje razvijalci prepiˇsejo v teste.

(31)

Diplomska naloga 17

4.2 Testna ogrodja za zaledni del sistema

Ogledali smo si veˇc testnih ogrodij za zaledni del sistema. Veˇcina jih je narejenih za pisanje testov po BDD metodologiji, ki pa je neprimerna za naˇso testno aplikacijo, saj je dokaj preprosta.

− JUnit

Preprosto ogrodje za pisanje ponovljivih testov. Eno izmed bolj popu- larnih ogrodij za testiranje individualnih enot programov [48].

− JBehave

Testno ogrodje za razvoj na podlagi vedenja (BDD) [4].

− Cucumber

Tako kot JBehave je Cucumber [45] testno ogrodje za BDD teste. Za pisanje posameznih testov podpira programski jezikGherkin [44].

− Serenity

ˇSe eno testno ogrodje za razvoj na podlagi vedenja (BDD) [10], ki podpira integracijo z JUnit, Cucumber, JBehave in Rest Assured [11].

− Mockito

Mockito [38] je testno ogrodje, ki podpira kreacijo testnih nadomestni- kov (angl. mock objects) v avtomatiziranih testih enot za namene TDD ali BDD.

− Rest Assured

REST Assured[43] je knjiˇznica, ki omogoˇca testiranje REST storitev v okvirju drugih testnih ogrodij.

Za namene naˇse testne aplikacije smo se odloˇcili za ogrodje JUnit 5 in knjiˇznico REST Assured. Preprosti testi enot s podporo za REST klice.

(32)

18 Andraˇz Sterle

4.3 Testna ogrodja za zaˇ celje

Pri ˇcelnem delu sistema smo si ogledali veˇcJavaScripttestnih ogrodij. Tako kot pri zalednem delu je veˇcina ogrodij veˇc kot primernih, za naˇso testno aplikacijo.

− Jasmine

Jasmineje JavaScript testno ogrodje za BDD [33].

− Mocha

Mocha je JavaScript testno ogrodje, ki omogoˇca preprosto asinhrono testiranje, ker se izvaja naNode.js [25] in v brskalniku [37].

− Jest

JestjeJavaScript testno ogrodje s poudarkom na preprostosti. Pod- pira veˇc razliˇcnih frontend ogrodij, kot so: Babel, TypeScript, Node, React, Angular, Vue, ... [22].

− Siesta

Siestaje JavaScriptorodje za testiranje enot in uporabniˇskega vme- snika, ki lahko izvaja teste na spletnih straneh ali v procesih Node.js [12].

− Protractor

Protractor [30] je uradno ogrodje za testiranje od konca do konca (angl. end to end - E2E) pri ogrodju Angular. Pri testiranju uporablja Selenium [18] streˇznik in Jasmine za samo primerjavo rezultatov.

− Karma

Karma je poganjalec testov, ki nam omogoˇca avtomatsko poganjanje testov. Podpira tudi poganjanje testov ob spremembi kode [34].

Pri primerjavi testnih ogrodij smo ugotovili, da so kar se tiˇce funkcional- nosti vsa analizirana ogrodja primerna za naˇse namene, saj je naˇsa testna

(33)

Diplomska naloga 19 aplikacija v obliki najmanjˇsega delujoˇcega izdelka. Zato je bila preprostost uporabe in vzpostavitve sistema kljuˇcna pri odloˇcitvi. Odloˇcili smo se za ogrodjeJasmine s poganjalcem testov Karma, saj so ˇze tovarniˇsko vkljuˇceni v vse noveAngular projekte.

(34)

20 Andraˇz Sterle

(35)

Poglavje 5

Testni primeri za aplikacijo

Po izbiri testnih ogrodij smo zaˇceli s pisanjem testnih primerov za aplika- cijo. Ker je naˇsa testna aplikacija v obliki MVP nimamo posebnih zahtev pri testnih primerih, zato smo se osredotoˇcili na ˇcim veˇcjo pokritost kode aplikacije.

5.1 Zaledni del sistema: JUnit z REST As- sured

Zaledni del sistema je sestavljen iz veˇc komponent, s katerimi skupaj podpi- ramo dve funkcionalnosti. Posamezne komponente oz. enote lahko testiramo s testom enot. Preverimo lahko izbrano vsebino recimo delovanje kode, ki spreminja barvo slike. Testiranja enot v nalogi nismo izpostavljali, ker je pri tako preprostih komponentah laˇzje testirati vse komponente skupaj kar z integracijskimi testi.

Za vsako od implementiranih funkcionalnosti smo napisali svoj razred, ki vsebuje integracijske teste napisane z JUnit in REST Assured. Ti testi se obnaˇsajo kot odjemalec in kliˇcejo iste HTTP poti, kot jih bo kasneje zaˇcelje.

Pri hranjenju podatkov imamo s testi pokrite vse veje kode, torej bra- nje vseh datotek, shranjevanje ene same datoteke in shranjevanje seznama datotek. Pri shranjevanju datotek, preberemo datoteko oziroma datoteke,

21

(36)

22 Andraˇz Sterle vsebino zakodiramo v Base641 in poˇsljemo JSON predstavitev na HTTP pot. ˇCe je odziv streˇznika enak 2002, je bila zahteva uspeˇsna (slika 5.1).

Pri branju seznama ˇze naloˇzenih datotek najprej pripravimo podatke in naloˇzimo nekaj datotek. ˇCe je shranjevanje datotek uspeˇsno, testiramo ˇse zahtevo za branje, preverimo odziv streˇznika (biti mora enak 200) in telo odziva, ˇce to vsebuje imena datotek, ki smo jih prej naloˇzili.

Slika 5.1: Test za preverjanje delovanja shranjevanja datotek

Z napisanimi testi smo pokrili veˇcino pogostejˇsih vej v kodi in dosegli zadovoljivo mero pokritosti kode na zalednem delu sistema, tako da smo se lotili ˇse zaˇcelja.

5.2 Celni del sistema: Jasmine s poganjalcem ˇ testov Karma

Na zaˇcelju imamo zelo preproste teste, ker je preprost tudi zaˇcelni del sistema.

Tako preverjamo le to, ˇce se naloˇzijo pravilni podatki glede na obiskano stran

1Uporablja se za prenos binarnih podatkov med sistemi, ki podpirajo samo prenos podatkov v obliki besedila.

2To je HTTP koda, ki predstavlja uspeˇsno izvrˇseno zahtevo.

(37)

Diplomska naloga 23 (slika 5.2).

Slika 5.2: Uporabniˇski vmesnik za pregled testov v Chromu

Ob obisku strani za nalaganje datotek recimo preverimo, ali se pojavi gumb za dodajanje datotek in ne gumb za poˇsiljanje na streˇznik. Za pre- verjanje delovanja nalaganja datotek bi potrebovali E2E teste, ki bi nam omogoˇcali testiranje testne aplikacije v celoti, ampak se za to zaradi prepro- stosti testne aplikacije, nismo odloˇcili.

(38)

24 Andraˇz Sterle

(39)

Poglavje 6

Priprava in namestitev CI, CD in CT sistema in cevovoda

S pripravljenimi testnimi primeri in testno aplikacijo, nam za postavitev celotnega sistema za neprekinjeno graditev, testiranje in dostavo manjkata samo ˇse postavitev streˇznika za graditev aplikacije in konfiguracija CI, CD in CT cevovoda.

6.1 Izbira sistema

Za postavitev svojega streˇznika za graditev aplikacije, smo izbirali med veˇc moˇznostmi [15].

− BuildBot

Buildbot je odprtokodna aplikacija za razporejanje opravil: postavi opravila v ˇcakalno vrsto, izvrˇsi opravila, ko so na voljo zahtevani viri, in poroˇca o rezultatih [13].

− Drone

Drone je samopostreˇzna platforma za neprekinjeno integracijo s pou- darkom na aplikacijah, ki teˇcejo v Docker okoljih [32].

25

(40)

26 Andraˇz Sterle

− Jenkins

Jenkins je vodilni odprtokodni streˇznik za avtomatizacijo. Ponuja ˇsirok nabor vtiˇcnikov za podporo gradnji, uvajanju in avtomatizaciji poljub- nega projekta [16].

− GitLab

GitLab je odprtokodna DevOps platforma, ki vsebuje cevovod za ne- prekinjeno uvajanje in integracijo ter upravljalnik Git repozitorija s funkcionalnostjo baze znanja in sledenja teˇzavam [14].

− TravisCI

Travis CI je gostujoˇca storitev za neprekinjeno integracijo, ki se upo- rablja za gradnjo in preizkuˇsanje projektov programske opreme, ki go- stujejo v Git repozitoriju [49].

ZaDrone.iobi potrebovali domeno za integracijo zGitHubrepozitorijem, kar ni smiselno za naˇso nalogo. TravisCI bi lahko bila zanimiva izbira, vendar je nismo izbrali, ker smo ˇze vse ostalo gostovali sami. GitLab je kot celoten paket preveˇc zapleten za tako preprosto aplikacijo. Podobno je tudi priBuildBot, ki je narejen za veliko prilagodljivost in bolj zapletene primere, kot so meˇsane jezikovne aplikacije ali zapleteni cevovodi.

Na koncu smo se odloˇcili za Jenkins, ker je odprtokodna aplikacija, ki jo lahko z vtiˇcniki prilagodimo svojim potrebam in jo lahko gostujemo sami.

6.2 Postavitev in konfiguracija Jenkins streˇ znika

Kot vse ostale streˇznike smo tudi Jenkinspostavili v svojemDocker okolju.

Jenkins ima ˇze pripravljeno svoje Docker okolje [17], ki smo ga prenesli in postavili z naˇso konfiguracijo. Za to smo uporabili datotekodocker-compose (slika 6.2).

Zdocker-compose prenesemoJenkinsokolje z dolgoroˇcno podporo, od- premo vsa potrebna vrata in zveˇzemo lokacijo na trdem disku z virtualnim

(41)

Diplomska naloga 27

Slika 6.1: Jenkinsuporabniˇski vmesnik diskom v Docker okolju.

6.2.1 Konfiguracija vtiˇ cnikov

Po postavitvi streˇznika smo izbrali vtiˇcnike, ki nam pridejo prav pri posta- vitvi cevovoda.

Med vtiˇcniki so bili, poleg privzetih, uporabni ˇse:

• GitHub integracija,

• Configuration as Code, ki nam omogoˇca konfiguracijo Jenkinsa s pisanjem kode,

• Docker vtiˇcniki, ki nam omogoˇcajo gradnjo in objavoDocker slik in

• NodeJS, ki nam omogoˇca gradnjo in testiranje zaˇcelja napisanega v Angularogrodju.

Naslednji korak je bila konfiguracija nastavitev kot so: postavitev Maven, JDKverzij, nastavitev hrambe kljuˇcev in gesel za dostop doGitHub repozito- rija za GitHub vtiˇcnik in dostop do Docker Huba pri Docker vtiˇcniku.

(42)

28 Andraˇz Sterle

Slika 6.2: Datoteka docker-compose.yml za postavitev Jenkinsokolja

6.2.2 Postavitev cevovodov

Z ˇze nastavljenim Jenksinsom nam je ostala samo ˇse postavitev cevovoda aplikacije. Ker imamo zaˇcelni in zaledni del sistema loˇcen, potrebujemo dva cevovoda, ki bosta delovala zelo podobno. V obeh poteh vzamemo najnovejˇso kodo z repozitorija, jo prevedemo in poˇzenemo streˇznik, na kateremu testi- ramo. ˇCe se vsi testi konˇcajo uspeˇsno, zgradimoDockersliko in jo prenesemo v Docker Hub.

Pri zaˇcelnem delu sistema je bila potrebna manjˇsa sprememba, ker je bilo za poganjanje testov potrebno pripraviti brezobliˇcni Chrome brskalnik (slika 6.4). Zato smo v isto Docker okolje, kjer se ˇze nahaja Jenkins, naloˇzili ˇse Chromebrskalnik. V nastavitvah zaKarmoje bilo potrebno nastaviti lastnost singleRun naTrue in dodati ˇse ChromeHeadless s posebnimi nastavitvami pri pogonu programa. S tem smo pripravili Karmo, da poganja Chrome v brezobliˇcni obliki, brez ˇcakanja na ˇcloveˇski odziv.

(43)

Diplomska naloga 29

Slika 6.3: Jenkinsnastavitve

Slika 6.4: Nastavitve za brezobliˇcni Chrome brskalnik

(44)

30 Andraˇz Sterle

(45)

Poglavje 7

Sklepne ugotovitve

V nalogi smo se osredotoˇcili na problem testiranja programskih sistemov in aplikacij, sestavljenih iz veˇc komponent, ki so napisane v razliˇcnih jezikih.

Zanimalo nas je, kaj lahko testiramo na zaˇcelnem ali zalednem delu sistema.

Zgradili smo testno aplikacijo, na podlagi katere smo potem analizirali in izbrali testna ogrodja, pripravili teste in postavili celoten DevOps cevovod.

Ugotovili smo, da se je pri testiranju treba prilagoditi potrebam. Te- sti na vsaki komponenti so najbolj primerni za testiranje le te komponente.

Veˇc preprostih delov aplikacije ali pa komponente, za katere je teˇzko napi- sati teste, je najlaˇzje testirati kot celoto z integracijskimi in E2E testi, ki nam omogoˇcajo istoˇcasno testiranje zelo razliˇcnih komponent aplikacije, ki so lahko del zaˇcelja ali zaledja.

Na ˇcelnem delu sistema testiramo funkcionalnost in delovanje celotne apli- kacije in uporabniˇskega vmesnika. Testiramo lahko tudi uporabniˇsko izkuˇsnjo s performanˇcnimi testi. Na zaledju pa se osredotoˇcamo na testiranje poslovne logike in podatkovne baze. Posebej se posvetimo tudi testiranju delovanja sistema pod stresom, ki ga simuliramo z veˇc navideznimi uporabniki. Tako lahko odkrijemo probleme, kjer pride do zagate, tvegana stanja ali izgube podatkov.

Za bolj podrobno primerjavo testnih ogrodij se je izkazalo, da imamo preveˇc preprosto testno aplikacijo, saj je veˇcina testnih ogrodij miˇsljena za

31

(46)

32 Andraˇz Sterle uporabo z veˇcjimi aplikacijami. Zaradi tega je bilo veliko ugotovitev teo- retiˇcnih in ne empiriˇcno dokazanih na aplikaciji.

Diplomsko nalogo bi lahko izboljˇsali z veˇcjo, bolj zapleteno testno apli- kacijo, kjer bi lahko implementirali veˇc vrst testov in testnih ogrodij. Potem bi lahko primerjali in analizirali primernost razliˇcnih pristopov testiranja na dejanskih primerih. Lahko bi se tudi znebili arhitekture odjemalec-streˇznik in celotno testno aplikacijo napisali v veˇc razliˇcnih jezikih in bi potem pri- merjali testna ogrodja, teste in rezultate testov med razliˇcnimi programskimi jeziki.

Menim pa, da smo kljub preprostosti testne aplikacije lahko pridobili veliko informacij. Ob tem smo se veliko nauˇcili o DevOps cevovodih, avto- matskem testiranju in o njuni pomembnosti za podjetja vseh velikosti, ki se ukvarjajo z izdelavo programske opreme.

(47)

Literatura

[1] Zack Aayush. Spring – rest controller, 2021. https:

//www.geeksforgeeks.org/spring-rest-controller/, dostopano 16.1.2022.

[2] Agiledata. Three agile testing methods – tdd, atdd and bdd, 2020. https://agiledata.io/blog/agile-techniques/three- agile-testing-methods-tdd-atdd-and-bdd/, dostopano 1.11.2021.

[3] Agiledata. Introduction to tdd, 2020. http://agiledata.org/essays/

tdd.html, dostopano 5.2.2022.

[4] Agiledata. Jbehave, 2021. https://jbehave.org, dostopano 1.11.2021.

[5] Agile Alliance. Behaviour driven development, 2017. https://www.

agilealliance.org/glossary/bdd/, dostopano 5.2.2022.

[6] Agile Alliance. Acceptance test driven development, 2020. https://

www.agilealliance.org/glossary/atdd/, dostopano 5.2.2022.

[7] Angular. Deployment, 2021. https://angular.io/guide/

deployment#building-and-serving-from-disk, dostopano 24.10.2021.

[8] Apache. Apache tomcat, 2021. https://tomcat.apache.org, dosto- pano 16.1.2022.

[9] Adam Auerbach. Part of the pipeline: Why continuous testing is essen- tial, 2015. https://www.techwell.com/techwell-insights/2015/

33

(48)

34 Andraˇz Sterle

08/part-pipeline-why-continuous-testing-essential, dostopano 16.1.2022.

[10] Serenity BDD. Serenity, 2021. https://serenity-bdd.info, dosto- pano 1.11.2021.

[11] Serenity BDD. Serenity introduction, 2021. https://serenity- bdd.github.io/theserenitybook/latest/index.html, dostopano 23.1.2022.

[12] Bryntum. Siesta, 2021. https://www.bryntum.com/products/

siesta/, dostopano 1.11.2021.

[13] Buildbot. Buildbot, 2021. http://buildbot.net, dostopano 7.11.2021.

[14] GitLab B.V. Gitlab, 2021. https://about.gitlab.com, dostopano 7.11.2021.

[15] CI Software. Comparison of continuous integration software, 2021.

https://en.wikipedia.org/wiki/Comparison_of_continuous_

integration_software, dostopano 1.11.2021.

[16] CloudBees. Jenkins, 2021. https://www.jenkins.io, dostopano 7.11.2021.

[17] CloudBees. Jenkins docker image, 2021. https://hub.docker.com/r/

jenkins/jenkins, dostopano 7.11.2021.

[18] Software Freedom Conservancy. Selenium, 2021. https://www.

selenium.dev, dostopano 5.2.2022.

[19] Containers. Podman, 2021. https://podman.io, dostopano 16.1.2022.

[20] Docker. Docker, 2021. https://www.docker.com, dostopano 16.1.2022.

[21] Docker. Node.js, 2021. https://docs.docker.com/compose/, dosto- pano 26.1.2022.

(49)

Diplomska naloga 35 [22] Facebook. Jest, 2021. https://jestjs.io, dostopano 1.11.2021.

[23] International Organization for Standardization. Information techno- logy — programming languages — c, 2001. https://www.iso.org/

standard/74528.html, dostopano 17.1.2022.

[24] Eclipse Foundation. Jakarta ee, 2021. https://jakarta.ee, dostopano 17.1.2022.

[25] OpenJS Foundation. Node.js, 2014. https://nodejs.org/en/, dosto- pano 23.1.2022.

[26] Martin Fowler. Continuous integration, 2006. https://martinfowler.

com/articles/continuousIntegration.html/, dostopano 16.1.2022.

[27] Inc. GitHub. About github, 2022. https://github.com/about/, do- stopano 17.1.2022.

[28] Google. Angular, 2019. https://opensource.google/projects/

angular, dostopano 17.1.2022.

[29] Google. Angular - the modern web developer’s platform, 2021. https:

//angular.io, dostopano 16.1.2022.

[30] Google. Protractor, 2021. http://www.protractortest.org/, dosto- pano 1.11.2021.

[31] Harness. Harness acquires continuous integration pioneer drone.io and commits to open source, 2020. https://www.prnewswire.com/news- releases/harness-acquires-continuous-integration-pioneer- droneio-and-commits-to-open-source-301106473.html, dostopano 18.1.2022.

[32] Harness Inc. Drone, 2020. https://www.drone.io, dostopano 7.11.2021.

(50)

36 Andraˇz Sterle [33] Jasmine. Jasmine, 2021. https://jasmine.github.io, dostopano

1.11.2021.

[34] Karma. Karma, 2021. https://karma-runner.github.io/latest/

index.html, dostopano 1.11.2021.

[35] Katalon. What is end-to-end (e2e) testing? all you need to know, 2021. https://www.katalon.com/resources-center/blog/end-to- end-e2e-testing/, dostopano 7.11.2021.

[36] Microsoft. What is typescript?, 2022. https://www.typescriptlang.

org, dostopano 17.1.2022.

[37] Mocha. Mocha, 2021. https://mochajs.org, dostopano 1.11.2021.

[38] Mockito. Mockito, 2021. https://site.mockito.org, dostopano 1.11.2021.

[39] Oracle. What is java technology and why do i need it?, 2021.

https://www.java.com/en/download/help/whatis_java.html, do- stopano 17.1.2022.

[40] Oracle. Oracle java, 2021. https://www.oracle.com/java/, dostopano 17.1.2022.

[41] Sten Pittet. What is continuous deployment?, 2021. https://www.

atlassian.com/continuous-delivery/continuous-deployment, do- stopano 16.1.2022.

[42] Pluralsight. Javascript, 2013. https://www.javascript.com, dosto- pano 17.1.2022.

[43] REST Assured. Rest assured, 2021. https://rest-assured.io, dosto- pano 1.11.2021.

[44] SmartBear Software. Gherkin reference, 2019. https://cucumber.io/

docs/gherkin/reference/, dostopano 23.1.2022.

(51)

Diplomska naloga 37 [45] SmartBear Software. Cucumber, 2021. https://cucumber.io, dosto-

pano 1.11.2021.

[46] Spring. Spring – rest controller, 2021. https://spring.io, dostopano 16.1.2022.

[47] SQLite. Sqlite, 2022. https://www.sqlite.org/index.html, dosto- pano 16.1.2022.

[48] The JUnit Team. Junit5, 2021. https://junit.org/junit5/, dosto- pano 1.11.2021.

[49] Gmbh Travis CI. Travis ci, 2021. https://github.com/travis-ci/

travis-ci/blob/master/README.md, dostopano 7.11.2021.

[50] webpack. webpack, 2020. https://webpack.js.org, dostopano 17.1.2022.

Reference

POVEZANI DOKUMENTI

Med elementi streˇ znika velja omeniti uporabo sistema za zajem zaslona PySide, navidezne tipkovnice virtkey in miˇske PyMouse, preusmerjanje prometa z obratnim posredniˇskim

Pri implementaciji simulacije učnega sistema v okolju so nam bili v veliko pomoč primeri izvornih kod za simulacijo vozička s palico, vmesnika med okoljem ter učnim

Koraki testiranja so: testiranje zahtev aplikacije, testiranje podatkovne zbirke, te- stiranje programskega vmesnika, testiranje vmesnika API po namestitvi na Heroku,

Za primerjavo testnih orodij smo razvili spletno aplikacijo, ki jo bomo upo- rabili za izdelavo in izvajanje avtomatiziranih testov v orodjih Selenium, Appium in Eggplant

zagotavljanje kakovosti, testiranje programske opreme, metode testiranja, pro- gramske reˇsitve po naroˇ

Reˇ sitve za oba primera, postavitev spletnega streˇ znika in spletnega oblaka, smo razvijali na navideznih raˇ cunalnikih.. Ustvarjali smo jih z orodjem Vagrant [15], ki je v

Proces validacije vključuje tudi testiranje delovanja sistema. Če je sistem obsežnejši, se testiranja izvajajo po posameznih modulih, ali po logično zaključenih delih sistema. Vedeti

Apple HomeKit je druˇ zina produktov za pametni dom. Za postavitev sistema potrebujemo Apple TV. Apple TV deluje kot centralna naprava, ki skrbi za nadzor celotnega sistema. Z Apple