Teststrategi för molnmigrering: faser, testtyper och checklista
En teststrategi för molnmigrering anger vad ni testar före, under och efter varje migreringsvåg, samt de kriterier för godkänt eller underkänt som avgör om en arbetsbelastning går live. Den omfattar funktion, dataintegritet, prestanda, säkerhet och återgång. Metoden: mät en baslinje på den gamla plattformen, kör en testmigrering, jämför och gör bara omläggningen när siffrorna stämmer.
Viktiga slutsatser
- Fånga baslinjer innan ni flyttar något: svarstider, felfrekvens, körtider för batchjobb och radantal.
- Kom överens om kriterier för godkänt eller underkänt och utlösare för återgång före den första vågen, inte under omläggningen.
- Använd migreringsverktygens egna testfunktioner: testmigreringar i Azure Migrate och datavalidering i AWS DMS finns för just detta.
- Testtyperna skalar med migreringsvägen. En lift-and-shift behöver främst paritetskontroller, medan en refaktorering behöver fullständiga funktions- och integrationstester.
- Kör testmigreringar i ett isolerat nätverk. Microsoft avråder från testmigreringar till ett virtuellt produktionsnätverk.
- Fortsätt testa efter omläggningen: följ servicenivåindikatorer (SLI) under minst en hel affärscykel.
Vad är testning vid molnmigrering?
Testning vid molnmigrering är de kontroller som visar att en applikation, dess data och dess infrastruktur fungerar minst lika bra efter flytten som före den. Den pågår genom hela migreringen, inte bara i slutet.
Den skiljer sig från vanlig releasetestning på tre sätt:
- Plattformen ändras, inte koden. Vid en lift-and-shift är koden densamma, så ni testar miljön: nätverk, identitet, lagringsprestanda, DNS och tidszoner.
- Data flyttas. Ni måste visa att varje rad och fil kom fram oförändrad, och att pågående ändringar fortsatte synkas fram till omläggningen.
- Molnet beter sig annorlunda. Autoskalning, gränser i hanterade tjänster, regional latens och delad infrastruktur kan förändra prestandan även när inget annat har ändrats.
Framgångskriterierna är desamma som i den egna miljön: funktionerna ska fungera, data ska vara kompletta och korrekta, och användarna ska inte märka någon nedgång i hastighet.
De fyra faserna i en teststrategi för migrering
Dela upp testningen i fyra faser, var och en med eget underlag och egen godkännandeprocess.
| Fas | Mål | Huvudkontroller | Underlag |
|---|---|---|---|
| 1. Planering och baslinje | Veta hur "bra" ser ut i dag | Beroendekarta, kritiska användarflöden, nuvarande svarstider, batchtider, datavolymer | Baslinjerapport, överenskomna kriterier för godkänt eller underkänt |
| 2. Testmigrering | Visa att arbetsbelastningen körs på målplattformen | Start och uppkoppling, funktionella rökprov, integrationer, datavalidering, prestanda under last | Testresultat per arbetsbelastning, fellista |
| 3. Omläggning | Byta säkert, med en väg tillbaka | Slutlig datasynk och validering, kontroll av DNS och certifikat, rökprov, go/no-go | Körbok för omläggningen med tider, undertecknat go/no-go |
| 4. Efter migreringen | Bekräfta stabilitet och finjustera | SLI-övervakning, acceptanstest, test av backup och återställning, kostnadskontroll | Hypercare-rapport, avslutade fel |
Fas 1: planering och baslinje
Börja med en inventering av applikationer, databaser, gränssnitt och schemalagda jobb, och rangordna dem efter affärsrisk. Notera för varje arbetsbelastning de siffror ni ska jämföra med senare: p95-svarstid för viktiga transaktioner, felfrekvens, varaktighet för nattliga batchjobb, databasstorlek och radantal.
Gör om dem till kriterier. Till exempel: "p95 för ordersökning inom 10 % av baslinjen", "noll avvikande rader i ekonomitabellerna", "nattbatchen är klar före 06.00". Googles SRE-bok definierar en SLI som "a carefully defined quantitative measure of some aspect of the level of service" och ett SLO som ett målvärde för den (Google SRE book). Om ni formulerar kriterierna så blir beslutet om go eller no-go objektivt.
Fas 2: testmigrering
Migrera en kopia av arbetsbelastningen till målplattformen och testa den där medan källan fortsätter köra. Båda de stora plattformarna stöder detta:
- Azure Migrate erbjuder en testmigrering som startar replikerade virtuella maskiner i ett virtuellt nätverk som ni väljer. Microsofts vägledning säger att det inte rekommenderas att testmigrera till ett virtuellt produktionsnätverk, eftersom öppna anslutningar till den egna miljön kan ge dubbla virtuella maskiner eller DNS-ändringar.
- AWS Application Migration Service (MGN) startar testinstanser från kontinuerligt replikerade servrar, och replikeringen fortsätter efter testet. AWS kallar det en bästa praxis att testa minst två veckor före den planerade omläggningen, så att det finns tid att rätta det ni hittar.
Använd fasen för att hitta överraskningarna: hårdkodade IP-adresser, saknade brandväggsregler, licenskontroller knutna till hårdvara och jobb som anropar servrar ni glömde migrera.
Fas 3: omläggning
Omläggningen är en inövad körbok, inte improvisation. Frys ändringar, kör den sista datasynkroniseringen, validera data, byt DNS eller mål för lastbalanseraren och kör rökprov. Varje steg har en ansvarig, en planerad tid och en återgångsåtgärd.
Definiera utlösare för återgång i förväg, till exempel: "om rökproven misslyckas eller datavalideringen visar avvikelser 60 minuter efter bytet, återställ DNS till källan". Öva återgången minst en gång under testmigreringarna.
Fas 4: validering efter migreringen
Efter driftsättningen jämför ni SLI:erna med baslinjen under minst en hel affärscykel, om möjligt inklusive månadsskifte eller toppdagar. Kör acceptanstest med användare, testa en återställning från de nya backuperna och kontrollera den första molnfakturan mot uppskattningen. Först därefter avvecklar ni källan.
Vilka testtyper bör ni köra?
Anpassa testtyperna efter risken i varje arbetsbelastning. Alla applikationer behöver inte alla tester.
| Testtyp | Vad den visar | Typiska verktyg |
|---|---|---|
| Funktions- och regressionstest | Funktioner och användarflöden fungerar fortfarande | Selenium, Playwright, befintliga testsviter |
| Integration | API:er, meddelandeköer, filöverföringar och tredjepartstjänster ansluter | Kontraktstester, API-testverktyg, syntetiska transaktioner |
| Datavalidering | Varje rad och fil kom fram och stämmer | AWS DMS data validation, kontrollsummor, radantal, verktyg för databasjämförelse |
| Prestanda och last | Svarstider och genomströmning når målen, autoskalningen fungerar | JMeter, k6, Gatling |
| Säkerhet och efterlevnad | Åtkomst, kryptering, nätverksregler och loggning är korrekta | Verktyg för säkerhetsläge i molnet, sårbarhetsskanningar, IAM-granskningar |
| Motståndskraft och DR | Arbetsbelastningen klarar fel och kan återställas | Failover-övningar, återställning av backuper, AWS Fault Injection Service |
| Acceptanstest | Verksamhetens användare bekräftar att systemet duger | Skriptade acceptanstest med godkännande |
För realistiska lasttester som motsvarar er topptrafik, se vår lasttestningstjänst.
Hur validerar ni data under en migrering?
Validera data på tre nivåer: antal, kontrollsummor och rad-för-rad-jämförelse för kritiska tabeller.
- Antal: rader per tabell, filer per bucket, totalt antal byte. Snabbt och fångar grova fel.
- Kontrollsummor och aggregat: summor av belopp, hashvärden för nyckelkolumner. Fångar avkortning och teckenkodningsproblem.
- Jämförelse på radnivå: för databaser jämför AWS DMS data validation varje källrad med motsvarande målrad och rapporterar avvikelser, inklusive ändringar som fångats under pågående replikering.
Två praktiska begränsningar i AWS-dokumentationen bör ni planera för: valideringen kräver en primärnyckel eller ett unikt index i varje tabell, och den ger extra frågelast på både källa och mål. Schemalägg tunga valideringskörningar utanför kontorstid, eller kör dem som separata uppgifter som bara validerar.
Testa också det som ändras avsiktligt. Om ni konverterar från Oracle till PostgreSQL skiljer sig datatyper, teckenordning (collation) och sorteringsordning, så jämför frågeresultat och inte bara lagrade värden. Vår databasmigreringstjänst tar upp dessa konverteringar.
Så förändras testningen med migreringsvägen
- Rehost (lift-and-shift): fokusera på paritet i miljön. Kontrollera nätverk, DNS, identitet, lagringens genomströmning, backupjobb och övervakningsagenter. Funktionstestningen kan vara ett rökprov plus de kritiska flödena.
- Replatform: när ni flyttar en databas till en hanterad tjänst eller en app till containrar, lägg till datavalidering, prestandatester och kontroller av gränser i den hanterade tjänsten, som antal anslutningar.
- Refaktorering: behandla det som ny programvara. Kör fullständig funktions-, integrations- och prestandatestning, och använd canary- eller blue/green-releaser med feature flags för att begränsa exponeringen.
Checklista för testning vid molnmigrering
- Inventering och beroendekarta klar för vågen
- Baslinjer registrerade för kritiska flöden, batchjobb och datavolymer
- Kriterier för godkänt eller underkänt och utlösare för återgång godkända av verksamhetsägaren
- Testmiljön isolerad från produktionsnätverk
- Infrastruktur definierad som kod så att test och produktion matchar (se vår tjänst för infrastruktur som kod med Terraform)
- Testdata maskerade där de innehåller personuppgifter
- Testmigrering genomförd, fel rättade och omtestade
- Datavalidering godkänd för alla tabeller i omfånget
- Lasttest vid förväntad topp godkänt
- Säkerhetsgranskning genomförd: IAM, kryptering, säkerhetsgrupper, loggning
- Återgång övad och tidtagen
- Körbok för omläggningen med ansvariga och tider godkänd
- Övervakningspaneler och larm för tiden efter migreringen i drift
- Återställning från backup testad på den nya plattformen
Så hjälper Opsio
Opsio planerar och driver molnmigreringar med testning inbyggd i varje våg. För SilverRail Technologies flyttade Opsio företagets nordiska gren till AWS och slog ihop den med den globala organisationen. Fasen Mobilize omfattade en pilotmigrering av utvalda arbetsbelastningar, och migreringsprocessen och AWS-tjänsterna justerades utifrån den testningen. Data flyttades med PostgreSQL:s egna verktyg enligt en detaljerad omläggningsplan, och omläggningarna genomfördes inom snäva servicefönster för att begränsa påverkan på kunderna. Läs kundcaset om SilverRail.
Vanliga frågor
Vad är en teststrategi för molnmigrering?
Det är en plan som anger vilka tester som körs före, under och efter varje migreringsvåg, kriterierna för godkänt eller underkänt för varje test och vem som godkänner. Den omfattar funktion, data, prestanda, säkerhet och återgång.
Vilka faser ingår i testning vid molnmigrering?
Planering och baslinje, testmigrering, omläggning och validering efter migreringen. Varje fas ger underlag, till exempel baslinjerapporter, testresultat, ett undertecknat go/no-go och en hypercare-rapport.
Hur testar man data efter en molnmigrering?
Jämför radantal och kontrollsummor för alla tabeller och kör jämförelser på radnivå för kritiska data. På AWS jämför DMS data validation käll- och målrader och rapporterar avvikelser. Den kräver en primärnyckel eller ett unikt index i varje tabell.
Hur skiljer sig testningen av en lift-and-shift från en refaktorering?
En lift-and-shift behöver främst paritetskontroller av miljön och de kritiska flödena, eftersom koden inte ändras. En refaktorering behöver fullständig funktions-, integrations- och prestandatestning, eftersom ni i praktiken släpper ny programvara.
Hur länge bör man övervaka efter omläggningen?
Under minst en hel affärscykel, inklusive toppdagar som månadsskifte, innan ni avvecklar källsystemen. Håll återgångsmöjligheten öppen tills de överenskomna kriterierna uppfylls.
Om författaren
Redaktionella riktlinjer: Artikeln är skriven av en certifierad praktiker, som anges i bylinen ovan. Vi uppdaterar den när tekniken eller regelverket den handlar om förändras; datumen ovan visar den senaste uppdateringen. Opsio är redaktionellt oberoende — vi rekommenderar lösningar utifrån tekniska meriter, inte kommersiella relationer.