Hva er gjenopprettingstesting? med eksempel

Hva er gjenopprettingstesting?

Gjenopprettingstesting er en programvaretestingsteknikk som verifiserer programvarens evne til å gjenopprette etter feil som programvare- eller maskinvarekrasj og nettverksfeil. Formålet med gjenopprettingstesting er å avgjøre om programvaredriften kan fortsette etter en katastrofe eller et integritetstap. Gjenopprettingstesting innebærer å tilbakestille programvaren til det punktet der integriteten var kjent, og behandle transaksjoner på nytt frem til feilpunktet.

Innen programvareutvikling er gjenopprettingstesting en type ikke-funksjonell testing — den dekker aspekter som ikke er knyttet til en spesifikk funksjon eller brukerhandling, som skalerbarhet eller sikkerhet. Den utføres av profesjonelle testere, og tilstrekkelige sikkerhetskopier av data oppbevares på sikre steder på forhånd.

Eksempel på gjenopprettingstesting

To scenarioer viser teknikken på sitt enkleste. I hvert scenario tvinges en feil frem med vilje, og deretter overvåkes applikasjonen mens den gjenopptas.

• Nettverksavbrudd: Mens et program mottar data fra nettverket, kobler du fra tilkoblingskabelen. Etter en stund kobler du den til igjen og analyserer programmets evne til å fortsette å motta data fra det punktet der forbindelsen ble brutt.
• Gjenoppretting av økt: Start systemet på nytt mens en nettleser har et bestemt antall økter åpne, og sjekk om nettleseren gjenoppretter alle.

Illustrasjonen nedenfor viser den samme ideen i visuell form.

Tiden det tar å bli frisk avhenger av:

• Antall omstartspunkter
• Datamengden som lagres av applikasjonen
• Opplæring og ferdigheter hos personer som utfører tilfriskningsaktiviteter, og verktøyene som er tilgjengelige for tilfriskningsaktiviteter

Når det er flere feil, bør gjenopprettingstesting gjøres på en strukturert måte i stedet for alt på én gang – utført for ett segment og deretter et annet.

Livssyklus for gjenopprettingsprosessen

Før man utformer testtilfeller, er det nyttig å se hvor en gjenopprettingstest griper inn. Livssyklusen til gjenopprettingsprosessen har fem trinn:

1. Normal operasjon
2. Katastrofehendelse
3. Avbrudd og svikt i operasjonen
4. Katastrofeklarering gjennom gjenopprettingsprosessen
5. Rekonstruksjon av alle prosesser og informasjon, slik at hele systemet går tilbake til normal drift

Flytskjemaet nedenfor viser de fem trinnene i rekkefølge.

La oss diskutere disse fem trinnene i detalj:

1. Normal drift. Et system av maskinvare, programvare og fastvare, integrert for å oppnå et felles mål, utfører sin tiltenkte jobb uten avbrudd innen en fastsatt tidsperiode.
2. Katastrofeforekomst. En avbrudd kan oppstå på grunn av feil i programvaren, som for eksempel en feil initiert av inndata, et krasj forårsaket av maskinvarefeil eller skade fra brann, tyveri eller streik.
3. Forstyrrelse og fiasko. Dette er den mest smertefulle fasen, som fører til forretningstap, brutte relasjoner, tapte muligheter, tapte arbeidstimer og uten unntak økonomisk tap og tap av goodwill. En katastrofeberedskapsplan holder denne fasen minimal.
4. Katastroferydning. Hvis en reserveplan og risikoreduserende prosesser allerede er på plass, koster gjenoppretting mye mindre tid og krefter. Et utpekt team, der hver persons rolle er definert på forhånd, fastsetter ansvaret og forhindrer en lang periode med avbrudd.
5. Gjenoppbygging. Dette kan innebære flere operasjonsøkter for å gjenoppbygge alle mapper sammen med konfigurasjonsfiler. Riktig dokumentasjon og en definert gjenoppbyggingsprosess er nødvendig for korrekt gjenoppretting.

Restaureringsstrategi

Gjenopprettingsteamet bør ha sin egen strategi for å hente viktig kode og data for å få driften tilbake til normalen. Denne strategien er unik for hver organisasjon, basert på hvor kritiske systemene den håndterer er, og for kritiske systemer kommer det ned til et sett med valg:

1. Én enkelt sikkerhetskopi, eller mer enn én
2. Flere sikkerhetskopier på ett sted, eller på forskjellige steder
3. Online sikkerhetskopiering, eller offline sikkerhetskopiering
4. Sikkerhetskopier kjøres automatisk under en policy, eller utløses manuelt
5. Et uavhengig restaureringsteam, eller utviklingsteamet som utfører arbeidet

Hvert valg har en kostnadsfaktor, og flere sikkerhetskopier kan forbruke mer fysiske ressurser eller kreve et uavhengig team. Avhengighet er også viktig: bedrifter er eksponert gjennom koden og dataene de oppbevarer hos én enkelt leverandør, og en storskala AWS Strømbrudd har gjentatte ganger ført til at kjente forbrukertjenester er utilgjengelige samtidig. Uavhengig gjenopprettingskapasitet er avgjørende i slike tilfeller.

Hvordan gjøre gjenopprettingstesting

Strategien er avgjort, og det neste spørsmålet er hvordan selve testen settes opp. Følgende punkter bør vurderes når man utfører restitusjonstesting.

• Lag en testmiljø som er så likt de faktiske utrullingsforholdene som mulig: grensesnitt, protokoll, fastvare, maskinvare og programvare bør samsvare med produksjonen.
• Selv om uttømmende testing kan være tidkrevende og kostbart, bør en identisk konfigurasjon og en fullstendig kontroll fortsatt utføres.
• Hvis mulig, test på maskinvaren som til slutt skal gjenopprettes til – spesielt når du gjenoppretter til en annen maskin enn den som opprettet sikkerhetskopien.
• Noen sikkerhetskopieringssystemer forventer at harddisken har nøyaktig samme størrelse som den sikkerhetskopien ble tatt fra.
• Håndter foreldelse: diskteknologi utvikler seg raskt, og en gammel disk er kanskje ikke kompatibel med en ny. Gjenoppretting til en virtuell maskin hjelper, siden virtualiseringsprogramvare kan etterligne eksisterende maskinvare, inkludert diskstørrelser.
• Online sikkerhetskopieringssystemer er ikke et unntak fra testing. De fleste leverandører beskytter brukere mot medieproblemer gjennom feiltolerant lagring, slik at feil dukker opp sent.
• Selv om systemer for sikkerhetskopiering på nett er ekstremt pålitelige, må gjenopprettingssiden testes for å bekrefte at det ikke er problemer med henting, sikkerhet eller kryptering.

Fordi restitusjonsøvelsene utføres ende mot ende, er disse løpeturene vanligvis planlagt samtidig systemtesting heller enn på enhetsnivå.

Testprosedyre etter restaurering

Gjenoppretting av dataene er bare halve oppgaven; den gjenopprettede kopien må fortsatt bevises brukbar. De fleste store selskaper har uavhengige revisorer som regelmessig kjører gjenopprettingsøvelser. En omfattende katastrofegjenopprettingsplan er dyr å vedlikeholde og teste, så mindre organisasjoner er ofte avhengige av sikkerhetskopier og ekstern lagring i stedet.

Etter at mapper og filer er gjenopprettet, bekrefter følgende kontroller at de ble gjenopprettet på riktig måte:

• Gi nytt navn til den ødelagte dokumentmappen, slik at den gjenopprettede kopien ikke kan forveksles med den.
• Tell filene i de gjenopprettede mappene og sammenlign antallet med den opprinnelige mappen.
• Åpne noen filer med programmet som vanligvis bruker dem, og bekreft at dataene kan blas gjennom og oppdateres som vanlig.
• Åpne flere filer av forskjellige typer – bilder, MP3og dokumenter, noen store og noen små.
• Bruk verktøyene for sammenligning av filer og kataloger som de fleste operativsystemer gi.

Spørsmål og svar