testiranje programske opreme na osnovi orodij …
TRANSCRIPT
UNIVERZA V MARIBORU
FAKULTETA ZA ELEKTROTEHNIKO,
RAČUNALNIŠTVO IN INFORMATIKO
David Herman
TESTIRANJE PROGRAMSKE OPREME NA
OSNOVI ORODIJ MICROSOFT
Diplomsko delo
Maribor, avgust 2016
TESTIRANJE PROGRAMSKE OPREME NA OSNOVI
ORODIJ MICROSOFT
Diplomsko delo
Študent(ka): David Herman
Študijski program: Visokošolski študijski program
Informatika in tehnologije komuniciranja
Smer: Sistemska podpora informatiki in tehnologijam komuniciranja
Mentor(ica): doc. dr. Boštjan Šumak, univ. dipl. inž. rač. in inf.
Lektor(ica): Vlasta Povše
i
ZAHVALA
Iskreno se zahvaljujem mentorju doc. dr. Boštjanu
Šumaku za pomoč in vodenje pri opravljanju
diplomskega dela.
Posebna zahvala velja staršem, ki so mi omogočili
študij.
ii
Testiranje programske opreme na osnovi orodij microsoft
Ključne besede: testiranje programske opreme, faze in življenjski cikel testiranja, V-model
testiranja, orodja za testiranje, Visual Studio 2013.
UDK: 004.4.052: 004.4'2(043.2)
Povzetek
Predstavili smo pomen testiranja programske opreme ter prikazali, kako uspešno testirati
programsko opremo skozi njen razvojni življenjski cikel in kaj dosežemo z uspešnim
testiranjem. V drugem delu diplomske naloge smo predstavili orodja in tipe testiranja ki so na
voljo v Visual Studio 2013. Na kratko smo opisali delo s testnimi rezultati in zaključek
testiranja. V zadnjem delu smo prikazali praktično uporabnost orodij za testiranje Visual
Studia 2013 po tehniki V-modela, ki je zasnovan tako, da se proces testiranja začne v
zgodnjem razvoju programske opreme, in zapisali ugotovitve. Končni rezultat je strnjen opis
in predstavitev orodij ter tipov za testiranje programske opreme, ki jih nudi Visual Studio
2013, ter praktična uporaba pri testiranju.
iii
Testing Software based on Microsoft tools
Ključne besede: software testing, phase and life cycle testing, V-model technique, testing
tools, Visual Studio 2013.
UDK: 004.4.052: 004.4'2(043.2)
Abstract
We presented the meaning of software testing, we showed how successfully test software
throughout its development life cycle and what is achieved with the successful testing. In the
second part of the diploma thesis we presented testing tools and types that are available in
Visual Studio 2013.We briefly described the work with testing results and the completion of
testing. In the last part, we showed the practical usefulness of the testing tools of Visual
Studio 2013 using V-model technique, which is designed on such a way that the testing
process begins early in the software development and then we wrote down the findings. The
end result is a compact description and presentation of tools and types of software testing
provided by Visual Studio 2013 and also the practical application use in testing.
iv
VSEBINA
1 Uvod ................................................................................................................................... 1
2 Pomen testiranja programske opreme ................................................................................ 3
2.1 Definicija testiranja .................................................................................................... 3
2.2 Definicija: Pomote (Error), izpada (falut), odpoved i(failure) in napake ................... 4
2.3 Pomen testiranja programske opreme ........................................................................ 5
2.4 Zgodovina testiranja ................................................................................................... 8
2.5 Razlogi za napake v programski opremi .................................................................... 9
2.6 Vloge in osebe pri testiranju ..................................................................................... 11
2.7 Pristopi učinkovitega testiranja ................................................................................ 13
2.8 Testno okolje ............................................................................................................ 15
2.9 Začetek testiranja ...................................................................................................... 16
2.10 Zaključek testiranja .................................................................................................. 16
3 Faze in življenjski cikel testiranja .................................................................................... 17
3.1 V-model testiranja .................................................................................................... 17
3.1.1 Faze verifikacije ................................................................................................. 20
3.1.2 Faze validacije .................................................................................................... 21
3.1.2.1 Testiranje komponente/enote ...................................................................... 21
3.1.2.2 Integracijsko testiranje ................................................................................ 22
3.1.2.3 Sistemsko testiranje .................................................................................... 23
3.1.2.4 Testiranje sprejemljivosti ............................................................................ 24
3.1.3 Iterativni življenjski cikli ................................................................................... 26
3.1.4 Prednosti in slabosti V-modela........................................................................... 27
3.1.5 Dodatne faze V-modela ...................................................................................... 27
4 Testiranje programske opreme v orodju Visual Studio 2013 ........................................... 29
4.1 Upravljanje življenjskega cikla aplikacije (ALM) ................................................... 29
4.2 Orodja za Testiranje programske opreme v orodju Visual Studio 2013 ................... 31
v
4.3 Postavitev testnega okolja ........................................................................................ 33
4.4 Skupina projektov v orodju TFS .............................................................................. 36
4.4.1 Logična definicija skupine projektov ................................................................. 36
4.4.2 Fizična definicija skupine projektov .................................................................. 37
4.5 Testiranje po testnem načrtu ..................................................................................... 40
5 Tipi testiranja v orodju Visual Studio 2013 ...................................................................... 45
5.1 Avtomatsko testiranje ............................................................................................... 48
5.1.1 Spletno testiranje ................................................................................................ 49
5.1.2 Zmogljivostni test ............................................................................................... 51
5.1.2.1 Cloud-based load testiranje ......................................................................... 52
5.1.3 Kodirano testiranje UI ........................................................................................ 52
5.1.3.1 Kodiran UI test za Windows Store aplikacijo ............................................. 53
5.1.4 Sekvenčno testiranje ........................................................................................... 54
5.1.5 Generično testiranje ............................................................................................ 54
5.1.6 Testiranje enote ................................................................................................... 54
5.1.6.1 Testiranje enote z orodjem Visual Studio .................................................... 55
5.1.6.2 Pisanje učinkovitih testov ........................................................................... 56
5.1.6.3 Testiranje enote za Windows Store aplikacije ............................................. 56
5.2 Ročno testiranje ........................................................................................................ 57
5.2.1 Microsoft Test Manager ..................................................................................... 58
5.2.1.1 Načrtovanje testa ......................................................................................... 58
5.2.1.2 Integracija gradnikov .................................................................................. 59
5.2.2 Team Web Access ............................................................................................... 60
5.2.3 Razlika med Microsoft Test Manager in Team Web Access .............................. 61
5.2.4 Test Runner......................................................................................................... 61
5.2.5 Testiranje Windows Store aplikacij .................................................................... 62
5.2.6 Raziskovalno testiranje ...................................................................................... 62
5.3 Dodatki za diagnostiko podatkov ............................................................................. 64
vi
6 Uporaba testnih orodij Visual Studio 2013 v praksi ......................................................... 66
6.1 Testiranje v okviru življenjskega cikla programske opreme .................................... 66
6.2 Testiranje z orodji Visual Studio 2013 po V-modelu ............................................... 66
6.2.1 Infrastruktura testnega okolja ............................................................................. 66
6.2.2 Strojna oprema pri postavitvi infrastrukture ...................................................... 68
6.2.2.1 Komponente infrastrukture ......................................................................... 69
6.2.2.2 Lab Manager in virtualizacija ..................................................................... 71
6.2.2.3 Ekonomična postavitev virtualizacije ......................................................... 73
6.2.3 Kreiranje in nastavitev skupine projektov .......................................................... 75
6.3 Priprava testne dokumentacije ................................................................................. 79
6.3.1 Uporaba testnih načrtov in garnitur .................................................................... 85
6.4 Testiranje aplikacije .................................................................................................. 86
6.5 Osebe in vloge pri testiranju ..................................................................................... 87
6.6 Prednosti testiranja po tem postopku ....................................................................... 89
7 Sklep ................................................................................................................................. 90
8 Viri in literatura ................................................................................................................ 92
KAZALO SLIK
Slika 1: Stroški testiranja [2] ...................................................................................................... 7
Slika 2: Waterfall model [6] ..................................................................................................... 18
Slika 3: V-model [11] ............................................................................................................... 20
Slika 4: Iterativni razvojni model [11] ..................................................................................... 26
Slika 5: Izdelava nove skupine projekta z uporabo orodja Team Explorer .............................. 37
Slika 6: Izbira predloge procesa ............................................................................................... 38
Slika 7: Vozlišča skupine projekta ............................................................................................ 39
Slika 8: Testni načrt .................................................................................................................. 43
Slika 9: Struktura testnega načrta v orodju MTM [42] ............................................................ 44
Slika 10: Dodajanje testnega tipa ............................................................................................. 48
Slika 11: Prikaz scenarija z več uporabniki, ki dostopajo do spletne strani z uporabo različnih
omrežij, brskalnikov in lokacij [13] ......................................................................................... 51
vii
Slika 12: Shema ročnega testiranja [12] ................................................................................... 57
Slika 13: Raziskovalno testiranje v orodju MTM 2013 [13] ................................................... 63
Slika 14: Komponente infrastrukture ....................................................................................... 69
Slika 15: Ekonomična postavitev virtualizacije ....................................................................... 73
Slika 16: Določitev imena in opisa zbirke skupine projekta, ................................................... 75
Slika 17: Določitev podatkovnega sloja ................................................................................... 76
Slika 18: Preverjanje ustreznosti zbirke skupine projekta pred njeno izdelavo ....................... 76
Slika 19: Proces izdelave zbirke skupine projekta ................................................................... 77
Slika 20: Začetna faza izdelave skupine projekta .................................................................... 77
Slika 21: Določitev imena in opisa skupine projekta ............................................................... 78
Slika 22: Izbira predloge procesa ............................................................................................. 78
Slika 23: Določitev sistema za nadzor nad verzijami .............................................................. 79
Slika 24: Skupina projekta v Team Explorer ............................................................................ 79
Slika 25: Osnovna zgradba V-modela ...................................................................................... 81
Slika 26: Dodajanje testnega načrta v orodju MTM ................................................................ 82
Slika 27: Konfiguracija testnega načrta ................................................................................... 82
Slika 28: Dodajanje testnega primera v privzeto testno garnituro ........................................... 83
Slika 29: Dodajanje zahtev testnemu načrtu ............................................................................ 83
Slika 30: Testni koraki testnega primera .................................................................................. 84
Slika 31: Povezava med privzetimi konfiguracijami in testnimi primeri ................................. 84
Slika 32: Izvajanje testnih korakov z orodjem Test Runner ..................................................... 85
Slika 33: Uporaba testnih tipov skozi faze testiranja ............................................................... 86
KAZALO TABEL
Tabela 1: Prednosti in slabosti V-modela [31] ......................................................................... 27
Tabela 2: ALM programske garniture [36] ............................................................................... 30
Tabela 3: Naštete lastnosti po izdajah orodja Visual Studio 2013 [13] .................................... 47
Tabela 4: Podprti testni tipi v Visual Studio 2013 [12] ............................................................ 48
Tabela 5: Uporabljena in primerna orodja za postavitev infrastrukture ................................... 67
viii
UPORABLJENE KRATICE
ISTQB - International Software Testing Qualifications Board
IEEE - Institute of Electrical and Electronics Engineers
V & V – Verifikacija in Validacija
QA - Quality Assurance
Y2K – Year 2000
RAD - Rapid Application Development
ISO - International Organization for Standardization
IT – Information Technology
dll - dynamic link library
ALM – Application Lifecycle Management
TDD – Test Driven Development
IDE - Integrated Development Environment
UI – User Interface
TFS – Team Faundation Server
MSF - Microsoft Solutions Framework
CMMI - Capability Maturity Model Integration
MTM – Microsoft Test Manager
API – Application programming interface
UI – User Interface
TWA – Team Web Access
LLD – Low Level Design
XP – Extreme Programming
TDD - Test-Driven Development
SRS - Software Requirements Specification
COTS - Commercial Off The Shelf
CPU - Central Processing Unit
RAM -Random Access Memory
VMs – Visrtual Machines
SCVMM - System Center Virtual Machine Manager
URI - Uniform Resource Identifier
PBIs – Product Backlog Items
SDET - Software Development Environment Throughput (SDET)
1
1 Uvod
V zadnjem desetletju so se v revijah pojavile številne spektakularne zgodbe o odpovedi
računalniške programske opreme. Kljub vidnim lekcijam o posledicah slabe programske
opreme so se napake še vedno pojavljale na prvih straneh časopisov. Ti neuspehi stanejo
ameriško gospodarstvo približno 59,5 biljona evra na leto. [1] Z ustreznim vodenim
testiranjem po fazah razvoja programske opreme bi lahko prihranili približno 22,2 biljona
evra letnih izgub. Skozi čas je nastala knjiga »Software Testing: Testing Across the Entire
Software Development Life Cycle«, ki predstavlja prvo celovito obravnavanje vseh testnih
dejavnosti v 21. stoletju, vse od načrtovanja testiranja in do zaključka vsake faze programske
opreme v okviru razvoja in revizije.
Testiranje programske opreme je ena najpomembnejših faz v razvoju programske opreme.
Kvaliteta programske opreme se meri z validacijo in verifikacijo programske opreme glede na
določene funkcije, ki jih programska oprema mora ali ne sme zajemati. Kvalitetno testiranje
lahko znatno zmanjša stroške pri razvoju programske opreme in celo izboljša njeno
zmogljivost.
Na trgu obstajajo različna orodja, ki pokrivajo večino opravil, ki se nanašajo na testiranje
programske opreme. Napredna orodja za testiranje programske opreme lahko povečajo
vrednost programske opreme na različne načine: zmanjšajo stroške pri razvoju in testiranju
programske opreme, zmanjšajo zahtevan čas za razvoj nove programske opreme, izboljšajo
učinkovitost in skladnost programske opreme.
Vendar učinkovito in moderno orodje za testiranje ni edini faktor pri zagotavljanju kvalitetne
in dobro testirane programske opreme. Največja odgovornost leži na načrtovanju testiranja.
Testiranje ne sme biti več ločena aktivnost. Testiranje je proces, ki se mora začeti takoj, ko so
določene zahteve programske opreme, in se mora nadaljevati vzporedno z razvojem
programske opreme. Raziskave so pokazale, da se v večini primerov uspešno in pravočasno
zagotovi kvaliteto programske opreme, če se v fazi zajemanja zahtev programske opreme
opravi 40 % delež celotnega testiranja, ki zajema podrobno dokumentacijo načrtovanja
testiranja in načrtovanja testnih primerov. [46] Vendar se ta tehnika testiranja v praksi še
2
vedno zelo redko uporablja, ker zahteva čas in znanje za načrtovanje testiranja. Še vedno je
praksa, da se programska oprema testira v fazi testiranja, po končanem kodiranju, kar je
razlog, da se programska oprema ne konča v roku in z zagotovljeno kvaliteto.
Cilj diplomske naloge je predstaviti pomen testiranja programske opreme, kako uspešno
testiramo programsko opremo skozi njen razvojni življenjski cikel in kaj dosežemo z
uspešnim testiranjem. V drugem delu bomo predstavili orodja in tipe testiranja, ki so na voljo
v orodju Visual Studio 2013. Podrobno bomo predstavili orodja in njihov namen ter tipe
testiranja in kaj lahko s posameznim tipom testiranja v programski opremi testiramo. Na
kratko bomo opisali delo s testnimi rezultati in zaključek testiranja. V zadnjem delu bomo
prikazali praktično uporabnost orodij za testiranje v Visual Studio 2013 na primeru testiranja
po tehniki V-modela, ki je zasnovan tako, da se proces testiranja začne v zgodnjem razvoju
programske opreme, in zapisali ugotovitve. Končni rezultat je strnjen opis in predstavitev
orodij ter tipov za testiranje programske opreme, ki jih nudi Visual Studio 2013.
3
2 Pomen testiranja programske opreme
2.1 Definicija testiranja
Ideja testiranja je v iskanju napak, vendar je pojem testiranja zelo razširjen, zato je testiranje
natančneje razloženo s standardi. V nadaljevanju bomo bolj nazorno predstavili definicijo
testiranja s standardi [54]:
• Testiranje je proces operacijskega sistema ali komponente z določenimi omejitvami,
pri katerem z opazovanjem in snemanjem rezultatov ocenimo vidik sistema oz.
komponente (Standard IEEE 610 [Programsko inženirska terminologija]).
• Testiranje je proces, ki z analizo programske opreme odkrije razliko med obstoječimi
in zahtevanimi pogoji (napake), s katerimi ovrednotimo značilnosti programske
opreme (Standard IEEE 829 [Testna dokumentacija]).
• Testiranje je proces, ki s preverjanjem programske opreme ugotavlja skladnost z
zahtevami (Standard BS 7925-1 [Testiranje programske opreme – slovar]).
• Testiranje je proces, sestavljen iz vseh dejavnosti življenjskega cikla, tako statičnega
in dinamičnega, ki se ukvarja z načrtovanjem, pripravo in vrednotenjem programske
opreme ter z drugimi podobnimi izdelki, ki ugotavljajo skladnost programske opreme
z zahtevami in s tem dokažejo, da so primerni za iskanje napak (Standard ISTQB).
Zgoraj opisane definicije procesa testiranja imajo skupen izraz »proces«, kar pomeni, da je
testiranje proces. Torej, kaj naj bi beseda proces pomenila? Standarda IEEE 610 in BS 7925
omenjata »upravljanje« in »preverjanje« programske opreme, kar pomeni, da testiranje
zahteva programsko opremo, ki teče na računalniku – temu pristopu pravimo dinamično
testiranje. Ideja standarda IEEE 829 omenja »analizo« in »statično testiranje« programske
opreme, prav tako standard ISTQB omenja izraz statičnega in dinamičnega testiranja. Pojavi
se vprašanje, kdaj nastopi dinamično in statično testiranje. [55]
Po definiciji se objekt testiranja giblje od sistema ali komponente, postavke programske
opreme in programske opreme do produkta programske opreme in podobnim produkov v
delu. Vzporedno s testiranjem, tako dinamičnim kot statičnim, moramo zaključiti sledeče:
Testiranje se lahko izvaja na kateremkoli produktu v izvedbi ali produktu (kjer razlika med
njima pomeni, da produkt v izvedbi še ni dostavljen do naročnika). [1] In nenazadnje si
postavimo še vprašanje: »Zakaj?« Podani razlogi vključujejo opazovanje, ovrednotenje,
4
zaznavanje hroščev/napak, potrditev/določitev zadovoljstva, demonstriranje ali služenje
svojemu namenu. Iz tega lahko zaključimo, da testiranje zbira informacije o kvaliteti objekta,
ki ga testiramo. Kvaliteta je skupek izpolnjenih pričakovanj. Na eni strani imamo določena
pričakovanja in na drugi strani imamo produkt, ki mora zadovoljiti tem pričakovanjem.
Vprašanje je: Ali izpolnjuje naša pričakovanja? Testiramo zato, da lahko odgovorimo na to
vprašanje [1].
2.2 Definicija: Pomote (Error), izpada (falut), odpoved i(failure) in napake
Ključ do izdelave kakovostne programske opreme je zamisel oziroma koncept pomote,
izpada, odpovedi in napake. Termin napaka se nanaša na določen problem, ki je lahko zunanja
ali notranja lastnost programske opreme. Definicija terminov, ki se navezujejo na pojem
napaka [53]:
• Odpoved: pomeni nezmožnost sistema, da opravi zahtevane funkcije, navedene znotraj
zmogljivostnih zahtev.
• Izpad: je nepravilen korak, proces oziroma nepravilna definicija podatkov programske
opreme.
• Pomota: je človeško dejanje, ki povzroči napačen rezultat.
Termin odpoved se torej nanaša na vedenja, ki odstopajo od zahtev uporabnika ali
specifikacij. Termin izpad temelji na osnovnem stanju znotraj programske opreme, ki
povzroči določeno napako, medtem ko pomota vsebuje manjkajoča ali napačna človeška
dejanja, ki povzročajo napake, ki so integrirane v programsko opremo. Napako lahko
razširimo glede na njen izvor ali glede na nepravilne ali manjkajoče akcije zaradi človeških
napačnih predstav oziroma nerazumevanj. Odpoved, izpad in pomota se navezujejo na pojem
napaka, ta pa se navezuje na pojem hrošč (bug), ki pa ni natančno definiran, kot so nekateri
vidiki napake (odpoved, izpad, pomota). Nekateri ljudje so razvili moralni ali filozofski očitek
do pomena napake in so si ga razlagali kot izmikanje odgovornosti nekaterih ljudi. Obstaja
tudi termin razhroščevati, ki dejansko pomeni »znebiti se hroščev«. Razhroščevanje vsebuje
tudi dejavnike, kot so iskanje in rokovanje s hrošči (napakami). [2]
5
2.3 Pomen testiranja programske opreme
Vsak dan se srečujemo z različnimi novicami o izgredih in varnostnih luknjah programske
opreme, kot so: banka izdela nepravilna poročila knjigovodskih stanj, vesoljska kupola, ki je
potovala na Mars, se je izgubila, nepravilno delovanje optičnega čitalnika v trgovini z živili,
potem heker, ki pridobiva dostop do številnih številk kreditnih kartic. Zakaj se vse to dogaja?
Ali si programerji ne morejo izmisliti način, ki bi omogočal večjo varnost programske opreme
pred vdori z nepooblaščenimi dostopi? Na žalost ne. Ko začne postajati programska oprema
vse bolj kompleksna jo je zelo težko implementirati brez napake. Ne glede na to, kako je
programer sposoben in koliko je vložil v program, se bo še vedno našla napaka v programu,
zato pa v takšnih primerih prevzame vlogo testiranje programske opreme. [3]
Testiranje programske opreme je zelo pomembno področje; v tej fazi vedno odkrijemo najbolj
nevarne napake, saj v fazi vzdrževanja postane popravilo teh zelo drago. Pri večjih in
donosnejših razvojnih projektih se testiranje pogosto izvaja v ločenem projektu, v takšnem
primeru se projekt razdeli na dva dela, neodvisno verifikacijo in validacijo (V & V). V & V
imata zelo veliko vlogo pri odkrivanju napak v fazah življenjskega cikla razvoja, ki pa se
odpravijo takoj po odkritju. Z ločitvijo testiranja v ločen projekt izboljšamo zanesljivost
programske opreme. [4]
Nekateri izzivi testiranja programske opreme vsebujejo številne napake, ki pa povečajo pritisk
na testerje, kar posledično povzroči luknje v testni strategiji, v testnem načrtu itd. Testiranje
programske opreme je skozi leta postajalo pomembno, saj stranke oz. uporabniki pričakujejo,
da bo njihov program čim bolj kakovostno izdelan. [4]
Najpogosteje se napake pojavijo znotraj zahtev, pri načrtovanju programa in kodiranja
programske opreme, zato je namen testiranja poiskati in odpraviti te napake. Sistem
programske opreme lahko vsebuje številne napake, ki jih je zelo težko odkriti in odpraviti.
Četudi bi imeli večjo skupino testerjev, bi za ta podvig potrebovali precej časa, da bi odkrili in
odpravili delež prisotnih napak v sistemu. Takšen pristop testiranja ni dovolj uporaben, saj
ima ekipa prodaje določen rok za izdajo izdelka na trg. Tudi v primeru, če izdelujemo
programsko opremo za organizacijo, moramo program pravočasno testirati, saj ga bo kmalu
rabila. Poleg tega bodo stroški pri večjem časovnem naporu testiranja postali preobsežni, kar
pa ni sprejemljivo. [4]
Najbolj učinkovit pristop testiranja je učinkovito testiranje, kjer ima vsaka aktivnost rok
izvedbe in raven kakovosti, ki je sprejemljiva za kupce, zato mora biti med kakovostjo in
6
časovno omejitvijo uravnovešenost. Npr.: imamo vnaprej določen urnik, ki traja 15 dni za
testiranje stopnje kakovosti programske opreme, a smo ugotovili, da ima program čez 100
napak, ki jih je potrebno popraviti preden gre v živo. [4]
Prioriteta testiranja je določena glede na potrebe projekta. Nekatere zahteve so vrednotene z
visoko prioriteto, nekatere pa z nižjo. Zahteve z visoko prioriteto so najprej testirane, tako da
so napake odpravljene, preden se nam izteče določen čas testiranja. V tem primeru zahteve z
nizko prioriteto po vsej verjetnosti ne bodo prišle do testiranja, vendar bo vpliv na projekt
veliko manjši, kot pa če ne bi bile testirane zahteve z visoko prioriteto. Zelo podobno je pri
testiranju sistema, v tej fazi mora testna ekipa dobro poznati zasnovo in arhitekturo programa,
da bo lahko učinkovito testirala. Testna ekipa bo učinkovito testirala le v primeru, če se bo
pravočasno vključila v življenjski cikel razvoja programske opreme. [4]
Testiranje mora zagotoviti brezhibno delovanje programske opreme, ki jo bodo uporabljali
končni uporabniki ali stranke. Namen testiranja je zagotovitev delovanja programa brez
napake. Z izvajanjem programske opreme ali komponente dokažemo delovanje programa v
skladu s pričakovanji. Zato prikaz pravilnega delovanja programa je glavni namen testiranja,
saj s tem dokažemo kakovost oziroma zadane cilje kakovosti programa. Sčasoma je prioriteta
testiranja postala odkrivanje in odpravljanje napak, s tem sta dejavnika zatrla kakovost
programa, ki pa je različnim organizacijam in ljudem primarni namen. Testiranje izpolnjuje
dva glavna namena [2]:
• Odkriti in odpraviti napake.
• Predstavitev kvalitete oziroma pravilnega delovanja programa.
Napaka, prisotna v programski opremi, lahko organizaciji povzroči škodo v višini več
milijonov evrov, če pa je napaka manjša in se jo da rešiti v času življenjskega cikla
programske opreme, je strošek občutno manjši in vodi v nekaj tisoč evrov. [5]
Recimo: vsako četrtletje izdamo programsko opremo, ki vsebuje 500 napak, ki jih je potrebno
odpraviti. Strošek za popravilo vsake napake v fazi razvoja je 100 €, v fazi testiranja 500 € in
v fazi predaje končnemu uporabniku 2500 €. Analize v podjetju prikazujejo, da 25 % napak
odkrije programer, 50 % napak odkrije povprečno izobražen tester, ostalih 25 % pa končni
uporabnik. Predpostavimo, da organizacija, ki je razvijala programsko opremo, ni imela testne
skupine, potem 75 % napak odkrije končni uporabnik, ostalih 25 % pa odkrije in odpravi
razvijalec. V takšnem položaju stroški odpravljanja napak narastejo na 887,500 € (12,500 € +
875,000 €). Recimo, da zaposlimo tri testerje, ki jim na uro plačamo 50 €, kar pomeni, da nam
7
zavzamejo 495,500 € (12,500 € + €108,000 € + €375,000 €) predvidenih stroškov na
četrtletje. [5]
Stroški odkrivanja in odpravljanja napak precej narastejo skozi življenjski cikel razvoja
programske opreme. Če je napaka storjena in je odkrita v fazi izdelave zahtev, potem je
napako odkriti in odpraviti relativno poceni. Spodnja slika prikazuje (Slika 1), kako stroški
naraščajo v odvisnosti od časa, kdaj je bila napaka odkrita in odpravljena. [2]
Slika 1: Stroški testiranja [2]
Testiranje je eden izmed najpomembnejših delov Quality Assurance (QA) in pogosto izvaja
QA. Kakovostna programska oprema je običajno brez napake in je pravočasno končana v
meji proračuna, izpolnjuje vse zahteve, izpolnjuje pričakovanja in jo je enostavno vzdrževati.
Kakovost programske opreme je odvisna od stranke in njenega sodelovanja skozi celoten
projekt, saj jo bodo uporabljali številni uporabniki v njeni organizaciji. Vsaka stranka ima
svoj kriterij določanja in merjenja kakovosti programske opreme; npr.: računovodska
organizacija določi kakovost v smislu donosnosti naložbe, medtem ko lahko uporabnik vidi
8
kakovost v drugačni smeri in mu je pomembna brezhibnost ter uporabniška prijaznost
programa. [5]
Programska oprema mora biti testirana tako, da bo brezhibno in z zaupanjem delovala na
predvidenem okolju. Kadar izvajamo večje število testov moramo testirati učinkovito, hitro,
uspešno ter čim bolj ugodno. [6]
Zelo pogoste so napake odkrite v zaključni fazi projekta, a zaradi prevelikih stroškov v večini
primerov niso odpravljene. Velikokrat se zgodi, da potrebe zadostujejo opredeljenim
specifikacijam, vendar pa so te velikokrat nepravilno zasnovane, kar povzroči nezadovoljstvo
končnega uporabnika s programsko opremo. V nekaterih primerih je napaka tako velika, da je
potrebno programsko opremo popolnoma prenoviti. [11]
2.4 Zgodovina testiranja
Kvaliteta programske opreme v letih od 1950 do 1960 je bila zelo slaba, saj ni obstajal noben
formalni razvojni in testni proces. V tem času je obstajalo le testiranje z razhroščevalnikom, ki
so ga uporabljali razvijalci v primeru zaustavitve programa in odpravljanju napak na licu
mesta. Med letoma 1960 in 1970 se je začelo graditi vse več aplikacij. Podaljšala se je
življenjska doba aplikacije s številnimi popravki in izboljšavami, ki so omogočili njeno
stabilnost ter zanesljivost. Na podlagi teh dveh dogodkov so se začeli uveljavljati testerji.
Stranke so skozi čas želele imeti zanesljivo in trdno programsko opremo. Pričakovanja strank
za kakovostno programsko opremo je začelo naraščati, zato so razvijalci začeli preiskovati in
izboljševati razvojne procese, tako da se čas razvojne dobe programske opreme zmanjšali in s
tem dosegli stabilnost in zanesljivost sistema.[7]
Med letoma 1970 in 1980 so razvijalci usvojili uspešno razvojno prakso, ki naj bi zagotovila
ponovljivo stopnjo zanesljivosti in stabilnosti programske opreme. Vendar ta razvojna praksa
ni ustrezala potrebam strank, nakar so prišli do spoznanja, da je manjkajoči del prakse
testiranje programske opreme. Ta proces se je uveljavil kot nova panoga v večjih
organizacijah z večjim številom zaposlenih. Proces testiranja se je začel uveljavljati šele po
letu 1990, ko je leta 2000 Damoklejev meč ogrozil preživetje računalniške panoge. Po tem
dogodku je testiranje v 21. stoletju postalo ključen dejavnik za testiranje odbitih programskih
oprem. Na stotine milijard evrov je bilo porabljenih, da bi zmanjšali morebitne poslovne
9
katastrofe, ki so jih povzročile kratice datumov. Vendar kratice programom niso omogočile,
da so lahko pravilno procesirali datum po prvemu januarju leta 2000 ali »Y2K« v domačem
jeziku. Avtorji menijo, da si vse zasluge za odkritje napake zasluži strokovna skupnost
testiranja za datum, 1 januar 2000. Kaj bi se zgodilo če intervencije ne bi bilo? Na prehod
tisočletja so opominjala tudi podjetja, nakar je vodstvo nekako priredilo stroške testiranja in
dalo na znanje, da je bil produkt »Y2K« dobro testiran. Kasneje je vodstvo spoznalo, da za
učinkovito poslovanje v 21. stoletju potrebujejo dobre testerje in testne procese. [7]
Pred razcvetom interneta so se leta 1990 razmnožila številna podjetja s programsko opremo,
kar je načelo veliko konkurenco med njimi. Posledica vsega tega je bilo zvišanje cen,
programske opreme so postajale vse bolj učinkovite in kakovostne itd. Zaradi vseh teh
sprememb, ki so se zgodile, je prevzelo glavno vlogo v programski opremi testiranje.
Arhitektura programskih sistemov, aplikacij, ki temeljijo na podlagi, interneta se razlikujejo
od starih glavnih ogrodjih oziroma strežniških aplikacij klienta, prav tako se je spremenila
metodologija za razvoj programske opreme. Novi razvojni model programske opreme se
imenuje agilno razvijanje ali ekstremno programiranje. Spremenil je vidik vodenja projektov
programske opreme in vplival tudi na testiranje. Tovrstna testiranja zahtevajo ponavljajoče in
postopne pristope testiranja. Pri testiranju testna ekipa ne uporablja samo metode črne skrinje
in druge pristope testiranja, ampak pri večini svojih dejavnosti uporabijo regresijsko
testiranje, ki se uporabi takrat ko dodamo novo funkcionalnost že obstoječi programski
opremi. Številni ponudniki testnih orodij so olajšali delo testnim inženirjem, tako da jim ni
potrebno izdelovati opravila ročno, ampak jih lahko izdelajo avtomatsko. [5]
2.5 Razlogi za napake v programski opremi
V tem poglavju bomo predstavili seznam vzrokov, zaradi katerih se pojavljajo napake v
programski opremi:
• Napačna komunikacija ali ne-komunikacija - specifikacije ali zahteve programske
opreme pogosto niso razumljive projektni skupini zaradi napačne komunikacije ali
ne-komunikacije med njimi. [5]
• Pomanjkanje znanja članov tima ali sposobnost prilagajanja – situacijo, v kateri
nimajo člani tima potrebnih znanj za projekt, preprečimo tako, da uporabimo
mentorski pristop za manj izkušene zaposlene. Pristop aktivno usposobi osebo preko
10
notranjih in zunanjih poti. Dobrega rezultata ne pridobimo brez dovolj usposobljenih
ljudi. [33]
• Kompleksnost programske opreme – ker postajajo zahteve za razvoj programske
opreme vse bolj zapletene, postaja tudi programska oprema vse bolj kompleksna.
Širitev različnih vrst programskih oprem z različnimi ter preizkušenimi
tehnologijami lahko vodi do kompleksne aplikacije. Večnamenske aplikacije,
porazdeljene aplikacije, podatkovne komunikacije, ogromne relacijske baze in druge
večje aplikacije so prispevale k eksponentni rasti kompleksnosti sistema. [5]
• Programiranje napak – če programerji niso razumeli namen specifikacije ali pa so
naredili napako pri implementaciji, potem bo napaka definitivno nastala v
programski opremi. [5]
• Spreminjanje zahtev – v tej fazi pride največkrat do napake. Spreminjanje zahtev
pogosto zruši plan celotnega projekta od zasnove do izgradnje, testiranja ter razvoja.
V ekstremnih situacijah lahko celotno dokumentacijo ter izdelek zavržemo oziroma
opustimo. Po navadi se v zahtevah spremeni kakšen modul programske opreme, ki
pa je lahko pomemben in se navezuje na druge module. Ti dejavniki so posledica
nenamernih napak v programski opremi. [5]
• Preobremenitev virov – za nedotakljivo ter abstraktno programsko opremo težko
planiramo načrt projekta. Zaradi slabega planiranja velikokrat prihaja do
preobremenitve, ki je posledica napak programske opreme. Strokovnjaki za
načrtovanje programske opreme težko določijo skrajne roke; zaradi površnega dela
prihaja do številnih napak v programski opremi. [5]
• Pomanjkanje testiranja kakovosti – v večini projektov je v ospredju kodiranje in ne
testiranje. Zato se testiranje zavzema za večjo integriteto in vlogo v celotnem
razvoju programske opreme življenjskega cikla. [34]
• Nezanesljivi viri – za razvoj programske opreme potrebujemo usposobljene in
izkušene strokovnjake. Zaradi pomanjkanja znanja zaposlenih na trgu pogosto
prihaja do napak v programski opremi. [5]
• Neprofesionalni odnos – zelo pogosto se zgodi, da imajo strokovnjaki v skupini
projekta težave z odnosom do ostalih. Njihovi neprofesionalni odnosi se kažejo tako,
da pogosto vzamejo svojo nalogo kot enostavno, igrajo svojo pisarniško politiko,
pogosto se izognejo dodeljeni nalogi in jo preložijo na druge člane ekipe. Ta dejanja
11
ne povzročijo le problemov pri doseganju končnih rokov, ampak s takšnim odnosom
povzročijo še več napak v programski opremi. [5]
• Slabo definirana dokumentacija – je druga največja napaka programske opreme. Pri
majhnih projektih uporabljajo pristop ekstremnega ali agilnega programiranja, saj je
pri teh metodah manj dokumentacije, razvijajo se manjši projekti, ki so manj
kompleksni. V primeru večjih projektov mora ekipa obravnavati več funkcionalnosti
programa hkrati, kjer je program tudi kompleksnejši in obširen, zato je pri razvoju
obširnih oziroma kompleksnih sistemov pomembna dobro definirana
dokumentacija. Pri pomanjkljivi dokumentaciji lahko pride do napake v programski
opremi. Problemi se pojavijo tudi pri vzdrževanju celotnega sistema, ko ga predamo
v produkcijo. [5]
• Pomanjkljivo sodelovanje s končnim uporabnikom – če se med razvijanjem
programske opreme ne upošteva vidik uporabnika, potem definitivno iščemo težave.
Težava nastane pri iskanju napak in vključevanje uporabnikov k sodelovanju v
proces razvoja programske opreme. [34]
• Razvojna orodja – zaradi hitrega razvoja v poslovnem okolju projektne skupine
uporabljajo raznolika orodja, ki jim omogočajo povečati produktivnost v
organizaciji. Orodja, ki jih uporabljajo, so vizualna orodja, razne knjižnice,
prevajalniki, orodja za izdelavo skript, Rapid Application Development (RAD),
integrirana orodja itd. Vsako orodje ima svoje slabe lastnosti, ki zaradi slabe
dokumentacije še pripomore k napaki programa. [5]
2.6 Vloge in osebe pri testiranju
Testiranje je stroka, ki zahteva določene spretnosti in sposobnosti posameznih testnih
praktikov, prav tako vključuje ljudi z določenimi človeškimi lastnostmi oziroma tipi
osebnosti. Ljudje imamo osebnosti, ki jih je zelo težko spremeniti; rojeni smo s številnimi
karakteristikami, ki se oblikujejo od rojstva naprej. [8]
Številni poklici za izdelavo programske opreme zahtevajo napredne tehnične veščine, kot so
razvijalci programske opreme, razvijalci podatkovnih baz, razvijalci omrežja ter sistemski
administratorji. Najboljši testerji programske opreme morajo imeti vsa napredna znanja
poklicev, ki smo jih našteli. Testiranje in arhitektura programske opreme zahtevata veliko
12
strokovnega znanja. Testerji, ki nimajo tehničnega in naprednejšega znanja, bodo na višji
ravni zelo težko načrtovali, še težje pa izvajali kompleksne testne plane na končanem sistemu.
Kako izurjen tester pravilno uporabi široko tehnično znanje? Edinstvena in najpomembnejša
vloga testerja je preveriti programsko opremo. Tester ima objektiven pogled na programsko
opremo, je neodvisen od avtorjev razvojnih dokumentov in programske kode, kjer z
večkratnim testiranjem ugotovi skladnost programske opreme s specifikacijami in zahtevami.
Razvojna ekipa od testerja pričakuje poročilo, v katerega zapiše izpolnjene in manjkajoče
zahteve oziroma specifikacije. Testni rezultati morajo biti dovolj razumljivi, da razvijalci
hitreje izsledijo napako; ne pozabimo, da je za diagnozo in popravilo napake še vedno
odgovoren razvijalec. [7]
Katere vloge, poleg validacije programske opreme še ima tester? Strokovni odgovor je
načrtovanje, načrtovanje in načrtovanje. Testiranju vedno primanjkuje časa, osebja in opreme,
običajno tudi vse troje, zato mora glavni tester identificirati kritične točke programske
opreme, ki morajo biti testirane na učinkovit način. Kot pri večini projektov moramo te
odločitve opredeliti v načrtu in urniku testiranja, nato mora tester upravljati z načrtom in
urnikom do konca testiranja. [7]
V večjih (30 in več razvijalcev) podjetjih je v testiranje vključeno večje število ljudi. V
manjših podjetjih se lahko vloge prekrivajo. Naštete so vloge, ki se v večini primerov
najpogosteje uporabljajo [8]:
• Osebje stranke so ljudje, ki bodo uporabljali sistem. Pogosto nimajo stikov z razvijalci
zahvaljujoč združenim prizadevanjem uprave na strani stranke in uprave na strani
razvijalcev. In to zaradi tega, ker lahko stik s strankinim osebjem, razvijalcem razkrije,
kako malo uprava na strani stranke ve o tem, kaj osebje zares počne in celo postavi
pod vprašaj razlog za sistem. Uprava na strani razvijalcev ne želi, da razvijalci
razburjajo strankino upravo z obsodbenimi vprašanji, ki se začnejo s frazami, kot so:
»Kaj je smisel tega,...?« ali »Zakaj enostavno ne bi ...?« Osebje stranke je ključno tako
pri pisanju specifikacije zahtev kot pri preverjanju, da so deli sistema, ki izvajajo
interakcijo med človekom in računalnikom (uporabniški vmesnik) realistični in
delujoči.
• Stranka je oseba, ki financira projekt. Upoštevati moramo, da stranka dejansko nikoli
ne bo uporabljala produkta, zato morajo razvijalci in testerji imeti stik z osebjem
stranke.
13
• Razvijalci so uslužbenci, ki pišejo kodo in modele na nizki ravni. Pogosto razvijajo in
izvajajo teste enote za kodo, ki jo programirajo, če to drži, jih še vedno mora preveriti
tester. Razvijalec mora teste izdelati tako, da se še po odkritju napake lahko ponovno
izvedejo. Nadzorovati je potrebno odnose med testerji in razvijalci ter zagotoviti, da si
niso preveč blizu (kar bi lahko omajalo kriterije testiranja, še posebej, če napake ne
spadajo pod pravo klasifikacijo). Prav tako morajo nadomeščati podporo za
programsko opremo, če je ne more nihče drug.
• Vodja projekta je odgovoren za vidike projekta. Projektni vodja načrtuje projektni
načrt in načrt kakovosti, prav tako je odgovoren za kakovost in varnost projekta.
Pogosto je nadrejeni nad vodjo testerjev in ima določeno finančno avtoriteto pod
prisotnostjo vodje oddelka. Pri svojem delu mora biti zelo pozoren, da njegovo osebje
ne uporablja bližnjic do lažjih rešitev, vendar je pogosto pod pritiskom vodje oddelka
in se velikokrat uporabijo. Projektni vodja odobri sistem za uporabo.
• Vodja testerjev je odgovoren za izdelavo testne strategije in testnih načrtov oziroma
testnih delov načrta kakovosti. Pogosto je pod vodstvom vodje projekta in vodje
oddelka in njima poroča o vseh podrobnosti sistema. Vodja testerjev mora voditi testno
skupino tako, da sproti pregleduje testne rezultate projekta. Ima moč zavrniti odobritve
sistema.
• Testerji so odgovorni za kakovost rezultatov z navedbo, načrtovanjem, izvajanjem in
analiziranjem testov. Testerji so lahko tudi razvijalci, vendar niso odgovorni za razvoj
sistema oziroma komponent, ki se testirajo. Potrebujejo testne specifikacije, verzije in
pregledujejo pravilnost specifikacij. So pod vodstvom vodje testerjev in mu poročajo o
napredkih, lahko pa neposredno poročajo projektni vodji.
Odnos med razvijalci in testerji je neizogibno kontradiktoren, kar pomeni, da to ni slaba stvar,
saj razvijalci želijo sprogramirati delujoč sistem, na katerega testerji želijo prikazati
nepravilnosti sistema. Ključ do uspeha je potrpežljivost, smisel za humor, jasne opredelitve
odgovornosti, načrt in dobro osebje. [8]
2.7 Pristopi učinkovitega testiranja
Ta načela so zmes strokovnega testiranja iz izkušenj med letoma 1980 in 1990 ter Y2K
izkušnje. Na podlagi teh so nastala spodaj navedena načela testiranja programske opreme [7]:
14
• Poslovno tveganje je mogoče zmanjšati z iskanjem napak.
Vprašanje, ki ga bomo zastavili, pogosto nima odgovora. »Kakšni bodo stroški če programska
oprema ne bo delovala tako kot je bilo predvideno?« Zato moramo zgodaj v procesu
zagotoviti močno povezavo med iskanjem napak in odpravljanjem tveganj.
• Pozitivno in negativno testiranje prispeva k zmanjševanju tveganja.
Pozitivno testiranje preveri, ali programska oprema deluje tako, kot je načrtovana. Pri
negativnem testiranju je podobno, s tem da stranka ne more onemogočiti delovanje
programske opreme pod normalnimi poslovnimi okoliščinami. Tak pristop testiranja je
pogosto ločen od razvoja programske opreme, zato ker je bolj zamudno kot pozitivno
testiranje; zahteva več testerjev kot pri pozitivnem testiranju in ni očitno usmerjenih tveganj.
• Statično in zmogljivostno testiranje prispevata k zmanjšanju tveganja.
Prevladujoče testiranje programske opreme, ki se uporablja danes, vključuje izvedbo
programske kode znotraj razvoja. Funkcionalno, strukturno (nefunkcionalno) in
zmogljivostno testiranje mora izvesti programska koda, da je testiranje dokončano. Številne
testne skupine in organizacije so prišle do spoznanja, da nastane zelo veliko dokumentov v
času razvoja programske opreme, v katerih se lahko nahajajo napake. Če bi napake
pravočasno odkrili in odpravili, bi lahko zmanjšali število napak še pred kodiranjem
programske opreme. Logična ugotovitev je, da niti najboljši programerji organizacije ne
morejo ugnati slabih zahtev ali slabih specifikacij pri programiranju programa
• Avtomatski testi lahko prispevajo k zmanjšanju tveganja.
Sčasoma so postala naročila programske opreme kompleksnejša od starejših sistemov, zato so
nastala nova poslovna tveganja. Ta nova tveganja pogosto najdemo v območju delovanja, kjer
sta odzivni čas sistema in velika prostornina prepustnosti ključna za poslovni uspeh, zato ju je
nemogoče testirati ročno. Zmogljivostna testna orodja so precej draga. Zaradi slabo
izvedenega zmogljivostnega testa je lahko potencialni riziko presežen strošek orodja.
• Največja nevarnost ima primarno prioriteto testiranja.
Kadar imamo omejeno število testnega osebja, omejena testna orodja in omejen čas za
testiranje (večina projektov ga ima) je pomembno zagotoviti, da vsa omenjena sredstva
zajamejo najbolj kritična poslovna tveganja. Če testna sredstva ne morejo zajeti vseh kritičnih
poslovnih tveganj in nadaljujemo s testiranjem, bo stranka dobila napačne rezultate testiranja.
• Testiranje programske opreme v vlogi kupca oziroma uporabnika.
To načelo se zdi zelo intuitivno, ampak izkušnje kažejo na vsakoletne številne primere, da
aplikacija enostavno ni testirana z vidika stranke.
15
• Predpostavimo, da so napake posledica procesa in ne osebnosti.
Dobri razvijalci programske opreme pogostokrat občutijo lastništvo nad produktom, ki ga
razvijajo. Številni vidiki lastništva so lahko pozitivni in lahko motivirajo razvijalce k dobremu
delu oz. razvijanju. Obstaja vidik, ki prikazuje lastništvo kot negativno lastnost. Razvijalec
dobro pozna program in ga bo testiral po bližnjicah, medtem ko tester ne pozna programa in
se osredotoči samo na napake programske opreme.
• Iskanje napak je naložba in tudi strošek.
Vodstvo, direktorji in menedžerji so naravnani k temu, da je testiranje velik strošek, ter
pogosto postavljajo vprašanja kot so: »Koliko ljudi je potrebnih? Koliko tednov je še do
prekoračitve roka? Kakšna orodja potrebujemo ter koliko?« Strošek dejavnikov predstavlja
legitimni del celotne poslovne slike, vendar obstajajo prednosti, ki lahko nadomestijo stroške
testiranja in zmanjšajo poslovna tveganja. Nekatere prednosti so lahko uresničene med
potekom testnega projekta z inteligentno uporabo avtomatskih testnih orodij. Z
avtomatiziranim testnim orodjem zmanjšamo strošek v primerjavi z ročnim testiranjem.
Učinkovito testiranje lahko vpeljemo glede na prihodnje testne projekte s ponovno uporabo
testnih scenarijev in odkrivanjem napačnih vzorcev. Napisani, validirani in izvedeni testni
scenariji predstavljajo uporabne podatke za sistem. To konzervativno znanje lahko uporabimo
v starejših ali posodobljenih sistemih s podobnimi funkcionalnostmi. Ponovna uporaba testnih
skript na poznejših verzijah programa se imenuje regresijsko testiranje.
2.8 Testno okolje
Testno okolje je sestavljeno iz programske in strojne opreme, na katerem testna ekipa izvaja
teste na novo zgrajeni programski opremi. Ta konfiguracija je sestavljena iz logične
konfiguracije, ki vključuje strojno opremo, in fizične konfiguracije, ki vključuje strežniški
operacijski sistem, odjemalski operacijski sistem, podatkovni strežnik, končno okolje, ki teče
v ospredju, brskalnik ali katerokoli drugo programsko opremo, potrebno za funkcioniranje
izdelka oz. programske opreme. To testno konfiguracijo je potrebno graditi na obeh straneh –
torej na strežniški in odjemalčevi strani. [35]
16
2.9 Začetek testiranja
Vse pogosteje se testiranje obravnava kot zelo preprosta dejavnost, ki jo lahko vsakdo
opravlja brez načrtovanja, razporejanja in drugih virov. Testiranje predstavlja visoko
kvalificirano testno osebje, združeno v testno skupino, ki imajo dovoljenje do vodstva,
sredstev ter razporedov, ki so potrebna za načrtovanje in dokončanje testiranja. Testna ekipa
lahko kot katerakoli druga poslovna ekipa priskrbi testne rezultate pravočasno in v okviru
proračuna, to je samo v primeru, če se držijo pravil standardnih praks projektnega vodenja.
Prednost te ugotovitve je, da pri testiranju ni potrebno zadeti in ne zgrešiti, ampak lahko
testiranje načrtujemo in zaključimo z zaupanjem, da bomo dosegli cilje projekta. Iz teh
ugotovitev smo spoznali, da so testerji omejena sredstva, to pomeni, če so vsi testerji že
razporejeni na enem ali več projektih, potem ne moremo načrtovati nadaljnjih projektov,
dokler ne zaposlimo dodatno silo kvalificiranih testerjev. [7]
2.10 Zaključek testiranja
Velikokrat zmanjka časa za dokončanje testiranja. Kaj storiti v tej situaciji, da lahko
dokončamo testiranje? Ko se približujemo koncu testiranja, najprej v ospredje postavimo
problematične napake, ki predstavljajo največjo možno poslovno tveganje, nato se lotimo
testiranja in odprave teh napak. Potem sledi pregled nedokončanega testnega plana ter
ocenitev neuspelega testiranja. Vodja razvoja mora v primeru predčasne zaustavitve testiranja
predstaviti oceno tveganja. Naloga vodje razvoja je pravilna razsodba o zaustavitvi testiranja,
če ne poteka po urniku projekta, ali poiskati dodaten čas in sredstva za dokončanje testiranja
po načrtu oziroma urniku. [7]
Zelo težko je testirati vse funkcionalnosti programske opreme v določenem času, zato
pregledamo testne rezultate in jih primerjamo s funkcionalnosti sistema, ki jih je stranka
postavila za najbolj pomembne. Cilj pregleda je določiti funkcionalnosti, ki jih bomo lahko
testirali v omejenem času z omejenimi sredstvi. [7]
Ne smemo pozabiti na skupino napak, ki jih lahko odkrijemo na istem območju. Če obstajajo,
zahtevamo pregled kode tega območja, nakar razvojna ekipa ugotovi, ali lahko skrite napake
odpravi brez večjega napora. Problematične napake morajo testerji in razvijalci obravnavati,
preden izgubijo preostala testna sredstva. [7]
17
3 Faze in življenjski cikel testiranja
Namen načrtovanja testiranja je preverjanje testiranja, ki opredeljuje testne cilje in pripomore
k nujnim odločitvam za preoblikovanje testne strategije v operativnem načrtu, ki predstavlja
plan izvedbe testiranja. [8]
V današnjih časih postaja velikost in kompleksnost programske opreme vse večja, zato
postaja neformalno testiranje brez priprave in načrtovanja neustrezno. Testiranje na formalen
način lahko hitro spregleda pomembne funkcije, lastnosti in povezane komponente
programske opreme ter določene podrobnosti implementacije. Zato je nujna potreba po
načrtovanju, spremljanju, upravljanju in optimiziranju testnih strategij.[2]
Če želimo, da testiranje postane učinkovito in uspešno, potem ne smemo testirati na določeni
točki razvojnega procesa programske opreme. Razvojni proces ni statičen, zato se morajo
testne tehnike prilagoditi statusu programa v okviru razvoja. Razvoj in testiranje programske
opreme bi morala slediti pristopu »kodiranja in odpravljanja napak«, v tem primeru se
testiranje izvaja po fazah. Za te faze ni nobene sheme, ki bi prikazovala njuno uporabo,
vendar obstaja model osnovne postavitve faz, s katerim se usmerjamo. Za primer si bomo
podrobneje ogledali V-model testiranja.
3.1 V-model testiranja
Pred obravnavanjem V-modela si bomo najprej pogledali model, ki je nastal pred njim.
Waterfall model je eden izmed prvih modelov, ki ima naravno časovnico, kjer se opravila
izvajajo v zaporedju. Waterfall model se začne na vrhu s študijo izvedljivosti in nadaljuje pot
navzdol z različnimi projektnimi opravili ter se zaključi z implementacijo izdelka v
produkcijo, kot je prikazano na spodnji sliki (Slika 2). Zasnova gre najprej skozi razvoj,
implementacijo in na koncu skozi testiranje. V tem primeru se izdelek testira na koncu
življenjskega cikla projekta, kjer se napake in pomanjkljivosti odkrijejo tik pred predajo. Ta
model težko prenese povratne informacije nazaj na vrh modela in ima težave pri izvajanju
številnih iteracij za določeno fazo. [11]
18
Slika 2: Waterfall model [6]
V-model je odpravil pomanjkljivosti Waterfall modela, kjer se je testiranje začelo na koncu
modela in so bile zaradi tega napake odkrite prepozno. Testiranje je posledično podaljšalo rok
projekta in dejansko predajo izdelka. V V-modelu se testiranje začne zgodaj v življenjskem
ciklu, ki je po načelu strukturiranega testiranja. Model vsebuje različne aktivnosti, ki se
izvedejo pred koncem faze kodiranja. Aktivnosti se izvajajo vzporedno z razvojem, kjer
morajo testerji sodelovati z razvijalci in analitiki, da lahko izvedejo opravila in pripravijo
testne rezultate. Proizvod, izdelan s strani razvijalcev in analitikov, je osnova za testiranje
skozi eno ali več ravni. Testiranje v zgodnji fazi pogosto odkrije napake v osnovnih
dokumentih, vendar nam dobra praksa narekuje, da testerje vključimo že pri pregledu osnutka
dokumenta. V-model ponazarja ujemanje testnih aktivnosti (verifikacije in validacije) z vsako
fazo življenjskega cikla. Testiranje validacije poteka predvsem v zgodnjih fazah
(pregledovanje zahtev uporabnika) in pozno v življenjskem ciklu (med testom
sprejemljivosti). [65]
19
Obstaja veliko različic V-modela, vendar je zelo pogost V-model s štirimi fazami testiranja.
Predstavili bomo cilje vseh štirih faz, ki so [11]:
• Testiranje enote/komponente: išče napake in preverja delovanje komponent
programske opreme (npr. kot so moduli, programi, objekti, razredi), ki jih posamezno
preverimo.
• Integracijsko testiranje: preverja vmesnike komponent, interakcije različnih delov
sistema, kot je operacijski sistem, datotečni sistem in strojna oprema.
• Sistemsko testiranje: preverja odzivanje celotnega sistema/izdelka, definiranega v
okviru razvojnega projekta ali izdelka. Glavni cilj testiranja sistema je preverjanje
pred predpisanimi zahtevami.
• Test sprejemljivosti: testiranje validacije glede na potrebe uporabnika, zahtev in
poslovnih procesov, ki na podlagi teh določi sprejemljivost sistema.
V-model prikazuje, v kateri fazi razvoja programske opreme bi morale potekati testne
aktivnosti. Vsaka razvojna aktivnost ima testno aktivnost in obratno. Vsa ta načela veljajo
povsod, ne glede na to, kateri model življenjskega cikla programske opreme se uporablja.
Najpomembnejši dejavnik za uspešno uporabo V-modela je določitev roka izdelave testnih
primerov. V fazi načrtovanja testov se vedno pojavijo napake ne glede na namen testov. Na
kratko bomo predstavili načrt testiranja v V-modelu: v fazi sprejemljivostnega testiranja testni
primeri odkrijejo napake v zahtevah, v fazi sistemskega testiranja testni primeri odkrijejo
napake v specifikacijah funkcionalnosti, v fazi integracijskega testiranja testni primeri
odkrijejo napake v zasnovi in v fazi testiranja enote/komponente testni primeri odkrijejo
napake v kodi. Načrt testiranja se mora sprožiti že v začetku, če se izvede proti koncu modela
postanejo popravila zelo draga. Z izdelavo testnega načrta ne čakamo do izvedbe testiranja,
ampak ga začnemo snovati takoj, ko pridobimo informacije za potek. Potem je učinek pri
iskanju napak uspešen in ne destruktiven, saj se napake odpravijo preden se razmnožijo.
Seveda testov ne moremo izvajati, dokler ni v celoti razvita enota/komponenta ali modul
programske opreme, vendar jih lahko pripravimo vnaprej. Testi se dejansko izvajajo v
obratnem vrstnem redu kot so zapisani, npr. testiranje enote/komponente je na zadnjem mestu,
vendar se izvaja prvo. [6]
V praksi ima V-model pogosto manj ali več različnih faz pri razvoju in testiranju, odvisno od
projekta in programske opreme. Faze modela se lahko kombinirajo in reorganizirajo glede na
20
naravo projekta ali arhitekture sistema. V primeru, če se izdelek razvija za komercialni trg
Commercial Off The Shelf (COTS), lahko kupec izvede samo integracijsko testiranje na ravni
sistema (npr., integracija infrastrukture in drugih sistemov) in v kasnejši fazi testa
sprejemljivosti. [11] Slika 3 prikazuje faze verifikacije in validacije ter kateri testi se
pripravijo v fazah verifikacije.
Slika 3: V-model [11]
3.1.1 Faze verifikacije
Faze verifikacije v V-modelu [31]:
• Analiziranje poslovnih zahtev: je začetna faza razvojnega cikla, kjer se z vidika
stranke opredelijo zahteve izdelka. Faza vključuje podrobno komunikacijo s stranko,
ki nam razloži pričakovanja in zahteve. Ta aktivnost je zelo pomembna in jo moramo
opraviti čim bolj uspešno, saj večina strank ne zna razložiti namena aplikacije. V tej
fazi se načrtuje in izvaja test sprejemljivosti, kjer se testirajo poslovne zahteve.
• Načrtovanje sistema: po zbranih zahtevah izdelka začnemo načrtovati celoten sistem.
Načrtovanje sistema obsega razumevanje strojne opreme in nastavitve komunikacije
izdelka. Načrt sistemskega testiranja je razvit na osnovi načrta sistema.
21
• Načrtovanje arhitekture: v tej fazi moramo najprej razumeti specifikacije
arhitekture, nato jo načrtujemo. Tehnični pristop izberemo na podlagi tehnične in
finančne izvedljivosti. Sistem je razčlenjen na module z različnimi funkcijami in se
imenuje High Level Design (HLD). Opredelimo tudi prenos podatkov in komunikacijo
med moduli in drugimi zunanji sistemi. V tej fazi z danimi informacijami načrtujemo
in dokumentiramo integracijsko testiranje.
• Načrtovanje modulov: načrtovanje notranjih modulov sistema se imenuje Low Level
Design (LLD). Konstrukcija mora biti združljiva z drugimi moduli strukture sistema in
z zunanjimi sistemi. Testiranje enote je ključni del vsakega razvojnega procesa, ki
odpravi največje napake v zelo zgodnji fazi. Teste načrtujemo in izvajamo v fazi
načrtovanja notranjih modulov.
• Faza kodiranja: v fazi kodiranja kodiramo sistemske module in se na podlagi sistema
ter zahtev arhitekture odločimo za primeren programski jezik. Kodiranje izvajamo na
osnovi smernic in standardov. Koda gre skozi številne recenzije, saj mora biti dobro
optimizirana, preden izdelamo verzijo.
3.1.2 Faze validacije
V-model ima štiri faze testiranja, ki so:
• testiranje komponente/enote
• integracijsko testiranje
• sistemsko testiranje
• test sprejemljivosti
3.1.2.1 Testiranje komponente/enote
Testiranje komponente je znano kot testiranje enote, modula, in programa, v katerih iščemo
napake in preverjamo delovanje ločenih delov programske opreme (npr. moduli, programi,
objekti, razredi, itd.). Pri testiranju preverjamo notranji najmanjši del sistema programske
opreme in njeno delovanje z ostalimi deli sistema. Modul, ki ga testiramo, je izključen iz
preostale kode in ga preverjamo, dokler ne deluje pravilno. [11]
V preverjanje je vključeno testiranje funkcionalne in nefunkcionalne karakteristike, kot je
spremljanje virov (npr. izgube pomnilnika), testiranje zmogljivosti in testiranje strukture (npr.
pokritost kode). Testni primeri izvirajo iz načrtovanja programske opreme ali podatkovnega
modela. Testiranje komponente prav tako preverja kodo s pomočjo razvojnega okolja, kot je
22
testno ogrodje enote ali razhroščevalno orodje, s katerim upravlja razvijalec, ki je napisal
kodo. Včasih, odvisno od ravni tveganja, izvaja testiranje zunanji razvijalec in s tem uvaja
neodvisnost. Odkrite napake razvijalci odpravijo hitro brez formalnega evidentiranja
ugotovljenih incidentov. Obstaja pristop, s katerim pred kodiranjem pripravimo in
avtomatiziramo testne primere, ki se uporablja v Extreme Programming (XP). Ta pristop
imenujemo Test-Driven Development (TDD) in je iterativen, temelji pa na ciklih razvoja
testnih primerov, izgradnji in integraciji manjših delov kode ter testiranju komponent. [13]
Prednost komponentnega testiranja je posamično testiranje enote sistema in hitro iskanje
napak. V integriranem sistemu je problem poiskati lokacijo napake, saj je težko ugotoviti, v
kateri enoti se nahaja, zato vedno testiramo enote pred integracijo sistema. Testiranje
nedokončanih modulov razvijalci nadomestijo z nadomestki in gonilniki, ki simulirajo klicano
(nadomestek) enoto in klicatelja (gonilnik) enote. Enota za testiranje potrebuje nadomestek in
gonilnik, kjer nadomestek simulira klicano enoto in gonilnik simulira klicatelja enote.
Podrobneje bomo predstavili uporabo gonilnikov in nadomestkov [32]:
• Nadomestki: imamo tri module A, B in C. Modul A je dokončan in ga je potrebno
testirati. Modul A kliče funkcije iz modula B in C, ki pa nista dokončana, zato
razvijalec izdela umeten modul, ki simulira vračanje vrednosti modula B in C k
modulu A. Ta umeten modul se predstavlja kot nadomestek.
• Gonilniki: V tem primeru imamo dokončana modula B in C, vendar modul A ni
dokončan in kliče funkcije iz modula B in C. Razvijalec napiše umetno kodo za modul
A, ki bo vračal vrednosti moduloma B in C. Delček umetne kode imenujemo gonilnik.
3.1.2.2 Integracijsko testiranje
Integracijsko testiranje preverja vmesnike med komponentami in interakcije z različnimi deli
sistema, kot so operacijski sistem, datotečni sistem in strojna oprema ali vmesnik med
sistemom. [57]
Večje ko je področje integracije, težje je izločiti napako določenega vmesnika. Integracijo
testiramo z različnimi pristopi, eden izmed njih je »big-bang«, ki preverja integrirane sisteme
ali komponente kot celoto. Prednost »big-bang« testiranja je, da razvijalcem za simulacijo ni
potrebno izdelovati umetnih komponent ali modulov, saj ta pristop testira dokončan sistem.
Glavni problem je pomanjkanje časa, saj je zelo zamudno in težko odkriti napako, zato »big-
bang« integracijo uporabimo takrat, ko smo optimistični in prepričani, da sistem ne bo
23
vseboval nobenih napak. Drugi ekstremni pristop najprej integrira module enega po enega,
nato izvede preizkus po vsakem koraku. [56]
Inkrementalni pristop zgodaj odkrije pomanjkljivosti, saj išče napake v manjšem sklopu
sistema, zato je vzrok odkrit relativno hitro. Vendar je ta pristop zamuden, saj moramo pri
testiranju razviti in uporabiti nadomestke ter gonilnike. Inkrementalna integracija ima vrsto
obstoječih možnosti, ki so deloma odvisne od arhitekture sistema [56]:
• Pristop top-down: testiranje poteka od zgoraj navzdol po arhitekturi sistema (npr.
začne iz uporabniškega vmesnika ali glavnega menija). Komponente so nadomeščene
z nadomestki.
• Pristop bottom-up: testiranje poteka od dna in se povzpenja po arhitekturi sistema
navzgor. Komponente so nadomeščene s strani gonilnikov.
• Inkrementacija funkcionalnosti: integracija in testiranje potekata na podlagi funkcij
oziroma funkcionalnosti, kot je dokumentirano v specifikacijah.
Preferenčno zaporedje in število korakov integracije je odvisno od lokacije v arhitekturi
vmesnikov z visokim tveganjem. Integracijo najprej začnemo z najbolj problematičnimi
vmesniki, s tem preprečimo nastanek večjih napak ob koncu faze integracijskega testiranja.
Inkrementalni pristop je bolj učinkovit od »big-bang« pristopa, saj zmanjša možnost odkritja
napake v pozni fazi testiranja. Idealno bi bilo, če bi tester popolnoma razumel arhitekturo in
vplive integracije. Dobra praksa za učinkovito testiranje priporoča, da najprej izdelamo teste
integracije, potem začnemo z razvijanjem komponent v zaporedju. [11]
Testerji se na vsaki stopnji integracije osredotočijo izključno na integracijo. Kar pomeni, da
pri integraciji s komponentama A in B testirajo izključno njuno medsebojno komunikacijo in
ne funkcionalnosti. V integracijsko testiranje je vključeno tudi preverjanje nefunkcionalnih
karakteristik (npr. testiranje zmogljivosti). V tej fazi se po navadi uporabijo tudi funkcionalni
in strukturni pristopi. [11]
3.1.2.3 Sistemsko testiranje
Sistemsko testiranje preverja obnašanje celotne programske opreme/sistema po opredeljenih
Software Requirements Specifications (SRS). Glavni cilj testiranja je preveriti skladnost
sistema z uporabniškimi zahtevami. [58]
Pogosto je to zadnje testiranje v razvoju, ki preveri ustrezanje sistema s specifikacijami in
poišče čim več možnih napak v sistemu. [59]
24
Testiranje pogosto nadzorujejo specializirani testerji, ki tvorijo posebne in samostojne testne
ekipe znotraj razvoja ter poročajo spremembe razvojni ali projektni vodji. V nekaterih
organizacijah sistemsko testiranje izvajajo zunanji testerji ali poslovni analitiki. Zahtevana
raven neodvisnosti temelji na primerni stopnji tveganja in s tem vpliva na način testiranja
sistema. [11]
Sistemsko testiranje preverja funkcionalne in nefunkcionalne zahteve sistema. Pod
nefunkcionalne zahteve spada preverjanje zmogljivosti in zanesljivosti, ki so včasih
nepopolne ali nedokumentirane. Pri testiranju funkcionalnih zahtev uporabimo tehnike, ki
temeljijo na specifikacijah (metode črne škatle). [60] Na kratko bomo predstavili primer ene
tehnike: izdelamo tabelo in na njeni podlagi kombiniramo učinke, navedene v poslovnem
pravilniku. Tehnike na podlagi strukture (metode bele škatle) vrednotijo temeljitost testiranja
elementov, kot je struktura menija ali navigacija spletne strani (za več informacij o različnih
tipih testiranja glej 5. poglavje). [11]
V tej fazi moramo v testnem okolju strogo nadzorovati: različice programske opreme, testno
opremo in testne podatke (za več informacij o upravljanju konfiguracije glej 6. poglavje).
Testiranje izvaja testna organizacija v ustrezno nadzorovanem okolju, ki se mora čim bolj
ujemati s produkcijskim, da zmanjša tveganja in napake v okolju.
3.1.2.4 Testiranje sprejemljivosti
Večino neodkritih pomanjkljivosti bo odkril uporabnik ali naročnik pri testiranju
sprejemljivosti. V tej fazi si moramo zastaviti vprašanja in na njih odgovoriti, to so: »Ali je
sistem pripravljen za izročitev? », »Ali obstajajo neporavnana poslovna tveganja?« in »Ali je
razvoj izpolnil svoje obveznosti?« Testiranje sprejemljivosti je odvisno od uporabnika
oziroma naročnika in drugih zainteresiranih oseb. Izvedba testne aktivnosti zahteva enako
testno okolje, kot je produkcijsko.
Glavni cilj testiranja je vzpostaviti zaupanje v sistem, v del sistema ali v določeno
nefunkcionalno karakteristiko, npr. uporabnost sistema. [61] Testiranje je pogosto
osredotočeno na vrsto testnega tipa, s katerim skušamo ugotoviti, ali sistem izpolnjuje svoj
namen. Glavni namen testiranja sprejemljivosti ni pri iskanju napak, ampak pri ocenjevanju
pripravljenosti sistema za uvajanje in uporabo, ki pa ni končna raven testiranja, na primer, pri
obsežnejšem sistemu lahko integracijsko testiranje izvedemo po sprejetju sistema. [11]
Testiranje sprejemljivosti se lahko pojavi na več ravneh, na primer [61]:
25
• Za izdelek, namenjen za COTS, mora organizacija pred instalacijo oziroma integracijo
izvesti test sprejemljivosti.
• Testiranje uporabnosti komponent se lahko opravi med testiranjem komponent.
• Testiranje sprejemljivosti nove izboljšane funkcionalnosti lahko opravimo pred
testiranjem sistema.
Testiranje sprejemljivosti sistemov za poslovno podporo razlikuje dva glavna testna tipa, ki
sta posebne narave in sta pripravljena ter izvedena ločeno. [11] Uporabniški test
sprejemljivosti se osredotoča predvsem na funkcionalnost, ki preveri uporabnost sistema s
strani uporabnika podjetja, medtem ko operativni test sprejemljivosti (imenovan tudi
produkcijski test sprejemljivosti) preverja skladnost sistema z zahtevami. Uporabniški test
sprejemljivosti je izveden s strani uporabnikov in upravljavcev aplikacije. V smislu
načrtovanja je to testiranje tesno povezano s sistemom in se v številnih primerih deloma
pokriva s časom. Testiranje sprejemljivosti neodvisnih podsistemov sistema mora biti v skladu
z izhodnimi kriteriji sistemskega testa in lahko pričnemo z izvedbo preverjanja tudi v primeru,
če je podsistem v fazi testiranja sistema. [61] V številnih organizacijah administracijo sistema
opravlja operativni test sprejemljivosti pred sprostitvijo sistema. Operativni test
sprejemljivosti vključuje preverjanje varnostnih kopij, ponesrečenih dogodkov, vzdrževalnih
opravil in varnostnih lukenj. [11]
Obstajata še dva tipa testiranja sprejemljivosti, ki preverjata pogodbe po naročilu izdelanega
sistema in predpise. Testiranje po naročilu izdelanega sistema se izvaja zoper kriterije, v
katerih je določen potek izdelave. Pri dogovorjeni pogodbi moramo formalno opredeliti
testiranje sprejemljivosti. Testiranje skladnosti ali predpisov se izvaja zoper predpise, ki jih
moramo upoštevati prav tako kot vladne, pravne ali varnostne predpise. [63]
Izdelek, razvit za množični trg, npr. za komercialni/poslovni trg, je za testiranje posameznega
uporabnika ali stranke nepraktičen. Zato nujno potrebujemo povratne informacije potencialnih
uporabnikov, preden predamo proizvod v prodajo. Zelo pogosto se takšen tip sistema testira v
dveh fazah testiranja sprejemljivosti. Prvi se imenuje alfa testiranje in ga izvede razvijalec.
Izbrana je peščica potencialnih uporabnikov in članov organizacije za testiranje sistema. Med
testiranjem razvijalci sodelujejo z uporabniki tako, da si beležijo odkrite napake in popravke.
Alfa testiranje lahko izvajajo neodvisne testne ekipe. Po koncu te faze nastopi beta testiranje
ali testiranje na terenu, kjer se pošlje sistem nekaterim uporabnikom, ki si ga namestijo in ga
uporabijo v realnih delovnih razmerah. Nato skozi določen čas uporabniki pošljejo evidenco
incidentov skupaj s sistemom k organizaciji, ki odpravi odkrite napake. [62]
26
Upoštevati je potrebno, da lahko vsaka organizacija po svoje imenuje fazo testiranja, kot sta
npr. tovarniško testiranje sprejemljivosti in test sprejemljivosti lokacije za sisteme, ki so bili
testirani pred in po prevzetju.
3.1.3 Iterativni življenjski cikli
Nekateri življenjski cikli nimajo zaporednega vrstnega reda. Obstajajo iterativni oziroma
inkrementalni življenjski cikli, kjer se na glavni razvojni časovni premici ponovi več manjših
samodejnih življenjskih ciklov za enak projekt (Slika 4). Zelo podobno kot pri V-modelu, ki
uporablja veliko različic iterativnih življenjskih ciklov.
Slika 4: Iterativni razvojni model [11]
Skupna značilnost iterativnih pristopov je njihova inkrementalna razdelitev, kjer se pri vsaki
iteraciji doda in preveri nova funkcionalnost. Začetni inkrement vsebuje infrastrukturo,
potrebno za podporo funkcionalnosti gradnika. Iterativni inkrement je lahko preverjen na
številnih ravneh kot del razvoja. Zaporedni inkrementi testirajo nove funkcionalnosti in
morajo izvesti regresijsko testiranje za obstoječo funkcionalnost ter integracijsko testiranje za
nove in obstoječe dele sistema. [64] Regresijsko testiranje je zelo pomembno pri vseh
iteracijah razen prve, to pomeni več testiranja za vsako naslednjo fazo, ki mora biti odobrena
v načrtih projekta. S tem življenjskim ciklom je lahko izdelek s kritično funkcionalnostjo zelo
kmalu na trgu, saj ga je zaradi razdeljenega obsega dela na manjše koščke enostavno
upravljati, s tem se posledično zmanjša začetna investicija, čeprav se lahko stroški na dolgi
rok povečajo. Zaradi hitre navzočnosti izdelka na trgu moramo pri vsakem inkrementu izvesti
validacijo, da dobimo povratne informacije o poslovni vrednosti in uporabnosti izdelka. [11]
27
3.1.4 Prednosti in slabosti V-modela
Prednost V-modela je vidna v enostavnem razumevanju in uporabi ter njegovi preprostosti za
lažje upravljanje z njim. Težava modela je pri prilagajanju sprememb, ki se pojavijo pri
spreminjanju zahtev, to je v današnjem dinamičnem življenju zelo pogosto in nas lahko
finančno veliko stane.
Tabela 1 prikazuje slabosti in prednosti V-modela [31]:
Tabela 1: Prednosti in slabosti V-modela [31]
Prednosti Slabosti
Je zelo discipliniran model, kjer se faze
zaključujejo po vrstnem redu.
Visoka tveganja in negotovosti.
Zelo dobro se izkaže v manjših projektih, v
katerih so dobro definirane in razumljive
zahteve.
Ni primeren za kompleksno in objektno
usmerjene projekte.
Preprost in enostaven za razumevanje in
uporabo.
Ni primeren za tekoče in dolge projekte.
Enostavno upravljanje z njim zaradi njegove
togosti. Vsaka faza ima posebne končne
rezultate in postopke pregleda.
Ni primeren za projekte, kjer se zahteve
pogosto spreminjajo.
V fazi testiranja je težko spreminjati
funkcionalnosti za nazaj.
Programska oprema začne delovat šele v
poznem življenjskem ciklu.
3.1.5 Dodatne faze V-modela
Spodaj naštete faze lahko dodatno vpeljemo k že znanim osnovnim štirim fazam V-modela.
Te lahko uresničijo le dovolj velika podjetja, kajti manjša podjetja nimajo profesionalnih
testerjev, niti rezerviranega sistema za testiranje ter imajo manj prefinjen načrt testiranja. V
tem primeru zasnova modela postane enostavnejša, temelji samo na komponentnem,
integracijskem, sistemskem in sprejemljivostnem testiranju. V nasprotni smeri večja podjetja
preuredijo organizacijo modela in zasnujejo svoje podfaze. [10]
• Centralno testiranje komponente
28
V tej fazi test ni izveden z razvojnega okolja, ampak so komponente testirane na
končnemu sistemu.
• Zmogljivostni test
Zmogljivostni test se izvede takoj po testiranju sistema. Namen tega testa je pridobiti
predstavo o učinkovitosti sistema ter iskanju ozkega grla zmogljivosti.
• Zmogljivostni test sistema
Ko so vse glavne komponente integrirane, je potrebno pregledati druge vpeljane
funkcionalnosti, ki niso storjene s strani razvijalcev. Prvi zmogljivostni test preveri
možne algoritmične omejitve in napačna prepričanja. S pridobljenimi podatki
preverjanja ocenimo zmogljivost programa pod realnimi pogoji.
• Pilotski test.
Pilotski test je izveden s prisotnostjo notranjega oddelka ali končnega uporabnika
oziroma stranke. Pri tem testiranju se polizdelek namesti na več sistemov, ki se po
testiranju lahko uporabijo v produkciji. Koncept pilotskega testiranja uporablja beta
teste in veliko število testerjev. Izvedejo jih v produkcijskem ali javnem okolju.
• Produktivna uporaba
Programska oprema obratuje pri končnem uporabniku ali stranki.
• Vzdrževanje
Običajno se program vzdržuje, še posebej takrat če se objavljajo nove različice.
29
4 Testiranje programske opreme v orodju Visual Studio 2013
Orodja v Visual Studio 2013 in Team Foundation Server 2013 nam omogočajo izboljšati cilje
testiranja. [12]
Glavni cilj testiranja je odkriti napake v zgodnji fazi razvoja programske opreme. Da bi
napako odkrili čim prej, moramo s testiranjem začeti v fazi načrtovanja zahtev življenjskega
cikla programske opreme, ki se nadaljuje vse do konca tega cikla. Testna ekipa mora pripraviti
testne primere, ki temeljijo na zahtevah. [13]
V tem poglavju bomo predstavili način upravljanja aplikacij skozi njihov življenjski cikel in
aplikacijsko podporo, ki jo za podporo temu upravljanju nudi Microsoft v izvedbah Visual
Studio 2013.
4.1 Upravljanje življenjskega cikla aplikacije (ALM)
Izraz ALM (Application Lifecycle Management) je postal zelo pomemben v industriji za
razvoj aplikacij, saj predstavlja način upravljanja vse od njenega rojstva ter izdelave,
namestitve, postavitve in do njene upokojitve.
ALM upravlja življenjski cikel (upravljanje, razvoj in vzdrževanje) programske opreme.
Zajema upravljanje zahtev, programsko arhitekturo, programiranje, testiranje programske
opreme, upravljanje programske opreme, upravljanje sprememb, kontinuirano integracijo,
projektno vodenje in upravljanje objave programske opreme. [36]
Uveljavila se je praksa ALM integracije, kjer se orodja in orodja uporabnikov sinhronizirajo
med seboj preko faz razvoja aplikacij. V tej integraciji mora vsak član ekipe spremljati
spremembe, ki so se zgodile v procesu razvoja, in ne dopuščati presenečanja v zadnjem
trenutku, ki bi zakasnil predajo izdelka. [36]
Pristop ALM je zelo celovit koncept, ki je spoznal, da se zahteve razvijajo na podlagi
poslovnih potreb, idej in strank, ki se štejejo kot del razvojne ekipe in igrajo vlogo skozi
razvoj aplikacije, s tem da pomagajo pri izboljšavi in aktivno sodelujejo pri implementaciji
aplikacije. Delo razvojne ekipe se ne konča s predajo aplikacije, ampak po predaji izdelka še
vedno odpravljajo težave, nastale v produkcijskem okolju, ali pa izdelajo številne različice
aplikacije, ki bodo ustrezale glede na odziv uporabnikov in analitikov. Visual Studio je
sčasoma opustil orodje, ki je podpiralo programerski koncept razvoja programske opreme
30
skozi življenjski cikel, in tako začel iskati rešitve, ki so bližje konceptu upravljanja
življenjskega cikla aplikacije. [14]
Tabela 2 prikazuje specializirane programske garniture za ALM:
Tabela 2: ALM programske garniture [36] Izdelek Izdelalo podjetje
Endevor CA Technologies
Enterprise Architect Sparx Systems
FogBugz Fog Creek Software
FusionForge FusionForge
GeneXus GeneXus - Artech
HP Application Lifecycle Management HP Software Division
IBM Rational Team Concert IBM
JIRA Atlassian
Mylyn Eclipse Foundation
Parasoft Concerto, Parasoft Development
Testing Platform
Parasoft
Protecode System 4 Protecode
Pulse Genuitec
PTC Integrity PTC
Rational solution for Collaborative
Lifecycle Management
IBM
SAP Solution Manager SAP
StarTeam Borland
TeamForge CollabNet
Team Foundation Server Microsoft
TestTrack Seapine Software
Visual Studio Application Lifecycle
Management
Microsoft
31
4.2 Orodja za Testiranje programske opreme v orodju Visual Studio 2013
Upravljanje življenjskega cikla aplikacije v orodju Visual Studio predstavlja nabor
integriranih razvojnih orodij, izdelanih s strani organizacije Microsoft. Orodja vključujejo
Integrated development environment (IDE), nadzor izvorne kode, razna opravila,
kolaboracije, meritve ter orodja za poročanje. Visual Studio ALM je sestavljen iz štirih
produktov:
• Visual Studio zagotavlja IDE za razvijanje in izdelavo uporabniških vmesnikov.
Obstajajo štiri izvedbe: Visual Studio Professional, Visual Studio Ultimate, Visual
Studio Premium in Visual Studio Test Professional. [37]
• Visual Studio Test Professional zagotavlja IDE za testerje programske opreme, da
lahko izdelajo in izvajajo teste, ki so izvedba iz Visual Studio 2013 in so primerni za
testerje, poslovne analitike, vodje produktov in za druge poslovne osebe, ki
potrebujejo kolaboracijsko orodje, vendar ne uporabljajo celotnega integriranega
razvojnega okolja. Test Professional 2013 nudi orodja za integrirano testiranje in
vodenje izdelka, ki zagotovijo kvaliteto v procesu razvoja. Podpira agilno upravljanje
portfelja, enostavnejše definicije zahtev in neprekinjene odzive strank ter zagotavlja
sledljivost preko teh procesov. [20]
• Team Foundation Server (TFS) zagotavlja kolaboracijo z izvorno kodo in
skladiščenje podatkov. Je orodje za spremljanje in poročanje o napredku projekta,
lahko ga uporabimo kot strežnik, na katerega razvijalci shranjujejo izvorno kodo
izdelka. Vzporedno lahko z njim razvijamo in testiramo programsko opremo ter
izdelamo poročila in namizja, ki prikazujejo napredek projekta. Vsebuje poročila
glede na opravljeno delo in testiranje, skladno z zahtevami.
TFS je ločen strežniški produkt orodja Visual Studio in je sestavljen iz dveh slojev, ki
ju lahko fizično naložimo na enega ali več računalnikov. Sloja, ki sestavljata TFS sta
[14]:
o Aplikacijski sloj je sestavljen iz številnih spletnih storitev, kjer računalnik
odjemalca komunicira s pomočjo visoko optimiziranega protokola spletne
storitve.
o Podatkovni sloj sestavlja SQL podatkovna baza, ki uporablja logiko
aplikacijskega sloja skupaj s podatki za našo instanco orodja TFS. Vsi podatki,
32
ki so shranjeni v orodju TFS so shranjeni v SQL strežniški bazi podatkov, kar
nam olajša delo pri izdelavi varnostnih kopij.
TFS je bil zasnovan z miselno razteznostjo. Obstajajo obsežni vmesniki za
programiranje aplikacij (API) v .NET in Javi, ki jih lahko integriramo z orodjem TFS
ter nabor dogodkov, ki omogočajo integracijo zunanjih orodij. Enake vmesnike in
dogodke uporablja Microsoft v zvezi z orodjem TFS, podobno kot integracija
odjemalca z orodji Visual Studio, Microsoft Office in Eclipse. TFS obdaja zelo veliko
konkurentov, vključno z drugimi poslovnimi življenjskimi cikli, ki upravljajo
programsko opremo in rešitve za posamezne namene (kot so nadzor nad viri, sistem za
sledenje dela itd.). Glavna prednost vseh teh zmožnosti je popolna integracija, da
lahko Microsoft upravlja z orodji za razvoj programske opreme in z orodji za
komunikacijo ekipe in stranke. [14]
• Visual Studio Lab Management je razvojno programsko orodje, ki ga je razvil
Microsoft in omogočil testerjem programske opreme izdelavo in upravljanje virtualnih
okolij [15]. Lab Managment razširja Visual Studio Application Lifecycle Management
platformo, ki omogoči celosten Hyper-V testni laboratorij. Visual Studio Lab
Management je integriran s System Center Virtual Machine Manager (SCVMM), ki
omogoča upravljanje več fizičnih računalnikov (ki gostijo virtualne naprave), shrambo
virtualnih naprav, predloge virtualnih naprav in druge konfiguracije datotek v
SCVMM strežniških knjižnicah. Uporabnikom omogoči naslednje [38]:
o Reproducira natančno stanje napake ali drugi problem pri razvijanju.
o Samodejna izgradnja, samodejno razvijanje in testiranje programske opreme v
čistem okolju.
o Zmanjšuje čas, ki je na voljo za izdelavo in konfiguracijo naprav za testiranje
programske opreme.
o Izvaja številne kopije pri testiranju ali razvoju hkrati.
o Izdelavo in upravljanje virtualnih okolij brez privilegija administratorja
sistema.
33
4.3 Postavitev testnega okolja
Preden začnemo pisati teste, moramo najprej analizirati zahteve, ki so ključnega pomena pri
testiranju izdelka, zato si postavimo naslednja vprašanja:
• Katere vrste testov se najprej lotimo pisati?
• Kje bomo zasnovali, razvili in izvajali teste?
• Kako posodobiti sistem pod vplivom testiranja in izvajati avtomatske teste?
Te tematike nam pomagajo pri postavitvi testnega okolja, nato se lotimo oblikovanja in
postavitve po zahtevah.
Vzpostavimo testno infrastrukturo, ki podpira naslednje zahteve:
• Razvijalci razvijajo avtomatske teste enot in integracije ter izvajajo teste na svojem
lokalnem okolju.
• Testerji izdelajo in izvajajo ročne teste v nadzornem okolju.
• Izbrane scenarije pretvorimo v avtomatizirane regresijske in zmogljivostne teste.
• Okolja generiramo na zahtevo z uporabo Visual Studio Lab Managment.
• Sistem, pod katerim je test objavljen na zahtevo s strani testerja z uporabo TFS Built
sistema.
Obstaja več poti prilagoditve orodja Visual Studio z življenjskim ciklom ALM, vendar bomo
z naslednjimi koraki prikazali le eno pot [21]:
• Uporaba le orodja Visual Studio – Visual Studio se uporablja za razvijanje in
testiranje, kjer testerji ugotavljajo pravilno delovanje aplikacije s pritiskom na tipko
F5. Testi enote so napisani s strani razvijalcev za testiranje posameznih razredov in
komponent. Kodirani UI testi so na nek način avtomatski testi celotne aplikacije, ki
testirajo uporabniški vmesnik.
• Osnove orodja Team Foundation Server – TFS je temeljnega pomena za upravljanje
življenjskega cikla programske opreme. Zaradi težav pri razvijanju programske
opreme velikokrat prihaja do propada projekta. Razvijanje programske opreme je
ustvarjalno prizadevanje in ne proizvodni proces, zato je bistven dejavnik uspeha
razvojne ekipe komunikacija med člani skupine in drugimi ljudmi. Microsoft Visual
Studio Team Foundation Server 2013 ponuja osnovne kolaboracijske funkcije,
namenjene razvojni ekipi programske opreme. Funkcionalnosti, ki jih TFS vključuje,
so naslednje:
o načrtovanje in upravljanje projekta
34
o sledenje opravil
o nadzor verzij
o upravljanje testnih primerov
o avtomatska izgradnja kode
o poročanje
o upravljanje virtualnega okolja laboratorija
Pri namestitvi orodja TFS dobimo številne funkcije. Funkcije, ki jih bomo najprej
izkoristili, so:
o Source control prepreči prekrivanja dela med razvijalci, zato uporabimo
sledeča pravila:
� Pravilnik prijave – opomni razvijalce, da najprej opravijo teste in
analize kakovosti na svoji kodi, preden jo dodajo na strežnik.
� Razne spremembe – razvijalec pošlje spremembe k drugemu, ki jih
pregleda in objavi na strežniku.
� Veje – pomagajo pri upravljanju dela v večjih projektih.
o Task Management sledi zahtevam (seznam opravil), napakam, problematikam
in specifikacijam. Opravila so zapisana v zapisniku, ki jih lahko dodelimo
zaposlenim, projektu, iteracijam in različnim delovnim območjem.
Organiziramo jih lahko v hierarhije in jih urejamo v Excelu ter sinhroniziramo
z orodji za upravljanje projektov.
• Project Portal je SharePoint spletna stran, integrirana z orodjem Team Foundation
Server. S tem dobi vsak projekt svojo spletno mesto. Omogoči nam različna namizja z
grafi in grafikoni napredka projekta, ki temeljijo na podlagi zahtev in testnih
rezultatov.
• Build Service je funkcija orodja Team Foundation Server, ki opravlja pomembno
nalogo za razvojno ekipo. Zgradi kodo, ki je bila preverjena s strani razvijalcev. Ekipi
omogoči, da preko e-pošte dobi obvestilo o neuspešnem testu, prav tako jim projektni
portal prikazuje poročila o najnovejših rezultatih. Obveščanje o napakah preko e-
sporočil je zelo učinkovito, saj s tem načinom ohranimo visoko kakovost kode
(prikaže nam vse zaposlene, ki so upravljali s kodo neuspele izgradnje).
• Microsoft Test Manager je zanimiv z vidika strokovnega testerja. MTM izdela teste,
zanesljive in ponovljive ter pospeši testiranje. Uporabimo ga lahko za uporabo:
35
o Pisanje ročnih testov, ki se med testiranjem prikažejo na strani zaslona.
o Snemanje testnih dejanj, ki delno avtomatizira teste, tako da lahko naslednjič
ponovno ponovimo ta dejanja.
o Popolnoma avtomatizirani testi se lahko izvajajo v storitvi za izgradnjo kode,
za ta podvig moramo prilagoditi generirano kodo iz delno avtomatiziranih
testov.
o Poveže teste z uporabniškimi zahtevami. Projektni portal vsebuje grafikone, ki
prikazujejo napredek vsake zahteve uporabnika glede na uspeh testiranja. Teste
organiziramo v garniture in načrte ter jih razdelimo po funkcionalnih področjih
in iteracijah projekta.
o Poročanje o napaki z enim korakom, vključuje posnetke stanja programa.
• Laboratoriji so zbirke testnih naprav, predvsem virtualnih naprav. Brez laboratorija
moramo aplikacijo testirati lokalno na svojem računalniku. Razvoj in razhroščevanje
aplikacije poteka na razvojnem računalniku, pogosto se številne panoge izvajajo na
istem računalniku. Vendar laboratorij lahko:
o Namesti sistem na več računalnikov in zbira testne rezultate od vsakega
računalnika. Npr. spletni odjemalec Microsoft Internet Information Services
(IIS) in podatkovna baza bosta funkcionirala na ločenih računalnikih.
o Hitro ustvari nove virtualne računalnike, tako da ni potrebno odstraniti starih
verzij aplikacije. Dobra lastnost tega je, da nam aplikacija ne more pokvariti
našega fizičnega računalnika. Pri konfiguraciji virtualnega računalnika imamo
možnost izbrati katerokoli platformo.
o Konfigurira okolje virtualnih računalnikov za posamezno testno garnituro in jo
lahko shranimo za ponoven zagon.
o Izdela posnetek stanja virtualnega okolja in ga shranimo skupaj s poročilom o
napakah.
• Avtomatska izgradnja, namestitev in testiranje. Build Service pogosto izvaja teste
enote na enem računalniku. Vendar za spletne in ostale porazdeljene aplikacije to ne
velja, ker na njih ne moremo opraviti realne simulacije pod dejanskimi operativnimi
pogoji. Z avtomatsko namestitvijo lahko izvajamo teste na virtualnem okolju, kot del
stalne ali redne izgradnje. Pri avtomatski izgradnji, sistem instancira ustrezno
virtualno okolje za teste ter postavi vsako komponento na pravi računalnik in pravo
36
okolje, ki izvaja teste, zbira podatke od vsakega virtualnega računalnika in beleži
rezultate na projektnem portalu.
4.4 Skupina projektov v orodju TFS
V orodju TFS je skupina projekta zbirka delovnih predmetov, kode, testov, delovnih izdelkov,
metrik itd., ki jih uporablja določena skupina za sledenje dela. Logični koncept skupine
projekta nam pomaga pri odločitvi, kaj naj vključimo in izključimo iz razvoja programske
opreme. Koncept skupine projekta je implementiran preko fizičnih orodij, skupin in delovnih
tokov orodji Team Explorer in TFS. Konceptualna meja, ki smo jo določili okrog skupine
projekta, vpliva na strukturo projektne skupine in na prehod iz ene skupine v drugo. [17]
4.4.1 Logična definicija skupine projektov
Z logičnega (ali konceptualnega) vidika je skupina projekta ena sama infrastruktura, ki zajema
posamezna orodja in elemente v življenjskem ciklu razvoja programske opreme. Vsaka
programska oprema ali »skupina projekta« je dejansko združena v svoj imenski prostor. Zato
je skupina projekta izoliran zbiralnik, ki vsebuje orodja in predmete, vezane na določeno
programsko opremo, tako da druga skupina projektov nima dostopa do teh orodij ali
predmetov (npr. izvorne kode, delovnih predmetov in dokumentov). [39]
Skupina projekta je osrednji koncept, ki drži skupaj prizadevanja skupine za oblikovanje
določene programske opreme ali izdelka. Skupina projekta je virtualna zbirka predmetov, ki
ustrezajo programski opremi. Za člane projekta, koncept skupine projekta odpravlja problem
dostopa do različnih predmetov, ki niso pomembni za to skupino. Takšen presežek predmetov
povzroča zmedo in upočasnjuje razvoj programske opreme. Skupina projekta mora biti
sestavljena iz orodij in predmetov, lahko vključuje tudi politiko za nadzor izvorne kode,
spletno stran za poročanje in portal. Orodje TFS omogoči skupini projekta predlogo procesa,
ki izbere ustrezna orodja in jih doda v zbiralnik skupine projekta. [39]
Koncept skupine projekta izboljšuje poročanje orodij, ki jih uporablja skupina. V preteklosti
je bilo poročanje orodij zahtevno, saj podatki iz različnih orodjih niso bili povezani. Npr.
razvijalec programske opreme želi pridobiti poročilo napak od orodij, zato bi razvijalec moral
ločiti napake iz številnih projektov, dokler te ne bi bile vse shranjene na isto lokacijo. Skupina
projekta je ustvarjena v imenskem prostoru, ki vsebuje le orodja in predmete pomembne za
37
projekt programske opreme; zato obstaja filter, ki se navezuje na različne predmete iz
različnih orodij. [39]
Orodje TFS lahko vsebuje več skupin projektov, ki so kreirane v ločenem imenskem prostoru,
npr. dokument X v imenskem prostoru A in dokument X v imenskem prostoru B nista med
sabo nič povezana, saj sta v različnem imenskem prostoru. Skupina projekta ima v ločenem
imenskem prostoru edinstvene predmete in orodja. Orodja in predmeti, ki jih vsebuje skupina
projekta A, niso dostopna razvijalcu, ki razvija na skupini projekta B. [39]
4.4.2 Fizična definicija skupine projektov
Logična definicija in konceptualna meja skupine projekta je dosežena preko orodja Team
Explorer. Team Explorer je razširljivo orodje v Visual Studio, ki združuje orodja in predmete
skupine projekta. Skupina projekta mora za svoj obstoj vsebovati vsaj orodja in predmete, ki
so določeni takrat, ko skupino projekta ustvarimo s predlogo procesa. Predloga procesa doda
skupini projekta dodatne funkcije, kot so: politiko nadzora nad izvorno kodo, spletno stran
poročanja skupine projekta, portal skupine projekta. [39]
Pri prvi uporabi orodja Team Explorer se moramo povezati z orodjem TFS; če se ne
povežemo, ne moremo izbrati skupine projektov iz orodja TFS. Team Explorer se lahko
poveže le z enim TFS orodjem, zato imamo možnost izbire skupine projektov le iz njega.
Slika 5 prikazuje povezavo z orodjem TFS in izdelavo nove skupine projekta.
Slika 5: Izdelava nove skupine projekta z uporabo orodja Team Explorer
Pred nastankom skupine projekta v orodju TFS moramo najprej izbrati predlogo procesa, ta
predloga definira nabor različnih tipov opravil in poročila, ki jih potrebujemo za načrtovanje
in spremljanje projekta. Predlogo za skupino projekta izberemo glede na potrebe testne
skupine, ki jim omogoči večjo osredotočenost na kvaliteto izdelka in zmanjšuje režijske
38
stroške. Če se potrebe testne ekipe razlikujejo od definiranih predlog, potem izdelamo
prilagojeno predlogo, nato ustvarimo skupino projekta ali najprej izdelamo skupino projekta
na podlagi predloge in nato prilagodimo projekt. [18]
Predloge lahko izbiramo glede na naslednje predpostavke [47]:
• Visual Studio Scrum 2.0 ali novejšo različico uporabimo, če se ekipa vzporedno
ukvarja z napakami in zahtevami izdelka v času načrtovanja cikla.
• MSF za Agile Software Development V6.0 ali novejšo različico uporabimo, če ekipa
loči napake od seznama zahtev izdelka ter reši opravila preden jih zaključi.
• MSF za CMMI Process Improvement v6.0 ali novejšo različico uporabimo, če ekipa
loči napake od seznama zahtev in reši opravila, preden jih zaključi ter formalno sledi
spremembam zahtev.
Pri izbiri predloge procesa imamo na voljo tri privzete predloge, ki se razlikujejo predvsem v
načrtovanju in sledenju dela (Slika 6).
Slika 6: Izbira predloge procesa
Odvisno od predloge procesa, ki se uporablja za izdelavo skupine projekta, imajo člani
skupine z uporabo orodja Team Explorer dostop do: informacije verzije izdelka, izvorne kode,
dodeljenih nalog, vpogleda v status projekta, iskanja dokumentov, pregleda nad poročili in
39
možnost izdelave delovnih predmetov, ki so povezani s skupino projekta. Slika 7 prikazuje
vozlišča skupine projektov.
Slika 7: Vozlišča skupine projekta
Npr. skupina projekta, izdelana s pristopom Microsoft Solutions Framework (MFS) za Agile
Software Development ali MFS za CMMI Process Improvement predloge procesa, imajo
naslednja vozlišča [17]:
• Delovni predmeti: omogočajo dostop za izdelavo in pregled nad poizvedbami zoper
podatkovne baze delovnega predmeta ter izdelavo novih delovnih predmetov.
Poizvedbe projekta implementira predloga procesa ali vodja projekta pri oblikovanju
skupine projekta. Uporabniško določene poizvedbe niso implementirane med
oblikovanjem skupine projekta, ampak so dodane kasneje kot vsebina po meri.
• Dokumenti: omogočajo dostop do delovnih proizvodov, kot so dokumenti,
preglednice, projektni načrti, smernice procesa in drugih nematerialnih proizvodov
razvoja. Dokumenti so shranjeni na edinstveni osrednji lokaciji portala skupine
projekta.
• Poročila: omogočajo dostop do poročil, ki vsebujejo metrike za skupino projekta in
do sredstev, ki zbirajo informacije od različnih orodij znotraj imenskega prostora
skupine projekta. SQL Reporting Services združuje informacije iz različnih orodij v
skupini projekta, ki nato tvori poročilo sestavljeno iz informacij izvoženih iz vsakega
orodja.
• Team Builds: omogoča dostop do gradnikov skupine projekta.
40
• Nadzor nad viri: omogoča dostop do artefaktov, kot sta izvorna koda in besedilo.
Razvijalci uporabijo raziskovalca virov za prijavo in odjavo izvorne kode.
Raziskovalec za nadzor virov je brskalnik izvornih datotek skupine projekta.
Nastavitve in lastnosti skupine projekta se razlikujejo od skupine projekta do skupine
projekta. Lastnosti skupine projekta so določene v Team menu v Visual Studio, ki definirajo
nastavitve za skupine in dovoljenja, ki identificirajo člane skupine projekta in njihove pravice
dostopa. Dodeljevanje skupin ustanavlja številne podskupine v skupini projekta in
učinkoviteje upravlja z zahtevanimi opravili. Nastavitve vsebujejo virtualno hierarhično
grupiranje za artefakte v skupini projekta. Struktura klasifikacije vključuje iteracije
življenjskega cikla, ki dopolnjuje skupino projekta in komponente (značilnosti skupine
projekta). Delovne predmete in druge artefakte, kot so testni primeri, je mogoče uvrstiti zoper
strukture/hierarhije za učinkovitejše sledenje in poročanje. [39]
4.5 Testiranje po testnem načrtu
Testiranje vključuje izdelavo testnega načrta, ki zajema zahteve za določeno obdobje
testiranja.
Načrtovanje testiranja je najpomembnejša dejavnost, ki na začetku v osnovnem načrtu
zagotovi listo opravil in mejnikov za spremljanje napredka projekta [40]. Prav tako določi
velikost testnega napora.
Testni načrt je glavni dokument, ki pogosto imenujemo »master test plan« ali testni načrt
projekta, ki ga običajno razvijemo v zgodnji fazi projekta [40]. Testni načrt vsebuje
informacije o procesu zagotavljanja kakovosti.
Parametri testnega načrta [48]:
• Identifikator testnega načrta: edinstvena identifikacijska referenca.
• Uvod: kratek uvod projekta in dokumenta.
• Testni predmeti: testni predmet je predmet programske opreme.
• Testiranje funkcije: je funkcija, ki jo je potrebno testirati na testni programski opremi.
• Funkcija, ki je ni potrebno testirati: identificiramo razloge, zakaj funkcija ni vključena
v testiranje.
• Pristop: splošne podrobnosti o pristopu testiranja.
41
• Uspešen/neuspešen kriterij predmeta: dokumentiramo uspeh ali neuspeh pri testiranju
predmeta programske opreme.
• Testni rezultati: testne rezultate pridobimo iz testnega procesa, testnih načrtov, testnih
specifikacij in iz testnih zbirnih poročil.
• Testna opravila: opravila za načrtovanje in izvajanje testiranja.
• Potrebe okolja: definiramo zahteve okolja, kot so strojna oprema, programska oprema
operacijskega sistema, konfiguracija omrežja itd.
• Odgovornosti: navedemo seznam vlog in opravil za člane skupine.
• Potrebe po zaposlovanju in usposabljanju: zajamemo dejanske zahteve zaposlenih za
specifično usposabljanje.
• Urnik: navedemo datum izdaje izdelka in ključne mejnike.
• Tveganja in olajšave: visoko nivojska tveganja v projektu, predpostavke in načrt
olajšave za vsako določeno tveganje.
• Dovoljenja: zajamemo naslove in datume poteka dovoljenj, ki se nahajajo v
dokumentu.
Aktivnosti testnega načrta [40]:
• Določimo obseg in tveganja testiranja.
• Dokumentiramo strategijo testiranja.
• Prepričati se moramo, da so vključene vse dejavnosti testiranja.
• Določiti moramo vstopne in izstopne kriterije.
• Ovrednotimo testiranje.
• Načrtujemo, kdaj in kako začeti s testiranjem, in se nato odločimo za način
vrednotenja testov ter določimo izstopni testni kriterij.
• Testni artefakt je del testne izvedbe.
• Definiramo informacije o vodenju, vključno z zahtevanimi meritvami, rešitvami nad
napakami in tveganji.
• Zagotovimo, da testna dokumentacija generira ponovljive teste.
Standard IEEE 829-20081 se uporablja kot referenca za oblikovanje strukture dokumentacije
testnega načrta projekta. Pregled dokumenta mora imeti povezave do podrobnosti, ki ga lahko
izdelamo bodisi v orodju TFS (Team Faundation Server) ali v drugih dokumentih. Testne
specifikacije vsebujejo podrobnosti o tem, katere funkcije testirati, o testnih primerih,
združevanju testov v kategorije, prioritetah testov in tako naprej. Večino del je lahko
42
opravljenih v TFS z uporabo seznama zahtev izdelka (ang. Product Backlog) in testnih
primerov. Da pa bi dobili dober pregled, bi morali delati po testni matriki, saj bi s tem
zmanjšali obseg testnih primerov. V primeru spremembe zahtev lahko z uporabo testne
matrike poiščemo ustrezne teste z določeno prioriteto ali seznam vseh avtomatiziranih testov.
[12]
V orodju Microsoft Test Manager (MTM) ali Team Web Access (TWA) testni načrt definira
način testiranja in rezultate testov. Vsi testi so načrtovani in izvedeni v okviru testnega načrta.
Skupina projektov ima običajno več testnih načrtov, ki so ločeni za vsak cikel (ang. Sprint),
mejnik ali drugo iteracijo. Pri razvoju več funkcionalnih področij hkrati je dobro ločiti testne
načrte za vsako področje. [16]Testni načrt je vključen v skupino projekta, ta pa je vključen v
zbirke projekta, ki gostujejo na strežniku skupine. [16]
Testni načrt vsebuje več testnih garnitur. Pri razvoju programske opreme je testna garnitura
zbirka testnih primerov, ki se uporabijo za testiranje programske opreme. S testnimi primeri
preverimo odzivanje programske opreme. Testna garnitura vsebuje podrobna navodila ali cilje
za vsako zbirko testnih primerov in informacije o uporabljeni konfiguraciji sistema med
testiranjem. Skupina testnih primerov vsebuje predpogoje stanj ali korakov in opise naslednjih
testov. Zbirko testnih primerov po navadi imenujemo testni načrt, testna skripta ali celo testni
scenarij, kar pa seveda ni pravilno. Testne garniture združujejo skupaj sorodne testne primere.
[41]
43
Testni primeri so pogosto imenovani kot testne skripte, in to takrat, ko jih združimo v testne
garniture. Testni primer je niz pogojev s pomočjo katerih tester ugotovi, ali programska
oprema deluje pravilno, kot je bilo zadano v začetku projekta. Pred izdajo programske opreme
v produkcijo moramo s številnimi testnimi primeri preveriti njeno pravilno delovanje. [17]
Slika 8 je izdelana na podlagi naše študije in prikazuje medsebojni odnos skupine projekta,
testnih načrtov, testnih garnitur in testnih primerov v orodju Visual Studio 2013, kot je bilo
opisano zgoraj.
Slika 8: Testni načrt
44
Visual Studio Ultimate, Visual Studio Premium in Test Professional vsebujejo orodje
Microsoft Test Manager, ki z uporabo testnih načrtov definira in upravlja s testnim naporom.
Najprej izdelamo testni načrt, v katerega dodamo testne garniture, testne primere ali določene
konfiguracije, kot je prikazano v spodnji sliki (Slika 9). Konfiguracija določa pristop, ki ga
bomo uporabili pri izvajanju testnih garnitur oziroma testnih primerov. [42]
Slika 9: Struktura testnega načrta v orodju MTM [42]
V MTM obstaja več načinov za izdelavo testnih načrtov in testnih primerov. Eden od načinov
je, da ustvarimo testni načrt, ki vsebuje vse mejnike, testne garniture ter teste v izdelavi. Pri
uporabi tega načina izgubimo vso zgodovino testnih rezultatov predhodnih mejnikov, zato je
bolje, da ustvarimo testne načrte, ki temeljijo na testnih ciljih za določeno iteracijo ali mejnik.
Testni načrt mejnika ima informacije o roku poteka za določen mejnik. Nov testni načrt za
mejnik izdelamo po izteku testiranja trenutnega mejnika, s tem lahko spremljamo napredek za
posamezen testni načrt in kakovosti aplikacije.
45
5 Tipi testiranja v orodju Visual Studio 2013
Visual Studio 2013 ima na voljo številna orodja, namenjena za testerje. Poglavje se prične s
pregledom tipov testiranja, ki so na voljo v programu Microsoft Test Manager in Visual
Studio 2013, omenili bomo tudi ročno in avtomatsko testiranje. Predvsem bomo izpostavili
sposobnost za avtomatizacijo testov User Interface (UI) s pomočjo UI kodirnih testov. Potem
bomo izpostavili zmogljivostne teste za spletne in namizne aplikacije, ki zagotovijo
nezmotljivo delovanje spletnih strani in namiznih aplikacij pod obremenitvijo.
Visual Studio omogoča podporo avtorizacije in izvršitve različnih testnih tipov, od katerih ima
pri testiranju aplikacije vsak drugačen namen. Uspešen testni načrt vsebuje mešanico različnih
testnih tipov, ki so:
• Ročno testiranje potrebuje človeško roko za interakcijo z aplikacijo, ki mora preveriti
pričakovane rezultate ter poročati o uspešnosti testiranja. Je edini tip, ki ga zastopa
Visual Studio Team Foundation Server 2013 kot opravilo (testni primer) in ne kot
datoteko izvorne kode. [17]
• Kodirano testiranje UI zagotavlja avtomatsko interakcijo z uporabniškim
vmesnikom aplikacije, ki preveri nekatere pričakovane rezultate in datoteke, če se v
njih nahajajo napake. Proces tega tipa je avtomatski in ga lahko izvajamo zelo
pogostokrat brez človeške interakcije, vendar ti testi postanejo finančno
nesprejemljivi, ko pride do vzdrževanja. Ročno testiranje je ceneje od UI avtomatskih
testov. [17]
• Testiranje enote so testi nizkega nivoja, ki preverjajo kodo programske opreme po
pričakovanjih razvijalcev. Test enote je koda, ki testira drugo kodo. [17]
• Spletno testiranje preverja funkcionalnost in zmogljivost spletne aplikacije. Primer
testa zmogljivosti je registracija uporabnika na spletni strani in je eden izmed testnih
garnitur, ki preverjajo delovanje spletne strani po naših pričakovanjih. [17]
• Zmogljivostno testiranje preverja odziv aplikacije. Sistem obremenimo z različnimi
testi, kjer si Visual Studio zabeleži podatke odziva sistema in jih pretvori v poročilo.
Zmogljivostni testi izhajajo iz nabora spletnih testov ter testov enot, saj lahko
zmogljivost namizne aplikacije testiramo tudi z njimi. [17]
46
• Generično testiranje omogoča sklic nadomestnega zunanjega testnega sistema. Za
primer imamo testno garnituro, ki vpliva na nek testni paket nekje zunaj. Rezultati
testov se lahko avtomatsko razčlenijo, iz njih pa se določi uspeh. [17]
• Sekvenčno testiranje je zaboj obstoječih testnih tipov, ki so urejeni po določenem
vrstnem redu, in omogoča večkratno izvedbo testov. [17]
• Raziskovalno testiranje je odprt pristop testiranja, ki ne uporablja nobenega procesa
ali testnega primera, ampak uporablja samo uporabniške zgodbe. Cilj testiranja je
preveriti funkcije aplikacije, poiskati napake, pretrgane povezave in morebitne
izboljšave sistema. Ta tip testiranja se uporablja že vrsto let, saj ni bilo nobenega
drugega orodja za testiranje, iskanje in odpravo napak. [10]
• Microsoft Test Manager ima nove funkcionalnosti, ki podpirajo raziskovalno
testiranje, zajemanje posnetkov zaslona, testne postopke, testne primere, komentarje,
priloge itd. [10]
Pri testiranju enega dela aplikacije lahko uporabimo več različnih tipov testiranja. Za
preverjanje funkcionalnosti spletne aplikacije lahko uporabimo kodiran UI test in
zmogljivostni test. Ko bomo postali bolj seznanjeni s kodirnimi UI testi v primerjavi z
zmogljivostnimi testi, bomo ugotovili, da je prvi boljše zasnovan za validacijo funkcionalnosti
in urejenost uporabniškega vmesnika, medtem ko je drugi boljši pri preverjanju zmogljivosti
in razširljivosti. Kdaj in kako izbrati pravilen testni tip bomo podrobneje predstavili v
naslednjih poglavjih. [17]
47
Tabela 3 prikazuje lastnosti, ki jih podpirajo različne izdaje orodja Visual Studio 2013.
Tabela 3: Naštete lastnosti po izdajah orodja Visual Studio 2013 [13]
Tipi testiranja Visual
Studio
Ultimate z
MSDN
Visual
Studio
Premium z
MSDN
Visual
Studio Test
professional
z MSDN
Visual
Studio
professional
z MSDN
Visual
Studio
professional
Testiranje
enote
Da Da Da Da
Kodirano
testiranje UI
Da Da
Testiranje
pokritosti
kode
Da Da
Ročno
testiranje
Da Da Da
Raziskovalno
testiranje
Da Da Da
Upravljanje
testnih
primerov
Da Da Da
Spletno
testiranje
Da
Zmogljivostni
test
Da
Testiranje na
virtualnih
sistemih
Da Da Da
Visual Studio Premium vsebuje vse funkcionalnosti orodji Visual Studio Professional in
Visual Studio Ultimate, ki vsebuje vse funkcionalnosti orodja Visual Studio Premium. Visual
Studio Premium in Ultimate vključujeta funkcionalnosti, ki jih ima Visual Studio Test
Professional. [20]
48
5.1 Avtomatsko testiranje
Skupna zahteva avtomatskih testov je, da se lahko večkrat ponovijo z različnimi parametri.
[12] Uporabijo se tudi pri testiranju nefunkcionalnih zahtev.
Enemu avtomatskemu testu lahko dodamo spletno in zmogljivostno testno sejo, ki validira
smiselnost in uporabnost sistema. Visual Studio 2013 podpira številne testne tipe naštete v
spodnji tabeli (Tabela 4), vse od osnovnih testov enot do avtomatiziranih UI testov ter
zmogljivostnih testov. Slika 10 prikazuje konsistentno dodajanje testnega tipa v orodju Visual
Studio.
Slika 10: Dodajanje testnega tipa
Tabela 4: Podprti testni tipi v Visual Studio 2013 [12]
Tipi testov Namen
Osnovni test enote Test enote brez predloge.
Test enote Ima predlogo in dodatne testne atribute.
Kodiran UI test Kodiran test uporabniškega vmesnika.
Kodiran UI Map Kodirane UI teste razdeli na manjše dele.
Generični test Zavije obstoječo funkcijo v MS test.
Sekvenčni test Krmili izvajanje številnih različnih testnih tipov.
Spletno testiranje Snema testiranje spletne strani s pomočjo brskalnika Internet
Explorer.
Zmogljivostni test S pomočjo čarovnika generiramo konfiguracijo
zmogljivostnega testa.
Vsi testni tipi so shranjeni v orodju Visual Studio kot izvorna koda, razen ročnega testiranja
(ki je predstavljen kot opravilo v orodju TFS). Testi v orodju Visual Studio so shranjeni v
49
predelu, kjer se nadzorujejo viri, podobno kot v orodju TFS, le da so testi v obliki zahtev.
Sčasoma vsebina projekta začne naraščati s številnimi testnimi garniturami, ki pripomorejo k
testiranju funkcionalnosti programske opreme. Testi so ključnega pomena za uspeh projekta,
zato ni nič neobičajnega za projekte, ki vsebujejo na desetine, včasih celo na stotine, testov.
[22]
5.1.1 Spletno testiranje
Spletno testiranje preverja odziv spletne aplikacije, tako da naenkrat izvede serijo
HTTP/HTTPS zahtev zoper spletne aplikacije ter analizira njena pričakovana odzivanja. [22]
Bistvo spletnega testiranje je prikazovanje pravilnih rezultatov spletne strani v pričakovanem
odzivnem času. Problem je potrebno ugotoviti in odpraviti v najkrajšem možnem času, da se
ta ne zgodi v dejanskem produkcijskem okolju. Zmogljivost strojne opreme preverimo s
pošiljanjem zahtev v določenem času ter na podlagi ugotovitev ugotovimo, ali potrebujemo
dodatno strojno opremo, ki bo brezhibno upravljala s prometom in se odzivala na številne
uporabniške zahteve ob pravem času. [13]
Predstavili bomo nekaj glavnih napotkov testiranja, ki izboljšajo zmogljivost in
razpoložljivost spletne aplikacije [13]:
• Validacija in verifikacija preverjata pričakovane vhodne podatke, vnesene po
zahtevah. Npr.: imamo vnosno polje, ki zahteva datum. Sistem mora preveriti pravilen
vnos datuma in ne sme spustiti uporabnika na naslednjo stran, dokler ne vnese
pravilne vrednosti.
• Testiranje uporabnosti spletne strani je metoda testiranja v produkcijskem ali testnem
okolju, kjer se simulira praktična uporabnost aplikacije za uporabnika. Preverijo se
povezave, vsebine strani, izbira menija in pogovorna okna s sporočili.
• S testiranjem varnosti preverimo odziv aplikacije na podlagi različnih končnih
uporabnikov, ki imajo različne varnostne nastavitve lokalnega sistema ali strežnika,
priključenega v omrežje. Primer je pisanje/branje podatkov log datoteke na omrežnem
centru.
• Zmogljivostni test preveri odziv spletne strani glede na pričakovanja, ki temeljijo na
okolju. To vključuje stresno in zmogljivostno testiranje aplikacije z upoštevanjem
številnih uporabniških scenarijev in obsega podatkov.
50
• Kompatibilnost spletne strani preverimo z več različnimi brskalniki glede na zahtevo
uporabnikov. Predstavitev spletne strani je odvisna od uporabljenih komponent in
podpore različnih brskalnikov.
• Testiranje spletne strani na različnih omrežjih je potrebno zaradi različnih lokacij
uporabnika. Učinkovitost in dostopnost aplikacije je neposredno vezana na omrežje, ki
zagotovi spletno stran uporabniku. Npr.: lahko testiramo z lokalnim intranetom ali z
intranetom s počasno hitrostjo omrežja.
Spletno testiranje ima še druge tipe testiranja, kot je uporaba različnih operacijskih sistemov z
uporabo različnih podatkovnih baz ali namestitvijo več različic operacijskega sistema.
Vsi testni tipi s številnimi dodatki so podprti s strani orodja Visual Studio. Dinamične spletne
strani lahko izdelamo z .NET jezikom, ki ga podpira Visual Studio z uporabo ASP.NET
projekta in predloge. Pri izdelavi spletne strani uporabimo komponente, knjižnice in po meri
izdelane storitve, da postane bolj dinamična in funkcionalna. Skriptni jeziki in druge
tehnologije, kot so JavaScript, Silverlight in Flash se uporabljajo za validacijo in boljšo
predstavitev spletne strani na klientovem računalniku. Končano spletno aplikacijo naložimo in
preverimo skladnost funkcionalnosti z zahtevami. Bistvo vsega tega je, da Microsoft Visual
Studio ponuja orodja za testiranje spletnih aplikacij na različne načine. Eden od načinov je
uporaba uporabniškega vmesnika, ki snema in doda spletni strani parametre in pravila za
vrednotenje, da poveča njeno dinamičnost. Drugi način posname zahtevo ter generira kodiran
spletni test na podlagi posnetega spletnega testa, ki ga prilagodi z uporabo generirane kode.
[13]
Testi zmogljivosti so shranjeni v XML datoteki, ki ima pripono ».webtest«. V času izvajanja
testa zmogljivosti Visual Studio generira kodo, ki se zapiše v XML datoteko. Kodirani spletni
testi imajo več funkcij testiranja, kot pa standardni spletni testi in so omejeni le na našo
sposobnost kodiranja. Jezik za generiranje kode je določen v testnem projektu, kjer je
shranjena vsebina spletnih testov. [22]
Za kodiran spletni test obstaja razred v .NET, ki generira zaporedje spletnih zahtev v vrstnem
redu snemanja. Razred je lahko napisan v jeziku C# ali Visual Basic. [13]
Na prvi pogled so morda testi zmogljivosti podobni kodirnim UI testom, vendar se nekatere
zmogljivosti prekrivajo (kot so snemanje, predvajanje in validacija na odziv). Ta dva tipa sta
oblikovana za doseganje različnih ciljev in ju je potrebno ustrezno uporabljati. Spletni testi bi
se morali uporabljati striktno za testiranje zmogljivosti in kot osnova za generiranje testa
zmogljivosti. UI testi zagotovijo pravilen odziv uporabniškega vmesnika in njegove
51
postavitve, vendar jih ne moremo nadomestiti s spletnimi testi. Nasprotno lahko spletne teste
kodiramo, tako da preverijo odzive sistema, vendar so kodirani UI testi veliko bolj primerni
za to nalogo. [22]
5.1.2 Zmogljivostni test
Zmogljivostni test testni ekipi pripomore pri razumevanju delovanja aplikacije pod različnimi
pogoji. Različni pogoji in parametri se uporabljajo za testiranje zmogljivosti aplikacije.
Simulira lahko kombinacije številnih uporabnikov, omrežne pasovne širine, spletne brskalnike
in različne konfiguracije. Spletne aplikacije vedno testiramo z naborom različnih uporabnikov
in brskalnikov, ki simulirajo pošiljanje številnih zahtev na strežnik hkrati. [49]
Slika 11 prikazuje primer scenarija z več uporabniki, ki dostopajo do spletne strani z različnih
omrežij, brskalnikov in lokacij.
Slika 11: Prikaz scenarija z več uporabniki, ki dostopajo do spletne strani z uporabo različnih omrežij, brskalnikov in lokacij [13]
Testi zmogljivosti se lahko uporabijo za preverjanje dostopnosti aplikacije do podatkov,
vendar niso omejeni samo na spletne aplikacije, ampak tudi na druge (namizne aplikacije
itd.). Zmogljivostni test identificira zmogljivost aplikacije pod različnimi obremenitvami, pri
manjših obremenitvah, pri večjih obremenitvah in pri obremenitvah z enako stopnjo bremena,
vendar trajajo različno dolgo.
Zmogljivostni testi uporabljajo kontrolorje (Controllers) in številne zastopnike (Agents), ki
kot skupina predstavlja ogrodje. Zastopniki zastopajo računalnike na različnih lokacijah.
52
Zastopnike nadzira centralni računalnik, ki se imenuje kontrolor. Visual Studio Load Agent v
zastopniških računalnikih ustvari dejansko breme za testiranje, kot je simulacija več prijav in
dostopov do spletnih strani. V tem primeru je naloga zastopnika zbiranje in evidentiranje
podatkov iz testa, medtem ko kontrolor nadzoruje zastopnike. Spletne strani pogosto obiskuje
in dostopa do njih zelo veliko število uporabnikov hkrati iz različnih lokacij, zato je nujno
potrebno simulirati dejansko stanje in delovanje aplikacije pred namestitvijo na glavni
strežnik. [13]
Zmogljivostno testiranje s stresnim testom številnih uporabnikov preveri aplikacijo. Pri
simulaciji lahko nastavimo stopnjo obremenitve in šele nato izvedemo test. Generiramo serijo
zahtev zoper ciljne aplikacije, kjer Visual Studio nadzira sistem, da lahko določi delovanje
aplikacije pod pritiskom testiranja. Zmogljivostno testiranje se najpogosteje uporablja pri
spletnem testiranju. Skozi vsebino smo spoznali, da je zmogljivostno testiranje seznam
kazalcev, ki kažejo na druge teste z različnimi tipi, z izjemo ročnega testiranja. [22]
5.1.2.1 Cloud-based load testiranje
Zmogljivostni test oblaka je na voljo kot del Visual Studia Online in je novost v Visual Studio
2013.
Z virtualnimi napravami generiramo zmogljivostne teste, kjer številni uporabniki dostopajo do
spletne strani ob enakem času. Pri testiranju zmogljivosti spletne strani ni potrebno
vzpostaviti lastnih računalnikov, ampak mora biti spletna stran javno dostopna na internetu za
izvedbo testa zmogljivosti z orodjem Visual Studio Online. [22]
5.1.3 Kodirano testiranje UI
Pri testiranju kode uporabniškega vmesnika se uporabljajo testi enote, vendar to ni dovršen
test nad celotnim uporabniškem vmesniku, saj mora test preveriti vse gumbe, sprejemljivost
okna ter njegovo vsebino. CUITs (Coded UI tests) so avtomatski testi, ki preverjajo
uporabniški vmesnik. [50]
UI teste lahko izdelamo na hiter in enostaven način. Namenjeni so samo za dva namena:
testiranje lažne poslovne logike uporabniškega vmesnika in testiranje sistema celotne
aplikacije. Prednost UI testov je hitra in enostavna izdelava, kar pomeni, da je njihovo
področje malo bolj razširjeno od drugih. Predstavili bomo na kakšen način se pogosto
uporablja kodiran UI test. Recimo, da imamo manjšo namizno aplikacijo, ki dostopa do baze
podatkov. Poslovno logiko neposredno vodi uporabniški vmesnik, zato testerji pogosto na
zelo hiter način izdelajo test za poslovno logiko, tako da posnamejo kodirane UI teste za
53
glavne funkcionalnosti aplikacije, namesto da bi preverili podatkovno bazo s testnimi podatki
in viri. Večina testerjev meni, da je s tem načinom čas bolje uporabljen tako, kot pa pisanje
kode za testiranje poslovne logike. Sčasoma je svetovalce metodologije način testiranja
poslovne logike s pritiskom in klikom na gumbe uporabniškega vmesnika začelo vznemirjati,
saj s tem mešamo uporabniški vmesnik in poslovno logiko skupaj in zanemarjamo vse dobre
lastnosti inženiringa programske opreme, ki ju ločujemo drug od drugega. S spreminjanjem
uporabniškega vmesnika bi izgubili uporabnost obstoječih testov enot za poslovno logiko.
Realistično gledano UI teste izdelamo takrat, ko je aplikacija končana, vendar ta način ne
omogoča progresivnega testiranja, ki glede na ideje in razprave izboljša in bolje definira
namen sistema, preden ga začnemo kodirati. Iz tega razloga se kodirani UI testi ne uporabljajo
za testiranje poslovne logike. [21]
Avtomatski test je posnet iz korakov ročnega testiranja, ki lahko posnetek ponovi, ne da bi
ročno ponovili celoten test. Drugi način je, da napišemo skripte, ki uporabljajo programski
jezik za avtomatizacijo nivoja storitve. Največji izziv je bila avtomatizacija uporabniškega
vmesnika, vendar je z današnjimi orodji to enostavno opraviti, saj nekatera zagotavljajo
snemanje akcij uporabnikov, iz katerih izdelajo skripte. Enostavnejša izdelava kodiranega UI
testa je v orodju Visual Studiu 2013, ki obstoječe ročno izdelane teste, testne primere in
posnete akcije generira v avtomatske teste in kodo, ki jo lahko upravljamo (C# ali VB.NET).
Kodiran UI test je mogoče zagnati neposredno iz orodja Visual Studio ali orodja Microsoft
Test Manager, ki je povezan z zahtevami, ki določijo število avtomatskih testov ter zbirajo
testne rezultate. [13]
5.1.3.1 Kodiran UI test za Windows Store aplikacijo
Windows Store aplikacija je nov tip aplikacije, ki je podprta na Windows 8 platformi in jo je
zelo enostavno namestiti in odstraniti. Kot privzeto so prikazane v enem oknu, ki zapolni
celoten zaslon, in avtomatsko podpirajo vhodne naprave, kot so: dotik na zaslon, risalno
tablico, miško, tipkovnico. Namesto statičnih ikon uporabljajo žive plošče, ki prikazujejo
obvestila. Windows Store aplikacije lahko razvijamo v različnih jezikih, kot so C# in Visual
Basic z XAML, C++ z XAML ali DirectX in JavaScript s HTML/CSS. [23]
Microsoft ponuja dve brezplačni orodji namenjeni za skupno delo, ki pomagata razviti,
preizkusiti in namestiti Windows Store aplikacije. To sta: Microsoft Visual Studio Express
2013 za Windows 8.1 in Blend za Visual Studio. (Ti orodji zahtevata operacijski sistem
Windows 8.1.). [23]
54
5.1.4 Sekvenčno testiranje
Do sedaj smo na kratko omenili test enote ter podrobno pojasnili vloge in uporabnost ročnega
testiranja, spletnega testiranja, kodiranega UI testiranja in zmogljivostnega testiranja. Visual
Studio omogoča dodaten tip testiranja, ki grupira in razvršča testne tipe v določen vrstni red;
takšen način imenujemo sekvenčno testiranje. Prednost sekvenčnega testiranja je, da nam
omogoči izvedbo testov v vrstnem redu glede na njihovo odvisnost. Za primer odvisnosti
imamo spletni test, ki je odvisen od rezultatov testa enote, torej mora biti test enote izveden
pred izvršitvijo spletnega testa. [13]
5.1.5 Generično testiranje
Generični testi so tako kot vsi drugi testi, vendar pri izvedbi uporabljajo zunanje orodje ali
program, ki ga lahko zaženemo preko ukazne vrstice. [51]
Generični testi integrirajo zunanje teste v Visual Studio. To so lahko aplikacije, ki uporabljajo
zunanje komponente ali storitve in jih je potrebno testirati kot del celotnega sistema.
Podrobnosti in notranja logika zunanje komponente je neznana in ni izpostavljena. Generični
testi v Visual Studio delujejo kot ovoji za testiranje zunanjih komponent. Ko so oviti,
izvedemo teste kot vse ostale s pomočjo orodja Visual Studio IDE. [13]
Zunanje komponente morajo upoštevati naslednje pogoje, da jih lahko razvrstimo na podlagi
generičnega testa v Visual Studio [51]:
• Izvršimo jih z ukazne vrstice.
• Vedno ko je komponenta izvršena iz ukazne vrstice, mora vrniti logično vrednost
(True ali False).
• Vrniti mora podrobne rezultate testov komponente.
5.1.6 Testiranje enote
Test enote je sestavljen iz kode in za razliko od drugih testnih tipov preverja sistem na nižjem
in granularnem nivoju. Testi so hitro postali standardna praksa mnogih organizacij. Izdelujejo
in uporabljajo jih programerji v vseh izdajah orodja Visual Studio z vsemi funkcijami
testiranja enot, ki so v celoti vključene v IDE, in drugimi funkcijami (kot so poročanje in
nadzor izvorne kode). Razvijalcem se ni potrebno več zanašati na zunanje storitve (kot je
NUnit) za izvedbo testa enote, vendar so še vedno na voljo in jih lahko integrirajo v Visual
Studio le z uporabo testnega adapterja. Testiranje enote je primer testiranja po beli škatli, kjer
se poznavanje notranje strukture uporabi za opredelitev učinkovitega načina testiranja
55
sistema. Dopolnjuje pristop testiranja po črni škatli, kjer poudarek ni na podrobnosti
implementacije, temveč na ujemanju funkcionalnosti s specifikacijami. Najbolj učinkovito
testiranje aplikacije je uporaba obeh pristopov testiranja. [17]
5.1.6.1 Testiranje enote z orodjem Visual Studio
Visual Studio omogoča izdelavo in avtomatizacijo testov enot, ne glede na tip metode
(privatna ali javna). Test enote je razred, ki je podoben drugim razredom in metodam, vendar
ima ta razred dodatne atribute, ki predstavljajo testne razrede in metode. Razrede in metode
lahko izdelamo ročno ali z generiranjem osnovne kode pod opcijo Create Unit Tests in jo
potem prilagodimo našim potrebam. Generirana koda testov enot vsebuje posebne lastnosti, ki
so dodeljene znotraj razreda in metod. Testni razred je označen z atributom TestClass() in
vsaka testna metoda s TestMethod(). Poleg teh dveh atributov obstajajo še številni, ki se
uporabljajo za testiranje enot. Generirani testni razredi in metode uporabljajo Assert metode
za preverjanje pričakovane vrednosti z dejansko vrednostjo. Vsi testni razredi in metode so
definirani znotraj imenskega prostora Microsoft.VisualStudio.TestTools.UnitTesting, zato
mora vsak izdelan test enote vsebovati ta imenski prostor. Eden izmed glavnih razredov je
TestContext, ki zagotavlja informacije za teste enot. [13] Spodaj naveden primer prikazuje
testni razred z imenom Class1Test in metodo z imenom TestMethod1, ki vsebuje Assert
metodo AreEqual. Na takšen način Visual Studio generira osnovno kodo za testiranje enote, ki
si jo lahko sami prilagodimo.
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
{
[TestClass()] //Testni razred.
public class Class1Test
{
[TestMethod()] //Testna metoda.
public void TestMethod1()
{
Assert.AreEqual(pricakovanaVrednost, dejanskaVrednost); //Atribut
//Assert, ki preverja pričakovano vrednost z dejansko
}
}}
56
5.1.6.2 Pisanje učinkovitih testov
Testiranje enote je samo po sebi kodiranje, pri katerem smo neomejeni pri številnih pristopih
razvijanja testov, vendar moramo upoštevati nekaj splošnih smernic [17]:
• Vedno ločimo skupino testov enot od kode, ki jo testiramo. S tem ločimo teste enot od
inštalacijskega paketa aplikacije, ki nimajo nobenega pomena v produkcijskem okolju.
• Izogibajmo se spreminjanju kode v prid izdelave enostavnih testov enot. Pogosta
napaka je neposreden dostop testov do članov razreda (class members); s tem
zmanjšamo enkapsulacijo in širimo zunanjo interakcijo. To naredi kodo, ki jo bomo
morali v bližnji prihodnosti redno vzdrževati, enostavnejšo za testiranje,.
• Vsak test bi moral preverjati manjši košček funkcionalnosti. Slaba praksa je pisanje
dolgih zaporednih testov enot. Manjše teste je lažje vzdrževati, saj lahko preverimo,
katera funkcionalnost preverja test, in hitro identificiramo ter odpravimo napako.
• Vsi testi bi morali biti samostojni in izolirani. Izogibamo se izdelavi testov, ki se
navezujejo na drugi test. Testi morajo biti izvršljivi v katerikoli kombinaciji in v
kateremkoli vrstnem redu. Z izvajanjem testov preverimo, ali smo teste postavili v
pravilen vrstni red. V primeru nepravilnega izvajanja mu spremenimo vrstni red.
• Testiramo pričakovano obnašanje (običajni delovni postopek) in stanja napak (izjeme
in neveljavne operacije). Za eno metodo je dobro imeti več testov enote, vendar
razvijalci vedno poiščejo lažji način za klicanje objektov, ki pa ni pravilen. Pri
testiranju moramo vedno pričakovati nepričakovano, kodirajmo defenzivno in
zagotovimo, da v različnih razmerah reagira ustrezno.
Ključen pomen učinkovitega testiranja enote je prihraniti čas pri razvoju in vzdrževanju.
Sčasoma spoznamo, kako pomembno je pridobiti čas.
5.1.6.3 Testiranje enote za Windows Store aplikacije
Visual Studio 2013 nam ponuja izdelavo testov enot za Windows Store aplikacije, ki so del
Team Build. Ustvarimo lahko teste enote za Windows Store aplikacije in te teste poženemo z
orodjem Visual Studio in kot del Team Build. [43]
57
5.2 Ročno testiranje
Ročno testiranje v razvojni industriji programske opreme v primerjavi s specializiranimi ali
avtomatskimi testi še vedno predstavlja približno 70 odstotkov testiranja. Namen izdelave
orodja za ročno testiranje je bil postavljen v ozadje, vse dokler ga ni izdelal Visual Studio
2010 in ga namenil za splošne testerje. Splošni tester je oseba, ki ročno testira programsko
opremo in ima neposreden stik z njo. Programsko opremo testiramo kot uporabniki in si
beležimo napake, ko naletimo na luknjo v funkcionalnosti ali na nepričakovana odzivanja.
Microsoft je še naprej izboljševal orodje za ročno testiranje in predstavil nove funkcionalnosti
v Visual Studio 2013. [17]
Slika 12 prikazuje preprosto shemo ročnega testiranja:
Slika 12: Shema ročnega testiranja [12]
Proces ročnega testiranja se prične z načrtovanjem, kjer si pomagamo z zahtevami. V načrtu
je potrebno določiti zahtevnost testiranja za preverjanje skladnosti zahtev z implementacijo.
Nato izdelamo testne primere, vzpostavimo testno okolje in testne konfiguracije. Z dobrimi
testnimi sredstvi bomo izvajali različne vrste testov, kot so raziskovalni testi, skriptni testi in
seveda avtomatizirani testi. Ob odkritju napake zapišemo in izdamo popravek ter spremljamo
njen odziv. Pri preverjanju popravka napake preprosto zaženemo testni primer, ki je odkril
napako. Ta cikel nekajkrat ponovimo in skozi čas poiščemo kandidate za regresijsko
testiranje. Potem se lahko odločimo za avtomatizacijo teh testov, tako bomo hitreje izvajali
testne cikle v prihodnje. Proces ročnega testiranja nas spominja na model slapa, ki je
zaporeden proces testiranja, vendar lahko v njem uporabimo iterativne in inkrementalne
postopke dela. V agilnem projektu vsako iteracijo načrtujemo, oblikujemo in testiramo.
Dejavnosti, kot sta integracijsko in avtomatsko testiranje, pogosto potrebujeta več časa za
izvedbo testiranja. Največ časa porabimo pri prilagajanju in planiranju teh dejavnikov, vendar
morajo biti predpogoji določeni. [12]
58
5.2.1 Microsoft Test Manager
Microsoft Test Manager je orodje, specifično namenjeno za splošne testne skupine. Omogoča
nam izdelavo in manipulacijo testnih načrtov, testnih primerov, izvedbo ročnih testov in
datoteke z napakami. [17]
Na visoki ravni Microsoft Test Manager obravnava [52]:
• načrtovanje testiranja
• oblikovanje testiranja
• izvedba in analiza testiranja
• poročanje o napaki z zbiranjem testnih rezultatov
• spremljanje opravil (prav tako napake)
• upravljanje testnega okolja
To je samostojen izdelek in ni del orodja Visual Studio 2013 Premium, ampak je del orodja
Visual Studio Profesional in Visual Studio Ultimate. MTM je funkcijsko testno orodje, ki
omogoča izdelavo in izvedbo ročnih testov. Je neodvisen od orodja Visual Studio, vendar
zahteva povezavo z orodjem Team Foundation Server in s skupino projekta. [13]
V orodju TFS so shranjeni testni načrti, testni primeri, poročila in rezultati napak izvedenih
testov s pomočjo orodja MTM. MTM spodbuja uporabo Team Foundation Build za gradnjo
programske opreme, čeprav lahko to storimo tudi v njem. [17]
5.2.1.1 Načrtovanje testa
V orodju MTM testni načrt vsebuje podrobnosti o testnem napredku in nizu testov (imenovani
testne garniture).
Priporočen je čim manjši obseg testnega načrta, najbolje je en načrt na cikel. Manjši načrti so
skozi celoten proces razumljivi in vodljivi, to lahko razberemo iz njihovega stanja. Zelo težko
je razumeti in razbrati napredek testnega načrta, če pokriva celoten projekt. Podatke manjših
testnih načrtov združimo v poročila projekta s pomočjo TFS poročil. [12]
Garniture zberejo teste, ki preverjajo funkcionalnosti v specifičnem testnem načrtu. Na voljo
so nam trije tipi testnih garnitur [13]:
• Statična testna garnitura (Static): statična garnitura je mapa, ki vsebuje testne primere
ali garniture.
• Garnitura na osnovi poizvedbe (Query-based): pridobi seznam testnih primerov glede
na rezultat definirane poizvedbe, ki jih nato dodamo v testno garnituro. Poizvedbo
59
lahko spreminjamo po želji, vendar se ob spremembi rezultata poizvedbe spremenijo
tudi testni primeri, ki so bili dodani v testno garnituro.
• Garnitura na podlagi zahteve (Requirements-based): garnitura vsebuje testne
primere, ki se navezujejo na določeno zahtevo.
Testni primer v orodju MTM predstavlja testna navodila za testerje. Implementiran je kot TFS
opravilo, ki ga lahko prilagodimo, tako da poda testerju informacije za dokončanje testiranja.
Testni primer lahko spremljamo in spreminjamo v vsakem TFS odjemalcu, medtem ko v njem
ne moremo spremljati testnih korakov, lahko jih samo v orodju MTM. [12]
Dejavnosti v MTM testerji opazujejo na armaturni plošči, kjer lahko preko nje opravimo
večino testnih opravil, izvajamo in analiziramo izvedbo testov, izvajamo in opazujemo seje
raziskovalnega testiranja ter spremljamo in preverjamo napake. [17]
5.2.1.2 Integracija gradnikov
Problemi se pojavijo, če ne vemo, katero verzijo sistema smo testirali in v kateri del kode smo
integrirali napako.
Rešitev napake je uporaba orodja TFS Build, s katerim ugotovimo, v katerem delu gradnika
testnega načrta se nahja koda, ki jo testiramo. Prav tako lahko v gradniku, ki je v postopku
preverjanja, avtomatsko odkrijemo in označimo napake. Če razvijalec odkrije spremembe
kode, ki se navezuje na določeno opravilo, lahko orodje TFS Build glede na konfiguracijo
opravilo označi kot integracijo gradnika. S povezovanjem testov in gradnikov dobimo veliko
dodatnih možnosti za testiranje. [12]
Assign Build v MTM je uporaben pri iskanju sprememb gradnika, ki smo ga pred časom
uporabljali, saj ugotovi, kateremu testnemu načrtu pripada. Svetuje nam, kdaj moramo
vpeljati nov gradnik ali počakati na več dokončanih funkcij in jih potem vpeljati v produkcijo.
[12]
Testing Center se uporablja za izdelavo testnih načrtov, testnih garnitur in testnih primerov
za določene testne načrte, povezane z zahtevami. Funkcije, ki jih podpira Testing Center so:
izvajanje ročnih testov, zajemanje testnih rezultatov in napak, spremljanje testnih rezultatov z
uporabo obstoječih in po meri izdelanih poizvedb, organizacije in skupnih ukrepov testnih
primerov ter vzdrževanje testne konfiguracije. [13]
Lab Center se uporablja za vzpostavitev in izdelavo laboratorijskih okolij za izvedbo
testiranja. Okolje izdelamo z uporabo fizičnih in virtualnih strojev ter naborom konfiguracij.
[13] Laboratorijska okolja uporabljamo za testiranje spletnih aplikacij, ki se izvajajo na
60
strežnikih. Komponente strežnika zaženemo na laboratorijskih napravah, medtem ko
brskalnik ali aplikacijo na lokalnem računalniku. Omogočijo nam zbiranje diagnostičnih
podatkov strežnika med izvajanjem testov z odjemalčevega računalnika. Če na primer
prijavimo napako v času testiranja, se bo prijava zapisala v poročilo napak in s tem
poenostavila diagnosticiranje. Okolje zagotavlja priročen način dodelitve računalnikov
testerjem. [44]
5.2.2 Team Web Access
Načrtovanje in spremljanje napredka razvoja programske opreme je preprosto, če
uporabljamo TWA. TWA nas poveže z določeno skupino projekta, opredeljeno v Visual
Studio TFS ali Visual Studio Online. Z njim upravljamo izvorno kodo, opravila, gradnike in
testna prizadevanja. [25]
Microsoft je v Visual Studio 2012 TWA uvedel upravljanje testnih primerov in možnost
izvedbe testov. V Visual Studiu 2013 TWA so bile dodane nove funkcije in zmožnosti za
izdelavo in urejanje testnih načrtov. Zaradi novosti ni potrebno uporabiti MTM za pregled in
izdelavo testnih načrtov, testnih garnitur in skupnih korakov izvedbe. Celotno upravljanje
testnih primerov je mogoče storiti iz TWA. [26]
TWA se poveže z Visual Studio TFS za upravljanje izvorne kode, opravil, gradnikov in
testnega prizadevanja. [26] Vsebina in opravila znotraj TWA so odvisna od pravic vsakega
uporabnika oz. uporabniške skupine.
TWA je idealen za uporabnike, saj jim ga ni potrebno namestiti na svoje računalnike.
Funkcionalnosti, ki jih ponuja TWA so [17]:
• planiranje seznam zahtev in iteracij,
• seznam opravil,
• ustvarjanje in urejanje opravil in njenih poizvedb,
• upravljanje področij in iteracij,
• administracija pravil in članstva ekip,
• pregled nad verzijami,
• skladiščenje in upravljanje definicij gradnikov.
Nove funkcije in opravila s prejšnjo verzijo [27]:
• izdelava testnega načrta,
• upravljanje testnih garnitur,
• izdelava testnih primerov vključno s skupnimi koraki in parametri za podporo,
61
• množično urejanje in vnašanje testnih primerov,
• prenos testnih primerov iz Excela,
• izvedba testov,
• urejanje testnih primerov med izvajanjem testov,
• testiranje Windows Store aplikacij na oddaljeni napravi z ročnimi testi.
5.2.3 Razlika med Microsoft Test Manager in Team Web Access
Microsoft Test Manager ima več funkcij kot Team Web Access, zato lahko za manj
kompleksne projekte uporabimo TWA.
Team Web Access omogoča izdelavo testnih primerov, ki jih razporedi v testne načrte in
garniture. Pri testiranju nam TWA prikaže testne korake in omogoča označbo neuspelega
koraka.
MTM ima več funkcij, kot so snemanje akcij, izdelava zaslonskih slik, dnevniki in drugi
diagnostični podatki. Z njim lahko upravljajo laboratorijska okolja. Vse te dodatne funkcije
nam omogoči Microsoft Test Runner.
Pri izbiri orodja se nam ni treba odločiti vnaprej, saj jih je na pretek in lahko še vedno
uporabimo druga orodja za urejanje testnih načrtov in izvajanje testov.
5.2.4 Test Runner
Test Runner omogoča snemanje dejanj, ki jih uporabimo za hitri pregled skozi testne korake v
prihodnjem testiranju. Ta način testiranja imenujemo hitro ročno testiranje, saj predvajanje
akcij pospeši ročno testiranje in s tem dokaže, da lahko na ta način hitreje izvajamo in
predvajamo teste, kot jih lahko izvaja človek. Posnetki olajšajo delo splošnim testerjem in jim
popestrijo delo s preučevanjem aplikacije, namesto opravljanja dolgočasnega dela, kot je
večkratno klikanje in vnašanje testnih podatkov v vnosna polja aplikacije. [17]
MTM v začetku testiranja prikaže Test Runner, ki je drugi del orodja. Pri izdelavi testa se
moramo odločiti, ali bomo akcijo snemali. Snemanje akcij posname vse interakcije
uporabnika z aplikacijo ter na podlagi teh Test Runner generira skripto za samodejno
testiranje v orodju MTM ali orodju Visual Studio. [12]
Funkcije, ki jih omogoča Microsoft Test Runner so [29]:
• Pri opisu napak so samodejno vsebovane naslednje funkcije:
o Slike zaslona akcij.
62
o Posnetek dejanj, ki smo jih izvajali: v posnetku je zajeto vse in ne samo testni
koraki, ki smo jih opravili.
o Informacije sistema, kot so verzija operacijskega sistema in id naprave.
• Ponovi naša storjena dejanja, to nam omogoči hitro in učinkovito izvedbo istega testa.
• Med testiranjem zbira dodatne diagnostične podatke.
5.2.5 Testiranje Windows Store aplikacij
Obstajajo dve možnosti testiranja Windows Store aplikacij, ki se izvajajo na telefonu,
tabličnem računalniku ali drugi napravi [45]:
• S TWA načrtujemo in izvajamo testiranje naprave, ki je povezana z brskalnikom ali
računalnikom. Pri testiranju z TWA Test Runner nima interakcije s programsko
opremo, ampak prevzame vlogo kontrolorja nad seznamom testnih korakov, zato ga ni
potrebno izvajati na napravi, ki jo testiramo. Ta možnost ne zahteva posebnih priprav
na napravi, razen namestitev programske opreme.
• MTM ima možnost do snemanja zaslonskih slik in zbiranja diagnostičnih podatkov
naprave.
5.2.6 Raziskovalno testiranje
S formalnim vodenjem testnih primerov testna ekipa začne s seznamom zahtev, ki jih je
izdelala razvojna ekipa in z izdelavo serij testnih primerov, s katerimi preverijo skladnost
zahtev z implementacijo.
Raziskovalno testiranje je svobodnejša oblika za načrtovanje in izvedbo testiranja. Testerji pri
tem tipu testiranja ne sledijo scenarijem, ampak pri testiranju uporabijo uporabniške zgodbe.
Cilj tega tipa je, da testerji osvojijo delovanje programske opreme in se osredotočijo na
testiranje in ne na dokumentiranje testnega procesa. Poudarek je na odkrivanju napak, ki jih
mreža avtomatskih testov ne more prestreči. Raziskovalno testiranje je v zadnjih letih postalo
zelo popularno, vendar ima tudi svoje slabosti. [12]
Z naslednjimi razlogi bomo predstavili slabosti raziskovalnega testiranja [17]:
• Raziskovalno testiranje lahko ustvari majhne napake, ker tester v določenih trenutkih
ne ve, kaj počne.
• Vodstvo nima nadzora nad testerjem med izvajanjem raziskovalnega testiranja, zato
pogosto nima orientacije o napredku testiranja, razen če je tester pripravil dober
zapisnik.
63
• Kako lahko zagotovimo z raziskovalnim testiranjem, da se napaka v prihodnosti ne bo
pojavila? Nekateri testerji bi to rešili s ponovno sejo raziskovalnega testiranja, vendar
se lahko ponovno znajdemo na starem mestu. Ugotovili smo, da raziskovalno
testiranje pri testiranju ni stoodstotno.
Predstavili smo večino slabosti raziskovalnega testiranja, vendar jih je Microsoft Visual
Studio 2012 odpravil tako, da je izdelal prvovrstno podporo v orodju MTM [17]:
• Testerji lahko zajamejo bogate podatke, ki temeljijo na njihovih testnih nastavitvah in
v primeru napake zagotovijo uporabne informacije o testiranju.
• Rezultati raziskovalnega testiranja se shranijo v TFS. Z analizo ugotovimo kdo je
izvajal testiranje, kateri pristopi so se uporabljali, koliko napak je bilo odkritih itd. S
tem ima vodstvo dostop do meritev, iz katerih razberejo napredek in zaključek
raziskovalnega testiranja aplikacije.
• Pojavljanje napake rešimo tako, da v trenutku izdelamo testni primer, ki ugotovi,ali je
napaka nazadovala v prihodnosti.
Slika 13 prikazuje primer raziskovalnega testiranja, kjer s klikom na izbrano zahtevo
pričnemo s testiranjem.
Slika 13: Raziskovalno testiranje v orodju MTM 2013 [13]
64
5.3 Dodatki za diagnostiko podatkov
Ključni izziv testiranja programske opreme je zagotoviti razvijalcem dovolj informacij o
padlih testih, da lahko potem ustrezno odpravijo napako. Kako pogostokrat se zgodi, da
razvijalec ni reproduciral napake, ki jo je odkril tester? Fraza »Deluje na mojem računalniku«
se pogostokrat pojavlja v razvoju programske opreme.
Microsoft je problem reprodukcije odpravil z dodatki za diagnostiko podatkov, ki zbirajo
informacije ene ali več naprav na podlagi testov. Zbrane informacije dodatkov za diagnostiko
podatkov lahko priložimo napaki in s tem omogočimo razvijalcu bogato količino podatkov, na
podlagi katerih bo diagnosticiral problem. [14]
Visual studio 2013 zajema številne dodatke za diagnostiko podatkov, ki se vključijo med
testiranjem in so naslednji:
• Dnevnik akcij (Action log): adapter se uporablja pri ročnem testiranju in vanj se
zapišejo koraki do odkritja napake. Razvijalcu zelo olajša delo, saj mu ni potrebno
ugotavljati, kako je tester prišel do napake, ampak pogleda v dnevnik akcij in iz njega
razbere testerjeve korake. Testerji za hitrejše ročno testiranje delov aplikacije
pogosteje uporabijo dnevnik akcij kot snemalnik. [21]
• ASP.NET Profiler: se uporablja na oddaljenih računalnikih pri izvajanju testa
zmogljivosti. Zagotavlja profiliranje informacij ASP.NET aplikacij in se uporablja za
natančno diagnozo ozkih grl. Diagnostični dodatek se uporablja samo za ASP.NET
teste zmogljivosti. [14]
• Pokritost kode (Code coverage): s tem dodatkom lahko ugotovimo, kateri predeli
kode se uporabljajo med izvajanjem avtomatskih testov. Kasneje lahko z analizo
določimo neuporabljeno sekcijo kode, ki smo jo odkrili s testiranjem. Dodatek
pokritosti kode je na voljo le za avtomatizirane teste. [21]
• IntelliTrace: intelliTrace zajema informacije o razhroščevanju .NET aplikacije.
Informacije lahko naložimo v Visual Studio 2013 in razvijalcem omogočimo analizo
napake. [14]
• Dnevnik dogodkov (Event log): med testiranjem se informacije zapisujejo v dnevnik
dogodkov. [13]
• Informacije sistema: zbira informacije o sistemu, ki so dodane zraven napake. V teh
informacijah je zapisana različica operacijskega sistema, velikost RAM-a, različica
brskalnika in druge informacije naprave, vključene pri testiranju. [12]
65
• Test učinkovitosti (Test impact): med testiranjem si zabeleži aktivne metode
aplikacije. Iz teh informacij ugotovimo, katere spremembe so nastale s strani
razvijalcev in določimo teste, na katerega so vplivale spremembe razvoja. Analiza
učinkovitosti usmerja splošne testerje k pravilnemu izvajanju pomembnih testov glede
na kritične dele aplikacije. [21]
• Video snemalnik: snemalnik snema aplikacijo med testiranjem in pomaga
razvijalcem pri diagnosticiranju napake vmesnika. Dodatek je bil omogočen že v
Visual Studio 2012 s snemalnikom zvoka in je lahko uporabljen za avtomatske teste
(kot kodiran UI test), vendar se bolj uporablja pri ročnem testiranju, tako da tester med
testiranjem posname tudi komentarje aplikacije. [14]
• Obstaja dodatek za diagnostiko podatkov, ki med testiranjem vpliva na napravo. Ta je
sledeč [14]:
o Emulacija omrežja: dodatek ne zbira podatkov, ampak na silo spreminja
vedenje naprave (npr. zmanjša hitrost internetne povezave, simulira hitrost
modema, recimo v omrežju podjetja, kjer so uporabniki nanj povezani iz
oddaljenih lokacij).
Imamo možnost izdelave lastnega dodatka za diagnostiko podatkov. Z uporabo številnih
dodatkov dramatično zmanjšamo čas diagnoze in odpravimo slabosti neuspelih testov.
66
6 Uporaba testnih orodij Visual Studio 2013 v praksi
6.1 Testiranje v okviru življenjskega cikla programske opreme
Testiranje ni samostojna dejavnost, ampak ima svoje mesto v modelu za razvoj življenjskega
cikla programske opreme, ki določa organiziranost testiranja. Obstajajo številne oblike
testiranja, vendar je zaradi različno vpletenih interesov in disciplin v življenjskem ciklu
pomembno, da definiramo različne ravni in tipe. V procesu razvoja je projekt odvisen od
svojih namenov in ciljev. Obstajajo številni razvojni življenjski cikli z različnimi cilji in
segajo vse od manj zahtevnih in zahtevnih metodologij. Ključen pomen metodologij je, da so
popolnoma nadzorovane in dokumentirane, saj sta pri njih pomembna kvaliteta in
zanesljivost. Vsaka od njih ima svoje mesto v sodobnem razvoju programske opreme in
najustreznejši razvojni proces za vsak projekt. Modeli določijo različni vrstni red in faze
procesa, v katerem se izvajajo.
Model življenjskega cikla ima velik vpliv na testiranje v projektu. Aktivnosti testiranja
opredelijo predmet, prostor in čas izvajanja, vplive regresijskega testiranja ter tehniko
testiranja. Testiranje mora slediti razvoju življenjskega cikla, da bo uspešno opravilo svoje
delo. Pogosto ima izdelek časovni rok predaje, zato mora biti testiranje hitro in učinkovito.
6.2 Testiranje z orodji Visual Studio 2013 po V-modelu
Preden opišemo postopek testiranja po V-modelu, je potrebna postavitev testnega okolja. V
naslednjem podpoglavju bomo predstavili vse potrebne snovi o nastavitvi okolja za
upravljanje življenjskega cikla aplikacij z Visual Studio 2013 (s poudarkom na testnih
orodjih).
6.2.1 Infrastruktura testnega okolja
Lastnosti, o katerih smo razpravljali, lahko kombiniramo s komponentami, ki skupaj tvorijo
infrastrukturo testiranja.
Postavitev infrastrukture, ki smo jo uporabljali, je precej omejena zaradi virov, zato bomo
dodali še orodja primerna pri postavitvi infrastrukture, ki še zadostujejo minimalnim
potrebam (Tabela 5).
67
Tabela 5: Uporabljena in primerna orodja za postavitev infrastrukture
Izdelek Programska
oprema in verzija
Namen
Visual Studio
2013
Visual Studio
Professional
Za testiranje enote, razhroščevanje.
Team Foundation Server UI
Visual Studio
Premium
Vse zgoraj našteto, plus pokritost
kode in kodiran UI test.
Visual Studio
*Ultimate
Našteto vse zgoraj, plus
zmogljivostni test, spletno testiranje in
MTM
Visual Studio Test
Profesional
MTM, Team Foundation Server UI.
Ne vsebuje testiranja enote in
razhroščevanja.
Microsoft Test
Manager (MTM)
Nameščen kot del
orodjaVisual Studio
Ultimate ali Test
Profesional.
Uporabniški vmesnik za upravljanje
laboratorija, testnih načrtov in orodja
Test Runner.
Windows Windows Server
2012 R2 Enterprise
64 bit (vključno z
Microsoftovo Hyper
– V tehnologijo)
Strežniki poganjajo testno
infrastrukturo komponent. Za vsak
virtualni računalnik rabimo licenco,
čeprav je virtualen. (Licence ne
potrebujemo za kratkotrajne testne
inštalacije.)
Windows 7 Potrebujemo za namizne in prenosne
računalnike.
Team
Foundation
Server
Visual Studio 2013
Team Foundation
Server
Sledenje opravil, nadzor nad viri,
storitve gradnikov.
System Center
Virtual Machine
Manager
(SCVMM)
Virtual Machine
Manager 2008 R2
SP1 ali 2012
Virtualne naprave za testna okolja.
68
Microsoft
SharePoint
Server
*SharePoint
Standard
Spletna stran projekta za objavo
osnovnih poročil.
*SharePoint
Enterprise
Za razširjena poročila in armaturne
plošče. Ogljete si namizje na MSDN.
Microsoft SQL
Server
SQL Server Express Podpira SCVMM.
**SQL Server 2012
Standard
Zagotavlja storitve poročanja z
grafikoni, ki predstavljajo napredek
ekipe in kakovost proizvoda.
Key
Management
Service (KMS)
Zagotavlja aktivacijske ključe za
testiranje virtualnih naprav.
*Veliko lahko privarčujemo, če ne uporabimo orodja SharePoint.
**Za podporo orodja Team Foundation Server lahko uporabimo SQL Server Express. Vendar
moramo biti pri tej odločitvi previdni, saj lahko nastane migracija orodja Team Foundation
Server iz enega strežnika SQL v drugo različico, kar pomeni izgubo zgodovinskih podatkov o
opravilih.
6.2.2 Strojna oprema pri postavitvi infrastrukture
Na zelo enostaven način lahko postavimo dva ali več velikih strežnikov, vendar nastane
težava v financah.
Uporabimo en velik strežnik, ki je testni gostitelj. Na njem se izvajajo virtualne naprave, ki
izvajajo teste. V primeru večje količine testov lahko dodamo več testnih strežnikov.
Strežnik služi za druge komponente testne infrastrukture, ki je naslednji: Team Foundation
Server, ki smo ga navedli v zgornji tabeli skupaj z različnimi pomožnimi agenti, storitvami in
konzolami.
V primeru preobsežnega projekta razširimo komponente infrastrukture na več računalnikov. V
nadaljevanju bomo podrobneje pogledali vloge različnih komponent.
69
6.2.2.1 Komponente infrastrukture
Slika 14 prikazuje komponente, nameščene na enem računalniku ali razširjene na številnih
računalnikih, ki imajo enake funkcije in povezave:
Slika 14: Komponente infrastrukture
Prikazana polja v diagramu predstavljajo proizvode programske opreme, razen testnega
gostitelja in fizičnega računalnika.
• Testni gostitelj je fizični računalnik, na katerem se izvaja Hyper-V. Virtualizacija
omogoča skupno rabo virov med virtualnimi napravami in fizičnim računalnikom.
Imamo lahko več testnih gostiteljev, da virtualne naprave delujejo istočasno. Hyper-V
je vloga v Windows Server, ki se nahaja na nadzorni plošči za upravljanje računalnika.
o Testni gostitelj mora imeti prostoren disk, veliko pomnilnika in veliko logičnih
procesorjev. Virtualizacija deli vire med virtualnimi napravami.
o Na testnem gostitelju je nameščen samo Hyper-V in nobenih drugih
pomembnih storitev.
o Teste lahko izvajamo brez Hyper-V virtualizacije, vendar nam orodje Hyper-V
olajša delo pri postavitvi novih testnih okolij.
• Na testnih virtualnih napravah (VMs) testna ekipa izvaja razne teste, kjer se vsaka
naprava odziva enako kot fizični računalnik. Z njimi se lahko prijavimo na omrežje
organizacije, lahko jih izvajamo in ustavimo, odpiramo konzolna okna, se povežemo
na drugi računalnik preko namizja na daljavo itd. Poleg tega imamo možnost shraniti
70
stanje naprave in jo kasneje ponovno nastaviti, s tem lahko izdelamo duplikate stanj
naprave, ki jih shranimo v knjižnico.
o Priporočeno je izvajanje testov na virtualnih napravah, saj je enostavno izdelati
nove virtualne naprave z drugačnimi konfiguracijami strojne opreme,
operacijskih sistemov in drugih programskih oprem. Zelo enostavno jih je
nastaviti na prvotno oziroma čisto stanje.
o Večino testov je mogoče izvesti na virtualnih napravah, vendar obstajajo
izjeme, ki vključujejo posebno strojno opremo in nekatere zmogljivostne teste.
o Uporabimo lahko tudi druga virtualna ogrodja, kot sta Vmware in Citrix Xen
Server, vendar bomo morali uporabiti njihove zmogljivosti za shranjevanje in
obnovitev virtualnih naprav.
o Fizični testni računalnik je uporaben za izvajanje zmogljivostnih testov ali
testov, ki se morajo izvajati na specificirani strojni opremi, vendar z uporabo
virtualnih naprav spoznamo, kako redko se uporabljajo fizične naprave, saj
lahko na virtualnih napravah še vedno izvajamo nekatere tipe zmogljivostnega
testiranja.
• Sistemski center za upravljanje virtualnih naprav (System Center Virtual Machine
Manager-SCVMM) združi Hyper-V gostitelje v en velik vir. Z njim lahko izdelamo
lasten zasebni oblak, prav tako nam omogoča izdelavo knjižnice za predloge
virtualnih naprav, s pomočjo katerih na enostaven način izdelamo nove virtualne
naprave. Po namestitvi orodja SCVMM nam ni potrebno delati s posameznimi Hyper-
V konzolami.
• VMM agent zastopa SCVMM in je nameščen na vsakem testnem gostitelju. VMM
agent omogoči SCVMM nadzor nad Hyper-V.
• VM knjižnica shramba datotek, v kateri so shranjene kopije in predloge virtualnih
naprav. Običajna virtualna naprava je velika nekaj gigabajtov, zato mora biti knjižnica
zelo velika in se mora nahajati na enakem disku, kot virtualna naprava. Primarna
knjižnica mora biti na enakem računalniku kot SCVMM, lahko dodamo še druge
knjižnice, ki se nahajajo na ločenih računalnikih.
• SCVMM SQL Server shranjuje podatke uskladiščenih in izvajajočih virtualnih
naprav.
• SCVMM konzola je uporabniški vmesnik administratorja za SCVMM. Konzola je
nameščena na enakem računalniku kot Team Foundation Server. Konzole lahko
71
namestimo tudi na druge računalnike, iz katerih želimo nadzorovati SCVMM. Poleg
tega namestimo Self-Service Portal za SCVMM, ki vsebuje spletni vmesnik, ki
omogoči navadnim uporabnikom izdelavo virtualnih naprav. Na zgornji sliki ni
prikazan.
• Team Foundation Server skladišči predmete, kot so testni primeri, uporabniške
zgodbe, napake in razvijalčeva opravila.
o Team Foundation Server zagotavlja nadzor nad verzioniranjem izvorne kode in
druge artefakte projekta.
o Pri večjih projektih namestimo instanco orodja TFS na ločene računalnike in
jih združimo v logično gručo, ki ima samo en identifikator enotnega vira (URI)
za uporabniški dostop.
• Z orodjem Lab Manager izdelamo in upravljamo laboratorijska okolja, ki so lahko
gruča virtualnih ali fizičnih naprav, na katerih se izvajajo testi. Lab Manager je del
orodja TFS in zagotavlja funkcije na vrhu orodja SCVMM.
o Build Service opravlja stalne in redne gradnike na strežniku, pri čemer vzame
izvorno kodo iz orodja TFS source control. Komunicira z Build Agent, ki je na
vsaki testni napravi in omogoča naložiti prevedeno kodo na določeno napravo.
• Testni krmilnik izvaja skripto za opravljanje testov. Za zagon in zbiranje testnih
podatkov na testni napravi se sporazumeva s testnim agentom.
• Visual Studio je glavni vmesnik, ki dostopa do TFS predmetov, izvorne kode in
gradnikov.
• Microsoft Test Manager (MTM) je vmesnik, ki dostopa do orodja Lab Manager in
testnega krmilnika.
• TFS Admin je administratorska konzola orodja TFS.
6.2.2.2 Lab Manager in virtualizacija
Pod tem naslovom bomo predstavili povezavo med virtualizacijo in Lab Managerjem.
Lab Manager je element orodja TFS, ki ga usposobimo preko TFS strežniške konzole.
Uporabniki dostopajo do orodja Lab Manager preko namiznih naprav s pomočjo Lab Center,
ki se nahaja v orodju MTM. Z orodjem Lab Manager kreiramo in nadzorujemo laboratorijska
okolja, ki tvorijo skupino naprav, na katere namestimo sistem, potreben za testiranje.
72
Določena laboratorijska okolja so zasnovana za testiranje distribuiranih sistemov, kot so
spletne storitve.
Okolje je sestavljeno iz fizičnih in virtualnih naprav, kjer imajo veliko prednost virtualne
naprave, saj z njimi hitro izdelamo novo okolje ter shranjujemo napake, odkrite s strani
okolja, za kasnejše preiskave. Vse te ugodnosti dobimo z namestitvijo orodja SCVMM, ki
zagotovi mesto virtualnih naprav v knjižnicah.
Lab Manager združi virtualne naprave v virtualnem okolju, kjer kot celoto naprave ustavimo
in zaženemo.
Izdelamo tudi standardna okolja z različnimi virtualnimi in fizičnimi napravami, kjer
virtualnim napravam ni potrebno upravljati z orodjem SCVMM. Standardno okolje ne
vsebuje vseh značilnosti virtualnega okolja, vendar z njim razvijamo in izvajamo teste. V vseh
pogledih je virtualno okolje primerno za vse tipe testiranja, medtem ko so standardna okolja
primerna le za izvajanje zmogljivostnih testov.
Lab Manager lahko instaliramo brez instalacije orodja SCVMM ali brez Hyper-V
virtualizacije. V tem primeru je možno postaviti le standardno okolje. Ta scenarij nam koristi,
če mora ekipa vložiti veliko truda v testno ogrodje, ki temelji na fizičnih napravah ali na
zunanjem ogrodju virtualizacije.
Če pogledamo seznam komponent, jih lahko v zaključen sistem uredimo na različne načine.
Obstaja veliko različic glede na različne dejavnike. Mi bomo omenili samo en primer
ekonomične postavitve.
73
6.2.2.3 Ekonomična postavitev virtualizacije
Pri tej nastavitvi smo postavili vso infrastrukturo na en računalnik ter Hyper-V za testne
virtualne naprave na drug računalnik. Stroške smo zmanjšali tako, da smo izpustili instalacijo
SharePoint-a (ali uporabili standardni SharePoint). Prostor shranjevanja za orodje TFS smo
zagotovili z uporabo SQL Server Expres namesto SQL Server, kot je prikazano v spodnji sliki
(Slika 15). S to izbiro smo izgubili armaturne plošče in spletne grafikone o napredku projekta
zoper testiranja.
Slika 15: Ekonomična postavitev virtualizacije
Omenjena konfiguracija ima naslednje specifikacije:
• Infrastruktura gostitelja:
o 16 učinkovitih centralno procesnih enot (ali več)
o 48GB RAM, 64-bitna arhitektura, zasnovana za Hyper-V (kar pa ne drži v
vseh 64-bitnih strežnikih)
o Windows Server 2012 R2 Enterprise 64 bit
o C: pogon 100GB za Windows-e
o E: pogon 2000GB za virtualne naprave
• Infrastruktura strežnika:
o 4 ali več učinkovitih centralno procesnih enot
o 10GB RAM ali več, 64-bitna arhitektura
74
o Windows Server 2012 R2 Enterprise 64 bit
o C: pogon 200GB za programsko opremo
o E: pogon naj bo čim večji za VM Library
• Programska oprema:
o 2 x Windows Server 2012 Enterprise R2 64 bit
o Team Foundation Server 2013
o System Center Virtual Machine Manager 2012 R2 SP1
o SQL Server Express (ali SQL Server 2012)
o (SharePoint Standard)
• Namizne naprave za razvijalce:
o Windows 7 Professional ali Enterprise
o Visual Studio Professional 2013 (ali Premium ali Ultimate)
• Namizne naprave za testerje:
o Windows 7 Professional ali Enterprise
o Visual Studio Test Professional 2013 (ali Ultimate)
Mi smo uporabili še bolj ekonomično postavitev infrastrukture in zaradi primanjkovanja virov
strnili infrastrukturo strežnika in gostitelja na en računalnik.
Omenjena konfiguracija ima naslednje specifikacije:
• Infrastruktura gostitelja in strežnika na enem računalniku:
o 4 ali več učinkovitih centralno procesnih enot
o 8GB RAM ali več, 64-bitna arhitektura
o Windows Server 2012 R2 Enterprise 64 bit
o C: pogon 200GB za programsko opremo
o E: pogon 1500GB za virtualne naprave
• Programska oprema:
o 2 x Windows Server 2012 Enterprise R2 64 bit
o Team Foundation Server 2013
o System Center Virtual Machine Manager 2012 R2 SP1
o SQL Server Express (ali SQL Server 2012)
o (SharePoint Standard)
• Namizne naprave za razvijalce:
o Windows 7 Professional ali Enterprise
75
o Visual Studio Professional 2013 (ali Premium ali Ultimate)
• Namizne naprave za testerje:
o Windows 7 Professional ali Enterprise
o Visual Studio Test Professional 2013 (ali Ultimate)
6.2.3 Kreiranje in nastavitev skupine projektov
Grupa skupine projektov se imenuje zbirka skupine projekta (team project collection). Ko
namestimo TFS, je že izdelana zbirka pod imenom »default collection«, v katero bomo lahko
dodajali skupine projektov. Pri izdelavi zbirke projekta moramo specificirati logične in fizične
vire, ki jih bo uporabljala skupina projektov. Vsi artefakti in podatki, ki jih uporablja skupina
projektov, so shranjeni v podatkovni bazi zbirke. V naslednjih korakih bomo prikazali
postopek izdelave nove zbirke skupine projektov.
1. Z administrativne konzole odpremo stran Team Project Collections in izberemo
zavihek Create Collection in nato s čarovnikom izdelamo zbirko skupine projekta.
V prvem koraku določimo ime in opis zbirke skupine projekta (Slika 16).
Slika 16: Določitev imena in opisa zbirke skupine projekta,
76
2. Slika 17 prikazuje določitev podatkovnega sloja ali SQL strežnike instance. V
polje SQL Server Instance navedemo TFS strežniški podatkovni sloj. Če želimo
uporabiti obstoječo instanco podatkovne baze za zbirko skupine projekta, moramo
navesti ime in instanco, kot je prikazana v naslednjem primeru: ServerName \
InstanceName.
Slika 17: Določitev podatkovnega sloja
3. Slika 18 prikazuje proces verifikacije. Readiness Checks preveri stanja pregledov.
Slika 18: Preverjanje ustreznosti zbirke skupine projekta pred njeno izdelavo
77
4. Slika 19 prikazuje proces izdelave zbirke skupine projekta.
Slika 19: Proces izdelave zbirke skupine projekta
Nato v orodju TFS izdelamo skupino projekta, s katero vzpostavimo repozitorij za izvorno
kodo in prostor za načrtovanje, spremljanje napredka ter kolaboracije. V naslednjih korakih
bomo prikazali postopek izdelave nove skupine projekta.
1. V orodju Team Explorer izberemo povezavo »Create Team Project«, kjer s
pomočjo čarovnika izdelamo novo skupino projekta (Slika 20).
Slika 20: Začetna faza izdelave skupine projekta
78
2. Slika 21 prikazuje okno New Team Project, v katerem določimo ime in opis
skupine projekta. Upoštevati moramo, da ko enkrat določimo ime skupine
projekta, ga ne moremo več spremeniti.
Slika 21: Določitev imena in opisa skupine projekta
3. Slika 22 v naslednjem oknu prikazuje izbiro predloge procesa, ki določa potek
dela skupine. Na voljo imamo tri predloge, mi smo uporabili predlogo Scrum, ker
bomo uporabljali predmete seznama zahtev izdelka in tipe delovnega predmeta.
Slika 22: Izbira predloge procesa
79
4. Potem je potrebno določiti sistem za nadzor nad verzijami (Slika 23). Na voljo
imamo dva sistema: Team Foundation Version Control (TFVC) ali Git. V isti
zbirki skupine projekta lahko uporabimo TFVC in Git sistema. Razlika med njima
je, da TFVC uporablja centraliziran strežniški repozitorij za sledenje in izdelavo
verzij datotek, medtem ko Git uporablja lokalni repozitorij, nima strežniškega
koncepta, ampak ima enega ali več skupnih repozitorijev.
Slika 23: Določitev sistema za nadzor nad verzijami
5. Slika 24 prikazuje skupino projekta v orodju Team Explorer po končani
konfiguraciji. Orodje Team Explorer ima povezavo do orodja Web Access.
Slika 24: Skupina projekta v Team Explorer
6.3 Priprava testne dokumentacije
Testiranje pričnemo v fazi analiziranja zahtev in izdelavi testnih kriterijev, ki usmerijo testno
ekipo.
Pred začetkom dejanskega testiranja se testna ekipa ukvarja z različnimi dejavnostmi, kot so
priprava testne strategije, načrtovanje testiranja, oblikovanje testnih primerov in testnih
80
skript, ki se izvajajo vzporedno z razvojem izdelka in nam omogočijo pridobiti testne
rezultate ob pravem času.
Na podlagi zahtev dokumenta razvojna ekipa začne delati na oblikovanju, potem pa se lotijo
dejanske implementacije, medtem ko testna ekipa začne delati na izdelavi testnega načrta,
testnih primerov in skript. Obe dejavnosti potekata vzporedno.
Življenjski cikel razvoja programske opreme v V-modelu lahko ima različne faze, vendar
bomo mi vzeli najosnovnejšo konstrukcijo V-modela s štirimi fazami. Glede na pridobljeno
študijo bomo sami določili in opisali potek dogajanja za posamezno fazo, ki velja za manjše
organizacije:
1. Testiranje sprejemljivosti: v tej fazi moramo razumeti pričakovanja stranke. Veliko
časa posvetimo stranki in razvijalcem. Skupaj z njimi zapišemo vrednote in poslovne
cilje, izdelamo diaproekcijo iz uporabniških scenarijev, zapišemo uporabniške zgodbe,
poslovne diagrame aktivnosti, poslovne modele entitet, relacij in diagrame interakcij
med glavnimi akterji. Na podlagi teh aktivnosti pripravimo osnutek načrta. Zahteve
izdelka vsebujejo seznam uporabniških zgodb, razvrščenih v vrstnem redu, po katerem
se bodo implementirale. Vsak element je zahteva, za katerega se izdela testna
garnitura. Na začetku projekta imamo obširno in dokaj urejeno zbirko zahtev, ki
rafinirajo potek projekta. Elemente zahtev izdelka (PBIs) poimenujemo in opišemo
tako, da so razumljivi stranki projekta. Vsakemu elementu podamo grobo oceno
stroškov glede na čas in druge vire. Pri tem opomnimo testno ekipo, da je v
ocenjevanje stroškov prav tako vključen čas, ki ga potrebujejo za pisanje in izvajanje
enotnih in sistemskih testov.
2. Sistemsko testiranje: v tej fazi pripravimo testne primere sistema. Načrt testiranja
sistema je izdelan na podlagi strojne opreme in komunikacije med njimi ter
predvidene načrtovane arhitekture, ki bo uporabljena pri implementaciji aplikacije. V
tem delu na podlagi znanih zahtev konfiguriramo ustrezno testno okolje.
3. Integracijsko testiranje: v tej fazi pripravimo testne primere za integracijsko testiranje.
Izdelamo načrt integracijskega testiranja in preverimo sposobnost komponent sistema
ter njihovo skupno delovanje z zmogljivostnim testom. Za čim bolj učinkovito
testiranje izdelamo testne primere, testne korake za testiranje sistema. Za boljšo
predstavo uporabniških zgodb izdelamo diaprojekcijo s koraki, ki opisujejo poteke
zgodb. Pisanje korakov vnaprej ima zelo veliko prednost, saj se izognemo
pristranskosti dejanskega delovanja sistema. Avtomatiziramo in razširimo pomembne
81
ročne teste iz prejšnjih ciklov. Pri tem moramo zagotoviti, da testi vsebujejo vse
lastnosti, ki so jih vsebovali pred avtomatizacijo in posegom v kodo. Testi se dodajo
dnevnim gradnikom.
4. Testiranje enote: pripravimo testne primere za teste enote. V tej fazi testiramo
komponente, kot so razredni diagrami z vsemi metodami in relacijami med razredi.
Slika 25, izdelana na podlagi naše študije, prikazuje faze leve in desne strani V-modela ter
vmesne faze za pripravo testne dokumentacije, ki je potrebna pri vsaki fazi testiranja. Pri
izdelavi testne dokumentacije imamo navedene tudi osebe, ki jo pripravijo.
Slika 25: Osnovna zgradba V-modela
82
Pripravljeno testno dokumentacijo je potrebno ustrezno vnesti v TFS z uporabo Microsoftovih
orodij, kot sta npr. Team Web Access ali MTM. Spodaj je prikazan primer kako vnesti tetstni
načrt z uporabo orodja MTM.
1. Najprej izberemo obstoječo testno skupino, ki lahko ima že izdelan testni načrt ali
pa ga dodamo na novo. Pri dodajanju novega testnega načrta ga ustrezno
poimenujemo in izberemo (Slika 26).
Slika 26: Dodajanje testnega načrta v orodju MTM
2. Na novo izdelanemu testnemu načrtu lahko dodelimo različne lastnosti. Slika 27
prikazuje lastnosti testnega načrta, ki ga lahko posodabljamo, mu spremenimo
ime, dodamo opis načrta, določimo drugo iteracijo skupine projekta ter čas
trajanja iteracije. Konfiguracije so del načrtovanja, ki nas obvestijo o potrebnih
zahtevah. Med izvajanjem testov ni zagotovljeno, ali se testi dejansko izvajajo na
določeni konfiguraciji.
Slika 27: Konfiguracija testnega načrta
83
3. Testne primere lahko dodamo v privzeto testno garnituro, ki ima enako ime kot
testni načrt. Slika 28 ima privzeto testno garnituro z imenom »Spletna trgovina«,
enako kot je ime testnega načrta.
Slika 28: Dodajanje testnega primera v privzeto testno garnituro
4. Slika 29 prikazuje dodane zahteve testnemu načrtu, zahtevam pa dodamo testne
primere. Testnemu načrtu lahko dodamo že obstoječo zahtevo. Testni primer,
izdelan za testno garnituro, ki temelji na zahtevi, se bo avtomatsko povezal z
zahtevo.
Slika 29: Dodajanje zahtev testnemu načrtu
84
5. Ročnim testnim primerom za vsak testni korak dodamo akcije in pričakovan
rezultat. Med izvajanjem testa lahko vsak testni korak označimo za uspelega in
neuspelega. Testni koraki s pričakovanim rezultatom so označeni kot koraki
validacije. Slika 30 prikazuje testni primer dodajanje izdelka v nakupovalno
košarico in njegove testne korake z opisanimi dejanji in pričakovanimi rezultati.
Slika 30: Testni koraki testnega primera
6. Povezavo med privzetimi konfiguracijami in testnimi primeri testnega načrta je
razvidna pod zavihkom »Test« (Slika 31). Izberemo lahko teste, ki jih želimo
izvajati z orodjem Test Runner.
Slika 31: Povezava med privzetimi konfiguracijami in testnimi primeri
85
7. Zaženemo testne korake pod zavihkom »Test«. Med izvajanjem označimo testne
korake bodisi za uspele ali neuspele; dodajamo komentarje, datoteke ali posnetke
zaslona; lahko izdelujemo napake. Slika 32 prikazuje orodje Test Runner, s
katerim smo izdelali posnetek neuspešnega koraka testnega primera.
Slika 32: Izvajanje testnih korakov z orodjem Test Runner
6.3.1 Uporaba testnih načrtov in garnitur
Testni načrt predstavlja kombinacijo testnih primerov, testnih okolij in testnih konfiguracij. Za
vsako iteracijo izdelamo nov testni načrt, s tem si olajšamo delo tako, da kopiramo testne
garniture iz podobnega testnega načrta v našega.
Izvajanje testov pri različnih konfiguracijah, kot je uporaba drugačnega spletnega brskalnika,
je izvedljiva, vendar je potrebno za vsako drugačno konfiguracijo izdelati testni načrt. Testni
načrti si lahko med seboj delijo testne garniture, saj jih lahko ponovno kopiramo v druge
testne načrte, s tem da spremenimo konfiguracijo testnega okolja v lastnostih testnega načrta.
Pri razpravljanju o scenarijih, uporabniških zgodbah in drugih zahtevah moramo vedno
razmišljati o načinu izvedbe testiranja. Zato se s stranko pogovorimo o testnih primerih, saj
nam ona najbolj pojasni delovanje zahtev.
• Pri testiranju moramo imeti v mislih validacijo in ne samo sistem, temveč poslovni
proces okoli njega. Z verifikacijo moramo ugotoviti usklajenost zahtev in
uporabniških zgodb s sistemom. Pridobljene povratne informacije stranke nam zelo
koristijo pri razvoju in testiranju programske opreme.
86
• Projekt vsebuje zahteve in testne primere, kjer nekaterim ključnim primerom dodamo
potek izvajanja. To zagotavlja jasen cilj za razvoj. Razvoj aplikacije načrtujemo kot
iterativen proces, tako zelo hitro končamo funkcionalnost izdelka od začetka do konca.
S tem procesom zmanjšamo tveganja v razvoju, kot je razvijanje neuporabne
funkcionalnosti in nepravilna zasnova arhitekture projekta.
• Vzpostavimo virtualne laboratorije za izvedbo sistemskih testov.
6.4 Testiranje aplikacije
Skozi življenjski cikel aplikacije se glede na različne faze po V-modelu uporabljajo določeni
tipi testiranja, ki so na voljo v Microsoftovih orodjih. Slika 33 prikazuje uporabo testnih tipov
skozi faze testiranja. Tipe za testiranje uporabimo glede na območje oz. zahteve posamezne
faze v V-modelu. Vsaka faza zahteva določen tip testiranja in določeno znanje testerja.
Povezave od testnih tipov do faz testiranja prikazujejo osebe, ki naj bi bile udeležene pri
testiranju.
Slika 33: Uporaba testnih tipov skozi faze testiranja
87
Predstavili bomo nekaj koristnih napotkov za uspešno testiranje:
• Pri izdelavi testov enot moramo najprej poskrbeti za pokritost kode, ki mora biti vsaj
70-80 %. Z izdelavo testov vedno začnemo pred implementacijo aplikacije. Testi
pogosto razčlenjujejo delovanje kode.
• Izdelamo nadomestke in gonilnike, da lahko testiramo komponente, ki so odvisne od
drugih nedokončanih ali pomanjkljivih komponent.
• V najkrajšem možnem času poskusimo zagnati testni primer. Vsakič, ko izdamo novo
izgradnjo izdelka, opravimo raziskovalno testiranje, da poiščemo napake in
definiramo dodatne testne primere.
• Pri izvajanju ročnih testnih primerov posnamemo svoja dejanja. Tako lahko hitreje
ponovimo določen test in hitreje izvajamo regresijsko testiranje.
• Uporabimo funkcijo v orodju MTM poročilo napak s klikom, ki vsebuje posnetke
okolja, tako lahko lažje odpravimo pomanjkljivost izdelka.
• Avtomatiziramo ključne ročne teste, ki jih vključimo v avtomatizacijo gradnikov. S
tem postane integriteta sistema bolj samozavestna.
• Ekipa mora ločevati vloge testerjev in razvijalcev, zato moramo poiskati osebje, ki je
dobro pri iskanju napak in jih že v začetku osredotočiti k uporabi in izvajanju
raziskovalnega testiranja. Vnaprej morajo razmišljati o načrtovanju testov.
• V skupino testerjev dodamo nekaj razvijalcev in obratno, tako da so skupine
pomešane in sčasoma postanejo učinkovitejše od osnovno razvrščenih skupin. V
postopek zahtev vključimo uvajanje v testiranje, kjer razvijalci pokažejo testerjem
postopke za avtomatizacijo testov.
6.5 Osebe in vloge pri testiranju
Razprava o tem ima dve plati: ali naj testirajo celoten sistem razvijalci ali pa se naj lotijo
testiranje sistema ločene skupine testerjev. Kot po navadi se odgovor nahaja med skrajnostmi
in je odvisen od naših okoliščin.
Projekt mora nujno imeti hiter splošen cikel, zato ločevanje skupin med razvijalce in testerje
ni priljubljeno in zaradi tega nastane zakasnitev Handoff (zakasnitev med vozlišči). Testerji in
razvijalci so ločeni v skupine zaradi raznolikosti, ki se pojavijo v znanju in odnosih. Med
razvijanjem izdelka si razvijalci vedno postavijo vprašanje »Kako čim bolj izdelati koristen in
88
uporaben izdelek za uporabnika?«, medtem ko testerji želijo zlomiti sistem in poiskati
njegove pomanjkljivosti. Razvijalci testiranja ne vzamejo resno, sistem preverjajo preveč
»nežno«, saj velikokrat izberejo lažjo in srečno pot, medtem ko usposobljeni testerji iščejo
pomanjkljivosti, izpostavljajo stanja in izvajajo zaporedje akcij na sistemu. Večini razvijalcev
takšen pristop ni všeč in menijo, da jih testerji postavljajo v slabo luč, ko želijo izpostaviti
luknjo v oklepu. Vsestranski testerji so tisti, ki znajo kodirati, medtem ko vsestranski
razvijalci znajo napisati dober test. V Microsoftu obstaja delovno mesto inženirja za razvoj
programske opreme in testiranja (SDET). To je strokovnjak, čigar sposobnosti presegajo pri
testiranju in pisanju dobre programske kode. SDET je sposoben izdelati teste na podlagi
modela in mora imeti vpogled v zasnovo sistema in v njegovo odvisnost, kjer na podlagi tega
poišče vir verjetne napake.
Pogosto razdelitev testerjev v skupine vpliva na zgodovino ekipe in na naravo projekta.
Ločene razvojne in testne skupine priporočamo le v primeru razvijanja kritičnih sistemov. Če
se posamezniki osredotočajo na razvoj in testiranje, jih moramo zadržati v isti ekipi.
Priporočljiva je menjava vlog med osebjem.
V mislih moramo imeti naslednje točke, če imamo ločene testerje:
• Testni primeri so ključni pri določevanju zahtev. Testni člani so ključni udeleženci pri
vsaki razpravi o uporabniških zgodbah (in drugih zahtevah). Kot smo obravnavali v 5.
poglavju »Ročno testiranje«, nekatere testne skupine prisegajo na agilen pristop testno
usmerjenega razvoja, kjer so sistemski testi edina navedba zahtev.
• Avtomatizirani sistemski testi so pomembni za zmanjševanje regresijskih napak in za
manjšanje razvojnih ciklov. Ta postopek nam prinese izboljšave v številne vidike
testiranja.
89
6.6 Prednosti testiranja po tem postopku
Hitreje se odzovemo na spremembe zahtev in poročila napak.
• Avtomatizirane regresijske teste lahko hitro in večkrat ponovimo, s tem načinom
tesiranje ne predstavlja več ovire pri izdaji posodobitev. Ročno testiranje uporabimo
samo za nove in popravljene funkcije. Najhitreje testiramo z virtualnim
laboratorijskem okoljem.
• Stranka sistem usklajuje in eksperimentira.
Večje zadovoljstvo strank.
• Z rednimi povratnimi informacijami omogočimo uporabnikom zgodnejši preizkus in
usklajevanje sistema z njihovimi procesi. V tem primeru bo izdelek po vsej verjetnosti
zagotavljal njihove potrebe.
• Zelo hitro odpravimo napake odkrite, s strani stranke, ali dodamo nove
funkcionalnosti izdelku.
90
7 Sklep
Testiranje programske opreme je zelo pomembno. V preteklosti se je programska oprema
testirala ob koncu projekta in ne vzporedno z njim. Pogosto faza razvoja traja dlje časa, kot je
predvidena, zato posledično zmanjšamo fazo testiranja, da lahko pravočasno ujamemo rok
izročitve programske opreme. Takšen način vpliva na rezultate in kakovost številnih
projektov.
V diplomskem delu smo se zelo dobro seznanili s testiranjem programske opreme z orodjem
Visual Studio 2013. Na drobno smo predstavili faze testiranja, stroške s testranjem in brez
njega, pristope učinkovitega testiranja ter kombinacijo V-modela in orodja Visual Studio
2013. V-model smo izbrali zato, ker se najbolj ujema z orodjem Visual Studio 2013. Na
praktičnem primeru smo prikazali konfiguracijo in infrastrukturo testiranja ter testiranje
aplikacije skozi življenjski cikel. Določili smo, kateri testni tipi, ki so na voljo v
Microsoftovih orodjih, spadajo v določeno fazo V-modela.
Pomembna zadeva, ki si jo je vredno zapomniti pri modelih življenjskega cikla, ki so: V-
model, W-model, model agilnega pristopa, iterativni model itd. je to, da vsak model
predstavlja poenostavitev realnosti, ki izpušča nekatere elemente. Do neke mere nam model
pomaga pri jasnem razmišljanju o nečem, kar moramo storiti ali razumeti v realnem svetu.
Model postane tudi del dogme, ki posega v realni svet napredka in nato postane problem.
Verjetno ni dobro, da model postane bolj pomemben od doseganja ciljev projekta.
Torej, če je izbran model koristen, ni nič hudega, ampak moramo razmišljati in delovati na
projektih trezno, še posebej pri integraciji testiranja v življenjski cikel od začetka do konca.
Kot smo ugotovili, je testiranje v V-modelu implicitno, saj je vključeno od začetka projekta in
vsebuje načelo, da mora biti vsak izdelek izpostavljen tako statičnim in dinamičnim testom v
najkrajšem času. Težava V-modela je pri prilagajanju sprememb, ki se pojavijo pri
spreminjanju zahtev, to je v našem dinamičnem življenju zelo pogosto in nas lahko finančno
veliko stane. Dobra stran V-modela je v njegovi preprostosti, lažjem upravljanju in
enostavnem razumevanju, saj ima vsaka faza posebne končne rezultate in postopke pregleda.
Zelo pomembno je začeti testirati v začetnih fazah razvoja programske opreme, to pomeni, da
s testiranjem pričnemo že pri določitvi funkcionalnosti in izdelavi dokumentacije programske
opreme. Vredno je investirati v zelo dobro testno okolje in testirati v okviru testnih faz, saj
nastali stroški pri odkrivanju programskih napak zelo hitro rastejo v odvisnosti od časa.
Pozneje ko napako odkrijemo, več stroškov bomo imeli z odpravo. Infrastruktura testnih
91
orodij naj bo ločena na več računalnikih. V primeru preobsežnega projekta razširimo
komponente infrastrukture še na dodatne računalnike.
Začetni strošek pri postavitvi testnega okolja je precej velik, ker je potrebno investirati v
programsko in strojno opremo ter osebje. Ker je Visual Studio 2013 izjemno obširen in
zahteven, je potrebno poskrbeti za izobraževanje osebja, da bodo lahko najbolj optimalno
uporabili orodja za testiranje ter pravilno in učinkovito izvajali teste. Kljub velikim začetnim
stroškom se skozi projekte ta strošek zmanjša, ker lahko testno okolje, testne garniture in
avtomatske teste uporabimo na različnih projektih, saj imajo določene programske opreme
zelo podobne funkcionalnosti. Prav tako pa lahko testno okolje, ki je enkrat postavljeno,
uporabljamo za vse nadaljnje projekte.
Za manipulacijo in izdelavo testnih načrtov, testnih garnitur, testnih primerov in izvedbo
ročnih testov smo se seznanili z orodjem MTM 2013 in orodjem TWA. Ugotovili smo, da ima
MTM več funkcij, kot so snemanje akcij, izdelava zaslonskih slik, dnevniki in drugi
diagnostični podatki. Z njim lahko upravljamo laboratorijska okolja. Vse te dodatne funkcije
nam omogoči Microsoft Test Runner. Orodje TWA je primerno za manj kompleksne projekte
in se lahko poveže z določeno skupino projekta, opredeljeno v Visual Studio TFS ali Visual
Studio Online.
Testno okolje naj bo ločeno od razvijalcev, komunikacija med njimi pa naj bo podprta s
kvalitetno programsko opremo, kot je Visual Studio 2013, ki nam to že omogoča s svojimi
integriranimi orodji. Osebje, ki sodeluje na razvoju programske opreme, mora nujno
sodelovati med sabo, na ta način preprečimo nastanek napak zaradi nerazumevanja.
Z diplomskim delom smo dosegli cilje, ki smo si jih zastavili na začetku. Predstavili smo tipe
testiranja, ki jih vsebuje Visual Studio 2013. Prikazali in določili smo, kateri testni tip orodja
Visual Studio spada v določeno testno fazo V-modela. Postavili smo primerno in izvedljivo
testno infrastrukturo z uporabo enega računalnika, saj za postavitev večjega sistema nismo
imeli na razpolago dovolj sredstev. Glede na pridobljeno znanje smo ponazorili uporabo V-
modela z integracijo Microsoftovih orodij in s tem omogočili drugim testerjem, ki imajo manj
izkušenj, izbiro primernega testnega orodja, infrastrukture in testnega modela.
Zaradi obsežnosti v diplomsko delo nismo vključili opisa praktičnega dela s posameznimi
orodji in tipi testiranja orodja Visual Studio. Orodja in tipe testiranja smo samo opisali in
navedli, za kaj se uporabljajo, nismo pa podrobneje opisali postopkov dela z njimi.
92
8 Viri in literatura
[1] Satheesh Kumar N, Subashni S, Guide to Advanced Software Testing, Julij 2013 [2] Jeff Tian, Software Quality Engineering -Testing Quality Assurance, and Quantifiable
Improvement, 2005 [3] Ron Patton , Software Testing, Julij 2005 [4] Taylor & Francis Group , SoftwareProjectManagementA Process-Driven Approach,
2012 [5] Ashfaque Ahmed, Software Testing as a Service, September 2009 [6] Mark Fewster, Dorothy Graham, Software Test Automation, September 1999 [7] Gerald D. Everett, Raymond McLeod Jr, Software Testing: Testing Across the Entire
Software Development Life Cycle, Avgust 2007 [8] Anne Mette Jonassen Hass, Guide to Advanced Software Testing, 2008 [9] Peter Farrell-Vinay, Manage Software Testing, 2008 [10] Tim A. Majchrzak, Improving Software Testing-Technical and Organizational
Developments, Januar 2012 [11] Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black, Foundations of
Software Testing [12] Joachim Rossberg, Mathias Oluasson, Pro Application Lifecycle Management with
Visual Studio 2012, September 2012 [13] Satheesh Kumar N, Subashni S, Software Testing using Visual Studio 2012, 2013 [14] Mickey Gousset, Brian Keller, Martin Woodward, Professional Application Lifecycle
Management with Visual Studio 2012, 2012 [15] Microsoft Visual Studio. Dostopno na:
http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Visual_Studio_2013 [3. 3. 2015]
[16] Visual Studio – Defining a Test Plan. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/dd286581%28v=vs.110%29.aspx [3. 3. 2015]
[17] Martin Woodward, Brian Keller, Mickey Gousset, Professional Application Lifecycle Management with Visual Studio 2012, September 2012
[18] Visual Studio – Choose a Process Template. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/ms400752%28v=vs.110%29.aspx [3. 3. 2015]
[19] Visual Studio – Guidance for Creating Test Plans and Test Suites. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/ff972304%28v=vs.110%29.aspx [7. 3. 2015]
[20] Visual Studio – Microsoft Test Manager vs Microsoft Visual Studio Test Professional 2013. Dostopno na: https://social.msdn.microsoft.com/Forums/vstudio/en-US/3c823d1c-9b60-4e0a-846d-5e149fce5240/microsoft-test-manager-vs-microsoft-visual-studio-test-professional-2013?forum=vstest [12. 3. 2015]
[21] Larry Brader, Howie Hilliker, Alan Cameron Wills, Testing for Continuous Delivery with Visual Studio 2012, 2012
[22] Visual Studio – Load test in the cloud. Dostopno na: https://www.visualstudio.com/get-started/test/load-test-your-app-vs [12. 3. 2015]
[23] Windows Dev Center – Get started with Windows apps. Dostopno na: https://dev.windows.com/en-us/getstarted [20. 3. 2015]
[24] Visual Studio – Standard lab environments. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/ee390842.aspx [1. 4. 2015]
93
[25] Visual Studio – Work in Team Web Access. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/ee523998.aspx [5. 4. 2015]
[26] DotNetCurry – Testing with Team Web Access using Visual Studio 2013. Dostopno na: http://www.dotnetcurry.com/showarticle.aspx?ID=951 [15. 4. 2015]
[27] Visual Studio – What's new in testing the application in Visual Studio 2013. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/dn268304.aspx [15. 4. 2015]
[28] Visual Studio - Testing your application using Microsoft Test Manager. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/jj635157.aspx [20. 4. 2015]
[29] Visual Studio – Run manual tests with Microsoft Test Manager. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/dd293545.aspx [24. 4. 2015]
[30] Visual Studio – Testing Windows Store apps. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/hh405417.aspx [10. 5. 2015]
[31] TutorialsPoint – SDLC - V-Model. Dostopno na: http://www.tutorialspoint.com/sdlc/sdlc_v_model.htm [15. 5. 2015]
[32] Unit testing. Dostopno na: http://www.softwaretestingmentor.com/test-levels/unit-testing/ [18. 5. 2015]
[33] Seven Reasons IT Projects Fail. Dostopno na: http://www.ibmsystemsmag.com/mainframe/tipstechniques/applicationdevelopment/project_pitfalls/?page=3 [25. 7. 2015]
[34] 10 Reasons that Lead to Software Project. Dostopno na: Failurehttps://www.outsource2india.com/software/SoftwareProjectFailure.asp [25. 7. 2015]
[35] Quality Assurance and Project. Dostopno na: Managementhttp://itknowledgeexchange.techtarget.com/quality-assurance/what-is-a-testing-environment-for-software-testing/ [26. 7. 2015]
[36] Application lifecycle management. Dostopno na: https://en.wikipedia.org/wiki/Application_lifecycle_management [28. 7. 2015]
[37] Microsoft Visual Studio. Dostopno na: https://en.wikipedia.org/wiki/Microsoft_Visual_Studio [29. 7. 2015]
[38] Visual Studio Lab Management. Dostopno na: https://en.wikipedia.org/wiki/Visual_Studio_Lab_Management [30. 7. 2015]
[39] Microsoft-Team Foundation Team Projects. Dostopno na: https://msdn.microsoft.com/en-us/library/ms181234%28v=vs.90%29.aspx [1. 8. 2015]
[40] Tutorialspoint-Test Plan. Dostopno na: http://www.tutorialspoint.com/software_testing_dictionary/test_plan.htm [4. 8. 2015]
[41] Wikipedia-Test Suite. Dostopno na: https://en.wikipedia.org/wiki/Test_suite [4. 8. 2015]
[42] Visual Studio-Testing the Application. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/ms182409(v=vs.110).aspx [4. 8. 2015]
[43] Visual Studio –What's new in testing the application. Dostopno na: http://msdn.microsoft.com/en-us/library/vstudio/dn268304.aspx [15. 8. 2015]
[44] Visual Studio-Standard lab environments. Dostopno na: http://msdn.microsoft.com/en-us/library/vstudio/ee390842.aspx [20. 8. 2015]
[45] Visual Studio-Testing Windows Store apps. Dostopno na: https://msdn.microsoft.com/en-us/library/vstudio/hh405417%28v=vs.120%29.aspx [20. 8. 2015]
[46] SEER-Software Project Failure Costs Billions. Better Estimation & Planning Can Help. Dostopno na: http://galorath.com/wp/software-project-failure-costs-billions-better-estimation-planning-can-help/ [29. 8. 2015]
94
[47] Sam Guckenheimer, Neno Loje, Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices, September 2012
[48] Test Plan. Dostopno na: http://softwaretestingfundamentals.com/test-plan/ [3. 3. 2016] [49] Load Testing. Dostopno na: https://en.wikipedia.org/wiki/Load_testing [4. 3. 2016] [50] Microsoft Developer Network-Verifying Code by Using UI Automation. Dostopno na:
https://msdn.microsoft.com/en-us/library/dd286726(v=vs.120).aspx [4. 3. 2016] [51] Microsoft Developer Network- Creating an Automated Test That Runs an Executable
Using Generic Tests. Dostopno na: https://msdn.microsoft.com/enus/library/dd286732(v=vs.120).aspx [7. 3. 2016]
[52] SlideShare-Test Case Management with MTM 2013. Dostopno na: http://www.slideshare.net/RalucaSuditu1/test-case-management-with-mtm-2013 [21. 3. 2016]
[53] Qatestable Blog- Definitions and Meaning: Error, Fault, Failure and Defect. Dostopno na: http://blog.qatestlab.com/2011/12/06/definitions-and-meaning-error-fault-failure-and-defect/ [4. 5. 2016]
[54] IEEE Standard Glossary of Software Engineering Terminology. Dostopno na: http://dis.unal.edu.co/~icasta/ggs/Documentos/Normas/610-12-1990.pdf [15. 4. 2016]
[55] BCS-Standards For Software Testing. Dostopno na: http://www.bcs.org/content/ConWebDoc/12416 [15. 4. 2016]
[56] Integration testing. Dostopno na: https://en.wikipedia.org/wiki/Integration_testing [17. 4. 2016]
[57] Software Testing Fundamentals-Integration Testing. Dostopno na: http://softwaretestingfundamentals.com/integration-testing/ [17. 4. 2016]
[58] System Testing. Dostopno na: http://www.softwaretestingmentor.com/test-levels/system-testing/ [18. 4. 2016]
[59] Tester's World-Chapter 2.Testing throughout the software life cycle. Dostopno na: http://testingintellectuallab.blogspot.si/2012/05/istqb-exam-chapter-2.html [18. 4. 2016]
[60] TutorialsPoint-Syntax Testing. Dostopno na: http://www.tutorialspoint.com/software_testing_dictionary/system_testing.htm [19. 4. 2016]
[61] ISTQB Exam Certification- What is Acceptance testing? Dostopno na: http://istqbexamcertification.com/what-is-acceptance-testing/ [19. 4. 2016]
[62] Acceptance testing. Dostopno na: https://en.wikipedia.org/wiki/Acceptance_testing [19. 4. 2016]
[63] Software Testing Guide-Acceptance Testing. Dostopno na: http://www.software-testingguide.com/2012/01/acceptance-testing.html [19. 4. 2016]
[64] Development Model. Dostopno na: http://www.softwaretestingmentor.com/sdlc/iterative-development-model/ [19. 4. 2016]
[65] V-Model. Dostopno na: http://www.softwaretestingmentor.com/sdlc/vmodel/ [21. 4. 2016]
