Strukturell testning - Vad är strukturell testning?

structural testing tutorial what is structural testing

Den här omfattande strukturella testhandledningen förklarar vad som är strukturell testning, dess typer, vad är kontrollflödestestning och kontrollflödesdiagram, täckningsnivåer etc:

En snabb Google-sökning av några av de dyraste programvarufelarna gjorde att jag tänkte - 500 miljarder dollar. Ja, så kostsamt kan ett fel bli. Att läsa allt som är relaterat till förlorade liv inom transport- och sjukvårdsindustrin på grund av ett programvarufel kan också vara skrämmande.

Även om fel i koden inte alltid är så extrema där de innebär förlust av stora mängder pengar och liv, är det enda viktiga takeaway här vi försöker förmedla att man inte kan förbise testet.

När testning görs ofta i hela SDLC, tillåter det oss att fånga buggar som skulle behöva mycket mer tid att fixa efter leverans av produkten.

Det som är viktigt är de typer av programvarutest som vi väljer. Det finns flera av dessa, inklusive funktionella, strukturella och förändringsbaserade tester.

Denna handledning förklarar också typer av strukturella test. Lär dig hur man gör mutationstestning, skivbaserad testning, dataflödestestning i detalj med exempel och förklaringar.

Vad du kommer att lära dig:

• Varför är programvarutestning viktigt
  • Strukturell testning mot andra testtyper
  • Vad strukturell testning inte är
• Vad är strukturell testning
  • Hur man utför strukturell testning
  • Kontroll av flödestestning
    • Kontrollflödesdiagram
    • Kontrollera flödesantaganden
  • Täckningsnivåer i kontrollflöden
    • # 1) Uttalande
    • # 2) Filialtäckning
    • # 3) Bantäckning
• Strukturella testtyper
  • Mutationstestning
  • Skivbaserad testning
    • Hur man gör skivning
    • Skivbaserade testtyper
    • # 1) Dynamisk skivbaserad testning
    • # 2) Statisk skivbaserad testning
  • Dataflödestestning
    • Dataflödesavvikelser
    • Process för dataflödestestning
  • Typer av dataflödestestning
• Fördelar och nackdelar med strukturell testning
• Best Practices för strukturell testning
  • Vanliga frågor för strukturbaserad testning
• Slutsats
  • Rekommenderad läsning

Varför är programvarutestning viktigt

Förutom att spara pengar och undvika katastrofer som de ovan nämnda fallen finns det flera andra skäl som motiverar vikten av att testa.

Nedan finns några anledningar:

# 1) För att säkerställa att de angivna kraven uppfylls innan du börjar bygga ett projekt. Intressenter (till exempel utvecklare och klienter) måste komma överens om alla aspekter av lösningen / produkten / programvaran som krävs för att bygga ett projekt.

Testning innebär att verifiera om programvarukraven uppfylls. Utvecklaren eller företaget som är involverat i att bygga lösningen får också ett gott rykte för att utforma en sådan högkvalitativ lösning som drivs av eklat kod.

# 2) Det verifierar att kodfunktionen fungerar som avsett. Testning innebär också att verifiera programvarans funktionalitet och i händelse av fel bör den åtgärdas under de tidiga faserna av SDLC (Software Development Life Cycle).

# 3) Den söker efter prestanda: till exempel för att identifiera den totala tiden som gått under körning av kod. Om vi ​​använder flera För loopar i vår kod tar det lång tid att få den avsedda utgången och kan till och med timeout ibland.

# 4) Det hjälper till att uppnå en bättre användarupplevelse. Användare kan inte använda programvara som fungerar felaktigt, buggy eller ”för långsam”. Användare kommer sannolikt att bli otåliga och lämna av sig med programvaran. Testning ger oss bättre möjligheter att säkerställa att användarna enkelt kan använda våra produkter.

# 5) Det kontrolleras för skalbarhet. En utvecklare bör sikta på att bygga programvara som kan skalas.

# 6) Det söker efter sårbarheter i koden. Testning ger oss möjlighet att se upp för säkerhetsproblem, Till exempel, kod som kan kompromissa PII (Personligt identifierbar information) som har hög prioritet för GDPR.

I den här artikeln kommer vi att fokusera på en typ av testning, dvs. Strukturell testning . Som namnet antyder har det att göra med kodens struktur. Detta skiljer sig från vad vi nämnde tidigare att testning hjälper till att bestämma aspekter som kodprestanda, funktionalitet och säkerhet.

Strukturell testning mot andra testtyper

Det finns många typer av programvarutestning. Men den SLUTA (International Software Testing Qualifications Board), definierar fyra huvudtyper för programvarutestning, nämligen

• Funktionell
• Icke-funktionell
• Strukturell
• Förändringsbaserad

Skillnaderna kan förklaras enligt nedan:

Funktionell testning: Det handlar om att verifiera programvarans funktionalitet mot de angivna kraven. Testdata används som inmatning. Vi kontrollerar också att den angivna produktionen är som förväntat.

Icke-funktionell testning : Detta innebär en testprocess för att analysera hur bra programvaran fungerar, till exempel, antalet användare den kan hantera samtidigt.

Strukturell testning: Denna typ av testning baseras på kodens struktur. Till exempel, om en kod är tänkt att beräkna medelvärdet av jämna nummer i en matris, skulle strukturbaserad testning vara intresserad av 'stegen som leder till att genomsnittet beräknas' snarare än om den slutliga utgången är ett korrekt numeriskt värde.

Antag att vi måste kontrollera om vi har definierat koden som skiljer jämna nummer från udda nummer. Vi kan ha ett villkorligt uttalande här, som om ett arrayelement är delbart med två utan en återstod, if (arr (i)% 2 === 0) då kan talet sägas som ett jämnt tal.

Strukturell testning utförs av samma personer som skriver koden som de förstår den bäst.

Ändringsbaserad testning : Detta innebär att testa effekterna av att göra ändringar i koden och sedan se till att de gjorda ändringarna har implementerats. Det säkerställer också att ändringarna i koden inte bryter den.

Vad strukturell testning inte är

Vi har tidigare nämnt att strukturbaserad testning hänvisar till kodens struktur. Observera att vi hanterar den faktiska koden här. Vi kontrollerar inte kraven och testar inte ens ingångarna mot de förväntade utgångarna. Vi är inte bekymrade över funktionalitet, användarupplevelse eller ens prestanda just nu.

hur kan jag visa en eps-fil

Vad är strukturell testning

Strukturbaserad testning kan därför definieras som en typ av programvarutestning som testar kodens struktur och avsedda flöden. Till exempel, verifiera den faktiska koden för aspekter som korrekt implementering av villkorliga uttalanden, och om varje uttalande i koden exekveras korrekt. Det är också känt som strukturbaserad testning.

För att utföra denna typ av testning måste vi förstå koden noggrant. Det är därför som denna testning vanligtvis görs av utvecklarna som skrev koden som de förstår den bäst.

Hur man utför strukturell testning

För att testa olika aspekter av koden måste vi först förstå kontrollflödet.

Kontroll av flödestestning

Detta härrör från tester från kodens kontrollflöden (den ordning i vilken uttalanden, funktioner och olika aspekter av koden implementeras).

Kontrollflödestestprocess:

Kontrollflödesdiagram

Kontrollflödesprocessen börjar med att skapa en visuell representation av olika sektioner av koden som hjälper oss att definiera de banor som kan följas under körning.

Dessa visuella representationer är kända som Control Flow Graphs (CFGs) och har flera komponenter som noder, kanter, banor, korsningar och beslutspunkter. Grafen kan skapas manuellt eller automatiskt, där programvara används för att extrahera grafen från källkoden.

Låt oss titta på dessa komponenter nedan:

# 1) Processblock

Denna del används för att representera en sektion av kod som körs sekventiellt. Detta innebär att det utförs på samma sätt varje gång, och det finns inga beslut eller ”förgreningar” som behöver göras. Den består av noder med en in- och utgångsväg.

Exempel på ett processblock:

(bild källa )

Processblocket är inte en väsentlig del av kontrollflödet och behöver därför endast testas en gång.

# 2) Beslutspoäng

Det här är några viktiga komponenter i kodens kontrollflöde. Inom dessa noder fattas beslut. Detta görs vanligtvis via jämförelse och kontrollflödet ändras beroende på beslut. Denna del av CFG består av en nod med minst 2 utgångar.

Beslutet som fattas här kan vara villkorliga uttalanden som, if-else-uttalanden (som har två möjliga utdata) och falluttalanden (som kan ha mer än två utdata).

(bild källa )

I diagrammet ovan finns det en beslutspunkt (från den villkorliga 'ålder = 18') som följs av 'ja' eller 'nej' alternativ.

# 3) Korsningspunkter

Från ovanstående diagram kan vi enkelt identifiera korsningspunkter för var beslutspunkterna går med. Korsningspunkter kan ha många inträdesvägar men kan bara ha en utgångsväg.

Bästa flödesdiagram för bästa metoder:

Det finns några saker att notera när man konstruerar kontrollflödesdiagram:

• Försök så mycket som möjligt för att hålla CFG enkelt. Vi kan göra detta genom att kombinera delar som kan anses vara ”mindre betydelsefulla”, till exempel, processblock.
• Se till att endast ett beslut fattas vid beslutspunkter. I mer komplexa CFG: er finns det ”konsekvenser” som kommer efter beslutet. I vårt exempel ovan kan vi också lägga till att om en person är 18 år eller äldre, är de berättigade och måste betala för en biljett. Om de inte är det är inträde gratis. Beslutet 'annat' måste 'hoppa över' några noder, och alla dessa steg måste visas i vår CFG.

När vi väl har definierat vår CFG är det nu dags att gå vidare till nästa steg i kontrollflödestestprocessen, dvs att definiera i vilken utsträckning vi ska testa koden.

Definiera hur mycket som ska testas:

Hur mycket av källkoden ska testas? Ska vi testa varje möjlig väg? Att försöka täcka alla vägar i våra tester är praktiskt taget omöjligt. Vi måste hitta en mellanväg för att avgöra hur mycket test vi kan göra.

Om vi ​​säger att vi syftar till att testa 50% av vår kod kan det betyda att vi kommer att definiera alla körbara koduttalanden och sträva efter att testa minst hälften av dem. Frågan som här uppstår är dock ”behöver vi då definiera alla möjliga körbara vägar?”

Detta igen kan vara praktiskt taget omöjligt. Ett bättre tillvägagångssätt kan vara att sikta på att testa 50% av de vägar som vi kan identifiera i varje avsnitt av koden.

Det finns olika täckningsnivåer, nämligen uttalande, gren och bantäckning. Vi kommer att titta kort på dem senare.

Skapa testfall:

Nästa steg är att skapa de testfall som vi kommer att använda. Testfallet i strukturbaserad testning baseras på följande faktorer:

• De körbara uttalandena.
• De ”beslut” som behöver fattas.
• De möjliga vägarna som kan följas.
• Villkoren som måste uppfyllas (dessa kan vara flera eller booleska).

Ovanstående faktorer ger oss en uppfattning om vilka typer av testfall som vi behöver skapa. Vi kan också använda ett strukturellt testgenereringsverktyg. Om vår kod är på programmeringsspråket C kan vi använda PathCrawler för att generera testkod. Ett annat verktyg som vi kan använda är fMBT.

Genomförande av testfall:

Här får vi köra testerna. Vi kan ange inmatning eller data för att kontrollera hur koden kör den och sedan kontrollera om vi får de förväntade resultaten. Till exempel, ange en matris i ett funktionsanrop för att observera att de resultat vi får efter att ha bläddrat igenom den, eller för att kontrollera om beslutspunkterna fattar rätt beslut.

Analys av resultaten:

I denna del är allt vi gör att kontrollera om vi får rätt resultat efter körning. Till exempel, om vi går in i en matris där alla värden är över 18 bör vi ha alla beslutspunkter som resulterar i 'kvalificerad'.

Kontrollera flödesantaganden

Det är viktigt att notera att för att utföra kontrollflödestester finns det några antaganden som görs. Dessa inkluderar:

• De enda fel som finns är de som kan påverka kontrollflödet.
• Alla variabler, funktioner och element definieras exakt.

Täckningsnivåer i kontrollflöden

Som vi har nämnt tidigare finns det olika täckningsnivåer vid kontrollflödestestning.

Låt oss titta kort på dem.

# 1) Uttalande

I strukturell testning spelar körbara kodförklaringar en viktig roll när det gäller att bestämma metoderna för att designa testerna.

Vi strävar efter att uppnå 100% täckning, vilket innebär att varje körbart uttalande har testats minst en gång. Ju högre täckning, desto mindre är sannolikheten att du missar buggarna och felen.

Det krävs att du använder testfall här. Data vi söker efter är att se till att varje körbart uttalande i ett kodblock körs minst en gång.

# 2) Filialtäckning

Denna täckningsnivå innebär att testa poängen i CFG-filialerna (där beslut fattas). Resultaten är booleska. Även om ett switch-uttalande används och det finns flera resultat, är i huvudsak varje fallblock en jämförelse av ett par värden.

Precis som med uttalandetäckning bör vi sikta på 100% filialtäckning. För att uppnå detta måste vi testa varje resultat på varje beslutsnivå minst en gång. Eftersom vi har att göra med booleska resultat bör vi sträva efter att köra minst två tester per kodsektion.

# 3) Bantäckning

Denna täckningsnivå är mer grundlig jämfört med täckning för beslut och uttalanden. Målet här är att ”upptäcka” alla möjliga vägar och testa dem minst en gång. Detta kan vara extremt tidskrävande. Det kan dock hjälpa till att upptäcka fel eller fel i vår kod, eller till och med aspekter som vi behöver definiera, till exempel, användarinmatning.

Strukturella testtyper

(bild källa )

Mutationstestning

Mutationstestning är en felbaserad testteknik där olika varianter av en programvara testas mot testdatasetet.

>> Se denna handledning för en djupare titt på Mutationstest.

Skivbaserad testning

Slice Based Testing (SBT) kan definieras som en programvarutestningsteknik som baseras på skivor - körbara delar av programmet eller grupper av uttalanden som påverkar vissa värden vid särskilda intressepunkter i programmet, till exempel, delar där variabler definieras eller utdata från en grupp påståenden.

Hur man gör skivning

Skärningsexempel i SBT: Kod för att skriva ut jämna och udda siffror (Python)

gratis YouTube-videokonverterare till MP4

Det finns två sätt att titta på en bit: Genom att följa sökvägen till en variabel av intresse eller den del av koden som påverkar utdata.

I vårt exempel kan vi spåra den del av koden som leder oss till den här utgången om vi tittar på utgången för udda tal.

I skivningskriterierna som ges av Mark Weiser (som introducerade SBT) definieras en skiva med den här formeln: S (v, n) , var, v hänvisar till variabeln i fråga ( till exempel, där en variabel definieras) och n är intresseanmälan ( till exempel, där output ges), och S står för skivan.

I exemplet ovan, för att få skivan, börjar vi från vår produktion på rad 10, som blir vår n . Vår variabel är var .

Så våra skivningskriterier är:

Vår oro är uttalandena som leder oss till produktionen.

Dessa är:
10,9,8,4,3,1

Så vår del i den här koden är:

Skivbaserade testtyper

Det finns två typer av SBT: Statisk och Dynamisk

# 1) Dynamisk skivbaserad testning

SBT-exemplet som förklarades ovan där vi tittade på uttalandena som påverkar utskrift av udda siffror är dynamiska SBT. Vår oro är mycket specifik. Vi får bara fokusera på det som direkt påverkar den specifika produktionen.

Vi kör koden och använder testdata för att säkerställa att den fungerar som den ska. Vi kan öka intervallet till intervallet (1,50), till exempel, för att se om det fortfarande genererar udda siffror. Dynamisk SBT kallas också valideringstestning.

# 2) StatiskSkivbaserad testning

Till skillnad från Dynamic SBT är statisk testning fokus på en viss variabel. Om vi ​​tänker på vår produktion i exemplet ovan som var , kan vi spåra den skiva som påverkar den som 10,9,8,7,6,5,4,3,2,1

Det är i princip hela kodblocket! Här verifierar vi att koden är korrekt när det gäller syntax och krav, och vi utför inte den. Statisk SBT är också känd som verifieringstestning.

Det är viktigt att notera att dynamisk SBT är ”mindre” jämfört med dess statiska motsvarighet. Det är också mer specifikt.

Slice Based Testing Bästa praxis / riktlinjer

Skivningskriterier bör bestämmas av:

• Uttalanden där värden är definierade eller tilldelade värde samt omfördelat värde.
• Uttalanden där värden tas emot utanför programmet, till exempel, via användarinmatning.
• Uttalanden som skriver ut / returnerar utdata.
• Programmets sista uttalande, till exempel, ett funktionsanrop som kan definiera värden eller ge värden till argument

Fördelarna med skivbaserad testning inkluderar:

• Eftersom vi i SBT bara arbetar med specifika intresseområden, gör det det enklare att effektivt skapa testsviter.
• Banan definieras av beroenden i koden, vilket är bättre än att använda vägtäckning.
• Med SBT är det lättare att hitta fel i källkoden.

Nackdelarna med skivbaserad testning inkluderar:

• Om vi ​​använder dynamisk testning när vi testar en stor kodbas behöver vi mycket beräkningsresurser.
• Om vi ​​använder statisk testning kan vi missa fel.

Dataflödestestning

Dataflödestestning kan definieras som en mjukvarutestningsteknik som baseras på datavärden och deras användning i ett program. Det verifierar att datavärden har använts korrekt och att de genererar rätt resultat. Dataflödestestning hjälper till att spåra beroenden mellan datavärden på en viss exekveringsväg.

Dataflödesavvikelser

Dataflödesavvikelser är helt enkelt fel i ett program. De klassificeras i typ 1, 2 respektive 3.

Låt oss gräva i dem nedan:

Typ 1: En variabel definieras och ett värde tilldelas den två gånger.

Exempelkod: Python

Lst_1 definieras och två olika värden tilldelas den. Det första värdet ignoreras helt enkelt. Avvikelser av typ 1 orsakar inte att programmet misslyckas.

Typ 2: Värdet på en variabel används eller refereras innan den definieras.

Exempelkod: Python

Slingan ovan har inga värden att itera över. Avvikelser av typ 2 gör att programmet misslyckas.

Typ 3: A datavärde genereras, men används det aldrig.

Exempelkod: Python

Variabeln lst_2 har inte refererats. Avvikelser av typ 3 kanske inte orsakar programfel.

Process för dataflödestestning

För att definiera beroenden mellan datavärden måste vi definiera de olika vägar som kan följas i ett program. För att effektivt göra detta måste vi låna från en annan strukturell testtyp som kallas kontrollflödestestning .

Steg 1) Rita ett kontrollflödesdiagram

Vi måste rita ett kontrollflödesdiagram, som är en grafisk representation av de vägar som vi kan följa i vårt program.

Exempelkod: Python

I ovanstående kodexempel bör en medlem få rabatt om de bjuder in en besökare.

Kontrollflödesdiagram (CFG):

Steg 2) Utforska definitionen och användningen av variabler och datavärden.

En variabel i ett program definieras eller används antingen. I CFG har vi variabler vid varje nod. Varje nod namnges enligt den variabeltyp som den innehåller. Om en variabel definieras vid en viss nod skapas en definierande nod. Om en variabel används i en nod skapas en användningsnod.

Om vi ​​tar hänsyn till den variabla kostnaden i CFG är det dessa som definierar och använder noder:

Steg 3) Definiera sökvägar för definitionsanvändning.

Det finns två typer av definitionsanvändningsvägar: du-vägar och likspår. du-vägar är definitionsvägar som börjar med en definitionsnod och slutar med en användningsnod. Detta är fallet för banan med hänvisning till ovanstående rörliga kostnad.

Ett exempel på en likströmsväg, en beslutsfri rutt, är vägen med avseende på räkningsvariabeln enligt nedan:

DC-sökvägen har mer än en definitionsnod även om den fortfarande slutar vid en användningsnod.

Steg 4) Skapa testsviten.

Detta lägger till input. Observera att vi måste ha en annan testsvit för varje variabel. Testpaketet hjälper oss att identifiera avvikelser i dataflödet.

Typer av dataflödestestning

Det finns två typer - Statisk och dynamisk .

Statisk innebär att vi går igenom koden och CFG för att identifiera dataavvikelser utan att utföra den. Dynamisk innebär att vi faktiskt identifierar de specifika vägarna och sedan skapar testsviter för att testa det i ett försök att 'fånga' anomalier som vi kan ha missat under statisk testning.

För- och nackdelar med dataflödestestning:

• Dataflödestestning är idealisk för att identifiera dataflödesavvikelser, vilket gör det till en mycket effektiv strukturell testmetod.
• Nackdelen är att det finns ett behov av att vara väl insatt i det språk som används för att skriva koden för att använda dataflödestestning. Det är också tidskrävande.

Fördelar och nackdelar med strukturell testning

Låt oss nu hitta orsakerna till att strukturell testning är ett bra tillvägagångssätt och utforska också några av dess nackdelar.

Fördelar:

• Tillåter noggrann kodtestning, vilket resulterar i minimala fel. Strukturbaserad testning ger utrymme för att mjukvara kan testas grundligt. De olika täckningsnivåerna - uttalande för uttalande, varje beslutspunkt och väg syftar till att uppnå 100% täckning vilket kraftigt minskar risken för att fel upptäcks.
• Möjligheten att automatisera . Det finns flera verktyg som vi kan använda för att automatisera testning. Detta hjälper oss att uppnå maximal kodtäckning och inom kortare tid jämfört med att göra testet manuellt.
• Det resulterar i högre kvalitetskod . Utvecklarna har en chans att studera kodens struktur och implementering och åtgärda eventuella fel samt förbättra dessa aspekter. Det gör att vi kan hålla den stora strukturen i åtanke när vi skriver efterföljande delar av koden eller implementerar återstående funktioner.
• Det kan göras genom varje fas i SDLC - Strukturell testning kan göras i varje fas av SDLC utan att vänta på att utvecklingen ska slutföras 100%. Detta gör det enkelt att identifiera fel i tidig fas och sparar därmed mycket tid jämfört med testning efter att utvecklingen är klar.
• Det hjälper till att bli av med död kod . Detta kan ses som ”extra” eller onödig kod, till exempel, kod som beräknar ett resultat men aldrig använder det i någon av följande beräkningar.
• Effektivitet - Eftersom utvecklarna som skriver koden är samma som testar den, finns det inget behov av att involvera andra som QA.

Nackdelar:

• Utvecklarna som utför strukturbaserad testning måste ha en grundlig förståelse för språket . Andra utvecklare och kvalitetsbedömningar som inte känner till språket kan inte hjälpa till med testning.
• Det kan bli ganska dyrt när det gäller tid och pengar . Det krävs mycket tid och resurser för att testa effektivt.
• Det orsakar förseningar i leverans av funktioner . Detta beror på att utvecklare dras från att bygga programvara för att göra testning.
• Skalning är ett problem, särskilt när stora applikationer är inblandade . En stor applikation motsvarar ett alltför stort antal rutter att täcka. Att uppnå 100% täckning blir omöjligt.
• Det kan saknas fall och rutter , till exempel, i ett fall där funktioner inte är fullt utvecklade eller ännu inte har utvecklats. Det betyder att det måste kombineras med andra testtyper som kravtestning (där vi kontrollerar mot de angivna funktionerna som behövde byggas).

Best Practices för strukturell testning

Några av de faktorer som kräver uppmärksamhet vid utförande av strukturbaserad testning är följande:

• Märk och namnge testerna tydligt . Om någon annan behöver köra testerna måste de kunna hitta dem enkelt.
• Innan du förstärker koden, dvs. genom att omforma den och optimera den för användning i olika miljöer, se till att dess struktur och flöde är idealiska.
• Kör tester separat . På det här sättet är det enkelt att identifiera buggar och fixa dem. Å andra sidan är det mindre troligt att vi missar buggar eller sökvägar till följd av överlappningar i kodavsnitt, block eller sökvägar.
• Skapa tester innan du gör ändringar . Testerna krävs för att köra som förväntat. På det här sättet, om något går sönder, är det lätt att spåra och åtgärda problemet.
• Håll testerna för varje avsnitt eller kodblock separata . På det här sättet, om det finns förändringar längs linjen, behöver vi inte ändra många tester.
• Åtgärda fel innan du går vidare med testningen . Om vi ​​identifierar några buggar är det bättre att fixa dem innan vi fortsätter att testa nästa avsnitt eller kodblock.
• Hoppa aldrig över strukturell testning med antagandet att en kvalitetsbedömning ”fortfarande gör testning ändå”. Även om buggarna kan verka obetydliga i början, kumulativt, kan de resultera i buggykod som aldrig kan uppnå det avsedda syftet.

Vanliga frågor för strukturbaserad testning

Här kommer vi att undersöka de vanliga frågorna när det gäller strukturbaserad testning.

F # 1) Vad är skillnaden mellan funktionell testning och strukturell testning?

Svar: Funktionell testning är en typ av programvarutestning baserad på fastställda krav i SRS (Software Requirements Specifications). Det görs vanligtvis i ett försök att hitta skillnader mellan specifikationerna i SRS och hur koden fungerar. Strukturell testning baseras på kodens interna struktur och dess implementering. En grundlig förståelse av koden krävs.

F # 2) Vilka typer av strukturella tester?

hur man konverterar youtube till wav

Svara typer inkluderar:

• Dataflödestestning
• Mutationstest
• Kontrollera flödestestning
• Skivbaserad testning

F # 3) Vad är ett exempel på strukturell testning?

Svar: Här är ett exempel som visar uttalande:

Hur mycket täckning vi får beror på testdata som vi tillhandahåller som input (om det uppfyller summan> 0 villkor).

F # 4) Vad är skillnaden mellan dataflödestestning och kontrollflödestestning?

Svar: Både dataflödestestning och kontrollflödestestning använder kontrollflödesdiagram. Den enda skillnaden är att vi vid kontrollflödestester fokuserar på de banor som genereras från koden, medan vi i dataflödestester fokuserar på datavärdena, deras definition och användning inom de vägar som identifierats i ett program.

F # 5) Vad används dataflödestester för?

Svar: Dataflödestestning är idealisk för att identifiera avvikelser i användningen av datavärden inom banor i ett kontrollflödesdiagram, till exempel, en variabel som har tilldelats värde två gånger, en variabel som har definierats och inte använts, eller en variabel som har använts eller refererats och inte definierats.

F # 6) Vad är skillnaden mellan skivning och tärning i programvarutestning?

Svar: Skivning innebär att man fokuserar på särskilda intresseanmälningar i ett program och ignorerar resten. Tärning är när vi identifierar en skiva som har fel inmatning och sedan skär den ytterligare för att spåra korrekt beteende.

F # 7) Vad är skillnaden mellan mutationstestning och kodtäckning?

Svar: I mutationstest betraktar vi antalet dödade mutanter som en procentandel av de totala mutanterna. Kodtäckning är helt enkelt den mängd kod som har testats i ett program.

Slutsats

I den här handledningen tittade vi djupt på strukturell testning - vad det är, vad det inte är, hur man ska gå tillväga, täckningstyper, fördelar och nackdelar, bästa praxis och till och med några vanliga frågor om denna programvarutestningstyp.

Det finns fortfarande så mycket mer som vi kan lära oss om strukturbaserad testning. I framtida handledning kommer vi att undersöka kodtäckning (uttalande, beslut, gren och sökväg), strukturella testtyper (mutation, dataflöde och skivbaserad) och till och med de verktyg som vi kan använda för att automatisera dessa testprocesser.

Det är viktigt att notera att det inte finns någon typ av programvara eller metod som är 100% effektiv. Det rekommenderas alltid att kombinera olika testtyper och metoder.

Till exempel, strukturell testning kompletteras i hög grad med kravtestning, eftersom det kan finnas funktioner som kanske inte har utvecklats vid den tidpunkt då strukturbaserad testning genomfördes.

Strukturella testtekniker baseras på de fel som mänskliga programmerare gör när de skriver kod. Antagandet är att programmeraren är expert och vet vad han eller hon kodar, men tar då och då fel.

De olika strukturella testtyperna som vi har tittat på - mutationstest, skivbaserad testning och dataflödestestning kan spåras tillbaka till fel som att använda fel operatör (mutationstest) eller referera till en variabel innan den används (dataflödestestning) .

Rekommenderad läsning

• Handledning med destruktiv testning och icke-destruktiv testning
• Funktionell testning mot icke-funktionell testning
• Vad är testbaserad testteknik?
• Soak Testing Tutorial - Vad är Soak Testing
• SOA Testing Tutorial: Testing Methodology For a SOA Architecture Model
• Lasttestning med HP LoadRunner-handledning
• Vad är gammatestning? Det sista testetappen
• DevOps Testing Tutorial: Hur DevOps kommer att påverka QA-testning?
• Vad är Compliance Testing (Conformance testing)?