OperaPélda az átvételi tesztelésre (OAT).
Thomas Hamilton
⚡ Okos összefoglaló
OperaA nemzetközi elfogadási tesztelés azt értékeli, hogy egy kiadás készen áll-e a futtatásra a szabványos verziójában. Operating Környezet, biztonsági mentések ellenőrzése, helyreállítás, riasztások, biztonság és dokumentáció, mielőtt a rendszert átadnák az éles támogató csapatoknak.
Mi a Operanemzeti átvételi tesztelés?
OperaNemzeti átvételi tesztelés (OAT) egy szoftvertesztelési technika, amely egy szoftveralkalmazás működési készenlétét értékeli az éles környezetben való megjelenése előtt. Az üzemi átvételi tesztelés célja a rendszer és az összetevők megfelelőségének, valamint a rendszer zökkenőmentes működésének biztosítása a szabványoknak megfelelően. Operakörnyezet (SOE).
Operanemzetközi átvételi tesztelésnek is nevezik OperaNemzetközi Készenléti Tesztelés (ORT), vagy rövidebben operatív tesztelés. Mindhárom elnevezés ugyanazt az ellenőrzést írja le: a szoftver már elvégezheti azt, amit a vállalkozás kért, de még senki sem bizonyította, hogy a bevezetés után a tulajdonosai telepíteni, biztonsági másolatot készíteni, újraindítani, felügyelni és helyreállítani tudják.
Ez a megkülönböztetés az OAT-t határozottan a következők közé sorolja: nem funkcionális tesztelés típusok. Azt kérdezi, hogyan viselkedik a rendszer valós működési körülmények között, ahelyett, hogy egy jellemző a helyes választ adja-e vissza.
Típusok Operanemzeti tesztelés
OperaAz interakciós tesztelés egy ernyőtevékenység. Az alábbi tételek mindegyike külön ellenőrzés, saját belépési feltételekkel és saját bizonyítékokkal, és egy teljes OAT-ciklus általában ezek nagy részét érinti.
- Telepítési tesztelés — megerősíti, hogy a build telepíthető, frissíthető és visszaállítható a célkörnyezetben a mellékelt dokumentáció segítségével.
- Terhelési és teljesítményteszt OperaCIÓ — ellenőrzi, hogy a rendszer tartja-e a várható átviteli sebességet és válaszidőket a termelési szintű mennyiség alatt. Lásd: Teljesítményfelmérés és a terhelés tesztelése az alapul szolgáló technikákhoz.
- Biztonsági mentés és visszaállítás tesztelése — bizonyítja, hogy a biztonsági mentés ténylegesen ütemterv szerint elkészíthető és működőképes állapotba visszaállítható, nem csupán lemezre írható.
- Biztonsági tesztelés — ellenőrzi a hozzáférés-vezérlést, a hitelesítő adatokat, a tanúsítványokat és a biztonsági előírások betartását a működési környezetben. Lásd: biztonsági tesztelés a részletes módszerhez.
- Code Elemzés — a leszállított kód és konfiguráció statikus áttekintése a karbantarthatóság és az ismert gyengeségek szempontjából, mielőtt az valakinek a termelési terhet jelentene.
- Sikertelen tesztelés – egy csomópontot, szolgáltatást vagy telephelyet leállásra kényszerít, és megfigyeli, hogy a tartalék üzemmód átveszi-e az irányítást a megbeszélt időn belül.
- Helyreállítási tesztelés – azt méri, hogy a rendszer milyen gyorsan és milyen teljes mértékben áll vissza a működésbe egy összeomlás után. Helyreállítási tesztelés mélyrehatóan tárgyalja a technikát.
- Végtől végig Tesztkörnyezet Operanemzeti tesztelés — egyetlen operációs egységként működteti a szerverek, hálózatok, feladatok és interfészek teljes láncolatát.
- Operanemzeti dokumentáció Review — ellenőrzi, hogy a runbookok, szolgáltatásdiagramok, újraindítási utasítások és eszkalációs útvonalak megfelelnek-e a ténylegesen felépített rendszernek.
Az alábbi ábra a kiadás körüli ellenőrzéseket csoportosítja, az operációs tesztelést az alkalmazás éles környezetbe való belépése előtti utolsó kapuként mutatva be.
Miért Operanemzeti tesztelés
OperaA funkcionális tesztelés azért létezik, mert egy olyan kiadást, amely minden funkcionális követelménynek megfelel, továbbra sem lehet futtatni.
- Az OAT során a szoftverkonfigurációk és az operatív támogatási komponensek először kerülnek össze.
- Funkcionális vagy nem funkcionális környezetben teszteli egy szoftver vagy szolgáltatás funkcionális vagy strukturális változtatásainak megvalósítását.
- Ez a tesztelés azt határozza meg, hogy egy alkalmazás telepíthető-e hálózaton az IT Infrastructure Library (ITIL) szabványoknak megfelelően.
- Azt mondja meg, hogy egy szoftver a tervezett módon fog-e működni anélkül, hogy megzavarná az üzleti folyamatokat.
- Az OAT főként a szoftvertermék következő aspektusaira összpontosít:
- Rugalmasság
- Helyreállító képesség
- Kezelhetőség és támogathatóság
- Integrity
Ki lép fel? OperaNemzetközi tesztelés és mikor
Az OAT tulajdonjoga minden korábbi tesztszinttől eltér, és ez a különbség magyarázza a legtöbb eredményt. Azok az emberek futtatják, akiket hajnali háromkor értesítenek.
- Rendszergazdák és infrastruktúra-mérnökök — telepítés végrehajtása, feladatátvétel és esetek újraindítása a célkörnyezetben.
- Operaés támogató csapatok — validálja a riasztásokat, küszöbértékeket, eszkalációs útvonalakat és az egyes riasztások által hivatkozott megoldási dokumentumokat.
- Adatbázis- és biztonsági mentési adminisztrátorok — biztonsági mentések készítése és visszaállítása, beleértve a második webhelyre történő visszaállítást is.
- Biztonsági és megfelelőségi személyzet — erősítse meg a védelmet, a hozzáférés-vezérlést és az auditnaplózást az élő környezetben.
- Tesztvezetők — gyűjtsd össze a bizonyítékokat az éles indulással kapcsolatos döntési csomagba.
A szoftvertesztelés életciklusaaz operatív tesztelés a legvégén található. Rendszer tesztelés Az OAT bizonyítja, hogy az összeállított termék működik, a felhasználói elfogadási tesztelés bizonyítja, hogy az üzleti tevékenység elfogadja, majd az OAT bizonyítja, hogy a szervezet képes futtatni. Mivel éles környezetre van szüksége, az OAT-t általában a kiadásra jelölt termék befagyasztása után ütemezik – a kód bármilyen módosítása ezután a ciklust visszaállítja a kezdetekre.
Példa tesztesetek a Operanemzeti tesztelés vagy OAT
Az alábbiakban egy hasznos ellenőrzőlista látható az OAT elvégzéséhez. Minden sort úgy írtunk, hogy az eredmény egyértelmű „sikeres” vagy „sikertelen” legyen, amire egy éles go-app boardnak szüksége van.
- Az egyik helyszínen készített biztonsági mentések ugyanarra a helyre visszaállíthatók.
- Az egyik helyszínen készített biztonsági mentések visszaállíthatók a másik helyszínen.
- Az új funkciók éles termelési környezetbe való bevezetése nem befolyásolja hátrányosan a jelenlegi termelési szolgáltatások integritását.
- A megvalósítási folyamat érvényes dokumentáció használatával megismételhető.
- Minden egyes komponens sikeresen leállítható és elindítható a megállapodott időskálán belül.
- Riasztások esetén minden kritikus riasztást a TEC-hez kell küldeni, és hivatkozni kell a megfelelő megoldási dokumentumra.
- Riasztások vannak érvényben, és azokat akkor adják ki, ha a megállapított küszöbértékeket túllépik.
- Minden elkészített vagy módosított helyreállítási dokumentáció, beleértve a szervizdiagramokat is, érvényes. Ezeket át kell adni az illetékes támogatási területeknek.
- A meghibásodás által érintett komponenseknél megjelenik az újraindítás ajánlott sorrendje, a befejezéshez szükséges idő és az érintett függőségek.
A lista egy praktikus kiegészítése a negatív eset: szándékosan megszakítunk egy függőséget, majd megerősítjük, hogy a riasztás aktiválódik, a runbook megtalálható, és a dokumentált újraindítási parancs visszaállítja a szolgáltatást. Egy olyan ellenőrzőlista, amely csak a sikeres műveleteket rögzíti, egyáltalán nem tesztelte a műveletet.
OperaNemzetközi tesztelés vs. felhasználói elfogadási tesztelés
ZAB és felhasználói elfogadási tesztelés mindkettő elfogadási tevékenység, és mindkettő késik, ezért keverik össze őket olyan gyakran. Különböző kérdésekre válaszolnak, és különböző emberek hagyják jóvá őket.
| Aspect | OperaNemzeti átvételi tesztelés (OAT) | Felhasználói elfogadási teszt (UAT) |
| Megválaszolt kérdés | Tudja-e a szervezet működtetni és támogatni ezt a rendszert? | Megfelel-e a rendszer a megállapodás szerinti üzleti követelményeknek? |
| Előadja | Operainfrastruktúrát és támogató személyzetet | Végfelhasználók, üzleti érdekelt felek és ügyfelek |
| Követelmény típusa | Főként nem funkcionális – helyreállítás, biztonsági mentés, riasztás, biztonság | Főként funkcionális – üzleti munkafolyamatok és szabályok |
| Környezet | Termelési szintű, valódi monitorozási és biztonsági mentési eszközökkel | Stabil tesztkörnyezet reprezentatív adatokkal |
| Tipikus bizonyítékok | Naplók, feladatátvételi időzítések, riasztási képernyőképek, aláírt runbookok visszaállítása | Végrehajtott üzleti forgatókönyvek és felhasználói jóváhagyás |
| A kudarc úgy néz ki, mint | A rendszer működik, de nem állítható vissza, nem figyelhető meg vagy nem indítható újra. | A rendszer működik, de nem azt teszi, amit a vállalkozás kért |
A kettő inkább kiegészíti egymást, mintsem alternatívát jelent. Az a kiadás, amelyik átmegy az UAT-n, de nem megy át az OAT-n, az az, amelyik az első kiesésig helyesen fog működni.
Előnyei és kihívásai Operanemzeti tesztelés
Az OAT-t alkalmazó csapatok általában ugyanazokat az előnyöket említik, és ugyanazokkal az akadályokkal szembesülnek.
Előnyök
- A kiesés kockázata csökken, mivel a helyreállítási és hibatűrési útvonalak aktiválása megtörténik, mielőtt az ügyfelek rájuk támaszkodnának.
- A támogató csapatok olyan dokumentációt örökölnek, amelyet a valós rendszerrel szemben igazoltak, nem pedig a terv alapján íródott.
- A telepítési meglepetések egy ellenőrzött időablakban érkeznek, ahelyett, hogy az éles indulás éjszakáján érkeznének.
- A megfelelőségi és auditbizonyítékok az ellenőrzőlista melléktermékeként keletkeznek.
Kihívások
- Egy termelési környezet drága, és egy kicsinyített másolat pontosan azokat a hibákat rejti, amelyeket az OAT-nak meg kell találnia.
- A ciklus ugyanarra a naptári helyre versenyez, mint a kiadás, így ez az első tevékenységcsökkentés, amikor egy dátum elcsúszik.
- A destruktív esetek, mint például a feladatátvétel és a visszaállítás, nehezen beszerezhető jóváhagyásokat és csendes ablakokat igényelnek.
- Az eredmények az operatív személyzettől függenek, akik egyidejűleg futtatják az aktuális élő szolgáltatást.
A szokásos megoldás a kicsiben való kezdés: először automatizálni kell a biztonsági mentés-visszaállítás és az újraindítás eseteit, mivel ezek minden kiadásban megismétlődnek, és a legtisztább jelet adják a sikeres vagy sikertelen állapotnak. Innentől kezdve az ellenőrzőlista minden ciklussal bővülhet, és a runbookok bármilyen módosítása potenciális jelöltté válik. regressziós teszt a következő kiadásban.
