380 likes | 623 Views
Program ų sistemų testavimas. Aist ė Stikliūtė aiste.stikliute @ mif.vu.lt http://web.vu.lt/mif/a.stikliute +370 604 17281 VU MIF Programų sistemų katedra. Testavimo atvejai (TA). Kas yra TA? Kas yra geras TA? Testai (procedūros), testų rinkiniai Reikalavim ų padengimas
E N D
Programų sistemų testavimas Aistė Stikliūtė aiste.stikliute@mif.vu.lt http://web.vu.lt/mif/a.stikliute +370 604 17281 VU MIF Programų sistemų katedra
Testavimoatvejai (TA) • Kas yra TA? • Kas yra geras TA? • Testai (procedūros), testų rinkiniai • Reikalavimų padengimas • TA sudarymo strategijos • Praktiniai TA sudarymo aspektai • TA valdymo įrankiai
Kas yra testavimo atvejis? • Sąlygų ir kintamųjų rinkinys, skirtas patikrinti, ar korektiškai PĮ elgiasikonkrečioje situacijoje • TA – tarsi klausimas programai: kas bus, jei padarysiu tai? • Iš kur žinomas teisingas atsakymas? • Orakulas (Oracle): reikalavimas, panaudojimo atvejis, komunikacija, euristika, sveikas protas
TA aprašymo forma • Neformali: • Sąrašiukas, ką reikia patikrinti (bet kokia patogia forma) • Formali: • TA rašomi taip, kad padengtų visus reikalavimus • Naudojama TA aprašymo forma su nustatytais laukais
Tipinė TA aprašymo forma • TA identifikatorius • Trumpas aprašymas • Sąlygos prieš TA vykdymą • TA vykdymo žingsniai • Laukiami rezultatai ir sąlygos po TA vykdymo • Bei kiti laukai pagal poreikį
Pavyzdys: specifikacijos ištrauka • Naudotojas, kuris turi įsiskolinimų (yra negrąžinęs knygų, o rezervacijos laikotarpis pasibaigė), negali rezervuoti naujų knygų. • Knygą rezervuoti nemokamai galima ne ilgiau kaip vienammėnesiui, vėliau taikomas 5 Lt/mėn. mokestis. • Naudotojas, pasirinkęs ilgesnį rezervacijos laikotarpį, turi būti įspėjamas prieš tęsiant rezervacijos procesą.
Yra klausimų? Kas yra TA? TA aprašymo forma
Testai ir testų rinkiniai • Testas (procedūra) – TA seka • Pvz.: • Sukurti laiško juodraštį • Išsiųsti laišką iš juodraščių katalogo • Testų rinkinys (test suite) • Pvz.: el. pašto programoje adresų knygelės testų rinkinys
TA sudarymo principai • Geras TA - tas, kuris su didžiausia tikimybe suranda dar nežinomus defektus • Geras TA - tas, kuris aprašo tikėtiną scenarijų • Gerai, jei TA galima pakartoti, pakartotinai panaudoti • Kitose testavimo iteracijose • Kitose aplinkose • Regresiniam testavimui
TA sudarymo principai • TA turi apimti ne tik tinkamus pradinius duomenis, bet ir netinkamus • TA turitikrinti ne tik, ar sistema daro, tai kas aprašyta specifikacijoje, bet ir ar nedaro to, kas neaprašyta. • Formaliai - kiekvienam reikalavimui bent du TA
Reikalavimų padengimas • Atsekamumomatrica (Traceability matrix) • Reikalavimų ir TA ryšys “daug su daug”
Yra klausimų? Testas (procedūra) Testų rinkinys Kaip sudaryti gerus TA?
TA sudarymo strategijos • Remiantis specifikacija • Remiantis programos struktūra (kodu) • Remiantis patirtimi ir intuicija
TA sudarymas remiantis specifikacija • Ekvivalenčių klasių metodas • Ribinių reikšmių metodas • Sprendimų lentelės metodas • Būsenų perėjimų testavimas • Testavimas pagal panaudojimo atvejus
Ekvivalenčios klasės • Galimi įvesties duomenys suskirstomi į klases • Kiekvienai klasei – bent po vieną TA • Pvz., reikalavimas: • Draudimo kaina nepilnamečiams 100 Lt, pensininkams 200 Lt, visiemskitiems 150 Lt. • Kokiosekvivalenčiosklasės? • Galimaskirstyti ir išvesties duomenis • Dažnai jungiamas su ribinių reikšmių metodu
Ribinės reikšmės • Testuojamos ribinės reikšmės, bei artimiausios reikšmės šalia • Tas pats pvz.: • Draudimo kaina nepilnamečiams 100 Lt, pensininkams 200 Lt, visiemskitiems 150 Lt. • Kokiosribinės reikšmės?
Sprendimų lentelės • Kai specifikacijos forma – priežasčių/pasekmių analizė
Būsenų perėjimų testavimas • Sistemoms, kurių elgesys apibrėžiamas būsenomis ir įvykiais • Būsenų perėjimų diagrama TA Aktyvuoti Sukurtas Aktyvus Deaktyvuoti Ištrinti Parduoti Ištrintas Parduotas
Panaudojimo atvejai • Specifikacijos forma – panaudojimo atvejai (PA) • UML diagramos arba tekstinis aprašymas • Naudotojo veiksmų seka ir sistemos atsakas į kiekvieną veiksmą • PA TA
TA sudarymas pagal PĮ struktūrą • Žinoma detali PĮ struktūra (kodas) • Sakinių testavimas • Sprendimų/atšakų testavimas • Kelių testavimas • Modifikuotas sprendimų testavimas • Ciklomatinis sudėtingumas
Sakinių testavimas • TA rašomi taip, kad būtų ištestuotas kiekvienas programos sakinys • Tuščios eilutės ir komentarai neskaičiuojami • Matuojama procentais (statement coverage) • Pvz.: if a > b then c = a - b else c = b - a print c
Sprendimų testavimas • Arba atšakų (branches) testavimas • TA rašomi taip, kad būtų ištestuotas kiekviena vieta programoje, kur priimamas sprendimas • Matuojama procentais (decision coverage) • Tas pats pvz.: if a > b then c = a - b else c = b - a print c
Kelių testavimas • Tikslas – ištestuoti visus įmanomus kelius per programą • Sudėtingesnėms programoms – neįmanoma • Pvz., ciklas su keletuifsakinių, galinčių nukreipti programą 10 skirtingų kelių: 210kombinacijų
Modifikuotas sprendimų testavimas • Modifikuotas sprendimų testavimas: • Ištestuojamas kiekvienas galimas programos įėjimo kelias ir išėjimo kelias • Ištestuojama kiekviena kiekvieno sprendimo baigtis • Nepriklausomai ištestuojama kiekviena sprendimo sąlyga
Ciklomatinis sudėtingumas • V(G) = E – N + 2 E – briaunų skaičius, N – viršūnių skaičius • Arba: sprendimų skaičius + 1 • Kuo didesnis sudėtingumas,tuo daugiau reikiatestavimo
Patirtimi pagrįstas testavimas • Klaidų spėjimas • Tiriamasis testavimas
Klaidų spėjimas • Paremtas testuotojo patirtimi ir intuicija • Paremtas tipinių klaidų sąrašais (checklists) • Pvz.: tuščias tekstas, nulis, neigiami skaičiai, Enter mygtukas, laukų apėjimas su TAB klavišu... • Paremtas praeities klaidų analize
Tiriamasis testavimas • Testavimo rezultatai nauji testai • Pasitelkiant įgytas žinias ir kūrybiškumą • Apibrėžiama testavimo misija • Nustatomas testavimui skiriamas laikas
Yra klausimų? PĮ strukūra paremtas TA sudarymas Specifikacija paremtas TA sudarymas Patirtimi ir intuicija paremtas TA sudarymas
Praktiniai aspektai • TA sudarymo strategijos parenkamos priklausomai nuo situacijos: • Kokia yra specifikacija • Kokią turim patirtį • Gali netikti nė viena formali strategija, belieka remtis verslo logikos žiniomis
Praktiniai aspektai • Ne visada išskiriami TA ir testai (procedūros) • TA/testų jungimas ir skaidymas. Pvz.: • Atsidaryti prekės aprašymą • Pasirinkti kiekį, spalvą, dydį • Spausti “Užsakyti” • Pasirinkti “Prisijungti” • Įvesti neteisingus prisijungimo duomenis • Įvesti teisingus prisijungimo duomenis • Pakeisti adresą • Patvirtinti užsakymą
Praktiniaiaspektai 1. Rašom TA taip, kad būtų kuo patogiau testuoti 2. Rašom TA taip, kad kuo efektyviau rastume kuo daugiau defektų
Praktiniai aspektai (Pvz.) Detalūs TA paprastiems scenarijams: 1. • Atsidaryti prekės aprašymą • Pasirinkti kiekį, spalvą, dydį • Spausti “Užsakyti” 2. • Suvesti neteisingus prisijungimo duomenis • Neįvesti prisijungimo d. • Suvesti teisingus prisijungimo duomenis Supaprastintas TA ilgamscenarijui: • Prekės aprašyme spausti “Užsakyti” • Pasirinkti “Prisijungti” • Įvesti teisingus prisijungimo duomenis • Pakeisti adresą • Patvirtinti užsakymą
Praktiniai aspektai • Kartais gerai aprašyti laukiamus rezultatus po kiekvieno žingsnio. Pvz.: • Paspausti mygtuką “Užsakyti” • Atsidaro užsakymo forma su tokiais laukais: ... 2. Užpildyti formą ir patvirtinti užsakymą • Pateikiamas sėkmės pranešimas • Užsakymo duomenys perduodami į X sistemą 3. Pasirinkti “Grįžti” • Naudotojas grąžinamas į prekių sąrašą
P.A.: bendri testavimo duomenys • Naudojami skirtinguose testavimo etapuose • Privalumai: • Pagerina testavimo produktyvumą • Sumažina darbo apimtis programuotojams • Supaprastina regresinį testavimą • Trūkumai: • Reikia iš anksto paruošti • Mažėja naujų defektų radimo tikimybė
TA kūrimo ir valdymo įrankiai • TA automatinio generavimo įrankiai • TestComposer, Lutess, AsmL ... • TA valdymo įrankiai • SpiraTest, QA Track ... Daugiau – per seminarus