model testimiështë një strukturë logjike që përshkruan funksionalitetin e sistemit dhe / ose sjelljen e përdoruesit, sipas së cilës krijohen rastet e testimit. Ndërtimi i një modeli testimi fillon me ndërtimin e një strukture dhe më pas struktura e miratuar mbushet me raste testimi.

Modelet zakonisht ndërtohen në bazë të kërkesave dhe/ose sjelljes së pritur të sistemit. Ndërtimi i një modeli testimi dhe menaxhimi i tij është i përshtatshëm për sisteme të mëdha me logjikë komplekse biznesi dhe është e vështirë të zbatohet në projekte që përdorin metodologji të shkathët, sepse kostoja e mirëmbajtjes së menaxhimit të modelit të testimit dhe procesit të sigurimit të cilësisë do të jetë shumë e lartë.

Menaxhimi i modelit të testit është një proces që kontrollon mbulimin e modelit të testimit, cilësinë e skenarëve që përshkruajnë modelin e testimit dhe aktualizimin e tij.

Menaxhimi i modelit të testit është një proces i vazhdueshëm gjatë gjithë kohës cikli i jetes produkt.

Mbulimi i modelit të testimit

Për të kontrolluar mbulimin e të gjitha kërkesave, mund të përdorni matricat e gjurmës që përcaktojnë mbulimin e kërkesave sipas skenarëve të testimit (shih shembullin).
Përpara se të përshkruhen rastet e testimit, struktura e modelit të testimit duhet të miratohet me klientin.

Cilësia e skriptit

Për të menaxhuar cilësinë e skenarëve, është e nevojshme të kontrollohet jo vetëm niveli i përshkrimit të rasteve të testimit, por edhe cilësia e tyre.

Para fillimit të përshkrimit të rasteve të testimit, është e nevojshme të përcaktohen kërkesat për çdo nivel të përshkrimit dhe kriteret për cilësinë e përshkrimit të rasteve të testimit.

Nivelet e mundshme të përshkrimit të rasteve të testimit:

Në nivelin e 4-të, marrëveshja me klientin mund të zëvendësohet me marrëveshje.

Kriteret e cilësisë për përshkrimin e rasteve të testimit mund të jenë si më poshtë:

• Rastet e testimit duhet të shkruhen sipas kërkesave

Testimi është procesi i verifikimit nëse një produkt i plotëson kërkesat e tij. Prandaj, në pjesën e përshkrimit të përgjithshëm të rastit të testimit (në sistemet e gjurmimit të testit, zakonisht përdoret termi "Përmbledhje"), është e nevojshme t'i referohemi një kërkese specifike në lidhje me fragmente të tekstit të kërkesave. Kështu, për të gjithë pjesëmarrësit e projektit do të jetë e qartë në bazë të asaj që është shkruar ky rast testimi.

• Përdorni parakushte të hollësishme

Si të kurseni kohë në rastet e testimit?

Vendosni rregullat e formatimit për të gjitha rastet e testimit. Pra, rasti i testit do të jetë i lehtë për t'u kuptuar dhe lexuar për çdo pjesëmarrës të projektit. Për shembull, në një projekt, mund të vendosni rregullat e mëposhtme:

• Të gjithë parametrat e hyrjes duhet të shënohen me të kuqe.
• Të gjitha skriptet duhet të theksohen me blu,
• Të gjithë emrat e butonave, fushave, blloqeve janë me shkronja të pjerrëta dhe të theksuara.
• Janë nënvizuar pasazhe të rëndësishme.
• Çdo hap i kryer duhet të ketë një rezultat të pritshëm.
• Çdo hap në rastet e testimit duhet të përshkruajë vetëm një veprim dhe rezultatin e pritur për të. Ato. kur merrni një rast testimi të dështuar në një hap të caktuar, duhet të jetë pa mëdyshje e qartë se në cilin veprim ndodh gabimi.
• Rezultati i pritur duhet të jetë i paqartë.

Rastet e testimit duhet të jenë të paqarta, d.m.th. duhet të hartohen dhe formulohen në mënyrë të tillë që të mos lejojnë interpretim të paqartë, por të kuptohen qartë nga të gjithë pjesëmarrësit.

Nëse shkrimi i rasteve të testimit kërkon një kohë të gjatë, atëherë mund të lindë një situatë kur një specialist ndalon të shohë gabimet e tij. Për ta bërë këtë, ju duhet një vështrim nga ana - këtu do t'ju ndihmojë rishikim i kryqëzuar. Kjo fazë rekomandohet të kryhet në rastet kur zhvillimi i një modeli testimi zgjatet në kohë dhe është i gjatë në kohë. Për shembull, kur zhvillimi i skenarëve të testimit zgjat më shumë se 1 muaj.

Procesi i kontrollit të cilësisë së skenarit mund të kryhet me Kontrollin e Modelit Test- shabllon i përgatitur posaçërisht.

Përditësimi i modelit të testimit

Është e nevojshme të përditësohet rregullisht modeli i testimit dhe vetë rastet e testimit për përputhjen me kërkesat, si dhe të rishikohen prioritetet e rasteve të testimit.

Për përditësimin ju mund të mbani një "Matricë të kërkesave"(Matrica e gjurmueshmërisë së kërkesave): pas çdo ndryshimi në një kërkesë të caktuar, bëhet një përzgjedhje e të gjithë skenarëve të testimit që lidhen me këtë kërkesë nga sistemi i gjurmimit të testimit dhe përditësohet.

Kontrollet e modelit të testimit:

• hekurudhor provë
• lidhje testimi
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• shkëlqejnë

Testimi është një proces që ju lejon të vlerësoni cilësinë e produktit që prodhohet. Një produkt softuerësh me cilësi të lartë duhet të plotësojë kërkesat për të, si funksionale ashtu edhe jofunksionale. PS duhet të zbatojë të gjitha VI-të e kërkuara dhe të mos ketë defekte - dallime midis vetive të jetës reale ose sjelljes nga ato të kërkuara. Përveç kësaj, PS duhet të ketë vetitë e besueshmërisë (nuk duhet të ketë hangupe, përplasje, etj.), Sigurinë, të sigurojë performancën e dëshiruar, të jetë e lehtë për t'u përdorur, e zgjerueshme, etj. Kështu, testimi është një proces i analizimit të PS , me qëllim identifikimin e defekteve dhe vlerësimin e vetive të PS.

Qëllimet e procesit të testimit

Qëllimi i testimit është vlerësimi i cilësisë produkt software përmes

• Kontrollet e ndërveprimit të komponentëve;
• Kontrollimi i integrimit të saktë të komponentëve;
• Kontrollimi i saktësisë së zbatimit të të gjitha kërkesave dhe identifikimi i defekteve.

Karakteristikat e procesit të testimit në RUP

Testimi është një proces i përsëritur i kryer në të gjitha fazat e ciklit jetësor. Testimi fillon nga fillimi faza fillestare identifikimi i kërkesave për një produkt të ardhshëm dhe integrimi i ngushtë me detyrat aktuale. Për çdo përsëritje, përcaktohen qëllimi i testimit dhe metodat për arritjen e tij. Në fund të çdo përsëritjeje, përcaktohet se deri në çfarë mase është arritur ky qëllim, nëse nevojiten teste shtesë, nëse duhet të ndryshohen parimet dhe mjetet e testimit.

Çdo defekt i gjetur regjistrohet në bazën e të dhënave të projektit me një përshkrim të situatës në të cilën është gjetur. Analisti përcakton nëse ky është një defekt i vërtetë dhe nëse është një përsëritje e një defekti të zbuluar më parë. Defekti i gjetur është caktuar një prioritet A që tregon rëndësinë e rregullimit. Projektuesi përgjegjës për zhvillimin e nënsistemit, komponentit ose klasës, ose një person tjetër i caktuar nga menaxheri, vazhdon të rregullojë defektin. Rendi në të cilin fiksohen defektet rregullohet nga prioritetet e tyre. Testuesi përsërit testet dhe është i bindur (ose jo i bindur) se defekti është rregulluar.

Zhvilluesi i testit përgjegjës për planifikimin, zhvillimin dhe zbatimin e testeve. Ai krijon një plan dhe model testimi, procedurat e testimit (shih më poshtë) dhe vlerëson rezultatet e testit.

testues (testues) përgjegjës për kryerjen e testimit të sistemit. Përgjegjësitë e tij përfshijnë vendosjen dhe ekzekutimin e testeve, vlerësimin e performancës së testit, rikuperimin nga gabimet dhe regjistrimin e defekteve të zbuluara.

Artefakte

Gjatë testimit, krijohen dokumentet e mëposhtme:

Plani i testimit– një dokument që përcakton strategjinë e testimit në çdo përsëritje. Ai përmban një përshkrim të qëllimeve dhe objektivave të testimit në përsëritjen aktuale, si dhe strategjitë që do të përdoren. Plani tregon se cilat burime do të kërkohen dhe ofron një listë të testeve.

Modeli i testimitështë një paraqitje e asaj që dhe si do të testohet. Modeli përfshin një sërë detyrash kontrolli, metoda testimi, skenarë testimi dhe rezultatet e pritshme (rastet e testimit), skriptet e testimit dhe përshkrimet e ndërveprimeve të testit.

• Detyrë kontrolli– një grup të dhënash testimi, kushtet e ekzekutimit të testit dhe rezultatet e pritura.
• Metoda e testimit– një dokument që përmban udhëzime për vendosjen dhe kryerjen e detyrave të kontrollit, si dhe për vlerësimin e rezultateve të marra.
• Skenari i testit- ky është një përshkrim i thjeshtuar i testit, duke përfshirë të dhënat fillestare, kushtet dhe sekuencat e veprimeve dhe rezultatet e pritura.
• Skenari i testitështë një program që ekzekutohet gjatë testimit të automatizuar duke përdorur mjete testimi.
• Përshkrimi i ndërveprimit të testitështë një diagram sekuencash ose bashkëpunimesh që pasqyron rrjedhën e mesazheve të renditura në kohë midis komponentëve të testimit dhe objektit të testimit.

Rezultatet e testit dhe të dhënat e marra gjatë kryerjes së testeve.

Modeli i ngarkesës së punës përdoret për të modeluar funksionet e jashtme të kryera nga përdoruesit fundorë, shtrirjen e këtyre funksioneve dhe ngarkesën e punës të krijuar nga ato funksione. Modeli është menduar për kryerjen e testimit të ngarkesës dhe/ose stresit që simulon funksionimin e sistemit në kushte reale.

Defektet- këto janë përshkrime të fakteve të mospërputhjes së sistemit me kërkesat e konstatuara gjatë testimit. Ato janë një lloj i kërkesave për ndryshim.

Punimet testuese kryhen në çdo përsëritje në të gjitha fazat, por qëllimet dhe objektivat në faza të ndryshme të projektit janë dukshëm të ndryshme.

Faza e hyrjes në projekt. Në këtë fazë bëhet përgatitja për testim. Ai përfshin:

• Krijoni një plan testimi që përmban kërkesat dhe strategjitë e testimit. Një plan i vetëm mund të krijohet për të gjitha llojet e testimeve (funksionale, me ngarkesë, etj.) ose plane të veçanta për secilin lloj.
• Analiza e fushës së testimit.
• Formulimi i kritereve të cilësisë dhe përfundimi i testimit.
• Instalimi dhe përgatitja për funksionimin e mjeteve të testimit.
• Formulimi i kërkesave për projektin e zhvillimit të PS, të përcaktuara nga nevojat e testimit.

Faza e zhvillimit. Në përsëritjet e kësaj faze, fillon ndërtimi i modelit të provës dhe objekteve përkatëse. Meqenëse modeli VI është tashmë i pranishëm në këtë fazë, mund të filloni të hartoni skenarë testimi. Në të njëjtën kohë, nuk këshillohet të kryhen teste, pasi zakonisht nuk ka ende fragmente PS të përfunduara në këtë fazë. Aktivitetet e mëposhtme kryhen:

• Zhvillimi i skenarëve të testimit.
• Krijimi i skripteve testuese.
• Zhvillimi i detyrave të kontrollit.
• Zhvillimi i metodave të testimit.
• Zhvillimi i një modeli të ngarkesës së punës.

Faza e ndërtimit. Në këtë fazë shfaqen fragmente të kompletuara të sistemit dhe prototipe, të cilat duhet të testohen. Në të njëjtën kohë, pothuajse në çdo përsëritje, të gjitha modulet kontrollohen (të dyja të zhvilluara dhe të testuara më parë, dhe të reja të shtuara në përsëritjen aktuale). Testet e aplikuara në përsëritjet e mëparshme përdoren gjithashtu në përsëritjet pasuese për testimin e regresionit, domethënë, për të kontrolluar që funksionaliteti i sistemit të implementuar më parë të ruhet në përsëritjen e re. Aktivitetet e mëposhtme kryhen:

• Krijoni një plan testimi për çdo përsëritje.
• Përsosja dhe shtimi i modelit të testimit.
• Ekzekutimi i testeve.
• Përshkrimi i defekteve të gjetura.
• Përshkrimi i rezultateve të testit.
• Vlerësimi i rezultateve të testit.

Bazuar në rezultatet e testimit, bëhen ndryshime në kodin e programit për të eliminuar defektet e identifikuara, pas së cilës testimi përsëritet.

Faza e vendosjes. Në përsëritjet e kësaj faze, kryhet testimi i të gjithë PS si produkt softuer. Aktivitetet e kryera janë të ngjashme me aktivitetet e fazës së mëparshme. Zbulimi i defektit përcakton nevojën për ndryshime dhe ritestim. Procesi përsëritës përsëritet derisa të plotësohen kriteret e përfundimit të testit.

Rezultatet e testit vlerësohen në bazë të matjeve të testimit që lejojnë përcaktimin e cilësisë së PS-së së testuar dhe vetë procesit të testimit.

Mbështetje instrumentale

Meqenëse procesi i testimit përsëritës përfshin përsëritje të shumta të testeve, testimi manual bëhet joefikas dhe nuk lejon një vlerësim të plotë të cilësisë së produktit softuer. Kjo është veçanërisht e vërtetë për testimin e ngarkesës dhe stresit, ku duhet të simuloni ngarkesën e punës dhe të grumbulloni një sasi të konsiderueshme të dhënash. Zgjidhja është përdorimi i mjeteve që mbështesin automatizimin e përpilimit dhe ekzekutimit të testeve.

Ashtu si procesi i zhvillimit, procesi i post-testimit të softuerit gjithashtu ndjek një metodologji specifike. Me metodologji, në këtë rast, nënkuptojmë kombinimet e ndryshme të parimeve, ideve, metodave dhe koncepteve të cilave u drejtoheni gjatë punës në një projekt.

Aktualisht ka një numër mjaft të madh qasjesh të ndryshme për testimin, secila me pikat e veta fillestare, kohëzgjatjen e ekzekutimit dhe metodat e përdorura në secilën fazë. Dhe zgjedhja e njërës ose tjetrës mund të jetë mjaft sfidë. Në këtë artikull, ne do të shikojmë qasje të ndryshme për testimin e softuerit dhe do të flasim për veçoritë e tyre kryesore për t'ju ndihmuar të lundroni në varietetin ekzistues.

Modeli i ujëvarës (Modeli linear sekuencial i ciklit jetësor të softuerit)

Modeli Waterfall është një nga modelet më të vjetra që mund të përdoret jo vetëm për zhvillimin ose testimin e softuerit, por edhe për pothuajse çdo projekt tjetër. E tij parimi bazëështë rendi vijues në të cilin kryhen detyrat. Kjo do të thotë që ne mund të vazhdojmë në hapin tjetër të zhvillimit ose testimit vetëm pasi ai i mëparshmi të ketë përfunduar me sukses. Ky model është i përshtatshëm për projekte të vogla dhe është i zbatueshëm vetëm nëse të gjitha kërkesat janë të përcaktuara qartë. Përparësitë kryesore të kësaj metodologjie janë efikasiteti ekonomik, lehtësinë e përdorimit dhe menaxhimin e dokumentacionit.

Procesi i testimit të softuerit fillon pas përfundimit të procesit të zhvillimit. Në këtë fazë, të gjitha testet e nevojshme transferohen nga njësitë në testimin e sistemit për të kontrolluar funksionimin e komponentëve si individualisht ashtu edhe në tërësi.

Përveç avantazheve të përmendura më lart, kjo qasje ndaj testimit ka edhe të metat e saj. Gjithmonë ekziston mundësia e gjetjes së gabimeve kritike në procesin e testimit. Kjo mund të çojë në nevojën për të ndryshuar plotësisht një nga komponentët e sistemit apo edhe të gjithë logjikën e projektit. Por një detyrë e tillë është e pamundur në rastin e modelit të ujëvarës, pasi kthimi në hapin e mëparshëm në këtë metodologji është i ndaluar.

Mësoni më shumë rreth modelit të ujëvarës nga artikulli i mëparshëm..

V-Model (Modeli i verifikimit dhe vërtetimit)

Ashtu si Modeli Waterfall, V-Model bazohet në një sekuencë të drejtpërdrejtë hapash. Dallimi kryesor midis këtyre dy metodologjive është se testimi në këtë rast planifikohet paralelisht me fazën përkatëse të zhvillimit. Sipas kësaj metodologjie të testimit të softuerit, procesi fillon sapo të përcaktohen kërkesat dhe bëhet i mundur fillimi i testimit statik, d.m.th. verifikimi dhe rishikimi, i cili shmang defektet e mundshme të softuerit në fazat e mëvonshme. Një plan i përshtatshëm testimi krijohet për çdo nivel të zhvillimit të softuerit që përcakton rezultatet e pritura dhe kriteret e hyrjes dhe daljes për atë produkt.

Skema e këtij modeli tregon parimin e ndarjes së detyrave në dy pjesë. Ato që lidhen me dizajnin dhe zhvillimin vendosen në të majtë. Detyrat që lidhen me testimin e softuerit ndodhen në të djathtë:

Hapat kryesorë të kësaj metodologjie mund të ndryshojnë, por zakonisht përfshijnë sa vijon:

• Fazë përcaktimet e kërkesave. Testimi i pranimit i përket kësaj faze. Detyra e tij kryesore është të vlerësojë gatishmërinë e sistemit për përdorim përfundimtar.
• Faza në të cilën dizajn i nivelit të lartë, ose dizajn i nivelit të lartë (HDL). Kjo fazë i referohet testimit të sistemit dhe përfshin një vlerësim të përputhshmërisë me kërkesat për sistemet e integruara.
• Faza e detajuar e projektimit(Dizajni i Detajuar) është paralel me fazën e testimit të integrimit, gjatë së cilës testohen ndërveprimet ndërmjet komponentëve të ndryshëm të sistemit
• Pas faza e kodimit Fillon një hap tjetër i rëndësishëm - testimi i njësisë. Është shumë e rëndësishme të siguroheni që sjellja e pjesëve dhe përbërësve individualë të softuerit është e saktë dhe plotëson kërkesat.

E vetmja pengesë e metodologjisë së konsideruar të testimit është mungesa e zgjidhjeve të gatshme që mund të aplikohen për të hequr qafe defektet e softuerit të gjetur gjatë fazës së testimit.

modeli në rritje

Kjo metodologji mund të përshkruhet si një model testimi i softuerit me shumë kaskadë. Rrjedha e punës ndahet në një numër ciklesh, secila prej të cilave ndahet gjithashtu në module. Çdo përsëritje shton funksionalitete të caktuara në softuer. Rritja përbëhet nga tre cikle:

1. projektimit dhe zhvillimit
2. duke testuar
3. zbatimi.

Në këtë model, zhvillimi i njëkohshëm i versioneve të ndryshme të produktit është i mundur. Për shembull, versioni i parë mund të jetë në fazën e testimit ndërsa versioni i dytë është në zhvillim. Versioni i tretë mund të kalojë në të njëjtën kohë fazën e projektimit. Ky proces mund të vazhdojë deri në fund të projektit.

Natyrisht, kjo metodologji kërkon zbulimin sa më të shpejtë të numrit maksimal të mundshëm të gabimeve në softuerin nën testim. Si dhe faza e zbatimit, e cila kërkon konfirmimin e gatishmërisë së produktit për t'i dorëzuar përdoruesit përfundimtar. Të gjithë këta faktorë rrisin ndjeshëm peshën e kërkesave të testimit.

Krahasuar me metodologjitë e mëparshme, modeli inkremental ka disa avantazhe të rëndësishme. Është më fleksibël, ndryshimet në kërkesat çojnë në kosto më të ulëta dhe procesi i testimit të softuerit është më efikas, pasi testimi dhe korrigjimi është shumë më i lehtë përmes përdorimit të përsëritjeve të vogla. Megjithatë, vlen të theksohet se kosto totale ende më i lartë se në rastin e modelit kaskadë.

model spirale

Modeli Spiral është një metodologji e testimit të softuerit që bazohet në një qasje në rritje dhe prototip. Ai përbëhet nga katër faza:

1. Planifikimi
2. Analiza e Riskut
3. Zhvillimi
4. Gradë

Menjëherë pas përfundimit të ciklit të parë, fillon i dyti. Testimi i softuerit fillon në fazën e planifikimit dhe vazhdon deri në fazën e vlerësimit. Avantazhi kryesor i modelit spirale është se rezultatet e testit të parë shfaqen menjëherë pas rezultateve të testeve në fazën e tretë të çdo cikli, gjë që ndihmon për të siguruar vlerësimin e saktë të cilësisë. Megjithatë, është e rëndësishme të kihet parasysh se ky model mund të jetë mjaft i shtrenjtë dhe jo i përshtatshëm për projekte të vogla.

Edhe pse ky model është mjaft i vjetër, ai mbetet i dobishëm si për testim ashtu edhe për zhvillim. Për më tepër, objektivi kryesor shumë metodologji të testimit të softuerit, duke përfshirë modelin spirale, kanë ndryshuar kohët e fundit. Ne i përdorim ato jo vetëm për të gjetur defekte në aplikacione, por edhe për të zbuluar arsyet që i kanë shkaktuar ato. Kjo qasje i ndihmon zhvilluesit të punojnë në mënyrë më efikase dhe të rregullojnë gabimet shpejt.

Lexoni më shumë rreth modelit spirale në postimin e mëparshëm në blog..

I shkathët

Metodologjia e zhvillimit të softuerit të shkathët dhe testimi i softuerit mund të përshkruhen si një grup qasjesh të përqendruara në përdorimin e zhvillimit interaktiv, formimin dinamik të kërkesave dhe sigurimin e zbatimit të tyre si rezultat i ndërveprimit të vazhdueshëm brenda një organizate vetë-organizuese. grupi i punës. Shumica e metodologjive të shkathëta të zhvillimit të softuerit synojnë të minimizojnë rrezikun përmes zhvillimit në përsëritje të shkurtra. Një nga parimet kryesore të kësaj strategjie fleksibël është aftësia për t'iu përgjigjur shpejt ndryshimeve të mundshme, në vend që të mbështetet në planifikimin afatgjatë.

Mësoni më shumë për Agile(shënim - artikull në anglisht).

Programim ekstrem (XP, Programim ekstrem)

Programimi ekstrem është një shembull i zhvillimit të softuerit të shkathët. Një tipar dallues i kësaj metodologjie është "programimi në çift", një situatë ku një zhvillues punon me kodin, ndërsa kolegu i tij vazhdimisht shqyrton kodin e shkruar. Procesi i testimit të softuerit është mjaft i rëndësishëm sepse fillon edhe përpara se të shkruhet rreshti i parë i kodit. Çdo modul aplikimi duhet të ketë një test njësi në mënyrë që shumica e gabimeve të mund të rregullohen në fazën e kodimit. Një veçori tjetër dalluese është se testi përcakton kodin, dhe jo anasjelltas. Kjo do të thotë që një pjesë e caktuar e kodit mund të konsiderohet e plotë vetëm nëse kalojnë të gjitha testet. Përndryshe, kodi refuzohet.

Përparësitë kryesore të kësaj metodologjie janë testimi i vazhdueshëm dhe lëshimet e shkurtra, gjë që ndihmon për të siguruar cilesi e larte kodi.

Scrum

Scrum - Pjesë e metodologjisë Agile, një kornizë përsëritëse në rritje e krijuar për të menaxhuar procesin e zhvillimit të softuerit. Sipas parimeve Scrum, ekipi i testimit duhet të përfshihet në hapat e mëposhtëm:

• Pjesëmarrja në planifikimin e Scrum
• Mbështetje për testimin e njësisë
• Testimi i historisë së përdoruesit
• Bashkëpunoni me klientin dhe pronarin e produktit për të përcaktuar kriteret e pranimit
• Sigurimi i testimit të automatizuar

Për më tepër, anëtarët e SC duhet të jenë të pranishëm në të gjitha takimet ditore, si anëtarët e tjerë të ekipit, për të diskutuar se çfarë është testuar dhe bërë dje, çfarë do të testohet sot, si dhe ecuria e përgjithshme e testimit.

Në të njëjtën kohë, parimet e metodologjisë Agile në Scrum çojnë në shfaqjen e veçorive specifike:

• Vlerësimi i përpjekjes së kërkuar për çdo histori përdoruesi është një domosdoshmëri
• Testuesi duhet të jetë i vëmendshëm ndaj kërkesave pasi ato mund të ndryshojnë gjatë gjithë kohës.
• Rreziku i regresionit rritet me ndryshime të shpeshta të kodit.
• Planifikimi dhe ekzekutimi i njëkohshëm i testeve
• Keqkuptimi midis anëtarëve të ekipit në rast se kërkesat e klientit nuk janë plotësisht të qarta

Mësoni më shumë rreth metodologjisë Scrum nga një artikull i mëparshëm..

konkluzioni

Si përfundim, është e rëndësishme të theksohet se sot praktika e përdorimit të një metodologjie të testimit të softuerit nënkupton një qasje multiversale. Me fjalë të tjera, nuk duhet të prisni që ndonjë metodologji të jetë e përshtatshme për të gjitha llojet e projekteve. Zgjedhja e njërit prej tyre varet nga një numër i madh aspektesh, si lloji i projektit, kërkesat e klientëve, afatet dhe shumë të tjera. Nga pikëpamja e testimit të softuerit, është e zakonshme që disa metodologji të fillojnë testimin herët në zhvillim, ndërsa për të tjerat është e zakonshme të presin derisa sistemi të përfundojë.

Pavarësisht nëse keni nevojë për ndihmë me zhvillimin ose testimin e softuerit, një ekip i përkushtuar zhvilluesish dhe inxhinierësh të QA është gati të fillojë.

Testimi i shërbimit në ueb

Shumica Menyra me e mire vlerësoni nëse e kemi testuar mirë produktin - analizoni defektet e humbura. Ato me të cilat përballen përdoruesit, zbatuesit, bizneset tona. Mund të vlerësoni shumë prej tyre: çfarë nuk kemi kontrolluar plotësisht, cilat fusha të produktit duhet t'i kushtohet më shumë vëmendje, sa është përqindja e lëshimeve në përgjithësi dhe cila është dinamika e ndryshimeve të tij. Me këtë metrikë (ndoshta më e zakonshmja në testim), gjithçka është në rregull, por ... Kur lëshuam produktin dhe zbuluam për gabimet e humbura, mund të jetë tepër vonë: një artikull i zemëruar për ne u shfaq në Habré, konkurrentët janë duke përhapur me shpejtësi kritikat, klientët kanë humbur besimin tek ne, menaxhimi është i pakënaqur.

Për të parandaluar që kjo të ndodhë, ne zakonisht përpiqemi të vlerësojmë cilësinë e testimit paraprakisht, përpara lëshimit: sa mirë dhe tërësisht e kontrollojmë produktin? Cilat fusha u mungon vëmendja, ku janë rreziqet kryesore, çfarë progresi? Dhe për t'iu përgjigjur të gjitha këtyre pyetjeve, ne vlerësojmë mbulimin e testit.

Pse të vlerësoni?

Çdo metrikë e vlerësimit është humbje kohe. Në këtë kohë, ju mund të provoni, të filloni gabimet, të përgatitni autoteste. Çfarë përfitimi magjik marrim nga matjet e mbulimit të testit për të sakrifikuar kohën e testimit?

1. Gjetja e zonave tuaja të dobëta. Natyrisht, na duhet kjo? jo vetëm për të pikëlluar, por për të ditur se ku nevojiten përmirësime. Cilat fusha funksionale nuk mbulohen nga testet? Çfarë nuk kemi kontrolluar? Ku janë rreziqet më të mëdha të gabimeve të humbura?
2. Rrallëherë marrim mbulim 100% nga rezultatet e vlerësimit. Çfarë duhet përmirësuar? Ku të shkojnë? Sa është përqindja tani? Si mund ta rrisim atë me çdo detyrë? Sa shpejt mund të arrijmë në 100? Të gjitha këto pyetje sjellin transparencë dhe qartësi në procesin tonë., dhe përgjigjet për to jepen nga vlerësimi i mbulimit.
3. Fokusi i vëmendjes. Le të themi se produkti ynë ka rreth 50 zona të ndryshme funksionale. duke dalë një version të ri, dhe ne fillojmë të testojmë të parin prej tyre, dhe gjejmë atje gabime shtypi, dhe butona që kanë lëvizur nja dy piksel, dhe gjëra të tjera të vogla ... Dhe tani koha e testimit ka mbaruar, dhe ky funksionalitet është testuar në detaje.. Dhe 50 të mbetura? Vlerësimi i mbulimit na lejon të prioritizojmë detyrat bazuar në realitetet dhe afatet aktuale.

Si të vlerësohet?

Para se të zbatoni ndonjë metrikë, është e rëndësishme të vendosni se si do ta përdorni atë. Filloni duke iu përgjigjur saktësisht kësaj pyetjeje - ka shumë të ngjarë, menjëherë do të kuptoni se si është më mirë ta llogaritni atë. Dhe unë do të ndaj në këtë artikull vetëm disa shembuj dhe përvojën time se si mund të bëhet kjo. Jo për të kopjuar verbërisht zgjidhje - por në mënyrë që imagjinata juaj të mbështetet në këtë përvojë, duke menduar për një zgjidhje që është ideale për ju.

Vlerësimi i mbulimit të kërkesave nga testet

Le të themi se keni analistë në ekipin tuaj dhe ata nuk e kalojnë kohën e tyre kot. Koha e punes. Bazuar në rezultatet e punës së tyre, u krijuan kërkesa në RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (me shtojca shtesë), etj. Në këtë sistem, ata bëjnë kërkesa që korrespondojnë me kërkesat për kërkesat (më falni për tautologjinë). Këto kërkesa janë atomike, të gjurmueshme, specifike… Në përgjithësi, kushte ideale për testim. Çfarë mund të bëjmë në një rast të tillë? Kur përdorni një qasje të skriptuar, lidheni kërkesat dhe testet. Ne kryejmë teste në të njëjtin sistem, bëjmë një lidhje test-kërkese dhe në çdo kohë mund të shohim një raport se cilat kërkesa kanë teste, cilat jo, kur janë kaluar këto teste dhe me çfarë rezultati.
Ne marrim një hartë mbulimi, mbulojmë të gjitha kërkesat e pambuluara, të gjithë janë të lumtur dhe të kënaqur, nuk na mungojnë gabimet ...

Mirë, le të kthehemi në tokë. Me shumë mundësi, nuk keni kërkesa të detajuara, ato nuk janë atomike, disa nga kërkesat në përgjithësi humbasin dhe nuk ka kohë për të dokumentuar çdo test, ose të paktën çdo të dytën. Ju mund të dëshpëroheni dhe të qani, ose mund të pranoni se testimi është një proces kompensues dhe sa më keq të jemi me analitikën dhe zhvillimin e projektit, aq më shumë ne vetë duhet të përpiqemi dhe të kompensojmë problemet e pjesëmarrësve të tjerë në proces. Le t'i analizojmë problemet veç e veç.

Problemi: Kërkesat nuk janë atomike.

Analistët gjithashtu ndonjëherë mëkatojnë me një sallatë në kokë, dhe zakonisht kjo është e mbushur me probleme me të gjithë projektin. Për shembull, ju jeni duke zhvilluar një redaktues teksti dhe mund të keni dy kërkesa në sistemin tuaj (ndër të tjera): "Duhet të mbështetet formatimi html" dhe "kur hapni një skedar të një formati të pambështetur, një dritare kërcyese me një pyetje duhet të shfaqet.” Sa teste kërkohen për verifikimin bazë të kërkesës së parë? Dhe për të 2-tën? Dallimi në përgjigje, ka shumë të ngjarë, është rreth njëqind herë!!! Nuk mund të themi që nëse ka të paktën 1 test në kërkesën e parë, kjo është e mjaftueshme - por për të 2-tin, ka shumë të ngjarë, plotësisht.

Kështu, të kesh një test kërkues nuk na garanton asgjë! Çfarë do të thotë statistikat tona të mbulimit në këtë rast? Pothuajse asgjë! Ne do të duhet të vendosim!

1. Në këtë rast, llogaritja automatike e mbulimit të kërkesave nga testet mund të hiqet - ende nuk ka një ngarkesë semantike.
2. Për çdo kërkesë, duke filluar me prioritetin më të lartë, ne përgatisim teste. Gjatë përgatitjes, ne analizojmë se cilat teste do të kërkohen për këtë kërkesë, sa do të jenë të mjaftueshme? Ne kryejmë një analizë të plotë të testit dhe mos e lëmë mënjanë "ka një provë, por në rregull".
3. Në varësi të sistemit të përdorur, ne eksportojmë/ngarkojmë teste sipas kërkesës dhe… i testojmë këto teste! A mjaftojnë ato? Në mënyrë ideale, natyrisht, një testim i tillë duhet të kryhet me një analist dhe një zhvillues të këtij funksioni. Printoni testet, mbyllni kolegët tuaj në sallën e mbledhjeve dhe mos i lini të shkojnë derisa të thonë “po, mjaftojnë këto teste” (kjo ndodh vetëm me marrëveshje me shkrim, kur këto fjalë thuhen për çregjistrim, edhe pa i analizuar testet. Gjatë një diskutimi me gojë, kolegët tuaj do të hedhin një kritikë në vaskë, teste të humbura, kërkesa të keqkuptuara, etj. - kjo nuk është gjithmonë e këndshme, por është shumë e dobishme për testim!)
4. Pas finalizimit të testeve sipas kërkesës dhe dakordimit për plotësinë e tyre, në sistem kjo kërkesë mund të shënohet me statusin “mbulohet nga testet”. Ky informacion do të thotë shumë më tepër sesa "ka të paktën 1 test këtu".

Sigurisht, një proces i tillë marrëveshjeje kërkon shumë burime dhe kohë, veçanërisht në fillim, derisa të zhvillohet praktika. Prandaj, kryeni vetëm kërkesa me prioritet të lartë dhe përmirësime të reja në të. Me kalimin e kohës, shtrëngoni pjesën tjetër të kërkesave dhe të gjithë do të jenë të lumtur! Por ... dhe nëse nuk ka kërkesa fare?

Problemi: Nuk ka fare kërkesa.

Mungojnë në projekt, diskutohen gojarisht, secili bën çfarë të dojë/mundet dhe si e kupton. Ne testojmë të njëjtën gjë. Si rezultat, marrim një numër të madh problemesh jo vetëm në testim dhe zhvillim, por edhe fillimisht zbatimin e gabuar të veçorive - ne donim diçka krejtësisht të ndryshme! Këtu mund të këshilloj opsionin "përcaktoni dhe dokumentoni vetë kërkesat", madje e përdora këtë strategji disa herë në praktikën time, por në 99% të rasteve nuk ka burime të tilla në ekipin e testimit - kështu që le të shkojmë shumë më pak mënyrë intensive me burime:

1. Krijo një listë funksionesh. Sami! Në formën e një google-tablet, në formatin PBI në TFS - zgjidhni cilindo, për sa kohë që nuk është një format teksti. Ende duhet të mbledhim statuse! Ne përfshijmë të gjitha zonat funksionale të produktit në këtë listë dhe përpiqemi të zgjedhim një nivel të përgjithshëm të dekompozimit (mund të shkruani objekte softuerësh, ose skriptet e përdoruesit, ose modulet, ose faqet e internetit, ose metodat API ose format e ekranit .. .) - por jo të gjitha këto menjëherë! NJË format zbërthimi që do ta bëjë më të lehtë dhe më të qartë për ju që të mos humbisni gjëra të rëndësishme.
2. Ne koordinojmë PLOTËSINËN e kësaj liste me analistë, zhvillues, biznes, brenda ekipit tonë... Mundohuni të bëni gjithçka që të mos humbni pjesë të rëndësishme të produktit! Se sa thellë për të analizuar varet nga ju. Në praktikën time, kishte vetëm disa produkte për të cilat krijuam më shumë se 100 faqe në tabelë, dhe këto ishin produkte gjigante. Më shpesh, 30-50 rreshta është një rezultat i arritshëm për përpunim të mëtejshëm të kujdesshëm. Në një ekip të vogël pa analistë të dedikuar testimi më shumë Elementet fichelista do të ishin shumë të vështira për t'u ruajtur.
3. Pas kësaj, ne kalojmë nëpër prioritetet dhe përpunojmë secilën rresht të fichelistit si në seksionin e kërkesave të përshkruara më sipër. Ne shkruajmë teste, diskutojmë, biem dakord për mjaftueshmërinë. Shënojmë statuset, për të cilat veçori ka mjaft teste. Ne marrim statusin, përparimin dhe zgjerimin e testeve përmes komunikimit me ekipin. Të gjithë janë të lumtur!

Por... Po nëse kërkesat mbahen, por jo në një format të gjurmueshëm?

Problemi: Kërkesat nuk janë të gjurmueshme.

Ekziston një sasi e madhe dokumentacioni për projektin, analistët shkruajnë me një shpejtësi prej 400 karaktere në minutë, ju keni specifikime, specifikime teknike, udhëzime, referenca (më shpesh kjo ndodh me kërkesën e klientit) dhe e gjithë kjo vepron si kërkesat, dhe çdo gjë ka qenë në projekt për një kohë të gjatë Jeni të hutuar ku të kërkoni çfarë informacioni?
Përsëritja e seksionit të mëparshëm, duke ndihmuar të gjithë ekipin të pastrohet!

1. Ne krijojmë një listë të veçorive (shih më lart), por pa një përshkrim të detajuar të kërkesave.
2. Për çdo veçori, ne mbledhim së bashku lidhje me specifikimet teknike, specifikimet, udhëzimet dhe dokumentet e tjera.
3. Ne kalojmë sipas prioriteteve, përgatisim teste dhe biem dakord për plotësinë e tyre. Gjithçka është e njëjtë, vetëm falë kombinimit të të gjitha dokumenteve në një pjatë ne rrisim lehtësinë e aksesit në to, statuset transparente dhe konsistencën e testeve. Në fund të fundit, gjithçka është super, dhe të gjithë janë të lumtur!

Por… Jo për shumë kohë… Duket se javën e fundit, analistët kanë përditësuar 4 specifika të ndryshme bazuar në kërkesat e klientëve!!!

Problemi: Kërkesat ndryshojnë gjatë gjithë kohës.

Sigurisht, do të ishte mirë të testonim një sistem fiks, por produktet tona zakonisht janë live. Klienti kërkoi diçka, diçka ndryshoi në legjislacionin e jashtëm për produktin tonë, dhe diku analistët gjetën një gabim analize të një viti më parë... Kërkesat jetojnë jetën e tyre! Çfarë duhet bërë?

1. Le të themi se keni mbledhur tashmë lidhje me TK dhe specifikimet në formën e një liste funksionesh, PBI, kërkesa, shënime Wiki, etj. Le të themi se tashmë keni teste për këto kërkesa. Dhe tani, kërkesa po ndryshon! Kjo mund të nënkuptojë një ndryshim në RMS, ose një detyrë në TMS (Task Management System), ose një letër në postë. Sido që të jetë, ajo çon në të njëjtin rezultat: testet tuaja janë të vjetruara! Ose mund të jenë të parëndësishme. Kjo do të thotë se ata kërkojnë përditësim (mbulim me teste version i vjeter produkti disi nuk konsiderohet shumë, apo jo?)
2. Në listën e veçorive, në RMS, në TMS (Test Management System - testet, sitechco, etj) testet duhet të shënohen si të parëndësishme menjëherë dhe pa dështuar! Në HP QC ose MS TFS, kjo mund të bëhet automatikisht kur përditësohen kërkesat, dhe në një google-tablet ose wiki, do t'ju duhet të vendosni stilolapsa. Por duhet ta shihni menjëherë: testet janë të parëndësishme! Kjo do të thotë që ne jemi duke pritur për një ri-shtesë të plotë: përditësoni, rinisni analizën e testit, rishkruani testet, bini dakord për ndryshimet dhe vetëm pas kësaj shënoni përsëri veçorinë/kërkesën si "të mbuluar nga testet".

Në këtë rast, ne marrim të gjitha përfitimet e vlerësimit të mbulimit të testit, madje edhe në dinamikë! Të gjithë janë të lumtur!!! Por…
Por ju jeni fokusuar aq shumë në punën me kërkesat, saqë tani nuk keni kohë të mjaftueshme as për të testuar apo dokumentuar testet. Për mendimin tim (dhe ka vend për një mosmarrëveshje fetare!) kërkesat janë më të rëndësishme se testet dhe është më mirë kështu! Të paktën ata janë në rregull, dhe i gjithë ekipi është në dijeni, dhe zhvilluesit po bëjnë pikërisht atë që nevojitet. POR NUK KA KOHE PËR DOKUMENTIM TË TESTEVE!

Problemi: Nuk ka kohë të mjaftueshme për të dokumentuar testet.

Në fakt, burimi i këtij problemi mund të jetë jo vetëm mungesa e kohës, por edhe zgjedhja juaj mjaft e vetëdijshme për të mos i dokumentuar ato (nuk na pëlqen, shmangim efektin e pesticidit, produkti ndryshon shumë shpesh, etj.). Por si të vlerësohet mbulimi i testit në këtë rast?

1. Ju ende keni nevojë për kërkesa si kërkesa të plota ose si një listë karakteristikash, kështu që një nga seksionet e mësipërme, në varësi të punës së analistëve në projekt, do të jetë ende i nevojshëm. Keni një kërkesë/listë karakteristikash?
2. Ne përshkruajmë dhe biem dakord verbalisht për një strategji të shkurtër testimi, pa dokumentuar teste specifike! Kjo strategji mund të specifikohet në një kolonë tabele, në një faqe wiki ose në një kërkesë në RMS, dhe përsëri duhet të bihet dakord. Si pjesë e kësaj strategjie, rishikimet do të kryhen në mënyra të ndryshme, por ju do ta dini: kur të ndodhë Herën e fundit testuar dhe me çfarë strategjie? Dhe kjo, e shihni, gjithashtu nuk është e keqe! Dhe të gjithë do të jenë të lumtur.

Por… Çfarë tjetër "përveç"? cila???

Thuaj, ne do të shkojmë rreth gjithçkaje dhe mund të jenë me ne produkte me cilësi të lartë!

| Planifikimi i mësimit për vitin shkollor | Fazat kryesore të modelimit

Mësimi 2
Fazat kryesore të modelimit

Duke studiuar këtë temë, do të mësoni:

Çfarë është modelimi;
- çfarë mund të shërbejë si prototip për modelim;
- cili është vendi i modelimit në veprimtarinë njerëzore;
- cilat janë fazat kryesore të modelimit;
- çfarë është një model kompjuterik;
Çfarë është një eksperiment kompjuterik.

eksperiment kompjuterik

Për t'i dhënë jetë zhvillimeve të reja të dizajnit, për të futur zgjidhje të reja teknike në prodhim ose për të testuar ide të reja, nevojitet një eksperiment. Një eksperiment është një eksperiment që kryhet me një objekt ose model. Ai konsiston në kryerjen e disa veprimeve dhe përcaktimin se si mostra eksperimentale reagon ndaj këtyre veprimeve.

Në shkollë, ju kryeni eksperimente në mësimet e biologjisë, kimisë, fizikës, gjeografisë.

Eksperimentet kryhen gjatë testimit të mostrave të produkteve të reja në ndërmarrje. Zakonisht, për këtë qëllim përdoret një konfigurim i krijuar posaçërisht, i cili bën të mundur kryerjen e një eksperimenti në kushte laboratorike, ose vetë produkti i vërtetë i nënshtrohet të gjitha llojeve të provave (një eksperiment në shkallë të plotë). Për të studiuar, për shembull, vetitë e performancës së një njësie ose montimi, vendoset në një termostat, ngrihet në dhoma të veçanta, testohet në stendat e dridhjeve, bie, etj. Është mirë nëse është një orë e re ose një fshesë me korrent - humbja gjatë shkatërrimit nuk është e madhe. Po sikur të jetë një avion apo një raketë?

Eksperimentet laboratorike dhe në shkallë të plotë kërkojnë kosto dhe kohë të mëdha materiale, por rëndësia e tyre, megjithatë, është shumë e madhe.

Me zhvillimin teknologji kompjuterike u shfaq një metodë e re unike kërkimore - një eksperiment kompjuterik. Në shumë raste, studimet e simulimit kompjuterik kanë ardhur për të ndihmuar, dhe ndonjëherë edhe për të zëvendësuar, mostrat eksperimentale dhe stolat e testimit. Faza e kryerjes së një eksperimenti kompjuterik përfshin dy faza: hartimin e një plani eksperimenti dhe kryerjen e një studimi.

Plani i eksperimentit

Plani i eksperimentit duhet të pasqyrojë qartë sekuencën e punës me modelin. Hapi i parë në një plan të tillë është gjithmonë testimi i modelit.

Testimi është procesi i kontrollit të korrektësisë së modelit të ndërtuar.

Test - një grup të dhënash fillestare që ju lejon të përcaktoni korrektësinë e ndërtimit të modelit.

Për t'u siguruar në korrektësinë e rezultateve të marra të modelimit, është e nevojshme: ♦ të kontrollohet algoritmi i zhvilluar për ndërtimin e modelit; ♦ sigurohuni që modeli i ndërtuar të pasqyrojë saktë vetitë e origjinalit, të cilat janë marrë parasysh në simulim.

Për të kontrolluar korrektësinë e algoritmit të ndërtimit të modelit, përdoret një grup testimi i të dhënave fillestare, për të cilat rezultati përfundimtar është i njohur paraprakisht ose i paracaktuar në mënyra të tjera.

Për shembull, nëse përdorni formulat e llogaritjes në modelim, atëherë duhet të zgjidhni disa opsione për të dhënat fillestare dhe t'i llogaritni ato "me dorë". Këto janë artikuj provë. Kur modeli është ndërtuar, ju testoni me të njëjtat inpute dhe krahasoni rezultatet e simulimit me përfundimet e marra nga llogaritja. Nëse rezultatet përputhen, atëherë algoritmi zhvillohet saktë, nëse jo, është e nevojshme të kërkohet dhe eliminohet shkaku i mospërputhjes së tyre. Të dhënat e testit mund të mos pasqyrojnë fare situatën reale dhe mund të mos kenë përmbajtje semantike. Megjithatë, rezultatet e marra gjatë procesit të testimit mund t'ju shtyjnë të mendoni për ndryshimin e modelit origjinal të informacionit ose të shenjës, kryesisht në atë pjesë të tij ku është përcaktuar përmbajtja semantike.

Për t'u siguruar që modeli i ndërtuar pasqyron vetitë e origjinalit, të cilat janë marrë parasysh në simulim, është e nevojshme të zgjidhni një shembull testimi me të dhëna burimore reale.

Kryerja e hulumtimit

Pas testimit, kur të keni besim në korrektësinë e modelit të ndërtuar, mund të vazhdoni drejtpërdrejt në studim.

Plani duhet të përfshijë një eksperiment ose seri eksperimentesh që përmbushin objektivat e simulimit. Çdo eksperiment duhet të shoqërohet nga një kuptim i rezultateve, i cili shërben si bazë për analizimin e rezultateve të modelimit dhe marrjen e vendimeve.

Skema për përgatitjen dhe kryerjen e një eksperimenti kompjuterik është paraqitur në figurën 11.7.

Oriz. 11.7. Skema e një eksperimenti kompjuterik

Analiza e rezultateve të simulimit

Qëllimi përfundimtar i modelimit është marrja e një vendimi, i cili duhet të zhvillohet në bazë të një analize gjithëpërfshirëse të rezultateve të simulimit. Kjo fazë është vendimtare - ose vazhdoni studimin, ose përfundoni. Figura 11.2 tregon se faza e analizës së rezultateve nuk mund të ekzistojë në mënyrë autonome. Përfundimet e marra shpesh kontribuojnë në një seri eksperimentesh shtesë, dhe ndonjëherë në një ndryshim të problemit.

Rezultatet e testimit dhe eksperimenteve shërbejnë si bazë për zhvillimin e një zgjidhjeje. Nëse rezultatet nuk korrespondojnë me qëllimet e detyrës, do të thotë se janë bërë gabime në fazat e mëparshme. Kjo mund të jetë ose një deklaratë e gabuar e problemit, ose një ndërtim tepër i thjeshtuar i një modeli informacioni, ose një zgjedhje e pasuksesshme e një metode ose mjedisi modelimi, ose një shkelje e metodave teknologjike gjatë ndërtimit të një modeli. Nëse identifikohen gabime të tilla, atëherë modeli duhet të korrigjohet, domethënë një kthim në një nga fazat e mëparshme. Procesi përsëritet derisa rezultatet e eksperimentit të përmbushin objektivat e simulimit.

Gjëja kryesore për të mbajtur mend është se gabimi i zbuluar është gjithashtu rezultati. Siç thotë proverbi, ju mësoni nga gabimet tuaja. Poeti i madh rus A. S. Pushkin gjithashtu shkroi për këtë:

Oh, sa zbulime të mrekullueshme kemi
Përgatitni frymën e iluminizmit
Dhe përvoja, bir i gabimeve të vështira,
Dhe gjeni, paradoks mik,
Dhe rastësia, Zoti është shpikësi...

Kontrolloni pyetjet dhe detyrat

1. Cilat janë dy llojet kryesore të deklarimit të problemit të modelimit.

2. Në "Librin e Problemeve" të njohur të G. Oster-it, vërehet ky problem:

Shtriga e keqe, duke punuar pa u lodhur, kthen 30 princesha në vemje në ditë. Sa ditë do t'i duhen asaj për të kthyer 810 princesha në vemje? Sa princesha në ditë do të duhej të shndërroheshin në vemje për të përfunduar punën në 15 ditë?
Cila pyetje mund t'i atribuohet llojit të "çfarë do të ndodhë nëse ...", dhe cila - llojit "si të bëhet kështu që ..."?

3. Rendisni qëllimet më të njohura të modelingut.

4. Formalizoni problemin lozonjar nga "Libri i problemeve" i G. Oster:

Nga dy kabina të vendosura në një distancë prej 27 km nga njëri-tjetri, dy qen të ashpër u hodhën drejt njëri-tjetrit në të njëjtën kohë. E para shkon me një shpejtësi prej 4 km / orë, dhe e dyta - 5 km / orë.
Sa kohë do të fillojë lufta?

5. Emërtoni sa më shumë karakteristika të objektit "palë këpucë". Hartoni një model informacioni të një objekti për qëllime të ndryshme:
■ Zgjedhja e këpucëve për ecje;
■ përzgjedhja e një kutie të përshtatshme këpucësh;
■ blerja e kremit për kujdesin e këpucëve.

6. Cilat karakteristika të një adoleshenti janë thelbësore për një rekomandim për zgjedhjen e një profesioni?

7. Pse kompjuteri përdoret gjerësisht në simulime?

8. Emërtoni mjetet e njohura për modelimin kompjuterik.

9. Çfarë është një eksperiment kompjuterik? Jep një shembull.

10. Çfarë është testimi i modelit?

11. Çfarë gabimesh hasen në procesin e modelimit? Çfarë duhet bërë kur zbulohet një gabim?

12. Çfarë është analiza e rezultateve të simulimit? Cilat përfundime nxirren zakonisht?