PROGRAMMEERIMINE

Testimine

Testimine on tarkvaraarenduses protsess, mille eesmärgiks on leida loodud tarkvaras võimalikke vigu ja kitsaskohti. Mida ja kuidas testitakse oleneb suuresti juba tarkvaraarenduse metoodikast, nõuetest ning loodud tarkvara olemusest ja eesmärkidest.

Tarkvara testimisviise jagatakse üldjoones kaheks: staatiliseks ja dünaamiliseks.

• Staatiline testimine
  Staatilise testimise korral otsitakse vigu programmi lähtekoodist juba enne selle käivitamist. Selle käigus kontrollitakse lähtekoodi süntaksi ja semantikavigu (selle kohastest vigadest teavitab ka kompilaator), võidakse kontrollida koodi lugedes erinevaid algoritme.

• Dünaamiline testimine
  Dünaamiline testimine näeb ette, et loodud tarkvara käivitatakse testimise jaoks ning seejärel analüüsitakse töötava tarkvara omadusi. Dünaamilise testimise võib jagada omakorda kaheks: Funktsionaalseks ja mittefunktsionaalseks testimiseks. Lihtsustatult võib öelda, et funktsionaalse testimise käigus kontrollitakse kas tarkvara teeb seda, mida vaja, mittefunktsionaalse testimise käigus aga seda, kas see töötab piisavalt hästi.

  • Funktsionaalne testimine
    Funktsionaalne testimise käigus kontrollitakse üks haaval, kas tarkvara täidab mingeid ülesandeid või funktsioone korrektselt, kas kindlate sisendparameetrite korral on tulemus alati õige ja ühesugune jne. Funktsionaalse testimise käigus ei arvestata kui kiiresti ja tõhusalt tarkvara toimib.
    Selle käigus toimub:

    • Kontrollimine, kas õigete sisendandmete sisestamisel on tarkvara väljundandmed samad, mis nende sisendandmete puhul oodatud väljundandmed.
    • Kasutaja käskluste testimine (kas käskluse andmisel juhtub see, mis juhtuma peab)
    • Kasutajaliidese funktsionaalne testimine
    • Teiste süsteemidega ühilduvuse ja integreeritavuse testimine

  • Mittefunktsionaalne testimine
    Mittefunktsionaalne testimise käigus kontrollitakse tarkvara toimimist, selle efektiivsust ja stabiilsust ja kasutatavust. Mittefunktsionaalse testimise käigus toimub:

    • Jõudluse / efektiivsuse testimine
    • Stabiilsuse testimine
    • Kasutatavuse testimine
    • Turvalisuse testimine

Hooldus [3]

Lõppversiooni valmimise ja paigaldamise järgselt on tänapäeval vajadus tarkvara lahenduse hoolduse järele. Selline vajadus on tingitud sellest, et testimise käigus ei ole tihti võimalik ette näha kõiki tekkida võivaid olukordi, koodi võib olla jäänud mittekorrektseid lahendusi ja funktsioone, teised lahendused, millega tarkvara on sidestatud, võivad muutuda, seadusandlikud aktid, mida tarkvaralahendus peab järgima, võivad muutuda jne.

IEEE standart 1219 defineerib tarkvara hoolduse järgmiselt: "The modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment." Vabatõlge eesti keelde kõlaks selliselt: "Tarkvaratoote täiustamine pärast üleandmist parandamaks vigu, parandamaks jõudlust või muid parameetreid, kohandamaks tarkvara muutunud keskkonnaga."

Põhimõtteliselt on tarkvara hooldus jagatav nelja kategooriasse:

• Kohandav: tarkvara muutmine seoses muutunud keskkonnaga
• Täiendav: tarkvara muutmine seoses uute (äri)vajadustega muudatuste tegemine
• Parandav: ilmnenud vigade parandus
• Ennetav: tulevikus tekkida võivate probleemide ennetamine

Enamus tarkvara hooldusest on kas kohandava või täiendava isdeloomuga.

Muudatuste tegemisele peab eelnema muudatuse analüüs, analüüsimisel tuleb lähtuda järgmisest kriteeriumitest:

• Muutuse tüüp – kas muudatus parandab sisulisi vigu või lisab uue funktsionaalsuse
• Muutuse ulatus – kui suure muudatusega on tegu, kui suur on muudatuse tegemiseks kuluv ressursside hulk
• Muutuse kriitilisus – kas ja kui suurel määral mõjutab muudatus tarkvara stabiilsust ja suurendab turvariske

Muudatuste mahust ja olemusest lähtuvalt on võimalik muudatusi liigitada järgmiselt:

• Versioon (version): suurem ja põhjalikum muutus, uute funktsioonide lisamisega on muudetud tarkvara struktuuri
• Väljalase (release): muudatus on lisanud uut funktsionaalsust
• Paik (patch): väiksemat sorti muudatus, lahendab mõne tekkinud probleemi või parandab vea.

Kõik muudatused tarkvara omadustes ja funktsionaalsuses tuleb kindlasti dokumenteerida. Muudatuste tegemine võib põhjustada uusi vigu ja seetõttu on äärmiselt oluline teada muudatuste olemust ja ajalugu. Kuna tarkava hoolduse käigus tekkivaid muudatusi reeglina on üsna palju, siis tuleb muudatusi ka hallata. Muudatuste haldamiseks on loodud mitmeid vahendeid ja keskkondi.

Dokumenteerimine [3]

Dokumenteerimise nõue on tarkvara arenduses täiesti möödapääsmatu, eriti tähtis on korralik dokumenteerimine kommertstarkvara projektide juures. Dokumentatsioon on vajalik, kuna arendusprojektid on muutunud oluliselt suuremaks kui need olid mõnda aega tagasi. Täna töötab ühe lahenduse väljatöötamise juures enamasti rohkem kui üks inimene, tihti isegi mitu erinevat gruppi.

Hästi-struktureeritud dokumentatsioon peab rahuldama järgmisi vajadusi:

• Õppimisvõimalus: uued inimesed, kes liituvad arendusmeeskonnaga, peavad leidma abi dokumentatsioonist arendusprojektiga tutvumisel.
• Infovahetus: kõigi tootega seotud inimestel (arendajad, projektijuhid, tugispetsialistid jne) peab olema võimalik saada neile vajalik info dokumentatsiooni abil.
• Informatsioon: dokumentatsioon peab sisaldama infot projektiga seotud arendustegevuse ja lahenduse ja kirjeldama näiteks programmi peamised nõuded ja funktsionaalsuse.

Arendusprotsessi jooksul võivad dokumentatsioonile esitatavad nõuded muutuda: näiteks arendusfaasis peab dokumentatsioon olema peaasjalikult tehniline ja võib seetõttu olla tavakasutajale raskesti mõistetav, kuid lõppversioon peab kindlasti sisaldama kasutajajuhendit mis oleks tavakasutajale lihtsalt mõistetav ja üheselt arusaadav.

Arendusprotsessis vajaliku dokumentatsiooni jaoks on loodud eraldi vahendeid, millega arenduse käigus loodud lahendusi ja tehtud muutusi on võimalik lihtsalt dokumenteerida (näiteks: tracking systems) ning mitmetesse arendusvahenditesse on integreeritud erinevad vahendid tarkvara loomise käigus luua ka tehniline dokumentatsioon (näiteks XML keeles Microsoft Visual Studios tehtud kommentaarid on võimalik hiljem koondada ühtseks dokumentatsiooniks).

Kasutajajuhendid peavad sisaldama juhendit programmi kasutamise kohta, kuid heas kasutajajuhendis on ka juhised kasutaja töö efektiivsemaks muutmiseks. Hea kasutajajuhend on nii abi- kui ka õppimisvahend. Tänapäevased kasutajajuhendid sisaldavad tihti terveid peatükke erinevate tarkvara funktsioonide efektiivsest kasutamisest.

Programmi loogika kirjeldamiseks kasutatakse nii tehnilises dokumentatsioonis kui ka kasutajajuhendis tihti voodiagramme, mis selgitavad, kuidas, mille alusel ja kuidas toimub andmete töötlemine ning kuidas programmi erinevad moodulid on suhestatud.

Peale voodiagrammide kasutatakse dokumentatsioonis tihti lahenduse kirjeldamiseks ka otsustuspuid ja UML diagramme. Otsustuspuud on otsuste puukujuline kujutamine puul on juurtipp ning iga uus tipp sisaldab mõnda otsust, sõltuvalt otsusest liigutakse puus kuni lehtedeni, kus on lõpuks lahendid (väljundid).