Menu

Jak testować aplikacje domeny bankowej: kompletny przewodnik po testowaniu BFSI

how test banking domain applications

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Kompletny przewodnik po testowaniu aplikacji bankowej: Proces testowania BFSI (bankowość, usługi finansowe i ubezpieczenia) i porady

Aplikacje bankowe to jedne z najbardziej złożonych aplikacji we współczesnej branży tworzenia i testowania oprogramowania.

Co sprawia, że ​​aplikacje bankowe są tak złożone? Jakie podejście należy zastosować, aby przetestować złożone przepływy pracy związane z aplikacjami bankowymi?

W tym artykule będziemy podkreślać różne etapy i techniki związane z testowaniem aplikacji bankowych.

Jak testować aplikacje bankowe

Czego się nauczysz:

Jak testować aplikacje bankowe?

Różne funkcje wykonywane przez aplikacje bankowe to:

Funkcje-banków

Najpierw przyjrzyjmy się cechom aplikacji bankowej:

  • Wielowarstwowa funkcjonalność obsługująca tysiące jednoczesnych sesji użytkowników
  • Integracja na dużą skalę: Zazwyczaj aplikacja bankowa integruje się z wieloma innymi aplikacjami, takimi jak narzędzie Bill Pay i rachunki handlowe
  • Złożone przepływy pracy w biznesie
  • Przetwarzanie w czasie rzeczywistym i wsadowo
  • Wysoki wskaźnik transakcji na sekundę
  • Bezpieczne transakcje
  • Solidna sekcja raportowania umożliwiająca śledzenie codziennych transakcji
  • Silny audyt w celu rozwiązywania problemów klientów
  • Ogromny system przechowywania
  • Zarządzanie po awarii / przywracaniu.

Wyżej wymienione dziesięć punktów to najważniejsze cechy aplikacji bankowej.

Aplikacje bankowe mają wiele poziomów związanych z wykonywaniem operacji.

Na przykład , do Aplikacja bankowa może mieć:

  • Serwer sieciowy do interakcji z użytkownikami końcowymi za pośrednictwem przeglądarki
  • Środkowa warstwa, aby sprawdzić poprawność danych wejściowych i wyjściowych dla serwera WWW
  • DataBase do przechowywania danych i procedur
  • Procesor transakcji, którym może być komputer mainframe o dużej pojemności lub jakikolwiek inny system starszej generacji, umożliwiający wykonywanie bilionów transakcji na sekundę.

Jeśli mówimy o testowaniu aplikacji bankowych, wymaga to Kompleksowa metodologia testowania obejmująca wiele technik testowania oprogramowania w celu zapewnienia:

  • Całkowite pokrycie wszystkich bankowych przepływów pracy i wymagań biznesowych
  • Funkcjonalny aspekt aplikacji
  • Aspekt bezpieczeństwa aplikacji
  • Integralność danych
  • Konkurencja
  • Doświadczenie użytkownika

Co sprawia, że ​​aplikacje bankowe są tak złożone?

  • Oprogramowanie bankowe zajmuje się głównie poufnymi danymi finansowymi, dlatego jego działanie powinno być wolne od błędów i bezpieczne.
  • Deweloperzy wolą skomplikowany projekt do tworzenia tych aplikacji, aby zapewnić, że aplikacja działa w pożądany, bezpieczny sposób.
  • Bankowość to stale zmieniający się świat. Obecnie usługi bankowe są udostępniane klientom za pośrednictwem różnych kanałów, takich jak oddziały stacjonarne, bankomaty, bankowość internetowa i obsługa klienta.
  • Wraz z pojawieniem się technologii wiele portfeli zalało rynki, które łączą się z systemami bankowymi w celu przeprowadzania transakcji finansowych.
  • Oczekuje się również, że bankowość będzie działać 24 godziny na dobę, 7 dni w tygodniu, z wysoką wydajnością. Aktualizacje oprogramowania, natychmiastowe poprawki itp. Nie mogą wpływać na tę dostępność.
  • Duży wpływ na świat bankowy mają również ciągłe zmiany wprowadzane przez rząd w postaci przepisów bankowych. Wszelkie zmiany w strukturze podatkowej mają również wpływ na system bankowy.
  • System bankowy wymaga również aktualizacji w zakresie nowych technologii. Analityka danych, taka jak przetwarzanie dużych danych i wyciąganie instynktów z dużych zbiorów danych za pomocą nauki o danych, zyskuje na popularności w świecie bankowym.

Powyższe punkty komplikują system bankowy dla programistów, którzy mogą tworzyć wokół niego aplikacje.

Znaczenie testowania aplikacji bankowej

  • Testowanie aplikacji bankowej zapewnia, że ​​wszystkie działania są nie tylko dobrze wykonane, ale także pozostają chronione i zabezpieczone.
  • Oprogramowanie bankowe jest skomplikowane i ma tysiące zależności, a proces testowania wymaga więcej czasu, zasobów i ciągłego monitorowania.
  • Ponieważ w grę wchodzą finanse, należy ściśle przestrzegać wytycznych. Zarówno testerzy, jak i programiści powinni mieć dobrą znajomość domeny.
  • Co najważniejsze, należy zapewnić prawidłowe egzekwowanie prawa i przepisów w transakcjach finansowych. Można to zapewnić tylko poprzez testowanie.
  • Ważne jest również, aby upewnić się, że aplikacja i infrastruktura, na której została wdrożona, są w stanie obsłużyć obciążenie, zwłaszcza w godzinach szczytu, bez powodowania jakichkolwiek zakłóceń. Można to zapewnić, wykonując testy wydajności.
  • W dzisiejszym cyfrowym świecie jedyną rzeczą, która dotyczy wszystkich, jest bezpieczeństwo. Aplikacje bankowe i transakcje finansowe, które są w nich dokonywane, muszą być zabezpieczone przed próbami włamania. Można to zapewnić, wykonując testy bezpieczeństwa. Testy bezpieczeństwa pomagają egzekwować standardy branżowe w celu zabezpieczenia transakcji finansowych.
  • Ważne jest również, aby upewnić się, że różne moduły aplikacji bankowej są odpowiednio zintegrowane i osiągają cel klienta. Testowanie integracji systemu pomaga osiągnąć to zadanie.

Przepływ pracy przy testowaniu aplikacji bankowych

Typowe etapy testowania aplikacji bankowych są pokazane w poniższym procesie roboczym. Każdy etap będziemy omawiać indywidualnie.

To jest model Waterfall testowania aplikacji.

Testowanie aplikacji bankowych

1) Zbieranie wymagań

Faza zbierania wymagań obejmuje dokumentację wymagań jako specyfikacje funkcjonalne lub przypadki użycia. Wymagania są zbierane zgodnie z potrzebami klientów i dokumentowane przez ekspertów bankowych lub analityków biznesowych.

Gromadzenie wymagań

Eksperci są zaangażowani w pisanie wymagań dotyczących więcej niż jednego tematu, ponieważ sama bankowość ma wiele subdomen, a jedna pełnoprawna aplikacja bankowa będzie integrować wszystkie te domeny.

Na przykład, Aplikacja bankowa może mieć oddzielne moduły dla przelewów, kart kredytowych, raportów, rachunków pożyczkowych, płatności rachunków, handlu itp.

# 2) Przegląd wymagań

Rezultat zbierania wymagań jest weryfikowany przez wszystkich interesariuszy, takich jak inżynierowie kontroli jakości, kierownicy ds. Rozwoju i równorzędni analitycy biznesowi.

Przegląd wymagań

Sprawdzają krzyżowo, czy ani istniejący biznesowy przepływ pracy, ani nowe przepływy pracy nie są naruszane. Wszystkie wymagania są weryfikowane i walidowane. Dalsze działania i poprawki dokumentów wymagań są wykonywane na tej samej podstawie.

# 3) Przygotowanie scenariusza biznesowego

Na tym etapie inżynierowie ds. Zapewnienia jakości wyprowadzają scenariusze biznesowe z dokumentów wymagań (specyfikacje funkcji lub przypadki użycia); Scenariusze biznesowe są opracowywane w taki sposób, aby pokryć wszystkie wymagania biznesowe. Scenariusze biznesowe to scenariusze wysokiego poziomu bez żadnych szczegółowych kroków.

Ponadto te scenariusze biznesowe są przeglądane przez analityków biznesowych w celu zapewnienia spełnienia wszystkich wymagań biznesowych. BA łatwiej jest przeglądać scenariusze wysokiego poziomu, niż przeglądać szczegółowe przypadki testowe niskiego poziomu.

Na przykład , klient otwierający stałą lokatę w interfejsie bankowości cyfrowej może być scenariuszem biznesowym. Podobnie możemy mieć różne scenariusze biznesowe związane z tworzeniem rachunków bankowych netto, depozytami online, przelewami online itp.

# 4) Testowanie funkcjonalne

Na tym etapie przeprowadzane są testy funkcjonalne i wykonywane są zwykłe czynności testowania oprogramowania, takie jak:

Przygotowanie przypadku testowego: Na tym etapie przypadki testowe są wyprowadzane ze scenariuszy biznesowych, jeden scenariusz biznesowy prowadzi do kilku pozytywnych przypadków testowych i negatywnych przypadków testowych. Generalnie narzędzia używane na tym etapie to Microsoft Excel, Dyrektor Testów czy Centrum Jakości.

Przegląd przypadku testowego: Recenzje przez innych inżynierów ds. Kontroli jakości

Przypadek testowy Wykonanie: Wykonywanie przypadków testowych może być ręczne lub automatyczne z wykorzystaniem narzędzi takich jak QC, QTP itp.

Testowanie funkcjonalne aplikacji bankowej różni się znacznie od zwykłego testowania oprogramowania. Ponieważ aplikacje te działają z pieniędzmi klientów i poufnymi danymi finansowymi, muszą zostać dokładnie przetestowane. Żaden ważny scenariusz biznesowy nie powinien zostać uwzględniony.

Ponadto zasób QA, który testuje aplikację, powinien mieć podstawową wiedzę z dziedziny bankowości.

# 5) Testowanie bazy danych

Aplikacja bankowa obejmuje złożoną transakcję, która jest wykonywana zarówno na poziomie interfejsu użytkownika, jak i bazy danych, dlatego testowanie bazy danych jest równie ważne jak testowanie funkcjonalne. Baza danych jest skomplikowana i stanowi całkowicie odrębną warstwę w aplikacji, dlatego jej testowanie jest przeprowadzane przez specjalistów od baz danych. Wykorzystuje takie techniki jak:

  • Ładowanie danych
  • Migracja bazy danych
  • Testowanie schematu bazy danych i typów danych
  • Testowanie reguł
  • Testowanie procedur składowanych i funkcji
  • Testowanie wyzwalaczy
  • Integralność danych

Głównym celem testowania baz danych jest upewnienie się, że:

  • Aplikacja może przechowywać i pobierać dane z bazy danych bez utraty danych.
  • Zakończone transakcje powinny zostać zatwierdzone, a przerwane transakcje są cofane, aby uniknąć wszelkich niezgodności przechowywanych danych.
  • Tylko autoryzowane aplikacje i użytkownicy mają dostęp do bazy danych i tabel bazowych.

Istnieją przede wszystkim trzy sposoby testowania baz danych:

  • Testowanie strukturalne
  • Testy funkcjonalności
  • Testy niefunkcjonalne

Testowanie strukturalne

Obejmuje testowanie obiektów bazy danych, takich jak bazy danych, schematy, tabele, widoki, wyzwalacze, kontrole dostępu itp. Zapewnienie, że typy danych w tabelach są zsynchronizowane z odpowiednimi zmiennymi w aplikacji. Sprawdzanie poprawności danych i integralności referencyjnej w tabelach.

Na przykład, Pole kwoty w aplikacji powinno mieć w tabeli typ danych dziesiętny / zmiennoprzecinkowy.

- Aby zachować zgodność ze standardami, użytkownikom należy zapewnić kontrolę dostępu poprzez widoki.

Testy funkcjonalności

Polega na testowaniu baz danych, które spełniają wymagania użytkowników. Są na to dwa sposoby: testowanie czarnoskrzynkowe i testowanie białoskrzynkowe.

Na przykład, Kiedy wykonujemy przelew internetowy, należy obciążyć konto nadawcy i zasilić konto odbiorcy dokładnie taką samą kwotą. Jeśli transakcja się nie powiedzie, wszystkie transakcje powinny zostać cofnięte, a rachunek nadawcy nie powinien zostać obciążony ani uznany z powrotem.

Testy niefunkcjonalne

Obejmuje testy obciążenia i obciążenia oraz optymalizację wydajności. Testowanie obciążenia pomaga w identyfikacji największej liczby transakcji, które można wykonać jednocześnie, bez wpływu na wydajność bazy danych.

Na przykład, Na podstawie danych wejściowych z testów obciążenia i testów warunków skrajnych aplikacje bankowe mogą zdecydować o dodaniu większej ilości zasobów do swoich aplikacji w godzinach szczytu pracy i zmniejszeniu ich poza godzinami pracy. Pomaga to bankowi w optymalnym wykorzystaniu zasobów i oszczędzaniu pieniędzy.

# 6) Testowanie bezpieczeństwa

Testowanie bezpieczeństwa jest zwykle ostatnim etapem cyklu testowania. Warunkiem rozpoczęcia testów bezpieczeństwa jest zakończenie testów funkcjonalnych i niefunkcjonalnych. Testowanie bezpieczeństwa jest jednym z głównych etapów całego cyklu testowania aplikacji, ponieważ ten etap zapewnia zgodność aplikacji ze standardami federalnymi i branżowymi.

Ze względu na charakter przenoszonych danych aplikacje bankowe są bardzo wrażliwe i stanowią główny cel hakerów i oszukańczych działań. Testy bezpieczeństwa zapewniają, że aplikacja nie ma takiej luki w zabezpieczeniach sieci, która mogłaby ujawnić poufne dane intruzowi lub napastnikowi. Zapewnia również zgodność aplikacji ze standardami takimi jak OWASP.

Na tym etapie głównym zadaniem jest skanowanie całej aplikacji, które odbywa się za pomocą narzędzi takich jak IBM AppScan czy HP WebInspect (są to najpopularniejsze narzędzia).

Po zakończeniu skanowania publikowany jest raport skanowania. W tym raporcie fałszywie dodatnie są odfiltrowywane, a pozostałe luki są zgłaszane zespołowi programistycznemu, aby zaczął on naprawiać problemy w zależności od wagi każdego problemu.

Na tym etapie przeprowadza się również testy penetracyjne, aby ujawnić propagację błędów. Rygorystyczne testy bezpieczeństwa należy przeprowadzać na różnych platformach, sieciach i systemach operacyjnych.

Inny Ręczne narzędzia do testowania bezpieczeństwa używane są Proxy Paros , Http Watch , Apartament Burp , i Ufortyfikować.

Głównym celem testów bezpieczeństwa jest wskazanie wszelkich luk w zabezpieczeniach, które może mieć aplikacja.

Testy bezpieczeństwa testują aplikację pod kątem:

  • Jakikolwiek atak zewnętrzny lub próba włamania się do aplikacji w złym zamiarze.
  • Każda luka w aplikacji może zostać wykorzystana, powodując straty danych lub pieniądze.
  • Wszelkie luki w sieci, serwerach i stacjach roboczych obsługujących aplikację.

Poniżej przedstawiono różne rodzaje testów bezpieczeństwa:

Testowanie podatności: Opracowywany i wykonywany jest zautomatyzowany program sprawdzający różne podatności.

Skanowanie bezpieczeństwa: Ten wariant polega na badaniu luk w zabezpieczeniach sieci i systemu, dostarczaniu rozwiązań ograniczających związane z nimi ryzyko.

Testy penetracyjne: Ten wariant testowania bezpieczeństwa imituje próbę włamania w celu wykrycia luk i luk, które w przeciwnym razie mogłyby uzyskać dostęp do bazy danych lub danych aplikacji.

Audyt bezpieczeństwa: Obejmuje audyt aplikacji i powiązanych sieci pod kątem wszelkich luk w zabezpieczeniach.

Ocena ryzyka: Ten wariant przeprowadza analizę w celu oceny poziomu ryzyka w przypadku wykorzystania luki lub luki w złym zamiarze. Takie ryzyko można podzielić na niskie, średnie i wysokie. W oparciu o poziom ryzyka zespół testujący zaleca odpowiednie środki w celu zmniejszenia lub uniknięcia ryzyka.

Etyczne hakowanie: Jest to wykonywane przez organizację w swoich systemach w celu zidentyfikowania luk, które mogą zostać wykorzystane w jej aplikacji lub sieci. Celem tego rodzaju hakowania nie jest kradzież ani uszkodzenie aplikacji lub sieci.

Ocena postawy: Jest to ocena zbiorcza obejmująca skanowanie bezpieczeństwa, ocenę ryzyka i etyczne hakowanie.

Wstrzyknięcie SQL: SQL Injection może służyć do uzyskania dostępu do bazy danych serwera. Testowanie ma na celu upewnienie się, że kod działa poprawnie, który wykonuje zapytania w bazie danych na podstawie następujących danych wejściowych od użytkownika:

  • Wsporniki
  • Apostrofy
  • Przecinki
  • Cudzysłów

Inne etapy testowania aplikacji BFSI

Oprócz powyższych głównych etapów, mogą występować różne etapy, takie jak testowanie integracyjne, testowanie użyteczności, testowanie akceptacyjne użytkownika i testowanie wydajności.

Porozmawiajmy pokrótce również o tych etapach:

Testy integracyjne

Jak wiesz, w aplikacji bankowej może istnieć kilka różnych modułów, takich jak przelewy, płatności za rachunki, depozyty itp. W związku z tym opracowano wiele komponentów. W testowaniu integracyjnym wszystkie komponenty są zintegrowane i sprawdzone.

Test użyteczności

Test użyteczności

Aplikacja bankowa obsługuje szeroką gamę klientów. Niektórym z tych klientów może brakować umiejętności i świadomości wymaganych do wykonywania zadań bankowych za pośrednictwem aplikacji.

Dlatego aplikacja bankowa powinna zostać przetestowana pod kątem prostego i wydajnego projektu, aby była użyteczna dla różnych grup klientów. Im prostszy i łatwiejszy w użyciu interfejs, tym większa liczba klientów skorzysta z aplikacji bankowej.

Chodzi o zbadanie poziomu łatwości korzystania z aplikacji przez użytkowników biznesowych lub klientów banku. Testy te nie są wykonywane przez programistę ani testera, ale są wykonywane przez użytkowników biznesowych.

Na przykład, W dzisiejszych czasach wszyscy korzystają z aplikacji mobilnych. Aplikacja bankowa powinna być przyjazna dla użytkownika oraz łatwa do zrozumienia i używania przez użytkownika końcowego.

Rodzaje testów użyteczności

Testy porównawcze użyteczności: Jest to test porównawczy, w którym łatwość użycia jednej witryny lub aplikacji z inną. Celem takich testów jest zapewnienie użytkownikom jak najlepszych wrażeń.

Eksploracyjne testowanie użyteczności: Celem tego testu jest określenie, jakie funkcje powinna posiadać nowa aplikacja lub oprogramowanie, aby spełnić wymagania klienta banku.

Poniżej przedstawiono zalety i wady testów użyteczności

który z poniższych elementów zapewnia zdalny program, który wygląda i działa jak aplikacja lokalna?

Zalety:

  • Użytkownicy końcowi aplikacji są zwykle zaangażowani w testowanie, dzięki czemu uzyskuje się informacje zwrotne z pierwszej ręki.
  • Zamiast tracić czas na analizę i dyskusję na temat cech, które produkt powinien mieć lub nie, lepiej jest uzyskać informacje bezpośrednio od użytkownika końcowego.
  • Wcześniej możemy wykryć potencjalne problemy.

Niedogodności:

  • Ponieważ w testowanie zaangażowanych jest wielu użytkowników końcowych, ich opinie, jeśli nie są precyzyjne, mogą wpłynąć na wymaganie.
  • Może to mieć wpływ na kanał od użytkowników końcowych.

Test wydajności

Niektóre okresy, takie jak dzień wypłaty, koniec roku obrotowego, okres świąteczny, mogą przynieść zmiany lub wzrost zwykłego ruchu w aplikacji. Dlatego należy przeprowadzić dokładne testy wydajności, aby klienci nie byli narażeni na awarie wydajności.

Istotnym przykładem z przeszłości, w którym klienci banków byli osobiście dotknięci z powodu awarii wydajności, jest awaria IT w cyber poniedziałek NatWest i RBS, w której klienci mieli swoje karty debetowe i kredytowe, a transakcje w sklepach w kraju były odrzucane.

Testy akceptacyjne użytkowników

Odbywa się to poprzez zaangażowanie użytkowników końcowych w celu zapewnienia, że ​​aplikacja jest zgodna z rzeczywistymi scenariuszami i zostanie zaakceptowana przez użytkowników, jeśli zostanie uruchomiona.

W dzisiejszym scenariuszu większość projektów bankowych korzysta : Metodologie Agile / Scrum, RUP i Continuous Integration oraz pakiety narzędzi, takie jak Microsoft VSTS i Rational Tools.

Jak wspomnieliśmy powyżej o RUP, RUP oznacza Rational Unified Process, czyli iteracyjną metodologię tworzenia oprogramowania wprowadzoną przez IBM, która składa się z czterech faz, w których wykonywane są działania programistyczne i testowe.

Są cztery fazy
i) Początek
ii) Współpraca
iii) Budowa i
iv) Przejście

RUP szeroko obejmuje narzędzia IBM Rational.

Przykładowe przypadki testowe dla aplikacji bankowych

Przypadki testowe dla New Branch

  • Utwórz nową gałąź z prawidłowymi i nieprawidłowymi danymi testowymi.
  • Utwórz nowy oddział bez danych.
  • Utwórz nowy oddział z istniejącymi danymi oddziału.
  • Sprawdź opcje resetowania i anulowania.
  • Zaktualizuj szczegóły oddziału, podając prawidłowe i nieprawidłowe dane testowe.
  • Zaktualizuj szczegóły oddziału o istniejące dane testowe oddziału.
  • Sprawdź, czy można zapisać nową gałąź.
  • Sprawdź, czy opcja anulowania działa.
  • Sprawdź usunięcie gałęzi z zależnościami i bez.
  • Sprawdź, czy opcja wyszukiwania oddziałów działa.

Przypadki testowe dla nowej roli

  • Utwórz nową rolę z prawidłowymi i nieprawidłowymi danymi testowymi.
  • Utwórz nową rolę bez danych.
  • Sprawdź, czy można utworzyć nową rolę na podstawie istniejących danych testowych.
  • Sprawdź opis roli i typy ról.
  • Sprawdź, czy działa opcja anulowania i resetowania.
  • Sprawdź proces usuwania roli z zależnością i bez niej.
  • Sprawdź linki na stronie szczegółów roli.
  • Zweryfikuj login administratora bez danych testowych.
  • Sprawdź wszystkie linki do strony głównej dla roli administratora.
  • Sprawdź, czy administrator może zmienić hasło za pomocą ważnych i nieprawidłowych danych testowych.
  • Sprawdź, czy administrator wylogował się pomyślnie.

Przypadki testowe dla klientów i bankierów

  • Sprawdź, czy wszystkie linki odwiedzających i klientów działają poprawnie.
  • Zweryfikuj login klienta z ważnymi i nieprawidłowymi danymi testowymi.
  • Zweryfikuj login klienta bez żadnych danych.
  • Zweryfikuj login bankiera bez żadnych danych.
  • Zweryfikuj login bankiera z ważnymi lub nieprawidłowymi danymi testowymi.
  • Sprawdź, czy klient lub bankier może się pomyślnie wylogować.

Przypadki testowe dla nowych użytkowników

  • Sprawdź, czy można utworzyć nowego użytkownika z ważnymi i nieprawidłowymi danymi testowymi.
  • Utwórz nowego użytkownika z istniejącymi danymi testowymi gałęzi
  • Sprawdź, czy opcja anulowania i resetowania działa prawidłowo.
  • Zaktualizuj dane użytkownika, podając prawidłowe i nieprawidłowe dane testowe.
  • Sprawdź usunięcie nowego użytkownika.
  • sprawdź, czy nowego użytkownika można zweryfikować.
  • Sprawdź obowiązkowe parametry wejściowe.
  • Sprawdź opcjonalne parametry wejściowe.
  • Sprawdź, czy można utworzyć użytkownika bez parametrów opcjonalnych.

Przypadki testowe do tworzenia nowego konta

  • Utwórz nowe konto z ważnymi i nieprawidłowymi danymi użytkownika.
  • Sprawdź, czy można zaktualizować dane użytkownika.
  • Sprawdź, czy można zapisać nowego użytkownika.
  • Utwórz nowe konto z danymi istniejącego użytkownika.
  • Sprawdź, czy użytkownik może zdeponować kwotę na nowo utworzonym koncie (i zaktualizuj saldo).
  • Sprawdź, czy użytkownik może wypłacić kwotę z nowego konta (po wpłacie i zaktualizowaniu salda).
  • W przypadku wynagrodzenia sprawdź, czy konto ma nazwę firmy, a pozostałe dane podaje użytkownik.
  • Sprawdź, czy w przypadku konta dodatkowego podano numer konta podstawowego.
  • Zweryfikuj dane użytkownika podane w przypadku rachunku bieżącego.
  • W przypadku rachunku wspólnego zweryfikuj dostarczone dowody do rachunku wspólnego.
  • Sprawdź, czy jesteś w stanie utrzymać zerowe saldo na koncie wynagrodzeń.
  • Sprawdź, czy jesteś w stanie utrzymać saldo zerowe lub minimalne saldo konta pozapłacowego.
  • Sprawdź, czy nowy użytkownik może się pomyślnie wylogować.

Przypadki testowe dla aplikacji bankowości internetowej

  • Sprawdź, czy użytkownik może otworzyć witrynę banku.
  • Sprawdź, czy wszystkie linki w witrynie działają.
  • Sprawdź, czy użytkownik może utworzyć nowe konto.
  • Sprawdź, czy użytkownik może się zalogować przy użyciu ważnej i nieprawidłowej nazwy użytkownika i hasła.
  • Sprawdź, czy nazwa użytkownika lub hasło są puste podczas logowania, użytkownik nie powinien mieć możliwości logowania i wyświetla się komunikat ostrzegawczy.
  • Sprawdź, czy użytkownik może zmienić hasło.
  • Jeśli wprowadzony zostanie nieprawidłowy użytkownik lub hasło, zostanie wyświetlony odpowiedni komunikat o błędzie.
  • Użytkownicy z nieprawidłowym hasłem nie powinni mieć możliwości logowania.
  • Sprawdź, czy po wielokrotnych próbach zalogowania się przy użyciu nieprawidłowego hasła, użytkownikowi powinien zostać wyświetlony komunikat o błędzie i zablokowany.
  • Sprawdź, czy użytkownik jest w stanie wykonać kilka podstawowych transakcji.
  • Sprawdź, czy użytkownik może dodać beneficjenta z prawidłowymi i nieprawidłowymi danymi.
  • Sprawdź, czy użytkownik może usunąć beneficjenta.
  • Sprawdź, czy użytkownik może dokonywać transakcji dla nowo dodanego beneficjenta.
  • Po transakcji sprawdź, czy konta użytkownika i odbiorcy są zaktualizowane.
  • Sprawdź, czy użytkownik może wpisać kwotę w postaci dziesiętnej.
  • Sprawdź, czy użytkownik nie może wprowadzić liczb ujemnych w polu kwoty.
  • Sprawdź, czy użytkownik może wykonywać transakcje z saldem minimalnym lub bez niego.
  • Sprawdź, czy użytkownik może wykonać nowy RD.
  • Sprawdź, czy wyświetla się odpowiedni komunikat w przypadku transakcji z niewystarczającym saldem.
  • Sprawdź, czy użytkownik jest proszony o potwierdzenie przed wykonaniem jakiejkolwiek transakcji.
  • Sprawdź, czy potwierdzenie odbioru jest dostarczane dla każdej udanej transakcji.
  • Sprawdź, czy użytkownik może przesyłać pieniądze na wiele kont.
  • sprawdź, czy użytkownik może anulować transakcję.
  • Sprawdź, czy szczegóły konta odzwierciedlają również przeprowadzone transakcje finansowe.
  • Sprawdź, czy zaimplementowano funkcję limitu czasu.
  • sprawdź, czy w przypadku przekroczenia limitu czasu sesji użytkownik powinien się ponownie zalogować.
  • sprawdź, czy upłynął właściwy limit czasu sesji w przypadku braku aktywności.
  • sprawdź, czy podczas wykonywania transakcji użytkownik przechodzi w tryb bezpieczny.
  • Sprawdź, czy użytkownik może się pomyślnie wylogować.
  • Sprawdź opcje wyszukiwania i resetowania.

Wniosek

W tym artykule omówiliśmy jak skomplikowana może być aplikacja bankowa i jakie są typowe fazy związane z testowaniem aplikacji . Oprócz tego omówiliśmy również aktualne trendy w branży IT, w tym metodologie i narzędzia tworzenia oprogramowania.

Zapraszam do dzielenia się swoimi doświadczeniami lub pytaniami na ten temat!

rekomendowane lektury

^