Μενού

Τρόπος δοκιμής εφαρμογών τραπεζικού τομέα: Ένας πλήρης οδηγός δοκιμών BFSI

how test banking domain applications

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Ένας πλήρης οδηγός για τη δοκιμή της τραπεζικής εφαρμογής: BFSI (Τραπεζικές, χρηματοοικονομικές υπηρεσίες και ασφάλεια) Διαδικασία δοκιμής και συμβουλές

Οι τραπεζικές εφαρμογές είναι μια από τις πιο περίπλοκες εφαρμογές στη σημερινή βιομηχανία ανάπτυξης λογισμικού και δοκιμών.

Τι κάνει τις τραπεζικές εφαρμογές τόσο περίπλοκες; Ποια προσέγγιση πρέπει να ακολουθηθεί για να δοκιμαστούν οι περίπλοκες ροές εργασίας που εμπλέκονται στις τραπεζικές εφαρμογές;

Σε αυτό το άρθρο, θα επισημάνουμε διάφορα στάδια και τεχνικές που εμπλέκονται στη δοκιμή τραπεζικών εφαρμογών.

Πώς να δοκιμάσετε τραπεζικές εφαρμογές

Τι θα μάθετε:

Πώς να δοκιμάσετε τις τραπεζικές εφαρμογές;

Διάφορες λειτουργίες που εκτελούνται από τις τραπεζικές εφαρμογές είναι:

Λειτουργίες των τραπεζών

Ας κατανοήσουμε πρώτα τα χαρακτηριστικά μιας Τραπεζικής Εφαρμογής:

  • Λειτουργικότητα πολλαπλών επιπέδων για την υποστήριξη χιλιάδων ταυτόχρονων περιόδων σύνδεσης χρηστών
  • Ενσωμάτωση μεγάλης κλίμακας: Συνήθως, μια τραπεζική εφαρμογή ενοποιείται με πολλές άλλες εφαρμογές όπως το Bill Pay και οι λογαριασμοί συναλλαγών
  • Σύνθετες επιχειρηματικές ροές εργασίας
  • Επεξεργασία σε πραγματικό χρόνο και παρτίδα
  • Το υψηλό ποσοστό συναλλαγών ανά δευτερόλεπτο
  • Ασφαλείς Συναλλαγές
  • Στιβαρή ενότητα αναφοράς για παρακολούθηση των καθημερινών συναλλαγών
  • Ισχυρός έλεγχος για την αντιμετώπιση προβλημάτων πελατών
  • Σύστημα μαζικής αποθήκευσης
  • Διαχείριση καταστροφών / αποκατάστασης.

Τα παραπάνω δέκα σημεία είναι τα τα πιο σημαντικά χαρακτηριστικά μιας τραπεζικής εφαρμογής.

Οι τραπεζικές εφαρμογές έχουν πολλά επίπεδα που εμπλέκονται στην εκτέλεση μιας λειτουργίας.

Για παράδειγμα , προς το Η τραπεζική αίτηση μπορεί να έχει:

  • Διακομιστής Web για αλληλεπίδραση με τελικούς χρήστες μέσω του προγράμματος περιήγησης
  • Μεσαίο επίπεδο για την επικύρωση της εισόδου και της εξόδου για τον διακομιστή ιστού
  • DataBase για αποθήκευση δεδομένων και διαδικασιών
  • Επεξεργαστής συναλλαγών που θα μπορούσε να είναι Mainframe μεγάλης χωρητικότητας ή οποιοδήποτε άλλο παλαιό σύστημα για την εκτέλεση τρισεκατομμυρίων συναλλαγών ανά δευτερόλεπτο.

Αν μιλάμε για δοκιμές τραπεζικών εφαρμογών, απαιτείται Μεθοδολογία δοκιμών από άκρο σε άκρο που περιλαμβάνει πολλαπλές τεχνικές δοκιμών λογισμικού για να διασφαλιστεί:

  • Συνολική κάλυψη όλων των τραπεζικών ροών εργασίας και επιχειρηματικών απαιτήσεων
  • Η λειτουργική πτυχή της εφαρμογής
  • Η πτυχή ασφάλειας της εφαρμογής
  • Ακεραιότητα δεδομένων
  • Συγχρονισμός
  • Εμπειρία χρήστη

Τι κάνει τις τραπεζικές εφαρμογές τόσο περίπλοκες;

  • Το τραπεζικό λογισμικό ασχολείται κυρίως με εμπιστευτικά οικονομικά δεδομένα, επομένως η απόδοση του λογισμικού πρέπει να είναι χωρίς σφάλματα και ασφαλή.
  • Οι προγραμματιστές προτιμούν έναν περίπλοκο σχεδιασμό για να αναπτύξουν αυτές τις εφαρμογές για να διασφαλίσουν ότι η εφαρμογή λειτουργεί με τον επιθυμητό ασφαλή τρόπο.
  • Η τραπεζική είναι ένας συνεχώς μεταβαλλόμενος κόσμος. Η τραπεζική, σήμερα, διατίθεται στον πελάτη χρησιμοποιώντας διαφορετικά κανάλια όπως καταστήματα τούβλου, ATM, online τραπεζικές συναλλαγές και εξυπηρέτηση πελατών.
  • Με την έλευση της τεχνολογίας, πολλά πορτοφόλια έχουν πλημμυρίσει τις αγορές που συνδέονται με τα τραπεζικά συστήματα για χρηματοοικονομικές συναλλαγές.
  • Το Banking αναμένεται επίσης να λειτουργεί και να λειτουργεί 24 Χ 7 με υψηλή απόδοση. Δεν επιτρέπεται η αναβάθμιση λογισμικού, οι άμεσες επιδιορθώσεις κ.λπ. που επηρεάζουν αυτήν τη διαθεσιμότητα.
  • Ο τραπεζικός κόσμος επηρεάζεται επίσης πολύ από τις συνεχείς αλλαγές που επιφέρει η κυβέρνηση με τη μορφή τραπεζικών κανονισμών. Οποιεσδήποτε αλλαγές στη φορολογική διάρθρωση επηρεάζουν επίσης το τραπεζικό σύστημα.
  • Το τραπεζικό σύστημα πρέπει επίσης να είναι ενημερωμένο όσον αφορά τις νέες τεχνολογίες. Η ανάλυση δεδομένων, όπως η Μεγάλη Επεξεργασία Δεδομένων και η λήψη ενστίκτων από μεγάλα δεδομένα, χρησιμοποιώντας την Επιστήμη Δεδομένων αυξάνει την έλξη στον τραπεζικό κόσμο.

Τα παραπάνω σημεία καθιστούν το τραπεζικό σύστημα πολύπλοκο για τους προγραμματιστές να δημιουργήσουν μια εφαρμογή λογισμικού γύρω από αυτό.

Σημασία της δοκιμής τραπεζικής εφαρμογής

  • Ο έλεγχος της εφαρμογής Banking διασφαλίζει ότι όλες οι δραστηριότητες δεν εκτελούνται μόνο καλά αλλά και παραμένουν προστατευμένες και ασφαλείς.
  • Το τραπεζικό λογισμικό είναι περίπλοκο με χιλιάδες εξαρτήσεις, η διαδικασία δοκιμών απαιτεί περισσότερο χρόνο, πόρους και συνεχή παρακολούθηση.
  • Επειδή εμπλέκονται τα οικονομικά, οι οδηγίες πρέπει να τηρούνται αυστηρά. Τόσο οι δοκιμαστές όσο και οι προγραμματιστές πρέπει να έχουν καλή γνώση τομέα.
  • Το πιο σημαντικό, πρέπει να διασφαλιστεί ότι οι νόμοι και οι κανονισμοί εφαρμόζονται σωστά στις χρηματοοικονομικές συναλλαγές. Αυτό μπορεί να διασφαλιστεί μόνο με δοκιμές.
  • Είναι επίσης σημαντικό να διασφαλιστεί ότι η εφαρμογή και η υποδομή στην οποία έχει αναπτυχθεί η εφαρμογή είναι σε θέση να χειριστεί το φορτίο, ειδικά κατά τις ώρες αιχμής, χωρίς να προκαλέσει διαταραχές. Αυτό μπορεί να διασφαλιστεί εκτελώντας δοκιμές απόδοσης.
  • Στον σημερινό ψηφιακό κόσμο, το μόνο που αφορά όλους είναι η ασφάλεια. Οι τραπεζικές εφαρμογές και οι χρηματοοικονομικές συναλλαγές που πραγματοποιούνται εντός αυτού πρέπει να είναι ασφαλείς από κάθε προσπάθεια διάρρηξης. Αυτό μπορεί να διασφαλιστεί εκτελώντας δοκιμές ασφαλείας. Ο έλεγχος ασφαλείας συμβάλλει στην επιβολή βιομηχανικών προτύπων για την εξασφάλιση χρηματοοικονομικών συναλλαγών.
  • Είναι επίσης σημαντικό να διασφαλιστεί ότι διαφορετικές ενότητες μιας τραπεζικής εφαρμογής και να ενσωματωθούν σωστά και να επιτευχθεί ο στόχος του πελάτη. Το System Integration Testing βοηθά στην επίτευξη αυτού του στόχου.

Ροή εργασίας δοκιμών εφαρμογών Banking

Τυπικά στάδια που εμπλέκονται στη δοκιμή τραπεζικών εφαρμογών εμφανίζονται στην παρακάτω ροή εργασίας. Θα συζητάμε κάθε στάδιο ξεχωριστά.

Αυτό είναι ένα μοντέλο Waterfall για τη δοκιμή μιας εφαρμογής.

Δοκιμές τραπεζικών εφαρμογών

# 1) Συγκέντρωση απαιτήσεων

Φάση συγκέντρωσης απαιτήσεων περιλαμβάνει την τεκμηρίωση των απαιτήσεων είτε ως λειτουργικές προδιαγραφές είτε ως περιπτώσεις χρήσης. Οι απαιτήσεις συλλέγονται σύμφωνα με τις ανάγκες των πελατών και τεκμηριώνονται από τους ειδικούς τραπεζικής ή τον επιχειρηματικό αναλυτή.

Συγκέντρωση απαιτήσεων

Οι ειδικοί ασχολούνται με τη σύνταξη απαιτήσεων σε περισσότερα από ένα θέματα, καθώς η ίδια η τραπεζική έχει πολλαπλούς υποτομείς και μία πλήρης τραπεζική εφαρμογή θα είναι η ολοκλήρωση όλων αυτών των τομέων.

Για παράδειγμα, Μια τραπεζική εφαρμογή μπορεί να έχει ξεχωριστές ενότητες για Μεταφορές, Πιστωτικές Κάρτες, Αναφορές, Λογαριασμούς Δανείων, Πληρωμές Λογαριασμού, Trading κ.λπ.

# 2) Αναθεώρηση απαιτήσεων

Το παραδοτέο της Απαίτησης Συγκέντρωσης εξετάζεται από όλα τα ενδιαφερόμενα μέρη, όπως QA Engineers, Development Lead και Peer Business Analysts.

Αναθεώρηση απαιτήσεων

Ελέγχουν αν δεν υπάρχει παραβίαση της υπάρχουσας επιχειρηματικής ροής ή της νέας ροής εργασίας. Όλες οι απαιτήσεις επαληθεύονται και επικυρώνονται. Οι ενέργειες παρακολούθησης και οι αναθεωρήσεις εγγράφων απαιτήσεων γίνονται με βάση τις ίδιες.

# 3) Προετοιμασίες επιχειρηματικού σεναρίου

Σε αυτό το στάδιο, οι μηχανικοί QA αντλούν επιχειρηματικά σενάρια από τα απαιτούμενα έγγραφα (Λειτουργίες προδιαγραφές ή περιπτώσεις χρήσης). Τα επιχειρηματικά σενάρια δημιουργούνται με τέτοιο τρόπο ώστε να καλύπτονται όλες οι επιχειρηματικές απαιτήσεις. Τα επιχειρηματικά σενάρια είναι σενάρια υψηλού επιπέδου χωρίς λεπτομερή βήματα.

Επιπλέον, αυτά τα επιχειρηματικά σενάρια εξετάζονται από επιχειρηματικούς αναλυτές για να διασφαλιστεί ότι πληρούνται όλες οι επιχειρησιακές απαιτήσεις. Είναι ευκολότερο για τους BA να ελέγχουν σενάρια υψηλού επιπέδου παρά να εξετάζουν λεπτομερείς υποθέσεις δοκιμής χαμηλού επιπέδου.

Για παράδειγμα , ένας πελάτης που ανοίγει μια σταθερή κατάθεση στη διεπαφή ψηφιακών τραπεζών μπορεί να είναι επιχειρηματικό σενάριο. Παρομοίως, μπορούμε να έχουμε διαφορετικά επιχειρηματικά σενάρια που σχετίζονται με τη δημιουργία λογαριασμού καθαρών τραπεζικών λογαριασμών, τις online καταθέσεις, τις ηλεκτρονικές μεταφορές κ.λπ.

# 4) Λειτουργική δοκιμή

Σε αυτό το στάδιο, πραγματοποιούνται λειτουργικές δοκιμές και εκτελούνται οι συνήθεις δραστηριότητες δοκιμών λογισμικού όπως:

Προετοιμασία δοκιμαστικής θήκης: Σε αυτό το στάδιο, οι δοκιμαστικές περιπτώσεις προέρχονται από επιχειρηματικά σενάρια, ένα επιχειρηματικό σενάριο οδηγεί σε πολλές θετικές και αρνητικές δοκιμαστικές περιπτώσεις. Γενικά, τα εργαλεία που χρησιμοποιούνται σε αυτό το στάδιο είναι το Microsoft Excel, το Test Director ή το Quality Center.

Επανεξέταση υπόθεσης: Κριτικές από ομότιμους μηχανικούς QA

Θήκη δοκιμής Εκτέλεση: Η εκτέλεση δοκιμαστικής υπόθεσης θα μπορούσε να είναι χειροκίνητη ή αυτόματη με εργαλεία όπως QC, QTP κ.λπ.

Ο λειτουργικός έλεγχος μιας τραπεζικής εφαρμογής είναι πολύ διαφορετικός από τον συνηθισμένο έλεγχο λογισμικού. Δεδομένου ότι αυτές οι εφαρμογές λειτουργούν με χρήματα των χρηστών και ευαίσθητα οικονομικά δεδομένα, πρέπει να δοκιμαστούν διεξοδικά. Κανένα σημαντικό επιχειρηματικό σενάριο δεν πρέπει να αφεθεί να καλυφθεί.

Επίσης, ο πόρος QA που δοκιμάζει την εφαρμογή θα πρέπει να έχει τις βασικές γνώσεις του τραπεζικού τομέα.

# 5) Δοκιμή βάσης δεδομένων

Η τραπεζική εφαρμογή περιλαμβάνει πολύπλοκες συναλλαγές που εκτελούνται τόσο σε επίπεδο UI όσο και σε επίπεδο βάσης δεδομένων, επομένως, η δοκιμή βάσης δεδομένων είναι εξίσου σημαντική με τη λειτουργική δοκιμή. Η βάση δεδομένων είναι περίπλοκη και ένα εντελώς ξεχωριστό επίπεδο στην εφαρμογή και έτσι η δοκιμή του πραγματοποιείται από ειδικούς βάσης δεδομένων. Χρησιμοποιεί τεχνικές όπως:

  • Φόρτωση δεδομένων
  • Μετεγκατάσταση βάσης δεδομένων
  • Έλεγχος σχήματος DB και τύπων δεδομένων
  • Δοκιμή κανόνων
  • Δοκιμή αποθηκευμένων διαδικασιών και λειτουργιών
  • Δοκιμές ενεργοποίησης
  • Ακεραιότητα δεδομένων

Ο κύριος σκοπός της δοκιμής βάσεων δεδομένων είναι να διασφαλιστεί ότι:

  • Η εφαρμογή είναι σε θέση να αποθηκεύει και να ανακτά δεδομένα από τη βάση δεδομένων χωρίς απώλεια δεδομένων.
  • Οι ολοκληρωμένες συναλλαγές πρέπει να πραγματοποιούνται και οι ματαιωμένες συναλλαγές επανέρχονται για να αποφευχθεί τυχόν αναντιστοιχία στα αποθηκευμένα δεδομένα.
  • Μόνο εξουσιοδοτημένες εφαρμογές και χρήστες επιτρέπεται να έχουν πρόσβαση στη βάση δεδομένων και στους υποκείμενους πίνακες.

Υπάρχουν κυρίως τρεις τρόποι δοκιμής βάσης δεδομένων:

  • Δομικές δοκιμές
  • Λειτουργική δοκιμή
  • Μη λειτουργικές δοκιμές

Δομικές δοκιμές

Περιλαμβάνει τον έλεγχο αντικειμένων της βάσης δεδομένων όπως βάσεις δεδομένων, σχήμα, πίνακες, προβολές, σκανδάλη, στοιχεία ελέγχου πρόσβασης κ.λπ. Διασφάλιση ότι οι τύποι δεδομένων στους πίνακες είναι συγχρονισμένοι με τις αντίστοιχες μεταβλητές στην εφαρμογή. Επικύρωση δεδομένων και ακεραιότητας αναφοράς στους πίνακες.

Για παράδειγμα, Ένα πεδίο ποσού στην εφαρμογή πρέπει να έχει έναν τύπο δεδομένων δεκαδικού / float στον πίνακα.

- Προκειμένου να συμμορφωθούν με τα πρότυπα, πρέπει να δοθούν στους χρήστες έλεγχοι πρόσβασης μέσω προβολών.

Λειτουργική δοκιμή

Περιλαμβάνει τον έλεγχο των βάσεων δεδομένων που ικανοποιούν τις απαιτήσεις των χρηστών. Υπάρχουν δύο τρόποι επίτευξης: Δοκιμή μαύρου κουτιού και Δοκιμή λευκού κουτιού.

Για παράδειγμα, Όταν πραγματοποιούμε ηλεκτρονική μεταφορά χρημάτων, ο λογαριασμός αποστολέα θα χρεώνεται και ο λογαριασμός παραλήπτη θα πιστωθεί με το ίδιο ακριβώς ποσό. Εάν η συναλλαγή αποτύχει, τότε ολόκληρες οι συναλλαγές πρέπει να αντιστραφούν και ο λογαριασμός αποστολέα δεν πρέπει να χρεωθεί ή να πιστωθεί ξανά.

Μη λειτουργικές δοκιμές

Περιλαμβάνει δοκιμές φόρτωσης και πίεσης και βελτιστοποίηση απόδοσης. Η δοκιμή φόρτωσης βοηθά στον προσδιορισμό του μεγαλύτερου αριθμού συναλλαγών που μπορούν να πραγματοποιηθούν ταυτόχρονα χωρίς να επηρεάζουν την απόδοση της βάσης δεδομένων.

Για παράδειγμα, Με βάση την εισροή από δοκιμές φόρτισης και πίεσης, οι τραπεζικές εφαρμογές μπορούν να αποφασίσουν να προσθέσουν περισσότερους πόρους στην εφαρμογή τους κατά τις ώρες αιχμής και να μειώσουν τους πόρους κατά τις ώρες εκτός λειτουργίας. Αυτό βοηθά την τράπεζα να κάνει τη βέλτιστη χρήση των πόρων και να εξοικονομήσει χρήματα.

# 6) Δοκιμή ασφαλείας

Η δοκιμή ασφαλείας είναι συνήθως το τελευταίο στάδιο του κύκλου δοκιμών. Απαραίτητη προϋπόθεση για την έναρξη δοκιμών ασφαλείας είναι η ολοκλήρωση λειτουργικών και μη λειτουργικών δοκιμών. Ο έλεγχος ασφαλείας είναι ένα από τα σημαντικότερα στάδια σε ολόκληρο τον κύκλο δοκιμών εφαρμογών, καθώς αυτό το στάδιο διασφαλίζει ότι η εφαρμογή συμμορφώνεται με τα ομοσπονδιακά και βιομηχανικά πρότυπα.

Λόγω της φύσης των δεδομένων που μεταφέρουν, οι τραπεζικές εφαρμογές είναι πολύ ευαίσθητες και αποτελούν πρωταρχικό στόχο για χάκερ και δόλιες δραστηριότητες. Ο έλεγχος ασφαλείας διασφαλίζει ότι η εφαρμογή δεν έχει τέτοια ευπάθεια στον ιστό που μπορεί να εκθέσει ευαίσθητα δεδομένα σε εισβολέα ή εισβολέα. Εξασφαλίζει επίσης ότι η εφαρμογή συμμορφώνεται με πρότυπα όπως το OWASP.

Σε αυτό το στάδιο, το κύριο καθήκον είναι η ολόκληρη σάρωση εφαρμογών που πραγματοποιείται χρησιμοποιώντας εργαλεία όπως το IBM AppScan ή το HP WebInspect (αυτά είναι τα πιο δημοφιλή εργαλεία).

Μόλις ολοκληρωθεί η σάρωση, δημοσιεύεται η αναφορά σάρωσης. Πάνω από αυτήν την αναφορά, τα False Positives φιλτράρονται και τα υπόλοιπα τρωτά σημεία αναφέρονται στην ομάδα ανάπτυξης, ώστε να αρχίσουν να επιδιορθώνουν τα ζητήματα ανάλογα με τη σοβαρότητα κάθε ζητήματος.

Ο έλεγχος διείσδυσης γίνεται επίσης σε αυτό το βήμα για να αποκαλυφθεί η διάδοση σφαλμάτων. Πρέπει να γίνουν αυστηροί έλεγχοι ασφαλείας σε πλατφόρμες, δίκτυα και λειτουργικά συστήματα.

Κάποιο άλλο Χειροκίνητα εργαλεία για έλεγχο ασφαλείας χρησιμοποιούνται είναι Πληρεξούσιος Πάρου , Http Watch , Burp Σουίτα , και Οχυρώνω.

Ο κύριος σκοπός του ελέγχου ασφαλείας είναι να εντοπίσει τυχόν ευπάθειες που μπορεί να έχει η εφαρμογή λογισμικού.

Ο έλεγχος ασφαλείας ελέγχει την εφαρμογή έναντι:

  • Οποιαδήποτε εξωτερική επίθεση ή απόπειρα παραβίασης της εφαρμογής με κακόβουλη πρόθεση.
  • Οποιοδήποτε κενό στην εφαρμογή λογισμικού θα μπορούσε να αξιοποιηθεί προκαλώντας απώλεια δεδομένων ή χρημάτων.
  • Τυχόν ευπάθεια στο δίκτυο, τους διακομιστές και τους σταθμούς εργασίας που φιλοξενούν την εφαρμογή.

Ακολουθούν οι διάφοροι τύποι δοκιμών ασφαλείας:

Δοκιμή ευπάθειας: Ένα αυτοματοποιημένο πρόγραμμα αναπτύσσεται και εκτελείται για τον έλεγχο διαφόρων τρωτών σημείων.

Σάρωση ασφαλείας: Αυτή η παραλλαγή περιστρέφεται γύρω από τη διερεύνηση τρωτών σημείων του δικτύου και του συστήματος, παρέχει λύσεις για τη μείωση του σχετικού κινδύνου.

Δοκιμή διείσδυσης: Αυτή η παραλλαγή των δοκιμών ασφαλείας μιμείται μια απόπειρα πειρατείας για να συλλάβει τρωτά σημεία και κενά, τα οποία διαφορετικά θα μπορούσαν να έχουν αποκτήσει πρόσβαση στη βάση δεδομένων ή στα δεδομένα της εφαρμογής.

Έλεγχος ασφάλειας: Περιλαμβάνει τον έλεγχο της εφαρμογής και των σχετικών δικτύων για τυχόν απώλεια ασφάλειας.

Εκτίμηση κινδύνου: Αυτή η παραλλαγή κάνει μια ανάλυση για να εκτιμήσει το επίπεδο κινδύνου, σε περίπτωση που εκμεταλλευτεί μια ευπάθεια ή ένα κενό για κακόβουλη πρόθεση. Ένας τέτοιος κίνδυνος μπορεί να κατηγοριοποιηθεί σε χαμηλό, μεσαίο και υψηλό. Με βάση το επίπεδο κινδύνου, η ομάδα δοκιμών συνιστάται κατάλληλα μέτρα για τη μείωση ή την αποτροπή του κινδύνου.

Ηθική εισβολή: Αυτό πραγματοποιείται από έναν οργανισμό στα συστήματά του για τον εντοπισμό κενών που θα μπορούσαν να αξιοποιηθούν στην εφαρμογή ή το δίκτυό του. Σκοπός αυτού του είδους πειρατείας δεν είναι να κλέψει ή να προκαλέσει ζημιά στην εφαρμογή ή το δίκτυο.

Αξιολόγηση στάσης: Αυτή είναι μια αξιολόγηση ομπρέλας που περιλαμβάνει σάρωση ασφαλείας, αξιολογήσεις κινδύνου και ηθική εισβολή.

Έγχυση SQL: Το SQL Injection θα μπορούσε να χρησιμοποιηθεί για να αποκτήσει πρόσβαση στη βάση δεδομένων του διακομιστή. Ο έλεγχος γίνεται για να διασφαλιστεί ότι ο κώδικας λειτουργεί σωστά, οι οποίοι εκτελούν ερωτήματα στη βάση δεδομένων με βάση τις ακόλουθες εισόδους από το χρήστη:

  • Αγκύλες
  • Απόστολοι
  • Κόμματα
  • Εισαγωγικά

Άλλα στάδια στη δοκιμή της εφαρμογής BFSI

Εκτός από τα παραπάνω βασικά στάδια, ενδέχεται να υπάρχουν διαφορετικά στάδια, όπως Δοκιμή ενοποίησης, δοκιμή ευχρηστίας, δοκιμή αποδοχής χρήστη και δοκιμή απόδοσης.

Ας μιλήσουμε εν συντομία και για αυτά τα στάδια:

Δοκιμή ολοκλήρωσης

Όπως γνωρίζετε ότι σε μια τραπεζική εφαρμογή, μπορεί να υπάρχουν πολλές διαφορετικές ενότητες όπως μεταφορές, πληρωμές λογαριασμών, καταθέσεις κ.λπ. Και έτσι, υπάρχουν πολλά στοιχεία που έχουν αναπτυχθεί. Στη δοκιμή ολοκλήρωσης, όλα τα στοιχεία και ενσωματώθηκαν μαζί και επικυρώθηκαν.

Δοκιμή χρηστικότητας

Δοκιμή χρηστικότητας

Μια τραπεζική εφαρμογή εξυπηρετεί μια μεγάλη ποικιλία πελατών. Ορισμένοι από αυτούς τους πελάτες ενδέχεται να μην διαθέτουν τις δεξιότητες και την ευαισθητοποίηση που απαιτούνται για την εκτέλεση των τραπεζικών εργασιών μέσω της εφαρμογής.

Έτσι, η τραπεζική εφαρμογή πρέπει να δοκιμαστεί για απλό και αποτελεσματικό σχεδιασμό, ώστε να μπορεί να χρησιμοποιηθεί σε διαφορετικές ομάδες πελατών. Η απλούστερη και εύχρηστη διεπαφή είναι ότι ο μεγαλύτερος αριθμός πελατών θα επωφεληθεί από την τραπεζική εφαρμογή.

Πρόκειται για την εξέταση του επιπέδου ευκολίας, των επιχειρηματικών χρηστών ή των τραπεζικών πελατών στη χρήση της εφαρμογής. Αυτός ο έλεγχος δεν πραγματοποιείται από τον προγραμματιστή ή τον υπεύθυνο δοκιμών, αλλά πραγματοποιείται από τους επιχειρηματικούς χρήστες.

Για παράδειγμα, Σήμερα όλοι χρησιμοποιούν εφαρμογές για κινητά. Η τραπεζική εφαρμογή πρέπει να είναι φιλική προς τον χρήστη και κατανοητή και εύκολη από τον τελικό χρήστη.

Τύποι δοκιμών ευχρηστίας

Συγκριτικός έλεγχος χρηστικότητας: Πρόκειται για δοκιμή βάσει σύγκρισης, όπου η ευχρηστία ενός ιστότοπου ή μιας εφαρμογής με έναν άλλο. Ο στόχος για τέτοιες δοκιμές είναι να παρέχει την καλύτερη εμπειρία χρήστη.

Διερευνητική δοκιμή χρηστικότητας: Ο στόχος αυτής της δοκιμής είναι να εντοπίσει ποιες δυνατότητες πρέπει να διαθέτει η νέα εφαρμογή ή λογισμικό προκειμένου να ικανοποιεί τις απαιτήσεις των πελατών της τράπεζας.

Ακολουθούν τα πλεονεκτήματα και τα μειονεκτήματα του Test Usability

πώς να δημιουργήσετε έργο σε έκλειψη

Πλεονεκτήματα:

  • Οι τελικοί χρήστες της εφαρμογής συνήθως εμπλέκονται στη δοκιμή, επομένως λαμβάνονται από πρώτο χέρι σχόλια.
  • Αντί να ξοδεύουμε χρόνο για ανάλυση και συζήτηση σχετικά με ένα χαρακτηριστικό που πρέπει να έχει ή όχι ένα προϊόν, είναι καλύτερο να λαμβάνετε απευθείας τις πληροφορίες από τον τελικό χρήστη.
  • Μπορούμε να αντιμετωπίσουμε τυχόν πιθανά προβλήματα εκ των προτέρων.

Μειονεκτήματα:

  • Καθώς πολλοί τελικοί χρήστες συμμετέχουν στη δοκιμή, οι απόψεις τους, εάν δεν είναι ακριβείς, μπορούν να επηρεάσουν την απαίτηση.
  • Η ροή από τους τελικούς χρήστες μπορεί να επηρεαστεί.

Δοκιμή απόδοσης

Ορισμένες χρονικές περιόδους όπως η ημέρα πληρωμής, το τέλος του οικονομικού έτους, οι εορταστικές περίοδοι ενδέχεται να φέρουν αλλαγή ή να αυξήσουν τη συνήθη επισκεψιμότητα στην εφαρμογή. Ως εκ τούτου, θα πρέπει να γίνουν διεξοδικές δοκιμές απόδοσης, ώστε οι πελάτες να μην επηρεάζονται από αποτυχίες απόδοσης.

Ένα σημαντικό παράδειγμα από το παρελθόν όπου οι τραπεζικοί πελάτες επηρεάστηκαν προσωπικά λόγω αποτυχιών απόδοσης είναι η διακοπή της τεχνολογίας NatWest και RBS cyber Monday IT, όπου οι πελάτες είχαν τη χρεωστική και πιστωτική τους κάρτα να έχουν απορρίψει συναλλαγές σε καταστήματα της χώρας.

Δοκιμή αποδοχής χρήστη

Αυτό επιτυγχάνεται με τη συμμετοχή των τελικών χρηστών για να διασφαλιστεί ότι η εφαρμογή συμμορφώνεται με τα σενάρια του πραγματικού κόσμου και θα γίνει αποδεκτή από τους χρήστες εάν προβάλλεται ζωντανά.

Στο σημερινό σενάριο Η πλειονότητα των τραπεζικών έργων χρησιμοποιεί : Μεθοδολογίες Agile / Scrum, RUP και Continuous Integration και πακέτα εργαλείων όπως τα VSTS της Microsoft και τα Rational Tools.

Όπως αναφέραμε για το RUP παραπάνω, το RUP σημαίνει Rational Unified Process, η οποία είναι μια επαναληπτική μεθοδολογία ανάπτυξης λογισμικού που εισήγαγε η IBM και περιλαμβάνει τέσσερις φάσεις στις οποίες διεξάγονται δραστηριότητες ανάπτυξης και δοκιμών.

Τέσσερις φάσεις είναι
i) Έναρξη
ii) Συνεργασία
iii) Κατασκευή και
iv) Μετάβαση

Το RUP περιλαμβάνει ευρέως εργαλεία IBM Rational.

Δείγμα δοκιμαστικών περιπτώσεων για τραπεζική εφαρμογή

Δοκιμαστικές θήκες για το New Branch

  • Δημιουργήστε έναν νέο κλάδο με έγκυρα και μη έγκυρα δεδομένα δοκιμής.
  • Δημιουργήστε έναν νέο κλάδο χωρίς δεδομένα.
  • Δημιουργήστε έναν νέο κλάδο με υπάρχοντα δεδομένα κλάδου.
  • Επαληθεύστε τις επιλογές επαναφοράς και ακύρωσης.
  • Ενημέρωση λεπτομερειών κλάδου με έγκυρα και μη έγκυρα δεδομένα δοκιμής.
  • Ενημέρωση λεπτομερειών κλάδου με υπάρχοντα δεδομένα δοκιμής κλάδου.
  • Επαληθεύστε εάν μπορεί να αποθηκευτεί ο νέος κλάδος.
  • Βεβαιωθείτε ότι η επιλογή ακύρωσης λειτουργεί.
  • Επαληθεύστε τη διαγραφή κλάδου με και χωρίς εξαρτήσεις.
  • Βεβαιωθείτε ότι λειτουργεί η επιλογή αναζήτησης κλάδου.

Θήκες δοκιμής για νέο ρόλο

  • Δημιουργήστε έναν νέο ρόλο με έγκυρα και μη έγκυρα δεδομένα δοκιμών.
  • Δημιουργήστε έναν νέο ρόλο χωρίς δεδομένα.
  • Επαληθεύστε ότι μπορεί να δημιουργηθεί ένας νέος ρόλος με τα υπάρχοντα δεδομένα δοκιμής.
  • Επαληθεύστε την περιγραφή του ρόλου και τους τύπους ρόλων.
  • Βεβαιωθείτε ότι η επιλογή ακύρωσης και επαναφοράς λειτουργεί.
  • Επαληθεύστε τη διαδικασία διαγραφής ρόλων με και χωρίς εξάρτηση.
  • Επαληθεύστε τους συνδέσμους στη σελίδα λεπτομερειών ρόλου.
  • Επαληθεύστε τη σύνδεση διαχειριστή χωρίς δεδομένα δοκιμής.
  • Επαληθεύστε όλους τους αρχικούς συνδέσμους για το ρόλο διαχειριστή.
  • Βεβαιωθείτε ότι ο διαχειριστής μπορεί να αλλάξει τον κωδικό πρόσβασης με έγκυρα και μη έγκυρα δεδομένα δοκιμής.
  • Επιβεβαιώστε με επιτυχία την αποσύνδεση του διαχειριστή.

Δοκιμαστικές περιπτώσεις για πελάτη και τραπεζίτη

  • Επαληθεύστε εάν όλοι οι σύνδεσμοι επισκεπτών και πελατών λειτουργούν σωστά.
  • Επαληθεύστε τη σύνδεση πελάτη με έγκυρα και μη έγκυρα δεδομένα δοκιμής.
  • Επαληθεύστε τη σύνδεση πελάτη χωρίς δεδομένα.
  • Επαληθεύστε τη σύνδεση του τραπεζίτη χωρίς δεδομένα.
  • Επαληθεύστε τη σύνδεση του τραπεζίτη με έγκυρα ή μη έγκυρα δεδομένα δοκιμών.
  • Βεβαιωθείτε ότι ο πελάτης ή ο τραπεζίτης μπορεί να αποσυνδεθεί με επιτυχία.

Δοκιμαστικές περιπτώσεις για νέους χρήστες

  • Επαληθεύστε εάν ο νέος χρήστης μπορεί να δημιουργηθεί με έγκυρα και μη έγκυρα δεδομένα δοκιμής.
  • Δημιουργήστε έναν νέο χρήστη με υπάρχοντα δεδομένα δοκιμής κλάδου
  • Βεβαιωθείτε ότι η επιλογή ακύρωσης και επαναφοράς λειτουργεί σωστά.
  • Ενημέρωση στοιχείων χρήστη με έγκυρα και μη έγκυρα δεδομένα δοκιμών.
  • Επαληθεύστε τη διαγραφή του νέου χρήστη.
  • ελέγξτε αν ο νέος χρήστης μπορεί να επαληθευτεί.
  • Επαληθεύστε τις υποχρεωτικές παραμέτρους εισαγωγής.
  • Επαληθεύστε τις προαιρετικές παραμέτρους εισαγωγής.
  • Επαληθεύστε εάν μπορεί να δημιουργηθεί ένας χρήστης χωρίς προαιρετικές παραμέτρους.

Δοκιμές για τη δημιουργία ενός νέου λογαριασμού

  • Δημιουργήστε έναν νέο λογαριασμό με έγκυρα και μη έγκυρα δεδομένα χρήστη.
  • Επαληθεύστε εάν μπορούν να ενημερωθούν τα στοιχεία χρήστη.
  • Επαληθεύστε εάν μπορεί να αποθηκευτεί ένας νέος χρήστης.
  • Δημιουργήστε έναν νέο λογαριασμό με τα υπάρχοντα δεδομένα χρήστη.
  • Βεβαιωθείτε ότι ο χρήστης μπορεί να καταθέσει το ποσό στο λογαριασμό που δημιουργήθηκε πρόσφατα (και να ενημερώσει το υπόλοιπο).
  • Βεβαιωθείτε ότι ο χρήστης μπορεί να αποσύρει ένα ποσό από το νέο λογαριασμό (μετά την κατάθεση και ενημέρωση του υπολοίπου).
  • Στην περίπτωση του μισθού, ο λογαριασμός επαληθεύει το όνομα της εταιρείας και άλλες πληροφορίες παρέχονται από τον χρήστη.
  • Επαληθεύστε εάν ο κύριος αριθμός λογαριασμού παρέχεται σε περίπτωση δευτερεύοντος λογαριασμού.
  • Επαληθεύστε τα στοιχεία χρήστη που παρέχονται σε περιπτώσεις του τρέχοντος λογαριασμού.
  • Επαληθεύστε τα παρεχόμενα αποδεικτικά στοιχεία για κοινό λογαριασμό σε περίπτωση από κοινού λογαριασμού.
  • Επαληθεύστε εάν μπορείτε να διατηρήσετε μηδενικό υπόλοιπο στο λογαριασμό μισθών.
  • Επαληθεύστε εάν μπορείτε να διατηρήσετε μηδενικό ή ελάχιστο υπόλοιπο για τον λογαριασμό μη μισθών.
  • Βεβαιωθείτε ότι ο νέος χρήστης μπορεί να αποσυνδεθεί με επιτυχία.

Δοκιμές για εφαρμογή Net Banking

  • Ελέγξτε εάν ο χρήστης μπορεί να ανοίξει τον ιστότοπο της τράπεζας.
  • Ελέγξτε εάν όλοι οι σύνδεσμοι στον ιστότοπο λειτουργούν.
  • Επαληθεύστε εάν ο χρήστης μπορεί να δημιουργήσει νέο λογαριασμό.
  • Ελέγξτε εάν ο χρήστης μπορεί να συνδεθεί με έγκυρο και άκυρο όνομα χρήστη και κωδικό πρόσβασης.
  • Επαληθεύστε εάν κάποιο από τα ονόματα χρήστη ή τον κωδικό πρόσβασης είναι κενό κατά τη σύνδεση, δεν θα πρέπει να επιτρέπεται η είσοδος στο χρήστη και εμφανίζεται ένα μήνυμα προειδοποίησης.
  • Ελέγξτε εάν επιτρέπεται στον χρήστη να αλλάξει τον κωδικό πρόσβασης.
  • Εάν εισαχθεί μη έγκυρος χρήστης ή κωδικός πρόσβασης εμφανίζεται το κατάλληλο μήνυμα σφάλματος.
  • Δεν επιτρέπεται η είσοδος σε χρήστες με μη έγκυρο κωδικό πρόσβασης.
  • Βεβαιωθείτε ότι μετά από επανειλημμένες προσπάθειες σύνδεσης με λανθασμένο κωδικό πρόσβασης, θα πρέπει να εμφανιστεί στον χρήστη ένα μήνυμα σφάλματος και να αποκλειστεί.
  • Ελέγξτε εάν ο χρήστης μπορεί να πραγματοποιήσει ορισμένες βασικές συναλλαγές.
  • Βεβαιωθείτε ότι ο χρήστης μπορεί να προσθέσει έναν δικαιούχο με έγκυρες και μη έγκυρες λεπτομέρειες.
  • Επαληθεύστε εάν ο χρήστης μπορεί να διαγράψει τον δικαιούχο.
  • Επαληθεύστε ότι ο χρήστης μπορεί να πραγματοποιήσει συναλλαγές στον δικαιούχο που προστέθηκε πρόσφατα.
  • Μετά τη συναλλαγή επαληθεύστε εάν ενημερώνονται οι λογαριασμοί τόσο του χρήστη όσο και του δικαιούχου.
  • Ελέγξτε εάν ο χρήστης μπορεί να εισαγάγει το ποσό με δεκαδικό αριθμό.
  • Επαληθεύστε εάν ο χρήστης δεν μπορεί να εισαγάγει αρνητικούς αριθμούς στο πεδίο ποσότητας.
  • Επαληθεύστε εάν επιτρέπεται στον χρήστη να κάνει συναλλαγές με ή χωρίς ελάχιστο υπόλοιπο.
  • Επαληθεύστε εάν ο χρήστης μπορεί να κάνει ένα νέο RD.
  • Βεβαιωθείτε ότι εμφανίζεται το κατάλληλο μήνυμα σε περίπτωση συναλλαγής με ανεπαρκές υπόλοιπο.
  • Ελέγξτε εάν ζητείται επιβεβαίωση από τον χρήστη πριν από οποιαδήποτε συναλλαγή.
  • Επαληθεύστε εάν παρέχεται απόδειξη απόδειξης σε κάθε επιτυχημένη συναλλαγή.
  • Επαληθεύστε εάν ο χρήστης μπορεί να μεταφέρει χρήματα σε πολλούς λογαριασμούς.
  • επαληθεύστε εάν ο χρήστης μπορεί να ακυρώσει τη συναλλαγή.
  • Βεβαιωθείτε ότι τα στοιχεία του λογαριασμού αντικατοπτρίζουν επίσης τις χρηματοοικονομικές συναλλαγές.
  • Βεβαιωθείτε ότι έχει εφαρμοστεί η δυνατότητα χρονικού ορίου.
  • επαληθεύστε ότι σε περίπτωση λήξης της περιόδου λειτουργίας ο χρήστης πρέπει να συνδεθεί ξανά.
  • επαληθεύστε ότι έχει γίνει σωστό χρονικό όριο περιόδου λειτουργίας σε περίπτωση αδράνειας.
  • επαληθεύστε ότι κατά τη συναλλαγή ο χρήστης μεταφέρεται σε ασφαλή λειτουργία.
  • Επαληθεύστε εάν ο χρήστης μπορεί να αποσυνδεθεί με επιτυχία.
  • Επιβεβαιώστε τις επιλογές αναζήτησης και επαναφοράς.

συμπέρασμα

Σε αυτό το άρθρο, συζητήσαμε πόσο περίπλοκη θα μπορούσε να είναι μια τραπεζική εφαρμογή και τι είναι τυπικές φάσεις που εμπλέκονται στη δοκιμή της εφαρμογής . Εκτός από αυτό συζητήσαμε επίσης τις τρέχουσες τάσεις που ακολουθούνται από βιομηχανίες πληροφορικής, συμπεριλαμβανομένων μεθοδολογιών και εργαλείων ανάπτυξης λογισμικού.

Μη διστάσετε να μοιραστείτε την εμπειρία ή τις απορίες σας σχετικά με αυτό το θέμα!

Συνιστώμενη ανάγνωση

^