Felkészülés a futásra: A pénzügyi alkalmazások teljesítményének minőségének biztosítása előre nem látható körülmények között

Felkészülés a futásra: A pénzügyi alkalmazások teljesítményének minőségének biztosítása előre nem látható körülmények között

Időbélyeg: 12. június 2023. 10:00
Preparing For a Run: Ensuring Financial App Performance Quality During Unpredictable Circumstances PlatoBlockchain Data Intelligence. Vertical Search. Ai.

Amikor az alkalmazásaik teljesítményének teszteléséről van szó, a kereskedők valamivel kiszámíthatóbb munkateherrel rendelkeznek. Már ismerik a zsúfolt időket – például a fekete pénteket és a karácsony előtti hetet. Ez egyszerűbbé teszi a kapacitástervezést és a szoftvertesztet.

A pénzügyi szektor viszont nem rendelkezik ezzel a luxussal. A pénzügyi szolgáltatások iránti nagy keresletet számos váratlan esemény kiválthatja, mint például a tőzsde nagy változásai, természeti katasztrófák vagy nagy világesemények. Ez azt jelenti, hogy a pénzügyi alkalmazásoknak és rendszereknek mindig készen kell állniuk a szokásosnál nagyobb forgalom kezelésére (nincs itt semmi új: az 1987-es internetes tőzsdekrach előtt sok helyszíni telefonrendszer nem volt felszerelve a váratlan mennyiség kezelésére az elkeseredett ügyfelek hívásai közül.)

Ezenkívül tévedés a teljesítménytesztet elszigetelt utólagos gondolatnak tekinteni, amelyet egy projekt befejezése után kell elvégezni. Ehelyett a fejlesztési folyamat minden lépésébe be kell ágyazni, és a teljesítménytesztet a tesztelés négy pillére egyikének kell tekinteni:

Funkcionális tesztelés – Győződjön meg arról, hogy a funkciók megfelelnek az előírásoknak

Regressziós tesztelés – Győződjön meg arról, hogy nem vezettek be új hibákat

Teljesítményteszt – Győződjön meg arról, hogy a teljesítmény megfelel a megadott kritériumoknak

Negatív tesztelés – Erősítse meg a szoftvert szokatlan és váratlan körülményeknek kitéve.

Mind a négy pillér figyelembevétele mellett fontos, hogy ezeket a teszteket jóval a rendszerintegráció előtt elvégezzék. Ez azt jelenti, hogy a tesztelés mind a négy szintjét az összetevők szintjén kell elvégezni (gondolja ezeket az alkalmazásokat alkotó kódblokkoknak). Ennek az az oka, hogy a kód részletei még mindig frissek lesznek a fejlesztő fejében, ha bármilyen probléma merülne fel. Ráadásul minél alaposabban tesztelik az összetevőket, annál nagyobb a valószínűsége a gyors és sikeres rendszerintegrációnak.

A tesztelést is be kell ágyazni a fejlesztési folyamatba: ne adják át a fejlesztőknek az összetevőket egy elszigetelt tesztelőcsoportnak. Ideális esetben egy környezet jön létre az egyes összetevők tesztelésére, amely nagyban hozzájárul az alkalmazás minden aspektusának megfelelő működéséhez. 

A negatív teszt az egyetlen pillér, amely nem kap annyi figyelmet, mint kellene. Ezeknek a teszteknek tartalmazniuk kell a határon túli feltételeket (ahol az értékek meghaladják a megadott tartományokat), a helytelen adatértékeket (például alfabetikus karaktereket egy numerikus mezőben) és a váratlan aszinkron hívásokat (amikor az összetevőt akkor hívják meg, amikor nem számít hívják).

Az álszolgáltatások nagyszerű eszközt jelentenek a negatív teszteléshez. Simulhatnak egy lassú szolgáltatást, egy érvénytelen adatot visszaadó szolgáltatást és egy olyan szolgáltatást, amely váratlan válaszokat ad vissza. Lehetnek harmadik felek is, akik részt vesznek a folyamatban (egy bank esetében ez más részlegeket is magában foglalhat). Ismét egy álszolgáltatás használható pozitív, negatív és teljesítménytesztekre élő harmadik fél helyett.

A negatív tesztelés célja annak biztosítása, hogy az alkalmazás minden komponense robusztus és rendezett módon kezelje a problémás körülményeket. Például a tipikus felhasználó akkor lesz a legelégedetlenebb, ha egy mobilalkalmazás vagy weboldal több mint három másodpercig változatlan marad. Ha egy mobil átjáró nem válaszol három másodpercen belül, a mobilalkalmazásnak üzenetet kell megjelenítenie, amely szerint a feldolgozás még folyamatban van. A mobil átjárót szimuláló lassú álszolgáltatás lehetővé teszi az effajta teszt elvégzését.

A teljesítményteszt kritikusságát nem lehet túlbecsülni. A nagyszámú eszköz terhelésének szimulációja felhasználható arra, hogy információkat gyűjtsünk a végfelhasználói élményről, amikor a rendszer terhelés alatt áll.

Amikor teljesítménytesztet hajtanak végre az összetevők szintjén, a rendszertervező meghatározhatja az egyes összetevők várható teljesítményét. Ha a komponens szintű teljesítményteszt során kiderül, hogy az összetevő nem éri el a kívánt teljesítményszintet, akkor gyorsan kezelhető, ahelyett, hogy nem lenne probléma a végső teljesítményteszt elvégzéséig, amikor a változtatások sokkal nehezebbek.

Az alkalmazás-összetevők fejlesztése és tesztelése után ugyanaz a négy pillér lesz érvényes a rendszerintegrációs tesztelésre.

Ha egy új projektet termelésbe helyeztek, a tesztelést továbbra is folytatni kell. A tesztelésnek időszakos maximális terhelési tesztekből kell állnia, hogy biztosítsák a teljes rendszer rendelkezésre állását váratlan terhelés esetén. Charles Schwab például rendszeresen végez nagy volumenű teszteket, hogy ha tőzsdei zavarok lépnének fel, online rendszereik bizonyítottan bírják a rendkívüli terhelést.

Néha egy bank bezárása annak a következménye, hogy egy pénzintézet rendszere nem képes kezelni a váratlan terhelést. Ez potenciálisan kérdéseket vethet fel a pénzintézet életképességével kapcsolatban. A mai banki világban a pletykák elektronikus banki megfutásokat okozhatnak. A pénzkivonás sebessége gyorsan megelőzheti a kapacitásproblémák megoldására irányuló tülekedést. Jobb alaposan tesztelni a teljesítményt, mielőtt a válság meglepetést okozna. 

A funkcionális, a regressziós, a teljesítmény- és a negatív tesztelés négy pillérének komponensszinten – és rendszeres szinten történő – végrehajtása nagymértékben hozzájárulhat a pénzintézetek technológiájába, alkalmazásaiba vetett bizalom építéséhez, és javíthatja az ügyfélélményt. , és készen áll az ismeretlennel való megküzdésre.

Időbélyeg:

Még több Fintextra