Operational Acceptance Testing (OAT) Eksempel

Hvad er Operational accepttest?

Operational Acceptance Testing (OAT) er en softwaretestteknik, der evaluerer en softwareapplikations operationelle parathed, før den frigives til produktion. Målet med operationel accepttest er at sikre system- og komponentoverholdelse og problemfri systemdrift i henhold til standarden. Operamiljø (SOE).

Operanational accepttest kaldes også OperaORT (Organisation Readiness Testing) eller, kortere sagt, operationel testning. Alle tre navne beskriver den samme kontrol: softwaren gør måske allerede det, virksomheden bad om, men ingen har endnu bevist, at den kan installeres, sikkerhedskopieres, genstartes, overvåges og gendannes af de personer, der vil eje den efter lanceringen.

Denne sondring placerer OAT solidt blandt de ikke-funktionel testning typer. Den spørger, hvordan systemet opfører sig under reelle driftsforhold, snarere end om en funktion returnerer det korrekte svar.

Typer af Operational test

OperaNational testning er en paraplyaktivitet. Hvert punkt nedenfor er en separat kontrol med sine egne adgangsbetingelser og sin egen dokumentation, og en fuld OAT-cyklus berører normalt de fleste af dem.

• Installationstest — bekræfter, at buildet kan installeres, opgraderes og rulles tilbage i målmiljøet ved hjælp af den medfølgende dokumentation.
• Belastnings- og ydeevnetest Operation — kontrollerer, at systemet holder sin forventede gennemløbshastighed og svartider under produktionslignende volumen. Se test af ydeevne og belastningstest for de underliggende teknikker.
• Sikkerhedskopiering og gendannelsestest — beviser, at en sikkerhedskopi faktisk kan tages til tiden og gendannes til en fungerende tilstand, ikke blot skrives til disk.
• Sikkerhedstest — verificerer adgangskontroller, legitimationsoplysninger, certifikater og hærdning i driftsmiljøet. Se sikkerhedstest for den detaljerede metode.
• Code Analyse — en statisk gennemgang af den leverede kode og konfiguration for vedligeholdelse og kendte svaghedsmønstre, før det bliver en produktionsbyrde for nogen.
• Mislykket over test — tvinger en node, tjeneste eller et sted til at fejle og observerer, om standby-funktionen overtager inden for den aftalte tid.
• Gendannelsestest — måler hvor fuldstændigt og hvor hurtigt systemet vender tilbage til drift efter et nedbrud. Genopretningstest dækker teknikken i dybden.
• Ende til ende Testmiljø Operational test — betjener hele kæden af ​​servere, netværk, job og grænseflader som én driftsenhed.
• Operational dokumentation Review — kontrollerer, at runbooks, servicediagrammer, genstartsordrer og eskaleringsstier stemmer overens med det system, der faktisk blev bygget.

Diagrammet nedenfor grupperer disse kontroller omkring udgivelsen og viser operationel testning som den sidste gate, før applikationen går ind i sit live-miljø.

Hvorfor Operational test

OperaDer findes ational testning, fordi en udgivelse, der opfylder alle funktionelle krav, stadig kan være umulig at køre.

• Under OAT mødes softwarekonfigurationer og driftssupportkomponenter for første gang.
• Den tester implementeringen af ​​funktionelle eller strukturelle ændringer i en software eller tjeneste i et funktionelt eller ikke-funktionelt miljø.
• Denne test afgør, om en applikation kan implementeres på et netværk i henhold til ITIL-standarder (IT Infrastructure Library).
• Den fortæller, om en software vil fungere som den er designet til, uden at forstyrre forretningsprocessen.
• OAT fokuserer primært på disse aspekter af softwareproduktet:
  • Resiliency
  • Gendannelsesevne
  • Håndterbarhed og støttebarhed
  • Integrity

Hvem optræder Operationel testning og hvornår

Ejerskabet af OAT er forskelligt fra alle tidligere testniveauer, og den forskel forklarer de fleste af resultaterne. De personer, der kører det, er de personer, der bliver kaldt klokken tre om morgenen.

• Systemadministratorer og infrastrukturingeniører — udfør installation, failover og genstart sager mod målmiljøet.
• Operationer og supportteams — validere advarsler, tærskler, eskaleringsruter og de løsningsdokumenter, der henvises til i hver advarsel.
• Database- og backupadministratorer — tage og gendanne sikkerhedskopier, herunder gendannelse til et andet sted.
• Sikkerheds- og compliance-personale — bekræft hærdning, adgangskontrol og revisionslogning i det live-lignende miljø.
• Testledere — indsamle beviserne i beslutningspakken til go-live.

I livscyklus for softwaretest, operationel testning sidder helt til sidst. Systemtest beviser, at det samlede produkt fungerer, brugeraccepttest beviser, at virksomheden accepterer det, og OAT beviser derefter, at organisationen kan køre det. Da det kræver et produktionslignende miljø, planlægges OAT normalt, når releasekandidaten er frosset – enhver kodeændring efter dette punkt sender cyklussen tilbage til starten.

Eksempler på testcases til Operational test eller OAT

Følgende er en praktisk tjekliste til at udføre OAT. Hver linje er skrevet, så resultatet er et klart bestået eller ikke bestået resultat, hvilket er, hvad et live-board har brug for.

1. Backups taget på ét sted kan gendannes på det samme sted.
2. Backups taget på ét sted kan gendannes på det andet sted.
3. Implementering af nye funktioner i det aktive produktionsmiljø påvirker ikke integriteten af ​​de nuværende produktionstjenester negativt.
4. Implementeringsprocessen kan replikeres ved hjælp af gyldig dokumentation.
5. Hver komponent kan lukkes ned og startes inden for den aftalte tidsramme.
6. For advarsler skal alle kritiske advarsler sendes til TEC og henvise til det korrekte løsningsdokument.
7. Der er alarmer på plads, og de udstedes, hvis de aftalte tærskler overskrides.
8. Enhver dokumentation vedrørende genopretning, der er produceret eller ændret, herunder servicediagrammer, er gyldig. Denne skal afleveres til de relevante supportområder.
9. Enhver komponent, der er berørt af en fejl, viser den anbefalede genstartsrækkefølge, det tid, det tager at fuldføre, og de involverede afhængigheder.

En praktisk tilføjelse til listen er det negative tilfælde: bryd bevidst én afhængighed, og bekræft derefter, at alarmen udløses, runbooken findes, og den dokumenterede genstartsordre gendanner tjenesten. En tjekliste, der kun registrerer succeser, har slet ikke testet handlingen.

Operationel testning vs. brugeracceptanstestning

HAVRE og test af brugeraccept er begge acceptaktiviteter, og begge er sent ude, hvilket er grunden til, at de så ofte forveksles. De besvarer forskellige spørgsmål og godkendes af forskellige personer.

De to er komplementære snarere end alternativer. En udgivelse, der består UAT og ikke består OAT, er en udgivelse, der vil fungere korrekt helt frem til det første nedbrud.

Fordele og udfordringer ved Operational test

Teams, der anvender OAT, nævner normalt de samme fordele og møder de samme forhindringer.

Fordele

• Risikoen for afbrydelser falder, fordi gendannelses- og failover-stier udføres, før kunderne er afhængige af dem.
• Supportteams arver dokumentation, der er blevet bevist i forhold til det virkelige system i stedet for at være skrevet ud fra designet.
• Implementeringsoverraskelser dukker op i et kontrolleret vindue i stedet for i løbet af den givne aften.
• Compliance- og revisionsbeviser genereres som et biprodukt af tjeklisten.

Udfordringer

• Et produktionslignende miljø er dyrt, og en nedskaleret kopi skjuler præcis de fejl, som OAT er beregnet til at finde.
• Cyklussen konkurrerer om den samme kalenderplads som udgivelsen, så det er den første aktivitet, der afbrydes, når en dato udskydes.
• Destruktive tilfælde som f.eks. failover og restore kræver godkendelser og stille vinduer, der er svære at opnå.
• Resultaterne afhænger af det driftspersonale, der samtidig kører den aktuelle live-tjeneste.

Den sædvanlige afhjælpning er at starte i det små: automatiser backup-gendannelse og genstart først, da de gentager hver udgivelse og giver det klareste signal om bestået eller fejlet. Derfra kan tjeklisten vokse med hver cyklus, og enhver ændring af runbooks bliver en kandidat til regressionstest i den næste udgivelse.

Ofte Stillede Spørgsmål