TALLINNA TEHNIKAÜLIKOOL
INFOTEHNOLOOGIA TEADUSTKOND
INFORMAATIKAINSTITUUT
Puhkuste ja töölt eemalolekute haldamise
rakenduse testimine
Projekt õppeaines “
Tarkvara kvaliteet ja
standardid ”
Autorid:
Martin Koidu
Li s Mironova
Pi a Ploovits
Rühm:
IABM10
Esitatud (esmane):
22.11.2015
Esitatud (täiendus):
20.12.2015
Juhendaja :
Stanislav Vassiljev
TALLINN 2015
Sisukord
1.
Ülesande püstitus.
Organisatsioon , süsteem, metoodika .................................................... 4
1.1.
Organisatsioon (ja süsteem) ............................................................................................... 4
1.2.
Süsteem (ja organisatsioon) ............................................................................................... 6
1.3.
Metoodika .......................................................................................................................... 7
2.
Eesmärgid. Nõuded süsteemile ............................................................................................ 8
2.1.
Funktsionaalsed nõuded .......................................................................................................... 8
2.2.
Mittefunktsionaalsed nõuded .......................................................................................... 17
3.
Hankimise tegevused .......................................................................................................... 25
3.1. Rakendatava elutsüklimudeli kirjeldus ................................................................................... 25
3.2. Hankija osalus hankes ............................................................................................................ 26
3.3. Nõuete
muudatuste haldamine ............................................................................................. 26
3.4. Vastuvõtmise plaan ................................................................................................................ 27
4.
Riskid ja vastuvõtutestid ...................................................................................................... 29
4.1. Riskide hinnang ...................................................................................................................... 29
4.2. Vastuvõtutestide koostamine ................................................................................................ 30
5.
Esmane hinnang ja sel e põhjendus .................................................................................... 33
5.1. Testide salvestamine ja täitmine ............................................................................................ 33
5.2. Esmane hinnang ..................................................................................................................... 33
6.
Läbivaatused ........................................................................................................................ 34
7.
Funktsionaalsed testid valitud al süsteemile ...................................................................... 36
7.1. Funktsionaalselt
testitav komponent ja detailsed nõuded .................................................... 36
7.2. Funktsionaalsed testid ............................................................................................................ 37
7.2.1. Detailsed nõuded ................................................................................................... 37
7.2.2. Kriteeriumite võimalikud väärtused, ekvivalentsiklassid ja pi rjuhud .................... 41
7.3. Funktsionaalsete testide salvestamine ja täitmine ................................................................ 47
8.
Mittefunktsionaalsed testid ................................................................................................ 52
8.1. Riskipõhiste mittefunktsionaalsete vastuvõtutestide täitmine .............................................. 52
8.1.1. Mittefunktsionaalsete vastuvõtutestide kokkuvõte .............................................. 57
9.
Programmipõhised testid .................................................................................................... 59
9.1. Testitav programm või
moodul .............................................................................................. 59
9.2. Programmipõhiste testide koostamine .................................................................................. 60
2
9.3. Programmipõhine testimine, tulemused ja hindamine .......................................................... 61
10.
Kokkuvõte ja lisad ................................................................................................................ 65
10.1. Süsteemi hindamine, riskianalüüs ja vastuvõtmine ............................................................. 65
10.2. Projektist saadud kogemuse analüüs ................................................................................... 65
10.3. Kasutatud kirjanduse
loetelu ................................................................................................ 66
3
1. Ülesande püstitus. Organisatsioon, süsteem, metoodika 1.1. Organisatsioon (ja süsteem) Testitavaks rakenduseks on tarkvara kui teenus
mudelil (SaaS) opereeriv ning reaalselt
eksisteeriv lahendus nimega “Somno”. Kasutatava mudeli puhul on tarkvaral
organisatioone üks kuni mitu, seetõttu ei saa aluseks võtta ühes organisatsioonis välja
kujunenud protsesse.
Kõnealusel rakendusel on ni teostajaks kui ka tel ijaks üks organisatsioon. Seega
mõistetakse hankija rol i all ettevõtte tootearendustiimi, kel e ülesanne on lõpptarbijate
nõuded kokku koguda ning seejärel organisatsiooni arendusosakonna abil lahendus
välja töötada.
Organisatsiooni all mõistame sedapuhku aga lõpptarbijat -‐ ettevõtet, kes tarkvara kui
teenust igapäevaselt kasutab.
Tarkvaralise rakenduse “Somno” eesmärk on hallata väiksemate ning keskmise
suurusega ettevõtete töötajate puhkuseid ning töölt eemalolekut.
Rakenduse peamiseks väärtuseks organisatsiooni jaoks on põhjaliku ülevaate andmine
ettevõtte inimressurssidest.
Lisaks:
• võimaldab
rakendus puhkuste ja töölt eemalolekute avalduste
esitamist lihtsalt ja
mugaval paberivabal kujul;
• puhkuste ja töölt eemalolekute
märkimine rakenduse abil on organisatsiooni töötajate
jaoks oluliselt ki rem, kuna rakendus võimaldab automaatset puhkusepäevade jäägi
arvutamist;
• puhkuste ja töölt eemalolekute menetlemine on rakendust kasutades oluliselt tõhusam,
kuna kinnitamine toimub organisatsiooni töötajate jaoks ühes keskkonnas;
• rakendus hoiab organisatsiooni töötajaid kursis
infoga , kes peab keda asendama ja see
info on alati ajakohane;
4
• organisatsiooni töötajatel on rakenduse vahendusel alati teada, kui palju on neil järel
puhkusepäevi;
• rakendus võimaldab organisatsiooni töötajatel paremini oma puhkuseid
planeerida , kuna
alati on hea ülevaade, kes kuna puhkab;
• organisatsiooni personalitöötajad saavad rakenduses oleva aruandluse põhjal märgata
töötajaid, kes võivad ol a läbipõlemisohus või kel e suhtes võib esineda oht ettevõttest
lahkuda.
Rakenduse kri tilisemad omadused taanduvad kõik ühele kriteeriumile – kasutajate rahulolu.
Tegemist on tarkvara kui teenus tüüpi rakendusega, mis tähendab, et rahulolematud kliendid
võivad vastava pi ri ületamisel lõpetada teenuse tarbimise.
Lisaks sel ele võivad probleemid turvalisusega tuua kaasa
täiendavaid kulutusi (näiteks kui peaks
toimuma andmete leke).
Turvalisus • kõik kasutajad peavad olema tuvastatavad, omama kasutajakontot ning logima sisse
kasutades e-‐
maili ja parooli;
• rakenduses sisalduvaid andmeid näidatakse vaid vastavate õigustega kasutajatele;
• rakendusega tehtavad toimingud on pi ratavad kasutajaõigustega;
• andmed peavad li kuma läbi krüpteeritud (TLS/SSL protokol ) andmekanali;
Käideldavus • taastatavus – mistahes tõrke korral peab olema süsteemi võimalik taastada. See
tähendab, et andmed peavad olema varundatud ning taastatavad;
• tõrketaluvus – rakendus peab olema suuteline säilitama spetsifitseeritud sooritusvõimet
tarkvara defektide puhul või tootele spetsifitseeritud li dese rikkumise puhul.
Kasutatavus • rakenduse kasutamine peab olema lihtne ja loogiline (enamik kasutajaid ei tohiks sattuda
segadusse);
5
• mitmekeelsuse tugi
Jõudlus • süsteem peab vastama kasutaja päringule mõistliku aja jooksul (tavapäring mitte rohkem
kui 2 sekundit);
• suutlikus teenindada korraga suurt hulka kasutajaid (vähemalt 200 kasutajat samal hetkel
leheküljel).
Üldjuhul on huvipoolteks kõik ettevõtte töötajad, kuid eksisteerivad kasutajad, kel e jaoks pakub
rakendus spetsi filisemaid ning ainult nende tööülesannetega seotud funktsionaalsusi.
Järgnevalt on välja toodud kõik rakenduses toimetavad huvipooled alustades arvuliselt kõige
suuremast grupist:
•
tavatöötajad – töötajad, kel e soov on esitada rakendust kasutades taotlusi puhkuseks
või muul
põhjusel vabadeks päevadeks. Samuti soovivad nad saada infot asendajate
kohta;
•
juhtkond – soovib saada rakendusest infot, mis võimaldab planeerida inimressursse
tööjaotuse planeerimiseks;
•
raamatupidajad – soovib saada rakendusest infot, mis on vajalik palgaarvestuseks;
•
personalitöötajad – peamine ülesanne rakenduses on hallata töötajaid ning nendega
seotud infot. Samuti soovivad personalitöötajad näha statistilist infot töötajate
puhkustest ja haiguspäevadest.
1.2. Süsteem (ja organisatsioon) Rakenduse kõik õigused edasi
arendamiseks ning levitamiseks jäävad sel e loonud ettevõtte
omandisse. See tähendab, et ni hankija kui ka
arendaja omavad samu õiguseid.
Lõppkasutajatele müüakse õigust vastavat rakendust kasutada. Andmed, mis lõppkasutaja
süsteemi tekitab, kuuluvad lõppkasutajale. See tähendab, et kui
klient ei soovi enam “Somno”
poolt pakutavat teenust kasutada, si s on tal õigus vajadusel oma 7 ettevõttega seotud andmed
süsteemist kätte saada. Sel isel juhul on vaja pöörduda klienditoe poole.
6
1.3. Metoodika Käesolevas projektis
testitakse olemasolevat tarkvara hankija seisukohalt. Seetõttu on
valikulistest osadest teostamiseks valitud “Hankimise tegevused” ja “Läbivaatused”. Hankija
vaatest on
eelpool nimetatud osad olulised sel eks, et hankimise ja tarkvara implementeerimise
protsessid oleksid jälgitavad, dokumenteeritud ning tagaksid võimalikult sujuva töö ni hankija
kui ka arendaja seisukohalt. Kokkuvõttes loob see hea aluse kvaliteetse tarkvara loomiseks.
Nõuete kirjeldamisel on lähtutud tarkvaraarenduses levinud FURPS+ mudelist. Mudel näeb ette
nõuete jaotamist järgmistesse üksustesse:
• funktsionaalsus (
functionality);
• kasutatavus (
usability);
• usaldusväärsus (
reliability);
• jõudlus (
performance );
• teenindatavus (
supportability)
Kõikidele töös kirjeldatud funktsionaalsetele nõuetele luuakse automaattestid kasutades
Codeception raamistikku.
Codeception võimaldab kirjutada kasutaja
vastuvõtu -‐, funktsionaal-‐
ning ühikteste. Käesoleva töö raames on pi rdutud funktsionaalsete ja ühiktestidega.
(Codeception Group, 2015)
Reaalselt käivitatakse käesolevas töös loodud testid enne iga uue funktsionaalsuse
kättesaadavaks tegemist lõppkasutajatele kasutades
Continuous Integration lahendust Codeship,
mis peale automaattestide läbimist rakenduse avalikus veebiserveris kättesaadavaks teeb.
7
2. Eesmärgid. Nõuded süsteemile 2.1. Funktsionaalsed nõuded
Käesolevas peatükis kirjeldatakse funktsionaalsed nõuded ning nendega seotud kasutusjuhud.
F01: Olemasoleva kasutaja rakenduse poolt tuvastamine Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 1. Kasutajal peab olema eelnevalt loodud rakendusse kasutaja.
2. Kasutaja asub sisselogimise leheküljel.
Järeltingimused: Kasutaja on sisse logitud (st kasutaja näeb oma nime üleval vasakus nurgas).
Põhistsenaarium: 1. Kasutaja sisetab oma e-‐posti aadressi ja parooli.
2. Kasutaja klikib nupul “Sign me in!”.
3. Rakendus tuvastab kasutaja ja logib kasutaja rakendusse.
F02: Osakondade lisamine Tegutsejad: kõik vastavate õigustega kasutajad, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. Kasutaja omab toimingu teostamiseks vastavaid õiguseid.
3. Kasutaja on leheküljel “Osakonnad”.
Järeltingimused: Uus
osakond on rakendusse loodud ning nähtav osakondade nimekirjas.
8
Põhistsenaarium: 1. Kasutaja klikib nupul “Lisa uus osakond”;
2. Rakendus kuvab akna uue osakonna sisestamiseks koos järgnevate kohustuslike
sisestusväljadega:
1. osakonna nimi;
2. kirjeldus;
3. 1. kinnitaja;
4. 2. kinnitaja;
5. 3. kinnitaja.
3. Kasutaja täidab kõik nõutud väljad;
4. Kasutaja vajutab nupul “Lisa osakond”;
5. Rakendus lisab süsteemi uue osakonna;
6. Rakendus kuvab kasutajale teate “Uus osakond lisatud”;
7. Kasutaja näeb osakondade nimekirjas lisatud
osakonda .
F03: Uue töötaja lisamine Tegutsejad: kõik vastavate õigustega kasutajad
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud;
2. Kasutaja omab toimingu teostamiseks vastavaid õiguseid;
3. Kasutaja on lehel “Töötajad”.
Järeltingimused: Uus
töötaja on rakendusse lisatud.
Põhistsenaarium: 1. Kasutaja klikib nupul “Lisa uus töötaja”;
2. Rakendus kuvab akna uue töötaja sisestamiseks koos järgnevate kohustuslike
sisestusväljadega:
9
1. eesnimi;
2. perenimi;
3. sünnipäev;
4. ettevõttes alates;
5. e-‐mail;
6. osakond;
7. kinnitaja.
1. Kasutaja täidab kõik nõutud väljad;
2. Kasutaja vajutab nupul “Lisa töötaja”;
3. Rakendus lisab süsteemi uue töötaja;
4. Rakendus kuvab kasutajale teate “Uus töötaja lisatud”;
5. Kasutaja näeb osakondade nimekirjas lisatud töötajat.
F04: Esitatud taotluse kinnitamine asendaja poolt Tegutsejad: kõik kasutajad (asendaja), rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud;
2. kasutaja on just taotluse esitamise aknas vajutanud nuppu “saada kinnitamisele”.
Järeltingimused: taotlus on staatuses “juhu kinnituse ootel”
Põhistsenaarium: 1. rakendus
saadab teavituse asendajaks märgitud töötaja e-‐posti
aadressile ;
2. asendaja vajutab
mailis sisalduval nupul “kinnita asendamine”;
3. rakendus märgib taotluse staatusesse “juhi kinnituse ootel”;
4. rakendus kuvab kasutajale teate “asendus kinnitatud”.
F05: Uue taotluse esitamine Tegutsejad: kõik kasutajad, rakendus
10
Eeltingimused: Kasutaja on rakendusse sisse loginud.
Järeltingimused: Kasutaja näeb teadet “Taotlus on
saadetud kinnitamisele”.
Põhistsenaarium: 1. Kasutaja vajutab nupule “Uus puhkuse taotlus”;
2. Rakendus kuvab akna uue taotluse sisestamiseks koos järgnevate kohustuslike
sisestusväljadega:
o periood;
o asendaja;
o puhkuse liik;
o
puhkusetasu maksmine ;
o kommentaar.
3. kasutaja täidab kõik nõutud väljad;
4. kasutaja vajutab nupul “Saada kinnitamisele”;
5. rakendus lisab taotluse süsteemi;
6. rakendus kuvab kasutajale teate “Taotlus on saadetud kinnitamisele”.
F06: Töötajate vaatamine osakondade kaupa Tegutsejad: kõik kasutajad
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud;
2. Kasutaja asub leheküljel “Töötajad”.
Järeltingimused: Töötajate nimekirjas kuvatakse ainult vastava osakonna töötajad.
Põhistsenaarium: 1. Kasutaja valib osakonna valiku menüüst soovitud osakonna ning klikib sel el;
2. Rakendus kuvab töötajate nimekirjas ainult valitud osakonda kuuluvad töötajad.
11
F07: Töötaja info muutmine Tegutsejad: kasutajad, kel el on vastavad õigused, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. Kasutaja omab toimingu teostamiseks vastavaid õiguseid.
3. Kasutaja on lehel “Töötajad”.
Järeltingimused: 1. Kasutaja näeb teadet “Töötaja info muudetud”.
2. tTöötaja info on rakenduses muudetud.
Põhistsenaarium: 1. Kasutaja klikib töötaja info muutmise nupul.
2. Rakendus kuvab kasutajale töötaja info muutmise akna pealkirjaga “Töötaja
muutmine”.
3. Kasutaja muudab soovitud välja väärtust.
4. Kasutaja vajutab nupul “Salvesta”.
5. Rakendus salvestab muudatused andmebaasi.
6. Rakendus kuvab kasutajale teate “töötaja info muudetud”.
F08: Töötaja kustutamine Tegutsejad: kasutajad, kel el on vastavad õigused, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. Kasutaja on lehel “Töötajad”.
3. Kasutaja omab toimingu teostamiseks vastavaid õiguseid.
4. Kustutamisele mineval töötajal ei tohi ol a esitatud ühtegi
taotlust .
12
Järeltingimused: Töötaja on rakendusest kustutatud.
Põhistsenaarium: 1. Kasutaja klikib töötaja
kustutamise nupul.
2. Rakendus kuvab kasutajale akna küsimusega “Kas oled kindel, et soovid töötajat
kustutada?” ning järgmised valikud: “Tühista”, “Jah, kustuta”.
3. Kasutaja vajutab nupul “Jah, kustuta”.
4. Rakendus
kustutab kasutaja andmebaasist.
5. Rakendus kuvab kasutajale teate “Töötaja on kustutatud”.
F09: Enda taotluse logi vaatamine Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. Kasutaja on lehel “Töölaud”
Järeltingimused: logi on kasutajale kuvatud
Põhistsenaarium: 1. kasutaja klikib nupul “vaata logi”;
2. rakendus kuvab kasutajale akna pealkirjaga “Logi nfo” kus on näha kasutaja taotluse
logikirjed
F10: Osakonna kustutamine Tegutsejad: kõik kasutajad kel el on vastavad õigused, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. kasutaja on lehel “osakonnad”;
13
3. kasutajal on õigused osakondade kustutamiseks
4. osakonnas ei ole ühtegi inimest
Järeltingimused: osakond on andmebaasist kustutatud
Põhistsenaarium: 1. kasutaja klikib osakonna kustutamise nupul;
2. rakendus kuvab kasutajale kasutajale dialoogi küsimusega “kas sa oled kindel, et soovid
osakonda kustutada?” ja järgmised valikud: “tühista”, “jah, kustuta”;
3. kasutaja vajutab nupul “jah, kustuta”;
4. rakendus kustutab osakonna andmebaasist;
5. rakendus kuvab kasutajale teate “osakond on kustutatud”
F11: Teise töötaja esitatud taotluste vaatamine Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. kasutaja on lehel “Töölaud”
Järeltingimused: teise töötaja esitatud taotlused on kasutajale kuvatud
Põhistsenaarium: 1. kasutaja klikib töötaja nimel;
2. rakendus kuvab kasutajale akna töötaja andmestikuga;
3. kasutaja klikib vahelehel “Taotlused”;
4. rakendus kuvab kasutajale valitud töötaja taotlused
F12: Perioodi vahetamine puhkuste kalendris Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 14
1. Kasutaja on rakendusse sisse loginud.
2. kasutaja on lehel “Töölaud”
Järeltingimused: periood on vahetunud kalendris
Põhistsenaarium: 1. kasutaja näeb perioodi valikut kuude lühenditena (juul, aug);
2. kasutaja klikib soovitud perioodil;
3. rakendus kuvab kasutajale valitud perioodi kalendri
F13: Kasutaja enda esitatud taotluste vaatamine Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. kasutaja on lehel “Töölaud”
3. kasutaja on
esitanud taotlusi
Järeltingimused: kasutaja näeb nimekirja ainult enda taotlustest
Põhistsenaarium: 1. kasutaja klikib menüüribal, enda nimel;
2. rakendus kuvab alammenüü järgmiste valikutega;
1. minu taotlused;
2.
konto ;
3. logi välja
3. kasutaja klikib valikul “Minu taotlusd”;
4. rakendus suunab kasutaja lehele “Minu taotlused”;
5. rakendus kuvab kasutajale kõik tema esitatud taotlused.
15
F14: Osakonna kinnitajate muutmine Tegutsejad: vastava õigustega kasutajad, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. kasutaja on lehel “Osakonnad”;
3. kasutajal on vastavad õigused
Järeltingimused: osakonna kinnitaja info on muudetud
Põhistsenaarium: 1. kasutaja klikib nupul “muuda osakonda”;
2. rakendus kuvab kasutajale akna “osakonna muutmine” (koos eelnevalt täidetud
väljadega, F2);
3. kasutaja muudab osakonnale määratud kinnitaja(d);
4. kasutaja vajutab nupul “salvesta”;
5. rakendus salvestab muudatuse baasi;
6. rakendus kuvab kasutajale teate “osakonna info muudetud”
F15: Taotluse tüüpide lisamine Tegutsejad: kõik vastavate õigustega kasutajad, rakendus
Eeltingimused: 1. Kasutaja on rakendusse sisse loginud.
2. kasutaja on lehel “töölaud”
3. kasutajal on vastavad õigused
Järeltingimused: uus taotluse tüüp on rakendusse lisatud
Põhistsenaarium: 1. kasutaja klikib valikul “Seaded”;
16
2. rakendus kuvab alammenüü järgmiste valikutega:
1. ettevõtte info;
2. regionaalsed seaded;
3. taotluste seaded;
4. integratsioonid;
5. arveldus
3. kasutaja klikib valikul “Taotluste seaded”;
4. rakendus suunab kasutaja lehele “Taotluste seaded”;
5. kasutaja vajutab nupul “lisa uus taotluse tüüp”;
6. rakendus kuvab kasutajale akna järgmiste kohuslike sisestusväljadega:
1. Taotluse tüüp;
2. Lubatud päevi aastas;
3. ülekanne järgmisse aastasse;
4.
automaatne kinnitus ;
5. luba võlgu
7. kasutaja täidab kõik väljad;
8. kasutaja vajutab nupul “salvesta”;
9. rakendus salvestab uue taotluse tüübi andmebaasi;
10. rakendus kuvab teate “uus taotluse tüüp lisatud”.
2.2. Mittefunktsionaalsed nõuded Mittefunktsionaalsed nõuded on jaotatud vastavalt FURPS+ mudelile nelja kategooriasse:
kasutatavus (
usability), usaldusväärsus (
reliability), jõudlus (
performance), teenindatavus
(
supportability)
MF01: Rakendus suudab teenindada 200 samaaegset kasutajat (jõudlus) Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: Rakendus on seadistatud ja valmis kasutamiseks.
17
Järeltingimused: 200 kasutajat on süsteemi probleemideta sisenenud ning neil on võimalik
sisestada oma puhkuseid.
Põhistsenaarium: Rakendusse sisenevad üheaegselt 200 kasutajat. Kasutajad saavad probleemideta rakendusse
siseneda ning
sooritada vajalikke tegevusi.
MF02: Rakenduse põhilehed vastavad W3C standarditele (kasutatavus) Tegutsejad: rakenduse arendaja, veebileht validator.w3.org
Eeltingimused: 1. rakenduse arendajal on avatud brauseris veebileht
http://validator.w3.org/ 2. testitav veebirakendus on kättesaadav
Järeltingimused: 1. põhileht “Töölaud” on valideeruv;
2. põhileht “töötajad” on valideeruv;
3. põhileht “osakonnad” on valideeruv;
4. põhileht “raportid” on valideeruv;
Põhistsenaarium: 1. rakenduse arendaja võtab põhilehe HTML-‐koodi;
2. rakenduse arendaja asetab koodi
lahtrisse “Validate by
direct input”;
3. rakenduse arendaja vajutab nuppu “
check ”;
4. veebileht validator.w3.org kuvab valideerimise tulemuse
MF03: Rakendus toimib erinevate veebilehitsejatega (kasutatavus) Tegutsejad: kõik kasutajad, veebilehitseja
Eeltingimused: kasutajal on olemas järgmised veebibrauserid
1. Internet Explorer (11.0);
18
2. Mozil a Firefox (41.0);
3. Google Chrome (46.0)
4. Safari (8.0)
Järeltingimused: rakenduse kogu funktsionaalsus toimib eeltingimustes nimetatud
veebilehitsejates ni nagu ette nähtud.
Põhistsenaarium: 1. kasutaja avab rakenduse paralleelselt kõikides eeltingimustes nimetatud
veebilehitsejates;
2. kasutaja testib manuaalselt läbi funktsionaalsused F1 -‐ F15
MF04: Rakendus saadab uuele kasutajale kinnituse e-‐maili teel (kasutatavus) Tegutsejad: rakenduse administraator, uus kasutaja, rakendus
Eeltingimused: veebirakendus on brauseris avatud
Järeltingimused: kasutaja saab oma e-‐posti aadressile kinnituse konto registreerimise kohta,
kus on kirjas tema kasutajatunnused)
Põhistsenaarium: 1. rakenduse administraator valib “lisa uus töötaja”;
2. rakenduse administraator märgistab väljasid täites valiku “teavita kasutajat”;
3. rakenduse administraator klikib nupul “lisa kasutaja”;
4. rakendus saadab uuele kasutajale kinnitusmaili;
MF05: Rakendus on mitmekeelne (eesti, vene, inglise) (kasutatavus) Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: veebirakendus on brauseris avatud
19
Järeltingimused: kogu veebirakenduse sisu on vastavates keeltes kuvatud
Põhistsenaarium: 1. kasutaja valib veebirakenduses kolme keele vahel (eesti/inglise/vene);
2. kasutajale kuvatakse rakendus tema valitud keeles
MF06: Ühe e-‐posti aadressiga võib olla seotud ainult üks kasutaja (usaldusväärsus) Tegutsejad: administraator, rakendus
Eeltingimused:
1) Rakendus on veebilehitsejas avatud;
2) Rakenduses on varasemalt registreeritud sama e-‐posti aadressiga kasutaja
Järeltingimused: Rakendus ei võimalda eksisteeriva e-‐posti aadressiga samale aadressile uut
kasutajat registreerida ja kuvab kasutajale vastavat teadet.
Põhistsenaarium: 1. rakenduse administraator valib “lisa uus töötaja”;
2. rakenduse administraator märgistab väljasid e-‐posti lahtrisse juba olemasoleva
kasutaja e-‐maili aadressi;
3. rakenduse administraator klikib nupul “lisa kasutaja”;
4. rakendus kuvab kasutajale veateate “sel ise e-‐posti aadressiga kasutaja on juba
olemas”.
MF07: Rakendus arvutab puhkusepäevade jäägi automaatset vastavalt puhkuse tüübile (kasutatavus) Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 1. Kasutajal peab olema ees aken “Uus puhkuse taotlus”.
20
2. Puhkuse tüüp peab olema seotud kasutajaga.
Järeltingimused: Rakendus on automaatselt arvutanud puhkusepäevade jäägi.
Põhistsenaarium: 1. Kasutaja sisestab perioodi alguse ja lõpu kuupäevad.
2. Rakendus kuvab puhkusepäevade jäägi.
MF08: Rakenduse põhifunktsioonid on teostatavad mobiilsetel seadmetel (kasutatavus) Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: Kasutaja on avanud rakenduse mobi lsel seadmel (tahvelarvuti, nutitelefon).
Järeltingimused: 1. Rakendus kohandub vastavalt ekraani laiusele.
2. Põhifunktsioonid (F1 -‐ F15) on teostatavad.
Põhistsenaarium: 1. Kasutaja avab seadme veebilehitsejas rakenduse.
2. Kasutaja testib manuaalselt läbi funktsionaalsused F1 -‐ F15.
MF09: Kasutajad pääsevad rakenduse funktsionaalsustele ligi vaid vastavaid õiguseid omades Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: kasutaja on rakendusse sisse loginud
Järeltingimused: 1. Rakendus on käivitatud kasutajale määratud õigustes.
2. Kasutajali deses ei kuvata rohkem valikud kui tema õigused ette näevad.
3. Keelatud
toiminguid ei saa teostada.
4. Lubatud toimingud peab saama takistusteta teostada.
21
Põhistsenaarium: 1. Rakendusse sisenetakse tavakasutajana.
2. Rakendus kontrol ib kasutajale õigustega lubatud toimingute teostamise võimalust ning
õigustega keelatud toimingute teostamist.
MF10: Kasutaja päringute/toimingute töötlemine ei ületa kahte sekundit (kasutatavus) Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: Rakendus on valmis kasutamiseks.
Järeltingimused: Toimingute töötlemise ki rus vastab nõuetele (mitte rohkem kui kahe
sekundiga).
Põhistsenaarium: 1. Süsteemi sisenenud kasutaja sooritab rakenduses võimaldatud tegevusi nagu: kõnele
vastamine, kirja avamine, kirja saatmine jms. Tegevuse käivitamise hetkest kuni
süsteemi vastuseni ei tohi kuluda rohkem kui kaks sekundit.
MF11: Rakendus on 24 tunni jooksul kättesaadav/toimiv 99,9%. Tõrkeid võib olla
maksimaalselt 2 (usaldusväärsus) Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: 1. rakendus on valmis kasutamiseks ja töötab tõrgeteta;
2. kõikide põhifunktsionaalsuste jaoks peavad olema funktsionaalsed automaattestid
Järeltingimused: rakenduse töös esineb 24 tunni jooksul maksimaalselt 2 tõrget
Põhistsenaarium: 1. rakendus käivitatakse testperioodiks kestvusega 1 nädal;
2. testperioodi jooksul monitooritakse rakenduse toimimist käivitades järjest rakenduse
põhifunktsionaalsusi (F01 -‐ F15);
22
3. funktsionaalsete testide tulemused logitakse maha;
4. testperioodi lõppedes kontrol itakse
esinenud vigade arvu vastavust nõuetele
MF12: Rakendus võimaldab uut puhkuse taotluse esitamist alustada 1 klikiga Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: Kasutaja on rakendusse sisse loginud.
Järeltingimused: Uut puhkuse taotluse esitamist on alustatud 1 klikiga.
Põhistsenaarium: 1. kasutaja vajutab nupule “Uus puhkuse taotlus”;
2. Rakendus kuvab kasutajale uue puhkuse taotluse
MF13: Kogu liiklus toimub krüpteeritud turvakanali (SSL/TLS) kaudu Tegutsejad: kõik kasutajad, rakendus
Eeltingimused: Rakendus on töökorras.
Järeltingimused: Li klus toimub kasutades krüpteeritud andmekanalit.
Põhistsenaarium: 1. Kasutaja avab rakenduse veebilehitsejas.
2. Kasutaja leiab veebilehitsejas aadressirea.
3. Kasutaja vaatab, kas aadressireal on rakenduse domeeninime ees HTTP või HTTPS.
MF14: Kasutusjuhend on leitav maksimaalselt ühe klikiga Tegutsejad: kõik kasutajad, rakendus
23
Eeltingimused: Kasutaja on rakendusse sisse loginud. Rakenduse kasutusjuhendid peavad
olema olemas
Järeltingimused: kasutajale
avaneb rakenduse kasutusjuhend
Põhistsenaarium: 1. kasutaja teeb ühe kliki kasutusjuhendi lingil;
2. kasutajale avaneb rakenduse kasutusjuhend
MF15: Rakenduse andmebaasi automaatsete varukoopiate tegemine vähemalt kord 24 tunni
jooksul Tegutsejad: skript
Eeltingimused: 1. varukoopiate tegemiseks on loodud automaatne skript;
2. skript on konfigureeritud automaatselt 24 tunni jooksul käivituma;
3. andmebaasi
server on kättesaadav;
4. kettal on ruumi varukoopia salvestamiseks
Järeltingimused: Iga 24 tunni kohta on kettal olemas varukoopia andmebaasist.
Põhistsenaarium: 1. Skript käivitub.
2. Skript salvestab andmebaasi varukoopia kettale.
24
3. Hankimise tegevused 3.1. Rakendatava elutsüklimudeli kirjeldus
Rakenduse arendamine toimub
Scrum (vt Joonis 1) elutsüklimudeli järgi. Scrum on oma
olemuselt iteraktiivne ning inkrementaalne meetod, mil e üks põhiprintsi pe on tihe suhtlus
tel ijaga. Kuna käesolava töö raames testitava tarkvara hankija ning arendaja on mõlemad samas
ettevõttes, si s vahetu suhtlus on juba eos toimiv.
Lisaks võimaldab Scrum metoodika uusi arendusi tarnida lõpptarbijateni tunduvalt ki remini kui
mõne teise metoodika puhul. (Learn Scrum, 2015)
Ühe arendustsükli (sprindi) pikkus on üldjuhul kaks nädalat.
Tsükkel algab
planeerimiskoosolekuga, mil el vaadatakse üle kõik planeeritavad tööd. Arendustsüklisse
võetakse ainult tööd, mil e puhul on arendustiim kindel, et need sprindi lõpuks reaalselt ka tehtud
ning testitud saavad.
Lisaks planeerimiskoosolekutele toimuvad tiimides igal
hommikul lühikesed (umbes 15m).
Käesoleva töö raames tesitava projekti puhul on hommikused koosolekud natuke pikemad kuna
seal vaadatakse üheskoos üle ka eelmisel päeval tehtud tähtsamad osad koodis.
Scrum metoodika puhul on omapärane asjaolu, et kogu projekti maksumus ei ole koheselt selge.
See tähendab, et reaalne maksumus
selgub alles projekti lõpus.
25
Joonis 1 – Scrum elutsüklimudel 3.2. Hankija osalus hankes Tarkvara arendamisel on väga oluline hankija aktiivne osalus hankes, sest lõpptulemus on sel
juhul tunduvalt parem. Tarkvara hankimine sarnaneb maja ehitamisega. See tähendab, et ei saa
loota, et ehitaja ehitab tel ija soovidele vastava maja valmis ilma tel ijaga vahepeal suhtlemata.
Tegemist on olukorraga, kus tel ija on “majas sees”. Seega jäävad ära mitmed organisatoorsed
tegevused nagu näiteks hanke väljakuulutamine, tarnija valimine ja lepingute sõlmimine. Uute
funktsionaalsuste arendamine ning olemasolevates muudatuste tegemine on reguleeritud
tarkvara kui teenust pakkuva ettevõtte sisemiste eeskirjade ja protseduuridega.
3.3. Nõuete muudatuste haldamine
Kuna tarkvara tel ija ja arendaja on üks ja seesama organisatsioon (
ressursid on samad), si s pole
väga suurt probeemi, kui esialgsetes nõuetes tuleb ette muudatusi.
26
Lisaks toetab muudatust nõuetes kasutusel olev Scrum metoodika, mis ei püüagi esimese hooga
tabada kõikide kasutaja nõuete paika panemist ja nö “kivisse raiumist”. Tel ija vaatab üldiselt iga
iteratsiooni lõpus üle kas tulemus on sobilik ning vajadusel lepitakse kokku muudatustes.
Mis puutub muudatuste haldamisse nõuetes, si s need registreeritakse vastavasse
taskihaldussüsteemi kohe kui soov muudatuse jaoks registreeritakse. Muudatuste juurde
lisatakse kasutajalugu ning vastuvõtukriteeriumid. Enne kui muudatus töösse võetakse, peab see
läbima joonisel 2. kirjeldatud protsessi.
Joonis 2 – nõuete ja muudatuste kokkuleppimise protsess
3.4. Vastuvõtmise plaan
Kuna tarkvara arendus toimub
Scrum metoodikal, si s tarkvara vastuvõtmine toimub iga
iteratsiooni lõpus. Peale tel ijapoolset vastuvõtutestide manuaalset sooritamist luuakse
funktsionaalsustele peale automaatsed vastuvõtutestid, mis läbitakse vi akse läbi enne
igat uue
27
funktsionaalsuse tarnet. Uus funktsionaalsus loetakse vastuvõetuks kui ka kõik eelnevad
vastuvõtutestid on edukalt läbitud.
Juhul kui tel ija otsustab teha nõuetes muudatusi, si s ei märgita vastavat funktsionaalsust enne
vastuvõetuks kui muudatused on sisse vi dud.
28
4. Riskid ja vastuvõtutestid 4.1. Riskide hinnang Riskid on jaotatud kolme prioriteedi vahel: kõrge, keskmine ja madal. Mida kõrgem prioriteet,
seda suuremat kahju sel e riski realiseerumine ni tel ija (
klient ) kui ka teostaja (teenuse osutaja)
jaoks see endast kujutab.
Antud rakenduse puhul peetakse suurimateks riskideks neid riske, mis mõjutavad kliendi
rahulolu. Al pool (vt tabel 1) on defineeritud 21 riski koos riski identifikaatori, kirjelduse ning riski
prioriteediga.
Riski ID Riski nimetus Prioriteet Vastuvõtutesti ID R01 Klient ei saa rakendusega ühendust IE, Chrome,
madal
VT05
Firefox, Opera või Safari veebilehitsejaga.
R02 Ebameeldiv kasutajakogemus madala jõudluse
keskmine
VT07
tõttu (rakendus on ülekoormatud)
R03 Kasutaja andmete leke
kõrge
VT06
R04 Andmebaasi riknemine
kri tiline
VT01
R05 Kasutaja jaoks on ebaselge, kuidas rakenduses
keskmine
mingit toimingut teha
R06 Rakendus ei saada teavitavaid e-‐maile välja
kõrge
VT08
R07 Rakendusse ei saa sisse logida
kri tiline
VT01
R08 Osakonda ei saa lisada
keskmine
VT02
R09 Taotlust ei saa esitada
Kõrge
VT03
R10 Uut töötajat ei ole võimalik rakendusse lisada
Kõrge
VT04
R11 Enda esitatud taotluse logi ei ole võimalik vaadata
madal
VT12
R12 Osakonda ei saa kustutada
keskmine
VT09
R13 Rakendus ei ole täielikult kättesaadav kasutaja
madal
VT11
soovitud keeles
R14 Rakenduses on rohkem kui üks sama e-‐maili
Keskmine
VT17
aadressiga töötaja, mil e tõttu ei ole võimalik
kasutajat tavalise sisselogimise teel (email ja
parool) tuvastada
R15 Kasutusjuhend ei ole ühe klikiga kättesaadav
Madal
VT18
R16 Rakendus ei arvuta puhkepäevade jääki
madal
automaatselt
29
R17 Osakonna kinnitajaid ei saa muuta
madal
VT13
R18 Rakenduse põhifunktsioonid ei ole kasutatavad
madal
VT20
mobi lsetel seadmetel
R19 Kasutaja enda taotlused ei ole rakenduses
keskmine
nähtavad
R20 Teiste kasutajate taotlused ei ole rakenduses
keskmine
nähtavad
R21 Perioodi ei ole võimalik vahetada
keskmine
Tabel 1 – Riskid, prioriteedid ning seotud vastuvõtutestud 4.2. Vastuvõtutestide koostamine
Vastuvõtutesti Sisend Seotud Seotud Oodatav väljund ID nõuded risk VT01 Töötajat on võimalik
F01
R07, R04 Töötaja on
rakenduses tuvastada
rakenduses
tuvastatud
VT02 Testija lisab uue osakonna
F02
R08, R04 Uus osakond on
rakendusse
lisatud
VT03 Testija lisab uue taotluse
F05
R09, R04 Uus taotlus on
rakendusse
lisatud
VT04 Testija lisab uue töötaja
F03
R10, R04 Uus töötaja on
rakendusse
lisatud
VT05 Testija püüab süsteemi a'i v
MF03,
R01, R04 Süsteem on kõigi
46.0, Internet Exploreri v 11.0,
MF02
nelja lehega
Mozil a Firefoxi v 41.0 ja Safari
kättesaadav, kõik
v 8.0.8
nõuded on
tagatud.
VT06 Testija kontrol ib, kas kogu
MF13
R03
Kogu li klus
li klus toimub krüpteeritud
toimub
turvakanali (SSL/TLS) kaudu
krüpteeritud
(
Demand Media, 2015)
turvakanali
(SSL/TLS) kaudu
30
VT07 Korraga tehakse rakenduse
MF01
R02
Rakendus töötab
pihta 200 samaaegset päringut
tõrgeteta edasi
VT08 Testija lisab uue töötaja e-‐maili
MF04
R06, R04 E-‐mail
saadetakse ning süsteem saadab konto
sisestatud e-‐
aktiveerimise andmed uue
mailile ning see
töötaja e-‐mailie
jõuab kohale.
VT09 Testija kontrol ib kas osakonda
F10
R12, R04 Osakond on
saab kustutada
kustutatud
VT10 Korraga tehakse rakenduse
MF01
R02
Rakendus töötab
pihta 50 samaaegset päringut
tõrgeteta edasi
VT11 Testija kontrol ib kas rakendus
MF05
R13, R04 Rakendus on
on kasutatav kolmes
erinevas kõigis keeltes
keeles (eesti, inglise, vene)
täielikult
kättesaadav
VT12 Testija kontrol ib kas rakendus
F09
R11, R04 Rakendus kuvab
kuvab esitatud taotluse logi
esitatud taotluste
logi
VT13 Testija kontrol ib, kas osakonna
F14
R17
Rakenduses on
kinnitajaid saab muuta
võimalik
osakonna
kinnitajaid muuta
VT14 Testija kontrol ib, kas tema
F13
R19
Kasutaja
esitatud taotlused on
taotlused on
rakenduses nähtavad
süsteemis
nähtavad
VT15 Testija kontrol ib, kas teise
F11
R20
Teiste kasutajate
töötaja esitatud taotlused on
taotlused on
rakenduses nähtavad
süsteemis
nähtavad
VT16 Testija kontrol ib, kas perioodi
F12
R21
Rakenduses on
on võimalik vahetada
võimalik perioodi
vahetada
VT17 Testija lisab samade
MF06
R14, R04 Samade
andmetega töötaja kaks korda
andmetega
kasutajat ei ole
võimalik mitu
korda lisada
VT18 Testija kontrol ib, kas ta jõuab
MF14
R15
Kasutusjuhend on
kasutusjuhendini igalt lehelt
igalt lehelt leitav
ühe klikiga
ühe klikiga
31
VT19 Testija kontrol ib kas
MF07
R16
Rakendus arvutab
puhkusepäevade jäägi
puhkusepäevade
arvutamine toimub rakenduses
jäägi
automaatselt
VT20 Testija kontrol ib, kas
MF08
R18
Rakenduse kõik
rakenduse põhifunktsionaalsus
põhifunktsioonid
toimib mobi lsetel seadmetel
on kasutatavad
mobi lsetel
seadmetel
Tabel 2 – vastuvõtutestid 32
5. Esmane hinnang ja selle põhjendus 5.1. Testide salvestamine ja täitmine Funktsionaalsed vastuvõtutestid vi di läbi
Codeception raamistiku ja
phantomjs ilma graafilise
kasutajali deseta veebilehitseja abil. Osadel juhtudel, kui testi
automatiseerimine ei olnud
võimalik, teostati testid käsitsi.
5.2. Esmane hinnang Esmase hinnangu saamiseks vi di läbi kõik peatükis 4.2. kirjeldatud vastuvõtutestid. Läbi vi dud
testidest (20 tk) kukkus läbi 4 testi, mis näitab, et rakenduse kvaliteeti annab kindlasti veel
parandada.
Läbi kukkunud testide seas oli 2 koormustesti, mis näitab, et enne suurema hulga kasutajate
peale lubamist tuleks vaadata üle serveri seadistus ning võimalusel lisada täiendavat võimsust.
Vastuvõtutesti ID Testimise kuupäev Läbis/ei läbinud VT01 03.12.2015
VT02 03.12.2015
VT03 03.12.2015
VT04 03.12.2015
VT05 03.12.2015
VT06 03.12.2015
VT07 03.12.2015
VT08 03.12.2015
VT09 03.12.2015
VT10 03.12.2015
VT11 03.12.2015
VT12 03.12.2015
VT13 03.12.2015
VT14 03.12.2015
VT15 03.12.2015
VT16 03.12.2015
VT17 03.12.2015
VT18 03.12.2015
VT19 03.12.2015
VT20 03.12.2015
Tabel 3 – Esmased vastuvõtutestid 33
6. Läbivaatused Läbivaatusi toimub tarkvaralise lahenduse “Somno” arenduses mitmeid erinevaid ning laias
laastus võib need jaotada järgmiselt:
1. arenduseelsed läbivaatused
2. arendusaegsed läbivaatused
Arenduseelsed läbivaatused Üldjuhul toimuvad eesmärgiga planeerida arendusi ja täiendusi loodavas rakenduses.
•
Esmane arendussoovide planeerimiskoosolek Eesmärk on kaardistada tootearendustiimilt tulevad soovid rakenduse edasisteks
arendusteks ja täiendusteks. Koosolekul osalevad üldiselt tootearendustiimi li kmed,
projektijuhid ja analüütik ning võimalusel ka mõni arendusmeeskonna juht. Koosoleku
raames kirjeldatakse ära kasutajalood ning pannakse paika kriteeriumid, mis peavad
olema täidetud vastava täienduse raames. Koosoleku ajaline pi r on 1 tund 30 minutit
ning sel est hoitakse
rangelt kinni.
•
Arendustööde planeerimiskoosolek (
grooming)
Koosolek, mil e sisendiks on esmaselt arendussoovide koosolekult tulnud nimekiri
soovitavatest täiendustest ning lisafunktsionaalsustest rakenduses ning nende
prioriteetidest. Koosoleku eesmärgiks vaadata üle juba eelnevalt registreeritud ja
kirjeldatud arendussoovid (
project backlog) ning veenduda, et sisend on pi sav
arendustöö alustamiseks. Kui sisend on ebapi sav, si s läheb see tagasi analüütikutele ja
projektijuhtidele, kes peavad järgmiseks koosolekuks olema puuduva info olema kätte
saanud. Koosolekul osaleb üldiselt sama koosseis nagu esmasel arendussoovide
koosolekul, kuid sedapuhku on hädavajalik arendusmeeskondade juhtide kohalolek.
Koosoleku ajaline pi r on üldiselt 1 tund 30 minutit ning sel est hoitakse rangelt kinni.
•
Arendusmeeskonna planeerimiskoosolek (
planning meeting )
Läbivaatus toimub iga arendusmeeskonnaga eraldi. Osalejateks on üldiselt projektijuht
34
ning kõik vastava meeskonna
arendajad . Üldiselt toimub koosolek iga iteraktsiooni
(
sprint) alguses.
Meeskond vaatab üle juba detailselt kirjeldatud ülesanded ning vajadusel
arutab nende implementeerimisega seotud detaile. Üldiselt püütakse iga taski jaoks
kulutada maksimaalselt 5-‐7 minutit. Koosoleku ajaline kogukulu on umbes 1 tund 30
minutit.
Arendusaegsed läbivaatused Koodi ülevaatus Üldiselt toimub 2 korda päevas (hommikul ning lõunal). Lõunase ülevaatuse
teostab tavaliselt
arendusmeeskonna juht. Hommikused ülevaatused toimuvad kogu tiimiga (4-‐5 li get) ning sel e
eesmärk on hoida kõik tiimi arendajad kursis koodis toimuvaga. Üle vaadatakse iga uus koodi
laadimine versioonihaldussüsteemi.
35
7. Funktsionaalsed testid valitud allsüsteemile 7.1. Funktsionaalselt testitav komponent ja detailsed nõuded Funktsionaalsed testid teostatakse puhkuse taotluse lisamise (vt. ekraanipilt 1) ja töötaja lisamise
(vt. ekraanipilt 2) kohta, sest need on kõige enam kasutatavad funktsionaalsused antud
rakenduses.
Ekraanipilt 1 – Uue puhkusetaotluse lisamine 36
Ekraanipilt 2 – Uue töötaja lisamine rakendusse 7.2. Funktsionaalsed testid
7.2.1. Detailsed nõuded Nõude ID: FTN01
Kriteerium : Periood
Nõue: Perioodi algus peab olema formaadis PP.KK.AAAA (näit. 01.12.2015).
Veateade : “Sisestatud perioodi algus peab olema formaadis PP.KK.AAAA.”
Nõude ID: FTN02
Kriteerium: Periood
Nõue: Perioodi lõpp peab olema formaadis PP.KK.AAAA (näit. 01.12.2015).
Veateade: “Sisestatud perioodi lõpp peab olema formaadis PP.KK.AAAA.”
Nõude ID: FTN03
Kriteerium: Periood
37
Nõue: Perioodi lõpp ei tohi ol a kronoloogiliselt enne algust.
Veateade: “Sisestatud perioodi lõpp ei saa ol a varem kui on perioodi alguses”.
Nõude ID: FTN04
Kriteerium: Periood
Nõue: Perioodi algus ja lõpp peavad olema
reaalsed kuupäevad. See tähendab, et KK ei saa ol a
rohkem kui 12, PP rohkem kui 31 ning aasta mitte vähem kui
käesolev aasta -‐1. ja mitte
rohkem kui käesolev aasta +1
Veateade: “Sisestatud perioodi alguse ja lõpu kuupäev ei ole korrektselt valitud”
Nõude ID: FTN05
Kriteerium: asendaja
Nõue: asendaja peab olema valitud
Veateade: “Taotluse sisestamiseks peab olema valitud asendaja”
Nõude ID: FTN06
Kriteerium: kommentaar
Nõue: kommentaari lahter võib ol a maksimaalselt 255 tähemärki.
Veateade: “Kommentaar pikkusel võib ol a maksimaalselt 255 tähemärki”
Nõude ID: FTN07
Kriteerium: eesnimi
Nõue: eesnime lahter peab olema täidetud
Veateade: “Eesnime väli peab olema täidetud”
Nõude ID: FTN08
Kriteerium: eesnimi
Nõue: eesnime lahter ei tohi
sisaldada järgmiseid tähemärke: ?!.123456789@£$€{[]}\~
Veateade: “Nimi ei tohi sisaldada sobimatuid sümboleid”
Nõude ID: FTN09
38
Kriteerium: eesnimi
Nõue: eesnime lahter ei tohi sisaldada rohkem kui 255 tähemärki
Veateade: “Nimi ei ole korrektne”
Nõude ID: FTN10
Kriteerium: perenimi
Nõue: perenime lahter peab olema täidetud
Veateade: “Perenime väli peab olema täidetud”
Nõude ID: FTN11
Kriteerium: perenimi
Nõue: perenime lahter ei tohi sisaldada järgmiseid tähemärke: ?!.123456789@£$€{[]}\~
Veateade: “Nimi ei tohi sisaldada sobimatuid sümboleid”
Nõude ID: FTN12
Kriteerium: perenimi
Nõue: perenime lahter ei tohi sisaldada rohkem kui 255 tähemärki
Veateade: “Nimi ei ole korrektne”
Nõude ID: FTN13
Kriteerium: e-‐mail
Nõue: e-‐maili lahter ei tohi sisalda vähem kui 5 tähemärki
Veateade: “E-‐maili aadress ei ole korrektne”
Nõude ID: FTN14
Kriteerium: e-‐mail
Nõue: e-‐maili lahter peab sisaldama ühte sümbolit “@”
Veateade: “E-‐maili aadress ei ole korrektne”
Nõude ID: FTN15
Kriteerium: e-‐mail
Nõue: e-‐maili lahter peab sisaldama kasutajanime osa (enne sümbolit “@”)
39
Veateade: “E-‐maili aadress ei ole korrektne”
Nõude ID: FTN16
Kriteerium: e-‐mail
Nõue: e-‐maili lahter peab sisaldama domeeni osa (pärast sümbolit “@”)
Veateade: “E-‐maili aadress ei ole korrektne”
Nõude ID: FTN17
Kriteerium: e-‐mail
Nõue: e-‐maili lahter ei tohi sisaldada rohkem kui 255 tähemärki
Veateade: “E-‐maili aadress ei ole korrektne”
Nõude ID: FTN18
Kriteerium: Ettevõttes alates
Nõue: Juhul kui väli ettevõttes alates on täüidetud, peab se olema formaadis PP.KK.AAAA (näit.
01.12.2015)..
Veateade: “Kuupäev peab olema formaadis PP.KK.AAAA”
Nõude ID: FTN19
Kriteerium: Telefon
Nõue: Telefoni väli võib sisaldada ainult numbreid ja “+” märki
Veateade: “Telefoninumber ei ole korrektne”
Nõude ID: FTN20
Kriteerium: Telefon
Nõue: Telefoni väli võib maksimaalselt 25 tähemärki
Veateade: “Telefoninumber ei ole korrektne”
Nõude ID: FTN21
Kriteerium: Osakond
Nõue: Osakond peab olema valitud
Veateade: “Osakond ei ole valitud”
40
Nõude ID: FTN22
Kriteerium: Rol
Nõue: Rol peab olema valitud
Veateade: “Rol ei ole valitud”
7.2.2. Kriteeriumite võimalikud väärtused, ekvivalentsiklassid ja piirjuhud Eelnevas punktis kirjeldatud detailsetest funktsionaalsetest nõuetest tekkinud pi rväärtused ning
ekvivalentsiklassid on nähtavad järgnevas tabelis (tabel 4):
Kriteerium Võimalikud väärtused Ekvivalentsiklassid Piirjuhud Periood
pp.kk.aaaa
01.01.2014
> 01.01.(käesolev aasta -‐ 1)
01.01.2014 -‐ 31.12.
2016 31.12.2016
> 31.12.2016
Kommentaar
Maksimaalne pikkus 255
0 tähemärki
0 tähemärki
tähemärki
1-‐255 tähemärki
255
> 255 tähemärki
tähemärki
Tähed,
numbrid ning
erimärgid.
Eesnimi
Minimaalne pikkus 1
1 tähemärk
tähemärk
1-‐255 tähemärki
255
> 255 tähemärki
tähemärki
Maksimaalne pikkus 255
tähemärki
Perekonnanimi Minimaalne pikkus 1
1 tähemärk
tähemärk
1-‐255 tähemärki
255
> 255 tähemärki
tähemärki
Maksimaalne pikkus 255
tähemärki
E-‐mail
Minimaalne pikkus 5
5 tähemärk
tähemärki
5-‐255 tähemärki
255
> 255 tähemärki
tähemärki
41
Maksimaalne pikkus 255
tähemärki
Telefon
Maksimaalne pikkus 25
25 tähemärki
tähemärki
> 25
Rol
> 0
0
4
Tabel 4 – detailsete funktsionaalsete nõuete ekvivalentsiklassid Tuginedes käesoleva peatüki punktis 7.2.1 kirjeldatud detailsetele funktsionaalsetele nõuetele
ning tabelis 3 kujutatud ekvivalentsiklassidele on koostatud järgmised funktsionaalsed testid:
Testi ID: FT01
Viide nõudele (ID): FTN04
Testitav kriteerium: Periood
Sisend: Periood sisestatakse
esimesest ekvivalentsiklassist (12.11.2013 -‐ 16.11.2013)
Oodatav väljund: “Sisestatud perioodi alguse ja lõpu kuupäev ei ole korrektselt valitud”
Testi ID: FT02
Viide nõudele (ID): FTN04
Testitav kriteerium: Periood
Sisend: Periood sisestatakse teisest ekvivalentsiklassist (10.11.2015 – 15.11.2015)
Oodatav väljund: Puhkusetaotlus salvestatakse edukalt.
Testi ID: FT03
Viide nõudele (ID): FTN04
Testitav kriteerium: Periood
Sisend: Periood sisestatakse kolmandast ekvivalentsiklassist (01.02.
2017 -‐ 05.02.2017)
Oodatav väljund: “Sisestatud perioodi alguse ja lõpu kuupäev ei ole korrektselt valitud”
Testi ID: FT04
42
Viide nõudele (ID): FTN03
Testitav kriteerium: Periood
Sisend: Perioodi sisestamisel on lõpu kuupäev enne alguse kuupäeva (12.11.2015 -‐ 16.11.2014)
Oodatav väljund: “Sisestatud perioodi alguse ja lõpu kuupäev ei ole korrektselt valitud”
Testi ID: FT05
Viide nõudele (ID): FTN01
Testitav kriteerium: Periood
Sisend: Perioodi sisestamisel märgitakse perioodi alguseks “12112013”
Oodatav väljund: “Sisestatud perioodi algus peab olema formaadis PP.KK.AAAA.”
Testi ID: FT06
Viide nõudele (ID): FTN02
Testitav kriteerium: periood
Sisend: Perioodi sisestamisel märgitakse perioodi lõpuks “12112013”
Oodatav väljund: Veateade: “Sisestatud perioodi lõpp peab olema formaadis PP.KK.AAAA.”
Testi ID: FT07
Viide nõudele (ID): FTN05
Testitav kriteerium: asendaja
Sisend: Puhkusetaotluse sisestamisel jäetakse asendaja lahter täitmata
Oodatav väljund: Veateade: “Taotluse sisestamiseks peab olema valitud asendaja”
Testi ID: FT08
Viide nõudele (ID): FTN06
Testitav kriteerium: kommentaar
Sisend: Puhkusetaotluse sisestamisel sisestatakse kommentaari lahtrisse tekst, mis on rohkem
kui 255 tähemärki pikk.
Oodatav väljund: Veateade: “Kommentaar pikkuse võib ol a maksimaalselt 255 tähemärki”
Testi ID: FT09
Viide nõudele (ID): FTN07
43
Testitav kriteerium: eesnimi
Sisend: Uue töötaja lisamisel jäetakse töötaja eesnime lahter tühjaks.
Oodatav väljund: Veateade: “Eesnime väli peab olema täidetud”
Testi ID: FT10
Viide nõudele (ID): FTN08
Testitav kriteerium: eesnimi
Sisend: Uue töötaja lisamisel sisestatakse eesnime lahtrisse
muuhulgas tähemärgid mõni
järgnevatest tähemärkidest: ?!.123456789@£$€{[]}\~
Oodatav väljund: Veateade: “Nimi ei tohi sisaldada sobimatuid sümboleid”
Testi ID: FT11
Viide nõudele (ID): FTN09
Testitav kriteerium: eesnimi
Sisend: Uue töötaja lisamisel sisestatakse eesnime lahtrisse rohkem kui 255 tähemärki
Oodatav väljund: Veateade: “Nimi ei ole korrektne”
Testi ID: FT12
Viide nõudele (ID): FTN10
Testitav kriteerium: perenimi
Sisend: Uue töötaja lisamisel jäetakse perenime lahter tühjaks
Oodatav väljund: Veateade: “Perenime väli peab olema täidetud”
Testi ID: FT13
Viide nõudele (ID): FTN11
Testitav kriteerium: perenimi
Sisend: Uue töötaja lisamisel sisestatakse perenime lahtrisse muuhulgas tähemärgid mõni
järgnevatest tähemärkidest: ?!.123456789@£$€{[]}\~
Oodatav väljund: Veateade: “Nimi ei tohi sisaldada sobimatuid sümboleid”
Testi ID: FT14
Viide nõudele (ID): FTN12
44
Testitav kriteerium: perenimi
Sisend: Uue töötaja lisamisel sisestatakse perenime lahtrisse rohkem kui 255 tähemärki
Oodatav väljund: Veateade: “Nimi ei ole korrektne”
Testi ID: FT15
Viide nõudele (ID): FTN13
Testitav kriteerium: e-‐mail
Sisend: Uue töötaja lisamisel sisestatkse e-‐maili lahtrisse vähem kui 5 tähemärki
Oodatav väljund: Veateade: “E-‐maili aadress ei ole korrektne”
Testi ID: FT16
Viide nõudele (ID): FTN14
Testitav kriteerium: e-‐mail
Sisend: Uue töötaja lisamisel sisestatkse e-‐maili lahtrisse ilma “@” märgita sõna
Oodatav väljund: Veateade: “E-‐maili aadress ei ole korrektne”
Testi ID: FT17
Viide nõudele (ID): FTN15
Testitav kriteerium: e-‐mail
Sisend: Uue töötaja lisamisel sisestatkse e-‐maili lahtrisse mail ilma kasutajanime osata
Oodatav väljund: Veateade: “E-‐maili aadress ei ole korrektne”
Testi ID: FT18
Viide nõudele (ID): FTN16
Testitav kriteerium: e-‐mail
Sisend: Uue töötaja lisamisel sisestatkse e-‐maili lahtrisse mail ilma domeeni osata
Oodatav väljund: Veateade: “E-‐maili aadress ei ole korrektne”
Testi ID: FT19
Viide nõudele (ID): FTN17
Testitav kriteerium: e-‐mail
45
Sisend: Uue töötaja lisamisel sisestatkse e-‐maili lahtrisse tekst rohkema kui 255 tähemärgiga
tekst.
Oodatav väljund: Veateade: “E-‐maili aadress ei ole korrektne”
Testi ID: FT20
Viide nõudele (ID): FTN18
Testitav kriteerium: Ettevõttes alates
Sisend: Uue töötaja lisamisel sisestatakse lahtrisse “Ettevõttes alates” tekst “12112013”
Oodatav väljund: Veateade: “Kuupäev peab olema formaadis PP.KK.AAAA”
Testi ID: FT21
Viide nõudele (ID): FTN19
Testitav kriteerium: telefon
Sisend: Uue töötaja lisamisel sisestatakse lahtrisse “telefon“ number, milles on sidekriips (“-‐”)
Oodatav väljund: Veateade: “Telefoninumber ei ole korrektne”
Testi ID: FT22
Viide nõudele (ID): FTN20
Testitav kriteerium: telefon
Sisend: Uue töötaja lisamisel sisestatakse lahtrisse “telefon“ teksti, mil e pikkus on rohkem kui
25 tähemärki.
Oodatav väljund: Veateade: “Telefoninumber ei ole korrektne”
Testi ID: FT23
Viide nõudele (ID): FTN21
Testitav kriteerium: osakond
Sisend: Uue töötaja sisestamisel jäetakse lahter “osakond” täitmata.
Oodatav väljund: Veateade: “Osakond ei ole valitud”
Testi ID: FT24
Viide nõudele (ID): FTN22
Testitav kriteerium: rol
46
Sisend: Uue töötaja sisestamisel jäetakse lahter “rol ” täitmata.
Oodatav väljund: Veateade: “Rol ei ole valitud”
7.3. Funktsionaalsete testide salvestamine ja täitmine Käesolevas peatükis läbi vi dud funktsionaalsed testid on kasutades Codeception1 raamistikku.
Testid on jaotatud kahte erinevasse komplekti. Testid FT01 kuni FT08, mis on seotud taotluste
esitamise funktsionaalsusega, kuuluvad testkogumikku “RequestCest”. Ülejäänud (FT09 kuni
FT24) kuuluvad kogumikku “AddNewUserCest”, mis sisaldab eranditult uue kasutaja/töötaja
lisamise funktsionaalsusega seotud teste.
Testide käivitamiseks on eelnevalt testmasinas üles seatud ilma graafilise kasutajali deseta (nn
headless) veebilehitseja
phantomjs2. Kasutaja sisselogimise funktsionaalsust testiv automaattest
on nähtav koodinäites 1. Nimetatud test tehakse iga
funktsionaalse testi alguses. Kõikide testide
eeltingimus on, et kasutaja on rakendusse sisse loginud.
Kõik käesoleva töö raames tehtud testid on kättesaadaval järgmiselt aadressilt:
http://bit.ly/tkvaliteet public function tryToLogin(AcceptanceTester $I) <
Koodinäide 1 – Codeception raamistikus kirjutatud automaattest 1
http://codeception.com/ 2
http://phantomjs.org/ 47
Ekraanipilt 3 – Funktsionaalsete testide käivitamisel tekkiv väljund ID Kuupäev Läbis/Ei Vea Vea kokkuvõte Probleemi kirjeldus läbinud tõsidus FT01 21.11.2015
Pole
Veateadet ei
Kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a.
FT02 21.11.2015
-‐
-‐
-‐
FT03 21.11.2015
-‐
-‐
-‐
FT04 24.11.2015
keskmine veateadet ei
Kuigi oodatav tulemus oleks
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
48
takistusteta läbi vi a.
Puhkusepäevade arvestus
läheb sel est tulenevalt
segamini.
FT05 03.12.2015
-‐
-‐
-‐
FT06 03.12.2015
-‐
-‐
-‐
FT07 03.12.2015
-‐
-‐
-‐
FT08 03.12.2015
-‐
-‐
-‐
FT09 11.12.2015
-‐
-‐
-‐
FT10 11.12.2015
pole
veateadet ei
Kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a.
Kuna andmete
salvestamisel
asendatakse kõik
ohtlikud
tähemärgid, si s ei
kujuta see
rakendusele
erilist ohtu
FT11 11.12.2015
-‐
-‐
-‐
FT12 11.12.2015
-‐
-‐
-‐
FT13 11.12.2015
-‐
-‐
-‐
49
FT14 11.12.2015
pole
Veateadet ei
kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a. Selle
tulemusena jõudis
andmebaasi sisestatud
andmetest ainult esimesed
255 tähemärki, mis tähendab,
et andmed ei ole sel e vea
järel enam terviklikud
FT15 11.12.2015
-‐
-‐
-‐
FT16 12.12.2015
-‐
-‐
-‐
FT17 12.12.2015
-‐
-‐
-‐
FT18 12.12.2015
-‐
-‐
-‐
FT19 12.12.2015
-‐
-‐
-‐
FT20 12.12.2015
-‐
-‐
-‐
FT21 10.12.2015
pole
veateadet ei
kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a.
FT22 10.12.2015
pole
veateadet ei
kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a.
FT23 10.12.2015
pole
veateadet ei
kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a.
FT24 10.12.2015
pole
veateadet ei
kuigi oodatav tulemus oleks
tõsine
kuvatud ning
olnud veateade, si s seda ei
toiming läks läbi.
kuvatud vaid lasti toiming ilma
takistusteta läbi vi a.
50
Tabel 5 – funktsionaalsete testide täitmine Nagu tabelist 5 näha, si s mitte kõik testid käivitati edukalt. Kokku kukkus läbi 8 testi, mil est 7 ei
kujuta endast tõsist probleemi. Üks läbi kukkunud test (FT04) on keskmise tõsiduse astmega, mis
tähendab, et sel e likvideerimine tuleks arendusmeeskonnal ära lahendada võimalikult ki resti.
FT04 testi läbi kukkumine tähendab seda, et sisuliselt on väimalik sisestada rakendusse
puhkusetaotlus ni , et lõpu kuupäev on kronoloogiliselt enne alguskuupäeva. See tähendab
sisuliselt seda, et kui kasutaja peaks sel iste kuupäevadega avalduse süsteemi
lisama , si s
puhkusepäevade jäägi arvutamisel mitte ei võeta päevi maha vaid lisatakse ekslikult juurde.
51
8. Mittefunktsionaalsed testid Järgnevas peatükis antakse ülevaade kümne mittefunktsionaalse vastuvõtutesti täitmisest. Neist
kaks, mis on oma olemuselt koormustestid on läbi vi dud Apache jMeter tarkvara abil. (Apache
Software Foundation, 11)
Kõik mittefunktsionaalsed testid peale koormustestide on teostatud manuaalselt.
8.1. Riskipõhiste mittefunktsionaalsete vastuvõtutestide täitmine
Järgnevalt kirjeldatakse kõik käesoleva töö raames tehtud mittefunktsionaalsete
vastuvõtutestide täitmine.
Testi ID: VT05 Testija kasutab testimiseks järgnevaid brausereid:
•
Google Chrome -‐ v 46.0;
•
Internet Explorer – v 11.0;
•
Firefox – v 41.0;
•
Safari – v 8.0.
Kõikides brauserites lisab testija kasutaja, taotluse, osakonna.
Tulemus: Silmnähtavaid vigu kujunduses ei avastatud. Funktsionaalsus töötab kõikjal ni nagu
ette nähtud.
Testi ID: VT06 Testija kontrol ib rakenduse põhifunktsionaalsuseid F01-‐F15. Kõikidel lehtedel ol es jälgib testija,
et veebilehitseja aadressireal oleks turvasertifikaadi kehtivust kinnitav märk (tabalukk ning
protokol https).
Tulemus: Kogu li klus toimib läbi https protokol i ning seega on test läbitud
Testi ID: VT07 52
Testija kasutab testi läbivi miseks tarkvara Apache JMeter, mil e abil tehakse lehekülje
https://demo.somno.co pihta 200 samaaegset päringut. Test kontrol ib kas server vastas
päringule HTTP protokol i staatusega “200”.
Tulemus: Kõik päringud said oodatud vastuse (http staatus 200), mistõttu võib väita, et test on
edukalt läbitud. Kül aga ei jõudnud mysql server kõiki päringuid ära teenindada. Kuna test jooksis
arendusserveri pihta, si s live serverisse kolimisel tuleks test uuesti läbida ja veenduda, et ka
andmebaasiühendused töötavad.
Testi ID: VT08 Testija lisab rakendusse uue kasutaja teostades funktsionaalses nõudes F03 kirjeldatud sammud.
Töötaja e-‐maili lahtrisse sisestab testija vabalt valitud e-‐posti aadressi, mil ele tal on olemas
ligipääs.
Peale kasutaja lisamist kontrol ib testija kas mail koos konto kinnitusega jõudis vastavale e-‐posti
aadressile.
Tulemus: e-‐mail koos konto kinnituse andmetega jõudis testimiseks kasutatud maili aadressile
vähem kui ühe minutiga. Test on seega edukalt läbitud.
Testi ID: VT10 Testija kasutab testi läbivi miseks tarkvara Apache JMeter (vt ekraanipilt 4), mil e abil tehakse
lehekülje
https://demo.somno.co pihta 50 samaaegset päringut. Test kontrol ib kas server vastas
päringule HTTP protokol i staatusega “50”.
Tulemus: Kõik päringud said oodatud vastuse, mistõttu võib väita, et test on edukalt läbitud.
Keskmine aeg, mis kulus päringutele vastuse saamiseks oli 1232,9 mil isekundit.
53
Ekraanipilt 4 – Koormustest kasutades Apache JMeter tarkvara
Testi ID: VT11 Testija teostab manuaalselt kõik põhifunktsionaalsused (F01-‐F15) ning jälgib, et kogu sisu oleks
kuvatud vastavalt valitud keeltele.
Tulemus: Keel tulemus eesti keel vigu ei leitud
inglise
vigu ei leitud
keel
vene keel leiti järgmised vead:
•
kalendrivaates ei näidata korralikult nädalapäevade lühendeid (vt
ekraanipilt nr 5);
•
Keelevalik ”Vene” on tõlkimata;
•
Osakondade lehel jääb uue osakonna lisamise
nupp ekraani taha peitu (vt
ekraanipilt nr 6)
54
Ekraanipilt 5 – Vead venekeelses tõlkes (nädalapäevade lühendid) Ekraanipilt 6 – Vead venekeelses tõlkes (osakonna lisamise nupp)
55
Testi ID: VT17 Testija lisab rakendusse uue kasutaja teostades funktsionaalses nõudes F03 kirjeldatud sammud.
Töötaja e-‐maili lahtrisse sisestab testija juba eelnevalt kasutajale lisatud e-‐posti aadressi.
Peale kasutaja lisamist kontrol ib testija kas rakendus näitas talle veateadet.
Tulemus: Rakendus kuvab kasutajale veateate “Sel ise e-‐mailiga kasutaja on juba olemas.”
Testi ID: VT18 Testija käib läbi järgmised alamsektsioonid:
•
Töölaud
•
Töötajad
•
Osakonnad
•
Seaded
Kõikidelt lehtedelt peab olema võimalik pääseda kasutusjuhendile ligi mitte rohkem kui ühe
klikiga. Kui kasutusjuhendi akna avamiseks peab tegema rohkem kui ühe kliki, si s loetakse test
läbi kukkunuks.
Tulemus: kõikidelt lehtedelt pääses kasutusjuhendile ligi ühe klikiga.
Testi ID: VT19 Testija teostab mittefunktsionaalse nõude MF07 põhistsenaariumis kirjeldatud sammud. Kui
peale kuupäevade valikut puhkusetaotluse aknas kuvatakse testijale puhkusepäevade jääk, si s
on test edukalt läbitud.
Tulemus: Peale kuupäevade valikud kuvatakse kasutajale tema puhkusepäevade jääk.
Testi ID: VT20 Testija kasutab testimiseks mobi lseid seadmeid või nende seadmete emulaatorprogramme.
Kõikides
seadmetes lisab testija kasutaja, taotluse, osakonna. Kõikides seadmetes on kujundus
samasugune , vigu ei avastatud. Funktsionaalsus töötab kõikjal ühtemoodi.
56
Testid on vi di läbi kasutades veebilehitseja
Google Chrome’i poolt pakutavat testimise tarkvara,
mis võimaldab suurel hulgal levinud mobi lsete seadmete peal teste läbi vi a (vt ekraanipilt 7).
Tulemus: tahvlitel, mis on suuremad kui 800 pikslit laiusega oli kõik ok. Kõikel mis olid väiksemad,
esines mitmeid probleeme.
Ekraanipilt 7 – Mobi lsetel seadmetel testimine 8.1.1. Mittefunktsionaalsete vastuvõtutestide kokkuvõte Testi ID Testimise kuupäev Tulemus VT05
20.11.2015
VT06
20.11.2015
VT07
20.11.2015
VT08
20.11.2015
VT10
20.11.2015
VT11
20.11.2015
VT17
20.11.2015
57
VT18
20.11.2015
VT19
20.11.2015
VT20
20.11.2015
Tabel 6 – mittefunktsionaalsete vastuvõtutestide kokkuvõte Kokku vi di läbi 20 testi, mil est 2 ei olnud edukad. VT11 testi puhul tekkis probleeme vene
keelega, mis tänu pikkadele sõnadele tekitasid olukorra kus mõni kasutajali dese element jäi
ekraani taha peitu.
VT20 puhul oli tegemist sisuliselt sama probleemiga, mis VT11 puhulgi. Osad elemendid jäid
pisikese ekraani taha peitu. Tõenäoliselt on sel e testi mitte läbimises peamine süüdlane vähene
testimine.
58
9. Programmipõhised testid 9.1. Testitav programm või moodul Kuna käesoleva töö raames testitava rakenduse kood ei ole vabalt kättesaadav, si s on
programmipõhiste testide projekteerimiseks kasutatud avalikult ligipääsetavat Sudoku
mõistatuse lahendamise programmi, mis on kirjutatud PHP-‐s.
Programmile antakse sisendina ette 9x9
maatriks , mil es tühje lahtreid tähistatakse arvuga “0”.
Programmi käivitamisel leitakse nul ide asemele sobilikud numbrid (vt ekraanipilt 8).
Ekraanipilt 8 – programmi SudokuSolver sisend ja väljund Programmi lähtekood on kättesaadav järgmisel lingil:
https://gist.github.com/aliendeveloper/889044 59
9.2. Programmipõhiste testide koostamine Programmipõhiste testide koostamisel on kasutatud PHPUnit3 raamistiku vi mast stabi lset
versiooni, mil eks töö kirjutamise hetkel on 5.1. (Bergmann, 2015)
Testide koodi kirjutamiseks on kasutatud
JetBrains’i poolt arendatavat
PHPStorm IDE-‐t (vt
ekraanipilt nr 9).
Ekraanipilt 9 – programmipõhiste testide kirjutamine PHPStorm IDE-‐s PHPUnit raamistiku abil Testide projekteerimisel on lähtutud lauseadekvaatsuse kriteeriumist, mis tähendab seda, et
programmis iga lause peab olema vähemalt korra läbitud. Lauseadekvaatsuse põhjal testimise
valiku põhjuseks on eesmärk saavutada rahuldav tulemus minimaalse
ajaga . Kui aga testimisele
panustavat ajalist ressurssi on rohkem, si s oleks mõistlik kasutada pigem haruadekvaatsust.
Haruadekvatsus võimaldaks kontrol ida ka harusid, mil es
lauseid pole ning seetõttu
laseb programmi töökindluses paremini veenduda. (Tepandi, 1999)
3
https://phpunit.de/ 60
Ühiktestid on koostatud klassi SudokuSolver eranditult kõikidele meetoditele. Kokku on
testitavaid
meetodeid 13, mil est iga kohta on kirjutatud minimaalselt üks test. Täpsemat
ülevaadet meetoditest ning projekteeritud testidest näeb tabelist nr 7.
Testi ID Meetodi nimi If-‐lauseid/tsükleid Testide arv UT1
__construct
1/-‐
2
UT2
input()
-‐/-‐
1
UT3
solve()
-‐/-‐
1
UT4
_updateSolved()
1/2
1
UT5
_solveSudoku()
-‐/1
1
UT6
_calculateProbabilityAndSolve() -‐/-‐
1
UT7
_findPosibilities()
1/2
1
UT8
_solvePossible()
1/2
1
UT9
_checkAllSolved()
1/2
2
UT10 _solveIfSolvable()
UT11 _setValueForCell()
-‐/-‐
1
UT12 _findAllProbables()
UT13 _findGridStart()
-‐/-‐
1
Tabel 7 – programmipõhiste testide ülevaade 9.3. Programmipõhine testimine, tulemused ja hindamine
Läbi vi di 17 programmipõhist testi, mil est kõik läbiti edukalt. Vastavalt standardile ANSI/IEE Std
829 koostatud testi tulemuste raport on näha tabelis nr 8.
Identifikaator TSR-‐UT-‐01
Kokkuvõte Kõrvalekaldumised Põhjalikkuse hinnang testimisega on täidetud lauseadekvaatsus koos ühe kõrvalekaldega.
Tulemuste kokkuvõte Hinnang 61
Tegevuste kokkuvõte Testiti kõiki klassi SudokuSolver meetodeid lauseadekvaatsuse
kriteeriumi põhjal.
Allkirjad M.Koidu
Tabel 8 – programmipõhiste testide raport vastavalt standardile ANSI/IEE Std 829 Testide katvuse
analüüsimiseks on kasutatud teeki
PHP_CodeCoverage4 (versioon 3.0.2) koos
Xdebug5 laiendusega, mis genereerib HTML-‐lehestiku koos põhjaliku ülevaatega jooksutatud
testidest ning koodi katvusest (vt ekraanipilt 10, 11 ja 12).
Ekraanipilt 10 – PHP_CodeCoverage poolt genereeritud ülevaade testide katvusest Lisaks ülevaatlikule hinnangule, mis on näha eelneval ekraanipildil (vt ekraanipilt 10), võimaldab
PHP_CodeCoverage poolt genereeritud väljund analüüsida iga programmi rida ning vaadata,
mil ised testid konkreetselt mingit konkreetset rida läbivad (vt ekraanipilt 11).
4
https://github.com/sebastianbergmann/php-‐code-‐coverage 5
http://xdebug.org/ 62
Ekraanipilt 11 – iga läbitud rea kohta nähtav detailne vaade Üheks väga suureks pussiks, mida kõnealune tööri st veel võimaldab, on testide poolt läbimata
ridade tuvastamine (vt ekraanipilt 12). Kuna inimesed kipuvad eksima, si s ei saa si nkohal
eeldada, et teste kirjutavad
insenerid oleksid mingisugune erand. Võib juhtuda, et testid, mis
peaks eeldustekohaselt kõik read läbima, ei tee seda si ski.
PHP_CodeCoverage poolt
genereeritud analüüs värvib kõik läbimata koodi punaseks, mis põhimõtteliselt elimineerib
võimaluse, et mõni rida jääb kusagil kogemata läbimata.
Ekraanipilt 12 – testide poolt läbimata read 63
Nagu
eelnevast näha, si s on testitavas programmis ridu, mida ükski test kordagi ei läbi. See
tähendab seda, et lauseadekvaatsuse kriteerium ei ole 100% täidetud.
Teste kirjutades ning programmi lähtekoodi analüüsides paistab, et tegemist on ni öelda surnud
koodiga, mida programmi loogikast tulenevalt tegelikult ei olegi võimalik läbida. Selles
veendumiseks sai punasega tähistatud read lähtekoodist ära kustutatud ning mitme erineva
sisendiga programmi käivitatud. Kõikidel juhtudel oli tulemus jätkuvalt korrektne.
Eelnevale tuginedes ei saa öelda, et testitud programmi kood oleks väga kvaliteetne. Reaalses
olukorras tuleks testijal läbimata koodi osas suhelda programmi või sel e osa kirjutanud
arendajaga. Nn “surnud” koodi programmis tuleks igal juhul püüda vältida.
64
10. Kokkuvõte ja lisad 10.1. Süsteemi hindamine, riskianalüüs ja vastuvõtmine Käesoleva projekti raames läbi vi dud testide tulemusele tuginedes võib väita, et süsteemi oleks
enne suuremale hulgale kasutajatele kätte andmist vaja veel parandada/täiendada ning seejärel
täiendav testimine läbi vi a.
Üheks peamiseks murekohaks on andmebaasiserveri jõudlus, mis ei suuda teenindada suurt
hulka samaaegseid kasutajaid. Enne rakenduse avalikuks tegemist tuleks mõelda tarkvara
li gutamist võimsama andmebaasiserveri peale ning seejärel testida uuesti serveri võimsust.
Tegmist on pi savalt suure riskiga, mil e maandamiseta ei saa projektiga LIVE’i minna. Üheks
lahenduseks oleks ka rakendada andmete puhverdamist.
10.2. Projektist saadud kogemuse analüüs Kõige suurema väärtusega kogemuseks peavad autorid eelkõige automaatsete testide
läbivi mist. Kuigi ühel autoril oli eelnevalt olemas automaatsete UI testimise ning ühiktestide
tegemise kogemus, si s jõudlustestide kavandamise ning läbivi misega ei olnud ükski autor
eelnevalt kokku puutunud. Samuti polnud keegi varem kasutanud mingisugust tööri sta, mis
võimaldaks koodi testidega katvust analüüsida ni nagu seda võimaldab
PHP_CodeCoverage.
Projekt õpetas testimist vaatlema erinevatest külgedest ning rohkem läbi mõtlema testimise
protsessi.
65
10.3. Kasutatud kirjanduse loetelu
Tepandi, J. (1999).
Tarkvara kvaliteet ja standardid. Tallinn, Harjumaa: TTÜ Kirjastus.
Bergmann, S. (18. 12 2015. a.).
PHPUnit. Kasutamise kuupäev: 18. 12 2015. a., allikas The PHP
Testing Framework :
https://phpunit.de/ Codeception Group. (22. 11 2015. a.).
Advanced Usage . Kasutamise kuupäev: 22. 11 2015. a.,
allikas
Codeception
-‐
Documentation:
http://codeception.com/docs/07-‐ AdvancedUsage#.VnaM7JN95E4
Apache Software Foundation. (2015. 11 11. a.).
User's Manual. Kasutamise kuupäev: 2015. 11
11. a., allikas Apache JMeter:
http://jmeter.apache.org/usermanual/index.html Learn Scrum. (25. 11 2015. a.). Kasutamise kuupäev: 25. 11 2015. a., allikas Scrum Methodology:
http://scrummethodology.com/ Demand Media. (19. 11 2015. a.).
How to Tel If a Website Is Using SSL. Kasutamise kuupäev: 19.
11 2015. a., allikas Chron.com:
http://smallbusiness.chron.com/tel -‐website-‐using-‐ssl-‐ 53686.html
66
100 punkti
Autor soovib selle materjali allalaadimise eest saada 100 punkti.
~ 66 lehte
Lehekülgede arv dokumendis
2017-12-20
Kuupäev, millal dokument üles laeti
7 laadimist
Kokku alla laetud
0 arvamust
Teiste kasutajate poolt lisatud kommentaarid
Murtin
Õppematerjali autor
annaabi.ee 
Kõik kommentaarid