Kas ir atkopšanas testēšana? ar piemēru

Satura rādītājs:

Anonim

Atkopšanas testēšana

Atkopšanas testēšana ir programmatūras testēšanas tehnika, kas pārbauda programmatūras spēju atgūties no kļūmēm, piemēram, programmatūras / aparatūras avārijām, tīkla kļūmēm utt. Atkopšanas testēšanas mērķis ir noteikt, vai programmatūras darbības var turpināt pēc katastrofas vai integritātes zaudēšanas. Atkopšanas pārbaude ietver programmatūras atgriešanu tajā vietā, kur bija zināma integritāte, un darījumu pārstrādi līdz kļūmes vietai.

Atkopšanas testēšanas piemērs

Kad lietojumprogramma saņem datus no tīkla, atvienojiet savienojuma kabeli.

  • Pēc kāda laika pievienojiet kabeli atpakaļ un analizējiet lietojumprogrammas spēju turpināt saņemt datus no vietas, kurā tika pārtraukts tīkla savienojums.
  • Restartējiet sistēmu, kamēr pārlūkprogrammā ir atvērts noteikts sesiju skaits, un pārbaudiet, vai pārlūkprogramma spēj tās visas atgūt vai nē

Programmatūras inženierijā atkopšanas testēšana ir nefunkcionālas testēšanas veids. (Nefunkcionāla pārbaude attiecas uz programmatūras aspektiem, kas, iespējams, nav saistīti ar noteiktu funkciju vai lietotāja darbību, piemēram, mērogojamību vai drošību.)

Atveseļošanās laiks ir atkarīgs no:

  • Restartēšanas punktu skaits
  • Pieteikumu apjoms
  • To cilvēku apmācība un prasmes, kuri veic atveseļošanās darbības, un atveseļošanai pieejamie rīki.

Ja ir vairākas kļūmes, atkopšanas pārbaude būtu jāveic strukturētā veidā, nevis rūpējoties par visām kļūmēm, kas nozīmē, ka atkopšanas pārbaudes jāveic vienam un pēc tam citam segmentam.

To veic profesionāli testētāji. Pirms atkopšanas pārbaudes drošā vietā tiek glabāti atbilstoši rezerves dati. Tas tiek darīts, lai nodrošinātu, ka operāciju var turpināt arī pēc katastrofas.

Atkopšanas procesa dzīves cikls

Atkopšanas procesa dzīves ciklu var iedalīt šādās piecās darbībās:

  1. Normāla darbība
  2. Katastrofas
  3. Operācijas traucējumi un neveiksmes
  4. Katastrofu likvidēšana, izmantojot atkopšanas procesu
  5. Visu procesu un informācijas rekonstrukcija, lai visa sistēma pārietu uz normālu darbību

Detalizēti apspriedīsim šīs 5 darbības

  1. Sistēma, kas sastāv no aparatūras, programmatūras un programmaparatūras, kas integrēta kopīga mērķa sasniegšanai, tiek darbināta, lai veiktu precīzi definētu un noteiktu mērķi. Sistēma ir aicināta veikt normālu darbību, lai projektēto darbu veiktu bez traucējumiem noteiktā laika periodā.

  2. Traucējumi var rasties programmatūras nepareizas darbības dēļ dažādu iemeslu dēļ, piemēram, ievades iniciētas darbības traucējumu dēļ, programmatūras avārijas dēļ aparatūras kļūmes dēļ, bojātas ugunsgrēka, zādzības un streika dēļ.

  3. Pārtraukšanas fāze ir vissāpīgākā fāze, kas noved pie uzņēmējdarbības zaudējumiem, attiecību pārtraukumiem, iespēju zaudējumiem, cilvēka stundas zaudējumiem un vienmēr finanšu un nemateriālās vērtības zaudējumiem. Katrai saprātīgai aģentūrai jābūt katastrofu seku novēršanas plānam, lai traucējumu fāze būtu minimāla.

  4. Ja rezerves plāns un riska mazināšanas procesi ir īstajā vietā, pirms sastopaties ar katastrofām un traucējumiem, atkopšanu var veikt bez daudz laika, pūļu un enerģijas zaudēšanas. Būtu jādefinē izraudzītā persona kopā ar savu komandu ar katras no šīm personām piešķirto lomu, lai noteiktu atbildību un palīdzētu organizācijai ietaupīt no ilgiem traucējumu periodiem.

  5. Rekonstrukcija var ietvert vairākas darbības sesijas, lai atjaunotu visas mapes kopā ar konfigurācijas failiem. Pareizai atkopšanai jābūt pienācīgai dokumentācijai un rekonstrukcijas procesam.

Atjaunošanas stratēģija

Atkopšanas komandai vajadzētu būt savai unikālajai stratēģijai svarīga koda un datu izgūšanai, lai aģentūras darbība atgrieztos normālā stāvoklī.

Stratēģija var būt unikāla katrai organizācijai, pamatojoties uz to sistēmu kritiskumu, ar kurām tās strādā.

Kritisko sistēmu iespējamo stratēģiju var vizualizēt šādi:

  1. Lai būtu viens dublējums vai vairāki
  2. Lai vienā vietā vai dažādās vietās būtu vairākas rezerves kopijas
  3. Lai būtu tiešsaistes dublējums vai bezsaistes dublējums
  4. Vai dublēšana var tikt veikta automātiski, pamatojoties uz politiku, vai tā ir manuāli?
  5. Darbam var izmantot neatkarīgu atjaunošanas komandu vai pašu izstrādes komandu

Katrai no šīm stratēģijām ir saistīts izmaksu faktors, un vairākiem resursiem, kas nepieciešami vairākām rezerves kopijām, var būt nepieciešams vairāk fizisko resursu vai var būt nepieciešama neatkarīga komanda.

Daudzi uzņēmumi var tikt ietekmēti to datu un kodu atkarības dēļ no attiecīgās izstrādātāju aģentūras. Piemēram, ja Amazon AWS pārtrauc 25 interneta slēgšanu. Šādos gadījumos izšķiroša nozīme ir neatkarīgai atjaunošanai.

Kā veikt atkopšanas testēšanu

Veicot atkopšanas testēšanu, jāņem vērā šādas lietas.

  • Mums ir jāizveido testa gulta pēc iespējas tuvāk faktiskajiem izvietošanas apstākļiem. Saskarnes, protokola, programmaparatūras, aparatūras un programmatūras izmaiņām jābūt pēc iespējas tuvākām faktiskajam stāvoklim, ja tas nav tāds pats.
  • Veicot pilnīgu pārbaudi, tas var būt laikietilpīgs, un jāveic dārga lieta, identiska konfigurācija un pilnīga pārbaude.
  • Ja iespējams, jāpārbauda aparatūra, kuru beidzot atjaunosim. Tas jo īpaši attiecas uz gadījumiem, kad mēs atjaunojam citu mašīnu, nevis to, kas izveidoja dublējumu.
  • Dažas dublēšanas sistēmas sagaida, ka cietais disks būs tieši tāda paša izmēra kā tas, no kura tika paņemts dublējums.
  • Novecošana būtu jāpārvalda, jo piedziņas tehnoloģija attīstās strauji, un vecā piedziņa var nebūt saderīga ar jauno. Viens no šīs problēmas risināšanas veidiem ir atjaunošana virtuālajā mašīnā. Virtualizācijas programmatūras pārdevēji, piemēram, VMware Inc., var konfigurēt virtuālās mašīnas, lai atdarinātu esošo aparatūru, ieskaitot diska izmērus un citas konfigurācijas.
  • Tiešsaistes dublēšanas sistēmas nav izņēmums testēšanai. Lielākā daļa tiešsaistes dublēšanas pakalpojumu sniedzēju pasargā mūs no tiešas multivides problēmu iedarbības ar to, kā viņi izmanto kļūdām izturīgas atmiņas sistēmas.
  • Lai gan tiešsaistes dublēšanas sistēmas ir ārkārtīgi uzticamas, mums jāpārbauda sistēmas atjaunošanas puse, lai pārliecinātos, ka nav problēmu ar izguves funkcionalitāti, drošību vai šifrēšanu.

Pārbaudes procedūra pēc atjaunošanas

Lielākajai daļai lielo korporāciju ir neatkarīgi auditori, kas periodiski veic atkopšanas pārbaudes vingrinājumus.

Visaptveroša katastrofu seku novēršanas plāna uzturēšanas un testēšanas izmaksas var būt ievērojamas, un mazākiem uzņēmumiem tas var būt pārmērīgi liels.

Mazāki riski var būt atkarīgi no viņu datu dublēšanas un ārpus vietas saglabāšanas plāniem, lai tos saglabātu katastrofas gadījumā.

Pēc mapju un failu atjaunošanas var veikt šādas pārbaudes, lai pārliecinātos, ka faili tiek pareizi atkopti:

  • Pārdēvējiet bojāto dokumentu mapi
  • Saskaitiet atjaunotajās mapēs esošos failus un saskaņojiet tos ar esošu mapi.
  • Atveriet dažus failus un pārliecinieties, ka tie ir pieejami. Noteikti atveriet tos ar lietojumprogrammu, kas tos parasti izmanto. Un pārliecinieties, ka varat pārlūkot datus, atjaunināt datus vai visu, ko parasti darāt.
  • Vislabāk ir atvērt vairākus dažāda veida failus, attēlus, mp3, dokumentus un dažus lielus un dažus mazus.
  • Lielākajai daļai operētājsistēmu ir utilītas, kuras varat izmantot failu un direktoriju salīdzināšanai.

Kopsavilkums:

Šajā apmācībā mēs esam iemācījušies dažādus atkopšanas testēšanas aspektus, kas palīdz saprast, vai sistēma vai programma pēc neveiksmes atbilst tās prasībām.

Šī raksta autore ir Šveta Prijadaršini