how effectively prepare test bed
Testbed / Testmiljø Oppsett utfordringer og beste praksis:
Ved flere anledninger finner testerne at manglene deres blir avvist av miljøspørsmål, eller de gjentar seg stadig ved å replikere feilene av lignende grunner. Mens det å åpne flest feil må absolutt være en av de personlige referansene for hver tester, må de fleste testere også legge vekt på å ha flest gyldige feil.
Hvordan oppnås dette?
Bortsett fra de andre aspektene som å planlegge en rekke testscenarier og forstå ordrelinjen grundig, a god tid må investeres i å sette opp testsengen eller testmiljøet . For det andre, til tross for at de har et estimert beløp for testsaksplanlegging, må testere også fokusere energiene sine på skape effektive testdata .
Personlig, som en del av revisjonsprosessen, har jeg observert at flest gyldige mangler blir funnet når en god innsats er investert i å lage testsengen eller testmiljøet på en riktig måte og når testeren har en grundig forståelse av hva slags miljø som trengs.
Den typen testdata som leveres til testmiljøet kan også utsette noen svært alvorlige feil i koden / funksjonen som testes, noe som kan påvirke produktets kvalitet alvorlig.
Denne artikkelen snakker om hva nøyaktig testsengen innebærer: Det er en totrinnsprosess med oppsett av testmiljø og oppsett av testdata:
Del 1) Den tidligere delen av artikkelen vil diskutere generell prosess med testmiljøoppsett , oftest møtt oppsettproblemer som tester og pekere står overfor når du lager en testseng i stedet for disse utfordringene.
Del 2) Etter å ha sagt så mye med hensyn til testsengen samlet i denne artikkelen, var det verdt å kaste litt lys på Test miljøvedlikehold aspekter også. Den siste delen av artikkelen diskuterer den andre delen av testsengoppsettet som involverer testdataene tilnærmingen til å sette den opp og noen effektive Test datahåndteringsteknikker .
Med et konstant 'big bang' innen programvareutvikling og testing, er det et stadig større fokus på å ta i bruk ulike metoder for å gjøre den samlede kvalitetssikringsprosessen gjennomsiktig, effektiv og tilstrekkelig.
Ulike kvalitetsrevisjoner gjennomføres på tvers av organisasjoner for å sikre at ytelsen til testteamet kan evalueres på passende måte og har målbare resultater med beregningene som ble identifisert ved initialiseringen av testsyklusen. Disse resultatene gjør det mulig å identifisere hvor et bestemt team står i forhold til å sikre optimal kvalitet for programvaren de tester.
Disse rapportene hjelper også teamet til å forstå mulighetene for forbedring basert på observasjonene som ble gjort under tilsynet.
Unødvendig å nevne, vil en veldig åpenbar beregning for ethvert testteam være med hensyn til det totale antall feil som er åpnet i forhold til antall feil som er gyldige . Derfor er et av spørsmålene som åpenbart dukker opp: Hva er grunnlaget for å prøve å oppdage en feil? Sagt på en annen måte, hva er grunnlaget som en mangel kan bli funnet på?
Svaret er enstemmig - Oppsett av testbed og / eller testmiljø. Det er kvalitetsstandarder satt i lagene til redusere manglene som blir avvist som en testoppsettfeil / brukerfeil, ugyldige konfigurasjoner eller i noen tilfeller feilene som oppstår som rømmer fra et bestemt team på grunn av utilgjengelige konfigurasjoner, uprøvde konfigurasjoner.
La oss starte med å se nærmere på å definere hva et testbed eller testmiljø er.
Hva du vil lære:
Hva er en testseng og testmiljø?
I en veldig generisk forstand kan en testseng defineres som et slags utviklingsmiljø der implementører av kode eller moduler har frihet til å teste modulene sine uten forstyrrelser fra testteamet, i absolutt inneslutning.
Imidlertid er en testseng ikke bare spesifikk for et utviklingsteam. Fra et testteams eller en testers perspektiv, siden Test Bed ikke er annet enn en plattform som er identifisert for programvare / produkttesting, kalles den også om hverandre et Testmiljø.
Ethvert testleie eller testmiljø må konfigureres i samsvar med å oppfylle det identifiserte testmålet for applikasjonen / produktet / programvaren som testes. I visse situasjoner vil en testseng være sammenstillingen av testmiljøet og testdataene det opererer med.
Komponenter i et testmiljø
Enhver test vil ha sine spesifikke testmiljøkrav, men i en veldig bred forstand vil ethvert testbed / testmiljø bestå av maskinvare, programvare og nettverksdeler for å støtte den nødvendige konfigurasjonen i det minste for å kjøre og gjennomføre den aktuelle testen. .
Det er kjent at en rimelig tid av en testers tid brukes av miljøproblemer, som igjen påvirker produktiviteten og testplanene. Selv om utfordringene varierer for hvert testteam, kan noen av dem være vanlige.
Noen viktige utfordringer som ofte står overfor er:
# 1) Eksternt miljø
Testmidlene eller miljøene er for det meste plassert geografisk på nettsteder som er fjerntliggende for teamene. Dette er en av de mest utfordrende utfordringene for testteam som i tilfelle eventuelle problemer som kan oppstå knyttet til maskinvare, firmware, programvare, nettverk osv.
Teamene som forbruker eiendelene, må være sterkt avhengige av støtteteamene på stedet der eiendelene er til stede.
I samme linje, hvis noen eiendeler trenger en firmwareoppgradering eller en build-oppgradering, kan det hende at testteamet trenger støtte fra supportteamene som eier miljøet ved å åpne supportbilletter. Dette kan også føre til betydelig testtid og forsinke tidsplaner, spesielt i tilfeller av forskjeller i tidssonen.
# 2) Kombinert bruk mellom lag
Ofte enn ikke bruker utviklings- og testteam de samme miljøaktivaene. Selv om den generelle normen definerer at utviklings-, test- og produksjonsmiljøer må være adskilte, oppnås faktisk dette ideelle scenariet svært sjelden. Det blir ekstremt uvennlig kostnad for organisasjoner å skaffe separate ressurser for hvert team.
Derfor krever de fleste organisasjoner den vanlige bruken av miljøet mellom utvikling og test. Lagt til dette, hvis utviklings- og testressursene kjemper for bruken av de samme eiendelene samtidig, fører det til kaos og uenigheter i medlemmene.
# 3) Ineffektiv planlegging for ressursbruk for integrering
I noen tilfeller for scenarier som trenger en slutt til slutt testing hvorved det er en integrering av to eller flere komponenter for å fungere sammen, kan det igjen være et krav om å ha felles ressursbruk mellom testteam. Ineffektiv planlegging med hensyn til bruk er en stor bidragsyter til at miljøet blir ustabilt, i tillegg til konflikt mellom teamene.
Den mest tydelige effekten av dette er at et problem som blir lagt merke til for en bestemt en eller to ganger, kan produsere en helt annen oppførsel i følgende løp for det samme scenariet. Hvis en mangel allerede er åpnet for dette, er det store sjanser for at den ikke blir akseptert av utviklingen som en gyldig kandidat for en løsning.
# 4) Kompleks testkonfigurasjon
Testbeds- eller testmiljøkonfigurasjonen er noen ganger for komplisert. Dette vil utgjøre flere utfordringer ettersom testteamet vil trenge de nødvendige ferdighetene for å forstå de nødvendige konfigurasjonene. Noen ganger er det mangel på kunnskapsbase tilgjengelig for at testeren skal kunne komme med den nødvendige konfigurasjonen.
I slike tilfeller kan testerne selv indusere en feil i testsengen ved å konfigurere den feil. Dette vil i stor grad påvirke testsaken og resultatene den gir.
# 5) Omfattende installasjonstid
I visse andre tider, for hvert testtilfelle, kan testoppsettet være altfor forseggjort på hvert testtilfelle som er identifisert. Dette kan skyldes et bredt utvalg av sameksisterende teknologier som må kobles sammen eller flere komponenter for å samarbeide i tilfeller av integrasjonstesting.
I disse tilfellene må hver av komponentene fungere perfekt for å sikre konsistente resultater, da en komponent kan danne et input til den neste.
Beste fremgangsmåter for å sette opp et testmiljø
Vi har sett på den brede oversikten over utfordringer som en tester står overfor før eller mens du starter testutførelsen. De fleste av oss har møtt en eller flere av disse problemene på et eller annet tidspunkt i løpet av prosjektets milepæler. Disse utfordringene har eksistert og vil muligens fortsette å eksistere i varierende grad fordi en idealistisk situasjon ikke eksisterer.
Gitt at oppsettutfordringer er en del av en testers jobb og er uunngåelige, er det noen forslag til hvordan du effektivt kan forberede oppsettet for testing. Dette kan bidra til å minimere feilene som kan oppstå i installasjonsproblemer.
Tips nr. 1) Forstå Test kravene grundig og utdann deg selv
konverter karakter til streng c ++
Begynn alltid med det grunnleggende og med det mest åpenbare! Når et spesifikasjonsdokument eller et bruksdokument blir rullet ut av utviklingsteamet, er det ufravikelige trinnet for testteamet å forstå kravene til ordrelinjen og deretter utarbeide et testdokument som beskriver testtilfellene.
Mens testplanleggingen gjennomføres, er det det den beste øve på å også inkludere detaljert testmiljøinformasjon i testdokumentet. Ingen gjetninger til det faktum at testeren vil bruke litt tid på å analysere hvilket testmiljø som kan være nødvendig, og følgelig de nødvendige konfigurasjonene.
Dette kan oppnås ved å snakke med utviklingsteamet / arkitekter for å bygge et godt kunnskapsgrunnlag. Dette vil ikke bare spare litt tid i utførelsessyklusen, men vil også hjelpe en tester til å fordele utføringstiden effektivt mellom enkle og komplekse tester.
Personlig er et godt resultat av dette at mange av oss oppdaget installasjonsproblemer (som iboende ville forhindre konsekvent testutførelse) helt i begynnelsen av syklusen, noe som ga oss tid til å kanalisere og skaffe den nødvendige hjelpen til å få løst disse problemene - dermed ikke utvide testsyklusen utover uakseptable perioder.
En annen positiv innvirkning dette ville ha, er at dette vil forbedre testteamets kunnskap og forhindre unødvendige feil. Selv om denne fremgangsmåten oppsummerer nesten alle fremgangsmåter som iboende er nødvendige for å takle utfordringene for testoppsettet som er nevnt ovenfor, er det fortsatt verdt å nevne de andre tipsene.
Tips 2) Kontrollerer tilkoblingen
Et annet viktigst sjekkpunkt er å sørge for at ressursene eller eiendelene du har tenkt å bruke til testing er tilgjengelige. Hvis systemet må kjøres integrert med andre maskiner, må du kontrollere tilkoblingen til hverandre ved hjelp av ping eller telnet.
Også hvis systemene må samhandle med hverandre og ligger bak brannmurer, må du sørge for at de kan autentisere seg gjennom disse brannmurene ved hjelp av Basic Security Options (BSO) og se etter eventuelle fullmakter også. I tilfelle du merker at noen maskiner ikke er tilgjengelige eller trenger BSO-autentisering, kan du komme med passende serviceforespørsler for å oppfylle kravet til supportteamet.
Dette er spesielt nyttig når miljøet er på avsidesliggende steder, og vil også unngå opptrapping med hensyn til maskiner og systemer. Hvis testteamet krever tilgang til en ressurs eller et lager, vil dette hjelpe til med å aktivt bestemme det samme.
Tips nr. 3)Kontrollerer nettverket og / eller lagringen
Dette er nesten en utvidelse til forrige tips og trenger en viss annen mer sjekk med større teknisk dybde. Forsikre deg om at testing du trenger har den nødvendige båndbredden, og om testingen trenger en internettforbindelse. Sørg også for at du finner en måte å verifisere at nettverkstopologien mellom systemer og ressurser er riktig.
For det andre, hvis testmålet ditt innebærer behov for lagring, må du sørge for at det er lagring og nettverkstilkobling. For det meste er det administratorens ansvar å ha dette på plass, men det er også en god verdi å ha litt fungerende og funksjonell kunnskap om det samme.
Tips nr. 4) Se etter nødvendig maskinvare og programvare, lisenser
Mange ganger skjer det slik at testere begynner å kjøre på systemene uten å sjekke nødvendig maskinvare og programvare som kan være nødvendig. Som et resultat av dette mange ganger innser en tester nesten under testsyklusen at viss funksjonalitet bare er tilgjengelig på et høyere nivå av maskinvare eller programvare / firmware.
På den tiden vil testeren flagge en blokkerer i sin testinnsats som spiser opp betydelig testtid. Derfor er det en uvurderlig praksis å ha et kontrollpunkt for å notere maskinvaren og programvaren som er nødvendig tidligere.
Mange ganger kan det være nedetid ved oppgradering av maskinvaren / programvaren, som alt sammen koker ned til Tips 1 der en tester må involvere i proaktiv planlegging av maskinvaren. Noen av programvaren kan kreve lisenser som kan kreve godkjenninger og handlinger fra det juridiske teamet. Dette er en prosessdrevet handling, og det kan igjen ta flere dager å bli oppfylt, noe som må planlegges.
Tips nr. 5)Nettlesere og versjoner
Testingen du gjør må speile hva en sluttbruker vil utføre . Han kan teste i en bestemt nettleser på de nyeste versjonene av alle nettlesere. Derfor er det obligatorisk å identifisere forskjellige typer nettlesere som skal brukes til testing, og få dem installert i ditt eget lokale testoppsett.
For det andre, identifiser også hvilke versjoner av nettlesere som må brukes til testing. En god praksis ville være å starte med en nettleser i den nedre versjonen, og dermed sikre bakoverkompatibilitet og deretter oppgradere til den nyeste versjonen.
Tips nr. 6)Planlegger bruk av testmiljø.
Med tanke på at testteamet aldri vil ha en situasjon med å ha sine egne testressurser, systemer og eiendeler - er det en av de viktigste milepælene i testplanleggingen å ha en effektiv bruk av testressursene.
hvordan vise eps-filer i Windows 10
Dette er spesielt påkrevd når mer enn ett team må ha tilgang til samme sett med ressurser enten på grunn av et slutt-til-slutt-scenario som består av to eller flere komponenter som arbeider sammen, eller en situasjon der testoppsettet er for forseggjort eller komplisert til å replikeres veldig enkelt, og det kan være flere medlemmer i samme team som har sine testmål med samme oppsett.
En god praksis ville være å utarbeide en tidsdelingsmetode der et bestemt team eller en person bruker den i den tidligere halvdelen og de resterende i den siste halvdelen. Det kan være en gang imellom som vil være vanlig hvor hver av dem kan kjøre uavhengige tester som ikke vil hemme den andre.
Å gjøre dette vil ikke bare redusere kaos og konflikter i medlemmene, men vil også sikre atferdets stabilitet i miljøet over lengre tid.
Tips nr. 7)Automatiseringsverktøy og deres konfigurasjoner
Som vi vet vil hver linje i testen ha noen gjentatte tester som vil være en del av regresjonssyklusen som må automatiseres. Testteamet må identifisere hva slags automatisering de ønsker å gjøre og de nødvendige verktøyene for det.
Selv om dette nødvendige ikke trenger å være en del av miljøforberedelsen, vil jeg fremdeles oppføre dette som en god praksis for å få automatiseringsverktøyene identifisert og konfigurert i samsvar med dette. Dette vil helt avhenge av testers skjønn når han ønsker å utføre denne aktiviteten, da dette ikke er en obligatorisk faktor for å sikre testberedskap.
Konklusjon
Disse tipsene og triksene kan danne et godt målestokk og fotavtrykk for å sikre testmiljøets beredskap for testing. Utvilsomt står hvert team overfor sitt eget unike sett med utfordringer, og tipsene ovenfor kan tilpasses og tilpasses for å passe deres respektive behov.
Faktisk kommer kilden til å notere hele dette skjelettet med tips fra en av oppgavene mine der jeg sto overfor alvorlig komplekse installasjonsproblemer og tok meg nesten et år på å til og med begynne å teste!
Selv om begrensningene i testmiljøet var utenfor min kontroll, følte jeg at mange av disse problemene kunne ha blitt rapportert tidligere hvis jeg hadde brukt disse tipsene. Jeg har brukt den på hver oppgave som kommer på min vei siden den gang, og dette skjelettet har hjulpet meg mye med å proaktivt finne oppsettproblemer og kanalisere arbeidet mitt for å få dem løst.
Om forfatteren: Denne artikkelen er skrevet av Sneha Nadig. Hun jobber som en testleder med over 7 års erfaring i manuelle og automatiseringstestprosjekter.
I del 2 av denne artikkelen vil vi se oppsett og vedlikeholdsprosess for testmiljø og forberedelse av testdata og administrasjonstips. I mellomtiden er du velkommen til å legge ut dine spørsmål om forberedelse av testbed i kommentarer.
Anbefalt lesing
- Hvordan utføre testing etter utgivelsen effektivt og minimere effekten av utgivelsen for live klienter
- Hvordan bestemmer du hvilke feil som kan aksepteres for at programvaren skal bli live-live?
- Hvordan forberede og levere en fremragende QA-testpresentasjon til teamet
- Process for defect management: Hvordan håndtere en feil effektivt
- 9 beste ideer for testere å utnytte benktiden effektivt
- Ledelse i testing - Testansvar og hvordan man administrerer testteam effektivt
- Hvordan planlegge og administrere testprosjekter effektivt (tips)
- Prosess for mangelfrihet og måter å håndtere møter med mangler