Klasat me kritere
Kriteret strukturore (Klasa I).
Kriteret strukturore përdorni një model programi "kuti të bardhë", i cili supozon njohuri për kodin burimor të programit ose specifikimin e programit në formën e një grafiku të kontrollit të rrjedhës. Informacion strukturorështë e kuptueshme dhe e arritshme për zhvilluesit e nënsistemeve dhe moduleve të aplikacionit, prandaj këtë klasë kriteret përdoren shpesh në fazat e testimit të njësisë dhe integrimit (testimi i njësisë, testimi i integrimit). Kriteret strukturore bazohen në elementet bazë të UGP, operatorët, degët dhe shtigjet.1 metodë e zbrazëtisë publike (ref int x) ( 2 nëse (x>17) 3 x = 17-x; 4 nëse (x==-13) 5 x = 0; 6 ) Shembulli 3.1. Një shembull i një programi të thjeshtë për testim sipas kritereve strukturore
1 metodë e zbrazët (int *x) ( 2 nëse (*x>17) 3 *x = 17-*x; 4 nëse (*x==-13) 5 *x = 0; 6 ) Shembulli 3.1.1. Një shembull i një programi të thjeshtë për testim sipas kritereve strukturore
Një grup testimi i një testi plotëson kriterin e komandës (C0): (X,Y)=((x në =30, x jashtë =0)) mbulon të gjithë operatorët e gjurmës 1-2-3-4-5-6 Grup testimi me dy teste, plotëson kriterin e degës (C1): (X,Y)=((30,0), (17,17)) shton 1 test për shumë teste për C0 dhe rrugën 1-2-4-6. Gjurma 1-2-3-4-5-6 kalon nëpër të gjitha degët e arritshme në nëse pohimet nën kushtin e vërtetë dhe gjurmimi 1-2-4-6 nëpër të gjitha degët e arritshme në nëse deklaratat nën kushtin false. teston, plotëson kriterin e rrugës (C2): (X,Y)=((30.0), (17.17), (-13.0), (21.-4)) Një grup kushtesh për dy nëse jepen deklaratat me etiketat 2 dhe 4
| (30,0) | (17,17) | (-13,0) | (21,-4) | |
| 2 nëse (x>17) | > | > | ||
| 4 nëse (x==-13) | = | = |
Kriteri i degës C2 e teston programin më tërësisht se kriteri C1, por edhe nëse plotësohet, nuk ka bazë për të pohuar se programi është zbatuar në përputhje me specifikimet. Për shembull, nëse specifikimi specifikon kushtin që |x|100 , pakënaqshmëria e të cilave mund të verifikohet me një test (-177,-177). Në të vërtetë, operatorët 3 dhe 4 në provën (-177,-177) nuk do të ndryshojnë vlerën x=-177 dhe rezultati nuk do të përmbushë specifikimet. Kriteret strukturore mos kontrolloni përputhshmërinë me specifikimet nëse nuk pasqyrohet në strukturën e programit. Prandaj, kur testojmë me sukses një program sipas kriterit C2, mund të mos vërejmë një gabim që lidhet me mospërmbushjen e kushteve të caktuara të specifikimit të kërkesave.
Kriteret funksionale (klasa II)
Kriteri funksional- kriteri më i rëndësishëm i testimit për industrinë e softuerit. Ai siguron, para së gjithash, kontroll mbi shkallën në të cilën kërkesat e klientëve janë përmbushur në produktin softuer. Meqenëse kërkesat janë të formuluara për produktin në tërësi, ato pasqyrojnë ndërveprimin e aplikacionit në provë me mjedisin. Testimi funksional përdor kryesisht një model të kutisë së zezë. Problemi me testimin funksional është, para së gjithash, intensiteti i punës; Fakti është se dokumentet që rregullojnë kërkesat për një produkt softuer (Specifikimet e kërkesave të softuerit, specifikimet funksionale, etj.) zakonisht janë mjaft voluminoze, megjithatë, verifikimi përkatës duhet të jetë gjithëpërfshirës. Më poshtë janë llojet specifike kriteret funksionale.Artikujt e specifikimeve të testimit- një grup testesh në total duhet të sigurojë që çdo artikull i testuar të kontrollohet të paktën një herë.
Një specifikim i kërkesave mund të përmbajë qindra e mijëra kërkesa për një produkt softuer, dhe secila prej këtyre kërkesave gjatë testimit duhet të verifikohet në përputhje me kriterin nga të paktën një test
Testimi i klasave të hyrjes- një grup testesh së bashku duhet të sigurojë që një përfaqësues i secilës klasë të të dhënave hyrëse të testohet të paktën një herë.
Kur krijohen teste, klasat e të dhënave hyrëse krahasohen me mënyrat e përdorimit të komponentit ose nënsistemit të aplikacionit që testohet, gjë që redukton ndjeshëm opsionet e forcës brutale të marra parasysh gjatë zhvillimit të rasteve të provës. Duhet të theksohet se kur renditni vlerat e ndryshoreve hyrëse në përputhje me kriterin (për shembull, skedarë të ndryshëm- burimet e të dhënave hyrëse), ne jemi të detyruar të përdorim suita të fuqishme testimi. Në të vërtetë, së bashku me kufizimet në vlerat e të dhënave hyrëse, ka kufizime në vlerat e të dhënave hyrëse në të gjitha kombinimet e mundshme, duke përfshirë kontrollimin e reagimeve të sistemit ndaj shfaqjes së gabimeve në vlerat ose strukturat e të dhënave hyrëse. . Marrja parasysh e këtij diversiteti është një proces intensiv i punës, i cili krijon vështirësi në zbatimin e kriterit.
Testimi i rregullave- një grup testesh në total duhet të sigurojë verifikimin e secilit rregull, nëse vlerat hyrëse dhe dalëse përshkruhen nga një grup rregullash, disa gramatikë.
Duhet të theksohet se gramatika duhet të jetë mjaft e thjeshtë në mënyrë që intensiteti i punës për zhvillimin e grupit përkatës të testeve të jetë realist (përshtatet në kornizën kohore dhe stafin e specialistëve të caktuar për zbatimin e fazës së testimit)
Testimi i klasave të rezultateve- një grup testesh në total duhet të sigurojë verifikimin e një përfaqësuesi të secilës klasë të prodhimit, me kusht që rezultatet e prodhimit të klasifikohen paraprakisht, dhe klasa të veçanta rezultatet marrin parasysh, ndër të tjera, kufizimet në burime ose kohë ( kohë jashtë).
Kur krijohen teste, klasat e të dhënave të daljes krahasohen me mënyrat e përdorimit të komponentit ose nënsistemit në provë, gjë që redukton ndjeshëm opsionet e forcës brutale të marra parasysh gjatë zhvillimit të rasteve të provës.
Testimi i funksionit- një grup testesh së bashku duhet të sigurojnë që çdo veprim i zbatuar nga moduli nën testim të kontrollohet të paktën një herë.
Një kriter shumë i popullarizuar në praktikë, i cili, megjithatë, nuk siguron mbulimin e një pjese të funksionalitetit të komponentit në provë të lidhur me vetitë strukturore dhe të sjelljes, përshkrimi i të cilit nuk është i përqendruar në funksione individuale (d.m.th. përshkrimi është i shpërndarë në të gjithë komponent).
Kriteri i testimit të funksionit kombinon pjesërisht veçoritë e strukturore dhe kriteret funksionale. Ai bazohet në modelin e "kutisë së tejdukshme", ku tregohen në mënyrë eksplicite jo vetëm hyrjet dhe daljet e komponentit në provë, por edhe përbërja dhe struktura e metodave (funksioneve, procedurave) dhe klasave të përdorura.
Kriteret e kombinuara për programet dhe specifikimet- një grup testesh së bashku duhet të sigurojë që të gjitha kombinimet e kushteve dhe specifikimeve të qëndrueshme të programit të kontrollohen të paktën një herë.
Në këtë rast, të gjitha kombinimet e kushteve të qëndrueshme duhet të konfirmohen, dhe kushtet e kontradiktave duhet të zbulohen dhe eliminohen.
Një shembull i përdorimit të kritereve të testimit funksional për të zhvilluar një grup testesh bazuar në kriterin e klasave të të dhënave hyrëse
Le të supozojmë se për të zgjidhur problemin e testimit të sistemit "Sistemi i kontrollit për një kompleks të automatizuar të magazinimit të kushinetave" (shih Shtojcën 1, FS), është zhvilluar fragmenti i mëposhtëm i specifikimit të kërkesave:Rasti i testit 1 (mbulon klasën 4):
Gjendja e magazinës - 32.
Sistemi kërkon statusin e magazinës (thirrni funksionin GetStoreStat) dhe merr 32
Rasti i testit 2 (mbulon klasën 5):
Gjendja e mjedisit (hyrje - X):
Statusi i magazinës është 12dfga.
Sekuenca e pritshme e ngjarjeve (dalja - Y):
Sistemi kërkon statusin e magazinës (thirrni funksionin GetStoreStat) dhe, sipas klauzolës së specifikimit, nëse vlera e statusit të magazinës është e pasaktë, mesazhi "MAGA: GABIM: Status i padefinuar" shtohet në regjistër.
Kriteret stokastike (klasa III)
Testimi stokastik përdoret gjatë testimit të kompleksit sistemet softuerike- kur grupi i testeve përcaktuese (X,Y) ka fuqi të madhe. Në rastet kur një grup i tillë nuk mund të zhvillohet dhe ekzekutohet gjatë fazës së testimit, mund të zbatohet metodologjia e mëposhtme. 
Oriz. 3.1.
Gjatë formalizimit të modelit të shkallës së zbulimit të gabimeve (), u përdorën shënimet e mëposhtme: N - numri fillestar i gabimeve në paketën e softuerit përpara testimit, C - konstanta për uljen e shkallës së zbulimit të gabimit për shkak të gjetjes së gabimit tjetër, t 1, t 2,...t n - një dyfish i intervaleve të zbulimit të sekuencës në rritje nga n gabime, T është koha për të identifikuar n gabime. Nëse supozojmë se n gabime janë identifikuar gjatë kohës T, atëherë lidhja (1) është e vlefshme, duke deklaruar që produkti i shpejtësisë së identifikimit të gabimit i dhe kohës për të identifikuar gabimin i është 1 sipas përkufizimit:
(1) (N-i+1)*C*t i = 1
Sipas këtij supozimi, relacioni (2) është i vlefshëm për n gabime:
(2) N*C*t 1 +(N-1)*C*t 2 +…+(N-n+1)*C*t n =n N*C*(t 1 +t 2 +…+t n ) - C*Σ(i-1)t i = n NCT - C*Σ(i-1)t i = n
Nëse përcaktojmë t i nga (1) dhe shumën nga 1 në n, atëherë arrijmë në relacionin (3) për kohën T për zbulimin e n gabimeve
(3) Σ1/(N-i+1) = TC
Nëse shprehim C nga (2), arrijmë në relacionin (4):
(4) C = n/(NT - Σ(i-1)t i)
Së fundi, duke zëvendësuar C në (3), marrim relacionin përfundimtar (5), i përshtatshëm për vlerësime:
(5) Σ1/(N-i+1) = n/(N - 1/T*Σ(i-1)t i)
Nëse vlerësojmë vlerën e N përafërsisht duke përdorur metoda të njohura për vlerësimin e numrit të gabimeve në një program, ose të dhëna në dendësia e gabimeve për projektet e klasës në fjalë nga databaza e projekteve historike, dhe, përveç kësaj, përdorni të dhënat aktuale në intervalet ndërmjet gabimeve t 1 ,t 2 …t n të marra gjatë fazës së testimit, atëherë duke i zëvendësuar këto të dhëna në (5), mund të merrni një vlerësim të intervalit kohor t n+1 që kërkohet për të gjetur dhe korrigjuar gabimin tjetër (gabimi i ardhshëm). t n+1 >Td është koha e lejuar për testimin e projektit, pastaj përfundojmë testimin, përndryshe vazhdojmë të kërkojmë gabime.Duke vëzhguar sekuencën e intervaleve të gabimeve t 1 ,t 2 ...t n , dhe kohën e shpenzuar për identifikimin n gabime T=Σt i , ne mund të parashikojmë intervalin kohor deri në gabimet e radhës dhe të përsosim vlerën e C në përputhje me (4) Kriteri Moranda është shumë praktik, pasi mbështetet në informacionin e mbledhur tradicionalisht gjatë procesit të testimit.
Kriteri i mutacionit (klasa IV).
Supozohet se programuesit profesionistë shkruajnë pothuajse menjëherë programet e sakta, që ndryshojnë nga ato të sakta për shkak të gabimeve të vogla ose gabimeve shkrimore si - përmbysja vlerat maksimale indekset në përshkrimet e grupeve, gabimet në shenja veprimet aritmetike, nënvlerësimi ose mbivlerësimi i kufirit të ciklit me 1, etj. Propozohet një qasje që lejon, bazuar në gabime të vogla, të vlerësohet numri total gabimet e mbetura në program Qasja bazohet në konceptet e mëposhtme: Mutacione - gabime të vogla në program. Mutantët janë programe që ndryshojnë nga njëri-tjetri nga mutacionet. Metoda e testimit të mutacioneve- mutacionet futen në programin e zhvilluar P, d.m.th. krijoni artificialisht programe mutant P1, P2 ... Pastaj programi P dhe mutantët e tij testohen në të njëjtin grup testesh (X,Y).Nëse në grupin (X,Y) vërtetohet korrektësia e programit P dhe, përveç kësaj , atëherë të gjitha gabimet futen në programet mutant komplet testimi (X,Y) ndeshje kriteri i mutacionit, dhe deklarohet programi në provë korrekte.Nëse disa mutant nuk i kanë identifikuar të gjitha mutacionet, atëherë është e nevojshme të zgjerohet grupi i testeve (X,Y) dhe të vazhdohet testimi.Shembull i aplikimit të kriterit të mutacionit
Programi i testuar P është paraqitur në. Për të janë krijuar dy programe mutant P1 dhe P2. Ndryshuar në P1 vlera fillestare variabli z nga 1 në 2 ().Në P2, vlera fillestare e ndryshores i ndryshohet nga 1 në 0 dhe vlera kufitare e indeksit të ciklit ndryshohet nga n në n-1 (). (X,Y) = ((x=2,n=3,y=8),(x=999,n=1,y=999), (x=0,n=100,y=0 ) Zbulohen të gjitha gabimet në programet mutant dhe një gabim në programin kryesor, ku në gjendjen e ciklit ka n-1 në vend të n:// Metoda llogarit jo-negativin // n fuqinë e numrit x statik publik double PowerNonNeg(double x, int n) ( double z=1; if (n>0) ( for (int i=1; n-1> Shembulli 3.2. Programi kryesor P
double PowerNonNeg(double x, int n) ( double z=1; int i; if (n>0) ( for (i=1;n-1> Shembulli 3.2.1. Programi kryesor P
Vlera fillestare e ndryshuar e ndryshores z në mutantin P1 shënohet me një ton të lehtë:
// Metoda llogarit jo-negativin // n fuqinë e numrit x statik publik double PowerMutant1(double x, int n) ( double z=2; if (n>0) ( for (int i=1; n>=i;i++) ( z = z*x; ) ) else Console.WriteLine("Gabim! Fuqia e n duhet të jetë më e madhe se 0."); ktheje z;) Shembulli 3.3. Programi mutant P1.
double PowerMutant1(x dyfishtë, int n) ( dyfishtë z=2; int i; nëse (n>0) (për (i=1;n>=i;i++) ( z = z*x; ) ) tjetër printf( "Gabim! Fuqia e n duhet të jetë më e madhe se 0."); ktheje z;) Shembulli 3.3.1. Programi mutant P1.
Vlera fillestare e ndryshuar e ndryshores i dhe kufirit të lakut në mutantin P2 shënohet me një ton të lehtë:
// Metoda llogarit jo-negativin // n fuqinë e numrit x statik publik double PowerMutant2(double x, int n) ( double z=1; if (n>0) ( for (int i=0; n-1>=i;i++ ) ( z = z*x; ) ) else Console.WriteLine("Gabim! Fuqia e n duhet të jetë më e madhe se 0"); ktheje z;) Shembulli 3.4. Programi mutant P2.
double PowerMutant2(x dyfishtë, int n) ( dyfishtë z=1; int i; nëse (n>0) (për (i=0;n-1>=i;i++) ( z = z*x; )) tjetër printf ("Gabim! Fuqia e n duhet të jetë më e madhe se 0."); ktheje z; ) Shembulli 3.4.1. Programi mutant P2.
- Kriteri duhet të jetë i mjaftueshëm, d.m.th. tregojnë kur disa grupe të fundme testesh janë të mjaftueshme për të testuar një program të caktuar.
- Kriteri duhet të jetë i plotë, d.m.th. në rast gabimi, duhet të ketë një test të grupit të testeve që plotëson kriterin që zbulon gabimin.
- Kriteri duhet të jetë i besueshëm, d.m.th. çdo dy grupe testesh që e plotësojnë atë duhet të zbulojnë ose të mos zbulojnë njëkohësisht gabimet e programit
- Kriteri duhet të jetë lehtësisht i verifikueshëm, për shembull, llogaritur në teste
Për klasat jo të parëndësishme të programeve në rastin e përgjithshëm nuk ka asnjë kriter të plotë dhe të besueshëm në varësi të programeve ose specifikimeve.
Prandaj, ne përpiqemi për një kriter të përgjithshëm ideal nëpërmjet atyre reale të veçanta.
Klasat me kritere
- Kriteret strukturore përdorni informacione rreth strukturës së programit (të ashtuquajturat kritere të "kutisë së bardhë")
- Kriteret funksionale janë formuluar në përshkrimin e kërkesave për produktin softuer ( kriteret e ashtuquajtura të "kutisë së zezë".)
- Kriteret testimi stokastik janë formuluar në drejtim të kontrollit të pranisë së vetive të specifikuara në aplikacionin në testim, me anë të testimit të një hipoteze të caktuar statistikore.
- Kriteret e mutacionit janë të përqendruara në kontrollimin e vetive të një produkti softuerik bazuar në qasjen Monte Carlo.
Kriteret strukturore (Klasa I).
Kriteret strukturore përdorni modeli i programit në formën e një "kuti të bardhë", e cila supozon njohjen e kodit burimor të programit ose specifikimet e programit në formën e një grafiku të kontrollit të rrjedhës. Informacioni strukturor është i kuptueshëm dhe i arritshëm për zhvilluesit e nënsistemeve dhe moduleve të aplikacionit, prandaj kjo klasë kriteresh përdoret shpesh në fazat e modularit dhe testimin e integrimit(Testimi i njësisë, Testimi i Integrimit).
Kriteret strukturore bazohen në elementet bazë të UGP, operatorët, degët dhe shtigjet.
- Kushti kriter komandat e testimit(kriteri C0) - një grup testesh në total duhet të sigurojë që çdo komandë të kalojë të paktën një herë. Ky është një kriter i dobët dhe zakonisht përdoret në sisteme të mëdha softuerike ku kritere të tjera nuk mund të zbatohen.
- Kushti kriter degët e testimit(kriteri C1) - grupi i testeve së bashku duhet të sigurojë që çdo degë të kalojë të paktën një herë. Ky është një kriter mjaft i fortë dhe në të njëjtën kohë ekonomik, pasi numri i degëve në aplikacionin në provë është i kufizuar dhe jo aq i madh. Ky kriter përdoret shpesh në sisteme automatizimi i testimit.
- Kushti kriter testimi i rrugës(kriteri C2) - një grup testesh në total duhet të sigurojë që çdo rrugë të kalohet të paktën 1 herë. Nëse programi përmban një lak (veçanërisht një me një numër të nënkuptuar përsëritjesh), atëherë numri i përsëritjeve është i kufizuar në një konstante (shpesh 2, ose numri i klasave të rrugës së daljes).
| (30,0) | (17,17) | (-13,0) | (21,-4) | |
| 2 nëse (x>17) | > | > | ||
| 4 nëse (x==-13) | = |
Kriteri i rrugës C2 e kontrollon programin më mirë se kriteri C1, por edhe nëse plotësohet, nuk ka asnjë arsye për të pretenduar se
Kërkesat për një kriter testimi ideal
Kriteri duhet të jetë i mjaftueshëm.
Kriteri duhet të jetë i plotë.
Kriteri duhet të jetë i besueshëm.
Kriteri duhet të jetë lehtësisht i verifikueshëm
Për klasat jo të parëndësishme të programeve, në përgjithësi nuk ekziston një kriter i plotë dhe i besueshëm në varësi të programeve ose specifikimeve.
Prandaj, ne përpiqemi për një kriter të përgjithshëm ideal nëpërmjet atyre reale të veçanta.
Klasat me kritere
Strukturore
Funksionale
Kriteret për testimin stokastik janë formuluar në drejtim të kontrollit të pranisë së vetive të specifikuara në aplikacionin nën testim, me anë të testimit të një hipoteze të caktuar statistikore.
Kriteret e mutacionit përqendrohen në kontrollimin e vetive të një produkti softuerësh bazuar në qasjen Monte Carlo.
Kriteret strukturore
- përdorni një model programi në formën e një "kuti të bardhë", e cila supozon njohuri për tekstin burimor të programit ose specifikimin e programit në formën e një grafiku të kontrollit të rrjedhës. Kjo klasë kriteresh përdoret shpesh në fazat e testimit të njësisë dhe integrimit (testimi i njësisë, testimi i integrimit)
Kriteret strukturore bazohen në elementët kryesorë të UGP-së, operatorët, degët dhe shtigjet.
Gjendja e kriterit të testimit të komandës (kriteri C0) - një grup testesh në total duhet të sigurojë që çdo komandë të kalojë të paktën një herë. Ky është një kriter i dobët dhe zakonisht përdoret në sisteme të mëdha softuerike ku kritere të tjera nuk mund të zbatohen.
Kushti i kriterit të testimit të degës (kriteri C1) është që grupi i testeve së bashku duhet të sigurojë që çdo degë të kalojë të paktën një herë. Ky është një kriter mjaft i fortë dhe në të njëjtën kohë ekonomik, pasi numri i degëve në aplikacionin në provë është i kufizuar dhe jo aq i madh. Ky kriter përdoret shpesh në sistemet e automatizimit të testimit.
Gjendja e kriterit për testimin e shtigjeve (kriteri C2) - një grup testesh në total duhet të sigurojë që çdo shteg të kalohet të paktën 1 herë. Nëse programi përmban një lak (veçanërisht një me një numër të nënkuptuar përsëritjesh), atëherë numri i përsëritjeve është i kufizuar në një konstante (shpesh 2, ose numri i klasave të rrugës së daljes).
Kriteret funksionale
- kriteri më i rëndësishëm i testimit për industrinë e softuerit. Ai siguron, para së gjithash, kontroll mbi shkallën në të cilën kërkesat e klientëve janë përmbushur në produktin softuer. Reflektoni ndërveprimin e aplikacionit në provë me mjedisin. Përdoret një model i "kutisë së zezë". Problemi: punë intensive; Fakti është se dokumentet që rregullojnë kërkesat për një produkt softuer (Specifikimet e kërkesave të softuerit, specifikimet funksionale, etj.) janë mjaft voluminoze.
Testimi i artikujve të specifikimeve - një grup testesh së bashku duhet të sigurojnë që çdo artikull i testuar të verifikohet të paktën një herë.
Testimi i klasave të të dhënave hyrëse - një grup testesh së bashku duhet të sigurojnë që një përfaqësues i secilës klasë të të dhënave hyrëse të testohet të paktën një herë. Kur krijohen teste, klasat e të dhënave hyrëse krahasohen me mënyrat e përdorimit të komponentit ose nënsistemit të aplikacionit që testohet, gjë që redukton ndjeshëm opsionet e forcës brutale të marra parasysh gjatë zhvillimit të rasteve të provës. Duhet të theksohet se ne jemi të detyruar të përdorim suita të fuqishme testimi. Në të vërtetë, së bashku me kufizimet në vlerat e të dhënave hyrëse, ka kufizime në vlerat e të dhënave hyrëse në të gjitha kombinimet e mundshme, duke përfshirë kontrollimin e reagimeve të sistemit ndaj shfaqjes së gabimeve në vlerat ose strukturat e të dhënave hyrëse. . Marrja parasysh e këtij diversiteti është një proces intensiv i punës, i cili krijon vështirësi në zbatimin e kriterit.
Rregullat e testimit - një grup testesh së bashku duhet të sigurojnë që çdo rregull të verifikohet nëse vlerat hyrëse dhe dalëse përshkruhen nga një grup rregullash të disa gramatikës.
Testimi i klasave të prodhimit - një grup testesh së bashku duhet të sigurojnë verifikimin e një përfaqësuesi të secilës klasë dalëse, me kusht që rezultatet e daljes të klasifikohen paraprakisht, dhe klasat e rezultateve individuale të marrin parasysh, ndër të tjera, kufizimet e burimeve ose të kohës. Kur krijohen teste, klasat e të dhënave të daljes krahasohen me mënyrat e përdorimit të komponentit ose nënsistemit në provë, gjë që redukton ndjeshëm opsionet e forcës brutale të marra parasysh gjatë zhvillimit të rasteve të provës.
Testimi i funksionit - një grup testesh së bashku duhet të sigurojnë që çdo veprim i zbatuar nga moduli nën testim të kontrollohet të paktën një herë. Nuk siguron mbulim të një pjese të funksionalitetit të komponentit në provë që lidhet me vetitë strukturore dhe të sjelljes, përshkrimi i të cilit nuk është i përqendruar në funksione individuale (d.m.th., përshkrimi është i shpërndarë në të gjithë komponentin). Kriteri i testimit të funksionit kombinon pjesërisht veçoritë e kritereve strukturore dhe funksionale. Ai bazohet në modelin e "kutisë së tejdukshme", ku tregohen në mënyrë eksplicite jo vetëm hyrjet dhe daljet e komponentit në provë, por edhe përbërja dhe struktura e metodave (funksioneve, procedurave) dhe klasave të përdorura.
Kriteret e kombinuara për programet dhe specifikimet - një grup testesh së bashku duhet të sigurojnë që të gjitha kombinimet e kushteve dhe specifikimeve të qëndrueshme të programit të testohen të paktën një herë.
Kriteret stokastike
- përdoret gjatë testimit të sistemeve komplekse softuerike - kur një grup testesh përcaktuese ka fuqi të madhe. Në rastet kur një grup i tillë nuk mund të zhvillohet dhe ekzekutohet gjatë fazës së testimit
Është e nevojshme të zhvillohen programe që simulojnë sekuenca të rastësishme të sinjaleve hyrëse (x). Llogaritni në mënyrë të pavarur vlerat (y) për sinjalet përkatëse hyrëse (x) dhe merrni grupin e provës (X,Y). Testoni aplikacionin në grupin e testimit (X,Y), duke përdorur dy mënyra për të kontrolluar rezultatet:
Kontrolli përcaktues - kontrollimi i korrespondencës së vlerës së llogaritur y me vlerën y të marrë si rezultat i kryerjes së një testi në një grup (x) - një sekuencë e rastësishme e sinjaleve hyrëse të krijuara nga simulatori.
Kontrolli stokastik - kontrollimi i përputhshmërisë së një grupi vlerash (y), të marra si rezultat i testeve të kryera në një grup vlerash hyrëse (x), me një shpërndarje të njohur më parë të rezultateve F(Y).
Në këtë rast, grupi Y është i panjohur (llogaritja e tij është e pamundur), por ligji i shpërndarjes së këtij grupi është i njohur.
Kriteret e testimit stokastik
Metodat statistikore për përfundimin e testimit - metodat stokastike për marrjen e vendimeve në lidhje me koincidencën e hipotezave për shpërndarjen e ndryshoreve të rastit. Këtu përfshihet e njohura: Metoda e Studentit, Metoda Chi-square.
Metoda e vlerësimit të shkallës së zbulimit të gabimit - bazuar në modelin e shkallës së zbulimit të gabimit, sipas të cilit testimi ndalon nëse intervali kohor i vlerësuar midis gabimit aktual dhe gabimit tjetër është shumë i gjatë për fazën e testimit të aplikacionit.
Kriteri i mutacionit (klasa IV).
- Supozohet se programuesit profesionistë shkruajnë menjëherë programe pothuajse të sakta që ndryshojnë nga ato të sakta me gabime të vogla ose gabime shtypi - duke kthyer vlerat maksimale të indekseve në përshkrimin e vargjeve, gabime në shenjat e operacioneve aritmetike, nënvlerësim ose mbivlerësim kufiri i lakut me 1, etj. Është propozuar një qasje që lejon, bazuar në gabime të vogla, të vlerësohet numri total i gabimeve të mbetura në program.
Mutacionet janë gabime të vogla në program.
Mutantët janë programe që ndryshojnë nga njëri-tjetri nga mutacionet.
Metoda e testimit të mutacioneve - mutacionet futen në programin e zhvilluar P, d.m.th. krijoni artificialisht programe mutant P1, P2... Më pas programi P dhe mutantët e tij testohen në të njëjtin grup testesh (X,Y).
Nëse korrektësia e programit P konfirmohet në grupin (X,Y) dhe, përveç kësaj, identifikohen të gjitha gabimet e paraqitura në programet mutant, atëherë grupi i testit (X,Y) korrespondon me kriterin e mutacionit, dhe i testuar programi shpallet i saktë.
Testimi i sistemeve të informacionit
1.2. Kriteret e testimit.
Kërkesat për një kriter testimi ideal mund të identifikohen:
· Kriteri duhet të jetë i mjaftueshëm, d.m.th. tregojnë kur disa grupe të fundme testesh janë të mjaftueshme për të testuar një program të caktuar.
· Kriteri duhet të jetë i plotë, d.m.th. në rast gabimi, duhet të ketë një test të grupit të testeve që plotëson kriterin që zbulon gabimin.
· Kriteri duhet të jetë i besueshëm, d.m.th. çdo dy grupe testesh që e plotësojnë atë duhet të zbulojnë ose të mos zbulojnë njëkohësisht gabimet e programit.
· Kriteri duhet të jetë lehtësisht i verifikueshëm, për shembull, i llogaritur në teste.
Për klasat jo të parëndësishme të programeve, në përgjithësi nuk ekziston një kriter i plotë dhe i besueshëm në varësi të programeve ose specifikimeve. Prandaj, si rregull, njeriu përpiqet për një kriter të përgjithshëm ideal përmes atyre të veçanta reale.
Klasat e kritereve:
· Kriteret strukturore përdorin informacion për strukturën e programit (të ashtuquajturat kritere të "kutisë së bardhë").
· Kriteret funksionale janë formuluar në përshkrimin e kërkesave për produktin softuer (të ashtuquajturat kritere të "kutisë së zezë").
· Kriteret e testimit stokastik janë formuluar në drejtim të kontrollit të pranisë së vetive të specifikuara në aplikacionin në testim, me anë të testimit të disa teorive statistikore.
· Kriteret e mutacionit janë të përqendruara në kontrollimin e vetive të një produkti softuer bazuar në qasjen Monte Carlo.
Kriteret strukturore (Klasa I).
Kriteret strukturore përdorin një model të kutisë së bardhë të programit, i cili supozon njohuri për kodin burimor të programit ose specifikimin e programit në formën e një grafiku të kontrollit të rrjedhës. Informacioni strukturor është i kuptueshëm dhe i arritshëm për zhvilluesit e nënsistemeve dhe moduleve të aplikacionit, prandaj kjo klasë kriteresh përdoret shpesh në fazat e testimit të njësisë dhe integrimit.
Kriteret strukturore bazohen në elementët kryesorë të UGP-së, operatorët, degët dhe shtigjet.
· Gjendja e kriterit të testimit të komandës (kriteri C0) - grupi i testeve në total duhet të sigurojë që çdo komandë të kalojë të paktën një herë. Ky është një kriter i dobët, i përdorur në sisteme të mëdha softuerike ku kritere të tjera nuk mund të zbatohen.
· Kushti i kriterit për testimin e degëve (kriteri C1) - grupi i testeve në total duhet të sigurojë që çdo degë të kalojë të paktën një herë. Ky është një kriter mjaft i fortë dhe në të njëjtën kohë ekonomik. Ky kriter përdoret shpesh në sistemet e automatizimit të testimit.
· Gjendja e kriterit për testimin e shtigjeve (kriteri C2) - një grup testesh në total duhet të sigurojë që çdo shteg të kalohet të paktën një herë. Nëse programi përmban një lak (veçanërisht një me një numër të nënkuptuar përsëritjesh), atëherë numri i përsëritjeve është i kufizuar në një konstante (shpesh 2, ose numri i klasave të rrugës së daljes).
Kriteret strukturore nuk kontrollojnë përputhshmërinë me specifikimet nëse
nuk pasqyrohet në strukturën e programit.
Kriteret funksionale (klasa II).
Kriteri funksional është kriteri më i rëndësishëm i testimit për industrinë e softuerit. Ai siguron, para së gjithash, kontroll mbi shkallën në të cilën kërkesat e klientëve janë përmbushur në produktin softuer. Meqenëse kërkesat janë të formuluara për produktin në tërësi, ato pasqyrojnë ndërveprimin e aplikacionit në provë me mjedisin. Testimi funksional përdor kryesisht modelin e kutisë së zezë. Problemi me testimin funksional është, para së gjithash, intensiteti i punës; Fakti është se dokumentet që rregullojnë kërkesat për një produkt softuer (Specifikimet e kërkesave të softuerit, specifikimet funksionale, etj.) zakonisht janë mjaft voluminoze, megjithatë, verifikimi përkatës duhet të jetë gjithëpërfshirës.
Më poshtë janë llojet specifike të kritereve funksionale.
· Testimi i artikujve të specifikimeve - një grup testesh në total duhet të sigurojë që çdo artikull i testuar të verifikohet të paktën një herë. Një specifikim i kërkesave mund të përmbajë qindra e mijëra kërkesa për një produkt softuerësh dhe secila prej këtyre kërkesave gjatë testimit duhet të verifikohet në përputhje me kriterin me të paktën një provë.
· Testimi i klasave të të dhënave hyrëse - një grup testesh së bashku duhet të sigurojnë që një përfaqësues i secilës klasë të të dhënave hyrëse të testohet të paktën një herë. Kur krijohen teste, klasat e të dhënave hyrëse krahasohen me mënyrat e përdorimit të komponentit ose nënsistemit të aplikacionit që testohet, gjë që redukton ndjeshëm opsionet e forcës brutale që merren parasysh gjatë zhvillimit të rasteve të provës. Duhet të theksohet se, duke renditur vlerat e variablave hyrëse në përputhje me kriterin (për shembull, skedarë të ndryshëm - burime të të dhënave hyrëse), ne jemi të detyruar të përdorim grupe të fuqishme testimi. Në të vërtetë, së bashku me kufizimet në vlerat e të dhënave hyrëse, ka kufizime në vlerat e të dhënave hyrëse në të gjitha kombinimet e mundshme, duke përfshirë kontrollimin e reagimeve të sistemit ndaj shfaqjes së gabimeve në vlerat ose strukturat e të dhënave hyrëse. . Marrja parasysh e këtij diversiteti është një proces intensiv i punës, i cili krijon vështirësi në zbatimin e kriterit.
· Testimi i rregullave - një grup testesh së bashku duhet të sigurojnë verifikimin e secilit rregull nëse vlerat hyrëse dhe dalëse përshkruhen nga një grup rregullash të disa gramatikës. Duhet të theksohet se gramatika duhet të jetë mjaft e thjeshtë në mënyrë që intensiteti i punës për zhvillimin e grupit përkatës të testeve të jetë realist (përshtatet në kornizën kohore dhe stafin e specialistëve të caktuar për zbatimin e fazës së testimit).
· Testimi i klasave të prodhimit - një grup testesh së bashku duhet të sigurojnë verifikimin e një përfaqësuesi të secilës klasë dalëse, me kusht që rezultatet e daljes të klasifikohen paraprakisht, me klasa individuale të rezultateve që tregojnë, duke përfshirë kufizimet e burimeve ose të kohës.
Kur krijohen teste, klasat e të dhënave të daljes krahasohen me mënyrat e përdorimit të komponentit ose nënsistemit në provë, gjë që redukton ndjeshëm opsionet e forcës brutale të marra parasysh gjatë zhvillimit të rasteve të provës.
· Testimi i funksionit - një grup testesh së bashku duhet të sigurojnë që çdo veprim i zbatuar nga moduli nën testim të kontrollohet të paktën një herë. Një kriter shumë i popullarizuar në praktikë, i cili, megjithatë, nuk siguron mbulimin e një pjese të funksionalitetit të komponentit në provë të lidhur me vetitë strukturore dhe të sjelljes, përshkrimi i të cilit nuk është i përqendruar në funksione individuale (d.m.th. përshkrimi është i shpërndarë në të gjithë komponent).
Kriteri i testimit të funksionit kombinon pjesërisht veçoritë e kritereve strukturore dhe funksionale. Ai bazohet në modelin e "kutisë së tejdukshme", ku tregohen në mënyrë eksplicite jo vetëm hyrjet dhe daljet e komponentit në provë, por edhe përbërja dhe struktura e metodave (funksioneve, procedurave) dhe klasave të përdorura.
· Kriteret e kombinuara për programet dhe specifikimet - një grup testesh së bashku duhet të sigurojnë që të gjitha kombinimet e kushteve dhe specifikimeve të qëndrueshme të programit të kontrollohen të paktën një herë. Në këtë rast, të gjitha kombinimet e kushteve të qëndrueshme duhet të konfirmohen, dhe kushtet e kontradiktave duhet të zbulohen dhe eliminohen.
Kriteret stokastike (klasa III).
Testimi stokastik përdoret gjatë testimit të sistemeve komplekse softuerike - kur një grup testesh përcaktuese (X, Y) ka fuqi të madhe. Në rastet kur një grup i tillë nuk mund të zhvillohet dhe ekzekutohet gjatë fazës së testimit, mund të zbatohet metodologjia e mëposhtme.
· Zhvilloni programe që simulojnë sinjale hyrëse të rastësishme vijuese (x).
· Llogaritni në mënyrë të pavarur vlerat (y) për sinjalet përkatëse hyrëse (y) dhe merrni një grup testimi (X,Y).
· Testoni aplikacionin në grupin e testimit (X,Y), duke përdorur dy mënyra për të kontrolluar rezultatet:
1. Kontrolli përcaktues - kontrollimi i përputhshmërisë së vlerës së llogaritur me vlerën y të marrë si rezultat i ekzekutimit të testit në grupin (x) - një sekuencë e rastësishme e sinjaleve hyrëse të gjeneruara nga simulatori.
2. Kontrolli stokastik - kontrollimi i përputhshmërisë së grupit (), i marrë si rezultat i testeve të kryera në një grup vlerash (x), me një shpërndarje të njohur më parë të rezultateve F(Y). Në këtë rast, bashkësia y është e panjohur (llogaritja e saj është e pamundur), por ligji i shpërndarjes së këtij grupi është i njohur.
Kriteret e testimit stokastik:
· Metodat statistikore për kompletimin e testimit - metodat stokastike për marrjen e vendimeve për koincidencën e hipotezave për shpërndarjen e ndryshoreve të rastit. Këtu bëjnë pjesë të njohurat: metoda Studenti (St), metoda Chi-square (x 2) etj.
· Metoda e vlerësimit të shkallës së zbulimit të gabimit - bazuar në modelin e shkallës së zbulimit të gabimit, sipas të cilit testimi ndalon nëse intervali kohor i vlerësuar midis gabimit aktual dhe gabimit tjetër është shumë i gjatë për fazën e testimit të aplikacionit.
Kriteri i mutacionit (klasa IV).
Supozohet se programuesit profesionistë shkruajnë menjëherë programe pothuajse të sakta që ndryshojnë nga ato të sakta me gabime të vogla ose gabime tipografike - duke kthyer vlerat maksimale të indekseve në përshkrimet e grupeve, gabimet në shenjat e operacioneve aritmetike, nënvlerësimin ose mbivlerësimin e lakut. kufiri me 1, etj. Është propozuar një qasje që lejon, bazuar në gabime të vogla, të vlerësohet numri total i gabimeve të mbetura në program.
Qasja bazohet në konceptet e mëposhtme:
Mutacionet janë gabime të vogla në program.
Mutantët janë programe që ndryshojnë nga njëri-tjetri nga mutacionet.
Metoda e testimit të mutacioneve - mutacionet futen në programin e zhvilluar P, d.m.th. krijoni artificialisht programe mutant P1, P2...Më pas programi P dhe mutantët e tij testohen në të njëjtin grup testesh (X,Y).
Nëse korrektësia e programit P konfirmohet në grupin (X,Y) dhe, përveç kësaj, identifikohen të gjitha gabimet e paraqitura në programet mutant, atëherë grupi i testit (X,Y) korrespondon me kriterin e mutacionit dhe programi nën provë është shpallur e saktë.
Nëse disa mutant nuk i kanë identifikuar të gjitha mutacionet, atëherë grupi i provës (X, Y) duhet të zgjerohet dhe testimi të vazhdojë.
Sistemi i automatizuar WEB për testimin e studentëve
Procesi i testimit për këtë produkt software u nda në 2 faza: · testimi i faqes së përdoruesit është paraqitur në tabelën nr. 11. Tabela nr. 11...
Sistemi i automatizuar i testimit të studentëve ndër-platformë
Procesi i testimit të këtij produkti softuer u nda në 2 faza: · testimi i produktit të përdoruesit është paraqitur në tabelën nr. 11. Tabela nr. 11...
Studimi i algoritmeve të menaxhimit të burimeve për serverët me një procesor gjatë përpunimit të detyrave në internet (algoritmet SPT dhe RR)
Kriteret e mëposhtme përdoren për të krahasuar algoritmet afatshkurtër të planifikuesve: 1. Shfrytëzimi (përdorimi) i CPU-së. Përdorimi i CPU-së teorikisht mund të variojë nga 0 në 100% ...
Klasifikimi sisteme të automatizuara menaxhimi
Klasifikimi i sistemeve të automatizuara të kontrollit varet ndjeshëm nga kriteret e klasifikimit...
Koncepti i ndërtimit të një komplete shpërndarjeje
Siç e dini, deri më sot njerëzimi ka dalë me vetëm dy mënyra për të menaxhuar softuerin - montimin e tyre direkt nga paketat tekstet burimore dhe instalimi nga paketat binare të rikompiluara. Ne perputhje me...
Arsyetimi për zgjedhjen e universitetit më prestigjioz në Perm
Le të përcaktojmë kriteret me të cilat do të vlerësoj alternativat e propozuara. Kam identifikuar 7 kritere kryesore: 1. Opinioni publik. Kjo është më kriter i rëndësishëm, mbi të cilin bazohet imazhi i universitetit. 2. Njohja. Reputacioni i universitetit është gjithashtu i rëndësishëm...
Projekt lokal rrjeti kompjuterik kati i dyte i shkolles nr.19
Kriteri kryesor për pranim është përputhja e projektit të përfunduar me kërkesat e klientit, si dhe cilësia e punës së kryer...
Zhvillimi i një faqe interneti për "Dyqanin e lodrave për fëmijë"
5. Nënsistemi i daljes së ekranit sistemi i ndihmës për përdoruesin; 6. Nënsistem për shfaqjen e informacionit të programit në ekran. 2...
Zhvillimi multimedial tekst elektronik
Postuar në http://www.allbest...
Zhvillimi i një teksti elektronik multimedial për disiplinën "Rrjetet kompjuterike"
Një nga kriteret për zgjedhjen e një hosti është ai i përdorur sistemi operativ, meqenëse softueri që do të mbështesë funksionalitetin e disa shërbimeve varet nga ai...
Testimi i baterive LAN
Për të përshkruar gjendjen e rrjetit, u zgjodh metoda e vlerës së pragut, thelbi i së cilës është të krahasohet çdo vlerë e matur me një vlerë të rekomanduar të tabelës...
Shumë shpesh hasim pyetjen "Çfarë të automatizojmë së pari?" Automatizimi nuk bëhet për hir të automatizimit: ju dëshironi të shihni rezultatin e një procesi që do të jepte një ROI pozitiv (mund të lexoni më shumë rreth llogaritjes së ROI).
Pse është e rëndësishme të përdoret automatizimi?
Zakonisht besohet se automatizimi i testimit vepron si një mjet për të mbështetur testimin manual, por në fakt është e rëndësishme të kuptohet se automatizimi është Mënyra më e mirë jo vetëm kurseni kohë, por gjithashtu rrisni efikasitetin, gjerësinë e mbulimit dhe saktësinë e testimit, sepse detyrat e përsëritura në një qasje manuale janë në rrezik të gabimit njerëzor. Automatizimi nuk e tejkalon ose zëvendëson testimin manual, por e plotëson atë. Ashtu si menaxhimi i testeve, automatizimi gjithashtu ka nevojë për një strategji me planifikim, monitorim dhe kontroll të duhur. Automatorët jo vetëm që mësojnë mënyra të reja për të automatizuar, por gjithashtu marrin shumë vendime të zgjuara. Automatizimi në zbatimin e saktë mund të jetë një aset për ekipin, projektin dhe organizatën.
Ka shumë përfitime të automatizimit, ne do të përmendim në vijim:
- përshpejton detyrat e zakonshme si testet e tymit dhe regresionit;
- ndihmon në përgatitjen e të dhënave të testit;
- optimizon ekzekutimin e rasteve të testimit të lidhura me logjikën komplekse të biznesit;
- lehtëson rastet e testimit ndër-platformë (për shembull, kur testoni OS të ndryshëm, shfletues, etj.);
- E shkëlqyeshme për ekzekutimin e rasteve të testimit që janë të vështira apo edhe të pamundura për t'u përfunduar me dorë;
- Ndihmon mirë në rastet kur numri i përsëritjeve gjatë ekzekutimit është i panjohur paraprakisht.
Në të njëjtën kohë, mos harroni se automatizimi i të gjithë procesit të testimit software e vështirë dhe joefektive, si për shkak të kostos së lartë të mjeteve të testimit dhe potencialit për natyrën e paqëndrueshme të seksioneve të caktuara të aplikacionit. Situatat e projektit ndikojnë shumë në zgjedhjen e zonës për automatizim (qoftë automatizimi i testeve për regresion apo automatizimi që do të tregojë vende të ngushta në kuvende të shpeshta). Duke përshkruar gjithçka opsionet e mundshme, ne rrezikojmë të marrim një libër të tërë, dhe për këtë arsye do të shqyrtojmë vetëm situatën më të zakonshme: është e nevojshme të automatizojmë grupin e regresionit.
Pra, cilat janë kriteret për zgjedhjen e rasteve të testimit për automatizim?
Një nga më gabimet e zakonshme Ajo që bëjnë testuesit është zgjedhja e testeve të gabuara për t'u automatizuar. Është e nevojshme të analizohen dhe identifikohen me kujdes kandidatët për automatizim, duke marrë parasysh më së shumti faktor i rëndësishëm, përkatësisht ROI; me fjalë të tjera, ju duhet të gjeni mënyra për të marrë një ROI më të lartë dhe më pozitiv. Për ta bërë këtë, do t'ju duhet të kryeni një sërë veprimesh:
- përcaktoni frekuencën e ekzekutimit të rastit të provës (ekzekutoni atë për secilën ndertim i ri apo një herë, por me një sasi të madhe të dhënash?);
- zbuloni nëse rasti i testimit është kritik për biznesin ose mbulon një skenar të plotë nga fundi në fund;
- sigurohuni që analiza e rezultateve të autotestit të mos kalojë kohën e kaluar gjatë testimit manual (përndryshe do të humbasë rëndësinë e tij për automatizimin);
- të marrë parasysh mundësinë e zbulimit të gabimeve (prezantoni teste që më së shpeshti tregojnë gabime dhe dobësi);
- kuptoni nëse testi mund të bëhet bllokues për funksion i rëndësishëm ose funksionalitet që është kritik për biznesin.
Cilat lloje të testeve duhet të përjashtohen nga testimi i automatizimit?
Ne rendisim rastet në të cilat rastet e testimit duhet të filtrohen nga automatizimi:
- Testet e përdorshmërisë që kërkojnë ndërhyrje manuale për të kontrolluar gabimet ose devijimet nga sjellja e pritur;
- rastet e testimit që përfshijnë instalimin ose nuk kanë nevojë të riekzekutohen funksione (megjithatë, duhet të automatizoni testet që kërkojnë të dhëna të mëdha hyrëse);
- Shmangni automatizimin e testeve që mund të çojnë në rezultate të paparashikueshme (për shembull, funksionalitetin e ri, testet e kohës, kontrollin e datës së skadencës);
- Testet UX që përfshijnë kontrollimin e rikalibrimit të objekteve madhësive të ndryshme ekran.
Ç'pritet më tej?
Bazuar në faktorët e mësipërm të përzgjedhjes, do të marrim skenarë që do të marrin pjesë në përzgjedhjen për automatizim.
Hapi tjetër është ndarja e aplikacionit nën provë në module. Për çdo modul ne analizojmë dhe identifikojmë rastet e testimit me të cilat do të ekzekutohen set të ndryshëm të dhënat, në mjedise të ndryshme (OS/Browser) dhe me logjikë komplekse biznesi, përdorin një sasi të madhe të dhënash (përfshirë të veçanta) dhe përdoren nga përdorues të ndryshëm.
Le të shohim procesin duke përdorur një shembull. Ne kemi një modul për krijimin e aplikacioneve në sistem, për të cilin zgjedhim rastet e testimit të përfshira në procesin e krijimit të një aplikacioni. Pasi të jenë shkruar të gjitha testet, vërejmë nëse plotësohet të paktën një nga kushtet që përcaktuam më lart (Fig. 1).
Duke klikuar mbi foto do të hapet versioni i plotë.
Y – plotësohet kushti
N – Kushti nuk plotësohet
Kështu, marrim 3 raste testimi që mund të automatizohen dhe 2 raste testimi që nuk kërkojnë automatizim. Kemi përfunduar detyrën më të rëndësishme dhe gjysmën e mirë të punës: rrëmujën. temë e re shndërrohet në plani i detajuarçfarë duhet bërë.
konkluzioni
Më shpesh ne preferojmë të automatizojmë grupin e regresionit sepse ai përmban sasi e madhe shembuj testimi, dhe funksionaliteti i tij është tashmë i qëndrueshëm (d.m.th., ai nuk ndryshon nga ndërtimi në ndërtim). Në këtë rast, ne mund të ndajmë paketat e regresionit në module dhe të vendosim të ekzekutojmë paketën e duhur sipas kërkesave të lëshimit.
Në vend që të automatizojmë të gjithë grupin, ne zgjedhim automatizimin fazor. Me fjalë të tjera, ne ndjekim një model prototip për të zhvilluar një paketë automatizimi.
Pra, krijoni një strukturë ose kornizë me më pak raste testimi të zbatuara dhe më pas përmirësojeni atë duke shtuar gjithnjë e më shumë shembuj.
Duaje testuesin në vetvete, jo veten në testim!
