Automatizované testování přihlašovacího procesu

Automatické testování přihlašovacího procesu se stává banální záležitostí jen tehdy, když funguje. Pokud selže po vydání, zaměstnanci čelí začátku směny, zákazníci se ocitnou zablokovaní mimo zákaznický portál, nebo dispečeři řeší blokované zpracování objednávek. Automatické testování přihlašovacího procesu proto neznamená jen zadání uživatelského jména a hesla do formuláře. Znamená to opakovanou kontrolu mission-critical přístupového bodu se všemi jeho pravidly, výjimkami, a bezpečnostními hranicemi.

Pro mnoho týmů automatizace začíná jediným pozitivním testovacím případem: zadáním platných přihlašovacích údajů, potvrzením přihlášení, a zobrazením domovské stránky. To má smysl, ale samo o sobě je nedostatečné jako jediný test. Chyby přihlášení se často vyskytují na okrajích: při vypršelých relacích, zablokovaných účtech, nové metodě vícefaktorové autentizace, nebo oprávněních, která po změně role už správně neplatí. Přesně tyto scénáře je třeba pokrýt plánovaným způsobem.

Proč přihlášení vyžaduje zvláštní testovací disciplínu

Přihlášení je současně bezpečnostní funkcí, technickým rozhraním, a vstupním bodem do pracovního postupu. Chyba může být příliš shovívavá, umožňující neoprávněný přístup. Naopak může být i příliš přísná, blokující oprávněné osoby. Obojí je nákladné: první případ vytváří rizika pro data a soulad, zatímco druhý způsobuje výpadky, zátěž podpory, a horečnatá nouzová řešení.

Pro webové aplikace přicházejí do hry další závislosti. Přihlášení často komunikuje s poskytovatelem identity, poštovním systémem pro obnovení hesla, MFA aplikací, nebo adresářovou službou. U desktopových aplikací Windows mohou mít vliv lokální práva, síťová připojení, a statusy verzí. Test, který se dívá jen na formulář v prohlížeči, nedokáže spolehlivě odhalit takové integrační problémy.

Proto by měl tým před zahájením jakékoli automatizace testů definovat, co znamená úspěšné přihlášení v daném systému. Stačí viditelná domovská stránka? Nebo je třeba zkontrolovat, zda byl načten správný výběr nájemce, zda je role uživatele správná, a zda je skutečně možná první chráněná akce? Pro skladový portál by to byl například přístup k příjmu zboží. Pro dispečerský systém by to mohlo být uvolnění trasy.

Automatické testování přihlašovacího procesu: od modelu pracovního postupu k testovacímu případu

Dobrým výchozím bodem není skript, ale model pracovního postupu. Přihlášení lze popsat jako sekvenci jasných stavů: odhlášen, přihlašovací údaje odeslány, identita potvrzena, vyžadována MFA, přihlášen, relace vypršela, nebo účet zablokován. Každý stav zahrnuje povolené akce a očekávané odpovědi systému.

Z tohoto modelu vznikají testovací případy s obchodní hodnotou. Standardní pozitivní případ sem patří, ale i nesprávná hesla, neexistující uživatelské účty, a vypršelé resetovací odkazy. Důležitá je zde očekávaná zpětná vazba. V případě chybných přihlašovacích údajů by aplikace neměla prozrazovat, zda e-mailová adresa existuje. Test proto kontroluje nejen to, zda se zobrazí chyba, ale i to, zda její text a chování neposkytují zbytečné náznaky.

Ochranné mechanismy proti opakovaným neúspěšným pokusům jsou obzvlášť relevantní. Po definovaném počtu nesprávných zadání může být účet dočasně zablokován. Automatizovaný test musí zkontrolovat, zda zablokování skutečně nastoupí, jak dlouho trvá, a zda legitimní uživatel následně získá zpět kontrolovaný přístup. Zde je potřeba přesnost: test, který záměrně blokuje produkční účty, vytváří více problémů, než řeší. Takové scénáře patří do samostatného testovacího prostředí se speciálně vytvořenými účty.

Samostatné zvážení MFA, obnovení hesla, a Single Sign-On

Vícefaktorová autentizace není drobný detail na konci přihlášení. Mění pracovní postup. Test musí rozpoznat, že po heslu se vyžaduje další potvrzení, a musí zmapovat úspěšné i odmítnuté potvrzení. U časově založených jednorázových kódů testovací prostředí vyžaduje kontrolované zacházení s časem a tajemstvími. V mnoha případech je testovací metoda poskytovaná poskytovatelem identity smysluplnější než rekonstrukce skutečného mobilního telefonu.

Obnovení hesla a Single Sign-On by měly také dostat vlastní testovací trasy. Při obnovení záleží na přenosu zprávy, jedinečnosti odkazu, době platnosti, a následném přihlášení s novým heslem. U SSO je rozhodující, zda aplikace správně vytvoří relaci a čistě převezme role po návratu od poskytovatele identity.

CAPTCHA tvoří zvláštní případ. Mají za cíl zpomalit automatizované útoky a neměly by být obcházeny prostřednictvím automatizace testů. Místo toho je smysluplná testovací konfigurace, oficiální testovací klíč, nebo zabezpečená výjimka pro testovací prostředí. Oklamávání bezpečnostních kontrol jen proto, aby test zobrazil zelený výsledek, není strategií kvality.

Výběr vhodné technické vrstvy testu

Ne každý test přihlášení musí probíhat přes skutečný prohlížeč. API testy mohou ověřit, zda tokeny, relace, chybová hlášení, a pravidla zablokování fungují správně. Jsou rychlé a pomáhají najít chyby blízko autentizační logiky. Prohlížečové testy naopak ukazují, zda pole, přesměrování, cookies, SameSite nastavení, a viditelné stavy do sebe zapadají ve skutečném pracovním postupu uživatele.

Pro kritické aplikace je smysluplná kombinace. Několik end-to-end testů kontroluje kompletní cestu pomocí prohlížeče. Pod tím cílené API a integrační testy zajišťují varianty. Toto snižuje dobu běhu a falešné poplachy. Kdo testuje každou představitelnou kombinaci výhradně v prohlížeči, často skončí s pomalou testovací sadou, jejíž údržba spotřebuje více času, než ušetří.

Pro desktopový software platí podobný princip. Automatizovaný test by neměl jen kontrolovat, zda se okno otevře. Musí určit, zda po přihlášení existuje správné datové spojení, zda jsou práva uživatele aktivní, a zda je přístupná centrální pracovní maska. Toto je obzvlášť relevantní pro aplikace ve skladu nebo výrobě, protože pracoviště mohou mít různé síťové podmínky, připojení skenerů, nebo lokální konfigurace.

Bezpečné a opakovatelné zacházení s testovacími daty

Testy přihlášení nevyhnutelně pracují s přihlašovacími údaji. Produkční účty zaměstnanců, skutečná zákaznická data, nebo MFA tajemství však nekontrolovaně nepatří do testovacích skriptů, deníků, a snímků obrazovky. Testovací účty musí být jasně označené, minimálně privilegované, a automaticky obnovitelné. Hesla a tokeny jsou poskytovány prostřednictvím bezpečné správy tajemství namísto uložení ve zdrojovém kódu.

Stejně důležité je čištění po testovacím běhu. Pokud test vytvoří nové relace, auditní záznamy, nebo zablokované účty, testovací prostředí se musí vrátit do definovaného počátečního stavu. Jinak test v pondělí selže jednoduše proto, že běh z pátku zanechal vedlejší účinky.

Pro firmy s důvěrnými aplikacemi je rozhodující i místo provedení. Snímky obrazovky přihlašovacích masek, testovací videa, a technické deníky mohou obsahovat citlivé informace. Samostatně hostovaná testovací infrastruktura jako COCO zde může mít smysl, protože testovací data, provedení, a důkazy zůstávají pod vlastní kontrolou. Zda je to nutné, závisí na potřebách ochrany, smluvních situacích, a interních směrnicích. Samostatná infrastruktura není automaticky nejekonomičtější volbou pro každou aplikaci.

Generování důkazů, nejen zelených značek

Testovací zpráva by měla pro QA, vývoj, a obchodní oddělení učinit srozumitelným, co bylo testováno. Zelený status bez kontextu moc nepomůže, pokud vydání později vyvolá otázky. Užitečné jsou proto časové značky, použité testovací prostředí, testovací účet, relevantní kroky, snímky obrazovky v případě chyb, a jasná chybová zpráva v běžném jazyce.

V tomto kontextu se samotné sbírání důkazů nesmí stát problémem ochrany dat. Hesla, jednorázové kódy, ID relací, a osobní údaje musí být v denících maskovány. U snímků obrazovky může být nutné rozmazat určité oblasti. Tato pravidla by měla být součástí testovací architektury, ne ruční dodatečnou úpravou po incidentu.

Co by měly týmy automatizovat jako první

Priorita se řídí rizikem a frekvencí používání. Nejprve přichází standardní přihlášení pro nejdůležitější role, chybné přihlašovací údaje, odhlášení, a vypršení relace. Poté následují pravidla zablokování, obnovení hesla, MFA, a změny rolí. SSO, speciální nájemci, nebo vzácné cesty výjimek mohou následovat později, pokud jejich selhání okamžitě nezastaví provoz.

Testy patří do procesu vydávání. Změny v přihlašovacích formulářích, cookies, oprávněních, nebo konfiguraci poskytovatele identity by měly spustit příslušnou testovací sadu předtím, než verze přejde do produkce. Kromě toho se vyplatí plánovaný běh v realistickém prostředí, například po změnách infrastruktury nebo obnovení certifikátů. Toto najde problémy, které nejsou viditelné v izolovaném vývojovém prostředí.

Nakonec nejlepší test přihlášení není ten s nejvíce kliknutími. Je to ten, který včas odhalí skutečné selhání, srozumitelně ho zdokumentuje, a stále může být spolehlivě proveden při další změně. Kdo zachází s přihlášením jako s jasně modelovaným obchodním procesem, chrání víc než jen formulář. Chrání přístup k práci, která za ním čeká.