Süsteemi testimine ja juurutamine

Get Started. It's Free
or sign up with your email address
Rocket clouds
Süsteemi testimine ja juurutamine by Mind Map: Süsteemi testimine ja juurutamine

1. Testitakse igat funktsiooni eraldi

2. Arendaja

3. uuendamise käigus installeeritakse uus versiooni süsteemist, kohandamine on samuti süsteemi muutmine, kuid põhjuseks on peamiselt muudatuse kliendipoolses keskkonnas.

4. Testimine, mille teostab isik(ud) kes ei ole toote arendamisega otseselt seotud

5. Testimise üldreegel

5.1. Testimisega saab näidata vigade esinemist, kuid mitte vigade puudumist.

6. Jõudlus

6.1. kuluv aeg andmete reageerimiseks ja töötlemiseks

7. Porditavus

7.1. Toote omadus väljendamaks aja- ja töökulu toote kohaldamisel teistesse keskkondadesse, platvormidele.

8. Funktsiooni testimine

9. Testimise eesmärgid

9.1. Vigade leidmine

9.1.1. Otsitakse tootest vigu

9.1.2. Testimise käigus leida olukordi kus tarkvara ei vasta spetsifikatsioonile

9.2. Et programm vastaks kasutaja nõuetele

9.3. Verifitseerimise

9.3.1. Eesmärk on kinnitada, et protsessi või projekti iga tulem vastab spetsifitseeritud nõuetele.

9.3.2. "Kas me teeme tarkvarasüsteemi õigesti?" (2+2=4)

9.4. valideerimine

9.4.1. Tarkvara süsteem vastab tellimusele - teeb seda, mida tellija oli kirja pannud

9.4.2. "Kas me teeme õiget tarkvarasüsteemi?" (Telliti kalkulaator, tehti kalkulaator)

10. Stabiilsus

10.1. Toote omadus väljendamaks muudatustejärgsete ootamatute nähtuste tekkimise riski suurust;

11. Autoriseerimine

11.1. Toode toetab kasutajate hierarhiat

12. Testijad

12.1. Arendaja Kolleeg

12.2. Testimis osakond

12.3. Spetsialiseerunud ettevõte

13. Paigaldus

13.1. Toote ülesseadmine

14. Optimaalsus

14.1. Toote kõrge jõudlus tase

15. Sõltumatu osapoole testimine

16. Süsteemitestimise

16.1. korral testitakse süsteemi kui terviku töötamist.

17. Vigade dokumenteerimine testimises

17.1. Testimise käigus kõik vead dokumenteeritakse. Need aitavad programmeerijale anda tagasisidet.

17.2. Taastatavus

17.2.1. Võimalus taastada toote põhifunktsiooni

18. Tarkvaratoote levitamine

18.1. installeerimine riistvarale. Keerukamate, hajutatud süsteemide on abiks UML levitusskeemid millised kirjeldavad tarkvara paiknemist erinevatel riistvara sõlmedes, sealhulgas:

18.1.1. Avalikustamine (release). Avalikustamine järgneb arendusprotsessile. See sisaldab kõiki tegevusi, et süsteem ette valmistada assembleerimiseks (masinkoodi viimiseks) ning kliendi juurde üleviimiseks. Selle tegevuse käigus määratakse ka ressursid, mis on vajalikud töötamiseks kliendi poolel.

18.1.2. Tarkvara installeerimine ja aktiveerimine - käivituvad komponendid paigutatakse arvutitele-serveritele, kus nad edasipidi töötama peavad. Keerulisemad süsteemid vajavad lisaks ka muu toetava tarkvara installeerimist (nt andmebaasimootori uus versioon jms). Tihti installeeritakse suurem süsteem mitmesse keskkonda - näiteks lisaks ka testserverile, mida saab hiljem kasutajakoolituseks ja muudeks katsetusteks kasutada.

18.1.3. Kohandamine ja uuendamine - uuendamise käigus installeeritakse uus versiooni süsteemist, kohandamine on samuti süsteemi muutmine, kuid põhjuseks on peamiselt muudatuse kliendipoolses keskkonnas.

18.1.4. andmeülekanne vanast süsteemist - varem kasutatud süsteemis on reeglina andmed, mida tuleb ka edaspidi kasutada. Soovitav on automaatülekandevahendi loomine, milline käivitatakse ühekordselt andmete ülekandeks vanast süsteemist uude. Ülekandemehhanism võib olla päris keerukas, eriti kui vana süsteemi ja uue süsteemi andmestruktuurid on oluliselt erinevad. Kui andmete kogus on väike ja/või automaatteisenduse algoritmi väljatöötamine liigselt keerukas, on võimalik andmeid ka käsitsi üle kanda. Sellisel juhul võib olla vajalik luua raportid vanast süsteemist andmete väljavõtmiseks ja sisestusvormid vm vahendid andmete käsitsi sisestamiseks kasutuselevõetavasse süsteemi;

18.1.5. muudatuste tegemine teistesse rakendustesse, millised peavad töötama koos ja/või kasutatakse koos arendatava tarkvaratootega;

18.1.6. koolituse ettevalmistamine ja läbiviimine tarkvaratootega kokkupuutuvatele inimestele, sh järgmistele rollidele:

18.1.6.1. Igapäevased kasutajad

18.1.6.2. Administraatorid

18.1.6.3. Kasutajatoe pakkujad.

19. Kasutusjuhend

19.1. on tehniline dokument, mis peab pakkuma tuge konkreetse süsteemi kasutajatele.

20. Aktsepteerimistest

21. Kohandamine ja uuendamine

22. Avalikustamine

23. Tarkvara installeerimine ja aktiveerimine

24. Testimise tüübid

24.1. Mooduli testimine

24.1.1. Testitakse igat moodulit eraldi

24.1.2. Otsitakse vigu, mitte vastavust kasutaja nõuetele

24.1.3. Tüüpiliselt kasutatakse "Valge kast"-i meetodit - testija tunneb testitava mooduli sisemist ülesehitust ja tööloogikat

24.1.4. testitakse andmetepõhiselt: õigete, puudulike ja vigaste andmetega

24.1.5. tarkvara vastab püstitatud nõuetele. Tellija saab seda, mida oli tellinud.

24.2. Integratsioonitestimine

24.2.1. Toote osade (moodulite) koostöö testimine

24.2.2. testija on üldjuhul sõltumatu (ei ole panustanud koodi kirjutamisse)

24.3. Süsteemi testimine

24.3.1. Toote tervikuna testimine (kõik moodulid koos)

24.3.2. Testitakse funktsionaalsust

24.3.3. Testjuhtumid koostab testija (peamiselt kasutuslugude põhjal), kes testid ka läbi viib

24.3.4. Kasutatakse "must kast" meetodit - vaadeldakse kastuajaliidese poolt, koodi ei uurita, ei nähta.

24.3.5. Testijaid peab olema nii tellija kui täitja poolel

24.4. Regressioontestimine

24.4.1. on igat tüüpi tarkvara testimine, mida kasutatakse peale koodi/süsteemi viidud muudatusi.

24.4.2. Regressioontestimise eesmärk on veenduda, et muudatused ja veaparandused pole tekitanud süsteemi uusi vigu.

24.4.3. on kasulik automatiseerida üldise töökoormuse vähendamiseks

24.4.4. Peamiseks meetodiks on juba kasutatud testide taaskäivitamine veendumaks, et süsteem toimib, vanad vead ei avaldu uuesti ja ei ole tekkinud uusi

24.5. Jõudlus testimine

24.5.1. Testitakse toote jõudlust/tootevõimet

24.5.2. ei testita funktsionaalsust (Mida toode teeb?) vaid jõudlust (Kuidas toode teeb?)

24.5.3. Jõudlustesti eesmärk on tuvastada kriitilisemad kohad, kus võib tekkida ülekoormus ja nende kohtade optimeerimine

24.6. Kasutatavuse testimine

24.6.1. kasutaja liidese ja -tegevuste juures vigade leidmine

24.6.2. Testimiseks peab inimene täitma konkreetseid ülesandeid ja sel teel selguvad tarkvarasüsteemis või ka veebilehel halvasti arusaadavad kohad.

24.7. Koodi läbivaatus

24.7.1. erinevalt eelnevalt käsitletud testi tüüpidest, koodi läbivaatuse puhul koodi ei käivitata vaid koodi inspekteeritakse testija poolt.

24.8. Vastuvõtu test

24.8.1. kliendi poolt läbiviidav test valminud toote hindamiseks ja vastuvõtmiseks

24.8.2. Vastuvõtutesti testijuhtumid kirjeldavad üheselt projekti üleandmise ja vastuvõtmise kriteeriumid ning testijuhtumid peavad olema konkreetsed ja mõõdetavad ning nendes lepivad tellija ja teostaja projekti realiseerimise eel kokku

25. Nõuded tarkvara omadustele

25.1. Funktsionaalsus

25.1.1. Toote omadus väljendamaks tema sobivust seatud ülesannete täitmiseks, st tarkvaraga saab teha seda, mida klient vajab

25.2. Turvalisus

25.2.1. Toote omadus piirata äriloogikale/andmetele ligipääsu autoriseerimata isikute poolt

25.3. Tõrkekindlus

25.3.1. toote omadus väljendamaks võimet tagada teatud jõudluse ja funktsionaalsuse tase veaolukorra tekke või liidese väärkasutamise puhul

25.4. Taastuvus

25.4.1. Kui edukalt toode vigadest taastub

25.4.2. toote omadus väljendamaks võimet taastada normaalne töörežiim ja jõudlus peale veaolukorra tekkimist

25.5. Taastatavus

25.5.1. toote omadus väljendamaks keerukust ja vajaminevat töö hulka ning aega süsteemi põhifunktsionaalsuse taastamiseks avariiolukorra puhul