A bejelentkezési folyamat automatizált tesztelése
A bejelentkezési folyamat automatikus tesztelése csak akkor válik banális kérdéssé, ha működik. Ha egy kiadás után meghibásodik, a munkatársak a műszak kezdetén szembesülnek vele, az ügyfelek kizárva találják magukat az ügyfélportálból, vagy a diszpécserek blokkolt rendeléskezeléssel szembesülnek. A bejelentkezési folyamat automatikus tesztelése ezért nem egyszerűen egy felhasználónév és jelszó űrlapba írását jelenti. Azt jelenti, hogy ismételten ellenőrizzük egy kritikus fontosságú belépési pontot, annak összes szabályával, kivételével, és biztonsági határával.
Sok csapat esetében az automatizálás egyetlen pozitív teszteseten kezdődik: érvényes hitelesítő adatok megadása, a bejelentkezés megerősítése, és a kezdőlap megjelenítése. Ez ésszerű, de önmagában nem elegendő egyetlen tesztként. A bejelentkezési hibák gyakran a szélső eseteknél fordulnak elő: lejárt munkameneteknél, zárolt fiókoknál, egy új többtényezős hitelesítési módszernél, vagy olyan jogosultságoknál, amelyek egy szerepkör-változtatás után már nem érvényesek helyesen. Pontosan ezeket a forgatókönyveket kell tervezett módon lefedni.
Miért igényel a bejelentkezés különleges tesztelési fegyelmet
A bejelentkezés egyszerre biztonsági funkció, technikai felület, és a munkafolyamat belépési pontja. Egy hiba lehet túl engedékeny, jogosulatlan hozzáférést téve lehetővé. Fordítva, lehet túl szigorú is, kizárva a jogosult személyeket. Mindkettő költséges: az első eset kockázatokat teremt az adatok és a megfelelőség szempontjából, míg a második állásidőt, támogatási terhet, és kapkodó vészmegoldásokat okoz.
Webalkalmazásoknál további függőségek jönnek szóba. A bejelentkezés gyakran kommunikál egy identitásszolgáltatóval, egy jelszó-visszaállító levelezőrendszerrel, egy MFA-alkalmazással, vagy egy címtárszolgáltatással. Windows asztali alkalmazásoknál a helyi jogosultságok, hálózati kapcsolatok, és verzióállapotok is befolyással lehetnek. Egy teszt, amely csak a böngészőben lévő űrlapot nézi, nem képes megbízhatóan felismerni az ilyen integrációs problémákat.
Ezért a tesztautomatizálás megkezdése előtt a csapatnak meg kell határoznia, mit jelent a sikeres bejelentkezés az adott rendszerben. Elegendő egy látható kezdőlap? Vagy ellenőrizni kell, hogy betöltődött-e a helyes bérlőkiválasztás, helyes-e a felhasználói szerepkör, és valóban lehetséges-e az első védett művelet? Egy raktári portálnál ez például a bejövő áruhoz való hozzáférés lenne. Egy diszpécseri rendszernél ez lehet egy túra felszabadítása.
A bejelentkezési folyamat automatikus tesztelése: a munkafolyamat-modelltől a tesztesetig
A jó kiindulópont nem egy szkript, hanem egy munkafolyamat-modell. A bejelentkezés leírható egyértelmű állapotok sorozataként: kijelentkezve, hitelesítő adatok elküldve, identitás megerősítve, MFA szükséges, bejelentkezve, munkamenet lejárt, vagy fiók zárolva. Minden állapot magában foglalja az engedélyezett műveleteket és a várt rendszerválaszokat.
Ebből a modellből üzleti értékkel bíró tesztesetek jönnek létre. A szabványos pozitív eset ide tartozik, de az érvénytelen jelszavak, nem létező felhasználói fiókok, és lejárt visszaállítási linkek is. Fontos itt a várt visszajelzés. Hibás hitelesítő adatok esetén egy alkalmazásnak nem szabad felfednie, hogy létezik-e egy e-mail cím. A teszt ezért nemcsak azt ellenőrzi, hogy megjelenik-e egy hiba, hanem azt is, hogy annak szövege és viselkedése nem ad-e felesleges nyomokat.
Az ismétlődő sikertelen kísérletek elleni védelmi mechanizmusok különösen relevánsak. Egy meghatározott számú helytelen bevitel után egy fiók átmenetileg zárolható. Az automatizált tesztnek ellenőriznie kell, hogy a zárolás valóban életbe lép-e, meddig tart, és hogy a jogos felhasználó ezt követően visszakapja-e a kontrollált hozzáférést. Itt precizitásra van szükség: egy teszt, amely szándékosan zárolja a termelési fiókokat, több problémát teremt, mint amennyit megold. Az ilyen forgatókönyvek egy különálló tesztkörnyezetbe tartoznak, kifejezetten erre létrehozott fiókokkal.
Az MFA, a jelszó-visszaállítás, és a Single Sign-On külön kezelése
A többtényezős hitelesítés nem apró részlet a bejelentkezés végén. Megváltoztatja a munkafolyamatot. Egy tesztnek fel kell ismernie, hogy a jelszó után további megerősítés szükséges, és le kell képeznie mind a sikeres, mind az elutasított megerősítést. Idő alapú egyszeri kódoknál a tesztkörnyezet kontrollált idő- és titokkezelést igényel. Sok esetben az identitásszolgáltató által biztosított tesztelési módszer ésszerűbb, mint egy valódi mobiltelefon rekonstruálása.
A jelszó-visszaállításnak és a Single Sign-On-nak is saját tesztpályákat kell kapnia. A visszaállításnál az üzenet továbbítása, a link egyedisége, az érvényességi időszak, és az azt követő bejelentkezés az új jelszóval számít. Az SSO-nál döntő, hogy az alkalmazás helyesen hozza-e létre a munkamenetet, és tisztán átveszi-e a szerepköröket az identitásszolgáltatótól való visszatérés után.
A CAPTCHA-k külön esetet képeznek. Ezek az automatizált támadások lassítására szolgálnak, és nem szabad megkerülni őket tesztautomatizálással. Ehelyett egy tesztkonfiguráció, egy hivatalos tesztkulcs, vagy egy biztosított kivétel a tesztkörnyezethez ésszerű. A biztonsági ellenőrzések becsapása csak azért, hogy egy teszt zöldre váljon, nem minőségi stratégia.
A megfelelő technikai teszt-réteg kiválasztása
Nem minden bejelentkezési tesztnek kell valódi böngészőn keresztül futnia. Az API-tesztek ellenőrizhetik, hogy a tokenek, munkamenetek, hibaüzenetek, és zárolási szabályok helyesen működnek-e. Gyorsak, és segítenek a hitelesítési logikához közeli hibák megtalálásában. A böngészőtesztek viszont megmutatják, hogy a mezők, átirányítások, sütik, SameSite beállítások, és a látható állapotok illeszkednek-e egymáshoz a valódi felhasználói munkafolyamatban.
Kritikus alkalmazásoknál ésszerű a kombináció. Néhány végponttól végpontig teszt ellenőrzi a teljes útvonalat a böngésző használatával. E mögött célzott API- és integrációs tesztek biztosítják a változatokat. Ez csökkenti a futásidőt és a téves riasztásokat. Aki minden elképzelhető kombinációt kizárólag a böngészőben tesztel, gyakran egy lassú tesztcsomaggal végzi, amelynek karbantartása több időt emészt fel, mint amennyit megtakarít.
Az asztali szoftvereknél hasonló elv érvényes. Egy automatizált tesztnek nem szabad csupán azt ellenőriznie, hogy egy ablak megnyílik-e. Meg kell határoznia, hogy bejelentkezés után fennáll-e a helyes adatkapcsolat, aktívak-e a felhasználói jogosultságok, és elérhető-e a központi munkaképernyő. Ez különösen releváns a raktári vagy gyártási alkalmazásoknál, mivel a munkaállomásoknak eltérő hálózati körülményei, szkennercsatlakozásai, vagy helyi konfigurációi lehetnek.
A tesztadatok biztonságos és ismételhető kezelése
A bejelentkezési tesztek elkerülhetetlenül hitelesítő adatokkal dolgoznak. A termelési munkatársi fiókok, valódi ügyféladatok, vagy MFA-titkok azonban nem tartoznak ellenőrizetlenül tesztszkriptekbe, naplókba, és képernyőképekbe. A tesztfiókoknak egyértelműen megjelöltnek, minimálisan jogosultnak, és automatikusan visszaállíthatónak kell lenniük. A jelszavakat és tokeneket biztonságos titokkezelésen keresztül biztosítják, nem pedig a forráskódban tárolják.
Ugyanolyan fontos a takarítás egy tesztfuttatás után. Ha egy teszt új munkameneteket, naplóbejegyzéseket, vagy zárolt fiókokat hoz létre, a tesztkörnyezetnek vissza kell térnie egy meghatározott kezdeti állapotba. Máskülönben egy hétfői teszt egyszerűen azért bukik meg, mert egy pénteki futtatás mellékhatásokat hagyott maga után.
Bizalmas alkalmazásokkal rendelkező vállalatoknál a végrehajtás helye is döntő. A bejelentkezési képernyők képernyőképei, tesztvideók, és technikai naplók érzékeny információkat tartalmazhatnak. Egy önállóan üzemeltetett tesztinfrastruktúra, mint a COCO, itt ésszerű lehet, mert a tesztadatok, a végrehajtás, és a bizonyítékok saját kontroll alatt maradnak. Hogy ez szükséges-e, a védelmi igényektől, szerződéses helyzetektől, és belső irányelvektől függ. Egy különálló infrastruktúra nem automatikusan a leggazdaságosabb választás minden alkalmazáshoz.
Bizonyítékok generálása, nem csak zöld pipák
Egy tesztjelentésnek érthetővé kell tennie a QA, a fejlesztés, és az üzleti osztály számára, hogy mit teszteltek. Egy zöld státusz kontextus nélkül keveset segít, ha egy kiadás később kérdéseket vet fel. Ezért hasznosak az időbélyegek, a használt tesztkörnyezet, a tesztfiók, a releváns lépések, a hibák esetén készült képernyőképek, és egy egyértelmű, hétköznapi nyelvű hibaüzenet.
Ebben az összefüggésben a bizonyítékgyűjtés önmagában nem válhat adatvédelmi problémává. A jelszavakat, egyszeri kódokat, munkamenet-azonosítókat, és személyes adatokat maszkolni kell a naplókban. Képernyőképeknél szükséges lehet bizonyos területek elmosása. Ezeknek a szabályoknak a tesztarchitektúra részét kell képezniük, nem egy incidens utáni manuális utómunkát.
Mit érdemes a csapatoknak először automatizálniuk
A prioritást a kockázat és a használati gyakoriság vezérli. Elsőként a legfontosabb szerepkörök szabványos bejelentkezése, a hibás hitelesítő adatok, a kijelentkezés, és a munkamenet lejárata következik. Ezt követik a zárolási szabályok, a jelszó-visszaállítás, az MFA, és a szerepkör-változtatások. Az SSO, speciális bérlők, vagy ritka kivétel-útvonalak később követhetik, feltéve hogy meghibásodásuk nem állítja le azonnal a működést.
A tesztek a kiadási folyamatba tartoznak. A bejelentkezési űrlapok, sütik, jogosultságok, vagy identitásszolgáltató-konfiguráció változásainak indítaniuk kell a megfelelő tesztcsomagot, mielőtt egy verzió éles környezetbe kerül. Ezenkívül megéri egy tervezett futtatás valós környezetben, például infrastruktúra-változtatások vagy tanúsítvány-megújítások után. Ez olyan problémákat talál meg, amelyek egy elszigetelt fejlesztői környezetben nem láthatók.
Végül a legjobb bejelentkezési teszt nem az, amelyiknek a legtöbb kattintása van. Az, amelyik korán észleli a valódi meghibásodást, érthetően dokumentálja, és még mindig megbízhatóan végrehajtható a következő változtatás során. Aki a bejelentkezést egyértelműen modellezett üzleti folyamatként kezeli, többet véd, mint egy egyszerű űrlapot. A mögötte várakozó munkához való hozzáférést védi.