Menu

7 faktorer, der påvirker testestimering af selen-automatiseringsprojekt - Selen-tutorial # 32

  • Vigtigste
  • Selen Tutorials
  • 7 faktorer, der påvirker testestimering af selen-automatiseringsprojekt - Selen-tutorial # 32

7 factors affecting test estimation selenium automation project selenium tutorial 32

Prøv Vores Instrument Til At Fjerne Problemer

I de sidste par Selen-tutorials lærte vi om automatiseringstest ved hjælp af agurk- og selenværktøj . Vi diskuterede også om integration af Selen WebDriver med agurk .

I denne vejledning vil vi diskutere forskellige faktorer, der påvirker indsatsestimering af Selen-automatisering .

Planlægning og estimering er to vigtigste aspekter af en softwareudviklings livscyklus.

Jeg føler personligt, at der i softwareindustrien er der ingen skudsikre metoder at gøre noget. Da hvert projekt er eksklusivt og har forskellige sæt af kompleksitet og miljømæssige faktorer, bør implementering af estimerings- og planlægningsstrategien være en samarbejdsindsats fra de enkelte teams med ordentlige interventioner fra seniorer og ledelsesstøtte.

Selen automatisering

Før du begynder med at estimere et projekt, er det bydende nødvendigt at forstå hver eneste fase, som dit projekt vil gennemgå, så du kan give et korrekt og en berettiget estimering.

Estimering kan ikke kun udføres for den manuelle testproces, men i denne tidsalder med automatisering anvendes estimeringsteknikker også til testautomatisering. Nu får Selen fart og popularitet på markedet, jeg prøver at skrive om nogle faktorer, der skal tages i betragtning, når jeg estimerer et Selen-projekt.

Lad os begynde!!

Jeg antager, at vi starter Automation-initiativet fra bunden, og at vi ikke har nogen færdige rammer til rådighed.

Hvad du lærer:

Faktorer, der påvirker estimering af selen automatisering

De forskellige faktorer, som påvirker, og som du bør overveje for estimering af et 'Selen' -specifikt projekt, forklares nedenfor:

# 1 Projektets omfang

Omfang betyder typisk at identificere de korrekte testsager til automatisering. Anvende 'Opdel og styr' -strategi for at opnå det. Opdel din applikation i små bidder eller moduler, og analyser hver af dem for at komme med de relevante testcases til automatisering.

De involverede trin er:

  1. Identificer de forskellige faktorer, der vil danne grundlag for identifikation af kandidat-testsagerne.
  2. Opdel applikationen i mindre moduler
  3. Analyser hvert modul for at identificere kandidatprøvesagerne
  4. Beregn ROI

For flere detaljer om, hvordan du identificerer den korrekte testsag, se venligst mit tidligere papir: Valg af korrekte testsager til automatisering

# 2 Ansøgningens kompleksitet

De involverede trin her er:

  1. Bestem størrelsen på applikationen baseret på antallet af testsager, der skal automatiseres.
  2. Størrelseskompleksitet gennem Fibonacci-serien.
  3. Identificer verifikationspunktet og kontrolpunktet for hver testtilfælde

Her er vi nødt til at etablere definitionen af ​​store / mellemstore og små applikationer. Denne definition adskiller sig fra et individuelt / gruppeperspektiv. Hvordan du klassificerer din ansøgning, afhænger også af antallet af testsager.

For eksempel:

Hvis din applikation har 300 - 500 testsager, der skal automatiseres, kan du betragte den som den lille applikation. Hvis testsagerne er over 1500, kan det klassificeres som komplekst. Denne faktor kan være forskellig for de forskellige applikationer. For nogle kan 1500 testsager til automatisering betragtes som små / mellemstore skaleret. Så når du har identificeret det nøjagtige antal testsager, skaleres det til lille / medium eller stor. Din strategi til at estimere indsatsen afhænger meget af disse kriterier.

Du skal også overveje de forskellige kontrolpunkter og verifikationspunkter for din testsag. En testsag kan have mere end 1 kontrolpunkt

men har kun 1 verifikationspunkt. Hvis du har mere end 1 verifikationspunkt, anbefales det at fordele sig i separate testsager. Dette letter også din vedligeholdelse og forbedring af din testpakke.

# 3 Brug af understøttende værktøjer / teknologier

De involverede trin her er:

  1. Identificer rammer og automatiseringsbehov
  2. Baseret på behovene, analyser og identificer de værktøjer, der skal bruges.
  3. Identificer afhængigheder / implikationer ved at bruge værktøjet.

Selen alene er ikke tilstrækkelig til at opbygge en ramme eller gennemføre automatiseringen. Selenium (webdriver) scripter kun testkassen, men der er også andre opgaver, såsom rapportering af resultatet, sporing af logfiler, optagelse af skærmbilleder osv.

For at opnå disse har du brug for separate værktøjer, der integreres i din ramme. Så det er vigtigt her at identificere disse understøttende enheder, der bedst passer til dine krav og vil hjælpe med at få et positivt investeringsafkast

# 4 Implementering af rammen

Her kommer den vanskelige del J de involverede trin er !!

  1. Identificer input (mønster, hvor data indføres i script) og output (rapporter / testresultater) til din automatiseringspakke.
  2. Design dine inputfiler. Dette kan variere fra en simpel tekstfil til en kompleks excel-fil. Det er grundlæggende den fil, der har dine testdata.
  3. Design mappestrukturen baseret på dine inputparametre og
  4. Implementér rapporteringsfunktionen (enten i en eller anden excel-fil eller ved hjælp af et hvilket som helst værktøj som ReportNG)
  5. Bestem / implementer logger i dine rammer
  6. Implementér buildværktøjet i dine rammer
  7. Implementere enhedstestrammen (Junit eller TestNG)

Der er mange andre krav bortset fra bare scripting i testautomatisering med Selen, som at læse data fra en fil, rapportere / spore testresultaterne, spore logfiler, udløse scripts baseret på inputbetingelser og miljø osv. Så vi har brug for en struktur der tager sig af alle disse scripts. Denne struktur er intet andet end din ramme.

Webapplikationer er komplekse af natur, fordi de involverer masser af understøttende værktøjer og teknologi til implementering. På samme måde er implementering af rammen i Selen også vanskelig (jeg vil ikke sige kompleks), da det involverer andre værktøjer at integrere. Da vi ved, at Selen IKKE er et værktøj, men faktisk en samling / gruppe af jar-filer, er det konfigureret og ikke “Installeret”, og Selen selv er ikke stærk nok til at opbygge en kompleks ramme. Det kræver en liste over tredjepartsværktøjer til opbygning af en ramme.

Vi er nødt til at huske her, at der ikke er noget 'færdigt' i Selen. For alt skal vi kode, så bestemmelser i estimering skal være der til googling af fejlene og fejlfinding.

Her skal vi forstå, at denne rammebygning er det vigtigste aspekt af din automatiseringsindsats. Hvis din ramme er bunnsolid, bliver vedligeholdelse og forbedring lettere, især i Agile-tiden, hvis din ramme er god, kan du nemt integrere dine tests i alle sprints.

Jeg tager ikke fejl, hvis jeg siger, at denne særlige faktor ved designet af rammen skal være det vigtigste aspekt af estimering. Hvis det er nødvendigt (som i kompleks anvendelse), skal denne faktor igen opdeles i en separat WBS, og estimering skal foretages.

# 5 Læring og træning

At lære selen er lidt anderledes end at lære noget andet automatiseringsværktøj. Det indebærer grundlæggende at lære et programmeringssprog end bare et scriptingsprog (selvom script sprog hjælper med at opbygge en ramme som du vil skrive et script, der vil påkalde dine automatiserede scripts efter at have foretaget ændringer i miljøindstillinger).

Hvis vi kombinerer WebDriver med java, vil jeg sige, at hvis man er velbevandret med core java, er de i en meget god form til at starte med Selen-automatisering.

Sammen med at lære java, bør der være bestemmelser for at lære andre teknologier som ANT / Maven (til bygning), TestNG / jUnit (enhedstestramme), Log4J (til logning), rapportering (til rapportering) osv. Denne liste kan vokse baseret på rammens niveau. Jo mere denne liste vokser, jo mere tid vil det tage.

Hvis ledelsen har besluttet at gå med selen, kan disse læringsaktiviteter udføres parallelt med planlægningsaktiviteten. Da der ikke er nogen grænse for at lære disse teknologier, foreslås det at have en bestemt plan (pensum) klar til holdet, så de kan starte deres læringsproces i en bestemt retning, og alle er på samme side.

Praktisk set har vi testere ikke meget lyst til at lære et fuldt udviklet programmeringssprog, og vi føler, at dette er udviklerens stykke. Men nu er vi nødt til at ændre denne mentalitet og bør overveje at lære programmeringssprog at være lige så vigtigt som at lære den nye testproces. Dette vil ikke kun øge testers viden om sprog og automatisering, men også give en chance for at forstå, hvordan applikationen fungerer internt, hvilket kan øge deres muligheder for at finde nye fejl.

# 6 Opsætning af miljø

Opsætning af miljø handler med (ikke begrænset til): -

  • Opsætning af koden i testmiljøet
  • Opsætning af kode i produktionsmiljø
  • Skrivning af scripts til udløsning af automatiserede tests.
  • Udvikling af logikken til rapportering
  • Etablering af hyppigheden af ​​kørsel af scripts og udvikling af logik til implementering
  • Oprettelse af tekst / excel-filer til indtastning af testdata og testsager
  • Oprettelse af ejendomsfiler til sporing af miljøer og legitimationsoplysninger

# 7 Kodning / scripting og gennemgang

Før du begynder at skrive dine prøver, er der to forudsætninger:

det understøtter interviewspørgsmål og svar pdf
  1. Kandidatprøvesager skal være praktisk
  2. Framework er klar

Identificer forskellige handlinger, som din webapplikation udfører. Det kan være enkle handlinger som navigation, klik, indtastning af tekst; eller en kompleks handling som at oprette forbindelse til en database, håndtere flash eller Ajax. Tag en testtilfælde ad gangen, og identificer, hvad alle handlinger den pågældende testtilfælde gør, og estimer timer i overensstemmelse hermed for pr. Summen af ​​alle timer for hele testpakken giver dig det nøjagtige antal.

Bestemmelser bør også være der til gennemgang. Anmeldelserne er simpelthen kodevurderingen, som kan udføres enten af ​​en peer eller en udvikler. Parprogrammering er den bedste løsning, som er hurtig, men hvis det ikke er muligt, baseret på de tilgængelige ressourcer eller organisationers gennemgangsstrategi, skal der tildeles timer til det.

Flere detaljer om hver faktor, der påvirker estimering:

Faktor nr. 1: Omfang

Betyder : Identificering af kandidat-testsager til automatisering gennem ROI

Involverede trin:

  1. Identificer de forskellige faktorer, der vil danne grundlag for identifikation af kandidat-testsagerne.
  2. Opdel applikationen i mindre moduler
  3. Analyser hvert modul for at identificere kandidatprøvesagerne
  4. Beregn ROI

Leveres: Liste over testsager, der skal automatiseres.

Bemærkninger: Det er vigtigt at fryse dit omfang, når du fortsætter med andre estimeringstrin.

Faktor nr. 2: Kompleksitet

Betyder: Fastlæg definitionen af ​​ligetil og lille applikation.

Involverede trin:

  1. Størr applikationen på baggrund af antallet af testsager, der skal automatiseres.
  2. Størrelseskompleksitet gennem Fibonacci-serien.
  3. Identificer verifikationspunktet og kontrolpunktet for hver testtilfælde.

Leveres: Applikationens størrelse - Lille, medium eller Stor.

Et antal testsager og deres tilsvarende kontrolpunkt og verifikationspunkt.

Bemærkninger : Anbefalet - En testsag kan have flere kontrolpunkter, men kun 1 verifikationspunkt. Hvis en testsag har mere end 1 verifikationspunkt, skal den splittes i en separat testsag.

Faktor nr. 3: Støttende værktøjer

Betyder: Selen i sig selv er ikke stærk nok til at opbygge en kompleks ramme. Det kræver en liste over rammeværktøjer til opbygning af en ramme.

Involverede trin:

  1. Afsluttet IDE
  2. Afsluttet enhedstestværktøj
  3. Afsluttet logger
  4. Afsluttet rapporteringsværktøj
  5. Afsluttet byggeværktøj

Leveres: Liste over nødvendige værktøjer til at skabe rammen.

Bemærkninger:

Eksempler:

  • Formørkelse / RAD - som IDE
  • Ant / Maven - Som byggeværktøj
  • jUnit / TestNG - som enhedstestramme
  • Log4j - som logger
  • ReportiNG - som rapporteringsværktøj
  • Tekstfiler - til sporing af miljøer / legitimationsoplysninger
  • Excel-filer - til sporing af testdata
  • Perl / Python - til opsætning af et miljø og udløsning af testscripts.

Faktor nr. 4: Implementeringsramme

Betyder: Oprettelse af struktur

Involverede trin:

  1. Design dine inputfiler.
  2. Design mappestrukturen
  3. Bestem / implementer logger i dit rammearbejde
  4. Implementér buildværktøjet i dine rammer
  5. Implementere enhedstestrammen

Leveres:

  • Ramme og mappestruktur oprettet i IDE.
  • Excel-ark, der indeholder dine inputdata
  • Ejendomsfiler, der indeholder miljørelaterede data og legitimationsoplysninger.

Bemærkninger: Dette er det mest afgørende skridt. Det tilrådes at medtage en vis buffertid, mens du estimerer, fordi noget tid til fejlfinding tager mere tid end forventet.

Faktor nr. 5: Opsætning af miljø

Betyder: Beskæftiger sig med kodeopsætning og download / forberedelse til implementering af kode

Involverede trin:

  1. Forbered inputfilen og rapporteringen
  2. Opret det udløsende script

Leveres: Miljø klar

Bemærkninger: Vi bør prøve at opbygge vores ramme på en sådan måde, at vores kode med mindst besvær implementeres i det nævnte miljø / boks.

Jeg bør ikke tage fejl, hvis jeg siger, at vores kode skal være klar til at køre og ROCK med minimale poster i vores tekstfiler (som har URL og legitimationsoplysninger)!

Faktor nr. 6: Læring og træning

Betyder: At lære et programmeringssprog og andre understøttende teknologier

Involverede trin: Forbered en plan i henhold til dine automatiseringsbehov, og del den med teamet og opfordre dem til at lære og fortsætte som beskrevet i pensum.

Leveres: Træningsplan og dens tracker, der sporer holdets fremskridt.

Bemærkninger: Der skal lægges vægt på at opbygge logik snarere at lære syntaks.

Faktor nr. 7: Kodning / scripting og gennemgang

Betyder: Skrive de faktiske testskripter og gennemgå dem

Involverede trin:

  1. Testcases og rammer er klar.
  2. Tag / del testsagerne, og konverter det til automatiserede scripts, og følg dine fremskridt

Leveres: Automatiske testskripter

Bemærkninger: Hele holdet skal deltage i at skrive testskripterne ved hjælp af den implementerede ramme. Så mens man estimerer, skal indsatsen fra hele holdet tages i betragtning.

bedste program til at downloade youtube videoer

Konklusion :

Når det er sagt om alle disse punkter, så glem ikke at medtage administrationsomkostninger og noget buffertid i dit endelige Selen-automatiseringsestimat. Den bedste og afprøvede måde at foretage et skøn på er at følge WBS-mekanismen (Work Break down Structure). Dette er ligetil og tjener formålet med at implementere automatiseringsestimeringsbehovene.

De ovennævnte faktorer er dem, der er baseret på min erfaring, men der kan også være andre enheder, der kan påvirke strategien.

Tommelfingerreglen her er “Identificer bestemte kriterier, del dine moduler eller test case på disse kriterier; og skaler det ”. Baseret på din skalerede figur - kan du komme til et nøjagtigt skøn.

Næste tutorial # 33 : Vi vil afslutte vores mest omfattende Selenium online træning gratis tutorials-serie med sidste tutorial dvs. “ Selenium-testspørgsmål med svar ”.

Fortæl os, hvis du har andre tip til estimering af indsats af Selen-projekter.

Anbefalet læsning

^