Meny

7 faktorer som påvirker testestimering av selen automatiseringsprosjekt - selen opplæring # 32

  • Hoved
  • Selen Tutorials
  • 7 faktorer som påvirker testestimering av selen automatiseringsprosjekt - selen opplæring # 32

7 factors affecting test estimation selenium automation project selenium tutorial 32

Prøv Instrumentet Vårt For Å Eliminere Problemer

I de siste par Selen-opplæringene lærte vi om automatiseringstesting ved hjelp av agurk- og selenverktøy . Vi diskuterte også om integrering av Selenium WebDriver med Agurk .

I denne opplæringen vil vi diskutere forskjellige faktorer som påvirker innsatsestimering av selen automatisering .

Planlegging og estimering er to viktigste aspekter av en livssyklus for programvareutvikling.

Jeg føler personlig at det er i programvareindustrien ingen skuddsikre metoder av å gjøre hva som helst. Siden hvert prosjekt er eksklusivt og har forskjellige sett med kompleksitet og miljøfaktorer, bør implementering av estimerings- og planleggingsstrategien være et samarbeid mellom de enkelte teamene med riktig inngrep fra seniorer og ledelsesstøtte.

Selen automatisering

Før du begynner å estimere et prosjekt, er det viktig å forstå hver eneste fase som prosjektet ditt vil gjennomgå, slik at du kan gi en riktig og en berettiget estimering.

Estimering kan ikke bare gjøres for den manuelle testprosessen, men i denne tiden av automatisering blir estimeringsteknikker også brukt til å teste automatisering. Nå som Selen får fart og popularitet i markedet, prøver jeg å skrive om noen faktorer som bør tas i betraktning når jeg estimerer et Selen-prosjekt.

La oss begynne!!

Jeg antar at vi starter Automation-initiativet helt fra bunnen av, og at vi ikke har noen ferdige rammer tilgjengelig.

Hva du vil lære:

Faktorer som påvirker estimering av selen automatisering

De ulike faktorene som påvirker og som du bør vurdere for estimering av 'Selen' -spesifikt prosjekt er forklart nedenfor:

# 1 Omfanget av prosjektet

Omfang betyr vanligvis å identifisere de riktige testtilfellene for automatisering. Bruk 'Divide & rule' -strategi for å oppnå det. Bryt søknaden din i små biter eller moduler, og analyser hver av dem for å komme med de riktige testtilfellene for automatisering.

Fremgangsmåten er:

  1. Identifiser de ulike faktorene som vil danne grunnlaget for å identifisere kandidatprøvesakene.
  2. Del applikasjonen i mindre moduler
  3. Analyser hver modul for å identifisere kandidatprøvesakene
  4. Beregn avkastning

For mer informasjon om hvordan du identifiserer riktig testtilfelle, se mitt forrige papir: Valg av riktige testsaker for automatisering

# 2 Kompleksiteten i applikasjonen

Fremgangsmåten som er involvert her er:

  1. Bestem størrelsen på applikasjonen basert på antall testtilfeller som må automatiseres.
  2. Størrelseskompleksitet gjennom Fibonacci-serien.
  3. Identifiser verifiseringspunktet og kontrollpunktet for hvert testtilfelle

Her må vi etablere definisjonen av store / mellomstore og små applikasjoner. Denne definisjonen skiller seg fra et individ- / gruppeperspektiv. Hvordan du klassifiserer søknaden din, avhenger kan også avhenge av antall testsaker.

For eksempel:

Hvis søknaden din har 300 - 500 testtilfeller å automatisere, kan du betrakte den som den små applikasjonen. Hvis testsakene er over 1500, kan det klassifiseres som komplekse. Denne faktoren kan være forskjellig for den forskjellige applikasjonen. For noen kan 1500 testsaker for automatisering betraktes som små / mellomstore. Så når du har identifisert det nøyaktige antallet testsaker, skaler du det til små / mellomstore eller store. Din strategi for å estimere innsatsen vil avhenge av disse kriteriene.

Du må også vurdere de forskjellige sjekkpunktene og bekreftelsespunktene for testsaken din. En testsak kan ha mer enn ett kontrollpunkt

men har bare 1 bekreftelsespunkt. I tilfelle du har mer enn ett verifiseringspunkt, anbefales det å splitte seg i separate testsaker. Dette vil også lette vedlikehold og forbedring av testpakken.

# 3 Bruk av støtteverktøy / teknologier

Fremgangsmåten som er involvert her er:

  1. Identifiser rammeverk og automatiseringsbehov
  2. Basert på behovene, analyser og identifiser verktøyene som skal brukes.
  3. Identifiser avhengighetene / implikasjonene ved å bruke verktøyet.

Selen alene er ikke tilstrekkelig for å bygge et rammeverk eller fullføre automatiseringen. Selenium (webdriver) skript bare testtilfellet, men det er også andre oppgaver, som å rapportere resultatet, spore loggene, ta skjermbilder osv.

For å oppnå disse trenger du separate verktøy som vil bli integrert i rammeverket ditt. Så det er viktig her å identifisere disse støttende enhetene som best passer dine krav og vil bidra til å få en positiv avkastning

# 4 Implementering av rammeverket

Her kommer den vanskelige delen J trinnene involvert er !!

  1. Identifiser inngangen (mønsteret der data blir matet til skriptet) og utdataene (rapporter / testresultater) til automatiseringspakken din.
  2. Design dine innspillingsfiler. Dette kan variere fra en enkel tekstfil til kompleks excel-fil. Det er i utgangspunktet filen som vil ha testdataene dine.
  3. Design mappestrukturen basert på inngangsparametrene og
  4. Implementere rapporteringsfunksjonen (enten i noen Excel-filer eller ved hjelp av et hvilket som helst verktøy som ReportNG)
  5. Bestem / implementer logger i ditt rammeverk
  6. Implementere byggeverktøyet i rammeverket ditt
  7. Implementere enhetens testrammeverk (Junit eller TestNG)

Det er mange andre krav bortsett fra bare skripting i testautomatisering med Selen, som å lese dataene fra en fil, rapportere / spore testresultatene, spore logger, utløse skriptene basert på inngangsforhold og miljø osv. Så vi trenger en struktur som vil ta vare på alle disse skriptene. Denne strukturen er ingenting annet enn ditt rammeverk.

Nettapplikasjoner er av natur kompliserte fordi det innebærer mange støtteverktøy og teknologi å implementere. På samme måte er det også vanskelig å implementere rammeverket i Selen (jeg vil ikke si komplisert), da det innebærer andre verktøy å integrere. Siden vi vet at Selen IKKE er et verktøy, men faktisk en samling / gruppe av jar-filer, er den konfigurert og ikke “Installert”, og Selen er i seg selv ikke sterk nok til å bygge et komplekst rammeverk. Det krever en liste over tredjepartsverktøy for å bygge et rammeverk.

Vi må huske her at det ikke er noe 'ferdig' i Selen. For alt må vi kode, så bestemmelsene i estimering bør være der for å google feilene og feilsøke.

Her må vi forstå at den rammeverket er det viktigste aspektet av automatiseringsarbeidet ditt. Hvis rammeverket ditt er solid, blir vedlikehold og forbedring lettere, spesielt i Agile-tiden, hvis rammeverket ditt er bra, kan du enkelt integrere testene dine i alle sprintene.

Jeg tar ikke feil hvis jeg sier at denne faktoren ved utformingen av rammeverket burde være det viktigste ved estimering. Om nødvendig (som i kompleks applikasjon), bør denne faktoren deles opp igjen i en egen WBS, og estimering bør gjøres.

# 5 Læring og trening

Læring av selen er litt annerledes enn å lære noe annet automatiseringsverktøy. Det innebærer i utgangspunktet å lære et programmeringsspråk enn bare et skriptspråk (selv om skriptspråk hjelper mens du bygger et rammeverk som du vil skrive et skript som vil påkalle dine automatiserte skript etter at du har gjort endringene i miljøinnstillingen).

beste c ++ kompilator for windows

I tilfelle vi kombinerer WebDriver med java, vil jeg si at hvis man er velbevandret med core java, er de i en veldig god form til å begynne med Selen-automatisering.

I tillegg til å lære java, bør det være mulig å lære andre teknologier som ANT / Maven (for bygging), TestNG / jUnit (enhetstestramme), Log4J (for logging), rapportering (for rapportering) osv. Denne listen kan vokse basert på rammeverket. Jo mer denne listen vokser, jo mer tid vil det ta.

Hvis ledelsen har bestemt seg for å gå med selen, kan disse læringsaktivitetene gjøres parallelt med planleggingsaktiviteten. Fordi det ikke er noen grense for å lære disse teknologiene, foreslås det å ha en klar plan (pensum) klar for teamet slik at de kan sette i gang læringsprosessen i en bestemt retning, og alle er på samme side.

Rent praktisk har vi testere ikke veldig lyst til å lære et fullverdig programmeringsspråk, og vi føler at dette er utviklerens kakestykke. Men nå må vi endre denne mentaliteten og bør vurdere å lære programmeringsspråket som like viktig som å lære den nye testprosessen. Dette vil ikke bare øke testernes kunnskap om språket og automatiseringen, men vil også gi en sjanse til å forstå hvordan applikasjonen fungerer internt, noe som kan øke deres muligheter for å finne nye feil.

# 6 Miljøoppsett

Miljøoppsett avtaler med (ikke begrenset til): -

  • Sette opp koden i testmiljøet
  • Sette opp kode i produksjonsmiljø
  • Skrive manus for å utløse automatiserte tester.
  • Utvikler logikken for rapportering
  • Etablere hyppigheten for å kjøre skriptene og utvikle logikk for implementeringen
  • Opprette tekst / excel-filer for å legge inn testdata og testtilfeller
  • Opprette eiendomsfiler for sporing av miljøer og legitimasjon

# 7 Koding / skripting og gjennomgang

Før du begynner å skrive testene dine, er det to forutsetninger:

  1. Kandidatprøvesaker bør være nyttige
  2. Rammeverket er klart

Identifiser forskjellige handlinger som webapplikasjonen din gjør. Det kan være enkle handlinger som navigering, klikk, skriv inn tekst; eller en kompleks handling som å koble til en database, håndtere flash eller Ajax. Ta en testtilfelle om gangen, og identifiser hva all handling gjør i det aktuelle testtilfellet, og estimer timer tilsvarende for hver testtilfelle. Summen av alle timene for hele testpakken gir deg nøyaktig antall.

Avsetning bør også være der for gjennomgang. Evalueringene er ganske enkelt kodegjennomgangen som kan gjøres enten av en jevnaldrende eller en utvikler. Parprogrammering er det beste alternativet som er raskt, men hvis det ikke er mulig, basert på tilgjengelige ressurser eller organisasjons gjennomgangsstrategi, bør det tildeles timer til det.

Flere detaljer om hver faktor som påvirker estimering:

Faktor nr. 1: Omfang

Betydning : Identifisere kandidattestsaker for automatisering gjennom avkastningen

Involverte trinn:

  1. Identifiser de ulike faktorene som vil danne grunnlaget for å identifisere kandidatprøvesakene.
  2. Del applikasjonen i mindre moduler
  3. Analyser hver modul for å identifisere kandidatprøvesakene
  4. Beregn avkastningen

Leveres: Liste over testsaker som må automatiseres.

Merknader: Det er viktig å fryse omfanget ditt når du går videre med andre trinn for estimering.

Faktor nr.2: Kompleksitet

Betydning: Etablere definisjonen av enkel og liten applikasjon.

Involverte trinn:

  1. Størr applikasjonen basert på antall testsaker som må automatiseres.
  2. Størrelseskompleksitet gjennom Fibonacci-serien.
  3. Identifiser verifiseringspunktet og kontrollpunktet for hvert testtilfelle.

Leveres: Søknadens størrelse - liten, middels eller stor.

En rekke testsaker og deres tilhørende kontrollpunkt og verifiseringspunkt.

Merknader : Anbefalt - En testsak kan ha flere kontrollpunkter, men bare 1 verifiseringspunkt. Hvis en testtilfelle har mer enn ett verifiseringspunkt, bør den deles inn i en egen testtilfelle.

Faktor # 3: Støtteverktøy

Betydning: Selen i seg selv er ikke sterk nok til å bygge et komplekst rammeverk. Det krever en liste over rammeverktøy for å bygge et rammeverk.

Involverte trinn:

  1. Ferdiggjort IDE
  2. Avsluttet enhetstestverktøy
  3. Avsluttet logger
  4. Avsluttet rapporteringsverktøy
  5. Ferdiggjort byggeverktøy

Leveres: Liste over verktøy som trengs for å lage rammeverket.

Merknader:

Eksempler:

  • Formørkelse / RAD - som IDE
  • Ant / Maven - Som byggeverktøy
  • jUnit / TestNG - som enhetstestrammer
  • Log4j - som logger
  • ReportiNG - som rapporteringsverktøy
  • Tekstfiler - for å spore miljøer / legitimasjon
  • Excel-filer - for sporing av testdata
  • Perl / Python - for å sette opp et miljø og utløse testskriptene.

Faktor nr. 4: Implementering Framework

Betydning: Oppretting av struktur

Involverte trinn:

  1. Design dine innspillingsfiler.
  2. Design mappestrukturen
  3. Bestem / implementer logger i rammearbeidet ditt
  4. Implementere byggeverktøyet i rammeverket ditt
  5. Implementere enhetens testrammeverk

Leveres:

  • Rammeverk og mappestruktur opprettet i IDE.
  • Excel-ark som inneholder inndataene dine
  • Eiendomsfiler som inneholder miljørelaterte data og legitimasjon.

Merknader: Dette er det mest avgjørende trinnet. Det anbefales å ta med buffertid mens du estimerer, fordi det tar lengre tid enn forventet å feilsøke noe.

Faktor nr. 5: Miljøoppsett

Betydning: Behandler kodeoppsett og nedlasting / forberedelse for kodedistribusjon

Involverte trinn:

  1. Forbered inndatafilen og rapporteringen
  2. Lag det utløsende skriptet

Leveres: Miljøklar

Merknader: Vi bør prøve å bygge vårt rammeverk på en slik måte at koden vår blir distribuert i det nevnte miljøet / boksen.

Jeg burde ikke ta feil hvis jeg sier at med minimale oppføringer i tekstfilene våre (som har URL og legitimasjon), skal koden vår være klar til å kjøres og ROCK!

Faktor 6: Læring og trening

Betydning: Lære et programmeringsspråk og andre støttende teknologier

Involverte trinn: Utarbeid en plan etter dine automatiseringsbehov, og del den med teamet og oppfordre dem til å lære og fortsette i henhold til pensum.

Leveres: Treningsplan og dens tracker som vil spore fremdriften til teamet.

Merknader: Det bør legges vekt på å bygge logikk i stedet for å lære syntaks.

Faktor 7: Koding / skripting og gjennomgang

Betydning: Skrive de faktiske testmanusene og gjennomgå dem

standard gateway er ikke tilgjengelig fortsetter å skje

Involverte trinn:

  1. Test tilfeller og rammeverk er klar.
  2. Ta / del testtilfellene og konverter det til automatiserte skript og følg fremdriften din

Leveres: Automatiserte testskripter

Merknader: den Hele teamet skal delta i å skrive testskriptene ved hjelp av det implementerte rammeverket. Så mens du estimerer, bør innsatsen fra hele teamet tas i betraktning.

Konklusjon :

Når det er sagt om alle disse punktene, ikke glem å ta med administrasjonsomkostninger og litt buffertid i den endelige estimeringen av Selen-automatisering. Den beste og velprøvde måten å gjøre noen beregninger på er å følge WBS-mekanismen (Work Break down Structure). Dette er rett frem og tjener formålet med å implementere behovene for automatiseringsestimering.

Faktorene nevnt ovenfor er de som er basert på min erfaring, men det kan også være andre enheter som kan påvirke strategien.

Tommelfingerregelen her er “Identifiser visse kriterier, del modulene dine eller test case på disse kriteriene; og skaler det ”. Basert på din skalerte figur - du kan komme til en nøyaktig estimering.

Neste opplæring # 33 : Vi avslutter vår mest omfattende Selenium online opplæring gratis opplæringsserier med siste opplæring dvs. ' Seleniumtest intervju spørsmål med svar ”.

Gi oss beskjed hvis du har noen andre tips for innsatsestimering av Selen-prosjekter.

Anbefalt lesing

^