Menu

Hvordan man effektivt forbereder “testbed” og minimerer testmiljøfejlene (del 1)

how effectively prepare test bed

Prøv Vores Instrument Til At Fjerne Problemer

hvordan man bruger torrentfiler efter download

Udfordringer og bedste praksis for opsætning af testbed / testmiljø:

Ved flere lejligheder finder testerne, at deres mangler bliver afvist af miljøspørgsmål, eller de gentager sig konstant af lignende årsager. Mens åbning af flest antal fejl helt sikkert skal være en af ​​de personlige benchmarks for hver tester, skal de fleste testere også lægge vægt på at have flest mulige gyldige fejl.

Hvordan opnås dette?

Sådan forbereder du effektivt

Bortset fra de andre aspekter som planlægning af en række testscenarier og grundig forståelse af linjeposten, a der skal investeres god tid i opsætningen af ​​testbedet eller testmiljøet . For det andet skal testere også, selvom de har et anslået beløb til planlægning af testsager fokusere deres energier på skabe effektive testdata .

Som en del af auditprocessen har jeg personligt observeret, at der findes flest gyldige mangler, når der er investeret en stor indsats i at skabe testsengen eller testmiljøet på en korrekt måde, og når testeren har en grundig forståelse af den type miljø, der er behov for.

Den slags testdata, der leveres til testmiljøet, kan også udsætte nogle meget alvorlige fejl i koden / funktionen, der testes, hvilket kan påvirke produktets kvalitet alvorligt.

Denne artikel taler om, hvad nøjagtigt testsengen indebærer: Det er en totrins proces med opsætning af testmiljø og opsætning af testdata:

Del 1) Den tidligere del af artiklen vil diskutere generel proces med opsætning af testmiljø , som oftest står over for installationsproblemer, som test og henvisninger står over for, når man opretter en testbed i stedet for disse udfordringer.

Del 2) Efter at have sagt så meget med hensyn til testsengen samlet i denne artikel, var det værd at kaste lys over Test miljøvedligeholdelse aspekter også. Sidste del af artiklen diskuterer anden del af testbed-opsætningen, som involverer testdata, fremgangsmåden til opsætning og nogle effektive Test teknikker til datastyring .

Med et konstant ”big bang” inden for softwareudvikling og test er der et stadig større fokus på at anvende forskellige metoder for at gøre den samlede kvalitetssikringsproces gennemsigtig, effektiv og passende.

Forskellige kvalitetsrevisioner gennemføres på tværs af organisationer for at sikre, at testteamets præstationer kan evalueres passende og har målbare resultater med de målinger, der blev identificeret ved initialiseringen af ​​testcyklussen. Disse resultater gør det muligt at identificere, hvor et bestemt team står med hensyn til at sikre optimal kvalitet til den software, de tester.

Disse rapporter hjælper også teamet med at forstå mulighederne for forbedring baseret på de observationer, der blev foretaget under revisionen.

Det er overflødigt at nævne, at en meget åbenbar måling for ethvert testteam ville være med hensyn til det samlede antal fejl, der blev åbnet i forhold til antallet af gyldige mangler . Derfor er et af de spørgsmål, der åbenbart dukker op, - hvad er grundlaget for at forsøge at opdage en defekt? Sagt på en anden måde, hvad er fundamentet, som en mangel kan findes på?

Svaret er enstemmigt - Opsætning af testbed og / eller testmiljø. Der er kvalitetsbenchmarks sat inden for hold til reducere de mangler, der afvises som en testopsætningsfejl / brugerfejl, ugyldige konfigurationer eller i nogle tilfælde de fejl, der opstår som undslipper fra et bestemt team på grund af utilgængelige konfigurationer, uprøvede konfigurationer.

Lad os starte med at se nærmere på at definere, hvad en testseng eller et testmiljø er.

Hvad du vil lære:

Hvad er en testbed og testmiljø?

I en meget generisk forstand kan en testseng defineres som en slags udviklingsmiljø, hvor implementører af kode eller moduler har frihed til at teste deres moduler uden forstyrrelser fra testteamet, i absolut indeslutning.

En testbed er dog ikke kun specifik for et udviklingsteam. Set fra et testteams eller en testers perspektiv, da testbedet ikke er andet end en platform identificeret til software / produkttest, kaldes det også ombytteligt et testmiljø.

Ethvert testseng eller testmiljø skal konfigureres i overensstemmelse med det identificerede testmål for applikationen / produktet / softwaren, der testes. I visse situationer vil en testseng være en sammenstilling af testmiljøet og de testdata, den arbejder med.

Komponenter i et testmiljø

Enhver test ville have sine specifikke testmiljøkrav, men i en meget bred forstand vil ethvert testbed / testmiljø bestå af hardware, software og netværksstykkerne til at understøtte den krævede konfiguration i det mindste for at køre og udføre den bestemte test .

Det er en velkendt kendsgerning, at en rimelig mængde af en testers tid forbruges af miljøproblemer, som igen påvirker produktiviteten og testplanerne. Selvom den slags udfordringer varierer for hvert testteam, kan nogle af dem være almindelige.

Nogle vigtige udfordringer, der ofte står over for, er:

# 1) Fjernmiljø

Testaktiverne eller -miljøerne placeres for det meste geografisk på steder, der er fjerntliggende for holdene. Dette er en af ​​de mest udfordrede udfordringer for testteam som i tilfælde af eventuelle problemer, der kan opstå i forbindelse med hardware, firmware, software, netværk osv.

De hold, der forbruger aktiverne, skal stærkt stole på supportteamene på det sted, hvor aktiverne er til stede.

I de samme linjer, hvis nogle aktiver har brug for en firmwareopgradering eller en build-opgradering, kan testteamet muligvis også have brug for support fra supportteamene, der ejer miljøet, ved at åbne supportbilletter. Dette kan også opsuge betydelig testtid og forsinke tidsplaner, især i tilfælde af tidszoneforskelle.

# 2) Kombineret brug mellem hold

Ofte end ikke bruger udviklings- og testteams de samme miljøaktiver. Selvom den generelle norm definerer, at udviklings-, test- og produktionsmiljøer skal være adskilte, opnås faktisk dette ideelle scenario meget sjældent. Det bliver ekstremt omkostningsvenligt for organisationer at skaffe separate ressourcer til hvert hold.

Derfor pålægger de fleste organisationer den fælles brug af miljøet mellem udvikling og test. Tilføjet til dette, hvis udviklings- og testressourcerne kæmper for brugen af ​​de samme aktiver på samme tid, fører det til kaos og uenighed inden for medlemmerne.

test udviklings- og produktionsmiljø

# 3) Ineffektiv planlægning af ressourceforbrug til integration

I nogle tilfælde for scenarier, der har brug for en test til ende til slut hvorved der er en integration af to eller flere komponenter til at fungere sammen, kan der igen være et krav om at have den fælles ressourceforbrug mellem testteamene. Ineffektiv planlægning med hensyn til brug er en stor bidragyder til, at miljøet bliver ustabilt, udover konflikt mellem hold.

Den mest tydelige effekt af dette er, at et problem, der bemærkes for en bestemt en eller to gange, kan producere en helt anden adfærd i de følgende kørsler for det samme scenarie. Hvis en mangel allerede er åbnet for dette, er der store chancer for, at den ikke accepteres af udviklingen som en gyldig kandidat til en løsning.

# 4) Kompleks testkonfiguration

Testsengen eller testmiljøkonfigurationen er undertiden for kompleks. Dette vil udgøre flere udfordringer, da testteamet har brug for de nødvendige færdigheder for at forstå de nødvendige konfigurationer. Til tider mangler der en vidensbase til rådighed for testeren for at kunne komme med den krævede konfiguration.

I sådanne tilfælde kan testerne selv fremkalde en fejl i testbedet ved at konfigurere den forkert. Dette vil i høj grad påvirke testsagen og de resultater, den producerer.

# 5) Omfattende opsætningstid

På bestemte andre tidspunkter, for hver testtilfælde, kan testopsætningen være alt for detaljeret på hver identificeret testtilfælde. Dette kan skyldes en bred vifte af sameksisterende teknologier, der skal kobles sammen eller flere komponenter for at arbejde sammen i tilfælde af integrationstest.

I disse tilfælde skal hver af komponenterne fungere perfekt for at sikre ensartede resultater, da en komponent kan danne et input til den næste.

Bedste fremgangsmåder til opsætning af et testmiljø

Vi har kigget på den brede oversigt over udfordringer, som en tester står over for før eller under påbegyndelsen af ​​testudførelsen. De fleste af os har haft et eller flere af disse spørgsmål på et eller andet tidspunkt i løbet af vores projektmilepæle. Disse udfordringer har eksisteret og vil muligvis fortsætte med at eksistere i varierende grad, fordi der ikke findes en idealistisk situation.

I betragtning af at installationsudfordringer er en del af en testers job og er uundgåelige, her er nogle forslag til, hvordan du effektivt forbereder opsætningen til test. Dette kan hjælpe med at minimere de fejl, der kan opstå i forbindelse med installationsproblemer.

Tip nr. 1) Forstå Test krav grundigt og uddanne dig selv

klon harddisk til ssd-software

Start altid med det grundlæggende og med det mest oplagte! Når et specifikationsdokument eller et use case-dokument rulles ud af udviklingsteamet, er det ufravigelige trin for testteamet at forstå linjepostkravene og derefter udarbejde et testcase-dokument, der beskriver testcases.

Mens testplanlægningen udføres, er det det bedste praksis for også at inkludere de detaljerede testmiljøoplysninger i testdokumentet. Ingen gætter på det faktum, at testeren derefter bruger lidt tid på at analysere, hvilket testmiljø der kan kræves, og dermed de nødvendige konfigurationer.

Dette kan opnås ved at tale med udviklingsteamet / arkitekterne for at opbygge en god videnbase. Dette vil ikke kun spare tid i eksekveringscyklussen, men vil også hjælpe en tester med at fordele sin eksekveringstid effektivt mellem enkle og komplekse tests.

Personligt er et godt resultat af dette, at mange af os opdagede installationsproblemer (der iboende ville forhindre konsekvent testudførelse) i begyndelsen af ​​cyklussen, hvilket gav os tid til at kanalisere og erhverve den nødvendige hjælp til at få disse problemer løst - således ikke forlænger testcyklussen ud over uacceptable perioder.

En anden positiv indvirkning dette ville have er, at dette i høj grad vil forbedre testteamets viden og forhindre unødvendige fejl. Selv om denne praksis opsummerer næsten alle de fremgangsmåder, der iboende er nødvendige for at klare de ovennævnte testopsætningsudfordringer, er det stadig værd at nævne de andre tip.

Tip nr. 2) Kontrol af forbindelse

Et andet meget vigtigt kontrolpunkt er at sikre, at de ressourcer eller aktiver, du har til hensigt at bruge til test, er tilgængelige. Hvis systemet skal køres integreret med andre maskiner, skal du kontrollere deres forbindelse med hinanden ved hjælp af ping eller telnet.

Også hvis systemerne har brug for at interagere med hinanden og ligger bag firewalls, skal du sørge for, at de kan godkende gennem disse firewalls ved hjælp af BSO (Basic Security Options) og også kontrollere, om der er nogen proxyer. Hvis du bemærker, at nogle maskiner ikke er tilgængelige eller har brug for BSO-godkendelse, kan passende serviceanmodninger rejses for at opfylde kravet til supportteamet.

Dette er især nyttigt, når miljøet befinder sig i fjerntliggende steder og vil også undgå optrapninger med hensyn til maskiner og systemer. Hvis testteamet kræver adgang til en hvilken som helst ressource eller et lager, vil dette hjælpe med at aktivt bestemme det samme.

Tip nr. 3)Kontrol af netværk og / eller lagring

Dette er næsten en udvidelse til det forrige tip og ville have brug for en vis anden mere kontrol med større teknisk dybde. Sørg for, at test, du har brug for, har den nødvendige båndbredde, og hvis din test har brug for en internetforbindelse. Sørg også for, at du finder en måde at kontrollere, at netværkstopologien mellem systemer og ressourcer er korrekt.

For det andet, hvis dit testmål indebærer behovet for opbevaring, skal du sikre dig, at der er opbevaring og netværksforbindelse. For det meste er det en administrators ansvar at have dette på plads, men det er også en stor tilføjelse at have noget fungerende og funktionel viden om det samme.

Tip nr. 4) Se efter den nødvendige hardware og software, licenser

Mange gange sker det så, at testere begynder at udføre på systemerne uden at kontrollere den nødvendige hardware og software, der kan være påkrævet. Som et resultat af dette mange gange indser en tester næsten under testcyklussen, at visse funktioner kun er tilgængelige på et højere niveau af hardware eller software / firmware.

På det tidspunkt markerer testeren en blokering i sin testindsats, der spiser betydelig testtid. Derfor er det en uvurderlig praksis at have et kontrolpunkt for at notere den hardware og software, der er nødvendig på forhånd.

Mange gange kan der være nedetid ved opgradering af hardware / software, som alt sammen koger til Tip 1 hvor en tester skal involvere sig i proaktiv planlægning af hardware. Nogle af softwaren kræver muligvis licenser, der muligvis kræver godkendelser og handlinger fra det juridiske team. Dette er en procesdrevet handling, der muligvis igen kan tage et antal dage at blive opfyldt, hvilket skal planlægges.

Tip nr. 5)Browsere og versioner

Den test, du laver, skal spejle hvad en slutbruger vil udføre . Han kunne teste i en bestemt browser på de nyeste versioner af alle browsere. Derfor er det obligatorisk at identificere de forskellige slags browsere, der vil blive brugt til test, og få dem installeret i din egen lokale testopsætning.

For det andet skal du også identificere, hvilke versioner af browsere der skal bruges til test. En god praksis ville være at starte med en browser i den lavere version og derved sikre bagudkompatibilitet og derefter opgradere til den nyeste version.

Tip nr. 6)Planlægning af brugen af ​​testmiljøet.

I betragtning af at testteamet aldrig vil have en situation med at have deres egne testressourcer, systemer og aktiver - er det en af ​​de største milepæle i testplanlægningen at have en effektiv brug af testressourcer.

bedste reg rengøringsmiddel til Windows 10

Dette er især nødvendigt, når mere end et hold skal have adgang til det samme sæt ressourcer, enten på grund af et slut-til-slut-scenarie, der består af to eller flere komponenter, der arbejder sammen, eller en situation, hvor testopsætningen er for udførlig eller kompleks til at blive replikeret meget let, og der kunne være flere medlemmer inden for det samme hold, der havde deres test-egne mål med samme opsætning.

En god praksis ville være at udarbejde en tidsdelingsmetode, hvorved et bestemt hold eller en person bruger det i den tidligere halvdel og de resterende mennesker i sidste halvdel. Der kan være et stykke tid imellem, der vil være almindeligt, hvor hver af dem kan køre uafhængige tests, der ikke hæmmer den anden.

At gøre dette vil ikke kun reducere kaos og konflikter i medlemmerne, men vil også sikre miljøets adfærdsmæssige stabilitet i længere tid.

Tip nr. 7)Automatiseringsværktøjer og deres konfigurationer

Som vi ved, vil hver linjepost ved testning have et par gentagne tests, der vil være en del af regressionscyklussen, som skal automatiseres. Testteamet skal identificere, hvilken type automatisering de gerne vil udføre, og de nødvendige værktøjer til det.

Selvom dette nødvendige ikke behøver at være en del af miljøforberedelsen, vil jeg stadig liste dette som en bedste praksis for at få automatiseringsværktøjerne identificeret og konfigureret i overensstemmelse hermed. Dette vil helt afhænge af testers skøn, når han ønsker at udføre denne aktivitet, da dette ikke er en obligatorisk faktor for at sikre testberedskab.

Konklusion

Disse tip og tricks kan danne en god målestok og fodaftryk for at sikre testmiljøets parathed til testning. Uden tvivl står hvert hold over for sit eget unikke sæt udfordringer, og tipene ovenfor kan tilpasses og tilpasses, så de passer til deres respektive behov.

Faktisk kommer kilden til at notere hele dette skelet af tip fra en af ​​mine opgaver, hvor jeg stod over for meget komplekse installationsproblemer og tog mig næsten et år til endda at begynde at teste!

Selvom begrænsningerne i testmiljøet var uden for min kontrol, følte jeg, at mange af disse problemer kunne have været rapporteret tidligere, hvis jeg havde anvendt disse tip. Jeg har anvendt det til hver opgave, der kommer min vej siden da, og dette skelet har hjulpet mig meget med at proaktiv finde installationsproblemer og kanalisere min indsats for at få dem løst.

Om forfatteren: Denne artikel er skrevet af Sneha Nadig. Hun arbejder som en testleder med over 7 års erfaring i manuelle og automatiseringstestprojekter.

I del 2 af denne artikel vil vi se testmiljøets opsætnings- og vedligeholdelsesproces og testdataforberedelse og ledelsestip. I mellemtiden er du velkommen til at skrive dine forespørgsler om forberedelse af testbed i kommentarer.

Anbefalet læsning

^