Infrastruktur er betegnelsen vi bruker for å beskrive all maskinvaren, alle skytjenestene, nettverkene, støtteprogramvaren og applikasjonen vi tester, som kreves for å utvikle, teste, distribuere og drifte systemene våre.
Det er likevel fornuftig å ikke begrense definisjonen vår til teknologi. Datasentre, kontorlokaler, skrivebord, stasjonære datamaskiner, bærbare datamaskiner, nettbrett og mobiltelefoner med egne installerte programvarestakker er alle en del av økosystemet som kreves for å utvikle, teste og distribuere systemer.
Hvis du inkluderer utviklerverktøy, DevOps-verktøy og -prosedyrer, testverktøy samt forretningsprosessene og fagkompetansen som kreves, omfatter det enda mer.
De mest hverdagslige tingene – tilgangskodene eller smartkortene som brukes for å få tilgang til bygninger – kan bli kritiske hvis de ikke er på plass.
Infrastruktur, i alle sine varianter, finnes for å støtte utvikling, testing, distribusjon og drift av systemene dine. Den er enten kritisk for testingen eller må testes.
Vi skal se på verktøy for utvikling, testing og samarbeid i neste artikkel. I denne artikkelen skal vi se på det de fleste oppfatter som testmiljøer, og kort se på det som ofte kalles infrastrukturtesting. Jeg skal dekke:
La oss sette i gang.
Testmiljøer
All testing bygger på en implisitt, kritisk og forenklende antakelse: at testene våre skal kjøres i et kjent miljø.
Hva er et miljø?
Alle systemer må testes i en kontekst. For at en test skal være meningsfull, må systemet installeres, konfigureres, distribueres eller bygges i et realistisk miljø som simulerer den virkelige verdenen der det skal brukes.
Vi kan for eksempel bruke testscenarioer som utfordrer systemenes kapasitet når det gjelder funksjonalitet, ytelse eller sikkerhet, men dette er egenskaper ved testene, ikke miljøet.
Et realistisk miljø vil gjenskape alle de forretningsmessige, tekniske og organisatoriske miljøene. Mye av dette består av data som brukes til å drive forretningsprosesser, konfigurere systemet og levere referansedata.
Men perfekt realistiske miljøer er vanligvis upraktiske eller altfor dyre (selv testere av systemer med høy kritikalitet, som fly, atomreaktorer eller hjerneskannere, må inngå kompromisser på et eller annet tidspunkt). Nesten all testing foregår i miljøer som simulerer den virkelige verdenen med et visst akseptabelt kompromissnivå.
Biler testes på rullebaner, i vindtunneler, på vibrasjonsbenker og på private testbaner før de testes på offentlig vei. Datasystemer testes i programvarelaboratorier av programmerere og programvaretestere før sluttbrukere involveres for å prøve dem ut i et produksjonslignende miljø.
For å sikre at testmiljøene dine holder bransjestandard, bør du vurdere å integrere en av disse høyt rangerte plattformene for testadministrasjon.
Have an account? Log In
Test i realistiske miljøer
Simulerte miljøer er feilbarlige, akkurat som kravene og testmodellene våre, men det må vi leve med.
Vi må planlegge tester som er meningsfulle i miljøene vi har tilgjengelig, og testresultater betyr det vi tolker dem som.
Påliteligheten til testresultatene avhenger av miljøet testene kjøres i. Hvis en test kjøres i et miljø som er feil konfigurert:
- En test som feiler, kan tyde på at systemet er defekt, når det faktisk er korrekt.
- En test som består, kan tyde på at systemet er korrekt, når det faktisk er defekt.
Begge situasjonene er selvsagt svært uønskede.
Få miljøer satt opp og levert i tide
Selv med fremveksten av skyinfrastruktur kan testmiljøer være vanskelige og kostbare å sette opp og vedlikeholde.
Når støtteteam arbeider med det nye produksjonsmiljøet, krever testerne testmiljøer (og kanskje flere av dem). Senere i testingen har støtteteamene ofte motstridende krav.
Utviklermiljøer eller andre senere testaktiviteter kan bli levert for sent eller ikke i det hele tatt, eller de kan være konfigurert eller kontrollert på en måte som ikke oppfyller kravene. Dette vil uunngåelig forsinke testingen og/eller svekke tilliten til ethvert resultat fra testingen.
En kritisk oppgave er å fastslå behovet for og kravene til et miljø som skal brukes til testing, inkludert en mekanisme for å håndtere endringer i dette miljøet—så snart som mulig.
Infrastruktur som kode er en nyere utvikling i hvordan miljøer kan bygges, med verktøy som følger prosedyrer og bruker deklarativ kode til å definere miljøoppsettet.
Selv om plattformer for grunnleggende operativsystemer (servere) enkelt kan opprettes i skyen eller som virtuelle maskiner i eget miljø, krever fullstendig spesifiserte servere for spesielle formål, med all nødvendig programvare, data, konfigurasjon og grensesnitt, mer arbeid.
Når du setter opp testinfrastrukturen, er det avgjørende å integrere pålitelig programvare for databasehåndtering for optimal ytelse
Når de først er satt opp, gir de imidlertid en svært effektiv måte å opprette miljøer på. Infrastrukturkode kan kildekodekontrolleres akkurat som all annen applikasjonskode og håndteres gjennom endringer.
Et hovedprinsipp for kontinuerlig levering er at noe programvare—selv om det ikke er nyttig—bør sendes gjennom leveringsrørledningen så snart som mulig for å bevise at prosessene fungerer.
Dette krever selvsagt egnede miljøer for bygginger, verktøy for kontinuerlig integrasjon, testing på systemnivå og distribusjon. Målet er å distribuere test- og produksjonsmiljøer uten begrensninger. Når miljødefinisjonene og distribusjonsprosessene er på plass, blir generering av miljøer en automatisert og rutinemessig oppgave.
Uansett omstendigheter er definisjonene av disse miljøene en tidlig leveranse fra prosjektet.
Utviklingsmiljøer
Utviklertesting fokuserer på konstruksjonen av programvarekomponenter som leverer funksjoner internt i applikasjonen eller på bruker- eller presentasjonslaget.
Tester drives vanligvis av kunnskap om kodens interne struktur, og de bruker eller krever kanskje ikke «realistiske» data for å kjøre. Tester av komponenter eller tjenester på lavt nivå kjøres vanligvis gjennom et API ved hjelp av spesialbygde eller proprietære drivere eller verktøy.
Utvalget av utviklingsverktøy, plattformer og såkalte integrerte utviklingsmiljøer (IDE-er) er enormt. I denne artikkelen kan vi bare komme inn på noen av de viktigste testrelaterte kravene og funksjonene i miljøer.
For å støtte utviklingen og testingen som omfattes av utviklernes arbeid, må miljøene støtte følgende aktiviteter. Dette er bare et utvalg—det kan finnes flere aktiviteter eller variasjoner av disse i din situasjon:
- Et «sandkassemiljø» for å eksperimentere med ny programvare. Sandkasser brukes ofte til å teste nye biblioteker, utvikle forkastbar prototypekode eller øve på programmeringsteknikker. Alle vanlige programmeringsspråk har hundrevis eller tusenvis av programvarebiblioteker. Sandkasser brukes til å installere og teste programvare som ennå ikke er en del av hovedgrenen i utviklingen, for å evaluere den og øve på å bruke den. Disse miljøene kan behandles som miljøer som kan forkastes.
- Lokalt utviklingsmiljø. Dette er stedet der utviklere vedlikeholder en lokal kopi av et delsett av eller all kildekoden for applikasjonen sin fra et delt kodelager, og kan opprette systembygginger for lokal testing. Dette miljøet gjør det mulig for utviklere å gjøre endringer i den lokale kopien av koden og teste endringene. Noen tester er ad hoc og blir kanskje aldri gjentatt. Andre tester er automatiserte. Automatiserte tester beholdes vanligvis permanent, særlig hvis de følger en testdrevet tilnærming.
- Delt miljø for (kontinuerlig) integrasjon. Når utviklerne mener at koden er klar, sender de endringene til det delte, kontrollerte kodelageret. CI-miljøet utfører automatiserte bygginger og kjører automatiserte tester ved hjelp av kodelageret. På dette tidspunktet er den nye eller endrede koden integrert og testet. CI-systemet kjører automatiserte tester ved behov, hver time eller daglig, og hele teamet får varsler og kan se teststatusen for den sist integrerte byggingen. Feil avdekkes raskt og håndteres som en hastesak.
Et utviklings- eller CI-miljø støtter utviklertesting, men andre applikasjonsservere, webtjenester, meldings- eller databaseservere som fullfører systemet, er kanskje ikke tilgjengelige.
Hvis disse grensesnittene ikke finnes fordi de ikke er bygget, eller fordi de tilhører et samarbeidende selskap og det bare finnes et produksjonssystem uten en testversjon, må utviklerne lage stubber eller simuleringer av disse grensesnittene for i det minste å kunne teste sin egen kode.
Verktøy for simulering kan være sofistikerte, men simulerte grensesnitt kan vanligvis ikke støtte tester som krever integrerte data på tvers av flere systemer.
Hvis et grensesnitt til en testdatabaseserver er tilgjengelig for utviklerne, kan testdataene deres være minimale, ikke integrerte eller konsistente og ikke representative for produksjonsdata.
Utviklingsdatabaser som deles av et team, er vanligvis utilfredsstillende. Hvis det ikke finnes et godt regime for å administrere denne delte ressursen, kan utviklerne gjenbruke, ødelegge eller slette hverandres data.
Testmiljøer på systemnivå
Testing på systemnivå fokuserer på integrasjonen av komponenter og delsystemer i samarbeid.
Disse miljøene tilbyr en plattform som støtter målene for integrasjon i større skala, funksjonsvalidering og systemdrift i konteksten av bruker- eller forretningsprosesser.
Miljøer kan også være dedikert til systemets ikke-funksjonelle aspekter, som ytelse, sikkerhet eller tjenesteadministrasjon.
En av de vanligste fallgruvene ved testing oppstår når en systemtester opplever en eller annen form for feil i sitt miljø, men utvikleren eller testeren ikke klarer å gjenskape feilen i utviklingsmiljøet, uansett hvor hardt de prøver.
Dette skyldes nesten helt sikkert manglende samsvar mellom de to miljøene. Forskjellen i atferd kan skyldes konfigurasjonen, forskjeller i programvareversjoner eller forskjeller i dataene i databasen.
Forskjeller i data som forårsaker problemer, er det første som bør undersøkes. De er vanligvis enkle å identifisere og kan ofte løses raskt.
Når det finnes et avvik i programvareversjon eller konfigurasjon, kan testere og utviklere kaste bort mye tid på å spore årsaken til forskjellen i atferd.
Når disse problemene oppstår, betyr det ofte at det har sviktet i kommunikasjonen mellom utvikleren og testeren. Det kan også indikere manglende konfigurasjonskontroll i oppsettet av utviklings- eller testmiljøet eller i distribusjonsprosessen.
Infrastruktur som kode og automatisert klargjøring av miljøer vil gjøre problemer med samsvar mellom miljøer til en saga blott.
Typer dedikerte testmiljøer
For å støtte systemtesting, akseptansetesting og ikke-funksjonell testing må miljøene støtte følgende aktiviteter (det kan finnes flere i organisasjonen din):
- (Funksjonelt) systemtestmiljø. I dette miljøet valideres systemet mot kravene som er dokumentert for systemet som helhet. Kravene kan være store tekstdokumenter med tabellariske testtilfeller definert for en systemtest. I smidige prosjekter kan dette miljøet være nødvendig for at testere skal kunne utforske det integrerte systemet uten å begrense seg til bestemte funksjoner.
- Ende-til-ende-test-miljø. Der CI-miljøet gjør det mulig å integrere komponenter med delsystemer, kan forretningsprosessene kreve at andre grensesnittytende systemer (som ikke er under utviklernes kontroll) er tilgjengelige. Omfattende miljøer kreves for å gjennomføre storskala integrasjon, forretningsprosess- eller overordnet akseptansetesting. Vanligvis er dataene en kopi av produksjonsdata, eller i det minste av passende størrelse. Når storskala integrasjon skal verifiseres, testes data- og kontrollflytene ved hjelp av lengre brukerreiser og uavhengige avstemminger av dataene på tvers av integrerte systemer. Håndtering av data i testmiljøer er avgjørende. Hvis du allerede bruker Jira, bør du vurdere å forbedre datahåndteringsfunksjonene dine med avanserte testhåndteringsverktøy utviklet for Jira.
- Ytelsesmiljø. Disse miljøene må tilby en meningsfull plattform for evaluering av ytelsen til et system (eller utvalgte delsystemer). Kompromisser i arkitekturen kan være mulige der det finnes redundans eller kloning av servere. Datamengdene må imidlertid være på produksjonsnivå, selv om dataene er syntetiske. Miljøet må naturligvis ha en størrelse som støtter produksjonens transaksjonsvolumer, slik at det blir mulig å forutsi systemenes ytelse i produksjon på en nyttig måte.
- Miljøer for tilgjengelighet, robusthet og håndterbarhet (ARM). På noen måter ligner disse miljøene på ytelsesmiljøene, men avhengig av testmålet kan variasjoner være uunngåelige. Tilgjengelighetstesting har som mål å verifisere at systemet kan fungere over lengre perioder uten å feile. Robusthetstesting (ofte kalt failovertesting) kontrollerer at systemkomponenter som feiler, ikke forårsaker et uakseptabelt avbrudd i den leverte tjenesten. Håndterbarhets- eller driftstesting har som mål å demonstrere at systemets administrative prosedyrer, administrasjonsprosedyrer samt prosedyrer for sikkerhetskopiering og gjenoppretting fungerer effektivt.
More Articles
Data i miljøer
I noen svært store prosjekter kan det finnes så mange som 20 eller til og med 30 storskala miljøer som er dedikert til ulike aspekter av testing, opplæring, datamigrering og prøvevise overganger. I mindre prosjekter vil det være færre, kanskje bare ett delt miljø eller et regime for kontinuerlig levering – og all testing kan være automatisert i miljøer som opprettes for engangsbruk og deretter fjernes.
Alle miljøer trenger data, men dataenes omfang og grad av realisme kan variere. Her er noen vanlige mønstre for hvordan testdata anskaffes og håndteres. Disse mønstrene fokuserer på eierskap (lokalt eller delt), hvordan dataene opprettes (manuelt, automatisert eller kopiert fra produksjon), og omfang:
- Lokale, manuelt opprettede data i liten skala – egnet for ad hoc-testing utført av utviklere eller testere.
- Lokale, automatiserte, syntetiske data. Egnet for automatiserte utviklertester eller miljøer der funksjonaliteten til bestemte moduler eller funksjoner kan dekkes.
- Delte, manuelt opprettede data. Brukes i integrasjons- og systemtestmiljøer, ofte der testdataene har utviklet seg parallelt med manuelt utførte tester. Sikkerhetskopieres og gjenopprettes ved behov.
- Delte, automatisk opprettede data. Brukes i integrasjons- og systemtestmiljøer der testdataene har utviklet seg parallelt med automatiserte eller manuelt utførte tester. Genereres og/eller gjenopprettes fra sikkerhetskopier ved behov.
- Delte syntetiske/tilfeldige data i stor skala. Ytelses- og ARM-testing krever sammenhengende data i store mengder. Disse dataene trenger vanligvis ikke å være meningsfulle – randomiserte data fungerer fint og genereres ved behov, eller genereres først og gjenopprettes fra sikkerhetskopier.
- Delte meningsfulle data i stor skala. Ende-til-ende-testing, akseptansetesting eller brukertesting trenger vanligvis meningsfulle data i stor skala. Noen ganger brukes kopier eller uttrekk fra produksjonsdata. Pass imidlertid på at du ikke bryter datalover hvis du ikke krypterer eller anonymiserer dem.
- Ny testing og regresjonstesting. Du trenger et kjent og kontrollert datasett i en kjent tilstand, så det gjenopprettes vanligvis fra sikkerhetskopier. Dette gjelder alle miljøene ovenfor, ettersom disse testene må kjøres på nytt med data i en kjent tilstand for å gjenskape feil på en pålitelig måte.
Infrastrukturtesting
I begynnelsen av denne artikkelen så vi på hva infrastrukturen omfatter, og siden da har vi hovedsakelig fokusert på de tekniske komponentene, nemlig programvaresystemene, og antatt at maskinvaren – fysisk eller virtuell – er tilgjengelig.
Når vi bygger systemer i utgangspunktet, antar vi at infrastrukturen finnes og at den fungerer korrekt, har god ytelse, er sikker og robust, osv.
Vi kan teste alle disse aspektene når vi har integrert applikasjonen vår, og uten tvil avdekke svakheter i infrastrukturen på et relativt sent tidspunkt i prosjektene våre. Men å finne infrastrukturproblemer så sent i et prosjekt er vanligvis svært forstyrrende.
- Endringer for å håndtere feil i infrastrukturen kan kreve betydelig redesign og endringer i applikasjonen vår.
- Resultater fra applikasjonen vår eller testing av hele systemet må gjentas.
- Hvis tredjepartskomponenter som database-, web-, nettverks- eller meldingstjenester svikter, er vi prisgitt leverandørene (eller fellesskapet for åpen kildekode) som støtter dem.
For å sikre at tilliten vår til infrastrukturkomponentene er velbegrunnet, kan vi basere oss på vår egen eller andres erfaring med å bruke dem tidligere. Alternativt må vi vurdere – gjennom testing – hvor pålitelige de er før vi forplikter oss til å bruke dem i utformingen og konstruksjonen av systemet vårt.
Avhengig av infrastrukturen som undersøkes, kan miljøet vi bruker variere – fra én enkelt server til en nesten komplett infrastrukturplattform.
Selv om noen tester vil være manuelle, vil vi for det meste bruke verktøy, drivere eller roboter til å simulere transaksjonsbelastningen applikasjonen vår ville generert. Vi må etterligne eller stubbe ut disse grensesnittene:
- Grensesnitt som for øyeblikket ikke er tilgjengelige
- Grensesnitt til komponenter vi stoler på, og som er enkle å simulere
- Grensesnitt som ikke inngår i omfanget, og som ikke påvirker infrastrukturen som testes.
Infrastruktur opererer som kjent vanligvis ikke gjennom et bruker- eller GUI-grensesnitt.
Integrasjonen av applikasjonen vår med infrastrukturen vil for det meste skje i form av meldinger eller kall til eksterne tjenester. Ofte krever trafikken som skal simuleres API-kall til enten web- eller applikasjonsservere, meldings- eller databaseservere, eller tjenester som leveres gjennom skyen eller fra eksterne lokasjoner.
Ytelses- og ARM-mål kan være kjent, og i så fall kan tester utføres for å sikre at disse målene nås.
Infrastruktur deles imidlertid ofte med andre applikasjoner enn vår egen, så det å kjenne den endelige kapasiteten hjelper oss med å vurdere hvor mye kapasitet som vil være igjen når applikasjonen vår settes i produksjon.
I dette tilfellet håndterer infrastrukturtesting risikoen for vår egen og eventuelt andre applikasjoner som i fremtiden skal baseres på den.
Meld deg på nyhetsbrevet til The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det sterkeste anbefaler for å få en dypere gjennomgang av dette og andre emner. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få $60 i rabatt på full kurspris!
Anbefalt lesning: 10 BESTE TESTADMINISTRASJONSVERKTØY MED ÅPEN KILDEKODE
