Testimi i softuerit

Testimi i softuerit është procesi i vlerësimit të një sistem softuerik për të kontrolluar nëse ai plotëson kërkesat e specifikuara dhe i përmbush qëllimet e synuara.

TestingCup – Kampionati Polake në Testimin e Softuerëve, Katowice, Maj 2016

Përmes testimit të softuerit, ofrohet informacion i pavarur dhe objektiv në lidhje me cilësinë e produktit softuerik dhe rreziqet e mundshme të dështimit të tij, në shërbim të përdoruesve, sponsorëve apo çdo pale tjetër të interesuar. ^[1]

Megjithëse testimi i softuerit mund të verifikojë saktësinë e tij për raste specifike, ai nuk mund të garantojë saktësinë për të gjitha skenarët ^{[2] [3]} e mundshëm dhe nuk është në gjendje të zbulojë të gjitha gabimet e ekzistuara.

Bazuar në kriteret për matjen e saktësisë nga një orakull, testimi i softuerëve përdor parime dhe mekanizma që mund të identifikojnë një problem. Shembuj të orakujve përfshijnë specifikimet, kontratat, ^[4] produkte të krahasueshme, versionet e kaluara të të njëjtit produkt, konkluzionet rreth qëllimit të synuar ose të pritur, pritjet e përdoruesit ose klientit, standardet përkatëse dhe ligjet në fuqi.

Testimi i softuerit mund të jetë funksional ose jofunksional në natyrë.

Testimi i softuerit është shpesh dinamik në natyrë; ekzekutimi i softuerit për të verifikuar përputhjet aktuale të rezultateve të pritura. Mund të jetë gjithashtu statik në natyrë; rishikimi i kodit dhe dokumentacionit të shoqëruar me të.

Testimi i softuerit përdoret shpesh për t'iu përgjigjur pyetjes: A bën softueri atë që duhet të bëjë dhe atë që duhet të bëjë?

Informacioni i nxjerrë nga testimi i softuerëve mund të përdoret për të përmirësuar procesin me të cilin zhvillohet softueri. ^{[5] : 41–43}

Një qasje e sugjeruar zakonisht për testimin e automatizuar është "piramida e testimit", ku shumica e testeve janë teste njësie, të ndjekura nga një grup më i vogël testesh integrimi dhe së fundmi disa teste nga fillimi në fund (e2e) . ^{[6] [7] [8]}

Ekonomi

Një studim i kryer nga NIST në vitin 2002 raportoi se gabimet në softuer i kushtojnë ekonomisë amerikane 59.5 miliardë dollarë në vit. Më shumë se një e treta e kësaj kostoje mund të shmangej nëse do të kryhej testim më i mirë i softuerit. ^{[ <span title="The material near this tag is possibly inaccurate or nonfactual. (September 2014)">i dyshimtë</span> – diskutoni ]}

Testimi i softuerëve me kontratë për shkak të kostove është shumë i zakonshëm, me Kinën, Filipinet dhe Indinë si destinacionet e preferuara. ^[9]

Histori

Glenford J. Myers fillimisht prezantoi ndarjen e debugging-ut nga testimi në vitin 1979. ^[10] Megjithëse vëmendja e tij ishte te testimi i prishjeve ("Një rast testimi i suksesshëm është ai që zbulon një gabim ende të pazbuluar." ^{[10] : 16}), ilustroi dëshirën e komunitetit të inxhinierisë së softuerëve për të ndarë aktivitetet themelore të zhvillimit, siç është debugging-u, nga ato të verifikimit. Testimi i softuerëve zakonisht përfshin trajtimin e gabimeve të softuerit – një defekt në kod që shkakton një rezultat të padëshirueshëm. ^{[11] : 31}Gabimet në përgjithësi ngadalësojnë progresin e testimit dhe kërkojnë ndihmën e programuesit për të debuguar dhe rregulluar.

Jo të gjitha defektet shkaktojnë një dështim. Për shembull, një defekt në kodin e vdekur nuk do të konsiderohet dështim.

Një defekt që nuk shkakton dështim në një moment të caktuar mund të çojë në dështim më vonë për shkak të ndryshimeve mjedisore. Shembuj të ndryshimit të mjedisit përfshijnë funksionimin në harduer të ri kompjuterik, ndryshimet në të dhëna dhe bashkëveprimin me softuerë të ndryshëm.

Golat

Testimi i softuerëve zakonisht udhëhiqet nga qëllimet.

Gjetja e defekteve

Testimi i softuerit zakonisht përfshin trajtimin e gabimeve të softuerit – një defekt në kod që shkakton një rezultat të padëshirueshëm. ^{[11] : 31}Gabimet në përgjithësi ngadalësojnë progresin e testimit dhe kërkojnë ndihmën e programuesit për të debuguar dhe rregulluar.

Jo të gjitha defektet shkaktojnë një dështim. Për shembull, një defekt në kodin e vdekur nuk do të konsiderohet dështim.

Një defekt që nuk shkakton dështim në një moment të caktuar mund të çojë në dështim më vonë për shkak të ndryshimeve mjedisore. Shembuj të ndryshimit të mjedisit përfshijnë funksionimin në harduer të ri kompjuterik, ndryshimet në të dhëna dhe bashkëveprimin me softuerë të ndryshëm. ^[12]

Një defekt i vetëm mund të shkaktojë simptoma të shumëfishta të dështimit.

Sigurimi që kërkesat janë përmbushur

Testimi i softuerit mund të përfshijë një boshllëk në Kërkesa – heqje nga dizajni i një kërkese. ^{[5] : 426}Boshllëqet e kërkesave shpesh mund të jenë kërkesa jo-funksionale, siç janë testueshmëria, shkallëzueshmëria, mirëmbajtja, performanca dhe siguria .

Mbulimi i kodit

Një kufizim themelor i testimit të softuerëve është se testimi nën të gjitha kombinimet e të dhënave hyrëse dhe parakushteve (gjendja fillestare) nuk është i realizueshëm, madje as me një produkt të thjeshtë. ^{[13] : 17–18 [14]} Defektet që manifestohen në kushte të pazakonta janë të vështira për t'u gjetur gjatë testimit. Gjithashtu, dimensionet jo-funksionale të cilësisë (si supozohet të jetë kundrejt asaj që supozohet të bëjë ) – përdorshmëria, shkallëzueshmëria, performanca, përputhshmëria dhe besueshmëria – mund të jenë subjektive; diçka që përbën vlerë të mjaftueshme për një person mund të mos jetë për një tjetër.

Edhe pse testimi për çdo të dhënë të mundshme nuk është i realizueshëm, testimi mund të përdorë kombinatorikën për të maksimizuar mbulimin duke minimizuar testet.