Förbättra programvarukvaliteten & spara tid med infrastrukt testning
Redaktörens anmärkning: Välkommen till serien Ledarskap inom testning från mjukvarutestningsgurun och konsulten Paul Gerrard. Serien är utformad för att hjälpa testare med några års erfarenhet – särskilt de som arbetar i agila team – att lyckas i roller som testledare och testchef.
I en tidigare artikel gick jag igenom hur man hanterar prestandatestning. Nu ska vi diskutera IT-infrastrukturprogramvara, testinfrastruktur och testmiljöer.
Anmäl dig till nyhetsbrevet från The QA Lead för att få aviseringar när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs Ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på hela kurspriset!
Infrastruktur är den term vi använder för att beskriva all maskinvara, alla molntjänster, nätverk, stödprogramvara och vår applikation under test som krävs för att utveckla, testa, distribuera och driva våra system.
Det är dock klokt att inte begränsa vår definition till teknik. Datacenter, kontorsutrymmen, skrivbord, stationära datorer, bärbara datorer, surfplattor och mobiltelefoner med egna installerade programvarustackar är alla delar av det ekosystem som krävs för att utveckla, testa och distribuera system.
Om du även inkluderar utvecklarverktyg, DevOps-verktyg och -procedurer, testverktyg samt de affärsprocesser och den ämneskompetens som krävs, blir det ännu mer omfattande.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
De mest alldagliga sakerna – åtkomstkoderna eller de smartkort som används för att få tillträde till byggnader – kan bli kritiska om de inte finns på plats.
Infrastruktur, i alla sina olika former, finns till för att stödja utveckling, testning, distribution och drift av dina system. Den är antingen avgörande för testningen eller behöver testas.
Vi ska titta på verktyg för utveckling, testning och samarbete i nästa artikel. I den här artikeln ska vi gå igenom vad de flesta betraktar som testmiljöer och kortfattat titta på det som ofta kallas infrastrukturtestning. Jag kommer att ta upp:
Då kör vi.
Testmiljöer
All testning bygger på ett underförstått, kritiskt och förenklande antagande: att våra tester kommer att köras i en känd miljö.
Vad är en miljö?
Alla system måste testas i sitt sammanhang. För att ett test ska vara meningsfullt måste systemet installeras, konfigureras, distribueras eller byggas i en realistisk miljö som simulerar den verkliga värld där det kommer att användas.
Vi kan till exempel använda testscenarier som pressar systemens kapacitet när det gäller funktionalitet, prestanda eller säkerhet, men detta är egenskaper hos testerna, inte hos miljön.
En realistisk miljö skulle återskapa alla affärsmässiga, tekniska och organisatoriska miljöer. En stor del av detta utgörs av data som används för att driva affärsprocesser, konfigurera systemet och tillhandahålla referensdata.
Men helt realistiska miljöer är vanligtvis opraktiska eller alldeles för dyra (även testare av system med mycket höga krav på kritisk säkerhet, till exempel flygplan, kärnreaktorer eller hjärnskannrar, måste kompromissa någonstans). Nästan all testning sker i miljöer som simulerar den verkliga världen med en viss acceptabel kompromissnivå.
Bilar testas på rullbanor, i vindtunnlar, på vibrationsbäddar och på privata testbanor innan de testas på allmän väg. Datorsystem testas i programvarulaboratorier av programmerare och programvarutestare innan slutanvändare involveras för att prova dem i en produktionslik miljö.
För att säkerställa att dina testmiljöer uppfyller branschstandarderna kan du överväga att integrera någon av dessa högst rankade plattformar för testhantering.
Testa i realistiska miljöer
Simulerade miljöer är felbenägna, precis som våra krav och testmodeller, men vi måste leva med det.
Vi måste genomföra tester som är meningsfulla i de miljöer vi har tillgång till, och testresultaten betyder det vi tolkar dem som.
Tillförlitligheten hos testresultaten beror på den miljö där testerna körs. Om ett test körs i en miljö som är felaktigt konfigurerad:
- Ett test som misslyckas kan antyda att systemet är felaktigt när det i själva verket är korrekt.
- Ett test som lyckas kan antyda att systemet är korrekt när det i själva verket är felaktigt.
Båda situationerna är naturligtvis mycket oönskade.
Att konfigurera och leverera miljöer i tid
Även med framväxten av molninfrastruktur kan testmiljöer vara svåra och dyra att konfigurera och underhålla.
När supportteamen arbetar med den nya produktionsmiljön kräver testarna testmiljöer (och kanske flera sådana). Senare under testningen har supportteamen ofta motstridiga krav.
Utvecklingsmiljöer eller annan senare testaktivitet kan levereras sent eller inte alls, eller så kanske de inte är konfigurerade eller kontrollerade enligt kraven. Detta kommer oundvikligen att fördröja testningen och/eller undergräva förtroendet för alla testresultat.
En kritisk uppgift är att fastställa behovet av och kraven på en miljö som ska användas för testning, inklusive en mekanism för att hantera ändringar i den miljön—så snart som möjligt.
Infrastruktur som kod är en ny utveckling i hur miljöer kan konstrueras, med verktyg som följer procedurer och använder deklarativ kod för att definiera miljökonfigurationen.
Även om grundläggande operativsystemplattformar (servrar) enkelt kan skapas i molnet eller som virtuella maskiner i den egna miljön, kräver fullständigt specificerade servrar för särskilda ändamål, med all nödvändig programvara, data, konfigurationer och gränssnitt, mer arbete.
När du konfigurerar din testinfrastruktur är det avgörande att integrera tillförlitlig programvara för databashantering för optimal prestanda
När de väl har konfigurerats ger de dock ett mycket effektivt sätt att skapa miljöer. Infrastrukturkod kan versionshanteras på samma sätt som all annan applikationskod och hanteras genom ändringar.
En viktig grundprincip för kontinuerlig leverans är att viss programvara—även om den inte är användbar—ska skickas genom leveranspipelinen så snart som möjligt för att bevisa att processerna fungerar.
Detta kräver naturligtvis fungerande miljöer för byggen, verktyg för kontinuerlig integrering, testning på systemnivå och driftsättning. Målet är att kunna driftsätta test- och produktionsmiljöer utan begränsningar. När miljödefinitionerna och driftsättningsprocesserna är på plats blir skapandet av miljöer en automatiserad och rutinmässig uppgift.
Oavsett omständigheterna är definitionerna av dessa miljöer en tidig leverans från projektet.
Utvecklingsmiljöer
Utvecklartestning fokuserar på konstruktionen av programvarukomponenter som levererar funktioner internt till applikationen eller på användar- eller presentationslagret.
Testerna styrs vanligtvis av kunskap om kodens interna struktur och behöver kanske inte använda eller kräva ”realistiska” data för att köras. Tester av komponenter eller tjänster på låg nivå körs vanligtvis via ett API med hjälp av specialbyggda eller proprietära drivrutiner eller verktyg.
Utbudet av utvecklingsverktyg, plattformar och så kallade integrerade utvecklingsmiljöer (IDE:er) är enormt. I den här artikeln kan vi bara beröra några av de viktigaste testrelaterade kraven och funktionerna hos miljöer.
För att stödja utvecklingen och den testning som ingår i utvecklarnas arbete måste miljöerna stödja följande aktiviteter. Detta är bara ett urval—det kan finnas ytterligare aktiviteter eller variationer av dessa aktiviteter i din situation:
- En ”sandlådemiljö” för att experimentera med ny programvara. Sandlådor används ofta för att testa nya bibliotek, utveckla prototypkod som ska kastas bort eller öva på programmeringstekniker. Alla vanliga programmeringsspråk har hundratals eller tusentals programvarubibliotek. Sandlådor används för att installera och testa programvara som ännu inte ingår i den huvudsakliga utvecklingslinjen, för att utvärdera den och öva på att använda den. Dessa miljöer kan betraktas som förbrukningsbara miljöer.
- Lokal utvecklingsmiljö. Det är här utvecklare underhåller en lokal kopia av en delmängd av eller all källkod för sin applikation från ett delat kodförråd och kan skapa systembyggen för lokal testning. Denna miljö gör det möjligt för utvecklare att göra ändringar i koden i sin lokala kopia och testa ändringarna. Vissa tester är ad hoc och kanske aldrig upprepas. Andra tester är automatiserade. Automatiserade tester behålls vanligtvis permanent, särskilt om de följer ett testdrivet arbetssätt.
- Delad miljö för (kontinuerlig) integrering. När utvecklarna litar på att deras kod är klar skickar de sina ändringar till det delade, kontrollerade kodförrådet. CI-miljön utför automatiserade byggen och kör automatiserade tester med hjälp av kodförrådet. Vid denna tidpunkt är den nya eller ändrade koden integrerad och testad. CI-systemet kör automatiserade tester på begäran, varje timme eller dagligen, och hela teamet får aviseringar och kan se teststatusen för det senaste integrerade bygget. Fel upptäcks snabbt och hanteras som en brådskande fråga.
En utvecklings- eller CI-miljö stöder utvecklartester, men andra applikationsservrar, webbtjänster, meddelandetjänster eller databasservrar som kompletterar systemet kanske inte är tillgängliga.
Om dessa gränssnittssystem inte finns eftersom de ännu inte har byggts, eller eftersom de tillhör ett partnerföretag och det endast finns ett produktionssystem utan någon testversion, måste utvecklarna skapa stubbar eller mockar för dessa gränssnitt för att åtminstone kunna testa sin egen kod.
Verktyg för mocking kan vara avancerade, men mockade gränssnitt kan vanligtvis inte stödja tester som kräver integrerade data från flera system.
Om ett gränssnitt till en testdatabasserver är tillgängligt för utvecklarna kan deras testdata vara minimal, icke-integrerad eller inkonsekvent och inte representativ för produktionsdata.
Utvecklingsdatabaser som delas av ett team är vanligtvis otillfredsställande. Om det inte finns en bra hantering av denna delade resurs kan utvecklare återanvända, korrumpera eller radera varandras data.
Testmiljöer på systemnivå
Testning på systemnivå fokuserar på integreringen av komponenter och delsystem i samverkan.
Dessa miljöer tillhandahåller en plattform som stöder målen för storskaligare integration, funktionsvalidering och systemdrift inom ramen för användar- eller affärsprocesser.
Miljöer kan också vara dedikerade till systemets icke-funktionella aspekter, såsom prestanda, säkerhet eller tjänstehantering.
En av de vanligaste fallgroparna vid testning är att en systemtestare i sin miljö stöter på någon form av fel, men oavsett hur mycket utvecklaren eller testaren försöker kan felet inte återskapas i utvecklingsmiljön.
”Det fungerar på min dator!”
”Ja, självklart gör det det.”
Detta orsakas nästan säkert av bristande överensstämmelse mellan de två miljöerna. Skillnaden i beteende kan bero på konfigurationen, skillnader i programvaruversioner eller skillnader i databasinnehållet.
Skillnader i data som orsakar problem är det första som bör kontrolleras. De är vanligtvis lätta att identifiera och kan ofta lösas snabbt.
När det finns en skillnad i programvaruversion eller konfiguration kan testare och utvecklare slösa mycket tid på att spåra orsaken till skillnaden i beteende.
När dessa problem uppstår innebär det ofta att kommunikationen mellan utvecklaren och testningen brister. Det kan också tyda på att kontrollen över konfigurationen har gått förlorad i utvecklings- eller testmiljöns uppsättning eller i distributionsprocessen.
Infrastruktur som kod och automatiserad etablering av miljöer kommer att göra problem med miljöernas överensstämmelse till ett minne blott.
Typer av dedikerade testmiljöer
För att stödja systemtestning, acceptanstestning och icke-funktionell testning måste miljöerna stödja följande aktiviteter (det kan finnas fler i din organisation):
- (Funktionell) Systemtestmiljö. I den här miljön valideras systemet mot de krav som dokumenterats för systemet som helhet. Kraven kan bestå av stora textdokument med tabellerade testfall som definierats för ett systemtest. I agila projekt kan den här miljön behövas för att testare ska kunna utforska det integrerade systemet utan att begränsa sig till specifika funktioner.
- Ändpunkt-till-ändpunkt-test-miljö. Där CI-miljön gör det möjligt att integrera komponenter med delsystem kan affärsprocesserna kräva att andra gränssnittssystem (som inte kontrolleras av utvecklarna) är tillgängliga. Miljöer med full omfattning krävs för att genomföra storskalig integration, affärsprocesser eller övergripande acceptanstester. Vanligtvis är data en kopia av produktionsdata, eller åtminstone av lämplig omfattning. När storskalig integration behöver verifieras testas data- och styrflödena med längre användarresor och oberoende avstämningar av data mellan integrerade system. Hantering av data i testmiljöer är avgörande. Om du redan använder Jira kan du överväga att förbättra dina funktioner för datahantering med avancerade testhanteringsverktyg utformade för Jira.
- Prestandamiljö. Dessa miljöer måste tillhandahålla en meningsfull plattform för att utvärdera prestandan hos ett system (eller utvalda delsystem). Kompromisser i arkitekturen kan vara möjliga där det finns redundans eller kloning av servrar. Datavolymerna måste dock motsvara produktionsskalan även om datan är syntetisk. Miljön måste naturligtvis ha tillräcklig omfattning för att stödja transaktionsvolymer i produktion och därmed möjliggöra användbara förutsägelser av systemens prestanda i produktion.
- Miljöer för tillgänglighet, motståndskraft och hanterbarhet (ARM). I vissa avseenden liknar dessa miljöer prestandamiljöerna, men variationer kan vara oundvikliga beroende på testmålet. Tillgänglighetstestning syftar till att verifiera att systemet kan fungera under längre perioder utan att drabbas av fel. Motståndskraftstestning (ofta kallad redundanstestning) kontrollerar att systemkomponentfel inte orsakar en oacceptabel störning av den levererade tjänsten. Hanterbarhets- eller driftstestning syftar till att visa att systemets administrativa rutiner samt rutiner för hantering, säkerhetskopiering och återställning fungerar effektivt.
Datamiljöer
I vissa mycket stora projekt kan det finnas så många som 20 eller till och med 30 storskaliga miljöer som är avsedda för olika delar av testning, utbildning, datamigrering och provövergångar. I mindre projekt finns färre miljöer, kanske bara en gemensam miljö eller en kontinuerlig leveransprocess – och all testning kan implementeras automatiskt i miljöer som skapas för engångsbruk och sedan avvecklas.
Alla miljöer behöver data, men datans omfattning och grad av realism kan variera. Här är några vanliga mönster för hur testdata hämtas och hanteras. Dessa mönster fokuserar på ägarskap (lokalt eller gemensamt), skapandemetod (manuellt, automatiserat eller kopierat från produktion) och omfattning:
- Lokalt, manuellt skapad data i liten skala – lämplig för ad hoc-testning av utvecklare eller testare.
- Lokal, automatiserad, syntetisk data. Lämplig för automatiserade utvecklartester eller miljöer där funktionaliteten hos specifika moduler eller funktioner kan täckas.
- Gemensamt använd, manuellt skapad data. Används i integrations- och systemtestmiljöer, ofta där testdata har utvecklats parallellt med manuellt körda tester. Säkerhetskopieras och återställs vid behov.
- Gemensamt använd, automatiskt skapad data. Används i integrations- och systemtestmiljöer där testdata har utvecklats parallellt med automatiserade eller manuellt körda tester. Genereras och/eller återställs från säkerhetskopior vid behov.
- Gemensamt använd syntetisk/slumpmässig data i stor skala. Prestanda- och ARM-tester kräver sammanhängande data i stora volymer. Denna data behöver vanligtvis inte vara meningsfull – slumpmässiga data fungerar bra och genereras vid behov, eller genereras initialt och återställs från säkerhetskopior.
- Gemensamt använd meningsfull data i stor skala. Ändpunkt-till-ändpunkt-tester, acceptanstester eller användartester behöver vanligtvis meningsfull data i stor skala. Ibland används kopior eller utdrag från produktionsdata. Se dock till att du inte bryter mot dataskyddsregler om du inte förvränger eller anonymiserar datan.
- Omtestning och regressionstestning. Du behöver en känd, kontrollerad datamängd i ett känt tillstånd, så den återställs vanligtvis från säkerhetskopior. Detta gäller alla ovanstående miljöer, eftersom dessa tester måste köras om med data i ett känt tillstånd för att fel på ett tillförlitligt sätt ska kunna återskapas.
Infrastrukturtestning
I början av den här artikeln tittade vi på vad infrastrukturen omfattar, och sedan dess har vi främst fokuserat på de tekniska komponenterna, nämligen programvarusystemen, och förutsatt att hårdvaran – fysisk eller virtuell – är tillgänglig.
När vi bygger system från början förutsätter vi att infrastrukturen finns och att den fungerar korrekt, har god prestanda, är säker och motståndskraftig osv.
Vi kan testa alla dessa aspekter när vi har integrerat vår applikation, och utan tvekan upptäcka brister i infrastrukturen i ett relativt sent skede av våra projekt. Men att upptäcka infrastrukturproblem så sent i ett projekt är vanligtvis extremt störande.
- Ändringar för att åtgärda fel i infrastrukturen kan kräva betydande omkonstruktion och ändringar i vår applikation.
- Resultat från vår applikationstestning eller testning av hela systemet måste upprepas.
- Om tredjepartskomponenter som databas-, webb-, nätverks- eller meddelandetjänster slutar fungera är vi utlämnade åt leverantörerna (eller öppen källkod-gemenskapen) som stöder dem.
För att säkerställa att vårt förtroende för infrastrukturkomponenterna är välgrundat kan vi förlita oss på våra egna eller andras erfarenheter av att använda dem tidigare. Eller så måste vi bedöma deras tillförlitlighet genom testning innan vi bestämmer oss för att använda dem i utformningen och konstruktionen av vårt system.
Beroende på vilken infrastruktur som undersöks kan miljön vi använder variera – från en enskild server till en nästan komplett infrastrukturplattform.
Även om vissa tester kommer att utföras manuellt kommer vi huvudsakligen att använda verktyg, drivrutiner eller robotar för att simulera den transaktionsbelastning som vår applikation skulle generera. Vi behöver skapa mockar eller stubbar för dessa gränssnitt:
- Gränssnitt som för närvarande inte är tillgängliga
- Gränssnitt till komponenter som vi litar på och som är enkla att simulera
- Gränssnitt som inte ingår i omfattningen och som inte påverkar infrastrukturen som testas.
Infrastruktur fungerar, som sagt, vanligtvis inte genom ett användar- eller grafiskt gränssnitt.
Integreringen av vår applikation med infrastrukturen kommer huvudsakligen att ske i form av meddelanden eller anrop till fjärrtjänster. Ofta kräver den trafik som ska simuleras API-anrop till webb- eller applikationsservrar, meddelande- eller databasservrar, eller tjänster som tillhandahålls via molnet eller på avlägsna platser.
Prestanda- och ARM-mål kan vara kända, och då kan tester utföras för att säkerställa att dessa mål uppfylls.
Infrastruktur delas dock ofta med andra applikationer än vår egen, så kunskap om dess maximala kapacitet hjälper oss att bedöma hur mycket kapacitet som kommer att återstå när vår applikation distribueras.
I detta fall hanterar infrastrukturtestningen risken för vår egen och kanske även andra applikationer som i framtiden ska baseras på den.
Prenumerera på nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kursen Ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER och få $60 rabatt på hela kurspriset!
Rekommenderad läsning: 10 BÄSTA TESTHANTERINGSVERKTYGEN MED ÖPPEN KÄLLKOD
