test data management concept
I den siste opplæringen fokuserte vi på hvordan du forbereder Test Bed for å minimere defekte testmiljøer . I forlengelse med samme opplæring, i dag vil vi lære hvordan du setter opp og vedlikeholder testmiljø og viktigTest datahåndteringteknikker.
Test miljøoppsettprosess
Den viktigste faktoren for testmiljøet er å replikere det så nær sluttbrukermiljøet som mulig. Vanligvis forventes det ikke at sluttbrukere utfører noen konfigurasjon eller installasjoner av seg selv ettersom et komplett produkt eller system sendes ut til dem. Derfor, av den definisjonen, selv testteamene trenger ikke eksplisitt å utføre slike konfigurasjoner.
Hvis noen slike konfigurasjoner er nødvendige for rent testformål (men vil bli konfigurert for sluttbrukere), må administratorer identifiseres. Administratorene som konfigurerer utviklingsmiljøet, må være de samme personene som konfigurerer testmiljøet.
Hvis utviklingsteamet selv tar initiativ til installasjon / konfigurasjon, må de hjelpe til med å gjøre det samme selv i testmiljøet.
For eksempel, hvis du må teste et program (med tilhørende mellomvare som skal installeres og konfigureres) på et system på tvers av forskjellige OS-plattformer, etc. - den beste måten å løse dette på er å bruke virtualisering eller Cloud-miljøer .
Ha et hovedsystem der alle applikasjoner og nødvendig mellomvare er riktig installert og konfigurert. Gjør deretter dette systemet til et hovedbilde ved å ta det og klone flere forekomster fra det samme bildet slik at hver bruker føler at han har et dedikert system med applikasjonen som testes.
Nedenfor er en illustrasjon av hva en testmiljøprosess vil innebære:
Testmiljøoppsettprosess
Hva du vil lære:
Vedlikehold av et testmiljø
Så mye sagt om forberedelsene til testmiljøet, om enn utfordringene, dette er utvilsomt mer enn en grunn som krever vedlikehold eller standardisering av testmiljøet. Mange ganger mister en tester testtid på grunn av miljø- eller oppsettproblemer.
Med en rask økning i operativsystemene og spekteret av maskinvare og programvare, må miljøet være nesten dynamisk, for å takle behovene. Testteam kan sikre at de leverer et høykvalitetsprodukt med en god testadministrasjonsprosess, og dette vil bidra til å ha optimal bruk av ressurser som er begrenset tilgjengelig.
Viktige tips for å sikre effektivt vedlikehold av testmiljø
Som testmiljøer inneholder de fleste ganger heterogene plattformer og stabler. Nedenfor er noen viktige tips for å sikre effektivt vedlikehold av testmiljøet.
# 1) Effektiv deling og distribusjon av miljø:
Som nevnt tidligere er en av de viktigste utfordringene ved forberedelse av testmiljøet at mange team eller mennesker trenger å bruke det samme settet med ressurser til testformål. Derfor må det utvikles en passende delingsmekanisme som tilfredsstiller behovene til alle lag og mennesker uten å utsette tidsplanene.
Dette kan oppnås ved å opprettholde et depot eller informasjonskobling der alle data angående:
- som bruker miljøet,
- når miljøet er fritt til bruk og
- hvordan fordelingen av miljøbrukstiden er angitt nøyaktig.
Ved å proaktivt bestemme hvor kravet til ressursene er stort versus den begrensede tilgjengeligheten av dem, blir en stor mengde kaos automatisk opphevet.
Det andre aspektet ved dette er å revidere teamenes ressurskrav for hver testsyklus og se etter hvilke ressurser som ikke brukes veldig tungt. Analyser om de spesielle ressursene kan erstattes med nye ressurser eller systemer som kan være nødvendige.
# 2) Sunnhetssjekker:
Noen testkrav krever et omfattende testoppsett eller oppsett som involverer forseggjorte trinn som er ekstremt tid til å konsumere. Dette er spesielt tilfelle under slutt til slutt testing som involverer to eller flere komponenter for å jobbe sammen. Derfor kan det samme testmiljøet måtte brukes på nytt av flere lag.
I slike tilfeller vil det å ha en god forståelse av hele miljøet som helhet, og samle hva slags tester som utføres av forskjellige team, tegne et fornuftig bilde for å gi de spesifikke ressursene til de respektive lagene.
Tatt i betraktning de ovennevnte faktorene - kan grunnleggende sunnhetstesting utføres som vil hjelpe til med å fremskynde testene for individuelle lag eller umiddelbart alarmere dem hvis miljøet må gjennomgå noen endringer eller reparasjoner som et resultat av disse sunnhetssjekkene.
# 3) Holde oversikt over eventuelle avbrudd:
Akkurat som hvert team som eier et testmiljø har sine, har en organisasjon alle mulige testmiljøer vedlikeholdt av et globalt supportteam.
I tillegg til at lag som eier testmiljøet har sin egen lokale nedetid i tilfelle firmware / programvareoppgraderinger, må også de globale teamene sørge for at alle miljøene overholder de nyeste standardene som kan innebære strøm- eller nettverksbrudd.
Derfor må de som opprettholder testmiljøet holde et øye med slike avbrudd som kan oppstå, og informere testteamet på forhånd om å planlegge sitt arbeid deretter.
# 4) Virtualiser der det er mulig:
Dette er igjen veldig relevant der testing må gjøres for å dele miljøet og det er et stort behov for optimalisering av ressursene. I slike tider er svaret å bruke et virtualisert miljø som en sky for testformål.
Når du bruker et slikt miljø, trenger alle testere å gjøre et øyeblikk, og denne forekomsten, når den er klargjort, vil danne et uavhengig testseng eller testmiljø som inneholder alle de forskjellige ressursene, som et dedikert operativsystem, database, mellomvare, automatiseringsrammer osv. som kreves for testingen.
Når testingen er avsluttet, kan disse tilfellene ødelegges, og dermed redusere kostnadene for en organisasjon. Skymiljøer er spesielt nyttige for funksjonelle verifiseringstester, automatiseringstestområder.
# 5) Regresjonstesting / automatisering:
type testing i programvareteknikk
Når og når det utvikles nye funksjoner og funksjoner, regresjonstester må utføres for disse funksjonene for hver utgivelsessyklus. Derfor, selv om testmiljøene for regresjonstesting på baksiden ser ut til å kjøre på samme testoppsett med de samme dataene, i virkeligheten utvikler de stadig hver utgivelse i samsvar med funksjonene som implementeres også.
Hver produktutgivelsessyklus vil ha en eller flere runder med regresjonstesting. Dermed ville etablering av regresjonstestmiljøer for hver produktutgivelsessyklus og gjenbruk av dem i syklusen, definitivt skildre testmiljøets stabilitet.
Utvikling av automatiseringsrammer og bruk av automatisering for regressive tester, hjelper også til å forbedre effektiviteten til et testmiljø fordi automatisering vil anta at miljøet er stabilt og defektene som er opprinnelsen er rent funksjons- / kodeorientert.
# 6) Generell styring:
Når det er noen problemer med testmiljøets maskinvare eller programvare, må disse problemene rettes til de rette personene for å sikre reparasjoner hvis de ikke kan løses internt av de som vedlikeholder laboratoriet.
For eksempel, hvis noen tester har en feil som består av en begrensning i fastvaren eller programvaren som brukes i det nåværende miljøet, kan dette vanligvis ikke løses utelukkende av de som er ansvarlige for miljøvedlikeholdet.
Derfor må forbrukeren (som er testeren i dette tilfellet) bli bedt om å komme med passende serviceforespørsler. Disse må rettes til den aktuelle leverandøren eller teamet, og koordinering må gjøres regelmessig med dem for å sikre at neste versjon har løst det aktuelle problemet.
Et annet aspekt ved styring ville være å levere detaljerte miljørapporter til ledelsen eller interessenter fra tid til annen, noe som hjelper til med å utstråle åpenhet og danner et godt grunnlag for enhver analyse.
Forberedelse av testdata
La oss nå ta en titt på den siste delen av en Test bed creation - som innebærer å sette opp testdataene . Med et så stort stykke som blir sagt om testmiljøet, kan testmiljøets sanne essens, dets robusthet og effektivitet måles med testdataene. Per definisjon er testdataene alle slags innganger gitt til programvarekoden som testes.
Selv om vi bruker god tid på å designe testtilfeller, er grunnen til at testdata er viktig fordi de sørger for fullstendig testdekning for alle slags scenarier, og derved forbedrer kvaliteten. Det kan være noen testdata som er nødvendig for enhver lykkelig eller positiv banetesting.
Noen andre data kan utformes for feil eller negativ testing, noe som er veldig nyttig når du oppdager hvordan applikasjonen fungerer når den blir satt i unormale situasjoner.
Testdata blir vanligvis opprettet før tekstutførelsen begynner fordi hvert testmiljø har sitt eget kompleksitet, eller det kan være en langvarig prosess å forberede selve dataene. Så generelt kan testdatakildene være det interne utviklingsteamet eller sluttbrukerne som bruker koden eller funksjonen.
For eksempel,Funksjonstesting
La oss ta et eksempel der du trenger å utføre funksjonell testing eller black-box testing. Her er målet at koden må fungere for å oppfylle kravene som er spesifisert.
Så i slike tilfeller - utarbeidelse av testsaker bør generelt ha dekning av følgende typer data:
- Positive banedata: Med utviklingsbruksdokumentet som referanse, er dette dataene generelt synkronisert med å utføre de positive sti-scenariene.
- Negative banedata: Dette er data som vanligvis betraktes som 'ugyldige' med hensyn til korrekt funksjon av koden.
- Null data: Leverer ingen data når applikasjonen eller koden forventer at dataene.
- Feil data: Bestemme ytelsen til koden når data leveres i ulovlig format.
- Data om grensevilkår: Test data som leveres ut av indeksen eller matrisen for å bestemme hvordan koden utfører.
Testdata spiller en nøkkelrolle for å identifisere hvor et produkt eller en funksjon helt kan gå i stykker. Ha alltid en praksis med å avstemme og validere typen data som blir matet til testmiljøet i forskjellige faser av testen.
Test datahåndtering
Når testdata spiller en så viktig rolle for å kvalitetssikre produktet, er det rimelig å si at administrasjonen og effektiviseringen av den også spiller en like viktig rolle i kvalitetssikringen av ethvert produkt som må frigjøres til kundene.
Behov for testdataadministrasjon og beste praksis:
#1) Et stort antall organisasjoner har det raskt skiftende forretningsmål for å imøtekomme sluttbrukernes behov, og det er derfor unødvendig å nevne at de aktuelle testdataene er medvirkende til å bestemme kvaliteten på testingen. Dette vil innebære å sette opp den eksakte typen data for de respektive testmiljøene og overvåke atferdsmønstrene.
Som allerede diskutert, brukes en stor del av testteamets tid på planlegging av testdata og tilhørende oppgaver. Ofte blir testing av funksjonalitet ofte hemmet på grunn av manglende tilgjengelighet av passende testdata som utgjør en kritisk utfordring med hensyn til fullstendig testdekning.
#to) Noen ganger også for visse testkrav testdata må oppdateres kontinuerlig . Dette i seg selv forårsaker mye forsinkelse i syklusen på grunn av konstant omarbeid, noe som også øker kostnadene ved at applikasjonen når markedet.
I visse andre tider, hvis produktet som sendes, er involvert i forskjellige arbeidsgruppenheter i en stor organisasjon, krever oppretting og oppdatering av testdata et intrikat nivå av koordinering på tvers av disse arbeidsgruppene.
# 3) Selv om testteamene trenger å lage alle slags data som er mulig for å sikre tilstrekkelig testing, må organisasjoner også vurdere at å gjøre dette vil bety at alle de forskjellige typene data må lagres i en slags lager.
Selv om det er god praksis å ha et depot, er lagring av overdreven og uønskede data vil ikke bare øke lagringsplassen betydelig for å lagre disse store biter av data, men også gjøre det stadig mer utfordrende å hente de riktige dataene for den aktuelle testen hvis det ikke er versjonsvedlikehold og arkivering av dette depotet.
De fleste av organisasjonene står generelt overfor disse vanlige utfordringene med hensyn til testdata. Dermed må det være noen ledelsesstrategier som må settes på plass for å minimere graden av disse utfordringene.
Her nedenfor er noen foreslåtte metoder for styring av testdataene og holder dem relevante for testbehovene. Følgende fremgangsmåter er veldig grunnleggende og generiske, som ofte vil fungere for de fleste organisasjoner. Hvordan det blir adoptert, er bare skjønnet fra de respektive organisasjonene.
Test Data Management Strategies
# 1) Analyse av data
Generelt sett konstrueres testdata basert på testsakene som skal utføres. For eksempel i et systemtestingsteam, ende til slutt testscenario må identifiseres ut fra hvilke testdata som er utformet. Dette kan innebære en eller flere applikasjoner for å fungere.
Si i et produkt som administrerer arbeidsmengde - det involverer administrasjonskontrollapplikasjonen, mellomvareapplikasjonene, databaseapplikasjonene for å fungere i samarbeid med hverandre. De nødvendige testdataene for det samme kan spres. En grundig analyse av alle forskjellige typer data som kan være nødvendig, må gjøres for å sikre effektiv styring.
# 2) Dataoppsett for å speile produksjonsmiljøet
Dette er vanligvis en utvidelse fra forrige trinn og gjør det mulig å forstå hva sluttbruker eller produksjonsscenario vil være og hvilke data som kreves for det samme. Bruk disse dataene og sammenlign disse dataene med dataene som for øyeblikket eksisterer i det nåværende testmiljøet. Basert på denne nye data kan det hende du må opprette eller endre.
# 3) Bestemmelse av opprydding av testdata
Basert på testkravet i den nåværende utgivelsessyklusen (der en utgivelsessyklus kan strekke seg over lang tid), kan det hende at testdataene må endres eller opprettes som angitt i punktet ovenfor. Selv om disse testdataene ikke er umiddelbart relevante, kan det være nødvendig på et senere tidspunkt. Derfor bør det formuleres en klar prosess for å vurdere når testdataene kan ryddes opp.
# 4) Identifiser sensitive data og beskytt dem
Mange ganger for å teste applikasjoner riktig, kan det være en stor mengde veldig følsomme data som kreves. For eksempel, et skybasert testmiljø er et populært valg fordi det gjør testing av forskjellige produkter etter behov.
Imidlertid er noe så grunnleggende som å garantere brukernes personvern i en sky en bekymring. Så spesielt i tilfeller der vi trenger å replikere brukermiljøet, må mekanismen for å skjerme sensitive data identifiseres. Mekanismen styres i stor grad av volumet på testdataene som brukes.
# 5) Automasjon
Akkurat som vi tar i bruk automatisering for å kjøre repeterende tester eller for å kjøre de samme testene med forskjellige typer data, er det også mulig å automatisere opprettelsen av testdata. Dette vil hjelpe til med å avsløre eventuelle feil som kan oppstå med hensyn til data under testing. En mulig måte å gjøre dette på er ved å sammenligne resultatene som produseres av et sett med data fra påfølgende testkjøringer. Automatiser deretter denne prosessen med å sammenligne.
# 6) Effektiv dataoppdatering ved hjelp av et sentralt depot
Dette er den desidert viktigste metoden og danner hjertet i implementeringen av datahåndtering. Alle punktene nevnt ovenfor, spesielt de med hensyn til dataoppsett, dataopprydding er direkte eller indirekte knyttet til dette.
Mye innsats for å lage testdata kan lagres ved å opprettholde et sentralt depot som inneholder alle slags data som kan være nødvendige for forskjellige typer testing. Hvordan gjøres dette? I påfølgende testsykluser, for enten en ny testtilfelle eller endret testtilfelle, sjekk om dataene finnes i depotet. Hvis det ikke finnes, må du mate dataene i testmiljøet først.
Deretter kan dette rettes til dette depotet for fremtidig referanse. Nå for påfølgende utgivelsessykluser kan testteamet bruke alle eller en delmengde av disse dataene. Er ikke fordelen veldig tydelig? Avhengig av datasettene som ofte brukes, kan foreldede data lett elimineres og dermed sikre at riktige data alltid er tilstede, og dermed redusere kostnadene for å lagre de unødvendige dataene.
For det andre kan du også lagre et par versjoner av dette depotet eller endre det etter behov. Å ha forskjellige versjoner av depotet kan hjelpe sterkt i regresjonstesting for å identifisere hvilken endring i data som kan føre til at koden går i stykker.
Konklusjon
Testmiljøet skal være av største betydning i hvert testteam. Hver utgivelsessyklus vil gi en rekke nye utfordringer å bekjempe med et upålitelig og ikke planlagt testmiljø.
Som et revolusjonerende tiltak setter mange organisasjoner nå strategier på plass, for eksempel å danne dedikerte testmiljøvedlikeholdsteam som etablerer visse rammer for effektivt vedlikehold av testmiljøene, for å sikre jevnere frigjøringssykluser.
Forbedret testing er bare en åpenbar effekt av effektivisering av testdataadministrasjon. En viktig essens i det er at det sikrer en kostnadseffektiv løsning for organisasjoner uten å inngå kompromisser med produktets pålitelighet.
Gi oss beskjed om hvordan du administrerer testmiljøet ditt og hvordan du forbereder testdata? Vil du legge til noen tips?
Anbefalt lesing
- Topp 14 BESTE testdataadministrasjonsverktøy i 2021
- 10 beste verktøy for dataanalyse for perfekt datahåndtering [2021 LISTE]
- Test Management Tutorial: En Ultimate Guide To Test Management
- Hva er testdata? Testdata Klargjøringsteknikker med eksempel
- Data Pool Feature i IBM Rational Quality Manager for Test Data Management
- Selen Framework Creation and Accessing Test Data from Excel - Selenium Tutorial # 21
- Generering av testdata med GEDIS Studio Online Tool (del 2)