Meny

Hur man effektivt förbereder 'testbädd' och minimerar testmiljöfel (del 1)

how effectively prepare test bed

Prova Vårt Instrument För Att Eliminera Problem

hur man öppnar en dat-fil på Windows

Utmaningar och bästa metoder för installation av testbädd / testmiljö:

Vid flera tillfällen finner testarna att deras brister avvisas på grund av miljöfrågor eller att de ständigt replikerar defekterna av liknande skäl. Även om det största antalet defekter öppnas måste det vara en av de personliga riktmärkena för varje testare, men de flesta testare måste också betona att de har flest antal giltiga defekter.

Hur uppnås detta?

Hur man effektivt förbereder

Bortsett från de andra aspekterna som att planera en rad olika testscenarier och att förstå raden grundligt, a god tid måste investeras i att ställa in testbädden eller testmiljön . För det andra måste testare också, trots att de har en uppskattad summa för planering av testfall fokusera sina energier på skapa effektiva testdata .

Personligen, som en del av granskningsprocessen, har jag observerat att flest giltiga fel upptäcks när en stor mängd ansträngningar har investerats i att skapa testbädden eller testmiljön på ett korrekt sätt och när testaren har en grundlig förståelse för vilken typ av miljö som behövs.

Den typ av testdata som levereras till testmiljön kan också avslöja några mycket allvarliga brister i koden / funktionen som testas vilket kan påverka produktens kvalitet allvarligt.

Den här artikeln talar om exakt vad testbädden innebär: Det är en tvåstegsprocess för installation av testmiljö och testdatainställning:

Del 1) Den tidigare delen av artikeln kommer att diskutera allmän process för installation av testmiljö , oftast inför installationsproblem som tester och pekare står inför när du skapar en testbädd i stället för dessa utmaningar.

Del 2) Efter att ha sagt så mycket om testbädden kollektivt i den här artikeln var det värt att kasta lite ljus på Testa miljöunderhåll aspekter också. Den sista delen av artikeln diskuterar den andra delen av testbäddsuppsättningen som involverar testdata metod för att ställa upp den och en del effektiv Testa datahanteringstekniker .

Med en ständig “big bang” inom mjukvaruutveckling och testning fokuseras alltmer på att använda olika metoder för att göra den övergripande kvalitetssäkringsprocessen transparent, effektiv och adekvat.

Olika kvalitetsrevisioner genomförs över organisationer för att säkerställa att testteamets resultat kan utvärderas på lämpligt sätt och har mätbara resultat med de mätvärden som identifierades vid initialiseringen av testcykeln. Dessa resultat gör det möjligt att identifiera var ett visst team står när det gäller att säkerställa optimal kvalitet för programvaran de testar.

Dessa rapporter hjälper också teamet att förstå möjligheterna till förbättringar baserat på observationerna som gjordes under revisionen.

Det behöver inte nämnas att en mycket uppenbar statistik för alla testteam skulle vara med avseende på det totala antalet defekter som öppnats jämfört med antal fel som är giltiga . Därför är en av de frågor som uppenbarligen dyker upp: Vad är grunden för att försöka upptäcka eventuella fel? Sagt på ett annat sätt, vad är grunden för vilken en defekt kan hittas?

Svaret är enhälligt - Testbädd och / eller testmiljöinställning. Det finns kvalitetsriktmärken som ställs in i lag till minska de defekter som avvisas som ett testinställningsfel / användarfel, ogiltiga konfigurationer eller i vissa fall de defekter som uppstår som undgår från ett visst team på grund av otillgängliga konfigurationer, oproverade konfigurationer.

Låt oss börja med att titta närmare på att definiera vad en testbädd eller testmiljö är.

Vad du kommer att lära dig:

Vad är en testbädd och testmiljö?

I en mycket generisk mening kan en testbädd definieras som en slags utvecklingsmiljö där implementerare av kod eller moduler har friheten att testa sina moduler utan störningar från testteamet, i absolut inneslutning.

En testbädd är dock inte bara specifik för ett utvecklingsteam. Ur ett testteams eller testarens perspektiv, eftersom testbädden inte är annat än en plattform som identifierats för programvara / produkttestning, kallas den också omväxlande en testmiljö.

Varje testbädd eller testmiljö måste konfigureras i enlighet med det angivna testmålet för applikationen / produkten / programvaran som testas. I vissa situationer skulle en testbädd vara en sammanställning av testmiljön och testdata som den arbetar med.

Komponenter i en testmiljö

Varje test skulle ha sina specifika testmiljökrav, men i mycket vid bemärkelse kommer alla testbäddar / testmiljöer att bestå av hårdvara, programvara och nätverksstycken för att stödja den konfiguration som krävs för att köra och genomföra det specifika testet .

Det är ett välkänt faktum att en rimlig tid av en testares tid konsumeras av miljöproblem, vilket i sin tur påverkar produktiviteten och testscheman. Även om typ av utmaningar varierar för varje testteam, kan vissa av dem vara vanliga.

Några viktiga utmaningar som ofta står inför är:

# 1) Fjärrmiljö

Testtillgångarna eller miljöerna placeras mestadels geografiskt på platser som ligger på avstånd från teamen. Detta är en av de vanligaste utmaningarna för testteam som i händelse av eventuella problem som kan uppstå avseende hårdvara, firmware, programvara, nätverk etc.

De lag som förbrukar tillgångarna måste starkt förlita sig på supportteamen på platsen där tillgångarna finns.

I samma rader, om någon tillgång behöver en firmwareuppgradering eller en build-uppgradering, kan testteamet återigen behöva stöd från supportteam som äger miljön genom att öppna supportbiljetter. Detta kan också höja avsevärd testtid och fördröja scheman, särskilt i fall av tidszonsskillnader.

# 2) Kombinerad användning mellan lag

Oftast använder inte utvecklings- och testteam samma miljötillgångar. Även om den allmänna normen definierar att utvecklings-, test- och produktionsmiljöer måste vara åtskilda, uppnås i själva verket detta ideala scenario sällan. Det blir extremt kostnadsvänligt för organisationer att skaffa separata resurser för varje team.

Därför förordar de flesta organisationer den gemensamma användningen av miljön mellan utveckling och test. Till detta läggs, om utvecklings- och testresurserna strider mot användningen av samma tillgångar samtidigt, leder det till kaos och oenigheter inom medlemmarna.

testutveckling och produktionsmiljö

# 3) Ineffektiv planering för resursanvändning för integration

I vissa fall för scenarier som behöver en testning från slut till slut varigenom det finns en integration av två eller flera komponenter för att fungera tillsammans, återigen kan det vara ett krav att ha den gemensamma resursanvändningen mellan testteam. Ineffektiv planering med avseende på användning är en stor bidragsgivare till att miljön blir instabil, förutom konflikt mellan team.

Den tydligaste effekten av detta är att en fråga som märks för en viss en eller två gånger kan ge helt olika beteenden i följande körningar för samma scenario. Om en defekt redan har öppnats för detta finns det stora chanser att den inte accepteras av utvecklingen som en giltig kandidat för en fix.

# 4) Komplex testkonfiguration

Konfigurationen av testbädd eller testmiljö är ibland för komplex. Detta kommer att utgöra flera utmaningar eftersom testteamet behöver de kunskaper som krävs för att förstå de konfigurationer som behövs. Ibland saknas kunskapsbas för att testaren ska kunna komma med den konfiguration som krävs.

I sådana fall kan testarna själva orsaka ett fel i testbädden genom att konfigurera det felaktigt. Detta skulle i hög grad påverka testfallet och de resultat det ger.

# 5) Utarbetad installationstid

Under vissa andra tider, för varje testfall, kan testuppsättningen vara alltför detaljerad för varje identifierat testfall. Detta kan bero på ett brett utbud av sameksisterande tekniker som måste kopplas ihop eller flera komponenter för att fungera tillsammans i fall av integrationstest.

I dessa fall måste var och en av komponenterna fungera perfekt för att säkerställa konsekventa resultat, eftersom en komponent kan utgöra en input till nästa.

Bästa metoder för att skapa en testmiljö

Vi har tittat på de breda konturerna av utmaningar som en testare står inför innan eller när testkörningen påbörjas. De flesta av oss har mött en eller flera av dessa frågor någon gång under våra milstolpar. Dessa utmaningar har funnits och kommer möjligen att fortsätta att existera i varierande grad eftersom det inte finns en idealistisk situation.

Med tanke på att installationsutmaningar är en del av en testares jobb och är oundvikliga, här är några förslag på hur du effektivt kan förbereda installationen för testning. Detta kan hjälpa till att minimera de defekter som kan orsakas av installationsproblemen.

Tips nr 1) Förstå Testkrav noggrant och utbilda dig själv

hur man använder css-väljaren i selen

Börja alltid med grunderna och med det mest uppenbara! När ett specifikationsdokument eller ett användningsfallsdokument rullas ut av utvecklingsteamet är det oföränderliga steget för testteamet att förstå kraven på rader och sedan förbereda ett testfallsdokument som beskriver testfallet.

Medan testplaneringen genomförs är det Det bästa öva att också inkludera detaljerad testmiljöinformation i testfallsdokumentet. Inga gissningar till att testaren sedan spenderar lite tid på att analysera vilken testmiljö som kan krävas och följaktligen de konfigurationer som behövs.

Detta kan uppnås genom att prata med utvecklingsteamet / arkitekterna för att bygga en bra kunskapsbas. Detta skulle inte bara spara lite tid i exekveringscykeln utan kommer också att hjälpa en testare att fördela sin exekveringstid effektivt mellan enkla och komplexa tester.

Personligen är ett bra resultat av detta att många av oss upptäckte installationsproblem (som i sig skulle förhindra konsekvent testkörning) i början av cykeln, vilket gav oss tid att kanalisera och skaffa den hjälp som krävs för att få dessa problem rättade - alltså inte förlänga testcykeln utöver oacceptabla perioder.

En annan positiv inverkan detta skulle ha är att detta avsevärt skulle förbättra testteamets kunskap och förhindra onödiga defekter. Även om denna praxis sammanfattar nästan alla metoder som i sig behövs för att klara av testutmaningarna som nämns ovan, är det fortfarande värt att nämna de andra tipsen.

Tips nr 2) Kontrollerar anslutningen

En annan viktigaste kontrollpunkt är att se till att de resurser eller tillgångar du tänker använda för testning är tillgängliga. Om systemet måste köras integrerat med andra maskiner, kontrollera deras anslutning till varandra med hjälp av ping eller telnet.

Också om systemen behöver interagera med varandra och ligger bakom brandväggar, se till att de kan autentisera genom dessa brandväggar med hjälp av Basic Security Options (BSO) och söka efter eventuella proxyservrar också. Om du märker att vissa maskiner inte kan nås eller behöver BSO-autentisering kan lämpliga serviceförfrågningar göras för att uppfylla kravet till supportteamet.

Detta är särskilt användbart när miljön är på avlägsna platser och kommer också att undvika eskaleringar med avseende på maskiner och system. Om testteamet behöver åtkomst till någon resurs eller förvar kan detta hjälpa till att aktivt bestämma detsamma.

Tips nr 3)Kontroll av nätverk och / eller lagring

Detta är nästan en förlängning till föregående tips och skulle behöva en viss annan mer kontroll med större tekniskt djup. Se till att testning du behöver har den bandbredd som behövs och om din testning behöver en internetanslutning. Se också till att du hittar ett sätt att verifiera att nätverkstopologin mellan system och resurser är korrekt.

För det andra, om ditt testmål innebär behov av lagring, se till att det finns lagring och nätverksanslutning. För det mesta är det en administratörs ansvar att ha detta på plats, men det är också ett stort värde att lägga till lite fungerande och funktionell kunskap om detsamma.

Tips nr 4) Kontrollera om det krävs hårdvara och programvara, licenser

Många gånger händer det så att testare börjar köra på systemen utan att kontrollera den nödvändiga hårdvaran och programvaran som kan krävas. Som ett resultat av detta många gånger inser en testare nästan under testcykeln att vissa funktioner endast är tillgängliga på en högre nivå av hårdvara eller mjukvara / firmware.

Vid den tidpunkten kommer testaren att flagga en blockerare i sin testinsats som äter upp avsevärd testtid. Därför är det en ovärderlig praxis att ha en kontrollpunkt för att notera den hårdvara och programvara som behövs tidigare.

Många gånger kan det vara driftstopp involverat i uppgradering av hårdvaran / programvaran, vilket allt handlar om Tips 1 där en testare måste involvera i proaktiv planering av hårdvaran. En del av programvaran kan kräva licenser som kan kräva godkännande och åtgärder från det juridiska teamet. Detta är en processdriven åtgärd, det kan återigen ta ett antal dagar att fullbordas, vilket måste planeras.

Tips nr 5)Webbläsare och versioner

Testet du gör måste spegla vad en slutanvändare kommer att utföra . Han kan testa i en viss webbläsare på de senaste versionerna av alla webbläsare. Därför är det obligatoriskt att identifiera olika typer av webbläsare som skulle användas för testning och få dem installerade i din egen lokala testinställning.

För det andra, identifiera också vilka versioner av webbläsare som ska användas för testning. En bra praxis skulle vara att börja med en webbläsare i den lägre versionen, vilket säkerställer bakåtkompatibilitet och sedan uppgradera till den senaste versionen.

Tips nr 6)Planera användningen av testmiljön.

Med tanke på att testteamet aldrig kommer att ha en situation med egna testresurser, system och tillgångar - det är en av de viktigaste milstolparna i testplaneringen att använda en effektiv testresurs.

hur man testar webbläsarkompatibilitet

Detta krävs särskilt när mer än ett team måste komma åt samma uppsättning resurser antingen på grund av ett slut-till-slut-scenario som består av två eller flera komponenter som arbetar tillsammans, eller en situation där testinställningen är för detaljerad eller komplicerad för att replikeras väldigt enkelt och det kan finnas flera medlemmar inom samma team som har sina egna testmål med samma inställning.

En bra praxis skulle vara att utarbeta en tidsdelningsmetod där ett visst team eller en person använder det för den tidigare halvan och de återstående personerna för den senare halvan. Det kan finnas någon gång däremellan som är vanligt där var och en av dem kan köra oberoende tester som inte hindrar den andra.

Att göra detta kommer inte bara att minska kaoset och konflikterna inom medlemmarna utan kommer också att säkerställa miljöns beteendestabilitet under en längre tid.

Tips nr 7)Automationsverktyg och deras konfigurationer

Som vi vet kommer varje rad i testningen att ha några repetitiva tester som kommer att vara en del av regressionscykeln som måste automatiseras. Testteamet måste identifiera vilken typ av automatisering de vill göra och vilka verktyg som behövs för det.

Även om detta nödvändiga inte behöver vara en del av miljöförberedelserna, skulle jag fortfarande lista detta som en bästa praxis för att få automatiseringsverktygen identifierade och konfigurerade därefter. Detta beror helt på testarens diskretion när han vill utföra denna aktivitet eftersom detta inte är en obligatorisk faktor för att säkerställa testberedskap.

Slutsats

Dessa tips och tricks kan bilda en bra måttstock och fotavtryck för att säkerställa testmiljöens testberedskap. Utan tvekan står varje lag inför sin egen unika uppsättning utmaningar och tipsen ovan kan anpassas och anpassas för att passa deras egna behov.

Faktum är att källan för att rita ut hela detta skelett av tips kommer från ett av mina uppdrag där jag mötte svårt komplexa installationsproblem och tog mig nästan ett år att ens börja testa!

Även om begränsningarna i testmiljön var utom min kontroll, kände jag att många av dessa problem kunde ha rapporterats tidigare om jag hade tillämpat dessa tips. Jag har använt det för varje uppdrag som kommer på min väg sedan dess och detta skelett har hjälpt mig mycket med att aktivt hitta installationsproblem och kanalisera mina ansträngningar för att få dem lösta.

Om författaren: Denna artikel är skriven av Sneha Nadig. Hon arbetar som testledare med över 7 års erfarenhet av manuella och automatiseringsprojekt.

I del 2 av den här artikeln kommer vi att se installations- och underhållsprocessen för testmiljö och tips om förberedelser och hantering av testdata. Under tiden är du välkommen att skicka dina frågor om testbäddsförberedelser i kommentarer.

Rekommenderad läsning

^