7 factors affecting test estimation selenium automation project selenium tutorial 32
I de senaste paret av Selen-självstudier lärde vi oss om automatiseringstest med hjälp av gurka- och selenverktyget . Vi diskuterade också om integration av Selen WebDriver med Gurka .
I denna handledning kommer vi att diskutera olika faktorer som påverkar uppskattning av selen automatisering .
Planering och uppskattning är två viktigaste aspekterna av en livscykel för programvaruutveckling.
Jag tycker personligen att det finns i programvaruindustrin inga skottsäkra metoder att göra vad som helst. Eftersom varje projekt är exklusivt och har olika uppsättningar av komplexitet och miljöfaktorer, bör genomförandet av uppskattnings- och planeringsstrategin vara ett samarbete mellan de enskilda grupperna med lämpliga interventioner från seniorer och ledningsstöd.
Innan du börjar med att uppskatta något projekt är det viktigt att förstå varje fas som ditt projekt kommer att gå igenom, så att du kan ge en korrekt och motiverad uppskattning.
Uppskattning kan inte bara göras för den manuella testprocessen utan i denna era av automatisering tillämpas uppskattningstekniker också för testautomatisering. Nu får Selen fart och popularitet på marknaden, jag försöker skriva om några faktorer som bör tas i beaktande när jag beräknar ett Selen-projekt.
Låt oss börja!!
Jag antar att vi startar automatiseringsinitiativet från grunden och att vi inte har några färdiga ramar tillgängliga.
Vad du kommer att lära dig:
- Faktorer som påverkar uppskattningen av selenautomatisering
- # 1 Projektets omfattning
- # 2 Ansökans komplexitet
- # 3 Användning av stödjande verktyg / tekniker
- # 4 Implementera ramverket
- # 5 Lärande och träning
- # 6 Miljöinställning
- # 7 Kodning / skript och granskning
- Slutsats:
- Rekommenderad läsning
Faktorer som påverkar uppskattningen av selenautomatisering
De olika faktorer som påverkar och som du bör överväga för uppskattning av ”Selen” -specifikt projekt förklaras nedan:
# 1 Projektets omfattning
Omfattning innebär vanligtvis att identifiera rätt testfall för automatisering. Tillämpa 'Divide & rule' -strategi för att uppnå det. Bryt din applikation i små bitar eller moduler och analysera var och en av dem för att komma med lämpliga testfall för automatisering.
De inblandade stegen är:
- Identifiera de olika faktorer som kommer att ligga till grund för att identifiera kandidatens testfall.
- Dela upp applikationen i mindre moduler
- Analysera varje modul för att identifiera kandidatens testfall
- Beräkna avkastning
För mer information om hur du identifierar rätt testfall, se min tidigare artikel: Val av korrekta testfall för Automation
# 2 Ansökans komplexitet
Steg involverade här är:
- Bestäm applikationens storlek baserat på antalet testfall som behöver automatiseras.
- Storlekskomplexitet genom Fibonacci-serien.
- Identifiera verifieringspunkten och kontrollpunkten för varje testfall
Här måste vi fastställa definitionen av stora / medelstora och små applikationer. Denna definition skiljer sig från ett individuellt / gruppperspektiv. Hur du klassificerar din ansökan beror på kan också bero på antalet testfall.
Till exempel:
Om din ansökan har 300 - 500 testfall att automatisera kan du betrakta den som den lilla applikationen. Om testfallet är över 1500 kan det klassificeras som komplicerat. Denna faktor kan vara annorlunda för olika applikationer. För vissa kan 1500 testfall att automatisera betraktas som små / medelstora skalor. Så när du har identifierat det exakta antalet testfall, skalar du det till små / medelstora eller stora. Din strategi för att uppskatta ansträngningen kommer enormt att bero på dessa kriterier.
Du måste också överväga de olika kontrollpunkterna och verifieringspunkterna för ditt testfall. Ett testfall kan ha mer än en kontrollpunkt
men har bara en verifieringspunkt. Om du har mer än en verifieringspunkt rekommenderas det att dela upp i separata testfall. Detta underlättar också ditt underhåll och förbättring av din testsvit.
# 3 Användning av stödjande verktyg / tekniker
Steg involverade här är:
- Identifiera ramverk och automatiseringsbehov
- Utifrån behoven, analysera och identifiera de verktyg som ska användas.
- Identifiera beroenden / konsekvenserna av att använda verktyget.
Selen ensam räcker inte för att bygga en ram eller slutföra automatiseringen. Selen (webbdrivrutin) kommer bara att skanna testfallet, men det finns också andra uppgifter, som att rapportera resultatet, spåra loggarna, ta skärmdumpar etc.
För att uppnå dessa behöver du separata verktyg som kommer att integreras i ditt ramverk. Så det är viktigt här att identifiera dessa stödjande enheter som bäst passar dina krav och hjälper till att få en positiv avkastning
# 4 Implementera ramverket
Här kommer den knepiga delen J de inblandade stegen är !!
- Identifiera ingången (mönster där data matas in i skriptet) och utdata (rapporter / testresultat) för din automatiseringssvit.
- Designa dina inmatningsfiler. Detta kan sträcka sig från en enkel textfil till komplex excel-fil. Det är i princip filen som kommer att ha dina testdata.
- Designa mappstrukturen baserat på dina inmatningsparametrar och
- Implementera rapporteringsfunktionen (antingen i någon excel-fil eller med något verktyg som ReportNG)
- Bestäm / implementera logger i ditt ramverk
- Implementera byggverktyget i ditt ramverk
- Implementera enhetens testramverk (Junit eller TestNG)
Det finns många andra krav förutom att bara skripta i testautomatisering med Selen, som att läsa data från en fil, rapportera / spåra testresultaten, spåra loggar, utlösa skript baserat på inmatningsförhållanden och miljö etc. Så vi behöver en struktur som tar hand om alla dessa manus. Denna struktur är inget annat än ditt ramverk.
Webbapplikationer är komplexa till sin natur eftersom de involverar massor av stödverktyg och teknik att implementera. På samma sätt är det också svårt att implementera ramen i Selen (jag säger inte komplex) eftersom det involverar andra verktyg att integrera. Eftersom vi vet att Selen INTE är ett verktyg utan faktiskt en samling / grupp av jar-filer, är det konfigurerat och inte 'installerat', men Selen är inte tillräckligt starkt för att bygga ett komplext ramverk. Det kräver en lista med verktyg från tredje part för att skapa en ram.
Vi måste komma ihåg här att det inte finns något 'färdigt' i Selen. För allt måste vi koda, så bestämmelser i uppskattning bör finnas för att googla felen och felsöka.
Här måste vi förstå att den rambyggnaden är den viktigaste aspekten av ditt automatiseringsarbete. Om ditt ramverk är bunnsolid blir underhåll och förbättring lättare, särskilt i Agile-eran, om ditt ramverk är bra kan du enkelt integrera dina tester i alla sprintar.
Jag kommer inte att ha fel om jag säger att denna speciella faktor för utformningen av ramverket bör vara den viktigaste aspekten av uppskattningen. Vid behov (som i komplex applikation) bör denna faktor återuppdelas i en separat WBS och uppskattning bör göras.
# 5 Lärande och träning
Att lära sig selen är lite annorlunda än att lära sig något annat automatiseringsverktyg. Det handlar i grunden om att lära sig ett programmeringsspråk än bara ett skriptspråk (även om skriptspråk hjälper till att bygga ett ramverk som om du vill skriva ett skript som skulle åberopa dina automatiska skript efter att du har gjort miljöinställningarna).
Om vi kombinerar WebDriver med java, skulle jag säga att om man är väl insatt i core-java, är de i en mycket bra form för att börja med Selen-automatisering.
Tillsammans med att lära java, bör bestämmelser finnas där för att lära sig andra tekniker som ANT / Maven (för byggnad), TestNG / jUnit (enhetstestramverk), Log4J (för loggning), rapportering (för rapportering) etc. denna lista kan växa baserat på ramens nivå. Ju mer denna lista växer, desto mer tid tar det.
Om ledningen har beslutat att gå med selen kan dessa inlärningsaktiviteter göras parallellt med planeringsaktiviteten. Eftersom det inte finns någon gräns för att lära sig dessa tekniker föreslås det att en klar plan (kursplan) är redo för teamet så att de kan starta sin inlärningsprocess i en bestämd riktning och alla är på samma sida.
Praktiskt taget har vi testare inte så mycket intresse av att lära oss ett fullfjädrat programmeringsspråk och vi anser att det här är utvecklare. Men nu måste vi ändra denna mentalitet och bör överväga att lära programmeringsspråket vara lika viktigt som att lära oss den nya testprocessen. Detta kommer inte bara att öka testarens kunskaper om språket och automatiseringen utan också ge en chans att förstå hur applikationen fungerar internt, vilket kan öka deras möjligheter att hitta nya buggar.
# 6 Miljöinställning
Miljöupprättande handlar om (inte begränsat till): -
- Ställa in koden i testmiljön
- Konfigurera kod i produktionsmiljö
- Skriva manus för att utlösa de automatiska testerna.
- Utveckla logiken för rapportering
- Upprätta frekvensen för skriptkörning och utveckla logik för dess implementering
- Skapa text / excel-filer för att mata in testdata och testfall
- Skapa egendomsfiler för att spåra miljöer och referenser
# 7 Kodning / skript och granskning
Innan du faktiskt börjar skriva dina tester finns det två förutsättningar:
var används c ++
- Kandidattestfall bör vara praktiska
- Ramverket är klart
Identifiera olika åtgärder som din webbapplikation gör. Det kan vara enkla åtgärder som att navigera, klicka, skriva in text; eller en komplex åtgärd som att ansluta till en databas, hantera flash eller Ajax. Ta ett testfall i taget och identifiera vad all åtgärd det specifika testfallet gör och uppskatta timmar därefter för varje testfall. Summan av alla timmar för hela testpaketet ger dig det exakta antalet.
Försörjningen bör också finnas där för granskning. Granskningarna är helt enkelt kodgranskningen som kan göras antingen av en kollega eller en utvecklare. Parprogrammering är det bästa alternativet som är snabbt, men om det inte är möjligt, baserat på tillgängliga resurser eller organisationsgranskningsstrategi, bör timmar tilldelas för det.
Mer information om varje faktor som påverkar uppskattningen:
Faktor nr 1: Räckvidd
Menande : Identifiera kandidatens testfall för automatisering genom ROI
Steg involverade:
- Identifiera de olika faktorer som kommer att ligga till grund för att identifiera kandidatens testfall.
- Dela upp applikationen i mindre moduler
- Analysera varje modul för att identifiera kandidatens testfall
- Beräkna avkastningen
Levereras: Lista över testfall som behöver automatiseras.
Anmärkningar: Det är viktigt att frysa din räckvidd när du går vidare med andra uppskattningssteg.
Faktor nr 2: Komplexitet
Menande: Upprätta definitionen av enkel och liten applikation.
Steg involverade:
- Storleka applikationen baserat på antalet testfall som behöver automatiseras.
- Storlekskomplexitet genom Fibonacci-serien.
- Identifiera verifieringspunkten och kontrollpunkten för varje testfall.
Levereras: Applikationens storlek - Liten, medelstor eller Stor.
Ett antal testfall och deras motsvarande kontrollpunkt och verifieringspunkt.
Anmärkningar : Rekommenderas - Ett testfall kan ha flera kontrollpunkter men endast 1 verifieringspunkt. Om ett testfall har mer än en verifieringspunkt bör det delas in i ett separat testfall.
Faktor # 3: Stödverktyg
Menande: Selen i sig är inte tillräckligt stark för att bygga en komplex ram. Det kräver en lista med ramverktyg för att bygga en ram.
Steg involverade:
- Slutförd IDE
- Slutfört enhetstestverktyg
- Slutförd logger
- Slutfört rapporteringsverktyg
- Slutfört byggverktyg
Levereras: Lista över verktyg som behövs för att skapa ramverket.
Anmärkningar:
Exempel:
- Eclipse / RAD - som IDE
- Ant / Maven - Som byggverktyg
- jUnit / TestNG - som enhetstestram
- Log4j - som logger
- ReportiNG - som rapporteringsverktyg
- Textfiler - för att spåra miljöer / referenser
- Excel-filer - för spårning av testdata
- Perl / Python - för att ställa in en miljö och utlösa testskript.
Faktor nr 4: Implementering av ramverk
Menande: Skapande av struktur
Steg involverade:
- Designa dina inmatningsfiler.
- Designa mappstrukturen
- Bestäm / implementera logger i ditt ramarbete
- Implementera byggverktyget i ditt ramverk
- Implementera enhetens testramverk
Levereras:
- Ram och mappstruktur skapad i IDE.
- Excel-ark som innehåller dina inmatningsdata
- Egenskapsfiler som innehåller miljörelaterade data och referenser.
Anmärkningar: Detta är det viktigaste steget. Det är tillrådligt att ta med lite buffertid medan du uppskattar eftersom det tar längre tid än förväntat att felsöka lite tid.
Faktor nr 5: Miljöinställning
Menande: Hanterar koduppsättning och nedladdning / förberedelse för koddistribution
Steg involverade:
- Förbered inmatningsfilen och rapporteringen
- Skapa det utlösande skriptet
Levereras: Miljö redo
Anmärkningar: Vi bör försöka bygga vårt ramverk på ett sådant sätt att med minsta krångel distribueras vår kod i nämnda miljö / ruta.
Jag borde inte ha fel om jag säger att med minimala poster i våra textfiler (som har URL och referenser) skulle vår kod vara redo att köras och ROCK!
Faktor nr 6: Lärande och träning
Menande: Lära sig ett programmeringsspråk och andra stödtekniker
Steg involverade: Förbered en plan enligt dina automatiseringsbehov och dela den med teamet och uppmuntra dem att lära sig och fortsätta enligt kursplanen.
Levereras: Träningsplan och dess tracker som spårar lagets framsteg.
Anmärkningar: Tyngdpunkten bör ligga på att bygga logik snarare att lära sig syntax.
Faktor nr 7: Kodning / skript och granskning
Menande: Skriva själva testmanusen och granska dem
Steg involverade:
- Testfall och ramverk är redo.
- Ta / dela upp testfallet och konvertera det till automatiserade skript och spåra dina framsteg
Levereras: Automatiserade testskript
Anmärkningar: Hela teamet ska delta i att skriva testmanusen med hjälp av det implementerade ramverket. Så när man uppskattar bör insatser från hela teamet tas med i beräkningen.
standardgatewayen är inte tillgänglig fix
Slutsats :
Efter att ha sagt om alla dessa punkter, glöm inte att inkludera ledningskostnader och lite buffertid i din slutliga uppskattning av Selen-automatisering. Det bästa och bevisade sättet att göra någon uppskattning är att följa WBS-mekanismen (Work Break down Structure). Detta är rakt fram och tjänar syftet att implementera automatiseringsuppskattningsbehoven.
Faktorerna som nämns ovan är de som bygger på min erfarenhet, men det kan också finnas andra enheter som kan påverka strategin.
Tumregeln här är “Identifiera vissa kriterier, dela dina moduler eller testfall på dessa kriterier; och skala det ”. Baserat på din skalade siffra - du kan komma till en exakt uppskattning.
Nästa handledning # 33 : Vi kommer att avsluta vår mest omfattande Selenium online-utbildningsserier med sista handledning dvs “ Selenium-intervjufrågor med svar ”.
Låt oss veta om du har några andra tips för ansträngningsberäkning av Selen-projekt.
Rekommenderad läsning
- Introduktion till Selen WebDriver - Selen Tutorial # 8
- Effektiv skriptning av selen och felsökning av scenarier - Selen-handledning # 27
- Felsökning av selenskript med loggar (Log4j-handledning) - Selen-handledning # 26
- 30+ bästa selen-självstudier: Lär dig selen med riktiga exempel
- Gurka Selen Tutorial: Gurka Java Selen WebDriver Integration
- Hur man hittar element i Chrome- och IE-webbläsare för att bygga selen-skript - Selen-handledning # 7
- De mest populära testautomatiseringsramarna med fördelar och nackdelar med var och en - Selen Tutorial # 20
- Implementering av vårt första WebDriver Script - Selenium WebDriver Tutorial # 10