Infrastruktur er det begreb, vi bruger til at beskrive al den hardware, alle cloudtjenester, netværk, understøttende software og vores applikation under test, der kræves for at udvikle, teste, implementere og drive vores systemer.
Det giver dog mening ikke at begrænse vores definition til teknologi. Datacentre, kontorlokaler, skriveborde, stationære computere, bærbare computere, tabletcomputere og mobiltelefoner med deres egne installerede softwarestakke er alle en del af det økosystem, der kræves for at udvikle, teste og implementere systemer.
Hvis du medtager udviklerværktøjer, DevOps-værktøjer og -procedurer, testværktøjer samt de forretningsprocesser og den fagekspertise, der er nødvendig, er der endnu mere at tage højde for.
Selv de mest trivielle ting – adgangskoderne eller chipkortene, der bruges til at få adgang til bygninger – kan blive kritiske, hvis de ikke er på plads.
Infrastruktur i alle dens forskellige former findes for at understøtte udvikling, test, implementering og drift af dine systemer. Den er enten kritisk for test eller skal testes.
Vi ser på værktøjer til udvikling, test og samarbejde i den næste artikel. I denne artikel ser vi på det, som de fleste betragter som testmiljøer, og tager kort et kig på det, der ofte kaldes infrastrukturtest. Jeg vil gennemgå:
Lad os komme i gang.
Testmiljøer
Al testning bygger på en implicit, kritisk og forenklende antagelse: at vores tests vil blive kørt i et kendt miljø.
Hvad er et miljø?
Alle systemer skal testes i en kontekst. For at en test kan være meningsfuld, skal systemet installeres, konfigureres, implementeres eller bygges i et realistisk miljø, der simulerer den virkelige verden, hvor det skal bruges.
Vi kan for eksempel bruge testscenarier, der udfordrer systemernes kapacitet med hensyn til funktionalitet, ydeevne eller sikkerhed, men det er egenskaber ved testene, ikke ved miljøet.
Et realistisk miljø ville gengive alle de forretningsmæssige, tekniske og organisatoriske miljøer. En stor del af dette består af data, der bruges til at drive forretningsprocesser, konfigurere systemet og levere referencedata.
Men fuldstændig realistiske miljøer er som regel upraktiske eller alt for dyre (selv testere af systemer med høj kritikalitet, såsom fly, atomreaktorer eller hjernescannere, er nødt til at indgå kompromiser på et tidspunkt). Næsten al testning foregår i miljøer, der simulerer den virkelige verden med et acceptabelt kompromisniveau.
Biler testes på rullefelter, i vindtunneller, på vibrationsbænke og på private testbaner, før de testes på offentlig vej. Computersystemer testes i softwarelaboratorier af programmører og softwaretestere, før slutbrugere involveres for at afprøve dem i et produktionslignende miljø.
For at sikre, at dine testmiljøer lever op til branchestandarderne, kan du overveje at integrere en af disse bedst bedømte teststyringsplatforme.
Have an account? Log In
Test i realistiske miljøer
Simulerede miljøer er fejlbehæftede, ligesom vores krav og testmodeller, men det må vi leve med.
Vi skal planlægge tests, der er meningsfulde i de miljøer, vi har til rådighed, og testresultater betyder det, vi fortolker dem som.
Testresultaternes pålidelighed afhænger af det miljø, testene køres i. Hvis en test køres i et miljø, der er konfigureret forkert:
- En test, der fejler, kan antyde, at systemet er defekt, når det faktisk er korrekt.
- En test, der består, kan antyde, at systemet er korrekt, når det faktisk er defekt.
Begge situationer er naturligvis meget uønskede.
Opsætning og levering af miljøer til tiden
Selv med fremkomsten af cloudinfrastruktur kan testmiljøer være vanskelige og dyre at opsætte og vedligeholde.
Når supportteams arbejder på det nye produktionsmiljø, kræver testerne testmiljøer (og måske flere af dem). Senere i testforløbet har supportteams ofte konkurrerende krav.
Udviklermiljøer eller enhver senere testaktivitet kan blive leveret for sent eller slet ikke, eller de er måske ikke konfigureret eller kontrolleret som krævet. Dette vil uundgåeligt forsinke testningen og/eller undergrave tilliden til ethvert resultat af testningen.
En kritisk opgave er at fastlægge behovet for og kravene til et miljø, der skal bruges til testning, herunder en mekanisme til håndtering af ændringer i dette miljø—så tidligt som muligt.
Infrastruktur som kode er en nyere udvikling i den måde, miljøer kan konstrueres på, med værktøjer, der følger procedurer og bruger deklarativ kode til at definere miljøopsætningen.
Selvom grundlæggende operativsystemplatforme (servere) nemt kan oprettes i skyen eller som virtuelle maskiner i dit eget miljø, kræver fuldt specificerede servere til særlige formål med al nødvendig software, data, konfiguration og grænseflader mere arbejde.
Når du opsætter din testinfrastruktur, er det afgørende at integrere pålidelig software til databasehåndtering for at opnå optimal ydeevne.
Når de først er opsat, giver de dog en meget effektiv måde at oprette miljøer på. Infrastrukturkode kan versionsstyres ligesom enhver applikationskode og håndteres gennem ændringer.
Et vigtigt princip i løbende levering er, at noget software—selv ikke nødvendigvis noget nyttigt—så hurtigt som muligt skal sendes gennem leveringspipen for at bevise, at processerne fungerer.
Dette kræver naturligvis anvendelige miljøer til byggeprocesser, værktøjer til løbende integration, test på systemniveau og implementering. Målet er at implementere test- og produktionsmiljøer uden begrænsninger. Når miljødefinitionerne og implementeringsprocesserne er på plads, bliver generering af miljøer en automatiseret og rutinemæssig opgave.
Uanset omstændighederne er definitionerne af disse miljøer en tidlig leverance fra projektet.
Udviklingsmiljøer
Udviklertest fokuserer på konstruktionen af softwarekomponenter, der leverer funktioner internt i applikationen eller på bruger- eller præsentationslaget.
Test drives typisk af kendskab til kodens interne struktur, og de bruger eller kræver muligvis ikke ‘realistiske’ data for at kunne køres. Test af komponenter eller tjenester på lavt niveau køres normalt gennem en API ved hjælp af specialbyggede eller proprietære drivere eller værktøjer.
Udvalget af udviklingsværktøjer, platforme og såkaldte integrerede udviklingsmiljøer (IDEs) er enormt. I denne artikel kan vi kun berøre nogle af de vigtigste testrelaterede krav og funktioner i miljøer.
For at understøtte udviklingen og den testning, der ligger inden for udviklernes ansvarsområde, skal miljøerne understøtte følgende aktiviteter. Dette er blot et udvalg—der kan være yderligere aktiviteter eller variationer af disse aktiviteter i din situation:
- Et ‘sandkasse’-miljø til eksperimenter med ny software. Sandkasser bruges ofte til at teste nye biblioteker, udvikle prototypekode, der skal kasseres, eller øve programmeringsteknikker. Alle almindelige programmeringssprog har hundredvis eller tusindvis af softwarebiblioteker. Sandkasser bruges til at installere og teste software, der endnu ikke er en del af den primære udviklingslinje, for at evaluere den og øve sig i at bruge den. Disse miljøer kan behandles som miljøer til engangsbrug.
- Lokalt udviklingsmiljø. Det er her, udviklere vedligeholder en lokal kopi af en delmængde af eller al kildekoden til deres applikation fra et delt kodelager og kan oprette systembygninger til lokal testning. Dette miljø giver udviklerne mulighed for at foretage ændringer i koden i deres lokale kopi og teste ændringerne. Nogle test er ad hoc og gentages måske aldrig. Andre test er automatiserede. Automatiserede test gemmes normalt for altid, især hvis de følger en testdrevet tilgang.
- Delt miljø til (løbende) integration. Når udviklerne har tillid til, at deres kode er klar, sender de deres ændringer til det delte, kontrollerede kodelager. CI-miljøet udfører automatiserede byggeprocesser og kører automatiserede test ved hjælp af kodelageret. På dette tidspunkt er den nye eller ændrede kode integreret og testet. CI-systemet kører automatiserede test efter behov, hver time eller dagligt, og hele teamet modtager meddelelser og kan se status for testene af den senest integrerede byggeversion. Fejl bliver hurtigt synlige og håndteres som en hastesag.
Et udviklings- eller CI-miljø understøtter udviklertest, men andre applikationsservere, webtjenester, meddelelsessystemer eller databaseservere, der fuldender systemet, er muligvis ikke tilgængelige.
Hvis disse grænsefladesystemer ikke findes, fordi de ikke er blevet bygget, eller fordi de tilhører en samarbejdsvirksomhed, og der kun findes et produktionssystem uden en testversion, er udviklerne nødt til at lave stubbe eller mocks af disse grænseflader for i det mindste at kunne teste deres egen kode.
Mockingværktøjer kan være avancerede, men mockede grænseflader kan normalt ikke understøtte test, der kræver integrerede data på tværs af flere systemer.
Hvis en grænseflade til en testdatabaseserver er tilgængelig for udviklerne, er deres testdata muligvis minimale, ikke integrerede eller konsistente og ikke repræsentative for produktionsdata.
Udviklingsdatabaser, der deles på tværs af et team, er normalt utilfredsstillende. Hvis der ikke findes en god praksis for administration af denne delte ressource, kan udviklerne genbruge, ødelægge eller slette hinandens data.
Testmiljøer på systemniveau
Test på systemniveau fokuserer på integrationen af komponenter og undersystemer i samarbejde.
Disse miljøer udgør en platform, der understøtter målene for integration i større skala, validering af funktionalitet og systemdrift i forbindelse med bruger- eller forretningsprocesser.
Miljøer kan også være dedikeret til systemets ikke-funktionelle aspekter, såsom ydeevne, sikkerhed eller servicestyring.
En af de mest almindelige faldgruber ved test opstår, når en systemtester i sit miljø oplever en eller anden form for fejl, men udvikleren eller testeren ikke kan genskabe fejlen i udviklingsmiljøet, uanset hvor hårdt de prøver.
Dette skyldes næsten helt sikkert manglende ensartethed mellem de to miljøer. Forskellen i adfærd kan skyldes konfigurationen, forskelle i softwareversioner eller forskelle i dataene i databasen.
Forskelle i data, der forårsager problemer, er det første, man bør undersøge. De er normalt nemme at identificere og kan ofte løses hurtigt.
Når der er en uoverensstemmelse i softwareversion eller konfiguration, kan testere og udviklere spilde meget tid på at finde årsagen til forskellen i adfærd.
Når disse problemer opstår, betyder det ofte, at der er svigt i kommunikationen mellem udvikleren og testmiljøet. Det kan også indikere manglende konfigurationsstyring i opsætningen af udviklings- eller testmiljøet eller i implementeringsprocessen.
Infrastruktur som kode og automatiseret klargøring af miljøer vil gøre problemer med ensartethed mellem miljøer til fortid.
Typer af dedikerede testmiljøer
For at understøtte systemtest, accepttest og ikke-funktionel test skal miljøerne understøtte følgende aktiviteter (der kan være flere i din organisation):
- (Funktionelt) systemtestmiljø. I dette miljø valideres systemet i forhold til de krav, der er dokumenteret for systemet som helhed. Krav kan være store tekstdokumenter med tabeller over testcases, der er defineret til en systemtest. I agile projekter kan dette miljø være nødvendigt for at give testere mulighed for at udforske det integrerede system uden at begrænse sig til specifikke funktioner.
- Slutpunkt-til-slutpunkt-test-miljø. Hvor CI-miljøet gør det muligt at integrere komponenter med delsystemer, kan forretningsprocesserne kræve, at andre systemer, der fungerer som grænseflader (og som ikke er under udviklernes kontrol), er tilgængelige. Miljøer med fuldt omfang er nødvendige for at gennemføre omfattende integrationstest, test af forretningsprocesser eller overordnet accepttest. Dataene er normalt en kopi af produktionsdata eller i det mindste af en passende størrelsesorden. Når omfattende integration skal dokumenteres, afprøves data- og kontrolstrømmene ved hjælp af længere brugerrejser og uafhængige afstemninger af dataene på tværs af integrerede systemer. Håndtering af data i test-miljøer er afgørende. Hvis du allerede bruger Jira, kan du overveje at forbedre dine datahåndteringsfunktioner med avancerede teststyringsværktøjer designet til Jira.
- Ydelsesmiljø. Disse miljøer skal udgøre en meningsfuld platform til evaluering af et systems (eller udvalgte delsystemers) ydeevne. Der kan være mulighed for kompromiser i arkitekturen, hvor der er redundans eller kloning af servere. Datamængderne skal dog være på produktionsniveau, selv hvis dataene er syntetiske. Miljøet skal naturligvis have en størrelse, der understøtter produktionsmængder af transaktioner, så det bliver muligt at forudsige systemernes ydeevne i produktion på en anvendelig måde.
- Miljøer for tilgængelighed, robusthed og håndterbarhed (ARM). På nogle områder ligner disse miljøer ydelsesmiljøerne, men variationer kan være uundgåelige afhængigt af testmålet. Test af tilgængelighed har til formål at verificere, at systemet kan fungere i længere perioder uden fejl. Robusthedstest (ofte kaldet failovertest) kontrollerer, at systemkomponenter, der svigter, ikke forårsager en uacceptabel afbrydelse af den leverede tjeneste. Test af håndterbarhed eller drift har til formål at demonstrere, at systemets administrative procedurer samt procedurer for administration, sikkerhedskopiering og gendannelse fungerer effektivt.
More Articles
Data i miljøer
I nogle meget store projekter kan der være så mange som 20 eller endda 30 omfattende miljøer, der er dedikeret til forskellige aspekter af test, oplæring, datamigrering og prøveovergange. I mindre projekter vil der være færre, måske kun ét delt miljø eller en kontinuerlig leveringsmodel—og al test kan være implementeret automatisk i miljøer, der oprettes til engangsbrug og derefter nedlægges.
Alle miljøer har brug for data, men dataenes omfang og grad af realisme kan variere. Her er nogle almindelige mønstre for, hvordan testdata anskaffes og håndteres. Disse mønstre fokuserer på ejerskab (lokalt eller delt), oprettelsesmetoden (manuelt, automatiseret eller kopieret fra produktion) og omfang:
- Lokale, manuelt oprettede data i lille skala—egnet til ad hoc-test udført af udviklere eller testere.
- Lokale, automatiserede, syntetiske data. Egnede til udvikleres automatiserede test eller miljøer, hvor funktionaliteten i specifikke moduler eller funktioner kan dækkes.
- Delte, manuelt oprettede data. Bruges i integrations- og systemtestmiljøer, ofte hvor testdata er udviklet parallelt med manuelt udførte test. Sikkerhedskopieres og gendannes efter behov.
- Delte, automatisk oprettede data. Bruges i integrations- og systemtestmiljøer, hvor testdata er udviklet parallelt med automatiserede eller manuelt udførte test. Genereres og/eller gendannes fra sikkerhedskopier efter behov.
- Delte syntetiske/tilfældige data i stor skala. Ydelses- og ARM-test kræver sammenhængende data i store mængder. Disse data behøver normalt ikke at være meningsfulde – tilfældige data fungerer fint og genereres efter behov eller genereres indledningsvist og gendannes fra sikkerhedskopier.
- Delte meningsfulde data i stor skala. Slutpunkt-til-slutpunkt-test, accepttest eller brugertest har normalt brug for meningsfulde data i stor skala. Nogle gange bruges kopier eller udtræk fra produktionsdata. Pas dog på ikke at overtræde databeskyttelsesreglerne, hvis du ikke slører eller anonymiserer dem.
- Gentest og regressionstest. Du får brug for et kendt, kontrolleret datasæt i en kendt tilstand, så det gendannes normalt fra sikkerhedskopier. Dette gælder for alle ovenstående miljøer, da disse test skal køres igen med data i en kendt tilstand for pålideligt at kunne reproducere fejl.
Infrastrukturtest
I begyndelsen af denne artikel så vi på, hvad infrastrukturen omfatter, og siden da har vi primært fokuseret på de tekniske komponenter, nemlig softwaresystemerne, og antaget, at hardwaren—fysisk eller virtuel—er tilgængelig.
Når vi bygger systemer indledningsvist, antager vi, at infrastrukturen eksisterer, og at den fungerer korrekt, har god ydeevne, er sikker og robust osv.
Vi kan teste alle disse aspekter, når vi har integreret vores applikation, og uden tvivl afdække mangler i infrastrukturen på et relativt sent tidspunkt i vores projekter. Men det er normalt ekstremt forstyrrende at finde infrastrukturproblemer så sent i et projekt.
- Ændringer for at håndtere fejl i infrastrukturen kan kræve betydeligt omdesign og ændringer i vores applikation.
- Resultater fra vores applikations- eller helsystemtest skal gentages.
- Hvis tredjepartskomponenter såsom database-, web-, netværks- eller beskedtjenester svigter, er vi afhængige af leverandørerne (eller fællesskabet for åben kildekode), som understøtter dem.
For at sikre, at vores tillid til infrastrukturkomponenterne er velbegrundet, kan vi basere os på vores egen eller andres erfaring med at bruge dem tidligere. Eller vi er nødt til at vurdere deres pålidelighed gennem test, før vi forpligter os til at bruge dem i designet og opbygningen af vores system.
Afhængigt af den infrastruktur, der undersøges, kan det miljø, vi bruger, variere fra en enkelt server til en næsten komplet infrastrukturplatform.
Selvom nogle test vil være manuelle, vil vi for det meste bruge værktøjer, drivere eller robotter til at simulere den transaktionsbelastning, som vores applikation ville generere. Vi er nødt til at simulere eller oprette stubbe for disse grænseflader:
- Grænseflader, der i øjeblikket ikke er tilgængelige
- Grænseflader til komponenter, som vi har tillid til, og som er nemme at simulere
- Grænseflader, der ikke er omfattet af omfanget, og som ikke påvirker den infrastruktur, der testes.
Infrastruktur fungerer som bekendt normalt ikke gennem en bruger- eller GUI-grænseflade.
Integrationen af vores applikation med infrastrukturen vil for det meste ske i form af beskeder eller kald til eksterne tjenester. Ofte kræver den trafik, der skal simuleres, API-kald til enten web- eller applikationsservere, besked- eller databaseservere eller tjenester, der leveres gennem skyen eller fra eksterne lokationer.
Ydelses- og ARM-målsætninger kan være kendte, og i så fald kan der udføres test for at sikre, at disse målsætninger opfyldes.
Infrastrukturen deles dog ofte med andre applikationer end vores egen, så kendskab til dens maksimale kapacitet hjælper med at vurdere, hvor meget kapacitet der vil være tilbage, når vores applikation implementeres.
I dette tilfælde adresserer infrastrukturtest risikoen for vores egen og måske andre applikationer, der fremover skal baseres på den.
Tilmeld dig The QA Lead-nyhedsbrevet for at få besked, når nye dele af serien udgives. Disse indlæg er uddrag fra Pauls kursus i ledelse inden for test, som vi varmt anbefaler, hvis du vil gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER og få $60 i rabat på den fulde kursuspris!
Forslag til læsning: 10 BEDSTE VÆRKTØJER TIL TESTSTYRING MED ÅBEN KILDEKODE
