Zautomatyzowane testowanie procesu logowania

Automatyczne testowanie procesu logowania staje się banalną kwestią dopiero wtedy, gdy działa. Jeśli zawodzi po wydaniu, pracownicy stają w obliczu początku zmiany, klienci znajdują się zablokowani poza portalem klienta, lub spedytorzy mają do czynienia z zablokowanym przetwarzaniem zamówień. Automatyczne testowanie procesu logowania nie oznacza więc po prostu wprowadzenia nazwy użytkownika i hasła do formularza. Oznacza wielokrotne sprawdzanie krytycznego dla biznesu punktu dostępu ze wszystkimi jego regułami, wyjątkami, i granicami bezpieczeństwa.

Dla wielu zespołów automatyzacja zaczyna się od pojedynczego pozytywnego przypadku testowego: wprowadzenia prawidłowych poświadczeń, potwierdzenia logowania, i zobaczenia strony głównej. Ma to sens, ale samo w sobie jest niewystarczające jako jedyny test. Błędy logowania często występują na krawędziach: przy wygasłych sesjach, zablokowanych kontach, nowej metodzie uwierzytelniania wieloskładnikowego, lub uprawnieniach, które przestały poprawnie obowiązywać po zmianie roli. Dokładnie te scenariusze muszą być objęte w zaplanowany sposób.

Dlaczego logowanie wymaga szczególnej dyscypliny testowej

Logowanie jest jednocześnie funkcją bezpieczeństwa, interfejsem technicznym, i punktem wejścia do przepływu pracy. Błąd może być zbyt łagodny, pozwalając na nieautoryzowany dostęp. Odwrotnie, może być też zbyt surowy, blokując autoryzowane osoby. Oba są kosztowne: pierwszy przypadek tworzy ryzyka dla danych i zgodności, podczas gdy drugi powoduje przestoje, obciążenie wsparcia, i gorączkowe rozwiązania awaryjne.

Dla aplikacji webowych w grę wchodzą dodatkowe zależności. Logowanie często komunikuje się z dostawcą tożsamości, systemem pocztowym do resetowania haseł, aplikacją MFA, lub usługą katalogową. Dla aplikacji desktopowych Windows wpływ mogą wywierać lokalne uprawnienia, połączenia sieciowe, i statusy wersji. Test, który patrzy tylko na formularz w przeglądarce, nie może niezawodnie wykryć takich problemów integracyjnych.

Dlatego przed rozpoczęciem jakiejkolwiek automatyzacji testów zespół powinien zdefiniować, co oznacza udane logowanie w danym systemie. Czy wystarczy widoczna strona główna? Czy trzeba sprawdzić, czy załadowano prawidłowy wybór najemcy, czy rola użytkownika jest poprawna, i czy pierwsza chroniona akcja jest faktycznie możliwa? Dla portalu magazynowego byłby to na przykład dostęp do przyjęcia towaru. Dla systemu dyspozytorskiego mogłoby to być zwolnienie trasy.

Automatyczne testowanie procesu logowania: od modelu przepływu pracy do przypadku testowego

Dobrym punktem wyjścia nie jest skrypt, lecz model przepływu pracy. Logowanie można opisać jako sekwencję jasnych stanów: wylogowany, poświadczenia przesłane, tożsamość potwierdzona, wymagane MFA, zalogowany, sesja wygasła, lub konto zablokowane. Każdy stan obejmuje dozwolone akcje i oczekiwane odpowiedzi systemu.

Z tego modelu wyłaniają się przypadki testowe o wartości biznesowej. Standardowy przypadek pozytywny należy tu, ale nieprawidłowe hasła, nieistniejące konta użytkowników, i wygasłe linki do resetowania też. Ważna jest tu oczekiwana informacja zwrotna. W przypadku błędnych poświadczeń aplikacja nie powinna ujawniać, czy adres e-mail istnieje. Test sprawdza więc nie tylko, czy wyświetlany jest błąd, lecz także, czy jego tekst i zachowanie nie dają niepotrzebnych wskazówek.

Mechanizmy ochrony przed powtarzającymi się nieudanymi próbami są szczególnie istotne. Po określonej liczbie błędnych wpisów konto może zostać tymczasowo zablokowane. Zautomatyzowany test musi sprawdzić, czy blokada faktycznie wchodzi w życie, jak długo trwa, i czy uprawniony użytkownik następnie odzyskuje kontrolowany dostęp. Potrzebna jest tu precyzja: test, który celowo blokuje konta produkcyjne, tworzy więcej problemów niż rozwiązuje. Takie scenariusze należą do oddzielnego środowiska testowego ze specjalnie utworzonymi kontami.

Osobne rozważenie MFA, resetowania hasła, i Single Sign-On

Uwierzytelnianie wieloskładnikowe nie jest drobnym szczegółem na końcu logowania. Zmienia przepływ pracy. Test musi rozpoznać, że po haśle wymagane jest dodatkowe potwierdzenie, i musi odwzorować zarówno udane, jak i odrzucone potwierdzenie. Dla kodów jednorazowych opartych na czasie środowisko testowe wymaga kontrolowanej obsługi czasu i sekretów. W wielu przypadkach metoda testowa dostarczona przez dostawcę tożsamości jest sensowniejsza niż odtwarzanie prawdziwego telefonu komórkowego.

Resetowanie hasła i Single Sign-On powinny również otrzymać własne ścieżki testowe. Dla resetu liczy się przesłanie wiadomości, unikalność linku, okres ważności, i następujące logowanie z nowym hasłem. Dla SSO kluczowe jest, czy aplikacja poprawnie tworzy sesję i czysto przejmuje role po powrocie od dostawcy tożsamości.

CAPTCHA stanowi przypadek specjalny. Mają one na celu spowolnienie zautomatyzowanych ataków i nie powinny być omijane przez automatyzację testów. Zamiast tego sensowna jest konfiguracja testowa, oficjalny klucz testowy, lub zabezpieczony wyjątek dla środowiska testowego. Oszukiwanie kontroli bezpieczeństwa tylko po to, aby test pokazał zielony wynik, nie jest strategią jakości.

Wybór właściwej warstwy technicznej testu

Nie każdy test logowania musi przebiegać przez prawdziwą przeglądarkę. Testy API mogą weryfikować, czy tokeny, sesje, komunikaty błędów, i reguły blokady działają poprawnie. Są szybkie i pomagają znaleźć błędy blisko logiki uwierzytelniania. Testy przeglądarkowe natomiast pokazują, czy pola, przekierowania, ciasteczka, ustawienia SameSite, i widoczne stany pasują do siebie w rzeczywistym przepływie pracy użytkownika.

Dla aplikacji krytycznych sensowna jest kombinacja. Kilka testów end-to-end sprawdza kompletną ścieżkę przy użyciu przeglądarki. Pod tym, ukierunkowane testy API i integracyjne zabezpieczają warianty. To zmniejsza czas wykonania i fałszywe alarmy. Każdy, kto testuje każdą możliwą kombinację wyłącznie w przeglądarce, często kończy z powolnym zestawem testów, którego utrzymanie pochłania więcej czasu niż oszczędza.

Dla oprogramowania desktopowego obowiązuje podobna zasada. Zautomatyzowany test nie powinien tylko sprawdzać, czy okno się otwiera. Musi określić, czy po logowaniu istnieje prawidłowe połączenie danych, czy uprawnienia użytkownika są aktywne, i czy centralna maska robocza jest dostępna. Jest to szczególnie istotne dla aplikacji w magazynie lub produkcji, ponieważ stanowiska pracy mogą mieć różne warunki sieciowe, połączenia skanerów, lub lokalne konfiguracje.

Bezpieczna i powtarzalna obsługa danych testowych

Testy logowania nieuchronnie pracują z poświadczeniami. Produkcyjne konta pracowników, prawdziwe dane klientów, lub sekrety MFA nie powinny jednak niekontrolowanie trafiać do skryptów testowych, dzienników, i zrzutów ekranu. Konta testowe muszą być jasno oznaczone, minimalnie uprzywilejowane, i automatycznie przywracalne. Hasła i tokeny są dostarczane przez bezpieczne zarządzanie sekretami, zamiast być przechowywane w kodzie źródłowym.

Równie ważne jest czyszczenie po przebiegu testu. Jeśli test tworzy nowe sesje, wpisy audytowe, lub zablokowane konta, środowisko testowe musi powrócić do zdefiniowanego stanu początkowego. W przeciwnym razie test w poniedziałek zawiedzie po prostu dlatego, że przebieg z piątku pozostawił skutki uboczne.

Dla firm z poufnymi aplikacjami decydujące jest też miejsce wykonania. Zrzuty ekranu masek logowania, nagrania testowe, i dzienniki techniczne mogą zawierać wrażliwe informacje. Samodzielnie hostowana infrastruktura testowa taka jak COCO może mieć tu sens, ponieważ dane testowe, wykonanie, i dowody pozostają pod własną kontrolą. Czy jest to konieczne, zależy od potrzeb ochrony, sytuacji umownych, i wewnętrznych wytycznych. Oddzielna infrastruktura nie jest automatycznie najbardziej ekonomicznym wyborem dla każdej aplikacji.

Generowanie dowodów, nie tylko zielonych znaczników

Raport testowy powinien uczynić zrozumiałym dla QA, rozwoju, i działu biznesowego, co zostało przetestowane. Zielony status bez kontekstu niewiele pomaga, jeśli wydanie wywołuje później pytania. Przydatne są więc znaczniki czasu, użyte środowisko testowe, konto testowe, istotne kroki, zrzuty ekranu w przypadku błędów, i jasny komunikat błędu w codziennym języku.

W tym kontekście zbieranie dowodów samo w sobie nie może stać się problemem ochrony danych. Hasła, kody jednorazowe, identyfikatory sesji, i dane osobowe muszą być zamaskowane w dziennikach. Dla zrzutów ekranu może być konieczne zamazanie pewnych obszarów. Te reguły powinny być częścią architektury testów, nie ręczną poprawką po incydencie.

Co zespoły powinny automatyzować najpierw

Priorytet kierowany jest ryzykiem i częstotliwością użycia. Najpierw przychodzi standardowe logowanie dla najważniejszych ról, błędne poświadczenia, wylogowanie, i wygaśnięcie sesji. Następnie reguły blokady, resetowanie hasła, MFA, i zmiany ról. SSO, specjalni najemcy, lub rzadkie ścieżki wyjątków mogą nastąpić później, pod warunkiem że ich niepowodzenie nie zatrzymuje natychmiast operacji.

Testy należą do procesu wydawniczego. Zmiany w formularzach logowania, ciasteczkach, uprawnieniach, lub konfiguracji dostawcy tożsamości powinny wyzwalać odpowiedni zestaw testów przed przejściem wersji do produkcji. Dodatkowo opłaca się zaplanowany przebieg w realistycznym środowisku, na przykład po zmianach infrastruktury lub odnowieniach certyfikatów. To znajduje problemy, które nie są widoczne w izolowanym środowisku deweloperskim.

Ostatecznie najlepszy test logowania to nie ten z największą liczbą kliknięć. To ten, który wykrywa rzeczywiste niepowodzenie wcześnie, dokumentuje je zrozumiale, i wciąż może być niezawodnie wykonywany przy następnej zmianie. Każdy, kto traktuje logowanie jako jasno zamodelowany proces biznesowy, chroni więcej niż tylko formularz. Chroni dostęp do pracy, która za nim czeka.