Automatizované testovanie prihlasovacieho procesu

Automatické testovanie prihlasovacieho procesu sa stáva banálnou záležitosťou len vtedy, keď funguje. Ak zlyhá po vydaní, zamestnanci čelia začiatku zmeny, zákazníci sa ocitnú zablokovaní mimo zákazníckeho portálu, alebo dispečeri riešia blokované spracovanie objednávok. Automatické testovanie prihlasovacieho procesu preto neznamená len zadanie používateľského mena a hesla do formulára. Znamená to opakovanú kontrolu mission-critical prístupového bodu so všetkými jeho pravidlami, výnimkami, a bezpečnostnými hranicami.

Pre mnohé tímy automatizácia začína jediným pozitívnym testovacím prípadom: zadaním platných prihlasovacích údajov, potvrdením prihlásenia, a zobrazením domovskej stránky. To má zmysel, ale samo osebe je nedostatočné ako jediný test. Chyby prihlásenia sa často vyskytujú na okrajoch: pri vypršaných reláciách, zablokovaných účtoch, novej metóde viacfaktorovej autentifikácie, alebo oprávneniach, ktoré po zmene roly už správne neplatia. Presne tieto scenáre je potrebné pokryť plánovaným spôsobom.

Prečo prihlásenie vyžaduje osobitnú testovaciu disciplínu

Prihlásenie je súčasne bezpečnostnou funkciou, technickým rozhraním, a vstupným bodom do pracovného postupu. Chyba môže byť príliš zhovievavá, umožňujúca neoprávnený prístup. Naopak, môže byť aj príliš prísna, blokujúca oprávnené osoby. Oboje je nákladné: prvý prípad vytvára riziká pre dáta a súlad, zatiaľ čo druhý spôsobuje výpadky, záťaž podpory, a horúčkovité núdzové riešenia.

Pre webové aplikácie prichádzajú do hry ďalšie závislosti. Prihlásenie často komunikuje s poskytovateľom identity, poštovým systémom na obnovenie hesla, MFA aplikáciou, alebo adresárovou službou. Pri desktopových aplikáciách Windows môžu mať vplyv lokálne práva, sieťové pripojenia, a statusy verzií. Test, ktorý sa pozerá len na formulár v prehliadači, nedokáže spoľahlivo odhaliť takéto integračné problémy.

Preto by mal tím pred začatím akejkoľvek automatizácie testov definovať, čo znamená úspešné prihlásenie v danom systéme. Stačí viditeľná domovská stránka? Alebo je potrebné skontrolovať, či bol načítaný správny výber nájomcu, či je rola používateľa správna, a či je skutočne možná prvá chránená akcia? Pre skladový portál by to bol napríklad prístup k príjmu tovaru. Pre dispečerský systém by to mohlo byť uvoľnenie trasy.

Automatické testovanie prihlasovacieho procesu: od modelu pracovného postupu k testovaciemu prípadu

Dobrým východiskovým bodom nie je skript, ale model pracovného postupu. Prihlásenie možno opísať ako sekvenciu jasných stavov: odhlásený, prihlasovacie údaje odoslané, identita potvrdená, vyžadovaná MFA, prihlásený, relácia vypršala, alebo účet zablokovaný. Každý stav zahŕňa povolené akcie a očakávané odpovede systému.

Z tohto modelu vznikajú testovacie prípady s obchodnou hodnotou. Štandardný pozitívny prípad sem patrí, ale aj nesprávne heslá, neexistujúce používateľské účty, a vypršané resetovacie odkazy. Dôležitá je tu očakávaná spätná väzba. V prípade chybných prihlasovacích údajov by aplikácia nemala prezradiť, či e-mailová adresa existuje. Test preto kontroluje nielen to, či sa zobrazí chyba, ale aj to, či jej text a správanie neposkytujú zbytočné náznaky.

Ochranné mechanizmy proti opakovaným neúspešným pokusom sú obzvlášť relevantné. Po definovanom počte nesprávnych zadaní môže byť účet dočasne zablokovaný. Automatizovaný test musí skontrolovať, či zablokovanie skutočne nastúpi, ako dlho trvá, a či legitímny používateľ následne získa späť kontrolovaný prístup. Tu je potrebná presnosť: test, ktorý zámerne blokuje produkčné účty, vytvára viac problémov, než rieši. Takéto scenáre patria do samostatného testovacieho prostredia so špeciálne vytvorenými účtami.

Samostatné zváženie MFA, obnovenia hesla, a Single Sign-On

Viacfaktorová autentifikácia nie je drobný detail na konci prihlásenia. Mení pracovný postup. Test musí rozpoznať, že po hesle sa vyžaduje ďalšie potvrdenie, a musí zmapovať úspešné aj odmietnuté potvrdenie. Pri časovo založených jednorazových kódoch testovacie prostredie vyžaduje kontrolované zaobchádzanie s časom a tajomstvami. V mnohých prípadoch je testovacia metóda poskytovaná poskytovateľom identity zmysluplnejšia než rekonštrukcia skutočného mobilného telefónu.

Obnovenie hesla a Single Sign-On by mali tiež dostať vlastné testovacie trasy. Pri obnovení záleží na prenose správy, jedinečnosti odkazu, dobe platnosti, a následnom prihlásení s novým heslom. Pri SSO je rozhodujúce, či aplikácia správne vytvorí reláciu a čisto prevezme roly po návrate od poskytovateľa identity.

CAPTCHA tvorí osobitný prípad. Majú za cieľ spomaliť automatizované útoky a nemali by byť obchádzané prostredníctvom automatizácie testov. Namiesto toho je zmysluplná testovacia konfigurácia, oficiálny testovací kľúč, alebo zabezpečená výnimka pre testovacie prostredie. Oklamávanie bezpečnostných kontrol len preto, aby test zobrazil zelený výsledok, nie je stratégiou kvality.

Výber vhodnej technickej vrstvy testu

Nie každý test prihlásenia musí prebiehať cez skutočný prehliadač. API testy môžu overiť, či tokeny, relácie, chybové hlásenia, a pravidlá zablokovania fungujú správne. Sú rýchle a pomáhajú nájsť chyby blízko autentifikačnej logiky. Prehliadačové testy naopak ukazujú, či polia, presmerovania, cookies, SameSite nastavenia, a viditeľné stavy do seba zapadajú v skutočnom pracovnom postupe používateľa.

Pre kritické aplikácie je zmysluplná kombinácia. Niekoľko end-to-end testov kontroluje kompletnú cestu pomocou prehliadača. Pod tým cielené API a integračné testy zabezpečujú varianty. Toto znižuje čas behu a falošné poplachy. Kto testuje každú predstaviteľnú kombináciu výlučne v prehliadači, často skončí s pomalou testovacou sadou, ktorej údržba spotrebuje viac času, než ušetrí.

Pre desktopový softvér platí podobný princíp. Automatizovaný test by nemal len kontrolovať, či sa okno otvorí. Musí určiť, či po prihlásení existuje správne dátové spojenie, či sú práva používateľa aktívne, a či je prístupná centrálna pracovná maska. Toto je obzvlášť relevantné pre aplikácie v sklade alebo výrobe, pretože pracoviská môžu mať rôzne sieťové podmienky, pripojenia skenerov, alebo lokálne konfigurácie.

Bezpečné a opakovateľné zaobchádzanie s testovacími dátami

Testy prihlásenia nevyhnutne pracujú s prihlasovacími údajmi. Produkčné účty zamestnancov, skutočné zákaznícke dáta, alebo MFA tajomstvá však nekontrolovane nepatria do testovacích skriptov, denníkov, a snímok obrazovky. Testovacie účty musia byť jasne označené, minimálne privilegované, a automaticky obnoviteľné. Heslá a tokeny sa poskytujú prostredníctvom bezpečnej správy tajomstiev namiesto uloženia v zdrojovom kóde.

Rovnako dôležité je čistenie po testovacom behu. Ak test vytvorí nové relácie, audítorské záznamy, alebo zablokované účty, testovacie prostredie sa musí vrátiť do definovaného počiatočného stavu. Inak test v pondelok zlyhá jednoducho preto, že beh z piatka zanechal vedľajšie účinky.

Pre firmy s dôvernými aplikáciami je rozhodujúce aj miesto vykonania. Snímky obrazovky prihlasovacích masiek, testovacie videá, a technické denníky môžu obsahovať citlivé informácie. Samostatne hostovaná testovacia infraštruktúra ako COCO tu môže mať zmysel, pretože testovacie dáta, vykonanie, a dôkazy zostávajú pod vlastnou kontrolou. Či je to potrebné, závisí od potrieb ochrany, zmluvných situácií, a interných smerníc. Samostatná infraštruktúra nie je automaticky najekonomickejšou voľbou pre každú aplikáciu.

Generovanie dôkazov, nielen zelených značiek

Testovacia správa by mala pre QA, vývoj, a obchodné oddelenie urobiť zrozumiteľným, čo bolo testované. Zelený status bez kontextu veľa nepomôže, ak vydanie neskôr vyvolá otázky. Užitočné sú preto časové pečiatky, použité testovacie prostredie, testovací účet, relevantné kroky, snímky obrazovky v prípade chýb, a jasná chybová správa v bežnom jazyku.

V tomto kontexte sa samotné zbieranie dôkazov nesmie stať problémom ochrany dát. Heslá, jednorazové kódy, ID relácií, a osobné údaje musia byť v denníkoch maskované. Pri snímkach obrazovky môže byť potrebné rozmazať určité oblasti. Tieto pravidlá by mali byť súčasťou testovacej architektúry, nie ručnou dodatočnou úpravou po incidente.

Čo by mali tímy automatizovať ako prvé

Priorita sa riadi rizikom a frekvenciou používania. Najprv prichádza štandardné prihlásenie pre najdôležitejšie roly, chybné prihlasovacie údaje, odhlásenie, a vypršanie relácie. Potom nasledujú pravidlá zablokovania, obnovenie hesla, MFA, a zmeny rolí. SSO, špeciálni nájomcovia, alebo zriedkavé cesty výnimiek môžu nasledovať neskôr, pokiaľ ich zlyhanie okamžite nezastaví prevádzku.

Testy patria do procesu vydávania. Zmeny v prihlasovacích formulároch, cookies, oprávneniach, alebo konfigurácii poskytovateľa identity by mali spustiť príslušnú testovaciu sadu pred tým, než verzia prejde do produkcie. Okrem toho sa oplatí plánovaný beh v realistickom prostredí, napríklad po zmenách infraštruktúry alebo obnovení certifikátov. Toto nájde problémy, ktoré nie sú viditeľné v izolovanom vývojovom prostredí.

Nakoniec najlepší test prihlásenia nie je ten s najväčším počtom kliknutí. Je to ten, ktorý včas odhalí skutočné zlyhanie, zrozumiteľne ho zdokumentuje, a stále môže byť spoľahlivo vykonaný pri ďalšej zmene. Kto zaobchádza s prihlásením ako s jasne modelovaným obchodným procesom, chráni viac než len formulár. Chráni prístup k práci, ktorá za ním čaká.