Mutatsioonitestimine ehk programmi mutatsioon on valge kasti testimise tehnika, mis aitab ettevõtetel arendada erinevaid uusi tarkvarakontrolle, auditeerides samal ajal ka projekti praeguseid protsesse. See on suhteliselt uus lähenemisviis, mis tagab, et nii arendajad kui ka testijad töötavad kõrgetasemeliselt.
Rakendus on ainult nii edukas või hea kui selle kvaliteedi tagamise menetlused – see tähendab, et organisatsioonidel on oluline kasutada rohkem kui ühte tüüpi testimistehnikat.
Mutatsioonitestimise tundmaõppimine võib aidata testimismeeskondadel suurendada oma oskusi ja üldist repertuaari, mis võimaldab neil parandada nende kontrollide usaldusväärsust. Mutatsioonitestimine on keeruline ja tundlik protsess, mistõttu on oluline, et testijad uuriksid põhjalikult kasu, probleeme ja kolmanda osapoole programme, mis võivad tagada eduka rakendamise.
Selles artiklis vaatleme mutatsioonitestimist ja seda, kuidas see parandab kvaliteedi tagamist, ning muid olulisi kaalutlusi tarkvara testimismeeskondade jaoks.
Mis on mutatsioonitestimine tarkvara testimisel?
Tarkvara kontekstis tähendab mutatsioonitestimine seda, et kvaliteedi tagamise meeskond lisab tahtlikult vigu ehk “mutatsioone” rakenduse koodi, et näha, kuidas meeskond reageerib. Eesmärk on tekitada viga ja veenduda, et testimise komplekt suudab tuvastada iga muudatuse rakenduses.
Programmi koodi redigeerimisel võib mutatsioonitestija vahetada tõene/vale väljendit, kustutada avaldise või lihtsalt muuta väärtust. Need vead võivad ilmneda mitmel viisil muude tarkvarakontrollide käigus; kõik need on kvalifitseeritud ja kogenud testimismeeskonna poolt kergesti avastatavad.
Mutatsioonid ise on sageli väga väikesed, mis võimaldab koodi muteerival testijal jälgida, kuidas meeskond neid muudatusi avastab. Olulised muudatused oleksid ilmselged isegi pealiskaudsel pilgul – seega on väiksemad vead tavaliselt parim viis tagada, et ettevõte rakendab kindlaid testimistavasid.
Selle meetodiga vaadeldakse konkreetselt meeskonna testjuhtumite tõhusust, st dokumente, mis sisaldavad testimise teavet. Meeskond võib nende kontrollide teostamiseks kasutada ka kolmanda osapoole automatiseerimistarkvara, mille puhul vaadeldakse, kui hästi suudab see platvorm tuvastada vead programmi koodis.
1. Millal on vaja teha mutatsioonikatsetusi?
Kuna mutatsioonitestimise eesmärk on valideerida ja parandada praegust kvaliteedikontrolli, on oluline, et meeskonnad viiksid selle läbi testimise varases etapis. See tähendab, et kui testimise pakett ei suuda mutante tuvastada ja “tappa”, on piisavalt aega, et teha organisatsiooni testimisprotseduurides ulatuslikke muudatusi.
Kuna tegemist on väga mitmekülgse meetodiga, on mutatsioonitestimine rakendatav praktiliselt igasuguse tarkvara, sealhulgas veebi-, mobiil- ja lauaarvutiprogrammide puhul. See toimib kõige paremini ühiktestimise etapis, kus uuritakse rakenduse kõige väiksemaid komponente.
2. Kui te ei pea tegema mutatsioonitestimist.
On veel mõned stsenaariumid, kus mutatsioon ja üldine valge kasti testimine ei ole programmi jaoks sobivad; see võib olla tingitud erinevatest põhjustest.
Näiteks kui testijate eesmärk on kontrollida ainult musta kasti testimist – sellisel juhul keskenduksid nad selle seansi puhul hoopis esiosa või isegi üldise testimise etapile.
Mõned ettevõtted peavad valge kasti testimist tüütuks ja aeganõudvaks, mistõttu võivad nad selle protsessi vahele jätta. Tugevad, hästi kontrollitud testjuhtumid võivad samuti vältida mutatsioonitestimise vajadust, kuna see näitab meeskonna hoolsust ja pühendumust täpsetele testimisprotseduuridele.
3. Kes osaleb mutatsioonianalüüsis?
Mutatsioonianalüüsis on mitmeid erinevaid rolle, sealhulgas:
– Mutatsiooni testijad
Nad muudavad koodi, lisades erinevaid väiksemaid vigu, et tagada, et testimisprotsess töötab ootuspäraselt. Need testijad on tavaliselt juba olemasolevad kvaliteedi tagamise meeskonna liikmed.
– Rakenduse testijad
Nad kontrollivad koodi regulaarselt probleemide suhtes, tuvastavad ja parandavad kõik leitud mutatsioonid. Nad viivad läbi valge kasti testimist, et leida kodeerimisvigu, kuid kasutavad ka muid meetodeid.
– Rakenduse arendajad
Nad kavandavad programmi funktsioone ja kirjutavad algse koodi. Nad parandavad ka kõik probleemid, mida testijad leiavad, tagades, et tarkvara on väljalaskmiseks stabiilses seisukorras.
– Projektijuhid
Nad pakuvad suuniseid taotluse kohta ja võivad töötada koos mutatsioonitestijatega, et näha oma meeskonna tõhusust. Nad tagavad ranged standardid igas arenguetapis.
Mida me testime mutatsioonitestidega?
Mutatsioonitestimine keskendub pigem protsesside kui rakenduse testimisele. Selleks uuritakse järgmist:
1. Testjuhtumid
Testjuhtumid on dokumendid, mis sisaldavad üksikasjalikku teavet iga testi kohta, sealhulgas tulemused, mida testijad igalt üksikult kontrollimiselt ootavad. Järjepidevad ja täpsed testjuhtumid annavad QA meeskonnaliikmetele ettekujutuse rakenduse seisundist ja sellest, kuidas selle jõudlus vastab ettevõtte ootustele.
Nendes testjuhtumites sisalduv teave võib määrata testija võime tuvastada teatud defekte – sealhulgas neid, mida mutatsioonitestimine põhjustab.
2. Katsestandardid
Mutatsioonitestid uurivad tähelepanelikult praeguseid testimisprotseduure, et meeskonnaliikmed saaksid tuvastada isegi väiksemaid probleeme, mis võivad mõjutada kasutaja arusaama tarkvarast.
Testijate hoolsus ja pädevus võivad olla isegi peamised tegurid, mida ettevõte nende kontrollide abil hindab. Kui igas etapis ei pöörata suurt tähelepanu üksikasjadele, võivad testijad programmis esinevad tõsised mutatsioonid kahe silma vahele jääda.
3. Üksikud koodiühikud
Mutatsioonitestid on levinud arenduse ühiktestimise käigus. See vaatab üksikuid komponente, et säilitada tugevat keskendumist igale testile, optimeerides märkimisväärselt kogu protsessi, tagades, et testijad töötavad ainult asjakohaste koodiridadega.
Kuna mutatsioonitestid on sageli kvaliteedi tagamise etapis varajases etapis ja võivad olla täieliku testimise eelkäijaks, võib selline lähenemisviis suurendada kiirust, ilma et see kahjustaks täpsust.
4. Programmi uuendused
Tarkvarauuendused hõlmavad tavaliselt testimise taaskäivitamist, et veenduda, et uusi vigu ei ole ja et varasemad vead ei ilmne uuesti.
Mutatsioonitestide kordamine on selle oluline osa ja aitab edendada järjepidevaid testimisstandardeid pärast suuremaid tarkvaramuutusi.
Testimismeeskond võib pidada põhjalikku uuendamisjärgset kontrolli mittevajalikuks, kuid koodimutatsioon võib tagada, et nad mõistavad testimise olulisust igas arendusetapis.
5. Automaatika tarkvara
Ettevõtted viivad läbi ka mutatsioonitestimist, et kontrollida oma automatiseeritud testimisviise ja veenduda, et nad suudavad muu hulgas märgata muteerunud koodi.
Kui kolmanda osapoole testimisrakendus suudab tuvastada programmi väliseid muudatusi ja potentsiaalselt isegi parandada seda, tähendab see, et organisatsioon võib testide automatiseerimisel tarkvara usaldada.
On oluline, et ettevõtted valideeriksid oma automatiseerimise lähenemisviisi; see annab igale testijale meelerahu.
6. Automatiseerimise strateegia
See, kuidas ettevõte integreerib automatiseerimise oma protsessidesse, on sama oluline kui tarkvara, mida ta kasutab; näiteks võib ta otsustada rakendada hüperautomaatikat. See võimaldab ettevõttel arukalt otsustada, milliseid mutatsiooni- ja tarkvarateste automatiseerida.
Ilma tugeva automatiseerimisstrateegiata, mis arvestab rakenduse koodis esinevat suurt mitmekesisust, võivad mõned testid olla automatiseerimisega kokkusobimatud, mis piirab platvormi võimeid.
7. Taotlus
Kuigi mutatsioonitestimine keskendub rohkem testimismeeskonnale kui rakendusele, võib see siiski tuua esile olulist teavet selle programmi kohta.
Näiteks näitab mutatsioonitestimine, kuidas tarkvara reageerib koodis tehtavatele muudatustele, sealhulgas seda, kas see näitab neid probleeme nii, nagu meeskond ootab.
See lähenemisviis ei ole tarkvara testimise meetod, kuid suudab siiski pakkuda huvitavaid andmeid selle sisemise toimimise kohta.
Mutatsioonitestide elutsükkel
Mutatsioonitestimise tavapärane elutsükkel on järgmine:
1. Nõuete analüüs
Iga mutatsioonitestimise elutsükli esimene samm on välja selgitada, mis täpselt vajab valideerimist ja millised rakenduse koodi osad saaksid nendest testidest kõige rohkem kasu.
Meeskond võib vestelda arendajate ja juhtidega, et teha kindlaks nende mured ja alustada nende lahendamist.
2. Testi planeerimine
Seejärel hakkavad testijad välja töötama täpseid kontrolle, mida nad kavatsevad rakendada – antud juhul mutatsioone, mis annavad parima ülevaate.
Selles etapis määratakse kindlaks üldine mutatsioonitestimise strateegia ja see, kuidas meeskond kavatseb kavandatud koodimutatsioonid tõhusalt rakendada.
3. Testjuhtumite väljatöötamine
Mutatsioonitestimine hõlmab oma eraldi testidokumentatsiooni, mis sisaldab teavet muteeritud koodi kohta ja seda, kuidas testijad peaksid probleemi parandama.
Hea arvestuse pidamine tagab, et kõik testid kulgevad plaanipäraselt, ja aitab meeskonnal säilitada oma pühendumust kõrgetele testimisstandarditele.
4. Testkeskkonna seadistamine
Testijad veenduvad, et rakendus on nende jaoks muutuste tegemiseks valmis – ja et neil on menetlus nende probleemide lahendamiseks, kui teised meeskonnaliikmed ei suuda neid tuvastada.
Selle osana loovad mutatsioonitestijad testiserveri ja kasutavad seda oma mutatsioonide jaoks.
5. Testide läbiviimine
Pärast ettevalmistusi muudavad testijad koodi mitmes rakenduse komponendis; seejärel ootavad nad, et teised testijad märkaksid ja parandaksid probleemid.
Nii mutatsioonitestijad kui ka rakenduste testijad peavad seda põhjalikult dokumenteerima, et nende andmed oleksid usaldusväärsed.
6. Katsetsükli lõpetamine
Kui testimine on lõppenud, kontrollivad mutatsioonitestijad veel kord, et kõik tehtud muudatused on parandatud kas rakenduse testijate või nende endi poolt.
Seejärel lõpetavad nad testitsükli ja analüüsivad tulemusi, arutades, kuidas testijad reageerisid erinevatele vigadele ning kuidas nad suutsid neid parandada.
7. Katse kordamine
Pärast testitsükli sulgemist võib olla vaja see pärast tulevasi tarkvarauuendusi uuesti aktiveerida.
Iga rakenduse muutmine muudab mingil viisil selle funktsionaalsust, mille tulemuseks on uued võimalused, mida meeskond peab arvesse võtma, et tagada, et nende testimisprotsess on piisavalt põhjalik.
Mutatsioonitestimise eelised
Mutatsioonitestide tegemisest on palju kasu, sealhulgas:
1. Valideerib testimisprotsessi
Mutatsioonitestimise peamine eelis on selle võime näidata, kuidas ettevõtte testijad tarkvarale lähenevad – ja nende võimet tuvastada kodeerimisprobleeme. See tagab ka, et meeskonna testjuhtumid on piisavalt põhjalikud ja hõlmavad kõiki vajalikke teste.
Mutatsioonitestid uurivad organisatsiooni üldist testimismenetlust, et tagada selle toimimine ootuspäraselt.
2. Tagab tugeva automatiseerimise
Mutatsioonitestimine aitab meeskonnal kontrollida, kas nende kolmanda osapoole testide automatiseerimisplatvorm suudab koodis olevad vead piisavalt tuvastada ja neid õigesti käsitleda.
Kui see tarkvara ei suuda neid isegi pärast vajalikku kalibreerimist tuvastada, võib tasuks platvormi vahetada sellise vastu, mis neid teste hõlpsasti läbib.
3. Hea katvus
Iga tarkvara testimise protsess peab suutma hõlmata kogu rakendust, et tagada, et igale aspektile pööratakse vajalikul määral tähelepanu.
Mutatsioonitestid võivad muuta mis tahes osa programmi koodist; hea rakendamine võimaldab neil testidel hõlmata kõiki olulisi funktsioone. See õpetab testijaid otsima probleeme kogu rakenduses.
4. Uurib lähtekoodi
Kuna mutatsioonitestimine hõlmab tööd koodiga ja vajaduse korral otseste muudatuste tegemist, võib see meetod rõhutada ka rakenduses olevaid optimeerimata skripte.
Tarkvara testijad võivad programmi heaks kiita ja oma tavalise testimisvooru läbi viia ainult siis, kui tarkvara kood on piisav; need kontrollid võimaldavad testijatel tuua esile võimalikke tulevasi probleeme.
5. Viib parema tarkvarani
Mutatsioonitestimine aitab veenduda, et rakenduse testimisprotsessid vastavad programmi nõuetele.
Kui mutatsioonianalüüs näitab, et kvaliteedi tagamise meeskond ei järgi õigeid protseduure või testjuhtumid on ebapiisavad, saavad testijad töötada selle parandamise nimel. Ilma sellise hoolsuskohustuseta võib organisatsioon anda välja vigase toote, ilma et ta sellest aru saaks.
6. Efektiivne erinevate keelte puhul
Olenemata sellest, millist keelt testimismeeskond oma rakenduses kasutab, on olemas tarkvaravõimalused, mis pakuvad kvaliteetset mutatsioonianalüüsi.
See hõlmab mitmeid keelele omaseid kvaliteedifunktsioone, mis ühtlustavad kontrollide läbiviimist suurema usaldusväärsuse saavutamiseks. Erinevate keelte jaoks kohandatud lähenemisviis parandab iga üksiku testi kvaliteeti.
7. Hästi kättesaadavad tööriistad
Paljud parimad mutatsiooniplatvormid on täielikult avatud lähtekoodiga – see tähendab, et nad pakuvad rohkem kohandusi ja ulatuslikke funktsioone tasuta või oluliselt madalamate kuludega.
Võrreldes paljude teiste testimisviisidega on koodimutatsioon kasulik ja mugav viis, kuidas ettevõtted saavad hinnata või isegi parandada oma kvaliteedi tagamise lähenemisviisi.
Mutatsioonitestimise väljakutsed
Selle protsessiga kaasnevad ka mitmed probleemid, näiteks:
1. Nõuab programmeerimisalaseid teadmisi
Selleks, et testijad saaksid neid kontrolle teostada, peavad nad programmi ja koodi põhjalikult tundma, mistõttu on vähem kogenud testijatel raske oma panust anda.
Ettevõte saab tarkvara testida ainult viisil, mis vastab testijate olemasolevatele oskustele, täpsemalt nende võimele redigeerida rakendust ja luua parandatav kodeerimisviga.
2. Ei sobi musta kasti testimiseks
Musta kasti testimine hõlmab peamiselt rakenduse esiosa vaatamist ilma selle sisemisi toiminguid ja koodi kontrollimata – see on sisuliselt vastuolus mutatsioonitestimisega.
Selle tulemusena on need kontrollid kasulikud ainult mõnede testide puhul võrreldes teiste meetoditega, millest paljud võivad pakkuda palju suuremat katvust kogu testimise etapile.
3. Mutatsioonitestide kavandamine on aeganõudev.
Koodimutatsioon võib olla tüütu protsess, sest meeskond peab leidma üksikud komponendid, mida tasub muuta. Otsustamine, milliseid mutatsioone rakendada, võib iseenesest võtta palju aega; see võib olla problemaatiline, kui teised testimisviisid ootavad tegelikult neid kontrolle, et ettevõtte testimisviis täielikult valideerida.
4. Võib nõuda palju koodimuutusi
Samamoodi on keerukate projektide puhul loomulikult vajalik suurem arv mutante, et tagada terviklik testimine. See lisab mutatsioonietappi rohkem aega ja võib hõlmata palju käsitsi tehtavaid muudatusi rakenduse koodis.
Ilma kvaliteetse testide automatiseerimise tarkvara ja programmi mutatsioonivõimaluseta võib seda testijatel olla raske edukalt rakendada.
5. Testijad ei pruugi vigu märgata
Suurim mure, mis mutatsioonitestijatel ja projektijuhtidel nende kontrollide rakendamisel sageli tekib, on võimalus, et tarkvara testijad (käsitsi või automatiseeritult) lihtsalt ei märka probleeme.
See võib nõuda ettevõtte testimisprotseduuride täielikku uuendamist – kuigi see võib siiski anda testijatele olulist teavet nende kvaliteedi tagamise standardite kohta.
6. Võib olla mälumahukas
Mutatsioonitestimine nõuab üldiselt suurt töötlemisvõimsust, kuigi see võib sõltuda rakendusest, mida testijad kasutavad.
Kui organisatsioonil on piiratud arv masinaid või kui need seadmed on madalate tehniliste näitajatega, võib neil olla raskusi liiga paljude samaaegsete mutatsioonide käivitamisega. See mõjutab seda, kui palju kontrolle nad saavad teha enne testimisetapi lõppu.
7. Aruanded võivad olla teabetihedad
Kuigi see sõltub peamiselt meeskonna mutatsioonitestimise tööriista kasutajaliidesest, võib nende poolt genereeritud aruandeid olla raske analüüsida.
See tähendab, et nende käsitsi sorteerimine ja õigete testitulemuste leidmine võtab aega; mõned programmid võimaldavad kasutajatel kohandada tegelikku aruandlusprotsessi; see on rakenduste lõikes erinev.
Mutatsioonitestide omadused
Tõhusate mutatsioonitestide peamised omadused on järgmised:
1. Põhjalik
Need kontrollid hõlmavad kõiki tarkvara peamisi aspekte; piisavate ressurssidega ettevõtted võivad isegi kavandada mutatsioonitesti iga tavalise testjuhtumi jaoks.
Kuigi täpne arv sõltub organisatsiooni võimalustest ja eelistustest, hõlmavad tõhusad mutatsioonitestid laia valikut kodeeritud funktsioone.
2. Strateegiline
Programmimuutused peaksid samuti järgima selget ja hästi kavandatud struktuuri, mis hõlbustab organisatsiooni üldisi testimiseesmärke.
Näiteks võivad nende tekitatud vead lähendada realistlikke testimisvigasid, mis võimaldab testijatel neid probleeme ennetada, kui need loomulikult esinevad, parandades oluliselt ettevõtte testimisprotsessi.
3. Konstruktiivne
Mutatsioonitestimise eesmärk on tuvastada puudujäägid testimises – näidata, kuidas meeskond saaks oma kontrolle parandada ja väiksemaid vigu parandada, kui need ilmnevad.
Mutatsioonitestijad peavad seadma prioriteediks “kehtetud” mutandid, mis mõjutavad tarkvara funktsionaalsust, võimaldades selgemat testimise parandamist kogu projektis.
4. Preemptive
Need kontrollid on olemas selleks, et valideerida meeskonna üldist strateegiat; see tähendab, et mutatsioonitestimine toimib paremini arenduse varajases etapis.
Kui testijad märkavad oma kvaliteeditagamise lähenemisviisis olulisi puudusi, annab see neile vajaliku aja testjuhtumite muutmiseks, et need oleksid piisavad.
5. Järjepidev
Mutatsioonitestimine rakenduse eri iteratsioonides peaks andma järjepidevaid tulemusi, lisades samal ajal rohkem kontrolle, et võtta arvesse tarkvaramuutusi.
Edasised kontrollid peavad olema sama üksikasjalikud, et säilitada nende tõhusus – ilma sellise täpsuseta võivad mutatsioonikatsed muutuda ebatäpsemaks.
6. Peenike
Mutatsioonitestide eesmärk on uurida kvaliteedi tagamise meeskonna võimet tuvastada koodivead oma testide ja kolmandate osapoolte platvormide abil.
See tähendab, et testid ei peaks olema kohe ilmsed kõigile tarkvara kontrollijatele; eesmärk on uurida, kuidas testijad reageerivad väiksematele koodiprobleemidele.
7. Koostöö
Nagu iga tarkvaratesti puhul, on ka koodimutatsioon protsess, mille edukuse tagamiseks on tavaliselt vaja meeskonnatööd ja suhtlemist. Koostööõhkkonna säilitamine aitab vältida teabesilosid, mis võivad põhjustada väärteomenetlust – see tagab ka selle, et iga testija jääb keskenduma konkreetsetele ülesannetele.
Mutatsioonitestide tüübid
Kolm peamist mutatsioonitestide tüüpi on järgmised:
1. Väärtuse mutatsioon
Väärtuse mutatsioonid muudavad otseselt koodis olevaid väärtusi, vahetades ühe numbri või tähe teise vastu nii, et see mõjutab rakenduse funktsionaalsust.
Näiteks võib testija muuta programmi täpseid parameetreid, näiteks numbreid, millele see reageerib. Mutatsioonitestijad võivad konkreetselt sihtmärgiks võtta tarkvara konstantsed väärtused, kuna need jäävad tavapärastes toimingutes alati samaks.
2. Otsuse mutatsioon
Otsusemutatsioonid muudavad aritmeetilisi ja loogilisi operaatoreid, muutes tõhusalt seda, kuidas rakendus reageerib konkreetsetele olukordadele.
Näiteks suurema kui operaatori (>) vahetamine väiksema kui operaatoriga (<) mõjutab loomulikult programmi väljundit. Testijad võivad ka vahetada “või” “ja” vastu või vastupidi, muutes põhimõtteliselt seda tarkvara ja seda, kuidas see tõlgendab teiste testijate ja võimalike kasutajate esitatud teavet.
3. Avalduse mutatsioon
Avaldusmuudatused muudavad koodi tegelikke avaldusi, muutes reegleid, mida rakendus kasutab oma otsuste tegemiseks. Testijad võivad nende ridade sisu muuta, neid dubleerida või isegi kustutada, et kontrollida, kuidas mutantprogramm mõjutab tarkvara funktsionaalsust.
Need mutatsioonid muudavad programmi ehitusplokke, eemaldades potentsiaalselt terveid funktsioone või takistades muul viisil nende toimimist.
Mõningate segaduste väljaselgitamine
– Mutatsioonitestimine vs. regressioonitestimine
Mutatsioon ja regressioonitestimine on mõlemad kasulikud lähenemisviisid tarkvara testimisele – mõlema tehnika mõistmine võib parandada ettevõtte üldist kvaliteedi tagamist.
1. Mis on regressioonitestimine?
Regressioonitestimine on see, kui testijad uurivad tarkvara erinevate iteratsioonide vahel, et veenduda, et see toimib hoolimata koodis tehtud muudatustest.
Isegi väikesed muudatused võivad ilma nende kontrollideta põhjustada tõsiseid probleeme, mis võivad põhjustada varasemate vigade uuesti esilekerkimist. See nõuab üldiselt automatiseerimist, kuna iga komponendi uuesti testimine on keeruline; paljud ettevõtted loobuvad seetõttu regressioonitestidest.
Testijad võivad neid kontrolle läbi viia üksikute üksuste, üksikute komponentide või kogu toote suhtes – täpsed vajalikud testid sõltuvad peamiselt projektist ja selle ulatusest.
2. Mis vahe on mutatsiooni- ja regressioonitestidel?
Regressioonitestimine keskendub peamiselt programmi ja selle funktsionaalsuse kontrollimisele, samas kui koodimutatsioon vaatab hoopis seda, kuidas testijad probleemidele reageerivad.
Esimene toimub samuti suures osas pärast programmi mitut iteratsiooni, samas kui mutatsioonikontroll võib toimuda mis tahes arendusetapis – kuigi tavaliselt testimisfaasi alguses.
Nii regressiooni- kui ka mutatsioonitestid võivad käsitleda üksikuid kodeerimisüksusi ja seda, kuidas väikesed muudatused võivad põhjustada olulisi probleeme, mille kõrvaldamiseks testijad peavad töötama.
3. Kokkuvõte: Mutatsioonitestimine vs. automatiseeritud testimine
Automatiseerimine on sageli mutatsioonitestimise oluline osa, kuna kontrollide ja üksuste hulk on väga suur – see muudab selle mõnikord edukaks ja terviklikuks testimisprotsessiks hädavajalikuks.
Ettevõtted kasutavad tavaliselt koodimuutusi, et uurida oma kolmanda osapoole automatiseerimisplatvormi ja seda, kui hästi see tuvastab probleemsed skriptid.
Kombineerides põhjalikku mutatsioonikontrolli kataloogi automatiseeritud tarkvaraga, saab ettevõtte katvust märkimisväärselt suurendada ja tagada tugevamad tulemused.
Kuigi need on kaks eraldi testimisviisi, ei pea need üksteisele vastuollu minema. Näiteks robotiseeritud protsesside automatiseerimise integreerimine võib anda tõuke ettevõtte mutatsioonitestimise strateegiale.
Mida on vaja mutatsioonitestimise alustamiseks tarkvaraarenduses?
Tavalised nõuded ulatuslikuks mutatsioonitestimiseks on järgmised:
1. Selge testimisstrateegia
Testimisrühm peab kehtestama mutatsioonitestimise strateegia, sealhulgas selle, milliseid komponente ja üksusi on kõige olulisem uurida.
Näiteks võivad teatavad koodi aspektid olla rakenduse edukuse ja funktsionaalsuse seisukohalt olulisemad; testijad peaksid tagama, et selle jaoks on piisavalt mutatsioone.
Ettevõtte mutatsioonitestimise ajakava on samuti oluline, sest see tagab, et testijatel on piisavalt aega koodi uurimiseks.
2. Ei ole ulatuse muutumist (scope creep)
Isegi kui on olemas põhjalik strateegia, milles on sätestatud ettevõtte lähenemisviis mutatsioonitestidele, on võimalik, et testide arv on oluliselt suurem kui vajalik.
Tõhusus on kogu selle menetluse jooksul ülimalt oluline, eriti kuna teised testimisetapid võivad oodata, et meeskond leiaks ja tapaks mutatsioonid. Testijad peavad enne koodi muutmise alustamist selgelt määratlema oma töövaldkonna; see tagab, et kõik on praktilise ajakava piires hallatav.
3. Range dokumentatsioon
Igale testimisprotsessile tuleb kasuks täielik dokumentatsioon – sageli testjuhtumite kujul, mis kirjeldavad üksikasjalikult üksikuid kontrolle ja kõiki asjakohaseid mutante.
See illustreerib meeskonna praegust arengut testide lõikes, mis on eriti kasulik juhtidele ja juhtidele. Iga koodimutatsiooni dokumenteerimine aitab testijatel säilitada selgeid andmeid tehtud muudatuste kohta.
Kui kvaliteedi tagamise meeskonnal on testimise käigus raske neid mutatsioone leida, siis on need dokumendid tegelikult vastusevõimalus.
4. Kvalifitseeritud testijad
Testijatel, kes koodi muudavad, peab olema tugev arusaam tarkvarast – sealhulgas paljudest võimalustest, kuidas nad seda muuta või isegi rikkuda võivad.
Mutatsioonitestijad teavad, kuidas nende muudatused mõjutavad rakendust ja kuidas teised kvaliteedi tagamise meeskonnaliikmed võiksid mutatsioonikoodi tuvastada.
See eeldab üldjuhul head programmeerimisoskust. Selleks, et mutatsioonianalüüs oleks tõhus, peaksid ka tarkvara testijatel olema hästi arenenud oskused ja testimiskogemus.
5. Automaatika tarkvara
Kolmanda osapoole automatiseerimistarkvara võib olla vajalik enne mutatsioonitestimist, kuna see protsess nõuab sageli palju kontrolle. See kehtib eriti keeruliste rakenduste puhul, kus on rohkem koodi ja funktsioone, mida kvaliteedi tagamise meeskond peab uurima.
Ettevõtted võivad neid kontrolle rakendada spetsiaalselt selleks, et testida, kuidas automatiseerimistarkvara reageerib kodeerimisvigadele. See võib olla ettevõtte prooviprotsessi põhiline osa, et otsustada, millised programmid on kõige kasulikumad.
Mutatsiooni testimise protsess
Tavalised sammud, mida testijad tavaliselt järgivad mutatsioonianalüüsi läbiviimisel, on järgmised:
1. Valmistage testid ette
Ettevalmistus on iga testimisprotsessi esimene samm. See hõlmab läbirääkimisi rakendatavate kontrollide täpse rakendamise üle ja vajaliku heakskiidu saamist – näiteks ettevõtte juhtidelt ja sidusrühmadelt.
Testijad peavad need kontrollid välja töötama nii, et need vastaksid projekti ajakavale, hõlmates samas kõiki peamisi komponente. Meeskonna planeerimine võib määrata nende koodimuutuste tõhususe.
2. Tutvustage mutandid ja vead
Kui ettevalmistused on lõpetatud, hakkab testimismeeskond koodi muutma, muutes seda vastavalt oma plaanile konkreetsete vigade sisseviimiseks. Need vead peaksid olema suhteliselt väikesed, sest see võimaldab testijatel hinnata ülejäänud meeskonna võimet tuvastada kodeerimisprobleeme.
Väiksemad vead võivad aidata organisatsioonil kontrollida ka oma kolmanda osapoole automatiseerimistarkvara tundlikkust.
3. Rakendage testjuhtumid
Testjuhtumid peavad arvesse võtma kõiki võimalikke rikkepunkte rakenduses – see võib nõuda ümberkirjutamist, kui mutantne programm suudab toimida ilma vigadeta.
Programmi testjuhtumid esindavad kogu kontrollide ulatust, mida testijad teevad; igaüks neist peaks aitama testijatel avastada kõik varjatud mutatsioonid ja olema lahutamatu osa rakenduse kasutatavusest.
4. Võrdle tulemusi
Pärast mutatsioonivigade lisamist programmile ja meeskonna testjuhtumite rakendamist peab meeskond võrdlema nii algse kui ka mutantprogrammi tulemusi.
Lootus on, et iga eduka kontrolli kohta originaalis on ka mutatsioonirakenduses viga. See näitab nii testijate kui ka nende kasutatavate vahendite võimeid.
5. Tegutsege erinevate väljundite alusel
Kui originaal- ja mutatsiooniprogrammi väljundid on erinevad, nagu testijad ootavad, tähendab see, et testjuhtum võib edukalt tappa mutandi, näidates selle olemasolu.
Seejärel saavad testijad jätkata oma metoodika ja kodeerimisprobleemide tuvastamise võime suhtes kindlusega. Nende konkreetsete testide puhul ei ole vaja testjuhtumeid muuta.
6. Vajaduse korral muutke juhtumeid.
Mõned koodimuutused võivad viia erinevate programmide puhul identsete järeldusteni, mis näitab, et testjuhtumid ei suuda edukalt esile tuua kõiki võimalikke vigu rakenduses.
Sellistel juhtudel jääb mutant “ellu” ja võib jätkuvalt mõjutada tarkvara viisil, mille käsitlemiseks testijatel puudub raamistik – see viib paremate testjuhtumite koostamiseni.
Kuidas luua mutantprogramme
Mutantprogrammid on sisuliselt identsed originaalprogrammidega, välja arvatud üks väike muudatus, mis võib mõjutada rakenduse funktsionaalsust väikestel, kuid märgatavatel viisidel.
Põhjalikud ja üksikasjalikud testjuhtumid aitavad testijal või tarkvarakomplektil neid muudatusi ja nendest tulenevaid vigu täpselt tuvastada. Iga juhtumi puhul, mida ettevõte kontrollib, on vaja nii algset kui ka muudetud programmi, mis näitab iga muudatuse mõju eraldi.
Programmid jäljendavad tavaliselt realistlikke vigu, näiteks kodeerimisvigu. Samuti on oluline, et testijad väldiksid “veel sündinud” mutante, mis takistavad rakenduse täitmist – see on testijatele liiga ilmne.
Mida muuta mutantprogrammis?
Nagu paljude tarkvara testimise muutujate puhul, sõltuvad täpsed muudatused, mida testijad teevad, rakendusest ja selle koodist.
On kolm kategooriat, mis hõlmavad enamikku mutatsioonitestidest: operandid, väljendid ja avaldised. Muutes ükskõik millist neist võib luua tõhusa mutantprogrammi – näidates, kuidas erinevad väärtused või reeglid mõjutavad programmi kasutatavat loogikat.
Need kategooriad on seotud kolme peamise mutatsioonitüübiga, mida testijad uurivad; need on vastavalt otsuse, väärtuse ja avalduse mutatsioonid. Muudatused peaksid olema väikesed ja ei tohi täielikult takistada testi läbiviimist.
Parimad tavad mutatsioonitestide tegemiseks
Mutatsioonitestimise läbiviimisel tarkvara testimise kontekstis tasub järgida teatud tavasid, mis tagavad tugevad tulemused, näiteks:
1. Maksimeerida mutatsiooni skoor
Programmi mutatsiooniskoor on mutantide protsent, mille meeskond või rakendus suudab edukalt tuvastada või “tappa”.
Näiteks kui mutatsioonitestimise voorus on 40 mutanti ja testijad leiavad 36 mutanti, on mutatsiooniskoor 90% – meeskonna eesmärk on alati tagada 100% tulemus.
2. Valige mutandid juhuslikult
Kuigi see võib aidata teatud komponente prioriseerida ja neid põhjalikumalt testida, on testijatel kasulik ka juhuslikult valida, milliseid mutante lisada – eriti tiheda tähtaja jooksul.
Niikaua kui need kontrollid esindavad kõiki olulisi mutatsioonitüüpe, saab kvaliteedi tagamise meeskond kinnitada oma üldise tarkvara testimise strateegia.
3. Hoidke muudatused väikesed
Koodimuutused peaksid kujutama väiksemaid kõrvalekaldeid algsest programmist, sest see näitab, kui tõenäoline on, et testija tuvastab teatavad vead; väiksemad kodeerimisprobleemid näitavad ka seda, kui tundlik on nende tarkvara.
On väga oluline, et mutatsioonitestijad leiaksid tasakaalu, mis võimaldab neil väikestel muudatustel siiski märgatavaid vigu tekitada.
4. Üks mutatsioon programmi kohta
Mutatsioonitestimine vaatleb üksikuid testjuhtumeid eraldi, et kontrollida, kui terviklikud need on. Selleks peaks igas muudetud programmis olema ainult üks muudatus võrreldes originaaliga.
Mitme mutatsiooniga programmid ei pruugi olla võimelised tõhusalt testjuhtumitega paarituma; mutatsioonid võivad omavahel konflikti sattuda.
5. Kaaluge hoolikalt automatiseerimistarkvara
Ettevõtted kasutavad sageli koodimutatsiooni, et kontrollida meeskonna automatiseerimistarkvara kasutamist ja veenduda, et see suudab tuvastada vigu sama tõhusalt kui inimtester.
See tähendab, et õige automatiseerimisplatvormi valimine võib olla oluline kaalutlus, nagu ka võimalus integreerida robotiseeritud protsesside automatiseerimine.
6. Kasutage testipõhist arendustegevust
Testipõhine arendus (TDD) viitab konkreetsele tehnikale, mis võtab testimisnõudeid arvesse igas arendusetapis.
See aitab tagada, et testjuhtumid on täielikult kooskõlas tarkvaraga – see võimaldab hõlpsasti läbida mutatsioonitestid ja teha parema programmi, mis on sünkroonis kvaliteedi tagamise protsessidega.
Mutatsioonitesti väljundite tüübid
Mutatsioonitestid genereerivad mitu väljundit, sealhulgas:
1. Mutantne programm
Mutatsiooniprogrammid on nende kontrollide loomulik väljund; testijad loovad neid, et kajastada oma jooksvaid testjuhtumeid ja probleeme, mida nad aitavad tuvastada. Programmid erinevad oma algsest vastandist tavaliselt ainult ühes väikeses, kuid olulises osas, et tagada suurem usaldusväärsus.
2. Elus või surnud mutant
Pärast teste on mutatsioon kas “tapetud” või jääb “elus” – see viitab lihtsalt sellele, kas testija (või tema tarkvara) tuvastab edukalt kodeerimisprobleemi või mitte.
Kui mutant jääb ellu, võivad testjuhtumid vajada tõsiseid muudatusi.
3. Muteerimise katsejuhtum
Kvaliteedi tagamise meeskond kasutab eraldi mutatsioonispetsiifilisi testjuhtumeid, mis logivad teavet oma mutatsiooniprogrammide kohta.
See aitab tagada, et meeskonnal on iga kontrolli kohta põhjalikud dokumendid; need dokumendid sisaldavad üksikasju mutatsioonide ja nende mõju kohta programmile.
4. Mutatsiooni skoor
Mis tahes mutatsioonitestide lõppeesmärk on saavutada 100% mutatsioonitulemus, kusjuures ettevõtte testimismenetlused leiavad ja hävitavad edukalt kõik mutandid. Kõik, mis on sellest väiksem, viitab sellele, et nende testjuhtumid ja üldised protsessid vajavad täiustamist, et tuvastada problemaatilist koodi.
Näited mutatsiooni testimise kohta
Siin on kolm näidet mutatsioonitestide kohta:
1. Väärtuse mutatsiooni näide
Väärtuse mutatsioon hõlmab konstandi või parameetri muutmist, mis võib potentsiaalselt muuta programmi piire. Näiteks võib kassaautomaadi tarkvara kasutada toidukauba hinna määramiseks selle kaalu.
Testijad võivad muuta selle programmi taga olevat koodi, et muuta kaaluparameetreid, muutes toidu iga unts või nael palju kallimaks. Testija või testplatvorm peaks olema võimeline tuvastama erinevate väärtuste mõju sellele programmile.
Kuna see viga muudab ühte tarkvara põhifunktsioonidest, peaksid testjuhtumid seda viga märkama ja meeskonda hoiatama.
2. Otsuse mutatsiooni näide
Otsusemutatsioonid hõlmavad aritmeetilise või loogilise operaatori muutmist, ümberpööramist või muul viisil muutmist, kuidas see rakendus reageerib kasutaja sisestusele. Tulles tagasi enesekassade näite juurde, võivad need masinad märkida ootamatult suure kaaluga kaubaartikli, mis võib olla tingitud kasutaja veast.
Masinakood võiks seda teha otsuse “if (a>b)” abil – kusjuures “b” kajastab oodatavat kaalu ja “a” vastab tegelikule kaalule. Meeskond võib selle muuta “if (a≤b)”, mis muudab kassasüsteemi reageerimist; see märgiks objekti isegi oodatava kaalu juures.
3. Näide avalduse mutatsioonist
Avaldusmuudatused hõlmavad reegli või väljundi muutmist – see võib hõlmata isegi avalduste kustutamist rakendusest üldse. Need mutatsioonid võivad olla märgatavamad kui teised, sõltuvalt konkreetse avalduse sagedusest; on oluline, et testijad valiksid avalduse targalt.
Näiteks võib isekassamasin kuvada hoiatuse, kui kasutaja üritab osta vanusepiiranguga kaupa. Ilma vastava avalduseta võib masin kokku kukkuda või lubada igal kliendil osta ükskõik millist toodet.
Avaldust muutes ja seda meeskonnale rõhutades saavad testijad kontrollida, et nende lähenemisviis vastab nendele probleemidele.
Mutatsioonitestimise abil tuvastatud vigade ja vigade tüübid
Mutatsioonitestid paljastavad peamiselt probleeme testimisprotsessis endas. Seda silmas pidades on siin hulk probleeme, mida need kontrollid aitavad tuvastada:
1. Ebaselged testjuhtumid
Kui mutatsioonianalüüs näitab madalat mutatsiooniskoori (või isegi alla 100%), tähendab see, et meeskonna testjuhtumid ei suuda arvesse võtta kõiki võimalikke vigu, mis võivad rakendust mõjutada.
Need ei pruugi olla piisavalt spetsiifilised või laiaulatuslikud, et vastata meeskonna nõuetele. Need dokumendid peaksid hõlmama kõiki võimalusi, millega meeskond võib tarkvara testimisel kokku puutuda, et tagada usaldusväärsus.
2. Koolitamata testimismeeskond
Mutatsioonitestid võivad samuti illustreerida meeskonna võimeid, sealhulgas seda, kui hästi nad isiklikult tuvastavad mutatsioonid ja muud vead. Kui nad ei suuda vaatamata selgetele ja üksikasjalikele testjuhtumitele leida mutante kõikides programmides, võib see olla tingitud sellest, et testijad ei ole neid juhtumeid õigesti rakendanud.
Mutantsed programmid võivad näidata probleeme kogu testimisprotsessi vältel – see võib hõlmata ka oskamatuid või väljaõppeta testijaid.
3. Ebapiisav testimistarkvara
Kui ettevõte kasutab neid kontrolle omaenda testimisplatvormi kontrollimiseks, võib ta leida, et tarkvara ei suuda täpselt tuvastada või hävitada mutantkoodi.
Ettevõte võib reageerida, uurides teisi valikuid, kuni nad leiavad ühe, mis sobib nende testjuhtumitega. Kui automatiseerimistarkvara ei leia problemaatilist koodi, on tõenäoliselt raske tuvastada muid tarkvara mõjutavaid probleeme.
4. Optimeerimata kood
Mutatsioonitestimine võib paljastada tarkvaras juba esinevad probleemid. Näiteks võivad testijad üritada koodi muuta, kuid avastavad ise kriitilisi vigu.
See on programmi teine oluline vaatenurk, mis näitab, et koodi mutatsioon annab kasu ka väljaspool testimisprotsessi. Mida rohkem testijad uurivad seda koodi mis tahes funktsioonis, seda rohkem probleeme saab meeskond avastada ja parandada kogu testimise käigus.
Ühine mutatsioonitesti meetrika
Mutatsioonitestide peamised mõõdikud on järgmised:
1. Tapetud mutandid
See viitab mutantide arvule, mida testijad või tarkvara suutsid tuvastada, märkides nende olemasolu, et töötajad saaksid selliseid väiksemaid vigu leida.
Testijate poolt tapetavate mutantide hulk sõltub nende testjuhtumite tugevusest.
2. Elusad mutandid
Elusad mutandid on need, mida testija või tarkvara ei suuda tuvastada – see näitab lünki, mis võivad esineda meeskonna kvaliteedi tagamise strateegias. Kui see juhtub, peaksid testijad oma protsessi ja testjuhtumid ümber kalibreerima, et need mutandid arvesse võtta, ja neid tulevaste kontrollide käigus hävitama.
3. Kehtivad mutandid
See mõõdik määrab kindlaks mutatsioonide hulga, mida programm suutis edukalt lisada, ilma et jooksuaegne viga tühistaks testi ja selle tõhususe.
Kehtivad mutandid on need, mida testija ja automatiseerimistarkvara saavad uurida; see on tingitud sellest, et mutatsioonid on suhteliselt väikesed.
4. Invaliidsed mutandid
Märkimisväärsed mutatsioonid võivad mõjutada rakendust piisavalt, et muuta testimine ebapraktiliseks või isegi võimatuks – seega aitab jälgida, kui palju “kehtetuid” mutante on muteeritud programmis.
Nende tuvastamine võimaldab testijatel neid muuta või isegi eemaldada, tagades, et kontrollid hõlmavad ainult kehtivaid mutatsioone.
5. Mutandid kokku
Mutatsioonide arv, sõltumata nende kehtivusest, on teine mõõdik, mida testijad jälgivad; see võimaldab neil jälgida mutante ja registreerida nende staatust.
Kuna iga mutatsioon hõlmab tavaliselt eraldi testi, siis on kogusumma ka koodimutatsioonide üldarvu näitajaks.
6. Mutatsiooni skoor
Mutatsioonianalüüsi kõige kasulikum näitaja on tavaliselt mutatsiooniskoor, mis on tegelikult nende kehtivate mutatsioonide protsent, mida testija või automaatika suutis tuvastada.
Kõik, mis on vähem kui 100% tuvastamine, võib olla märk ebaõigest katsemenetlusest.
7 viga ja lõksu mutanttestide rakendamisel
Mutatsioonitestimine on keeruline protsess, mida ettevõtted peavad rakendama targalt, et vältida tõsiseid probleeme või vigu. Siin on seitse lõksu, mida testijad peaksid vältima mutatsioonitestide läbiviimisel:
1. Ebakorrektne muteerimise skaleerimine
Mutatsioonianalüüsi puhul on oluline kaalutlus, sest see protsess on olemas selleks, et testijad tuvastaksid rakenduse väiksemad vead. Kui mutatsioon on testijatele liiga ilmne, ei pruugi see olla tõhus viis kontrollida nende võimet märgata või tõrjuda tarkvaraprobleeme.
2. Invaliidid või elusad mutatsioonid
Isegi õiges mastaabis pakuvad paljud mutatsioonid vaid piiratud tõhusust – näiteks kui need ei too kaasa viga või põhjustavad probleemi, mis peatab rakenduse töötamise.
Testijad peaksid silmas pidama, kuidas mis tahes koodimuudatus võib mõjutada kogu tarkvara.
3. Ühildumatud testjuhtumid
Testjuhtumid ja mutatsioonid peavad sobima ideaalselt kokku, et tagada järjepidev ja harmooniline testimine. Kui otsustatakse, milliseid mutatsioone lisada või isegi esialgsete testjuhtumite kavandamisel, võib kvaliteedi tagamise meeskond töötada selle nimel, et need sobiksid kokku ja viiksid üldiselt sujuvama testimiseni.
4. Tähtajad ja ajakava
Testimise etapid on erineva pikkusega, kuid peaksid alati järgima ettevõtte sisemisi tähtaegu. Ettevõtted, kes ei suuda oma mutatsioonikatsetusi nõuetekohaselt planeerida, ei pruugi protsessi õigeaegselt lõpule viia.
Enne kui projekt jõuab testimisjärku, peab meeskond tagama, et testimise ajakava on piisavalt põhjalik.
5. Ebapiisav testide katvus
Ettevõtted võivad rakendada oma koodeksimuutusi juhuslikult – kuid on siiski oluline, et need hõlmaksid laia teemaderingi.
Selleks, et nii testijad kui ka tarkvara suudaksid tuvastada igat tüüpi mutatsioonid, peaksid kontrollid hõlmama vähemalt mitmeid väärtus-, otsustus- ja avaldismutatsioone.
6. Mutantide kasutamine tarkvara testimiseks
Kuigi mutatsioonitestimine annab uue vaatenurga rakendusele, peavad meeskonnad kasutama seda meetodit ainult omaenda testimisprotsessi kontrollimiseks. Ettevõte peab mõistma mutatsioonitestimise täpseid võimalusi ja piiranguid; see meetod saab olla edukas ainult koos muude tarkvarakontrollidega.
7. Liiga palju mutante
On ülimalt tähtis, et ettevõtted tagaksid laialdase testide katvuse, kuid nad võivad selle käigus rakendada liiga palju mutante. Iga mutatsiooniprogramm nõuab märkimisväärset arvutusvõimsust, mis piirab seda, kui palju neid saab organisatsioon samaaegselt läbi viia.
Liiga paljude mutatsioonide käivitamine võib samuti raskendada testimise tähtaegadest kinnipidamist.
Mutatsiooni testimise kontrollnimekiri, näpunäited ja nipid
On mitmeid täiendavaid nõuandeid, mis võiksid aidata igal meeskonnal parandada oma mutatsioonitestimise protsessi edukust, näiteks:
1. Kontrollige programmeerimiskeele ühilduvust
Nii tasuta kui ka tasulised mutatsioonitestimise tööriistad on tavaliselt spetsialiseerunud ühele kodeerimiskeelele, mistõttu on oluline, et testijad valiksid tööriista, mis ühildub rakenduse ja tarkvara testimise platvormiga.
Testimismeeskond peaks uurima mitmeid võimalusi, et tagada, et nad kasutavad programmi, mis sobib nii nende eelarvele kui ka nende eelistatud kodeerimiskeelele.
2. Jagage testid targalt
Testimismeeskonna eri liikmed vaatavad tõenäoliselt rakenduse erinevaid aspekte, mis tavaliselt on seotud nende konkreetsete tugevuste, nõrkuste ja üldise kogemusega.
Kui meeskond määrab igale testijale mutatsioonitestid, peaksid nad seda silmas pidama, et saada ettekujutus nende tasemest; see näitab, kui hästi edasine testimine tõenäoliselt läheb.
3. Valige vead hoolikalt
Kui tarkvara hiljutises iteratsioonis oli mingi väärtuse või avaldusega seotud viga, võib aidata seda korrata ja uurida, kuidas meeskond või programm reageerib.
See aitab tagada rakenduse pikaajalisuse ja näitab meeskonna võimet märgata varasemaid vigu, kui need korduvad – see on regressioonitestimise põhikomponent.
4. Maksimeerida arvutusvõimsust
Kuna mutatsioonikontroll võib võtta palju arvutusvõimsust, aitab see ettevõtte riistvara maksimaalselt ära kasutada.
Näiteks kui teatud masinatel on tugevamad spetsifikatsioonid, võib olla kasulik käivitada mutandid nendes seadmetes. See võimaldab ettevõttel vältida märkimisväärseid viivitusi, mida aeglasemad masinad võivad põhjustada.
5. Ära jäta elusat mutatsiooni kõrvale
Isegi range ajakava korral peaksid testijad töötama selle nimel, et muuta ja laiendada oma testjuhtumeid, et võidelda mis tahes mutantide vastu, mis jäävad ellu.
Kuigi need vead ei pruugi tunduda märkimisväärsed, kui tarkvara või testija neid ei leia, kujutavad need siiski endast testijuhtumite ebaõnnestumist kõigi kodeerimisprobleemide tuvastamisel.
6. Uue automatiseerimistarkvara uurimine
Kui meeskonna testjuhtumid on piisavalt üksikasjalikud, kuid nende automatiseeritud testimise komplekt ei suuda neid edukalt kasutada iga mutatsiooni tuvastamiseks, võib neile olla kasulik teistsugune tarkvara.
Saadaval on palju tasuta ja tasulisi platvorme ning ettevõtted peaksid kontrollima kõiki võimalusi, et veenduda, et nende tarkvara sobib kõige paremini nende testimisjuhtumitele pikemas perspektiivis.
7. Sünkroonige iga testimisprotsessi
Koostöö on iga testimisstrateegia põhikomponent – see aitab tagada, et kõik protsessid sobivad hõlpsasti kokku nii, nagu meeskond seda soovib.
Näiteks võiks testimismeeskond arendada oma testjuhtumeid mutatsiooniga, et tagada suurem ühilduvus, mis lihtsustaks testijate jaoks nende strateegia valideerimist.
8. Kasutage ühiktestimist
Ühiktestimine võimaldab kvaliteedi tagamise meeskonnal kontrollida kooditükke eraldi, mis lihtsustab testide läbiviimist ja muudab probleemide tuvastamise meeskonnale lihtsamaks.
See kombinatsioon võib olla eriti kasulik, kui testijad muretsevad tähtaegade pärast, andes neile võimaluse lihtsustada oma kontrolle ja parandada üldist katvust – mis viib palju tugevamate tarkvarateste.
9. Kirjutage üksikasjalikud testjuhtumid
Mutatsioonitestid peaksid sisaldama piisavat teavet mutandi ja selle mõju kohta programmile, samuti selle kohta, kuidas testimismeeskond või platvorm need vead tuvastas.
Andes võimalikult palju üksikasju, saab testija isiklikult valideerida testjuhtumi ja veenduda, et meeskond teab täpselt, kuidas tagada sujuv testimine.
5 parimat mutatsiooni testimise tööriista
On olemas suur hulk vahendeid, mis võivad aidata ettevõtteid nende mutatsioonitesti nõuete täitmisel. Nagu sageli tarkvara testimise rakenduste puhul, on hinnad ja funktsioonid eri platvormidel erinevad, mistõttu on oluline, et organisatsioonid valiksid oma vajadustele kõige paremini vastava platvormi.
Mõned neist programmidest võivad pakkuda tasuta vasteid või olla täielikult avatud lähtekoodiga; kuigi suurema mugavuse eest tuleb tavaliselt maksta.
Seda silmas pidades on siin viis parimat tööriista mutatsioonide testimiseks.
1. Stryker
Stryker on spetsialiseerunud JavaScripti mutatsioonile, lihtsustades seda protsessi märkimisväärselt, et tagada valepositiivsete tulemuste puudumine ja vähendada üldist jõupingutust, mida testijad peaksid muidu kõigi mutatsioonikontrollide puhul rakendama.
Strykeri platvorm hindab tarkvara intelligentselt ja kasutab kogutud teavet, et selgitada välja koodijooned või koodilõigud, mille mutatsioonist oleks kasu. See rakendus on varustatud selge tekstiga reporteriga, mis annab välja kokkuvõtte mutandi kohta, sealhulgas selle kohta, kas Stryker suutis selle tappa.
2. PITest
PITest on väga populaarne valik kogu maailmas tänu oma võimele muuta Java bait-koodi ja teha tuhandeid mutatsioone sekundis. See rakendus kasutab testjuhtumite katvuse andmeid, et kohe teada saada, millised testid võivad mutandi tappa.
See käivitab ainult need testid, mille kohta ta teab, et need on asjakohased, piirates arvutusvõimsust, mida see protseduur tavaliselt tarbib. PITest ühildub ka enamiku Surefire’i ühiktestimise lisavormidega, kuid võib olla hädas testimisjärjekorra sõltuvuste tõhusa haldamisega.
3. Kindlustage++
Insure++-l on palju testimisvõimalusi, sealhulgas mutatsioonianalüüs, mis võimaldab platvormil tuvastada programmis esinevaid ebaselgusi. Erinevalt tavalisest mutatsioonitestimisest loob Insure++ vigaste mutantide genereerimisest ja loob selle asemel funktsionaalselt samaväärseid mutatsioone, mis vastavad projekti lähtekoodile.
Sellega välditakse kaudseid eeldusi, mis võivad tahtmatult piirata testimisprotsessi ja ei pruugi kajastada realistlikku testimiskeskkonda. Nagu nimigi ütleb, ühildub platvorm peamiselt C++ programmidega ja kõik funktsioonid on sellele keelele kalibreeritud.
4. Jumble
See rakendus on spetsialiseerunud JUnit JavaScripti raamistikule, millel on põhjalikud visuaalsed näitajad selle kohta, kuidas kood reageerib mutatsioonianalüüsile. Jumble on avatud lähtekoodiga platvorm ja töötab Java-rakenduste baitkoodis, et vähendada iga testitsükli aega.
Sarnased rakendused, mis kasutavad ainult programmi lähtekoodi, võivad mõnikord nende kontrollide tegemiseks kauem aega kulutada, kuna nad kompileerivad programmi uuesti.
Jumble kasutab ka heuristikat, et optimeerida mutatsioonitestimist veelgi, muutes hilisemad testid lihtsamaks.
5. MutPy
MutPy toetab Pythonil põhinevate rakenduste mutatsiooniteste, pakkudes täielikku tuge kõrgekvaliteedilistele mutatsioonidele ning põhjalikku katvuse analüüsi. Selle programmi kasutajaliides on väljundfaasis hõlpsasti kasutatav, mis näitab kasutajatele selgelt kõiki olulisi detaile meeskonna mutatsioonikatsete kohta.
MutPy pakub testijatele mitmeid kohandatud valikuid, mis võimaldavad neil kalibreerida seda tarkvara spetsiaalselt nende vajadustele vastavaks. Platvorm kasutab abstraktseid süntaksipuid, mis annavad rakenduse lähtekoodi selge struktuuri, mis annab testijatele suurema usalduse nende mutatsioonide suhtes.
Kokkuvõte
Koodi mutatsioon on rakendatav peaaegu igas tarkvara testimise protsessis, pakkudes ettevõtetele, kes seda tehnikat rakendavad, mitmeid selgeid eeliseid – eriti kvaliteedi tagamise etapis.
Ükski metoodika ei ole ilma väljakutseteta; see tähendab, et organisatsioonidel on hädavajalik targalt kaaluda mutatsioonianalüüsi eeliseid, tagades samal ajal, et see sobib nende tavapärase tarkvaraarenduse ajakavaga.
Need mutatsioonid annavad testimismeeskonnale võimaluse kontrollida oma lähenemisviisi ja määrata kindlaks selle tõhusus lähtekoodis esinevate vigade leidmisel ja parandamisel. See tehnika sobib eriti hästi kokku automatiseerimismenetlustega, võimaldades ettevõtetel valideerida tarkvara, mida nad usaldavad oma kontrollide läbiviimiseks.
Mutatsioonitestimine pakub kvaliteedi tagamise meeskonnale terviklikku võimalust arendada paremat arusaamist oma protsessidest ja tarkvarast, sealhulgas probleemidest, mida nad muidu ei avastaks.
Seetõttu on väga oluline, et testimismeeskonnad uuriksid seda tehnikat põhjalikult, et hinnata, kas see vastab organisatsiooni vajadustele – sealhulgas, kas valitud mutatsioonivahendid ühilduvad täielikult nende programmeerimiskeelega. ZAPTESTi automatiseeritud testimistarkvaral on palju funktsioone, mis võimaldavad tal läbida mutatsioonitestid, tagades, et meeskondadel on täielik usaldus selle võimete suhtes.
Nii Free- kui ka Enterprise-versioonid pakuvad kvaliteetset testimisprotsessi, mis suudab hõlpsasti kohaneda koodimuutustega.
KKK ja ressursid
1. Parimad kursused mutatsioonitestimise kohta
Veebikursused võivad aidata esmakordsetel testijatel õppida koodi mutatsiooni põhitõdesid või tugevdada kogenud kvaliteedi tagamise töötajate juba olemasolevaid oskusi. Ka üldised tarkvara testimise õppetunnid võivad pakkuda testijatele palju kasu. Parimad veebikursused mutatsioonitestijatele on järgmised:
– PluralSight’i teoses “Mutatsioonitestimine Java’s PITestiga” vaadeldakse konkreetselt, kuidas muuta Java-koodi ja kuidas see lähenemisviis võiks praktilise tarkvara testimise protsessidest kasu tuua.
– Udemy “The Complete 2023 Software Testing Bootcamp” on eriti ajakohane kursus, mis illustreerib kõiki tarkvaratesti võtmekomponente, sealhulgas valge kasti testimist.
– Alisoni raamat “Tarkvara testimine – tingimuste katvus ja mutatsioonitestimise strateegiad” on tasuta ja uurib põhjalikult, kuidas mutatsioonitestimist targalt rakendada.
– PluralSight’i “Ühiktestimise alused” uurib ühiktestimise eeliseid ja funktsioone, aidates tagada, et õpilased mõistaksid täpselt, kuidas kirjutada tugevaid ühikteste.
– Udemy “Introduction to Unit Testing” on veel üks tasuta kursus, mis annab selge ülevaate ühiktestimisest ja testipõhise arendusstrateegia tähtsusest.
2. Millised on 5 kõige olulisemat intervjuuküsimust mutatsioonitestimise kohta?
On mitmeid küsimusi, mida ettevõtted võivad kandidaatidelt intervjuu ajal küsida, et kontrollida nende kogemusi või arusaamist mutatsioonitestimisest ja selle põhiprintsiipidest. See võimaldab ettevõttel veenduda, et nad palkavad kvalifitseeritud testija, kes suudab hõlpsasti läheneda erinevatele mutatsiooniga seotud stsenaariumidele.
Täpsed küsimused varieeruvad, kuid võivad sisaldada nende endi arvamuste või näidete küsimist nende koodimutatsiooni oskuste kohta.
Viis parimat mutatsioonitestimise intervjuuküsimust on järgmised:
– Milliste mutatsioonitestimise vahenditega on teil varasemad kogemused, kui üldse? Millised olid selle tarkvara peamised omadused?
– Kuidas te tagaksite koodimutatsiooni läbiviimisel terve tasakaalu testimise kiiruse ja sügavuse vahel?
– Millistes olukordades oleks mutatsioonianalüüs võimatu? Kuidas te kontrolliksite testimismenetlust nende stsenaariumide puhul?
– Kui väärtuse mutatsioon õnnestub testimisprotsessi üle elada, siis kuidas te tegutseksite, et see ei korduks?
– Millist teavet te sisaldaksite mutatsioonikatsete puhul, et tagada kolleegidele vajalike andmete olemasolu?
3. Parimad YouTube’i õpetused mutatsiooni testimise kohta
YouTube’is on saadaval tasuta õppematerjalid, veebiseminarid ja muud videod, mis aitavad testeril paremini mõista mutatsioonitestimist. Mõned kõige kasulikumad videod ja sarjad sel teemal on järgmised:
– Software Testing’s “Mutation Testing for Programs”, mis annab praktilisi näiteid, kuidas koodimutatsioon aitab programme, ning kuidas kirjutada põhjalikke testjuhtumeid.
– Devoxxi “Mutatsiooni testimine: mis käsitleb seda, kuidas mutatsioonianalüüs parandab igasuguste tarkvaraprojektide üldist testimismenetlust.
– NDC konverentside “Tapa kõik mutandid! Intro to Mutation Testing”, mis uurib, kuidas testimisüksused saavad kasu koodi mutatsioonist ja vigadest, mida see aitab tekitada.
– GOTO Conferences’ “Mutation Testing in Python”, mis uurib konkreetselt, kuidas Pythonil põhinevaid rakendusi saab rakendada mutatsioonianalüüsi konkreetsete testimiseesmärkide saavutamiseks.
– Diego Pacheco “Java Mutation Testing With PITest”, mis illustreerib sarnaselt JavaScripti tarkvara kasutamist koodi mutatsiooniga – keskendudes mutatsiooniprogrammile PITest.
4. Kuidas säilitada mutatsioonitestid?
Mutatsioonianalüüsi kombineerimine regressioonitestimise ja muude pikaajaliste strateegiatega võimaldab ettevõtetel tagada tugeva kvaliteedi tagamise standardi ka pärast väljalaskmist.
Hilisemad uuendused võivad viia koodimuudatusteni, mis nõuavad täiendavaid kontrolle. Mutatsioonitestimine näitab, et automatiseerimistarkvara ja testijad on sama tarkvara eri versioonide puhul järjepidevad, kinnitades uuesti nende konkreetset lähenemisviisi.
Uued funktsioonid nõuavad uusi testjuhtumeid, eriti kui need funktsioonid on koostoimes juba olemasolevate funktsioonidega.
Lisaks sellele võimaldab testipõhise arenduse kasutamine meeskonnaliikmetel planeerida tarkvara pikaajalisust ja testida selle ühilduvust omaenda arendustsükli raames.
