Operariikliku vastuvõtutesti (OAT) näide
Thomas Hamilton
⚡ Nutikas kokkuvõte
OperaStandardne vastuvõtutestimine hindab, kas versioon on oma standardkeskkonnas käivitamiseks valmis. Operatootmiskeskkonna kontrollimine, varukoopiate, taastamise, häirete, turvalisuse ja dokumentatsiooni kontrollimine enne süsteemi üleandmist tootmistoe meeskondadele.
Mis on Operariiklik vastuvõtutest?
Operariiklik vastuvõtutest (OAT) on tarkvara testimise tehnika, mis hindab tarkvararakenduse töövalmidust enne selle tootmisse avaldamist. Töövõime aktsepteerimistesti eesmärk on tagada süsteemi ja komponentide vastavus standarditele ning süsteemi sujuv toimimine. Operakeskkonnaalane nõustamine (SOE).
OperaRahvuslikku vastuvõtutestimist nimetatakse ka OperaRiiklik valmisoleku testimine (ORT) või lühemalt öeldes operatiivtestimine. Kõik kolm nime kirjeldavad sama kontrolli: tarkvara võib juba teha seda, mida ettevõte soovis, kuid keegi pole veel tõestanud, et seda saavad pärast kasutuselevõttu omanikud installida, varundada, taaskäivitada, jälgida ja taastada.
See eristamine asetab OATi kindlalt nende hulka mittefunktsionaalne testimine tüübid. See küsib, kuidas süsteem käitub reaalsetes töötingimustes, mitte seda, kas funktsioon tagastab õige vastuse.
Tüübid Operariiklik testimine
OperaRahvusvaheline testimine on üldtegevus. Iga allolev punkt on eraldi kontroll oma sisenemistingimuste ja tõendusmaterjaliga ning täielik OAT-tsükkel hõlmab tavaliselt enamikku neist.
- Paigaldamise testimine — kinnitab, et järku saab sihtkeskkonnas installida, uuendada ja tagasi pöörata, kasutades kaasasolevat dokumentatsiooni.
- Koormus- ja jõudluskatse Operamine — kontrollib, kas süsteem hoiab oma eeldatavat läbilaskevõimet ja reageerimisaegu tootmismahule sarnasel tasemel. Vaata jõudluse testimine ja koormuse testimine aluseks olevate tehnikate jaoks.
- Varundamise ja taastamise testimine — tõestab, et varukoopiat saab tegelikult ajakava järgi teha ja töökorras olekusse taastada, mitte ainult kettale kirjutada.
- Turvalisuse testimine — kontrollib juurdepääsukontrolle, volitusi, sertifikaate ja turvalisuse tugevdamist töökeskkonnas. Vt turvalisuse testimine detailse meetodi jaoks.
- Code Analüüs — tarnitud koodi ja konfiguratsiooni staatiline ülevaade hooldatavuse ja teadaolevate nõrkuste mustrite osas enne, kui see kellegi tootmiskoormuseks muutub.
- Testimine ebaõnnestus — sunnib sõlme, teenuse või saidi rikki minema ja jälgib, kas varurežiim võtab kokkulepitud aja jooksul üle.
- Taastamise testimine — mõõdab, kui täielikult ja kui kiiresti süsteem pärast krahhi tööle naaseb. Taastumistestid käsitleb tehnikat põhjalikult.
- Lõpp-lõpuni Testi keskkond Operariiklik testimine — teostab kogu serverite, võrkude, tööde ja liideste ahelat ühtse operatsiooniüksusena.
- Operariiklik dokumentatsioon Review — kontrollib, kas käitusraamatud, teenuseskeemid, taaskäivitamiskäsud ja eskalatsiooniteed vastavad tegelikult loodud süsteemile.
Allolev diagramm rühmitab need kontrollid väljalaske ümber, näidates toimimistestimist viimase väravana enne rakenduse sisenemist oma reaalajas keskkonda.
Miks Operariiklik testimine
OperaRahvusvaheline testimine eksisteerib seetõttu, et versiooni, mis vastab kõigile funktsionaalsetele nõuetele, võib ikkagi olla võimatu käivitada.
- OAT-i ajal saavad tarkvarakonfiguratsioonid ja operatiivse toe komponendid esmakordselt kokku.
- See testib tarkvara või teenuse funktsionaalsete või struktuuriliste muudatuste rakendamist funktsionaalses või mittefunktsionaalses keskkonnas.
- See testimine määrab kindlaks, kas rakendust saab võrgus juurutada vastavalt IT-infrastruktuuri teegi (ITIL) standarditele.
- See näitab, kas tarkvara töötab ettenähtud viisil, ilma äriprotsesse häirimata.
- OAT keskendub peamiselt tarkvaratoote järgmistele aspektidele:
- Vastupidavus
- Taastusvõime
- Juhitavus ja toetatavus
- Integrity
Kes esineb OperaRahvuslik testimine ja millal
OAT-i omandiõigus erineb igast varasemast testitasemest ja see erinevus seletab enamiku selle tulemustest. Seda haldavad inimesed on inimesed, kellele helistatakse kell kolm öösel.
- Süsteemiadministraatorid ja taristuinsenerid — teostada installimist, tõrkesiire ja taaskäivitada juhtumeid sihtkeskkonnas.
- Operaja tugimeeskonnad — valideerida hoiatused, läviväärtused, eskalatsiooniteed ja iga hoiatuse puhul viidatud lahendusdokumendid.
- Andmebaasi ja varundamise administraatorid — varukoopiate tegemine ja taastamine, sh taastamine teisele saidile.
- Turva- ja vastavustöötajad — kinnitada kaitse tugevdamist, juurdepääsukontrolli ja auditilogimist reaalajas toimuva keskkonnaga sarnases keskkonnas.
- Testijuhid — koguda tõendid kasutuselevõtu otsuste paketti.
aasta tarkvara testimise elutsükkel, operatiivsed testid toimuvad kõige lõpus. Süsteemi testimine tõestab, et kokkupandud toode töötab, kasutajate vastuvõtutestimine tõestab, et ettevõte selle aktsepteerib, ja seejärel OAT tõestab, et organisatsioon saab seda käivitada. Kuna see vajab tootmislaadset keskkonda, planeeritakse OAT tavaliselt siis, kui väljalaskekandidaat on külmutatud – iga koodimuudatus pärast seda punkti saadab tsükli tagasi algusesse.
Näidistesti juhtumid jaoks Operariiklik testimine või OAT
Järgnev on mugav kontroll-leht OAT tegemiseks. Iga rida on kirjutatud nii, et tulemuseks oleks lihtsalt „pass“ või „nots“, mis ongi käivitatava plaadi jaoks vajalik.
- Ühes kohas tehtud varukoopiaid saab taastada samasse kohta.
- Ühes kohas tehtud varukoopiaid saab taastada teises kohas.
- Uute funktsioonide rakendamine reaalajas tootmiskeskkonda ei mõjuta negatiivselt praeguste tootmisteenuste terviklikkust.
- Rakendusprotsessi saab korrata kehtiva dokumentatsiooni abil.
- Iga komponenti saab kokkulepitud aja jooksul edukalt seisata ja käivitada.
- Kriitiliste hoiatuste puhul tuleb kõik need saata TEC-ile ja viidata õigele lahendusdokumendile.
- Hoiatused on olemas ja neid väljastatakse, kui kokkulepitud künnised ületatakse.
- Kõik koostatud või muudetud taastamisdokumendid, sh hooldusskeemid, on kehtivad. Need tuleks üle anda vastavatele tugiüksustele.
- Iga rikkest mõjutatud komponendi puhul kuvatakse soovitatav taaskäivitamise järjekord, lõpuleviimise aeg ja kaasatud sõltuvused.
Praktiline täiendus nimekirjale on negatiivne juhtum: katkesta teadlikult üks sõltuvus ja seejärel veendu, et hoiatus käivitub, käitusraamat leitakse ja dokumenteeritud taaskäivituskäsk taastab teenuse. Kontrollnimekiri, mis salvestab ainult õnnestumisi, pole toimingut üldse testinud.
OperaRahvusvaheline testimine vs kasutaja aktsepteerimistestimine
KAERA ja kasutaja aktsepteerimise testimine on mõlemad aktsepteerimistegevused ja mõlemad hilinevad, mistõttu neid nii tihti segamini aetakse. Nad vastavad erinevatele küsimustele ja neile kirjutavad alla erinevad inimesed.
| Aspekt | Operariiklik vastuvõtutest (OAT) | Kasutaja aktsepteerimise testimine (UAT) |
| Küsimusele vastati | Kas organisatsioon saab seda süsteemi hallata ja toetada? | Kas süsteem vastab kokkulepitud ärivajadustele? |
| Esitab | Operaasutused, infrastruktuur ja tugipersonal | Lõppkasutajad, äripartnerid ja kliendid |
| Nõude tüüp | Peamiselt mittefunktsionaalne – taastamine, varundamine, teavitamine, turvalisus | Peamiselt funktsionaalne — äritegevuse töövood ja reeglid |
| keskkond | Tootmislaadne, päris jälgimise ja varundustööriistadega | Stabiilne testimiskeskkond representatiivsete andmetega |
| Tüüpilised tõendid | Logide, tõrkesiirde ajastuste, hoiatuste ekraanipiltide ja allkirjastatud käitusraamatute taastamine | Täidetud äristsenaariumid ja kasutaja kinnitus |
| Ebaõnnestumine näeb välja selline | Süsteem töötab, kuid seda ei saa taastada, jälgida ega taaskäivitada | Süsteem töötab, aga ei tee seda, mida ettevõte palus |
Need kaks täiendavad teineteist, mitte ei ole alternatiivid. Väljalase, mis läbib UAT-i, aga ei läbi OAT-i, toimib korrektselt kuni esimese katkestuseni.
Eelised ja väljakutsed Operariiklik testimine
OAT-d kasutusele võtvad meeskonnad viitavad tavaliselt samadele eelistele ja seisavad silmitsi samade takistustega.
Eelised
- Katkestuse risk väheneb, sest taastamis- ja tõrkesiirde teed rakendatakse enne, kui kliendid neist sõltuvad.
- Tugimeeskonnad pärivad dokumentatsiooni, mis on tõestatud tegeliku süsteemi vastu, mitte ei ole kirjutatud disainist.
- Juurutamise üllatused ilmnevad kontrollitud aknas, mitte otseülekande ööl.
- Kontrollnimekirja kõrvalsaadusena genereeritakse vastavus- ja audititõendeid.
Väljakutsed
- Tootmiskeskkond on kallis ja vähendatud koopia peidab täpselt neid vigu, mida OAT peaks leidma.
- Tsükkel konkureerib sama kalendriruumi pärast kui väljalase, seega on see esimene tegevuse kärpimine, kui kuupäev nihkub.
- Hävitavad juhtumid, näiteks tõrkesiire ja taastamine, vajavad raskesti kättesaadavaid kinnitusi ja vaikseid aknaid.
- Tulemused sõltuvad tegevpersonalist, kes samaaegselt käitab praegust reaalajas teenust.
Tavaline leevendus on alustada väikesest: automatiseerida esmalt varundamise-taastamise ja taaskäivitamise juhtumid, kuna need korduvad igas väljalaskes ja annavad kõige selgema signaali läbimise või ebaõnnestumise kohta. Sealt edasi saab kontrollnimekiri iga tsükliga kasvada ja iga muudatus tööraamatutes muutub kandidaadiks. regressioonitest järgmises väljaandes.
