Software testatze

Software-testatzea softwarearen kalitatea bermatzeko erabiltzen den ikerketari deritzo. Teknika multzo bat erabiliz, akatsak hauteman ditzakegu softwarearen kalitate-maila bermatzeko. Beste era batera esanda, garatutako aplikazioaren ikuspegi objektiboa lortzen laguntzen digu gure aplikazioaren kalitatea hobetu ahal izateko.

Software-produktu bakoitzak publiko desberdinak izan ditzake. Software-probak publiko edo interesatuentzat produktua onargarria den ebaluatzen laguntzen digu.

Akatsak softwarearen bizi-zikloaren atal oso garrantzitsuak dira. Hauei esker gure softwarearen erroreak zuzendu eta hurrengo bertsioetan aplikazioaren kalitatea hobetzen dute eta bertsio hobetuak argitaratzea ahalbidetzen dute. Hori dela eta, testatze metodo asko akatsei zuzenduak egon ohi dira.

Probak egiteko garaian hainbat testaketa-mota aurki ditzakegu. Lehena proba estatikoa da. Bertan, kodea bere horretan exekutatu gabe, kodearen analisia lortzen da erreminta automatizatuak erabiliz. Bigarrena, dinamikoa litzateke, non programak exekutatuak izan behar dute analisia lortu ahal izateko. Hirugarrenean, proba pasiboetan, sistemaren erregistroak aztertzen dira analisia burutzeko.

Softwarea testatzeko metodo ohikoenak kutxa zuria eta beltza izan ohi dira. Hauetaz gain grisa ere aurki dezakegu, bien arteko ikuspegi hibridoa deritzona.

Azkenik, testeatze mailak eta teknikak adierazten dira sakonago. Hauetan atal bakoitzaren funtzioa azaltzen da. Atal bakoitzak ez du zertan besteekin zerikusia eduki behar, baina probak osagarriak izan daitezke beraien artean.

Ikuspegi orokorra

Softwarea probatzeak softwarearen zuzentasuna zehaztu dezake hipotesi zehatz batzuen arabera. Hala ere, probek ezin dituzte softwarearen akats guztiak identifikatu. Horren ordez, produktuaren egoera eta portaera probako orakuluekin alderatzen dituen kritika edo konparazioa ematen du. Orakulu horien artean, zehaztasunak, kontratuak, produktu konparagarriak, produktu beraren aurreko bertsioak, aurreikusitako edo espero zen xedeari buruzko ondorioak, erabiltzaileen edo bezeroen itxaropenak, arau garrantzitsuak, aplikagarriak diren legeak edo bestelako irizpideak aurki-daitezke.

Proben helburu nagusia software akatsak hautematea da, akatsak aurkitu eta zuzendu ahal izateko. Probek ezin dute egiaztatu produktu batek baldintza guztietan ondo funtzionatuko duenik. Ordea, jakin daiteke baldintza berezietan behar bezala funtzionatuko ez duela. Software-proben irismenean kodearen azterketa sar daiteke, baita kode hori hainbat ingurune eta baldintzatan exekutatzea ere. Gaur egungo software garapenaren kulturan, baliteke proba-erakunde bat garapen-taldetik bereizita egotea. Zenbait rol daude proba-taldeko kideentzat. Softwarea probatzetik eratorritako informazioa erabil daiteke softwarea garatzeko prozesua zuzentzeko.

Software-produktu bakoitza publiko zehatz bati dago zuzendua. Adibidez, bideo-jokoen softwarearen audientzia edo bankuena guztiz desberdinak dira. Beraz, erakunde batek software-produktu batean beste modu batera garatzen edo inbertitzen duenean, ebaluatu ahal izango du softwarearen produktua onargarria ote den azken erabiltzaileentzat, hartzaileentzat, erosleentzat eta beste alderdi interesdun batzuentzat. Software-probek ebaluazio hori egiten laguntzen dute.

Akatsak eta hutsegiteak

Software hutsegiteak prozesu hau jarraitzen dute: programatzaile batek akats bat egiten du, eta horrek errore bat sortzen du softwarearen iturburu-kodean. Matxura hau gauzatzen bada, zenbait egoeratan sistemak emaitza okerrak lortuko ditu, hutsegitea sortuz.

Akats guztiek ez dute derrigorrez huts egingo. Adibidez, hildako kodearen akatsak ez dira exekutatuko. Ordea, akatsak agerian jarri ez dituen hutsegiteak agertu daitezke ingurunea aldatzen denean. Ingurumeneko aldaketa horien adibide dira ordenagailuko hardware-plataforma berri batean exekutatzen ari den softwarea, iturburuko datuen aldaketak edo software desberdinen elkarreragina. Akats bakar batek huts egitearen sintoma ugari sor ditzake.

Softwarearen akats guztiak ez dira kodetze-akatsen ondorioz sortzen. Akats garestien iturri komun bat baldintza falta da, hau da, onartu gabeko baldintzak, programaren diseinatzaileak kontuan hartu ez dituenak. Eskakizunen hutsuneak askotan funtzionalak ez diren baldintzak izan daitezke, hala nola probagarritasuna, eskalabilitatea, mantenua, errendimendua eta segurtasuna.

Sarrera-konbinazioak eta aurrebaldintzak

Software probekin izaten den funtsezko arazo bat da sarrera-konbinazio eta aurrebaldintza guztietako probak ezin direla egin, ezta produktu sinple batekin ere. Horrek esan nahi du software-produktu baten hutsegite kopurua oso handia izan daitekeela eta gutxitan gertatzen diren akatsak nekez aurki daitezkeela probetan eta arazketan. Bestalde, kalitatearen dimentsio ez-funtzionalak — erabilgarritasuna, eskalabilitatea, errendimendua, bateragarritasuna eta fidagarritasuna — oso subjektiboak izan daitezke; pertsona batentzat balio nahikoa duen zerbaitek beste pertsona batentzat onartezina izan daiteke.

Software-garatzaileek ezin dute dena probatu, baina konbinazio-proben diseinua erabil dezakete nahi duten estaldura lortzeko ahalik eta proba kasu gutxien erabiliz.

Ekonomia

NISTek 2002an egindako ikerketa baten arabera, software akatsek AEBetako ekonomiari 59,5 mila milioi dolarreko kostua suposatzen zuen urtero. Kostu horren herena baino gehiago ekidin liteke, software proba hobeak egiten badira.

Softwarea testatzearen kostuak direla-eta azpikontratatzea oso ohikoa da. Txina, Filipinak eta India dira lehentasunezko helmuga batzuk lan hori burutzeko.

Rolak

Software-probak software-garatzaile arduratuek egin ditzakete; 1980ko hamarkada arte, "software tester" terminoa erabiltzen zen orokorrean, baina geroago lanbide bereizi gisa ere ikusi zen. Software-proben aldiei eta helburuei dagokienez, hainbat funtzio ezarri dira, hala nola, proben kudeatzailea, proben burua, proben analista, proben diseinatzailea, probatzailea, automatizazioaren garatzailea eta proben administratzailea.

Historia

Glenford J. Myersek 1979an bereizi zuen arazketa test probetatik. Bere arreta haustura-probetan bazegoen ere, softwarearen ingeniaritzaren komunitatearen garapenerako funtsezko jarduerak (arazketa, egiaztapenetik) bereizteko nahia adierazi zuen. Berak esan bezala, proba arrakastatsu bat oraindik aurkitu gabeko akats bat detektatzean datza.

Testatzearen ikuspegia

Proba estatikoak, dinamikoak eta pasiboak

Ikuspegi asko daude eskuragarri software-probetan. Azterketa edo ikuskapenei proba estatiko deitzen zaie, eta proba kasu multzo jakin batekin programatutako kodea gauzatzeari, berriz, proba dinamiko deritzo.

Proba estatikoak, askotan, inplizituak izaten dira; hau da, programazio-tresnek edo testu-editoreek iturburu-kodearen egitura berrikusten dutenean edo konpilatzaileek (aurrekonpilatzaileek) sintaxia eta datu-fluxua egiaztatzen dutenean programa analisi estatiko gisa exekutatzen dira. Proba dinamikoak programa bera exekutatzen denean gertatzen dira. Proba dinamikoak programa osoa bukatu baino lehen has daitezke, kode-atal zehatzak probatzeko eta funtzio edo modulu diskretu bat aplikatzeko. Ohiko teknikak hauek dira: stubs/driverrak erabiltzea edo ingurune arazle batetik exekutatzea.

Proba estatikoak egiaztapena eskatzen du, eta saiakuntza dinamikoak, berriz, egiaztapena eta baliozkotzea.

Proba pasiboa egiteak sistemaren portaera egiaztatzea esan nahi du software produktuarekin inolako interakziorik gabe. Proba aktiboekin alderatuta, garatzaileek ez dute proba daturik ematen. Honen ordez, sistemaren erregistroak aztertu behar dituzte.

Esplorazio-ikuspegia

Esplorazio-probak software-proben ikuspegi bat dira, eta honela deskribatzen dira: aldi bereko ikaskuntza, proben diseinua eta proben exekuzioa. Cem Kaner-ek asmatu zuen terminoa 1984an eta berak horrela definitu zuen: «software-proben estilo bat, norberaren askatasuna eta norberaren lanaren kalitatea etengabe optimizatzeko erantzukizuna nabarmentzen duena, probekin, proben diseinuarekin, proben gauzatzearekin eta proben emaitzak interpretatzearekin, eta proiektu osoan paraleloan egiten diren elkarri laguntzeko jarduerekin.»

"Kutxa" ikuspegia

Softwarea probatzeko metodoak kutxa zuri eta beltzeko probetan banatzen dira tradizionalki. Bi ikuspegi horiek garatzaileek proba-kasuak diseinatzean hartzen dituzten erabakiak deskribatzeko erabiltzen dira. Halaber, software proben metodologiari «kutxa grisa» izeneko ikuspegi hibridoa aplika dakioke. Kutxa grisa kontzeptuarekin, kutxa beltzeko eta zuriko proben arteko bereizketa arbitrario hori pixka bat desegin da.

Testatze mailak

Hiru testatze maila daude gutxienez: unitate-probak, integrazio-probak eta sistema-probak. Hala ere, garatzaileek 4.maila bat dagoela deritzote: onarpen-proba. Testatze azken honek, softwareak itxaropen funtzionalak betetzen dituela ziurtatzeko erabili ohi da. ISTQBren ikasketa-programaren arabera, testatze mailak lau horiek lirateke, 4. maila onarpen-proba izanda. Testak maila horietako batean taldekatzen dira maiz, softwarearen garapen-prozesuan gehitzen diren lekuaren edo probaren espezifikotasun-mailaren arabera.

Unitate-probak

Artikulu nagusia: Unit testing

Unitate-probak kode atal zehatzen funtzionaltasuna egiaztatzen dute. Objektuei zuzendutako ingurune batean klase mailan egongo litzateke, eta unitate-proba minimoen artean eraikitzaileak eta suntsitzaileak aurkitzen dira.

Proba mota hauek garatzaileek idazten dituzte kodea lantzen duten bitartean (kutxa zuriaren estiloa), funtzioa espero bezala funtzionatzen duela ziurtatzeko. Funtzio batek hainbat proba izan ditzake, kode izkinak edo bestelako adarrak harrapatzeko. Unitate-probek bakarrik ezin dute software baten funtzionaltasuna egiaztatu, baina softwarearen atal bakoitzak modu independentean funtzionatzen duela ziurtatzeko erabiltzen dira.

Unitate-proba akatsak prebenitzeko eta hautemateko estrategia espektro zabala erabiltzen duen aplikazio sinkronizatua da. Honen helburua, arriskuak, denbora eta kostuak murriztea da. Softwarearen garatzaileari edo ingeniari dagokio softwarea garatzeko bizitza-zikloaren eraikuntza fasean. Unitate proben helburua softwarea eraikitzean sortutako akatsak ezabatzea da, kodea testaketa proba osagarrietara pasa aurretik. Estrategia honen bitartez, lortutako softwarearen kalitatea eta garapen prozesu orokorraren eraginkortasuna hobetu beharko litzateke.

Erakundeak softwarea garatzeko dituen itxaropenen arabera, unitate probek kode estatikoen analisia, datuen-fluxuen analisia, metriken analisia, pareko kodeen berrikuspenak, kodeen estalduraren analisia eta beste software-proba batzuk izan ditzakete.

Integrazio-probak

Artikulu nagusia: Integrazio-probak

Integrazio-probak software diseinuaren aurka osagaien arteko interfazeak egiaztatzea helburu duen edozein software proba mota dira. Osagaiak modu iteratiboan edo guztiak batera ("big bang") integratu daitezke. Normalean, lehena praktika hobetzat hartzen da interfaze arazoen konponketa azkarragoa eta konpontze errazagoa duelako.

Integrazio-probak interfazeen arteko akatsak eta osagai integratuen(moduluen) arteko elkarreragina erakusteko balio dute. Softwareak sistema gisa funtzionatu arte, software-osagaien multzo handiagoak integratzen eta testatzen dira.

Integrazio probek kode asko dakarte eta unitate probetan sortutakoak baino aztarna handiagoak sortzen dituzte. Horrek eragina du huts egiteen akatsak lokalizatzeko erraztasunean. Horri aurre egiteko, proba handiak pieza txikiagoetan partekatzea proposatu ohi da.

Sistema-probak

Artikulu nagusia: Sistema-probak

Sistema-probek, sistema guztiz integratua probatzen du eskakizunak ondo betetzen dituela egiaztatzeko. Adibidez, sistemaren testaketa saio-hasierako interfaze bat probatzea izan daiteke, ondoren sarrera bat sortu eta editatzea, emaitzak bidali edo inprimatzea eta gero, sarrerak prozesatu edo ezabatzea. Azkenik saioa amaitzeko.

Onarpen-probak

Artikulu nagusia: Onarpen-probak

Onarpen probetan lau maila ezberdin bereiz ditzakegu:

• Erabiltzaileen onarpen-probak
• Onarpen operatibo probak
• Kontratuzko eta erregulatzaile onarpen-probak
• Alpha/Beta testaketa

Erabiltzaileen onarpen-probak eta Alpha/beta probak hurrengo testatze moten atalean azaltzen dira.

Onarpen operatiboa, kalitatea kudeatzeko sistema baten parte bezala, produktu, zerbitzu edo sistema baten operazio-prestutasuna(aurre-bertsioa) zuzentzeko erabiltzen da. OAT software ez-funtzionalaren proba arrunta deritzo, batez ere softwarea garatzeko eta softwarea mantentzeko proiektuetan erabiltzen da. Testatze mota hau sistemaren prestazio operatiboan oinarritzen da edo produkzio ingurunearen parte bihurtzeko intentzioarekin erabiltzen da. Hori dela eta, prestakuntza operatiboko probak (ORT) edo Eragiketen prestasuna eta bermea (OR&A) testetzea bezala ere deitzen zaie. OATen testatze funtzionalak sistemaren alderdi ez funtzionalak egiaztatzeko beharrezkoak diren probetara mugatzen dira.

Gainera, softwarearen probak espero bezala funtzionatzeaz gain, sistemaren eramangarritasuna, ingurunea ez hondatzea edo ingurune horretako beste prozesu batzuk ez funtzionatzea eragotzi behar du.

Kontratuaren onarpen proben akordioan zehaztutako onarpen irizpideetan oinarrituta egiten dira eta onarpen-probak software produktuari dagozkion araudietan oinarrituta egiten dira. Bi probaketa hauek erabiltzaileek edo testatzaile independenteek egin ditzakete. Araudia onartzeko probetan arauen agentziek parte hartuko dute zenbaitetan proben emaitzak ikuskatzeko.

Testatze motak, teknikak eta taktikak

Testaketa adierazteko hainbat etiketa ezberdin erabili ditzakegu. Gure kasuan, testatze motak, teknikak eta taktikak erabiliko ditugu.

Instalazio-probak

Artikulu nagusia: Instalazio-probak

Software-sistema gehienek erabili aurretik instalazio-prozedurak behar dituzte, haien helburu nagusia bete dadin.  Alegia, prozedura horiek  testatu behar dira etorkizunean software honi erabilera eman ahal izateko.

Bateragarritasun-probak

Artikulu nagusia: Bateragarritasun-probak

Software bat garatzeko garaian, arazo garrantzitsua izan daiteke beste aplikazio batzuekin bateragarria ez izatea. Aplikazioaren sistema eragileak bertsio zaharkitua edo berritua izateak ezusteko erroreak ekar ditzake, edo aplikazio bera ingurune ezberdinetan arazo berriak erakus ditzake (terminal batekin edo GUI aplikazio batekin mahaigainean exekutatzeko sortua izan den aplikazioa web aplikazio bihurtu nahiko bagenu, web arakatzaile batean errendatu beharko genuke. Baliteke hau egitea ezinezkoa izatea, bateragarritasun arazoengatik). Adibidez, atzerako bateragarritasunik ez dagoenean aurreko bertsioak dituzten erabiltzaileak erroreak jasoko dituzte. Hau da, garatzaileek azken bertsioetan testaketa sakona egiteak ez du zuzenean aurreko bertsioen exekuzio zuzena bermatuko. Batzuetan, arazo horiek sistema eragilearen funtzionaltasunaren abstrakzio proaktiboaren bidez konpon daitezke bereizitako programa- edo liburutegi-modulu batean.

Ke- eta zentzu- probak

Artikulu nagusia: Ke-probak

Zentzuzko probek zehazten dute probekin jarraitzea arrazoizkoa den ala ez.

Ke-proba softwarea saiakera urriekin funtzionatzea lortzea da, funtzionatzea eragotziko duen oinarrizko arazorik dagoen ala ez erazagutzeko diseinatua dago. Horrelako probak, eraikuntza(build) egiaztatze-proba gisa erabil daitezke.

Erregresio-probak

Artikulu nagusia: Erregresio-probak

Erregresio-probak kode aldaketa garrantzitsuen ostean akatsak aurkitzeaz arduratzen dira. Zehazki, softwarearen atzerakadak aurkitzen saiatzen da, degradatutako edo galdutako funtzioak eta akats zaharrak kontuan hartuz. Erregresio horiek aurretik behar bezala funtzionatzen zuen software funtzionaltasunak nahi bezala funtzionatzeari uzten dionean gertatzen dira. Normalean, atzerakada hauek programa aldaketen ustekabeko ondorio gisa gertatzen dira, softwarearen zati berriak aurreko kodearekin talka egiten dutenean. Erregresio-probak normalean software komertzialaren garapeneko esfortzu handiena behar duen atala da, aurreko softwarearen ezaugarrietan xehetasun ugari egiaztatu eta aztertu behar izateagatik. Arazoei aurre egiteko ohikoena software zaharraren eta berriaren testaketa zati batzuk bateratzea izaten da, horrela funtzionamendu egokia bermatuz.

Erregresio-probak egiteko ohiko metodoa aurreko test multzoak berrexekutatzea izaten da, aurreko arazoak bueltatu ez direla egiaztatzeko. Testatze sakonera bertsio prozesuaren fasearen eta gehitutako ezaugarrien arriskuen araberakoa izango da. Erregresio probetan, garrantzitsua da dagoen portaerari buruzko baieztapenak sendoak izatea. Horretarako, posible da baieztapen berriak sortu eta gehitu behar izatea erabilpen kasuetan. Hau, anplifikazio automatiko gisa ezagutzen da.

Onarpen-probak

Onarpen-probak esanahi hauek izan ditzake:

1. Ke-probak onarpen mailaren testatzea dira, beste edozein testatze baina lehenago egiten da(Integrazio edo erregresioa baino lehen).
2. Bezeroak egindako onarpen-probak, askotan bere hardware bidezko laborategi-inguruneetan eginak, erabiltzaileen onarpen-probak (UAT) izenarekin ezagutzen dira. Onarpen-probak garapenaren edozein bi faseren eskualdatze barruan egin daitezke.

Alfa-probak

Alfa testatzea gartzaileen gunean erabiltzaile edo testatze talde batek egindako simulazio edo proba operatiboak dira. Testatze hau, produktua ofizialki saldu baino lehenago egiten da eta beta testaketaren aurrekaria da. Honela, softwarearen barne-testaketa onargarria den jakin dezakegu.

Beta-probak

Ikusi ere: Software askatzearen bizi-zikloa § Beta

Beta testatzea alfa testatzearen ondoren dator eta kanpo erabiltzaileen onarpen probatzat har daiteke. Softwarearen bertsioak, beta bertsioak izenez ezagutzen direnak, beta testers izenarekin ezagutzen diren programazio taldetik kanpoko publiko mugatu bati bakarrik kaleratzen zaizkio. Softwarea talde jakin batzuei kaleratzen zaie proba kopurua handitzearren eta akats edo bug gutxi dituela ziurtatzeko. Beta-bertsioak publiko zabalaren eskura jar daitezke atzeraelikaduraren etorkizuneko iritzi eremua erabiltzaile kopuru handiagora iristeko eta proba honen luzera nahi adina luzatu ahal daiteke.

Proba funtzional eta ez-funtzionalak

Proba funtzionalak kodearen ekintza edo funtzio zehatzak egiaztatzen duten jarduerak dira. Hauek normalean kodearen eskakizunen dokumentazioan aurkitzen dira, nahiz eta garapen metodologia batzuk erabilera kasuetatik edo erabiltzaileen istorioetatik abiatzen diren. Proba funtzionalek "erabiltzaileak hau egin dezake?" edo "ezaugarri honek funtzionatzen du?" galderari erantzun ohi diote.

Funtzionalak ez diren probek baliteke funtzio zehatzekin edo erabiltzailearen ekintzarekin erlazionatuta ez egotea, hala nola eskalagarritasuna edo bestelako errendimenduan, murrizketa portaeretan edo segurtasunean zentratu daitezke. Testatzeak zehaztuko du haustura puntua, eskalagarritasun edo errendimendu muturrek exekuzio ezegonkorra zein puntutan gertatzen den adieraziz. Funtzionalak ez diren probak produktuaren kalitatea islatzen dutenak izan ohi dira, batez ere erabiltzaileen egokitasun ikuspegiaren testuinguruan.

Etengabeko-probak

Artikulu nagusia: Continuous testing

Etengabeko proben helburua softwarearen emate prozesuaren atal bakoitzean kalitatea ebaluatzea da, testak maiz eginez.

Proba hauek proba automatizatuak dira eta negozio arriskuei buruzko berehalako iritzia lortzeko erabiltzen dira. Etengabeko testatzeak proba funtzionalak eta funtzionalak ez direnak balioztatu behar izatea dakar. Proben esparrua goranzko eskakizunak edo erabiltzaileen istorioak balioztatzetik negozioaren helburu nagusiekin lotutako sistemaren eskakizunak ebaluatzera hedatzen da.

Proba suntsitzaileak

Artikulu nagusia: Destructive testing

Proba suntsitzaileak softwarea edo azpisistema baten huts egitea eragiten du. Softwarearen funtzionamendu egokia egiaztatzen du sarrera desegokiak edo ustekabekoak jasotzen dituenean ere, horrela sarrera baliozkotzeko eta erroreak kudeatzeko errutinen sendotasuna ezarriz. Software akatsen injekzioak, fuzzing moduan, hutsegite proben adibidea izan daiteke. Funtzionalak ez diren proba komertzialetako hainbat tresna software akatsen injekzio orrialdetik lotuta daude; iturri irekiko eta doako software tresna ugari daude eskuragarri, proba suntsitzaileak egiten dituztenak.

Softwarearen errendimendu-probak

Artikulu nagusia: Software performance testing

Errendimendu-probak sistema edo azpisistema batek lan-karga jakin baten aurrean sentikortasunari eta egonkortasunari dagokionez nola funtzionatzen duen zehazteko erabiltzen da. Sistemaren beste kalitate atributu batzuk ikertzeko, neurtzeko, baliozkotzeko edo egiaztatzeko ere balio dezake, hala nola eskalagarritasuna, fidagarritasuna eta baliabideen erabilera.

Kargen probek sistemak karga zehatz baten pean funtzionatzen jarrai dezakeela egiaztatzeaz arduratzen da, hau datu edo erabiltzaile kopurua handiarekin egin ohi da. Normalean software eskalagarritasuna esaten zaio. Jarduera ez-funtzional gisa egiten den karga-probari erresistentzia-proba deitzen zaio. Bolumenaren testatzea software funtzioak probatzeko modu bat da, zenbait osagaien (adibidez, fitxategi edo datu basea) tamaina handituz. Tentsio probek fidagarritasuna probatzeko modu bat eskaintzen dute ustekabeko edo arraroak diren lan-kargekin batez ere. Egonkortasun-probak (askotan karga edo erresistentzia probak deituak) epe onargarri batean softwareak etengabe ondo funtziona dezakeen egiaztatzen du.

Errendimendu proben helburu zehatzen kontuarekin adostasun gutxi dago. Kargen probak, errendimendu-probak, eskalagarritasun-probak eta bolumen-probak terminoak aldagarriak dira askotan.

Denbora errealeko software sistemek denbora mugarri zorrotzak dituzte eta denbora-mugak betetzen diren egiaztatzeko, denbora errealeko probak erabiltzen dira.

Erabilgarritasun-probak

Erabilgarritasun-proben helburua erabiltzailearen interfazea erabilerraza eta ulergarria dela egiaztatzea da. Aplikazioaren erabileraz arduratzen da batez ere. Hau ez da automatiza daitekeen probetako bat; benetako giza erabiltzaileak behar dira, UI diseinatzaile trebeek kontrola izanik.

Irisgarritasun-probak

Irisgarritasun probetan, honako estandarrak bete daitezke:

• Desgaitasuna duten Amerikarren 1990eko Legea
• 1973ko Errehabilitazio Legeari buruzko 508. atala
• World Wide Web Partzuergoaren (W3C) Web Irisgarritasunerako Ekimena (WAI)

Segurtasun-probak

Segurtasun-probak ezinbestekoak dira datu konfidentzialak prozesatzen dituzten softwarearentzat hackerren intrusioa ekiditeko.

Normalizaziorako Nazioarteko Erakundeak (ISO) honela definitzen du: "proba-elementu batek eta horri lotutako datuak eta informazioa,nola babesten diren ebaluatzeko egindako proba mota da. Baimenik gabeko pertsonek edo sistemek horiek erabili, irakurri edo aldatu ezin ditzaten, eta baimendutako pertsonei edo sistemei sarbidea baimenduz".

Nazioartekotzea eta kokapena

Nazioarteko eta kokapen probek softwarea baliozkotzeko, softwarea hizkuntza eta eskualde geografiko desberdinetan erabil daitezke. Sasi-kokapen prozesua aplikazio batek beste hizkuntza batera itzultzeko duen gaitasuna probatzea eta lokalizazio prozesuak produktuan akats berriak sortzen direnean identifikatzen laguntzeko erabiltzen da.

Globalizazio testak egiaztatzen du kultura berrietarako egokitzea bermatzen du.(adibidez moneta eta ordu zonak)

Gaur egungo hizkuntzaren itzulera testatua izan behar du globalizazio eta kokapen porrotak barne:

• Softwarea gehiengoetan testuinguru gabeko string zerrendetan egiten dira itzulpenak. Horrek okerrak eragin diezaioke itzultzaileari edo hitz anbiguoak itzul ditzake.
• Terminologia teknikoa batzuetan ez dator bat gaiarekin, hau gerta daiteke proiektu talde batek oso zorrotz erabiltzeagatik termino horiek edo itzultzailearen akatsarengatik.
• Hitzez hitz egindako itzulpenak ezegokiak dira oso artifizialak direlako.
• Jatorrizko hizkuntzan itzuli gabeko mezuak iturburu kodean gogor kodetuta egon daitezke.
• Zenbait mezu automatikoki sor daitezke exekuzio garaian eta ondorioz katea ez da gramatikala, funtzionalki okerra edo nahasgarria izan daitezke.
• Softwareak jatorrizko hizkuntzaren teklatuaren diseinuan funtziorik ez duen teklatu-lasterbideak erabil ditzake, baina helburu hizkuntzarako diseinuan karaktereak idazteko erabiltzen dira.
• Softwarea helburu hizkuntzaren karaktere kodeketarako laguntzarik ez edukitzea gerta daiteke.
• Baliteke jatorrizko hizkuntzan egokiak diren letra-motak eta tamainak desegokiak izatea helburu-hizkuntzan.
• Helburuko hizkuntzan string kate batek softwareak kudeatu dezakeena baino luzeagoa izatea gerta daiteke eta horrek, katea neurri batean ikusezin bihur dezake, softwareak huts edo funtzionamendu okerra eragin dezake.
• Softwarea euskarri egokia izan dezake bi hizkuntzen arteko irakurketa eta idazketan batetik bestera itzultzeko.
• Softwareak kokatuta ez zegoen testuarekin irudiak bistaratu ditzake.
• Sistema eragileek sistemaren konfigurazio fitxategiak , ingurune aldagaiak , data eta moneta formatu desberdinak izan dezakete.

Garapen probak

Software garapen probak softwarea garatzeko prozesu bat da eta softwarea garatzeko arriskuak, denbora eta kostuak murrizteko erabiltzen dira.  Software-garapenak edo ingeniariak eraikuntza fasean garapen testak egiten ditu eraikuntzako akatsak ekiditeko.Kodea beste proba batzuetara eraman aurretik, estrategia honen bidez lortutako softwarearen kalitatea eta garapen-prozesu orokorraren eraginkortasuna areagotu nahi da.

A/B probak

A/B testaketa kontrolerako esperimentu bat egiteko metodo bat da, metodo honetan, ikusi nahi dena gaur egungo dugun bertsioari eta aldatu nahi den bertsioaren artean zein bertsio den hobea zehazteko erabiltzen da.

Konkurrentzia probak

Konkurrentzia-testaketa erabiltzen da konputazio bateratua erabiltzen duten softwarea  erabiltzen duten sistemen portaera eta errendimendua ebaluatzeko. Testaketa honekin blokeaketa, lasterketa-arazoak, memoria eta baliabideak banatzeko arazoak probatzeko erabiltzen da.

Adostasun probak edo mota probak

Software probetan, adostasun probak produktu batek zehaztutako estandarren arabera funtzionatzen dutela egiaztatzen ditu. [aditzaren komunztadura zaindu] Konpiladoreak, adibidez, azterketa sakonak egiten dituzte hizkuntza horretan estandarrak betetzen diren ala ez jakiteko.

Irteera alderatzeko probak

Irteera alderatzeko probetan espero den irteerako datu bat sortzen da eta testua edo irudi bat izan daiteke. Honekin irteerako datuak datu okerrak diren ikus daitezke. Metodo hau argazki proba edo urrezko maisu proba  izenez bezela ezagutzen da, baina ez da oso gustukua. Honen arrazoia, testaketa sisteman datza: ez da automatikoa eta gizakiak ebaluatzen du probaren zuzentasuna.

Propietate probak

Propietate testaketa egiterako garaian, ausazko sarrerako datu ugari sortzen dira, ondoren, egiaztatzeko emaitzak ondo dauden edo ez propietate batzuk aplikatzen zaizkio. Adibidez, ordenatze funtziorako sarrera bakoitzeko bere irteera zerrendaren luzera bera izan beharko lukete. Ordenatzeko funtzio baten, irteera guztiak monotoki hazten den zerrenda bat izan behar du.

Propietate testaketa batzuetan "testaketa generatiboak" edo "QuickCheck test" izenarekin ere ezagutzen dira Haskell liburutegiak "QuickCheck" aurkeztu eta ezagun egin zenetik.

VCR probak

VCR testaketa "playback testing" edo "record/replay testing" bezala ezagutzen da. Testaketa teknika hau fidagarritasuna eta abiadura handitzeko erabiltzen da motelagoa eta ez fidagarria den beste API bat dagoenean. Sistemak kanpoko osagaiarekin dituen elkarreraginen grabaketa ("kasetea") egitea da, ondoren, grabatutako interakzioak errepikatzen dira.

Metodo hau famatua egin zuen web garapenerako Ruby liburutegi batek.

Testaketa prozesuak

Ur-jauzien garapen modu tradizionala

Ur-jauzien garapena, normalean, testaketa talde independenteek egiten dute,  eta gauza hauek gerta daitezke:

• Funtzionalitatea garatu ondoren eta bezeroari bidali aurretik, praktika horri esker, askotan proben fasea proiektuaren buffer gisa erabiltzen da proiektuaren atzerapenak konpentsatzeko, horrela, probei eskainitako denbora arriskuan jartzen da.
• Garapen-proiektua hasi den momentu beretik, proiektua amaitu arte egon behar dira.

Hala ere, ur-jauzia garatzeko ereduan ere, unitate testaketa, software garapenerako taldeak egin ohi ditu.

Arin edo XP garapen eredua

Gaur egun sortzen ari diren software diziplina batzuek, hala nola, muturreko programazioak eta software garapen arineko mugimenduak, "test-driven software development" ereduari jarraitzen diote. Prozesu honetan, software ingeniariak unitate testaketak idazten dituzte. Proba hauek idaztean, huts egitea espero da eta huts egin duen proba bakoitzari kodea idazten zaio, proba horiek gainditu ahal izateko. Akatsak aurkitu ahala konpontzen joaten dira eta honela porrotaren baldintza berriei aurre egiten zaie. Unitate testaketak gainerako softwarearen iturburu-kodearekin batera mantentzen dira orokorrean, eraikuntza-prozesuan integratzen dira.

Proba prozesu honen azken helburuak etengabeko integrazioari laguntzea eta akats tasak murriztea izango dira.

Metodologia honek garapenean egindako proben ahalegina areagotzen du. Testaketa eredu hau, proiektua bukatzen denean ematen ohi da, normalean, eta erabili baino lehen beste testaketa batzuk egiten dira.

Lagin testaketa zikloa

Erakundeen artean aldakuntzak egon arren, probetarako ziklo tipikoak daude. Laginen testaketa zikloa normalean ur-jauzi garapena erabiltzen duten erakundeak erabiltzea. Beste eredu batzuetan ikusi arren, ez dira hain argiak edo esplizituak izango.

• Eskakizunen analisia: Probak software garapeneko bizi-zikloaren eskakizunen fasean hasi beharko litzateke. Diseinu fasean, probatzaileek, lan egiten dute diseinu batean zein alderdi aztertu daitezkeen eta proba horietan zein parametro erabili beharko diren diseinuak funtzionatzeko.
• Testaketaren plangintza: Test estrategia, test plana, test lekuaren sorrera. Testaketan zehar jarduera ugari burutuko direnez, plan bat behar da.
• Testakeren garapena: Testaketa prozedurak, testaketa eszenatokiak, testaketa kasuak, testaketen datu multzoak, testaketarako softwarean erabiltzeko scriptak.
• Testaketaren exekuzioa: Probatzaileek softwarea exekutatzen dituzte eta azterketen dokumentuetan oinarrituta, ondoren aurkitutako akatsak jakinaraziko dizkio garapen taldeari. Aipatutako azken pauso hau zaila izan daiteke probatzaileak programatzen jakiten ez badu.
• Testaketen berri ematea: Testak amaitu ondoren, probatzaileek, metrikak sortzen dituzte eta azken txostena bat egiten dute probako ahaleginari buruz, bertan, probatutako softwarea prest kaleratzeko dagoen edo ez egongo da.
• Testaketaren emaitzen analisia: Normalean, garapen-taldeak bezeroarekin batera egiten ditu. Bertan zer akats esleitu, konpondu eta baztertu (hau da, softwarea behar bezala funtzionatzen duen) edo softwarea atzeratu behar den erabakitzeko.
• Akatsen birprobaketa: Garapen taldeak behin akats bat aurkituta, akats hori konpondu ondoren, proba taldeak berriro probatzen du.
• Erregresio-testak: Ohikoa da proba-programa txiki bat egitea proben azpimultzo batez osatua. Software berri hori, aldaketa edo integrazio bakoitzeko beharrezkoa da proba-programa berri bat egitea azken bidalketan akatsik ez egoteko.
• Testen itxiera: Testak irteerako irizpideak betetzen dituenean, funtsezko irteerak jasotzean, ikasitakoa, emaitzak, erregistroak eta proiektuarekin lotutako dokumentuak gorde eta etorkizunerako proiektuaren erreferentzia gisa erabiltzen dira.

Testaketa automatizatuak

Programazio taldeek gero eta gehiago erabiltzen dute proba automatikoak. Probak idazteko esparru asko daude, eta etengabeko integraziorako softwareak automatikoki exekutatuko ditu probak aplikazioaren bertsio bakoitzeko.

Automatizazioak gizakiak egin dezakeen guztia ezin egin arren, oso erabilgarria izan daiteke erregresio probak egiteko. Hala ere, testatzeko scriptak ondo garatutako proba multzoak beharko ditu benetan erabilgarria izateko.

Testaketa tresnak

Programen probak egiterako garaian, matxurak hautemateko tresnak eta arazketa probak izan daitezke. Probatzeko/arazteko tresnek honako ezaugarri hauek dituzte:

• Programaren monitoreak, kodearen kontrol partziala edo osoa ematen dute, besteak beste:
  • Agindu multzoen simulagailua, agindu maila kontrolatzeko eta trazatzeko instalazio osoa baimentzen dituena.
  • Hiperbisorea, programa kodearen exekuzioaren kontrol osoa baimentzen du.
  • Programaren animazioa, urratsez urrats, exekuzioa eta etenaldi baldintzatua baimentzen du iturburu mailan edo makina kodean.
  • Kodearen estaldura txostenak.
• Formateatutako zabortegia edo arazketa sinbolikoa, programaren aldagaiak akatsen bat dagoenean edo aukeratutako puntu konkretu bat ikustea ahalbidetzen  duen tresna.
• Erabiltzaile interfaze-grafiko funtzional automatizatuak (GUI) probatzeko tresnak erabiltzen diren sistema-mailako GUI bidezko errepikapenak.
• Oinarrizko erreferentziak, exekuzio garaiko errendimendu konparazioa ahalbidetuz.
• Errendimenduaren azterketetan, puntu beroak eta baliabideen erabilera nabarmentzen lagundu dezakete.

Ezaugarri horietariko batzuk tresna konposatuetan edo Garapen Ingurune Integratuetan (IDE) sar daitezke.

Kanpo estekak

• Datuak: Q188522
• Multimedia: Software testing / Q188522