fbpx

Mutacijos testavimas, arba programos mutacija, yra „baltosios dėžės” testavimo metodas, padedantis bendrovėms kurti įvairias naujas programinės įrangos patikras ir kartu tikrinti esamus projekto procesus. Tai palyginti naujas metodas, kuriuo užtikrinama, kad ir kūrėjai, ir testuotojai dirbtų pagal aukštus standartus.

Programa yra tik tiek sėkminga ar gera, kiek geros yra jos kokybės užtikrinimo procedūros, todėl labai svarbu, kad organizacijos taikytų daugiau nei vieną testavimo būdą.

Mokymasis apie mutacijų testavimą galėtų padėti testavimo grupėms patobulinti savo įgūdžius ir bendrąjį repertuarą, kad jos galėtų padidinti šių patikrinimų patikimumą. Mutacijų testavimas yra sudėtingas ir jautrus procesas, todėl labai svarbu, kad testuotojai nuodugniai ištirtų privalumus, iššūkius ir trečiųjų šalių programas, galinčias užtikrinti sėkmingą įgyvendinimą.

Šiame straipsnyje apžvelgsime mutacijų testavimą ir kaip jis pagerina kokybės užtikrinimą, taip pat kitus svarbiausius programinės įrangos testavimo komandų aspektus.

 

Table of Contents

Kas yra mutacijų testavimas programinės įrangos testavime?

Naudos, kurias teikia Od įsteigtas kompetencijos testavimo centras. Ar našumo testavimas skiriasi nuo funkcinio testavimo?

Kalbant apie programinę įrangą, mutacijų testavimas reiškia, kad kokybės užtikrinimo komanda sąmoningai į programos kodą įterpia klaidų (arba mutacijų) ir stebi, kaip komanda reaguoja. Tikslas – sukurti klaidą ir įsitikinti, kad testavimo rinkinys gali nustatyti kiekvieną programos pakeitimą.

Redaguodamas programos kodą, mutacijos testuotojas gali pakeisti tiesos ir netiesos išraišką, ištrinti teiginį arba tiesiog pakeisti reikšmę. Šios klaidos gali pasireikšti įvairiais būdais atliekant kitus programinės įrangos patikrinimus; visas jas lengvai aptinka kvalifikuota ir patyrusi testavimo komanda.

Pačios mutacijos dažnai būna labai nežymios, todėl kodą mutavęs testuotojas gali stebėti, kaip komanda atranda šiuos pakeitimus. Reikšmingi pakeitimai būtų akivaizdūs net iš pirmo žvilgsnio, todėl nedidelės klaidos paprastai yra geriausias būdas įsitikinti, kad įmonė taiko patikimą testavimo praktiką.

Šiuo metodu konkrečiai vertinamas komandos testavimo atvejų (dokumentų, kuriuose pateikiama testavimo informacija) veiksmingumas. Šiems patikrinimams atlikti komanda taip pat gali naudoti trečiosios šalies automatizavimo programinę įrangą – tokiu atveju atliekant mutacijų testavimą tikrinama, kaip gerai ši platforma gali aptikti programos kodo klaidas.

 

1. Kada reikia atlikti mutacijų tyrimą?

 

Kadangi mutacijų testavimo tikslas – patvirtinti ir patobulinti esamas kokybės užtikrinimo patikras, komandoms labai svarbu jas atlikti ankstyvuoju testavimo etapu. Tai reiškia, kad jei testavimo rinkinys nesugeba nustatyti ir „nužudyti” mutantų, yra pakankamai laiko iš esmės pakeisti bet kokio masto organizacijos testavimo procedūras.

Kadangi tai labai universalus metodas, mutacijų testavimas gali būti taikomas praktiškai bet kokio tipo programinei įrangai, įskaitant žiniatinklio, mobiliąsias ir darbalaukio programas. Tai geriausiai veikia vienetų testavimo etape, kuriame tikrinami mažiausi programos komponentai.

 

2. Kada nereikia atlikti mutacijų testavimo

 

Vis dar pasitaiko scenarijų, kai mutacijos ir bendras „baltosios dėžutės” testavimas programai netinka; taip gali būti dėl įvairių priežasčių.

Pavyzdžiui, jei bandytojai siekia patikrinti tik „juodosios dėžutės” bandymus – tokiu atveju jie turėtų sutelkti dėmesį į tos sesijos priekinę dalį arba net į bendrą bandymų etapą.

Kai kurios įmonės mano, kad „baltosios dėžutės” testavimas yra nuobodus ir reikalauja daug laiko, todėl gali atsisakyti šio proceso. Stiprūs, gerai patikrinti testavimo atvejai taip pat gali padėti išvengti mutacijos testavimo, nes tai rodo komandos kruopštumą ir atsidavimą tikslioms testavimo procedūroms.

 

3. Kas dalyvauja atliekant mutacijų analizę?

kas dalyvauja programinės įrangos testavime

Atliekant mutacijų analizę atliekami įvairūs vaidmenys, įskaitant:

 

– Mutacijų testeriai

Jie keičia kodą įvesdami įvairius smulkius defektus, kad užtikrintų, jog testavimo procesas veikia taip, kaip tikimasi. Šie testuotojai paprastai yra jau esami kokybės užtikrinimo grupės nariai.

 

– Programų testeriai

Jie reguliariai tikrina kodą, ar nėra problemų, nustato ir ištaiso rastas mutacijas. Jie atlieka „baltosios dėžutės” testavimą, kad rastų kodavimo klaidas, tačiau naudoja ir kitus metodus.

 

– Programų kūrėjai

Jie kuria programos funkcijas ir rašo pradinį kodą. Jie taip pat ištaiso visas testuotojų aptiktas problemas, užtikrindami, kad programinė įranga būtų stabili, kad ją būtų galima išleisti.

 

– Projektų vadovai

Jie teikia nurodymus dėl paraiškos ir gali dirbti kartu su mutacijų bandytojais, kad įsitikintų savo komandų veiksmingumu. Jie užtikrina griežtus standartus visuose vystymosi etapuose.

 

Ką tikriname mutacijų testais?

kai kurių neaiškumų programinės įrangos testavimo automatizavimo srityje išaiškinimas

Mutacijų testavimas labiau orientuotas į procesų, o ne į programos testavimą. Šiuo tikslu jame nagrinėjami šie klausimai:

 

1. Testavimo atvejai

 

Testavimo atvejai – tai dokumentai, kuriuose pateikiama išsami informacija apie kiekvieną testą, įskaitant rezultatus, kurių testuotojai tikisi iš kiekvieno atskiro patikrinimo. Nuoseklūs ir tikslūs testavimo atvejai suteikia QA komandos nariams informacijos apie programos būklę ir tai, kaip jos veikimas atitinka įmonės lūkesčius.

Šių testavimo atvejų informacija gali lemti testuotojo gebėjimą pastebėti tam tikrus defektus, įskaitant tuos, kuriuos sukelia mutacijų testavimas.

 

2. Bandymų standartai

 

Atliekant mutacijos testus atidžiai išnagrinėjamos dabartinės testavimo procedūros, siekiant užtikrinti, kad komandos nariai galėtų nustatyti net ir nedideles problemas, kurios gali turėti įtakos naudotojo suvokimui apie programinę įrangą.

Testuotojų kruopštumas ir kompetencija netgi gali būti pagrindiniai veiksniai, kuriuos įmonė įvertina atlikdama šiuos patikrinimus. Jei kiekviename etape neskiriama daug dėmesio detalėms, testuotojai gali nepastebėti rimtų programoje esančių mutacijų.

 

3. Atskiri kodo vienetai

 

Mutacijos testai yra įprasti kuriant vienetinius testus. Tai padeda analizuoti atskirus komponentus, kad būtų galima sutelkti dėmesį į kiekvieną testą ir gerokai optimizuoti visą procesą, užtikrinant, kad testuotojai dirbtų tik su atitinkamomis kodo eilutėmis.

Kadangi mutacijų bandymai dažnai atliekami ankstyvuoju kokybės užtikrinimo etapu ir gali būti pirmtakas visapusiškiems bandymams, šis metodas gali padidinti greitį nesumažinant tikslumo.

 

4. Programos atnaujinimai

 

Atnaujinant programinę įrangą paprastai iš naujo paleidžiamas bandymų procesas, kad būtų įsitikinta, jog nėra naujų klaidų ir ankstesnės klaidos nepasikartoja.

Mutacijos testų kartojimas yra pagrindinė šio proceso dalis, padedanti skatinti nuoseklius testavimo standartus po didelių programinės įrangos pakeitimų.

Testavimo komanda gali manyti, kad nuodugnios patikros po atnaujinimo nereikalingos, tačiau kodo mutacija gali užtikrinti, kad jie suprastų testavimo svarbą kiekviename kūrimo etape.

 

5. Automatikos programinė įranga

 

Įmonės taip pat atlieka mutacijos testavimą, kad patikrintų savo automatinių testų rinkinius ir įsitikintų, ar jie, be kitų problemų, gali pastebėti mutavusį kodą.

Jei trečiosios šalies testavimo programa gali nustatyti išorinius programos pakeitimus ir galbūt net juos ištaisyti, tai reiškia, kad organizacija gali pasitikėti šia programine įranga, kad galėtų automatizuoti testus.

Labai svarbu, kad įmonės patvirtintų savo automatizavimo metodą; tai suteikia ramybę kiekvienam testuotojui.

 

6. Automatizavimo strategija

 

Tai, kaip įmonė integruoja automatizavimą į savo procesus, yra ne mažiau svarbu nei naudojama programinė įranga; pavyzdžiui, ji gali nuspręsti įdiegti hiperautomatizaciją. Tai leidžia įmonei protingai nuspręsti, kuriuos mutacijos ir programinės įrangos testus automatizuoti.

Neturint tvirtos automatizavimo strategijos, kuri būtų pritaikyta prie didžiulės programos kodo įvairovės, kai kurie testai gali būti nesuderinami su automatizavimu, o tai apriboja platformos galimybes.

 

7. Paraiška

 

Nors atliekant mutacijų testavimą daugiau dėmesio skiriama testavimo komandai, o ne programai, jis vis tiek gali atskleisti svarbią informaciją apie šią programą.

Pavyzdžiui, mutacijos testavimas parodo, kaip programinė įranga reaguoja į kodo pakeitimus, įskaitant tai, ar ji nurodo šias problemas taip, kaip komanda tikisi.

Šis metodas nėra programinės įrangos testavimo metodas, tačiau vis tiek gali suteikti įdomių duomenų apie jos vidines operacijas.

 

Mutacijų testų gyvavimo ciklas

Įprastas mutacijų testavimo ciklas yra toks:

 

1. Reikalavimų analizė

 

Pirmasis bet kokio mutacijos testavimo ciklo žingsnis – tiksliai išsiaiškinti, ką reikia patvirtinti ir kurioms programos kodo dalims šie testai būtų naudingiausi.

Komanda gali pasikalbėti su kūrėjais ir vadovais, kad išsiaiškintų jiems rūpimus klausimus ir pradėtų juos spręsti.

 

2. Bandymų planavimas

 

Tuomet testuotojai pradeda rengti tikslias patikras, kurias ketina įgyvendinti, šiuo atveju – mutacijas, kurios padės geriausiai suprasti.

Šiame etape nustatoma bendra mutacijų testavimo strategija ir tai, kaip komanda ketina veiksmingai įgyvendinti numatytas kodo mutacijas.

 

3. Testavimo atvejų kūrimas

 

Mutacijos testavimas apima atskirą testavimo dokumentaciją, įskaitant informaciją apie mutavusį kodą ir tai, kaip bandytojai turėtų išspręsti problemą.

Gerai vedant apskaitą užtikrinama, kad visi bandymai vyktų pagal planą, ir tai gali padėti komandai išlaikyti aukštus bandymų standartus.

 

4. Bandomosios aplinkos nustatymas

 

Testuotojai įsitikina, kad programa yra paruošta jiems keisti ir kad jie turi procedūrą, kaip spręsti šias problemas, jei kiti komandos nariai negali jų aptikti.

Mutacijų testuotojai sukuria testavimo serverį ir naudoja jį kaip savo mutacijų drobę.

 

5. Bandymų vykdymas

 

Baigę pasiruošimo darbus, testuotojai pakeičia kelių programos komponentų kodą; tada jie laukia, kol kiti testuotojai pastebės ir ištaisys problemas.

Tiek mutacijų testuotojai, tiek programų testuotojai turi tai išsamiai dokumentuoti, kad įsitikintų, jog jų įrašai yra patikimi.

 

6. Bandymų ciklo uždarymas

 

Baigę testavimą, mutacijų testuotojai dar kartą patikrina, ar visus jų padarytus pakeitimus ištaisė programų testuotojai arba jie patys.

Tada jie užbaigia testavimo ciklą ir analizuoja rezultatus, aptaria, kaip testuotojai reagavo į įvairias klaidas ir kaip sugebėjo jas ištaisyti.

 

7. Bandymų kartojimas

 

Uždarius bandymų ciklą, ateityje atnaujinus programinę įrangą gali prireikti jį vėl įjungti.

Kiekvienas programos pakeitimas tam tikru būdu keičia jos funkcionalumą, todėl atsiranda naujų galimybių, į kurias komanda turi atsižvelgti ir užtikrinti, kad testavimo procesas būtų pakankamai kruopštus.

 

Mutacijų tyrimo nauda

 

Mutacijų tyrimai turi daug privalumų, įskaitant:

 

1. Patvirtina testavimo procesą

 

Pagrindinė mutacijų testavimo nauda – galimybė parodyti, kaip įmonės testuotojai žiūri į programinę įrangą, ir jų gebėjimą atpažinti kodavimo problemas. Taip pat užtikrinama, kad komandos testavimo atvejai būtų pakankamai išsamūs ir apimtų visus būtinus testus.

Mutacijos testais tikrinama bendra organizacijos testavimo procedūra, siekiant užtikrinti, kad ji veiktų taip, kaip tikėtasi.

 

2. Užtikrinamas stiprus automatizavimas

 

Mutacijos testavimas padeda komandai patikrinti, ar trečiosios šalies testavimo automatizavimo platforma sugeba tinkamai nustatyti kodo klaidas ir tinkamai jas pašalinti.

Jei ši programinė įranga jų neaptinka net po būtino kalibravimo, galbūt verta pakeisti platformą į tokią, kuri lengvai atlieka šiuos bandymus.

 

3. Gera aprėptis

 

Kiekvienas programinės įrangos testavimo procesas turi plačiai apimti visą programą, kad kiekvienam jos aspektui būtų skiriamas reikiamas dėmesys.

Mutacijos testai gali pakeisti bet kurią programos kodo dalį; geras įgyvendinimas leidžia šiems testams aprėpti visas svarbiausias funkcijas. Tai išmoko testuotojus ieškoti problemų visoje programoje.

 

4. Išnagrinėja pirminį kodą

 

Kadangi atliekant mutacijos testavimą reikia dirbti su kodu ir prireikus daryti tiesioginius pakeitimus, taikant šį metodą taip pat gali būti atkreiptas dėmesys į neoptimizuotus programoje esančius scenarijus.

Programinės įrangos testuotojai gali patvirtinti programą ir atlikti įprastus testus tik tuo atveju, jei programinės įrangos kodas yra tinkamas; šie patikrinimai leidžia testuotojams atkreipti dėmesį į galimas būsimas problemas.

 

5. Geresnė programinė įranga

 

Mutacijų testavimas padeda įsitikinti, kad programos testavimo procesai atitinka programos reikalavimus.

Jei atlikus mutacijos analizę paaiškėja, kad kokybės užtikrinimo komanda nesilaiko tinkamų procedūrų arba testavimo atvejai yra netinkami, testuotojai gali stengtis tai pagerinti. Neatlikusi šio deramo patikrinimo, organizacija gali išleisti nekokybišką gaminį, pati to nesuprasdama.

 

6. Efektyvus skirtingomis kalbomis

 

Nesvarbu, kokią kalbą testavimo komanda naudoja savo programai, yra programinės įrangos, galinčios pasiūlyti aukštos kokybės mutacijų analizę.

Tai apima daugybę kalbai būdingų gyvenimo kokybės funkcijų, kurios supaprastina patikras, kad jos būtų patikimesnės. Skirtingoms kalboms pritaikytas metodas pagerina kiekvieno atskiro testo kokybę.

 

7. Labai prieinamos priemonės

 

Daugelis geriausių mutacijos platformų yra visiškai atviro kodo, t. y. jose nemokamai arba už gerokai mažesnę kainą galima pritaikyti daugiau funkcijų ir naudotis įvairiausiomis funkcijomis.

Lyginant su daugeliu kitų testavimo formų, kodo mutacija turi mažiau kliūčių, todėl yra naudingas ir patogus būdas įmonėms įvertinti ar net patobulinti savo kokybės užtikrinimo metodą.

 

Mutacijų tyrimo iššūkiai

iššūkiai apkrovos testavimas

 

Šis procesas taip pat susijęs su daugybe iššūkių, pvz:

 

1. Reikalingos programavimo žinios

 

Kad testuotojai galėtų atlikti šias patikras, jie turi gerai išmanyti programą ir kodą, todėl mažiau patyrusiems testuotojams sunku prisidėti.

Įmonė gali testuoti programinę įrangą tik tokiais būdais, kurie atitinka turimus testuotojų įgūdžius, konkrečiai – jų gebėjimą redaguoti programą ir sukurti ištaisomą kodavimo klaidą.

 

2. Netinka juodosios dėžės testavimui

 

„Juodosios dėžės” testavimas daugiausia apima taikomosios programos priekinės dalies tikrinimą, netikrinant jos vidinės struktūros ir kodo – tai iš esmės nesuderinama su mutacijos testavimu.

Todėl šie patikrinimai naudingi tik kai kuriems bandymams, palyginti su kitais metodais, kurių daugelis gali užtikrinti daug didesnę viso bandymo etapo aprėptį.

 

3. Mutacijų testų kūrimas užima daug laiko

 

Kodo mutacija gali būti varginantis procesas, nes komandai reikia rasti atskirus komponentus, kuriuos verta mutuoti. Sprendimas, kurias mutacijas įgyvendinti, gali užtrukti daug laiko; tai gali būti problemiška, kai kitų tipų bandymai iš tikrųjų laukia, kol šie patikrinimai visiškai patvirtins įmonės bandymų metodą.

 

4. Gali prireikti daugybės kodo mutacijų

 

Panašiai ir sudėtinguose projektuose, siekiant užtikrinti visapusišką testavimą, natūraliai reikia daugiau mutantų. Dėl to mutacijos etapas užtrunka ilgiau ir gali tekti atlikti daug rankinių programėlės kodo pakeitimų.

Be aukštos kokybės testavimo automatizavimo programinės įrangos, turinčios programų mutacijos galimybes, testuotojams gali būti sunku tai sėkmingai įgyvendinti.

 

5. Testuotojai gali nepastebėti klaidų

 

Didžiausią nerimą mutacijų testuotojams ir projektų vadovams, įgyvendinant šias patikras, dažnai kelia galimybė, kad programinės įrangos testuotojai (rankiniai ar automatiniai) paprasčiausiai nepastebės problemų.

Dėl to gali tekti iš esmės peržiūrėti įmonės testavimo procedūras, nors tai vis tiek gali suteikti testuotojams svarbios informacijos apie jų kokybės užtikrinimo standartus.

 

6. Gali būti imlus atminčiai

 

Mutacijų testavimui paprastai reikia didelės skaičiavimo galios, nors tai gali priklausyti nuo testuotojų naudojamos programos.

Jei organizacija turi ribotą skaičių mašinų arba jei šių įrenginių specifikacijos yra žemos, jie gali būti nepajėgūs atlikti per daug vienu metu atliekamų mutacijų. Tai turi įtakos tam, kiek patikrinimų jie gali atlikti iki testavimo etapo pabaigos.

 

7. Ataskaitose gali būti daug informacijos

 

Nors tai daugiausia priklauso nuo komandos mutacijų testavimo įrankio sąsajos, jų generuojamas ataskaitas gali būti sunku analizuoti.

Tai reiškia, kad rankiniu būdu juos rūšiuoti ir rasti reikiamus bandymų rezultatus užtrunka; kai kurios programos leidžia naudotojams pritaikyti faktinį ataskaitų teikimo procesą; tai skiriasi priklausomai nuo programos.

 

Mutacijų tyrimų charakteristikos

Nefunkcinis testavimas: kas tai yra, skirtingi tipai, metodai ir įrankiai

Pagrindinės veiksmingų mutacijos testų savybės yra šios:

 

1. Išsamus

 

Šios patikros apima visus svarbiausius programinės įrangos aspektus; įmonės, turinčios pakankamai išteklių, gali net sukurti mutacijos testą kiekvienam įprastam testavimo atvejui.

Nors tikslus skaičius priklauso nuo organizacijos galimybių ir pageidavimų, veiksmingi mutacijų testai apima platų koduotų funkcijų spektrą.

 

2. Strateginis

 

Programų mutacijos taip pat turėtų atitikti aiškią ir gerai suplanuotą struktūrą, kuri palengvintų bendrų organizacijos testavimo tikslų įgyvendinimą.

Pavyzdžiui, jų sukuriamos klaidos gali būti panašios į realias testavimo klaidas, todėl testuotojai gali numatyti šias problemas, jei jos natūraliai atsiranda, ir taip gerokai patobulinti įmonės testavimo procesą.

 

3. Konstruktyvus

 

Mutacijų testavimo tikslas – nustatyti testavimo trūkumus ir parodyti, kaip komanda galėtų patobulinti patikrinimus ir ištaisyti atsiradusias nedideles klaidas.

Mutacijų testuotojai turi teikti pirmenybę „negaliojančioms” mutacijoms, kurios daro įtaką programinės įrangos funkcionalumui, kad būtų galima aiškiau patobulinti testavimą visame projekte.

 

4. Prevencinis

 

Šie patikrinimai skirti bendrai komandos strategijai patvirtinti; tai reiškia, kad mutacijų testavimas geriau veikia ankstyvaisiais kūrimo etapais.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Jei testuotojai pastebi kokių nors reikšmingų kokybės užtikrinimo metodo trūkumų, jie turi pakankamai laiko pakeisti savo testavimo atvejus, kad įsitikintų, jog jie yra tinkami.

 

5. Nuoseklus

 

Atliekant mutacijų testavimą skirtingose programos iteracijose turėtų būti gaunami nuoseklūs rezultatai, taip pat pridedama daugiau patikrų, kad būtų galima atsižvelgti į programinės įrangos pakeitimus.

Vėlesniems patikrinimams turi būti skiriamas toks pat dėmesys detalėms, kad jie išliktų veiksmingi – be šio tikslumo mutacijų testai gali tapti ne tokie tikslūs.

 

6. Subtilus

 

Mutacijos testais siekiama patikrinti kokybės užtikrinimo grupės gebėjimą nustatyti kodo defektus naudojant jų testus ir trečiųjų šalių platformas.

Tai reiškia, kad testai neturėtų būti iš karto akivaizdūs kiekvienam, tikrinančiam programinę įrangą; siekiama ištirti, kaip testuotojai reaguoja į nedideles kodo problemas.

 

7. Bendradarbiavimas

 

Kaip ir bet kuris programinės įrangos testas, kodo mutacija yra procesas, kurio sėkmei užtikrinti paprastai reikia komandinio darbo ir bendravimo. Bendradarbiavimo atmosfera padeda išvengti informacijos atskirties, dėl kurios gali kilti nesusikalbėjimo, taip pat garantuojama, kad kiekvienas testuotojas susitelks į atliekamas užduotis.

 

Mutacijų tyrimų tipai

Trys pagrindiniai mutacijų tyrimų tipai:

 

1. Vertės mutacija

 

Vertės mutacijos tiesiogiai keičia kodo reikšmes, pakeisdamos vieną skaičių ar raidę kita taip, kad būtų paveiktas programos funkcionalumas.

Pavyzdžiui, bandytojas gali pakeisti tikslius programos parametrus, pavyzdžiui, skaičius, į kuriuos ji reaguoja. Mutacijų testavimo specialistai gali būti konkrečiai nukreipti į programinės įrangos pastovias vertes, nes įprastinės veiklos metu jos visada išlieka tokios pačios.

 

2. Sprendimo mutacija

 

Sprendimų mutacijos keičia aritmetinius ir loginius operatorius, veiksmingai keisdamos taikomosios programos reakciją į konkrečias situacijas.

Pavyzdžiui, didesnio už operatorių (>) pakeitus mažesniu už operatorių (<), tai natūraliai paveikia programos išvestį. Testuotojai taip pat gali keisti „arba” į „ir” arba atvirkščiai, taip iš esmės pakeisdami šią programinę įrangą ir tai, kaip ji interpretuoja kitų testuotojų ir galimų naudotojų pateiktą informaciją.

 

3. Pareiškimo mutacija

 

Pareiškimų mutacijos keičia tikruosius kodo teiginius, modifikuodamos taisykles, kurias programa naudoja savo sprendimams priimti. Bandytojai gali keisti šių eilučių turinį, dubliuoti jas arba net ištrinti, kad patikrintų, kaip mutavusi programa paveiks programinės įrangos veikimą.

Šios mutacijos pakeičia programos sudedamąsias dalis ir gali pašalinti visas funkcijas arba kitaip trukdyti joms veikti.

 

Kai kurių neaiškumų išaiškinimas

– Mutacijų testavimas ir regresijos testavimas

UAT testavimo palyginimas su regresijos testavimu ir kitais

Tiek mutacijos, tiek regresijos testavimas yra naudingi programinės įrangos testavimo būdai – išmanant kiekvieną iš šių metodų galima pagerinti bendrą įmonės kokybės užtikrinimą.

 

1. Kas yra regresijos testavimas?

 

Regresinis testavimas – tai toks testavimas, kai testuotojai tikrina programinę įrangą tarp skirtingų iteracijų, kad įsitikintų, jog ji vis dar veikia nepaisant kodo pakeitimų.

Net ir nedideli pakeitimai gali sukelti rimtų problemų, o neatlikus šių patikrinimų gali vėl atsirasti ankstesnių klaidų. Dėl sudėtingo kiekvieno komponento pakartotinio testavimo pobūdžio tai paprastai reikia automatizuoti; dėl šios priežasties daugelis įmonių atsisako regresijos testų.

Bandytojai gali tikrinti atskirus vienetus, atskiras sudedamąsias dalis arba visą gaminį – tikslūs reikalingi bandymai daugiausia priklauso nuo projekto ir jo masto.

 

2. Kuo skiriasi mutacijos ir regresijos testai?

 

Regresinis testavimas pirmiausia skirtas programai ir jos funkcionalumui tikrinti, o kodo mutacija – tam, kaip testuotojai reaguoja į problemas.

Pirmoji taip pat dažniausiai atliekama po kelių programos iteracijų, o mutacijos patikros gali būti atliekamos bet kuriame kūrimo etape, tačiau dažniausiai ankstyvuoju testavimo etapu.

Tiek regresijos, tiek mutacijos testai gali būti susiję su atskirais kodavimo vienetais ir tuo, kaip nedideli pakeitimai gali sukelti reikšmingų problemų, kurias testuotojai turi ištaisyti.

 

3. Išvada: Mutacijų testavimas ir automatizuotas testavimas

Naudos, kurias teikia Od įsteigtas kompetencijos testavimo centras. Ar našumo testavimas skiriasi nuo funkcinio testavimo?

Automatizavimas dažnai yra pagrindinė mutacijų testavimo dalis dėl didelio patikrinimų ir vienetų skaičiaus, todėl kartais jis yra labai svarbus sėkmingam ir išsamiam testavimo procesui.

Įmonės paprastai naudoja kodų mutacijas, kad patikrintų savo trečiosios šalies automatizavimo platformą ir tai, kaip gerai ji nustato probleminius scenarijus.

Derinant išsamų mutacijų patikrų katalogą su automatizuota programine įranga galima gerokai padidinti įmonės aprėptį ir užtikrinti geresnius rezultatus.

Nors tai yra dvi atskiros testavimo praktikos, jos neturi prieštarauti viena kitai. Pavyzdžiui, robotizuotų procesų automatizavimo integravimas gali sustiprinti įmonės mutacijų testavimo strategiją.

 

Ko reikia norint pradėti mutacijų testavimą programinės įrangos inžinerijoje?

kontrolinio sąrašo programinės įrangos testavimo procesai

Įprasti išsamių mutacijų tyrimų reikalavimai yra šie:

 

1. Aiški testavimo strategija

 

Testavimo grupė turi nustatyti mutacijų testavimo strategiją, įskaitant tai, kuriuos komponentus ir vienetus svarbiausia ištirti.

Pavyzdžiui, tam tikri kodo aspektai gali būti labiau susiję su programos sėkme ir funkcionalumu; bandytojai turėtų įsitikinti, kad yra pakankamai mutacijų, kad būtų galima tai pritaikyti.

Įmonės mutacijų testavimo grafikas taip pat yra labai svarbus aspektas, nes taip užtikrinama, kad testuotojai turėtų pakankamai laiko kodui ištirti.

 

2. Jokios apimties šliaužimo

 

Net ir turint išsamią strategiją, kurioje išdėstytas įmonės požiūris į mutacijų tyrimus, gali būti, kad bus atlikta gerokai daugiau tyrimų, nei reikia.

Šios procedūros metu svarbiausia yra efektyvumas, ypač dėl to, kad kiti tyrimo etapai gali laukti, kol komanda suras ir sunaikins mutacijas. Prieš pradėdami keisti kodą, bandytojai turi aiškiai apibrėžti savo veiklos sritį; taip bus užtikrinta, kad viską bus galima atlikti per praktišką laiką.

 

3. Griežta dokumentacija

 

Kiekvienam testavimo procesui naudingas išsamus dokumentavimas – dažnai tai būna testavimo atvejai, kuriuose išsamiai aprašomi atskiri patikrinimai ir visi susiję mutantai.

Tai parodo dabartinę komandos pažangą atliekant testus, o tai ypač naudinga vadovams ir vadybininkams. Kiekvienos kodo mutacijos dokumentavimas taip pat padeda testuotojams tvarkyti aiškius įrašus apie atliktus pakeitimus.

Jei kokybės užtikrinimo komandai bandymų metu sunku rasti šias mutacijas, šie dokumentai gali būti atsakymo raktas.

 

4. Įgudę bandytojai

 

Kodą keičiantys testuotojai turi gerai išmanyti programinę įrangą, įskaitant daugybę būdų, kuriais jie gali ją pakeisti ar net sugadinti.

Mutacijų testuotojai apytiksliai žino, kaip jų pakeitimai paveiks taikomąją programą ir kaip kiti kokybės užtikrinimo komandos nariai galėtų nustatyti mutavusį kodą.

Tam paprastai reikia gerų programavimo žinių. Kad mutacijų analizė būtų veiksminga, programinės įrangos testuotojai taip pat turėtų turėti gerai išvystytų įgūdžių ir testavimo patirties.

 

5. Automatikos programinė įranga

 

Prieš atliekant mutacijų testavimą gali prireikti trečiosios šalies automatizavimo programinės įrangos, nes šiam procesui dažnai reikia atlikti daugybę patikrinimų. Tai ypač aktualu sudėtingoms programoms, kuriose yra daugiau kodo ir funkcijų, kurias turi patikrinti kokybės užtikrinimo komanda.

Įmonės gali atlikti šias patikras specialiai tam, kad patikrintų, kaip automatizavimo programinė įranga reaguoja į kodavimo klaidas. Tai gali būti pagrindinė įmonės bandomojo proceso dalis siekiant nuspręsti, kurios programos yra naudingiausios.

 

Mutacijų testavimo procesas

kontrolinis sąrašas uat, žiniatinklio programų testavimo įrankiai, automatizavimas ir dar daugiau

Atlikdami mutacijų analizę testuotojai paprastai atlieka šiuos veiksmus:

 

1. Parengti testus

 

Pasirengimas yra pirmasis bet kokio testavimo proceso žingsnis. Tai apima derybas dėl tikslių patikrinimų, kuriuos reikia atlikti, ir būtino pritarimo, pavyzdžiui, įmonės vadovų ir suinteresuotųjų šalių, gavimą.

Testuotojai turi parengti šias patikras taip, kad jos atitiktų projekto tvarkaraštį ir kartu apimtų visus svarbiausius komponentus. Komandos planavimas gali lemti jų kodo mutacijų veiksmingumą.

 

2. Pristatykite mutantus ir defektus

 

Baigusi pasiruošimo darbus, testavimo komanda pradeda keisti kodą, mutuoti jį pagal savo planą, kad būtų įvestos konkrečios klaidos. Šios klaidos turėtų būti palyginti nedidelės, nes tai leidžia testuotojams įvertinti likusios komandos dalies gebėjimą nustatyti kodavimo problemas.

Nedideli gedimai taip pat gali padėti organizacijai patikrinti trečiosios šalies automatizavimo programinės įrangos jautrumą.

 

3. Taikyti testavimo atvejus

 

Bandymų atvejais turi būti atsižvelgta į visus galimus programos gedimo taškus – gali tekti perrašyti programą iš naujo, jei mutavusi programa gali veikti be klaidų.

Programos testavimo atvejai – tai visos testuotojų atliekamos patikros; kiekvienas iš jų turėtų padėti testuotojams atskleisti paslėptas mutacijas ir būti neatsiejamas nuo programos tinkamumo naudoti.

 

4. Palyginkite rezultatus

 

Į programą įtraukusi mutacinių klaidų ir pritaikiusi komandos testavimo atvejus, komanda turi palyginti pradinės ir mutacinės programų rezultatus.

Tikimasi, kad po kiekvieno sėkmingo patikrinimo originalioje paraiškoje bus padaryta klaida ir mutavusioje paraiškoje. Tai parodo tiek testuotojų, tiek jų naudojamų įrankių gebėjimus.

 

5. Veikti pagal skirtingus rezultatus

 

Jei originalios ir mutavusios programos išvestys skiriasi, kaip tikisi testuotojai, tai reiškia, kad testavimo atvejis gali sėkmingai sunaikinti mutantą, parodydamas jo buvimą.

Tuomet testuotojai gali pasitikėti savo metodika ir gebėjimu nustatyti kodavimo problemas. Šiems konkretiems bandymams nereikia keisti bandymų atvejų.

 

6. Jei reikia, pakeiskite dėklus

 

Dėl kai kurių kodo mutacijų skirtingose programose gali būti daromos vienodos išvados, o tai rodo, kad testavimo atvejais neįmanoma sėkmingai išryškinti visų galimų programos klaidų.

Tokiais atvejais mutantas lieka „gyvas” ir gali toliau daryti poveikį programinei įrangai taip, kad testavimo specialistai neturi galimybių jo išspręsti – tai padeda sukurti geresnius testavimo atvejus.

 

Kaip sukurti mutavusias programas

Mutavusios programos iš esmės yra identiškos originalioms programoms, išskyrus vieną nedidelį pakeitimą, kuris gali turėti nedidelės, bet pastebimos įtakos programos veikimui.

Išsamūs ir detalūs testavimo atvejai padeda testuotojui ar programinės įrangos rinkiniui tiksliai nustatyti šiuos pakeitimus ir jų sukeltas klaidas. Kiekvienu atveju, kurį tikrina bendrovė, reikia ir originalios, ir mutavusios programos, kad būtų galima atskirai parodyti kiekvieno pakeitimo poveikį.

Programos paprastai atkartoja realias klaidas, pavyzdžiui, kodavimo klaidas. Taip pat svarbu, kad testuotojai vengtų „dar negimusių” mutantų, kurie neleidžia programai veikti – testuotojams tai pernelyg akivaizdu.

 

Ką keisti mutantinėje programoje?

Kas yra apkrovos testavimas?

Kaip ir daugelio programinės įrangos testavimo kintamųjų atveju, tikslūs testuotojų atliekami pakeitimai priklauso nuo programos ir jos kodo.

Yra trys kategorijos, apimančios daugumą mutacijos testų: operandai, išraiškos ir teiginiai. Pakeitus bet kurią iš jų, galima sukurti veiksmingą mutavusią programą – taip parodoma, kaip skirtingos reikšmės ar taisyklės veikia pačią programos logiką.

Šios kategorijos susijusios su trimis pagrindiniais mutacijų tipais, kuriuos tiria testeriai; tai atitinkamai sprendimo, vertės ir teiginio mutacijos. Pakeitimai turi būti nedideli ir neturi visiškai trukdyti atlikti testą.

 

Geriausia mutacijų tyrimo praktika

Kas yra vieneto testavimas

Atliekant mutacijos testavimą programinės įrangos testavimo kontekste, verta laikytis tam tikros praktikos, kuri užtikrina gerus rezultatus, pvz:

 

1. Maksimizuoti mutacijos rezultatą

 

Programos mutacijos rezultatas – tai mutantų, kuriuos komanda arba programa gali sėkmingai nustatyti arba „sunaikinti”, procentinė dalis.

Pavyzdžiui, jei mutacijų testavimo raunde yra 40 mutacijų, o testuotojai randa 36, mutacijos rezultatas yra 90 % – komandos tikslas visada yra užtikrinti, kad rezultatas būtų 100 %.

 

2. Atsitiktine tvarka pasirinkite mutantus

 

Tai gali padėti nustatyti tam tikrų komponentų prioritetus ir kruopščiau juos išbandyti, tačiau testuotojams taip pat naudinga atsitiktine tvarka pasirinkti, kuriuos mutantus pridėti, ypač per trumpą terminą.

Jei šie patikrinimai atspindi visas svarbiausias mutacijų rūšis, kokybės užtikrinimo komanda gali patvirtinti bendrą programinės įrangos testavimo strategiją.

 

3. Nedideli pakeitimai

 

Kodo mutacijos turėtų būti nedideli nukrypimai nuo pradinės programos, nes tai parodo, kaip tikėtina, kad testuotojas nustatys tam tikras klaidas; nedidelės kodavimo problemos taip pat parodo, kokia jautri yra jų programinė įranga.

Labai svarbu, kad mutacijų testavimo specialistai rastų pusiausvyrą, kuri leistų, kad šie nedideli pakeitimai vis tiek sukeltų pastebimų klaidų.

 

4. Viena mutacija vienai programai

 

Atliekant mutacijos testavimą nagrinėjami atskiri testavimo atvejai, siekiant patikrinti, ar jie yra išsamūs. Kad būtų lengviau tai padaryti, kiekviena mutavusi programa turėtų turėti tik vieną pakeitimą, palyginti su originalu.

Programų su keliomis mutacijomis gali nepavykti veiksmingai susieti su testavimo atvejais; mutacijos gali prieštarauti viena kitai.

 

5. Atidžiai apsvarstykite automatizavimo programinę įrangą

 

Įmonės dažnai naudoja kodo mutaciją, kad patvirtintų, kaip komanda naudoja automatizavimo programinę įrangą, ir įsitikintų, kad ji gali nustatyti klaidas taip pat efektyviai, kaip ir žmogus testuotojas.

Tai reiškia, kad labai svarbu pasirinkti tinkamą automatizavimo platformą, taip pat galimybę integruoti robotizuotą procesų automatizavimą.

 

6. Naudokite bandymais pagrįstą kūrimą

 

Testais grindžiamas kūrimas (TDD) – tai specifinis metodas, kurį taikant į testavimo reikalavimus atsižvelgiama kiekviename kūrimo etape.

Tai padeda užtikrinti, kad testavimo atvejai būtų visiškai suderinami su programine įranga – taip ji gali lengvai pereiti mutacijos testus ir sukurti geresnę programą, sinchronizuojamą su kokybės užtikrinimo procesais.

 

Mutacijos testo rezultatų tipai

testavimo kompetencijos centro (TCoE) steigimo privalumai

Mutacijų testai generuoja keletą rezultatų, įskaitant:

 

1. Mutantų programa

 

Mutuojančios programos yra natūralus šių patikrinimų rezultatas; testuotojai jas sukuria, kad atspindėtų dabartinius testavimo atvejus ir problemas, kurias jie padeda aptikti. Programos paprastai skiriasi nuo originalo tik vienu nedideliu, tačiau reikšmingu būdu, kad būtų užtikrintas didesnis patikimumas.

 

2. Gyvas ar miręs mutantas

 

Atlikus bandymus, mutacija arba „žūsta”, arba lieka „gyva” – tai paprasčiausiai reiškia, ar bandytojas (arba jo programinė įranga) sėkmingai nustatė kodavimo problemą, ar ne.

Jei mutantas lieka gyvas, testavimo atvejus gali reikėti rimtai pakeisti.

 

3. Mutacijos testo atvejis

 

Kokybės užtikrinimo komanda naudoja atskirus konkrečiai mutacijai skirtus testavimo atvejus, kurie registruoja informaciją apie savo mutacines programas.

Tai padeda užtikrinti, kad komanda turėtų išsamius kiekvieno patikrinimo dokumentus; šiuose dokumentuose pateikiama išsami informacija apie mutacijas ir jų poveikį programai.

 

4. Mutacijos balas

 

Bet kokio mutacijos tyrimo galutinis tikslas – pasiekti 100 % mutacijos rezultatą, kai bendrovės tyrimo procedūros sėkmingai nustato ir sunaikina kiekvieną mutantą. Jei tai yra mažiau, galima manyti, kad reikia tobulinti testavimo atvejus ir bendruosius procesus, kad būtų galima nustatyti probleminį kodą.

 

Mutacijų testavimo pavyzdžiai

api testavimas ir automatizavimas

Pateikiame tris mutacijų tyrimo pavyzdžius:

 

1. Vertės mutacijos pavyzdys

 

Vertės mutacijos – tai konstantos arba parametro keitimas, kuris gali pakeisti programos ribas. Pavyzdžiui, automatinio kasos aparato programinė įranga gali naudoti maisto produkto svorį jo kainai nustatyti.

Bandytojai gali mutuoti šios programos kodą ir pakeisti svorio parametrus, todėl kiekvienas uncijos ar kilogramo maisto produktas taps daug brangesnis. Bandytojas arba bandymų platforma turėtų sugebėti nustatyti skirtingų verčių poveikį šiai programai.

Kadangi ši klaida keičia vieną iš pagrindinių programinės įrangos funkcijų, testavimo atvejai turėtų pastebėti šią klaidą ir įspėti komandą.

 

2. Sprendimo mutacijos pavyzdys

 

Sprendimų mutacijos apima aritmetinio ar loginio operatoriaus pakeitimą, apvertimą ar kitokį šios programos reagavimo į naudotojo įvestį pakeitimą. Grįžtant prie savitarnos kasos pavyzdžio, šie aparatai gali pažymėti, kad prekė yra netikėtai didelio svorio, galbūt dėl naudotojo klaidos.

Mašinos kodas tai galėtų padaryti priimdamas sprendimą „if (a>b)”, kai „b” atspindi tikėtiną svorį, o „a” – faktinį svorį. Komanda gali pakeisti šią funkciją į „if (a≤b)”, kuri pakeistų kasos reakciją; ji pažymėtų elementą net ir esant numatytam svoriui.

 

3. Pareiškimo mutacijos pavyzdys

 

Pareiškimo mutacijos apima taisyklės arba išvesties keitimą – tai gali būti net visiškas pareiškimų pašalinimas iš programos. Šios mutacijos gali būti labiau pastebimos nei kitos, priklausomai nuo konkretaus teiginio dažnumo; labai svarbu, kad testuotojai teiginį pasirinktų išmintingai.

Pavyzdžiui, savitarnos kasoje gali būti rodomas įspėjimas, jei naudotojas bando įsigyti prekę, kurios amžius ribojamas. Be atitinkamo teiginio mašina gali sugesti arba leisti bet kuriam klientui nusipirkti bet kurią prekę.

Pakeisdami teiginį ir atkreipdami į jį komandos dėmesį, testuotojai gali patikrinti, ar jų metodas atitinka šias problemas.

 

Klaidų ir klaidų, aptiktų atliekant mutacijų testavimą, tipai

zaptest-runtime-error.png

Mutacijų testai dažniausiai atskleidžia problemas pačiame testavimo procese. Atsižvelgdami į tai, pateikiame keletą problemų, kurias gali padėti nustatyti šie patikrinimai:

 

1. Neaiškūs testavimo atvejai

 

Jei atlikus mutacijų analizę nustatomas žemas mutacijų rezultatas (arba net bet koks rezultatas, mažesnis nei 100 %), tai reiškia, kad komandos testavimo atvejai negali atsižvelgti į visas galimas klaidas, kurios gali paveikti taikomąją programą.

Jie gali būti nepakankamai konkretūs arba platūs, kad atitiktų komandos reikalavimus. Šie dokumentai turėtų apimti visas galimybes, su kuriomis komanda gali susidurti bandydama programinę įrangą, kad būtų užtikrintas patikimumas.

 

2. Neapmokyta testavimo komanda

 

Mutacijų testai taip pat gali parodyti komandos gebėjimus, įskaitant tai, kaip gerai jie asmeniškai nustato mutacijas ir kitas klaidas. Jei, nepaisant aiškių ir išsamių testavimo atvejų, jiems nepavyksta aptikti mutantų visose programose, tai gali būti dėl to, kad testuotojai netinkamai taikė šiuos atvejus.

Mutavusios programos gali kelti problemų viso testavimo proceso metu – tai gali būti ir nekvalifikuoti ar neapmokyti testuotojai.

 

3. Netinkama testavimo programinė įranga

 

Jei įmonė, naudodama šias patikras, tikrina savo testavimo platformą, gali paaiškėti, kad programinė įranga negali tiksliai nustatyti ar sunaikinti mutavusio kodo.

Įmonė gali reaguoti tirdama kitus pasirinkimus, kol ras vieną, atitinkantį jos bandomuosius atvejus. Jei automatizavimo programinei įrangai nepavyksta rasti probleminio kodo, greičiausiai bus sunku nustatyti kitas programinei įrangai daromos įtakos turinčias problemas.

 

4. Neoptimizuotas kodas

 

Mutacijų testavimas gali atskleisti jau esamas programinės įrangos problemas. Pavyzdžiui, bandytojai gali bandyti mutuoti kodą, bet patys aptikti kritinių defektų.

Tai dar vienas svarbus programos aspektas, parodantis, kad kodo mutacija duoda naudos ne tik testavimo procese. Kuo daugiau testuotojų bet kokiu būdu tikrina šį kodą, tuo daugiau problemų komanda gali aptikti ir ištaisyti testavimo etape.

 

Bendrosios mutacijos testo metrikos

apkrovos testavimas

 

Pagrindinės mutacijų testų naudojamos metrikos yra šios:

 

1. Nužudyti mutantai

 

Tai reiškia, kiek mutantų pavyko nustatyti testuotojams arba programinei įrangai, pažymint jų egzistavimą, kad darbuotojai galėtų rasti tokius nedidelius trūkumus.

Testuotojų sunaikinamų mutantų kiekis priklauso nuo jų testavimo atvejų stiprumo.

 

2. Gyvi mutantai

 

Gyvi mutantai – tai tie, kurių testuotojas ar programinė įranga neidentifikuoja – tai rodo, kad komandos kokybės užtikrinimo strategijoje gali būti spragų. Jei taip atsitinka, testuotojai turėtų iš naujo suderinti savo procesą ir testavimo atvejus, kad jie atitiktų šiuos mutantus, ir pašalinti juos per būsimus patikrinimus.

 

3. Galiojantys mutantai

 

Šis rodiklis nustato mutacijų, kurias programa galėjo sėkmingai įtraukti be paleidimo klaidos, panaikinančios testą ir jo veiksmingumą, kiekį.

Galiojantys mutantai yra tie, kuriuos testeris ir automatizavimo programinė įranga gali patikrinti; taip yra todėl, kad mutacijos yra palyginti nedidelės.

 

4. Negaliojantys mutantai

 

Reikšmingos mutacijos gali paveikti programą tiek, kad testavimas taptų nepraktiškas ar net neįmanomas, todėl naudinga stebėti, kiek „negaliojančių” mutacijų yra mutavusioje programoje.

Nustatydami šias mutacijas, testuotojai gali jas redaguoti ar net pašalinti ir taip užtikrinti, kad būtų tikrinamos tik galiojančios mutacijos.

 

5. Iš viso mutantų

 

Mutacijų skaičius, neatsižvelgiant į jų pagrįstumą, yra dar vienas rodiklis, kurį stebi testuotojai; taip jie gali stebėti mutantus ir fiksuoti jų būklę.

Kadangi kiekviena mutacija paprastai apima atskirą testą, bendra suma taip pat yra visų kodo mutacijų skaičiaus rodiklis.

 

6. Mutacijos balas

 

Naudingiausia mutacijų analizės metrika paprastai yra mutacijų rezultatas, kuris iš tikrųjų yra galiojančių mutacijų, kurias aptiko testeris arba automatizavimo rinkinys, procentinė dalis.

Bet koks mažesnis nei 100 % aptikimas gali būti netinkamų bandymo procedūrų požymis.

 

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

7 klaidos ir spąstai įgyvendinant mutacinius testus

programinės įrangos testavimo automatizavimo postas

Mutacijų testavimas yra sudėtingas procesas, kurį įmonės turi įgyvendinti protingai, kad išvengtų rimtų problemų ar klaidų. Pateikiame septynis spąstus, kurių testuotojai turėtų stengtis išvengti atlikdami mutacijų testus:

 

1. Netinkamas mutacijos mastelio nustatymas

 

Atliekant mutacijų analizę svarbu atsižvelgti į mastą, nes šis procesas skirtas užtikrinti, kad testuotojai nustatytų nedideles programos klaidas. Jei testuotojams mutacija yra pernelyg akivaizdi, tai gali būti neveiksmingas būdas patikrinti jų gebėjimą pastebėti programinės įrangos problemas arba jas pašalinti.

 

2. Negaliojančios arba gyvos mutacijos

 

Net ir tinkamu mastu daugelis mutacijų yra tik ribotai veiksmingos, pavyzdžiui, jei jos nesukelia gedimo arba sukelia problemą, dėl kurios programa nustoja veikti.

Testuotojai turėtų nepamiršti, kaip bet koks kodavimo pakeitimas gali paveikti visą programinę įrangą.

 

3. Nesuderinami bandymų atvejai

 

Testavimo atvejai ir mutacijos turi puikiai derėti tarpusavyje, kad būtų užtikrintas nuoseklus ir darnus testavimas. Spręsdama, kokias mutacijas pridėti, ar net kurdama pradinius testavimo atvejus, kokybės užtikrinimo komanda gali stengtis užtikrinti, kad jos derėtų tarpusavyje ir apskritai užtikrintų sklandesnį testavimą.

 

4. Terminai ir tvarkaraščiai

 

Testavimo etapai gali būti skirtingos trukmės, tačiau visuomet turi būti laikomasi įmonės vidaus terminų. Įmonės, kurios nesugeba tinkamai suplanuoti mutacijos tyrimų, gali nespėti laiku užbaigti proceso.

Prieš pradėdama projekto testavimo etapą, komanda turi užtikrinti, kad testavimo tvarkaraštis būtų pakankamai išsamus.

 

5. Nepakankama testų aprėptis

 

Įmonės gali rinktis atsitiktinius kodų pakeitimus, tačiau vis tiek svarbu, kad jie apimtų platų klausimų spektrą.

Siekiant užtikrinti, kad testuotojai ir programinė įranga galėtų aptikti visų tipų mutacijas, patikrinimai turėtų apimti bent kelias reikšmių, sprendimų ir teiginių mutacijas.

 

6. Mutantų naudojimas programinei įrangai išbandyti

 

Nors mutacijų testavimas suteikia naują požiūrį į programą, komandos turi naudoti šį metodą tik norėdamos patikrinti savo testavimo procesą. Įmonė turi suprasti tikslias mutacijų testavimo galimybes ir apribojimus; šis metodas gali būti sėkmingas tik kartu su kitomis programinės įrangos patikromis.

 

7. Per daug mutantų

 

Labai svarbu, kad įmonės užtikrintų plačią bandymų aprėptį, tačiau šiame procese jos gali įdiegti per daug mutantų. Kiekvienai mutacijos programai reikia nemažai skaičiavimo galios – tai riboja, kiek jų organizacija gali atlikti vienu metu.

Vykdant per daug mutacijų taip pat gali būti sunkiau laikytis testavimo terminų.

 

Mutacijų testavimo kontrolinis sąrašas, patarimai ir gudrybės

Programinės įrangos testavimo kontrolinis sąrašas

Yra keletas papildomų patarimų, kurie gali padėti bet kuriai komandai pagerinti mutacijų testavimo proceso sėkmę, pvz:

 

1. Patikrinkite programavimo kalbos suderinamumą

 

Tiek nemokami, tiek mokami mutacijų testavimo įrankiai paprastai specializuojasi vienoje kodavimo kalboje, todėl svarbu, kad testuotojai pasirinktų įrankį, suderinamą su programa ir programinės įrangos testavimo platforma.

Testavimo komanda turėtų išnagrinėti daugybę galimybių, kad įsitikintų, jog naudoja programą, atitinkančią jų biudžetą ir pageidaujamą kodavimo kalbą.

 

2. Išmintingai paskirstykite testus

 

Skirtingi testavimo grupės nariai tikriausiai nagrinės skirtingus programos aspektus, paprastai atsižvelgdami į savo stipriąsias ir silpnąsias puses bei bendrą patirtį.

Kai komanda kiekvienam testuotojui paskiria mutacijos testus, ji turėtų tai turėti omenyje, kad sužinotų, koks yra jų gebėjimas; tai parodo, kaip seksis atlikti tolesnius testus.

 

3. Atidžiai pasirinkite gedimus

 

Jei naujausioje programinės įrangos iteracijoje pasitaikė klaida, susijusi su verte ar teiginiu, gali būti naudinga ją pakartoti ir ištirti, kaip reaguoja komanda ar programa.

Tai padeda užtikrinti taikomosios programos ilgaamžiškumą ir parodo komandos gebėjimą pastebėti ankstesnes klaidas, jei jos pasikartotų – tai yra pagrindinė regresijos testavimo sudedamoji dalis.

 

4. Maksimaliai padidinti skaičiavimo galią

 

Kadangi mutacijos patikroms atlikti gali prireikti daug skaičiavimo galios, tai padeda maksimaliai išnaudoti įmonės techninę įrangą.

Pavyzdžiui, jei tam tikrų įrenginių specifikacijos yra griežtesnės, gali būti naudinga paleisti mutantus šiuose įrenginiuose. Tai leidžia įmonei išvengti didelių vėlavimų, kuriuos galėtų sukelti lėtesnės mašinos.

 

5. Neatmeskite gyvų mutacijų

 

Net ir laikydamiesi griežto tvarkaraščio, testuotojai turėtų stengtis keisti ir plėsti savo testavimo atvejus, kad būtų galima kovoti su bet kokiais mutantais, kurie išlieka procese.

Nors šios klaidos gali atrodyti nereikšmingos, jei programinė įranga ar testuotojas jų neatskleidžia, vis dėlto jos rodo, kad testavimo atvejais nepavyko nustatyti visų kodavimo problemų.

 

6. Ištirti naują automatizavimo programinę įrangą

 

Jei komandos testavimo atvejai yra pakankamai išsamūs, tačiau jų automatizuotas testavimo rinkinys negali sėkmingai jais pasinaudoti ir nustatyti kiekvienos mutacijos, jiems gali būti naudinga kita programinė įranga.

Yra daug nemokamų ir mokamų platformų, todėl įmonės turėtų patikrinti visas galimybes, kad įsitikintų, jog turi programinę įrangą, kuri geriausiai tinka jų ilgalaikiams bandymams.

 

7. Sinchronizuokite kiekvieną testavimo procesą

 

Bendradarbiavimas yra pagrindinė kiekvienos testavimo strategijos sudedamoji dalis – tai padeda užtikrinti, kad kiekvienas procesas lengvai derėtų tarpusavyje taip, kaip komanda ketina.

Pavyzdžiui, testavimo komanda galėtų kurti testavimo atvejus atsižvelgdama į mutaciją, kad būtų užtikrintas didesnis suderinamumas ir testuotojams būtų lengviau patvirtinti savo strategiją.

 

8. Naudokite vieneto testavimą

 

Vieneto testavimas leidžia kokybės užtikrinimo komandai tikrinti atskirus kodo fragmentus, taip gerokai supaprastinant testus ir palengvinant komandoms nustatyti problemas.

Šis derinys gali būti ypač naudingas, jei testuotojai nerimauja dėl galutinių terminų, nes suteikia jiems galimybę supaprastinti patikrinimus ir pagerinti bendrą aprėptį – taip sukuriami daug stipresni programinės įrangos testai.

 

9. Rašyti išsamius testavimo atvejus

 

Mutacijų testavimo atvejuose turėtų būti pateikta tinkama informacija apie mutaciją ir jos poveikį programai, taip pat apie tai, kaip testavimo komanda ar platforma nustatė šias klaidas.

Pateikdamas kuo daugiau detalių, testuotojas gali asmeniškai patvirtinti testavimo atvejį ir įsitikinti, kad komanda tiksliai žino, kaip užtikrinti sklandų testavimą.

 

5 geriausi mutacijų testavimo įrankiai

 

 

Yra daugybė įrankių, kurie gali padėti įmonėms atlikti mutacijų testavimo reikalavimus. Kaip dažnai būna su programinės įrangos testavimo programomis, skirtingų platformų kainos ir funkcijos skiriasi, todėl labai svarbu, kad organizacijos pasirinktų geriausiai jų poreikius atitinkančią platformą.

Kai kurios iš šių programų gali būti nemokamos arba visiškai atviro kodo; tačiau už didesnį patogumą paprastai reikia mokėti.

 

Atsižvelgdami į tai, pateikiame penkias geriausias mutacijų tyrimo priemones.

 

1. Stryker

 

„Stryker” specializuojasi „JavaScript” mutacijų srityje, gerokai supaprastindama šį procesą, kad būtų išvengta klaidingai teigiamų rezultatų ir sumažėtų bendras pastangų kiekis, kurį testuotojams tektų įdėti atliekant visas mutacijų patikras.

„Stryker” platforma protingai įvertina programinę įrangą ir, naudodama surinktą informaciją, nustato kodo eilutes ar segmentus, kuriuos būtų naudinga mutuoti. Šioje programoje yra aiškaus teksto pranešėjas, kuris pateikia mutanto santrauką, įskaitant informaciją, ar Strykeriui pavyko jį nužudyti.

 

2. PITest

 

PITest yra labai populiarus visame pasaulyje, nes gali keisti „Java” baitų kodą ir atlikti tūkstančius mutacijų per sekundę. Ši programa naudoja testavimo atvejų aprėpties duomenis, kad iš karto sužinotų, kurie testai gali nužudyti mutantą.

Ji atlieka tik tuos testus, kurie, kaip ji žino, bus svarbūs, taip apribodama skaičiavimo galią, kurią paprastai sunaudoja ši procedūra. PITest taip pat yra suderinamas su daugeliu „Surefire” vienetų testavimo įskiepio formų, tačiau gali būti sunku veiksmingai valdyti testų užsakymų priklausomybes.

 

3. Apdrausti++

 

„Insure++” turi daugybę testavimo galimybių, įskaitant mutacijų analizę, leidžiančią platformai pastebėti dviprasmybes programoje. „Insure++”, nukrypdama nuo įprastinio mutacijų testavimo, negeneruoja klaidingų mutantų, o sukuria funkciškai lygiavertes mutacijas, atitinkančias projekto pirminį kodą.

Taip siekiama išvengti netiesioginių prielaidų, kurios gali netyčia apriboti testavimo procesą ir neatspindėti realios testavimo aplinkos. Kaip matyti iš pavadinimo, ši platforma daugiausia suderinama su C++ programomis, o visos funkcijos pritaikytos šiai kalbai.

 

4. Džemperis

 

Ši programa specializuojasi „JavaScript” sistemoje „JUnit” ir turi išsamius vaizdinius rodiklius, rodančius, kaip kodas reaguoja į mutacijų analizę. „Jumble” yra atvirojo kodo platforma, veikianti „Java” programų baitų kode ir leidžianti sutrumpinti kiekvieno testavimo ciklo laiką.

Panašios programos, kurios naudoja tik programos pirminį kodą, kartais gali užtrukti ilgiau, kol atliks šiuos patikrinimus, nes jas reikia iš naujo kompiliuoti.

Be to, „Jumble” naudoja euristiką, kad dar labiau optimizuotų mutacijų testavimą ir supaprastintų vėlesnius testus.

 

5. MutPy

 

„MutPy” palaiko mutacijų testus „Python” programoms ir siūlo visapusišką aukštosios eilės mutacijų palaikymą bei išsamią aprėpties analizę. Šios programos sąsaja lengva naudotis išvesties etape, kurioje aiškiai matoma kiekviena esminė komandos mutacijos testų detalė.

„MutPy” testuotojams siūlo daug individualių pasirinkimų, todėl jie gali šią programinę įrangą pritaikyti pagal savo reikalavimus. Platformoje naudojami abstraktūs sintaksės medžiai, kurie suteikia aiškią programos šaltinio kodo struktūrą, todėl testuotojai gali labiau pasitikėti savo mutacijomis.

 

Išvada

Kodo mutacija gali būti taikoma beveik bet kokiame programinės įrangos testavimo procese, o šį metodą įdiegusioms įmonėms suteikia daug akivaizdžios naudos, ypač ankstesniame kokybės užtikrinimo etape.

Nė viena metodika neapsieina be iššūkių; tai reiškia, kad organizacijoms būtina protingai apsvarstyti mutacijų analizės privalumus ir užtikrinti, kad ji atitiktų įprastą programinės įrangos kūrimo tvarkaraštį.

Šios mutacijos suteikia testavimo komandoms galimybę patikrinti savo metodus ir nustatyti jų veiksmingumą ieškant ir taisant pradinio kodo klaidas. Šis metodas ypač suderinamas su automatizavimo procedūromis, todėl įmonės gali patvirtinti programinę įrangą, kuria jos pasitiki, kad ji tvarkytų jų patikrinimus.

Mutacijų testavimas – tai išsamus būdas kokybės užtikrinimo komandoms geriau suprasti savo procesus ir programinę įrangą, įskaitant problemas, kurių kitu atveju jos neaptiktų.

Todėl labai svarbu, kad testavimo komandos atidžiai išnagrinėtų šį metodą ir įvertintų, ar jis atitinka organizacijos poreikius, įskaitant tai, ar pasirinkta mutacijos priemonė visiškai suderinama su jų programavimo kalba. Automatizuoto testavimo programinė įranga ZAPTEST pasižymi daugeliu funkcijų, leidžiančių atlikti mutacijos testus, todėl komandos gali visiškai pasitikėti jos galimybėmis.

Tiek nemokamoje, tiek verslo versijoje siūlomas aukštos kokybės testavimo procesas, kuriame galima lengvai pritaikyti kodo mutacijas.

 

DUK ir ištekliai

1. Geriausi mutacijų testavimo kursai

 

Internetiniai kursai gali padėti pradedantiems testuotojams išmokti kodo mutacijos pagrindų arba sustiprinti jau turimus patyrusių kokybės užtikrinimo darbuotojų įgūdžius. Bendrosios programinės įrangos testavimo pamokos taip pat gali būti naudingos testuotojams. Geriausi internetiniai kursai mutacijų testuotojams:

– „PluralSight” straipsnyje „Mutacijų testavimas „Java” naudojant PITest” konkrečiai nagrinėjama, kaip keisti „Java” kodą ir kaip šis metodas galėtų būti naudingas praktiniams programinės įrangos testavimo procesams.

– „Udemy” „The Complete 2023 Software Testing Bootcamp” – tai ypač aktualus kursas, kuriame iliustruojami visi pagrindiniai programinės įrangos testų komponentai, įskaitant „baltosios dėžutės” testavimą.

– Alison „Programinės įrangos testavimas – sąlygų aprėptis ir mutacijų testavimo strategijos” yra nemokama ir joje išsamiai nagrinėjama, kaip išmintingai įgyvendinti mutacijų testavimą.

– PluralSight „Unit Testing Fundamentals” nagrinėja vienetų testavimo privalumus ir funkcijas, padeda užtikrinti, kad mokiniai suprastų, kaip tiksliai rašyti stiprius vienetų testus.

– „Udemy” „Įvadas į vienetinį testavimą” – tai dar vienas nemokamas kursas, kuriame aiškiai išdėstytas vienetinis testavimas ir testais pagrįstos kūrimo strategijos svarba.

 

2. Kokie yra 5 svarbiausi interviu klausimai apie mutacijų testavimą?

 

Yra keletas klausimų, kuriuos įmonės gali užduoti kandidatams per pokalbį, kad patikrintų jų patirtį ar supratimą apie mutacijų testavimą ir jo pagrindinius principus. Tai leidžia įmonei įsitikinti, kad ji samdo kvalifikuotą testuotoją, kuris gali lengvai spręsti įvairius su mutacijomis susijusius scenarijus.

Tikslūs klausimai gali būti įvairūs, tačiau gali būti prašoma pateikti savo nuomonę arba kodo mutacijos įgūdžių pavyzdžių.

 

Penki svarbiausi interviu dėl mutacijų testavimo klausimai:

 

– Su kokiomis mutacijų testavimo priemonėmis turite patirties, jei turite? Kokios buvo pagrindinės šios programinės įrangos savybės?

– Kaip bandydami atlikti kodo mutaciją užtikrintumėte tinkamą pusiausvyrą tarp testavimo greičio ir išsamumo?

– Kokiais atvejais mutacijų analizė būtų neįmanoma? Kaip tikrintumėte testavimo procedūrą pagal šiuos scenarijus?

– Jei vertės mutacijai pavyktų išgyventi testavimo procesą, kokių veiksmų imtumėtės, kad tai nepasikartotų?

– Kokią informaciją įtrauktumėte į mutacijos testo atvejį, kad užtikrintumėte, jog jūsų kolegos gautų reikiamus duomenis?

 

3. Geriausi „YouTube” vadovėliai apie mutacijų testavimą

 

„YouTube” galima rasti nemokamų pamokų, internetinių seminarų ir kitų vaizdo įrašų, kurie padės testuotojui geriau suprasti mutacijų tyrimus. Keletas naudingiausių vaizdo įrašų ir serijų šia tema:

 

– „Programinės įrangos testavimas”, kuriame pateikiama praktinių pavyzdžių, kaip kodo mutacijos padeda programoms, ir kaip rašyti išsamius testavimo atvejus.

– „Devoxx” „Mutacijų testavimas: Ar mano testas sugadino mano kodą?”, kuriame nagrinėjama, kaip mutacijų analizė pagerina bendras visų rūšių programinės įrangos projektų testavimo procedūras.

– NDC konferencijos „Nužudyk visus mutantus! Intro to Mutation Testing”, kurioje nagrinėjama, kaip testavimo rinkiniai gali pasinaudoti kodo mutacijomis ir jų padedamomis sukurti klaidomis.

– GOTO konferencijos „Mutation Testing in Python”, kurioje nagrinėjama, kaip „Python” programose galima taikyti mutacijų analizę siekiant konkrečių testavimo tikslų.

– Diego Pacheco „Java Mutation Testing With PITest”, kuriame panašiai iliustruojama, kaip „JavaScript” programinė įranga naudoja kodo mutaciją, daugiausia dėmesio skiriant „PITest” mutacijos programai.

 

4. Kaip išlaikyti mutacijų testus?

 

Derindamos mutacijų analizę su regresijos testavimu ir kitomis ilgalaikėmis strategijomis, įmonės gali užtikrinti aukštus kokybės užtikrinimo standartus net ir po išleidimo.

Vėlesni atnaujinimai gali lemti kodo pakeitimus, dėl kurių reikia atlikti tolesnius patikrinimus. Mutacijos testavimas parodo, kad automatizavimo programinė įranga ir testuotojai yra nuoseklūs skirtingose tos pačios programinės įrangos versijose, taip dar kartą patvirtindami savo konkretų požiūrį.

Naujoms funkcijoms reikia naujų testavimo atvejų, ypač jei šios funkcijos sąveikauja su jau egzistuojančiomis funkcijomis.

Be to, naudojant bandymais pagrįstą kūrimą komandos nariai gali planuoti programinės įrangos ilgaamžiškumą ir išbandyti jos suderinamumą, nes tai yra jos kūrimo ciklo dalis.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post

Virtual Expert

ZAPTEST

ZAPTEST Logo