1 / 16

Tarkvara testimise reaalsus

Tarkvara testimise reaalsus. Miks tarkvara ei saa ideaalseks olla. Võib usuta, et on võimalik täilikult testida tarkvara, leida kõik vead ja lõpptulemuseks saada ideaalne tarkvara. Kahjuks ei ole see nii. Põhjused: Sisendite arv on liiga suur. Väljundite arv on liiga suur.

keefe-levine
Télécharger la présentation

Tarkvara testimise reaalsus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tarkvara testimise reaalsus

  2. Miks tarkvara ei saa ideaalseks olla Võib usuta, et on võimalik täilikult testida tarkvara, leida kõik vead ja lõpptulemuseks saada ideaalne tarkvara. Kahjuks ei ole see nii. Põhjused: • Sisendite arv on liiga suur. • Väljundite arv on liiga suur. • Tarkvara läbimise teid on liiga palju • Spetsifikatsioon on subjektiivne asi • Kui kõik neid arvud teine teisega korrutada tulemuseks saame tohutu suur arv võimalikke variante mis tuleb läbi vaadata. Neid on liiga palju läbivaatamiseks.

  3. Võimatu tarkvara täielikuks testida Kui keegi selles ei usu võime lihtsat näidet pakkuda. Võtame MS kalkulaatori ja näitame mis tähendab seda täielikult testida. Kontrollime kui palju on 1+0. Saame 1. Õige. Nüüd 1+1. Saame 2. Õige. ..... Ja nii kuni 99999999999999999999999999999999+ 99999999999999999999999999999999. Pärast tuleb kontrollida 0.1+1=1.1? Võimatu ja mõttetu.

  4. Testimine on riskantne Juhul kui oli võetud otsus ei testi kõike võimalikke juhtumi, te riskite. Näiteks te ei testinud 355+300? Kui siin on mingi viga ja tarkvara on juba müüdud on väga kallis seda viga parandada. Selleks, et tarkvara oleks müüdud tuleb testimist lõpetada. Kui aga te lõpete liiga vara siis paljud juhtumid jäävad testimata. Mis teha?

  5. Testimine on riskantne • Tuleb otsustada kui palju teste on mõistlik teha. • Tuleb otsustada mis on tähtis testida ja mis ei ole.

  6. Testimine ei saa kinnitust, et vigu rohkem ei ole. • Testimine ei saa näidata et vigu rohkem ei ole. Bug mis ei ole veel leitud on lihtsalt bug millest keegi ei tea.

  7. Vead on nagu putukad. Kui testija äkki leidis bug siis on suur tõenäosus, et ta kohe leiab veel ja veel. Selleks on järgmised põhjused: • Programmeerijatel on halvad päevad. • Programmeerijad tihti teevad sama tüüpi vead. • Juhtub, et tarkvara disainis on fundamentaalne viga. Ja siis “bug follow bug”.

  8. Kuidas testimise kvaliteedi tõsta Testija peab aeg ajalt oma testimismeetodeid muutma testimise efektiivsuse tõstmiseks. Kui alati kasutada samad testid siis tulemuseks saame tarkvara milles puuduvad selle testiga määratud vead. Kuid teist tüüpi vigu võib olla palju. Seega testija peab kirjutada võimalikult palju teste , et rohkem vigu leida.

  9. Elu reaalsus Paljud vead mis testija leiab jäävad parandamata. Selleks on järgmised põhjused: • Ei ole piisavalt aega vea parandamiseks. • Võib olla see ei ole bug. • See on liiga riskantne, et seda parandada. • See ei ole seda väär.

  10. Kas see on viga? Kui tarkvaras on mingi probleem aga keegi ei ole seda veel leidnud, kas see on bug? Selle küsimuse vastamiseks vaatleme veel kord bug defenitsiooni. • Tarkvara ei tee midagi mis on spetsifikatsioonis määratud. • Tarkvara teeb midagi mis spetsifikatsioonis on keelatud. • Tarkvara teeb midagi mis spetsifikatsioonis ei ole mainitud. • Tarkvara ei tee midagi mis spetsifikatsioonis ei ole määratud, aga peab olema. Seega otsustame, et bug on bug ainult siis kui ta on leitud.

  11. Testija populaarsusest Tarkvara testijad ei ole kõige populaarsed inimesed tiimis. Selleks, et seda olukorda parandada tuleb järgida järgmiseid reegleid: • Leida vigu varsti. • Ära olla liiga entusiastlikuks. • Aeg ajalt öelda head uudised ka.

  12. Terminid ja definitsioonid • Täpsus (Precision) on kui programm vastab spetsifikatsioonile. • Korrektsus (Accuracy) spetsifikatsiooni vastab tellijate nõuetele.

  13. Terminid ja definitsioonid • Õigeks tunnistamine (Vertification) on kontroll kas tarkvara vastab oma spetsifikatsioonile. • Kehtivaks tunnistamine (Validation) on kontroll kas spetsifikatsioon vastab tellija nõuetele.

  14. Terminid ja definitsioonid Näide: Aprillis 1990 Hubble oli saadetud kosmosse. Hubbles oli suur peegel. Selle peegli testimine oli raske, sest testimine toimus maal aga kasutada oli vaja kosmoses. Seega ainus võimalus seda testida oli kontrollida spetsifikatsioonile vastus. Pärast seda kui Hubble oli orbiidile saadetud hakkas ta valesti töötama (nõrk kvaliteediga pildid). Uurimus näitas, et probleem oli just peeglis. Peegel vastas spetsifikatsioonile, aga spetsifikatsioon oli ebakorrektne. Peegel oli täpne (precise) aga ei olnud korrektne (accurate). Vertification oli õnnelik aga validation oli ebaõnnelik.

  15. Terminid ja definitsioonid • Kvaliteet (quality) tarkvara vastab tellija nõutele. • Usaldatavus (reliability) kui tihti tarkvara raksatab.

  16. Terminid ja definitsioonid • Testimise eesmärk on leida kõike vigu ja leida neid nii vara kui võimalik. • Kvaliteedi kinnituse (quality assurance) eesmärk on looma meetodeid ja standardid tarkvara arendamise protsessi parandamiseks ja takistada vigade tekkimist.

More Related