Testa programmet och Azure-miljön
Testning är en av de grundläggande komponenterna och DevOps och flexibel utveckling i allmänhet. Om automatisering ger DevOps den hastighet och flexibilitet som krävs för att distribuera programvara snabbt, kommer endast genom omfattande testning av dessa distributioner att uppnå den tillförlitlighet som kunderna kräver.
En viktig grundsats i en DevOps-metod för att uppnå systemtillförlitlighet är principen "Skift vänster". Om utveckling och distribution av ett program är en process som beskrivs som en serie steg från vänster till höger bör testningen inte begränsas till att utföras i slutet av processen (till höger). Det bör flyttas så mycket till början (till vänster) som möjligt. Fel är billigare att reparera när de fångas tidigt. De kan vara dyra eller omöjliga att åtgärda senare i programmets livscykel.
En annan aspekt att tänka på är att testning bör ske på all kod. (inte bara programkod utan även infrastrukturmallar och konfigurationsskript) Enligt beskrivningen i Infrastruktur som kod bör miljön där program körs vara versionskontrollerad och distribuerad via samma mekanismer som programkod, och därför kan testas och verifieras med samma testparadigm som teamen redan använder för programkod.
Det finns en rad olika testverktyg för att automatisera och effektivisera olika typer av testning, inklusive Azure Load Testing, Azure Pipelines för automatiserad testning och Azure-testplaner för manuell testning.
Det finns flera steg där tester kan utföras i kodens livscykel och var och en av dem har vissa särskilda funktioner som är viktiga att förstå. I den här guiden hittar du en sammanfattning av de olika tester som du bör överväga när du utvecklar och distribuerar program.
Automatiserad testning
Automatisera tester är det bästa sättet att se till att de körs konsekvent. Beroende på hur ofta tester utförs är de vanligtvis begränsade i varaktighet och omfattning, vilket de olika typerna av automatiserade tester visar:
Enhetstestning
Enhetstester är tester som vanligtvis körs som en del av rutinen för kontinuerlig integrering. Enhetstester bör vara omfattande (helst täcka 100 % av koden) och snabbt (körs på under 30 sekunder, även om det här talet är en riktlinje).
Enhetstestning kan verifiera att syntaxen och funktionerna i enskilda kodmoduler fungerar som de ska. (till exempel: skapa en definierad utdata för kända indata) Enhetstester kan också användas för att verifiera att infrastrukturen som kodtillgångar är giltig.
Enhetstester bör tillämpas både på alla kodtillgångar. (inklusive mallar och skript)
Röktestning
Röktester kontrollerar att en arbetsbelastning kan ställas upp i en testmiljö och fungerar som förväntat. De går inte till integreringstesternas omfattning eftersom de inte verifierar samverkan mellan olika komponenter.
I stället verifierar de att distributionsmetoden för både infrastrukturen och programmet fungerar och att systemet svarar som avsett när processen är klar.
Integrationstestning
När du har kontrollerat att de olika programkomponenterna fungerar korrekt individuellt har integreringstestningen som mål att avgöra om de kan interagera med varandra som de ska.
Det kan ta lång tid att köra en stor integreringstestsvit, vilket är anledningen till att tester bör flyttas åt vänster så mycket som möjligt, med integreringstester som reserveras för scenarier som inte kan testas med rök- eller enhetstest.
Tidskrävande testprocesser kan köras med jämna mellanrum om det behövs. Detta ger en bra kompromiss och identifierar samverkansproblem mellan programkomponenter senast en dag efter att de introducerades.
Manuell testning
Manuell testning är mycket dyrare än automatiserad testning, och därför körs den vanligtvis mycket mindre ofta. Manuell testning är dock grundläggande för att DevOps-feedbackloopen ska fungera korrekt, för att korrigera fel innan de blir för dyra att reparera eller göra kunderna missnöjda.
Acceptanstestning
Beroende på kontextgodkännandetestningen utförs ibland manuellt. I vissa fall är den delvis eller helt automatiserad. Dess syfte är att avgöra om programvarusystemet har uppfyllt kravspecifikationerna eller inte.
Huvudsyftet med det här testet är att utvärdera systemets efterlevnad av affärskraven och kontrollera om det uppfyller de nödvändiga kriterierna för leverans till slutanvändare.
Verktyg som Application Insights User Behavior Analytics kan hjälpa dig att räkna ut hur personer använder ditt program. På så sätt kan du bestämma om en ny funktion har förbättrat dina program utan att medföra oavsiktliga negativa effekter.
Nästa avsnitt i den här artikeln beskriver metoder för "Testning i produktion", som kan användas för att kontrollera om funktioner har uppfyllt affärsmål med verkligt användarbeteende.
Testning och experimentering i produktion
Beroende på din valda distributionsstrategi kan azure-plattformsfunktioner hjälpa dig att utföra experiment i produktion.
Azure AppService levereras till exempel med platsfunktioner som gör att du kan ha två olika versioner av samma program som körs samtidigt. Platser tillåter A/B-testning genom att dirigera en del av användartrafiken till en version av programmet och resten av trafiken till en annan.
Det finns flera populära metoder för experimentering i produktion:
- Blå/gröna distributioner När du distribuerar en ny programversion kan du distribuera den parallellt med den befintliga. På så sätt kan du börja omdirigera klienter till den nya versionen, och om allt går bra kan du inaktivera den gamla versionen. Om det uppstår problem med den nya distributionen kan du alltid omdirigera användarna tillbaka till distributionen med den tidigare versionen.
- Canary-versioner Du kan exponera nya funktioner i ditt program på ett förskjutet sätt för att välja grupper av användare. Om användarna är nöjda med de nya funktionerna, eller om den nya funktionen fungerar som förväntat med kontrollgruppen, kan du utöka funktionen till en större grupp användare tills den har distribuerats helt.
- A/B-testning: A/B-testning liknar kanarietestning, men även om kanarieversioner fokuserar på att minska risken fokuserar A/B-testningen på att utvärdera två versioner av ett program eller en funktion sida vid sida. Om du till exempel har två versioner av layouten för ett visst område i ditt program kan du skicka hälften av dina användare till en, den andra hälften till den andra, och använda vissa mått för att se vilken layout som är mer framgångsrik i samband med dina affärsmål.
Stresstestning
Som vi redan nämnt i andra avsnitt inom detta ramverk är det ytterst viktigt att utforma programkoden och infrastrukturen för skalbarhet. Stresstester hjälper dig att regelbundet verifiera att både ditt program och din miljö anpassas efter föränderliga belastningsförhållanden.
Under dessa stresstester är det viktigt att övervaka alla komponenter i systemet för att identifiera om du stöter på flaskhalsar, men också för att upprätta en tydlig baslinje att testa mot.
Varje komponent i systemet som inte kan skalas ut kan omvandlas till en skalningsbegränsning, till exempel aktiva/passiva nätverkskomponenter eller databaser. Det är därför viktigt att känna till deras gränser så att du kan minska deras inverkan när det gäller programskala.
En annan viktig del av stresstesterna är att verifiera att infrastrukturen skalas ned till sitt normala skick som förväntat för att hålla kostnaderna under kontroll.
Testning av affärskontinuitet
Programåterställningstest
Programåterställningstest är viktiga för att verifiera att den befintliga säkerhetskopieringsstrategin kompletteras av en fungerande återställningsprocedur. Dessa bör utföras regelbundet.
Verktyg som Azure Site Recovery göra det möjligt att starta en isolerad kopia av den primära arbetsbelastningsplatsen i en sekundär miljö, så att den kan verifieras att arbetsbelastningen har återställts som den ska i en nödsituation.
Om ett problem uppstår under detaljnivån kan haveriberedskapsproceduren optimeras och infrastrukturen i den sekundära miljön kan tas bort på ett säkert sätt.
Undersökande testning
Under undersökande testning utforskar experter programmet i sin helhet och försöker hitta fel eller icke-optimala implementeringar av funktioner. Dessa experter kan vara utvecklare, UX-specialister, produktägare, faktiska användare och andra profiler.
Strukturerade testplaner används vanligtvis inte, eftersom testningen lämnas till den enskilda testarens förmåga.
Felaktig inmatning
Felinmatningstester om programmet är motståndskraftigt mot infrastrukturfel. Tekniken introducerar fel i den underliggande infrastrukturen och observerar hur programmet beter sig.
Den här typen av testning är grundläggande för att skapa förtroende för dina redundansmekanismer. Att stänga av infrastrukturkomponenter, avsiktligt försämra prestanda eller införa fel är ett sätt att verifiera att programmet kommer att reagera som förväntat när dessa situationer inträffar.
Produkter som Azure Chaos Studio syftar till att förenkla processen för felinmatningstestning. Många större organisationer har skapat egna kaosmotorer som använder automatiserade testverktyg för att uppnå felinmatning.
Sammanfattning
För att kunna distribuera programvara snabbt och tillförlitligt är testning en grundläggande komponent i livscykeln för utveckling och distribution. Det är viktigt att se till att programmet fungerar som förväntat i varje situation. Därför behöver vi inte bara testa programkoden utan alla aspekter av vår arbetsbelastning.