Meny

Uppskattningstekniker för programvarutestning (komplett testguide för uppskattning av testinsats)

  • Huvud
  • Teststrategi
  • Uppskattningstekniker för programvarutestning (komplett testguide för uppskattning av testinsats)

software test estimation techniques

Prova Vårt Instrument För Att Eliminera Problem

För framgången för alla projekt är testuppskattningar och korrekt utförande lika viktigt som utvecklingscykeln. Att hålla sig till uppskattningen är mycket viktigt för att bygga ett gott rykte hos kunden.

Erfarenhet spelar en viktig roll i uppskattningen av 'Software Testing Insats'. Att arbeta med olika projekt hjälper till att förbereda en exakt uppskattning av testcykeln. Uppenbarligen kan man inte bara blindt sätta ett antal dagar för någon testuppgift. Testuppskattningen bör vara realistisk och korrekt.

Uppskattningstekniker för programvarutest

I den här artikeln försöker jag sätta några punkter på ett mycket enkelt sätt, vilket är till hjälp för att förbereda korrekt testuppskattning.

Vad du kommer att lära dig:

Kort beskrivning av testuppskattningsprocessen

'Uppskattning är processen att hitta en uppskattning, eller approximation, vilket är ett värde som kan användas för något ändamål även om ingångsdata kan vara ofullständiga, osäkra eller instabila.' (Referens: Wikipedia )

Vi stöter på olika uppgifter och arbetsuppgifter och tidsfrister under våra liv som yrkesverksamma, nu finns det två sätt att hitta en lösning på ett problem.

Ett första tillvägagångssätt är ett reaktivt tillvägagångssätt där vi försöker hitta en lösning på det aktuella problemet först efter det.

I det andra tillvägagångssättet som kan kallas en proaktiv metod där vi först förbereder oss långt innan problemet kommer med våra tidigare erfarenheter och sedan med vår tidigare erfarenhet försöker vi hitta en lösning på utmaningen när den kommer.

Uppskattning kan således betraktas som en teknik som används när vi tar ett proaktivt förhållningssätt till problemet.

Således kan uppskattning användas för att förutsäga hur mycket ansträngning med avseende på tid och kostnad som krävs för att slutföra en definierad uppgift.

När testteamet kan göra en uppskattning av det aktuella problemet är det lättare för dem att komma fram till en lösning som skulle vara optimal för det aktuella problemet.

Uppskattningen kan definieras mer formellt som en ungefärlig beräkning av den sannolika kostnaden för ett arbete.

Läs också=> 7 faktorer som påverkar testuppskattning av Selen Automation Project

De grundläggande förutsättningarna för testuppskattningsprocessen

# 1) Insikter samlade från att arbeta med tidigare erfarenheter : Det är alltid en bra praxis att spendera lite tid och komma ihåg tidigare projekt som ställde utmaningar som liknar den nuvarande strävan.

# 2) Tillgängliga dokument eller artefakter: De testhanteringsförrådsverktyg kommer in praktiskt i dessa typer av scenarier eftersom de lagrar krav och förtydligande dokument. Dessa dokument kan hänvisas av testteamet för att tydligt definiera projektets omfattning.

# 3) Antaganden om typen av arbete: Tidigare arbetserfarenhet hjälper till att göra antaganden om projektet. Det är här anställning av erfarna yrkesverksamma är viktigast.

Testcheferna kan plocka upp hjärnorna hos dessa människor för att leverera de önskade resultaten.

# 4) Beräkning av potentiella risker och hot: Testteamet måste också visualisera de potentiella risker och hot och fallgropar som ligger för teamet i framtiden.

# 5) Bestämma om dokumenten har baslinjerats: Testteamet måste också avgöra om kraven har baslinjerats eller inte. Om dokumenten inte baseras är det viktigt att bestämma hur ofta ändringarna ska ske.

# 6) Alla ansvarsområden och beroenden bör vara tydliga: Organisationen bör tydligt definiera roller och ansvarsområden för alla personer som skulle göra uppskattningsprocessen.

# 7) Dokumentation och spårning av uppskattningsposterna: All relevant information för uppskattningsprocessen ska dokumenteras.

# 8) Aktiviteter som måste utföras under testuppskattningsprocessen

  • Organisera teamet som skulle göra uppskattningar
  • Sönderdela projektet i projektfaser och efterföljande aktiva aktiviteter
  • Beräkna beräkningen baserat på tidigare projekt och yrkeserfarenhet
  • Prioritera de möjliga hoten och kom med metoder för att mildra dessa risker
  • Granska och dokumentera relevant del av arbetet
  • Skicka in arbetet till berörda intressenter

Mest framstående testuppskattningstekniker

Några av de viktigaste teknikerna för testuppskattning är:

  • Uppskattning av testpunkt
  • Arbetsfasbaserad uppskattning
  • Använd uppskattning av fall

Hur och var vi använder dessa tekniker:

# 1) Uppskattning av testpunkt är en enkel och lättförståelig uppskattningsteknik som används i stor utsträckning över programvarutestningsspektrumet. Iterativa faser och enkelhet är de viktigaste funktionerna i just denna teknik.

selen webdriver tutorial java eclipse pdf

# 2) Beräkning av arbetsfasen är den uppskattningsteknik som används varigenom en gissningsuppskattning görs för en viss fas (normalt den kortaste och enklaste av faserna) och sedan adderar testteamet gradvis andra faser i den initiala uppskattningen och kommer slutligen med en lämplig uppskattning.

# 3) Uppskattningsteknik för användningsfall är uppskattningen av användningsfall där den ojusterade aktörens vikter och de ojusterade användningsfallsvikten används för att bestämma uppskattningen av programvarutestningen.

Detaljer om testpunktens uppskattningsteknik

Uppskattningstekniken för testpunkten görs enligt följande steg: -

testpunkt uppskattningsteknik

(Följande vikter som kan variera från projekt till projekt kan övervägas under detta paradigm - Några av dessa vikter är vikten för programmeringsspråket baserat på kodens komplexitet, applikationsvikt baserat på applikationstyp och testvikter som är tilldelas baserat på de olika faserna av testning av programvara.)

Obehandlade testpunkter multipliceras med CWF för att erhålla teststorleken i testpunktsstorlek.

Produktivitetsfaktorn anger hur lång tid en testingenjör har slutfört testningen av en testpunkt

Testansträngningen i personliga timmar beräknas genom att multiplicera testpunktens storlek med produktivitetsfaktorn.

För beräkning av testpunktens uppskattningsteknik beaktar vi följande variabler.

  • Testkravskomplexitet

Testkravskomplexitet

  • Gränssnitt med andra krav

Gränssnitt med andra krav

  • Totalt antal verifieringspunkter

Totalt antal verifieringspunkter

  • Basdata testdata

Basdata testdata

Vi måste sedan överväga viktvektorer för var och en av datavariablerna och organisera dem på följande sätt.

viktvektorer för datavariablerna

Justeringsfaktor = Genomsnitt av (produkt av komplexitetsvikt och faktorvikt) / 30

Justeringstestpunkt för testkassedesign = Total testpunkt X (1 + Justeringsfaktor för testkassedesign)

hur öppnar jag apk-filer

Justerad testpunkt för utförande av testfall = Total testpunkt X (1 + justeringsfaktor för utförande av testfall)

Total testpunkt (normaliserad) X (1 + justeringsfaktor för testfall design / utförande) = justerad testpunkt för testfall design / utförande

Total ansträngning i person timmar (PH) = antal normaliserade testpunkter / produktivitet (i normaliserade testpunkter per person timmar)

Testuppskattningsexempel

Låt oss försöka tillämpa formuleringen ovan i en annan praktisk användning.

Antag att vi slutar med ett testkrav där vi har 5 testscenarier att testa.

Säg nu Testscenario 1 har 5 förväntade testresultat, testscenario 2 6 test förväntade resultat, testscenario 3 endast 2 test förväntade resultat, testscenario 4 9 test förväntade resultat, testscenario 5 också 9 test förväntade resultat.

Så vi klassificerar testscenarierna i tre klasser, dvs. komplexa, enkla och måttliga baserat på det totala antalet förväntade resultat som finns i dessa tre klasser.

Komplexa klasser kommer att ha mer än 7 förväntade resultat medan de enkla kommer att bestå av mindre än 5 förväntade resultat och de måttliga scenarierna skulle bestå av mellan 4 och 7 förväntade resultat.

Vi klassificerar således testscenario 1 och testscenario 2 som måttliga scenarier, scenario 5 och scenario 6 som komplexa och testscenario 3 som enkla.

Vi kommer nu att använda testpunkter för alla dessa scenarier. Vi använder 5 testpunkter för komplexa klasser, 3 för måttliga och 2 för enkla scenarier.

Vi multiplicerar de antagna testpunkterna med det totala antalet förväntade resultat i alla dessa testscenarier. Så vi slutar med följande approximationer.

Scenario 1: 3 testpunkter * 5 test förväntade resultat = Justerade testpunkter = 25
Scenario 2: 3 testpunkter * 6 test förväntade resultat = Justerade testpunkter = 30
Scenario 3: 2 testpunkter * 2 test förväntade resultat = Justerade testpunkter = 4
Scenario 4: 5 testpunkter * 9 test förväntade resultat = Justerade testpunkter = 45
Scenario 5: 5 testpunkter * 9 test förväntade resultat = Justerade testpunkter = 45

Så med tanke på att vi måste ansöka om att säga 5 personstimmar för varje justerad testpunkt får vi följande ungefärliga resultat.

Testscenario 1: 25 justerade testpunkter * 5 Personstimmar = 125 Personstimmar
Testscenario 2: 30 justerade testpunkter * 5 Personstimmar = 150 Personstimmar
Testscenario 3: 4 justerade testpunkter * 5 Personstimmar = 20 Personstimmar
Testscenario 4: 45 justerade testpunkter * 5 Personstimmar = 225 Personstimmar
Testscenario 5: 45 justerade testpunkter * 5 Personstimmar = 225 Personstimmar

Så totalt ungefärliga arbetstimmar är: 745 Personstimmar

Använd uppskattningsmetod för fall

Use-Case Point-metoden baseras på användningsfall där vi beräknar den totala testuppskattningsinsatsen baserat på användningsfall eller kraven.

Här är den detaljerade processen för uppskattningsmetoden Use case point:

Använd metod för uppskattning av fall

Ett exempel på detsamma är att säga i ett visst krav har vi 5 användningsfall, användningsfall 1, användningsfall 2, ..., användningsfall 5 respektive. Låt oss nu överväga att användningsfall 1 består av 6 aktörer, användningsfall 2 består av 15 aktörer, användningsfall 3, 4 och 5, 3, 4 respektive 5 aktörer.

Vi betraktar alla användningsfall som involverar det totala antalet aktörer som mindre än 5 som negativa, varje användningsfall med det totala antalet aktörer är lika med eller mer än 5 och mindre än eller lika med 10 som positivt och varje användningsfall med mer än tio aktörer som exceptionella.

Vi bestämmer oss för att tilldela 2 poäng till undantagsfall, 1 till de positiva och -1 för de negativa.

Således kategoriserar vi användningsfall 1 och 5 som positiva, användningsfall 2 som exceptionella och användningsfall 3, 4 som negativa baserat på våra ovan angivna antaganden.

Så den obearbetade skådespelarens vikter = Use case 1 = (totalt antal aktörer) 5 * 1 (den tilldelade poängen) = 5. På samma sätt

Använd fall 2 = 15 * 2 = 30.

Upprepa processen för resten av användningsfallet får vi de obearbetade aktörens vikter = 33

Obehandlad användningsfallsvikt = totalt antal användningsfall = 5

Obehandlad användningsfallspunkt = Ojusterad aktörsvikt + Ojusterad användningsfallsvikt = 33 + 5 = 38

Bearbetad användningsfall = 38 * (0,65+ (0,01 * 50) = 26,7 eller 28 Personstimmar ungefär

Uppdelningsteknik för arbetsfaser

Uppdelningstekniken för arbetsfasen kan beskrivas i följande steg.

  • Dela upp det övergripande arbetet i faser.
  • Börja med den enklaste fasen och tilldela den ett ungefärligt uppskattningsvärde.
  • Fortsätt sedan med att identifiera nästa möjliga fas som kan påbörjas när denna fas är klar.
  • Hämta en möjlig uppsättning approximationsvärden som kan tillämpas på denna fas och välj det maximala värdet bland alla de härledda approximationsvärdena.
  • Sammanfatta det ungefärliga uppskattningsvärdet genom att lägga till det aktuella uppskattningsvärdet för fasinsats till det redan existerande värdet.
  • Fortsätt steg 3 till 5 tills alla faser som identifierats i det första steget är slut.
  • Acceptera det slutliga ungefärliga uppskattningsvärdet som det ultimata.

Antag att i ett krav finns det 5 nödvändiga faser. Så i den inledande fasen 1 antar vi att de totala ansträngningarna som krävs är 35 arbetstimmar och sedan inleder vi nästa fas 2 för vilken vi har 4 jämförande antaganden om 35, 45, 55 respektive 65.

Så vi betraktar 65 personstimmar som är det maximala värdet här. I fas 3, 4, 5 kommer vi med uppskattningar (12, 33, 43, 54), (15, 10, 7, 8) respektive (2, 16, 5, 13). Genom att tillämpa nämnda princip slutar vi med 185 Personhours.

Jag lägger information om - Hur man uppskattar testinsatser för alla testuppgifter, vilket jag lärde mig av min erfarenhet.

9 allmänna tips om hur man uppskattar testtiden korrekt

Faktorer som påverkar uppskattning av programvarutest och allmänna tips för att uppskatta korrekt:

# 1) Tänk på lite buffertid
Uppskattningen bör innehålla viss buffert. Men lägg inte till en buffert, som inte är realistisk. Att ha en buffert i beräkningen gör det möjligt att hantera eventuella förseningar som kan uppstå. Att ha en buffert hjälper också till att säkerställa maximal testtäckning.

# 2) Tänk på bugcykeln
Testuppskattningen inkluderar också bugcykeln. Den faktiska testcykeln kan ta fler dagar än beräknat. För att undvika detta bör vi överväga det faktum att testcykeln beror på byggnadens stabilitet. Om byggnaden inte är stabil kan utvecklare behöva mer tid att fixa och uppenbarligen utvidgas testcykeln automatiskt.

# 3) Tillgänglighet för alla resurser för beräknad period
Testuppskattningen bör ta hänsyn till alla löv planerade av teammedlemmarna (vanligtvis långa löv) under de närmaste veckorna eller de närmaste månaderna. Detta kommer att säkerställa att uppskattningarna är realistiska.

Uppskattningen bör ta hänsyn till ett visst fast antal resurser för en testcykel. Om antalet resurser minskar bör uppskattningen återbesökas och uppdateras därefter.

# 4) Kan vi göra parallelltestning?
Har du några tidigare versioner av samma produkt så att du kan jämföra utdata? Om ja, kan detta göra din testuppgift lite enklare. Du bör tänka på uppskattningen baserat på din produktversion.

# 5) Uppskattningar kan gå fel - Så besök uppskattningarna ofta i inledande steg innan du gör det.
I de tidiga stadierna bör vi ofta besöka testuppskattningarna och göra en modifiering om det behövs. Vi bör inte förlänga uppskattningen när vi fryser den om det inte finns stora förändringar i kraven.

# 6) Tänk på din tidigare erfarenhet att göra bedömningar!
Erfarenheter från tidigare projekt spelar en viktig roll när de bereder tidsberäkningar. Vi kan försöka undvika alla svårigheter eller problem som stod inför tidigare projekt. Vi kan analysera hur de tidigare uppskattningarna var och hur mycket de hjälpte till att leverera produkten i tid.

# 7) Tänk på omfattningen av projektet
Vet vad som är slutmålet för projektet och lista över alla slutliga resultat. Faktorer som ska beaktas för små och stora projekt skiljer sig mycket åt.

Det stora projektet inkluderar vanligtvis att skapa en testbädd, generera testdata, testskript etc. Därför bör uppskattningarna baseras på alla dessa faktorer. I små projekt inkluderar testcykeln typiskt skrivfall, utförande och regression.

# 8) Kommer du att utföra lasttestning?
Om du behöver lägga mycket tid på prestandatestning, uppskatta därefter. Uppskattningar för projekt, som involverar belastningstestning, bör övervägas annorlunda.

# 9) Känner du ditt team?
Om du känner till styrkor och svagheter hos individer som arbetar i ditt team kan du uppskatta testuppgifter mer exakt. När man uppskattar bör man överväga det faktum att alla resurser kanske inte ger samma produktivitetsnivå. Vissa människor kan köra snabbare jämfört med andra. Även om detta inte är en viktig faktor, lägger det till den totala förseningen av leveranser.

Slutsats

Uppskattning av programvarutest är den praxis som kräver involvering av erfarna yrkesverksamma samt införande av branschövergripande bästa praxis som testfall och använder case point-metoder.

Det är också viktigt för att anta ett öppet sinne för att anpassa de processer som krävs. Det framgångsrika genomförandet av dessa processer leder till en total förbättring av testprocessen.

vad är ett datainsamlingsverktyg

Detta är en gästartikel av författaren “N. Sandhya Rani ”.

Rekommenderad läsning

^