Menu

10-trins automatiseringstestproces: Sådan starter du automatiseringstest i din organisation

10 step automation testing process

Prøv Vores Instrument Til At Fjerne Problemer

Automatiseringstestproces: Lær, hvordan du starter automatiseringstest på dit projekt (en trinvis vejledning)

I mange organisationer er kvalitet den første præference. Hvis det viser sig, at du befinder dig i en sådan organisation, og der stadig ikke er nogen formel testautomatisering, kan du være den person, der indvier den.

Det vil hjælpe din organisation med at opbygge flere kvalitetsprodukter på kortere tid og ligeledes være i stand til at markedsføre det tidligt.

=> I dette tredje stykke af ' Test automatiseringsvejledningsserier ”, Jeg vil diskutere, hvad der er testautomatiseringsproces og hvordan man starter testautomatisering i din organisation . Det er vigtigt at forstå, hvilket trin der er at udføre først, og hvorfor.

At holde fast ved disse trin hjælper dig med at introducere automatisering på en problemfri måde og giver dig mulighed for at afværge almindelige faldgruber, som fører til automatiseringsfejl.

trin til introduktion af testautomatisering

Hvad du lærer:

10-trins automatiseringstestproces for at starte testautomatisering

Her er en trin-for-trin testautomatiseringsproces og vejledning, der hjælper dig med at starte automatiseringstest.

Lad os begynde.

Trin 1.Overbevis ledelsen

Uanset hvor meget du er ivrig efter at opdage og igangsætte testautomatisering i din organisation, kan du ikke gøre noget, hvis din ledelse ikke er overbevist om fordelene ved testautomatisering. Det er en universel kendsgerning, at testautomatisering er dyr. Værktøjerne er dyre ( HP QTP / UFT licens koster omkring $ 8K pr. maskine). Der er omkostninger ved en testautomationsarkitekt eller ingeniør (som forresten også er dyre). Derefter kan fordelene ved testautomatisering ikke ses med det samme. Du skal vente 2-3 måneder, før dine scripts er klargjort, testet, og det kan køre pålideligt for dig at teste applikationen.

Du er nødt til at overbevise ledelsen om at bære smerten ved disse udgifter, og du skal også fortælle dem at være tålmodige, før testautomatisering kan begynde at give dem resultater.

Så hvordan vil de blive overbevist? Du er nødt til at fortælle dem cost-benefit-analysen. Som om du kan stille spørgsmål, hvor meget tid vi tager på at teste BAT (Build Acceptance Testing) af vores ansøgning? Så kan du sige, hvis det tager en dag, med testautomatisering kan vi teste det inden for 2 timer. Omkostningerne er, at du skal købe værktøjet, træne ressourcen og vente på resultaterne i to måneder. Efter to måneder vil vi være i stand til at køre en BAT om to timer. Det sparer 6 timers manuel test hver gang, når en ny version frigives. Hvis build frigives 4 gange om måneden. Du vil være i stand til at spare 24 timer eller 3 dages manuel test!

Det betyder ikke, at manuelle testere ikke vil gøre noget. De bruger disse 6 timers test til at fokusere på nye og vigtige funktioner i applikationen, mens automatisering tager sig af regressionsproblemerne. Denne opsætning vil generelt forbedre produktets kvalitet et dusin gange.

Hvis din ledelse ikke er villig til at betale for kvaliteten af ​​deres produkter, kan ingen tvinge dem til at gøre det. De lærer automatisk, når kunder klager over produkterne. Kvalitet påvirker alt. Det påvirker dit salg, det påvirker dit forhold til kunder, det påvirker din opfattelse hos forbrugerne. Så intelligent ledelse har altid investeret i kvaliteten af ​​deres produkter.

Så fem punkter at huske på at overbevise din ledelse:

  1. Fortæl dem om fordelene ved testautomatisering i detaljer.
  2. Fortæl dem, at testautomatisering er dyrt, og det vil koste dig penge i første omgang, men derefter vil omkostningerne blive reduceret, når scripts er klargjort og begynde at udføre.
  3. Fortæl dem, at de skal vente i omkring 3 måneder, før de forventer noget resultat fra testautomatisering.
  4. Fortæl dem, at testautomatisering ikke er at erstatte manuelle testere, men at hjælpe manuelle testere, da de er i stand til at teste mere på samme tid.
  5. Testautomatisering betyder ikke mere test på kortere tid; det betyder mere test på samme tid. (Hvis manuelle testere brugte til at teste BAT om 8 timer, vil de være i stand til at teste BAT plus ny funktionalitet plus mange andre ting i de samme 8 timer i nærvær af automatisering.)

Husk, at overbevise din ledelse er det første og vigtigste trin i introduktionen af ​​testautomatisering i din organisation. Hvis de ikke er overbeviste, skal du glemme testautomatisering eller ændre din organisation. :)

Trin 2.Find eksperter på automatiseringsværktøjer

Der er to slags automatiseringseksperter.

  1. Automatiseringsarkitekter
  2. Automatiseringsingeniører

Automatiseringsarkitekter er en sjælden race. De er svære at finde, ekstremt dyre og yderst nødvendige for succesen med automatiseringsprojektet. Disse mennesker er normalt ansvarlige for at oprette automatiseringsrammer. (Vi vil diskutere automatiseringsrammer detaljeret i en separat artikel)

Automatiseringsarkitekter opleves i forskellige slags værktøjer, og de kender normalt styrker og svagheder ved hvert værktøj. De vil også hjælpe ledelsen med at vælge det rigtige værktøj til automatisering ved nøje at analysere applikationen og teknologierne, der anvendes i den applikation . De hjælper også med at opbygge rammen, designe navngivningskonventionerne og skabe regler for scripting. De hjælper også med at vælge, hvilke testsager der skal automatiseres først.

Hvis du er i stand til at finde den rigtige ressource til stillingen som automatiseringsarkitekt, udføres dit halve arbejde i vellykket automatisering i din organisation

Automatiseringsingeniører derimod er de mennesker, der vil konvertere manuelle testsager til automatiserede scripts. De vil arbejde under en automatiseringsarkitekt og vil være ansvarlig for oprettelse og udførelse af scripts .

Nogle virksomheder ansætter automatiseringsingeniører udefra, og nogle virksomheder ansætter internt ved at uddanne deres eksisterende manuelle testere. Uanset hvad der er tilfældet, skal ressourcen være god til programmering. Han / hun skal vide især om objektorienteret programmering. En kombination af 1 automatiseringsarkitekt og to automatiseringsingeniører er fantastisk til de fleste af produkterne.

Trin # 3.Brug af det rigtige værktøj til automatisering

Dette punkt fortjener sin egen artikel (og jeg vil skrive en om det). Dette er endnu et vanskeligt trin i processen med at starte automatisering. Der er forskellige værktøjer på markedet, men du skal vælge de, der er bedst til din applikation.

For at gøre det kort vil jeg skrive de vigtigste overvejelser, mens jeg vælger værktøjet. Jeg vil forklare procesudvælgelsesprocessen detaljeret i en separat artikel.

De vigtigste ting, du skal overveje, når du vælger de rigtige værktøjer, er:

  1. Værktøjet skal være i din budget . Automatiseringsværktøjerne er virkelig dyre. Så virksomheden skal have budgettet til at købe værktøjet.
  2. Værktøjet skal supportteknologier bruges i din ansøgning. Hvis din applikation bruger flash eller Silverlight, skal værktøjet understøtte det. Hvis din applikation kører på mobil, skal værktøjet være i stand til at udføre scripts på mobil. Du kan købe et enkelt værktøj, der understøtter alle teknologier, der bruges i din applikation, eller du kan købe separate værktøjer til hver teknologi. For eksempel , kan du bruge selen til dine webapplikationer, robotter til dine Android-applikationer og MS-kodet brugergrænseflade til desktop-applikationer. Uanset hvilken beslutning det skal være, skal dette være i dit budget.
  3. Du skal have det nødvendige dygtige ressourcer der kan bruge dette værktøj eller lære det værktøj på kortere tid. For eksempel , du har hyret automatiseringsarkitekten, der kun har oplevet QTP, og du køber en licens til MS Coded UI, ressourcen er muligvis ikke behagelig at bruge den. Værktøjer er som gode biler, men du skal også have gode chauffører for at køre disse gode biler.
  4. Værktøjet skal have en god rapporteringsmekanisme at vise resultaterne for interessenter efter hver udførelse.

Der er forskellige andre faktorer, når du vælger det rigtige værktøj, og jeg vil dække dem i en separat artikel.

Læs denne vejledning for de nyeste top automatiseringsværktøjer:

Top 20 bedste værktøjer til automatiseringstest i 2020 (omfattende liste)

Trin # 4.Analyse af forskellige applikationer for at bestemme dem, der er bedst egnede til automatisering

Hvis din organisation arbejder på 5 applikationer, er det ikke nødvendigt, at hver skal automatiseres. Vi skal se de forskellige faktorer, mens vi vælger et hvilket som helst program, der skal automatiseres.

Den applikation, der skal automatiseres, skal have følgende faktorer:

  1. Ansøgningen bør ikke være i de tidlige stadier af dens udvikling. (Ansøgningen skal have alle eller nogle moduler, der er stabile og testet af manuelle testere)
  2. Applikationens brugergrænseflade skal være stabil. (Brugergrænsefladen må ikke ændres hyppigt)
  3. De manuelle test tilfælde af denne ansøgning skal være i skriftlig form.

Hovedmålet med automatisering er at sikre, at hvis applikationen er fejlfri i en build, skal den forblive fejlfri i den næste version. Den manuelle tester bør ikke spilde deres tid på at finde problemer med regression, disse problemer skal identificeres i automatisering.

Så for at finde en regression skal vi have en applikation, der allerede er stabil og har nogle testcases skrevet til den. Automatiseringsteamet konverterer disse testtilfælde til scripts og kører disse scripts på hver build for at sikre, at ingen regression vises.

Læs også => Sådan vælges korrekte testtilfælde til automatiseringstest

Trin # 5.Træning af holdet

Efter værktøjsvalg og ressourceudlejning er det næste trin logisk uddannelse af ressourcerne.

Hvis manuelle testere omdannes til automatiseringsingeniører, skal de trænes i automatiseringsterminologier og -koncepter. Hvis der ansættes automatiseringsarkitekt udefra, skal han få viden om produktet, der skal testes, den manuelle testproces og hvad ledelsen forventer.

Giv ressourcerne lidt tid til at prøve forskellige ting, indtil de endelig kommer med en vindende automatiseringsstrategi. Træn dem på de værktøjer, som organisationen allerede bruger bug tracking software og software til kravstyring .

God træning og stærk kommunikation mellem manuelle testere, udviklere og automatiseringsteam er virkelig nødvendigt.

Trin # 6.Oprettelse af testautomatiseringsrammen

Den største opgave for automatiseringsarkitekten er at komme med en automatiseringsramme, der skal understøtte automatiseret test i det lange løb.

Automatiseringsrammer er grundlæggende sæt af regler og omhyggelig planlægning for at skrive scripts på en måde, der resulterer i mindst mulig vedligeholdelse. Hvis der ændres noget i applikationen, har scriptsne kun brug for lidt eller ingen opdatering for at klare den ændring. Det er skønheden i en automatiseringsramme.

Der er fem slags automatiseringsrammer, nemlig lineær, modulær, datadrevet, søgeordsdrevet og hybrid. Alle disse rammer vil blive dækket detaljeret med eksempler i en separat artikel i denne serie.

Du kan også begynde at læse mere om automatiseringsrammer i følgende tutorials:

=> Hvorfor har vi brug for rammer til testautomatisering?
=> QTP Framework eksempler
=> Selenium Framework eksempler

Trin # 7.Udvikling af en udførelsesplan

Udførelsesplanen inkluderer valg af miljøer, som scriptsne skal udføres. Miljøet inkluderer OS, Browser og forskellige hardwarekonfigurationer.

For eksempel , hvis testsagen kræver, at den skal kontrollere hjemmesiden i 3 browsere, nemlig Chrome, Firefox og IE, så vil automatiseringsteamet skrive scriptet på en sådan måde, at det vil være i stand til at udføre i hver browser.

Dette skal altid fortælles, før man skriver scriptsne, fordi det bliver taget hånd om i scripts, hvis automatiseringsteamet ved det på forhånd. Udførelsesplanen skal også angive, at hvem der udfører scripts. Normalt udfører automatiseringsteamet scripts på hver build, men det varierer fra firma til virksomhed. Nogle ledere beder udviklere om at udføre disse scripts på deres build inden frigivelse, og nogle virksomheder ansætter en dedikeret ressource kun til udførelsen. Selv nogle virksomheder kører scripts i uovervåget tilstand, hvilket naturligvis ikke kræver nogen yderligere ressource.

Trin # 8.Skrivning af manuskripter

Når rammen er designet, er udførelsesplanen kendt, og ressourcer trænes i det nye værktøj, nu er det det rigtige tidspunkt at begynde at skrive scripts.

Scripts skal skrives på en organiseret måde med korrekt navngivningskonvention. Kildekoden skal opretholdes i en kildekontrol for at undgå kodetab. Versionskontrol og historik skal opretholdes. Testautomatisering er ligesom softwareudvikling. Alle bedste programmeringsmetoder skal tages hånd om, mens du skriver manuskripterne.

Læs også => Sådan oversættes manuelle testtilfælde til automatiseringsskripter

Trin 9.Rapportering

Rapporteringsfunktionen leveres normalt af værktøjet. Men vi kan oprette tilpassede rapporteringsmekanismer som automatisk e-maile resultaterne til ledelsen.

Vi kan oprette rapporter i slutningen af ​​hver udførelse i form af diagrammer og tabeller, hvis ledelsen har brug for det. Ledelsen skal altid informeres om dækningen af ​​testsagen, hvilket betyder, hvilke manuelle testsager, der er dækket af automatisering, og hvilke af dem der er tilbage.

Trin # 10.Vedligeholdelse af scripts

Hvis den bedste programmeringspraksis følges, og rammerne er gode, er vedligeholdelse ikke et problem.

Vedligeholdelse sker normalt, når der er en ændringsanmodning om en applikation. Scripts skal straks opdateres for at klare denne ændring for at sikre fejlfri udførelse.

For eksempel , hvis du skriver noget tekst i tekstboksen gennem scriptet, og nu bliver dette tekstfelt til rullelisten, skal vi straks opdatere scriptet.

Nogle andre former for ændringer inkluderer, at dine scripts kørte på den engelske version af applikationen. Nu er der en ændringsanmodning om, at applikationen skal understøtte kinesisk. Din ramme skal give dig mulighed for at opdatere dine scripts med lidt indsats for at understøtte udførelse på kinesisk også! Derfor er automatiseringsarkitekter dyre. :)

Hvis rammen ikke er god, og bedste praksis ikke følges, bliver vedligeholdelse et mareridt. De fleste automatiseringsprojekter mislykkes på grund af dårlig vedligeholdelse af scripts.

Konklusion

Denne artikel beskriver hvad er automatiseringstestproces, og hvordan man starter automatiseringstest i din organisation fra start til slut trin for trin. Hvis du følger disse trin, håber jeg, at din automatisering bliver en succes.

Foreslået læsning = >> Bedste it-procesautomatiseringssoftware

Der er nogle dele (som valg af automatiseringsværktøj og automatiseringsrammer), der fortjener deres egne artikler. Vi vil dække disse i kommende dele af denne automatiseringsprøvende tutorial-serie.

=> I mellemtiden Klik her for at tjekke alle vejledningerne vi har allerede sendt i denne serie.

Jeg forsøgte at dække alle aspekter i et bredere overblik og bruge min egen erfaring til at skrive denne tutorial.

Hvis du føler, at jeg savnede noget vigtigt, eller at en del af denne vejledning har brug for lidt mere forklaring, så spørg mig i kommentarfeltet. Jeg vil meget gerne besvare dine spørgsmål.

oracle sql forespørgsler eksempler med svar pdf

PREV Tutorial # 2 | NÆSTE vejledning # 4

Anbefalet læsning

^