Menú

Com provar aplicacions de domini bancari: una guia completa de proves de BFSI

how test banking domain applications

Proveu El Nostre Instrument Per Eliminar Problemes

Una guia completa de proves d'aplicació bancària: procés i consells de prova BFSI (banca, serveis financers i assegurances)

Les aplicacions bancàries són una de les aplicacions més complexes de la indústria actual de desenvolupament i proves de programari.

Què fa que les aplicacions bancàries siguin tan complexes? Quin enfocament s’hauria de seguir per provar els complexos fluxos de treball implicats en les aplicacions bancàries?

En aquest article, destacarem les diferents etapes i tècniques implicades en la prova d’aplicacions bancàries.

Com provar aplicacions bancàries

Què aprendreu:

Com provar aplicacions bancàries?

Diverses funcions realitzades per les aplicacions bancàries són:

Funcions dels bancs

Primer comprenem les característiques d’una sol·licitud bancària:

  • Funcionalitat de diversos nivells per donar suport a milers de sessions d'usuari simultànies
  • Integració a gran escala: normalment, una aplicació bancària s’integra amb moltes altres aplicacions, com ara la utilitat Bill Pay i els comptes comercials
  • Fluxos de treball empresarials complexos
  • Processament en temps real i per lots
  • L’alt percentatge de transaccions per segons
  • Transaccions segures
  • Secció d'informes sòlida per fer un seguiment de les transaccions del dia a dia
  • Auditoria forta per solucionar problemes de clients
  • Sistema d’emmagatzematge massiu
  • Gestió de desastres / recuperació.

Els deu punts enumerats anteriorment són els característiques més importants d’una aplicació bancària.

Les aplicacions bancàries tenen diversos nivells implicats en la realització d’una operació.

Per exemple , a L'aplicació bancària pot tenir:

  • Servidor web per interactuar amb els usuaris finals a través del navegador
  • Middle Tier per validar l'entrada i la sortida del servidor web
  • DataBase per emmagatzemar dades i procediments
  • Processador de transaccions que podria ser un mainframe de gran capacitat o qualsevol altre sistema heretat per dur a terme bilions de transaccions per segon.

Si parlem de provar aplicacions bancàries, cal un Metodologia de proves de punta a punta que inclouen diverses tècniques de prova de programari per garantir:

  • Cobertura total de tots els fluxos de treball bancaris i requisits empresarials
  • L'aspecte funcional de l'aplicació
  • L'aspecte de seguretat de l'aplicació
  • Integritat de les dades
  • Concurrència
  • Experiència d'usuari

Què fa que les aplicacions bancàries siguin tan complexes?

  • El programari bancari tracta principalment de dades financeres confidencials, de manera que el rendiment del programari ha d’estar lliure d’errors i segur.
  • Els desenvolupadors prefereixen un disseny complicat per desenvolupar aquestes aplicacions per garantir que l'aplicació s'executi de la manera segura desitjada.
  • La banca és un món en constant canvi. Avui, la banca es posa a disposició del client mitjançant diferents canals com sucursals de maó i morter, caixers automàtics, banca en línia i atenció al client.
  • Amb l'arribada de la tecnologia, moltes carteres han inundat els mercats que es connecten als sistemes bancaris per a les transaccions financeres.
  • També s’espera que la banca funcioni 24 x 7 amb un alt rendiment. No es pot permetre que les actualitzacions de programari, les correccions instantànies, etc. afectin aquesta disponibilitat.
  • El món bancari també es veu molt afectat pels constants canvis que el govern ha dut a terme en forma de regulacions bancàries. Qualsevol canvi en l’estructura fiscal també afecta el sistema bancari.
  • El sistema bancari també ha d’estar actualitzat pel que fa a les noves tecnologies. L’anàlisi de dades com el Big Data Processing i treure instints del big data mitjançant Data Science augmenta la força del món bancari.

Els punts esmentats anteriorment fan que el sistema bancari sigui complex per als desenvolupadors per crear una aplicació de programari al seu voltant.

Importància de l'aplicació bancària de proves

  • La prova de l’aplicació bancària assegura que totes les activitats no només s’executen bé, sinó que també es mantenen protegides i protegides.
  • El programari bancari és complicat amb milers de dependències; el procés de proves requereix més temps, recursos i un seguiment continu.
  • Com que hi participen les finances, cal seguir estrictament les directrius. Tant els provadors com els desenvolupadors haurien de tenir un bon coneixement del domini.
  • El més important, s’ha d’assegurar que les lleis i regulacions s’apliquen correctament en les transaccions financeres. Això només es pot assegurar amb proves.
  • També és important assegurar-se que l’aplicació i la infraestructura en què s’ha desplegat l’aplicació siguin capaços de gestionar la càrrega, especialment durant les hores laborals màximes, sense causar cap interrupció. Això es pot assegurar realitzant proves de rendiment.
  • Al món digital actual, l’única cosa que preocupa a tothom és la seguretat. Les aplicacions bancàries i les transaccions financeres que s’hi realitzen han de ser segures de qualsevol intent d’introducció. Això es pot assegurar realitzant proves de seguretat. Les proves de seguretat ajuden a fer complir els estàndards de la indústria per garantir transaccions financeres.
  • També és important assegurar-se que els diferents mòduls d’una aplicació bancària s’integrin correctament i assoleixin l’objectiu del client. Les proves d’integració del sistema ajuden a assolir aquesta tasca.

Flux de treball de proves d'aplicacions bancàries

Etapes típiques de la prova d'aplicacions bancàries es mostren al flux de treball següent. Anem a discutir cada etapa individualment.

Es tracta d’un model Waterfall per provar una aplicació.

Proves d

# 1) Reunió de requisits

Fase de reunió de requisits implica la documentació de requisits, ja sigui com a especificacions funcionals o com a casos d’ús. Els requisits es recullen segons les necessitats dels clients i els documenten experts bancaris o analistes de negocis.

Reunió de requisits

Els experts participen en la redacció de requisits sobre més d’un tema, ja que la banca té diversos subdominis i una aplicació bancària completa serà la integració de tots aquests dominis.

Per exemple, Una aplicació bancària pot tenir mòduls separats per a transferències, targetes de crèdit, informes, comptes de préstecs, pagaments de factures, negociació, etc.

# 2) Revisió dels requisits

El lliurament de Reunió de requisits és revisat per totes les parts interessades, com ara enginyers de control de qualitat, responsables de desenvolupament i analistes de negocis entre iguals.

Revisió del requisit

Comproven que no s’incompleixen ni els fluxos de treball empresarials existents ni els nous. Es verificen i validen tots els requisits. Les accions de seguiment i les revisions del document de requisits es fan en funció del mateix.

# 3) Preparatius de l'escenari empresarial

En aquesta etapa, els enginyers de control de qualitat deriven els escenaris empresarials dels documents de requisits (especificacions de funcions o casos d’ús); Els escenaris empresarials es deriven de manera que es cobreixin tots els requisits empresarials. Els escenaris empresarials són escenaris d’alt nivell sense cap pas detallat.

A més, aquests escenaris empresarials són revisats per analistes empresarials per garantir que es compleixin tots els requisits empresarials. És més fàcil per als BA revisar escenaris d'alt nivell en lloc de revisar casos de prova detallats de baix nivell.

Per exemple , un client que obri un dipòsit fix a la interfície de banca digital pot ser un escenari comercial. De la mateixa manera, podem tenir diferents escenaris comercials relacionats amb la creació de comptes bancaris nets, dipòsits en línia, transferències en línia, etc.

# 4) Proves funcionals

En aquesta etapa, es realitzen proves funcionals i es realitzen les activitats habituals de prova de programari, com ara:

Preparació del cas de prova: En aquesta etapa, els casos de prova es deriven d’escenaris empresarials; un escenari empresarial condueix a diversos casos de prova positius i casos de prova negatius. Generalment, les eines que s’utilitzen durant aquesta etapa són Microsoft Excel, Director de proves o Quality Center.

Revisió de casos de prova: Ressenyes d’enginyers de control de qualitat d’iguals

Cas de prova Execució: L'execució de casos de prova pot ser manual o automàtica amb eines com QC, QTP, etc.

Les proves funcionals d'una aplicació bancària són molt diferents de les proves de programari normals. Atès que aquestes aplicacions funcionen amb els diners del client i amb dades financeres confidencials, cal que les provin a fons. No s’ha de deixar cobrir cap escenari comercial important.

A més, el recurs de control de qualitat que prova l'aplicació hauria de tenir els coneixements bàsics del domini bancari.

# 5) Proves de bases de dades

L’aplicació bancària implica una transacció complexa que es realitza tant a nivell d’interfície d’usuari com a nivell de base de dades. Per tant, les proves de bases de dades són tan importants com les proves funcionals. La base de dades és complicada i té una capa totalment separada a l'aplicació i, per tant, la seva prova la realitzen especialistes en bases de dades. Utilitza tècniques com:

  • Càrrega de dades
  • Migració de bases de dades
  • Prova d’esquemes de bases de dades i tipus de dades
  • Proves de regles
  • Proves de procediments i funcions emmagatzemades
  • Proves de desencadenants
  • Integritat de les dades

L’objectiu principal de les proves de bases de dades és assegurar-se que:

  • L’aplicació és capaç d’emmagatzemar i recuperar dades de la base de dades sense cap pèrdua de dades.
  • Les transaccions finalitzades haurien de ser compromeses i les transaccions avortades es recuperaran per evitar qualsevol desajustament de les dades emmagatzemades.
  • Només els usuaris i les aplicacions autoritzades poden accedir a la base de dades i a les taules subjacents.

Hi ha principalment tres maneres de provar bases de dades:

  • Proves estructurals
  • Proves funcionals
  • Proves no funcionals

Proves estructurals

Es tracta de provar els objectes de la base de dades, com ara bases de dades, esquemes, taules, vistes, activadors, controls d’accés, etc. Garantir que els tipus de dades de les taules estiguin sincronitzats amb les variables corresponents de l’aplicació. Validació de dades i integritat referencial a les taules.

Per exemple, Un camp de quantitat de l'aplicació ha de tenir un tipus de dades decimal / flotant a la taula.

- Per tal de complir els estàndards, els usuaris haurien de tenir controls d'accés mitjançant vistes.

Proves funcionals

Es tracta de provar les bases de dades que satisfacin els requisits de l'usuari. Hi ha dues maneres d’aconseguir-ho: proves de caixes negres i proves de caixes blanques.

Per exemple, Quan fem una transferència de diners en línia, s’ha de domiciliar el compte del remitent i s’ha d’acreditar el compte del receptor amb la mateixa quantitat exacta. Si la transacció falla, s'haurien de revertir les transaccions senceres i no s'ha de carregar ni acreditar el compte del remitent.

Proves no funcionals

Implica proves de càrrega i esforç i optimització del rendiment. Les proves de càrrega ajuden a identificar el màxim nombre de transaccions que es poden realitzar simultàniament sense afectar el rendiment de la base de dades.

Per exemple, Basant-se en les aportacions de les proves de càrrega i estrès, les aplicacions bancàries poden decidir afegir més recursos a la seva aplicació durant les hores laborals màximes i reduir els recursos durant les hores laborals. Això ajuda el banc a fer un ús òptim dels recursos i estalviar diners.

# 6) Proves de seguretat

Les proves de seguretat solen ser l’última etapa del cicle de proves. Un requisit previ per començar les proves de seguretat és la realització de proves funcionals i no funcionals. Les proves de seguretat són una de les etapes principals de tot el cicle de proves de l'aplicació, ja que aquesta etapa garanteix que l'aplicació compleixi els estàndards federals i industrials.

A causa de la naturalesa de les dades que contenen, les aplicacions bancàries són molt sensibles i són un objectiu principal per a pirates informàtics i activitats fraudulentes. Les proves de seguretat asseguren que l'aplicació no tingui cap vulnerabilitat web tal que pugui exposar dades sensibles a un intrús o un atacant. També assegura que l'aplicació compleix amb estàndards com OWASP.

En aquesta etapa, la tasca principal és l'escaneig complet de l'aplicació que es realitza mitjançant eines com IBM AppScan o HP WebInspect (aquestes són les eines més populars).

Un cop finalitzada l'escaneig, es publica l'informe d'escaneig. En aquest informe, es filtren els falsos positius i es comunica a la resta de vulnerabilitats a l'equip de desenvolupament perquè comencin a solucionar els problemes en funció de la gravetat de cada problema.

En aquest pas també es fan proves de penetració per revelar la propagació d'errors. S'han de fer proves de seguretat rigoroses a totes les plataformes, xarxes i SO.

Algun altre Eines manuals per a proves de seguretat usats són Paros Proxy , Http Watch , Suite Burp , i Enfortir.

L’objectiu principal de les proves de seguretat és identificar qualsevol vulnerabilitat que pugui tenir l’aplicació de programari.

Les proves de seguretat comproven l'aplicació contra:

  • Qualsevol atac extern o intent de piratejar l'aplicació amb intenció malintencionada.
  • Qualsevol escletxa de l'aplicació de programari es podria explotar causant pèrdues de dades o diners.
  • Qualsevol vulnerabilitat a la xarxa, servidors i estacions de treball que allotja l'aplicació.

A continuació es detallen els diferents tipus de proves de seguretat:

Proves de vulnerabilitat: Es desenvolupa i s’executa un programa automatitzat per comprovar si hi ha diverses vulnerabilitats.

Escaneig de seguretat: Aquesta variant gira al voltant de la investigació de les vulnerabilitats del sistema i de la xarxa, i proporciona solucions per reduir el risc associat.

Proves de penetració: Aquesta variant de les proves de seguretat imita un intent de pirateria per captar vulnerabilitats i llacunes, que d'altra manera haurien pogut accedir a la base de dades o a les dades de l'aplicació.

Auditoria de seguretat: Implica l’auditoria de l’aplicació i de les xarxes associades en cas de deficiències de seguretat.

Avaluació de riscos: Aquesta variant fa una anàlisi per avaluar el nivell de risc, en un cas en què s’explota una vulnerabilitat o una llacuna per intenció malintencionada. Aquest risc es podria classificar en baix, mitjà i alt. En funció del nivell de risc, l’equip de proves aconsella mesures adequades per reduir o evitar el risc.

Hacking ètic: Una organització la realitza en els seus sistemes per identificar les llacunes que es podrien explotar a la seva aplicació o xarxa. La intenció d’aquest tipus de pirateria no és robar ni causar danys a l’aplicació o a la xarxa.

Avaluació de la postura: Es tracta d’una avaluació general que comprèn escaneig de seguretat, avaluacions de riscos i pirateria ètica.

Injecció SQL: SQL Injection es podria utilitzar per accedir a la base de dades del servidor. La prova es realitza per assegurar-se que el codi funciona correctament, que executa consultes a la base de dades basant-se en les següents entrades de l'usuari:

  • Suports
  • Apostrofes
  • Comes
  • Cometes

Altres etapes de la prova de l'aplicació BFSI

A part de les etapes principals anteriors, hi pot haver diferents etapes, com ara proves d’integració, proves d’usabilitat, proves d’acceptació d’usuaris i proves de rendiment.

Parlem breument d’aquestes etapes també:

Proves d'integració

Com ja sabeu, en una aplicació bancària hi pot haver diversos mòduls diferents, com ara transferències, pagaments de factures, dipòsits, etc. I, per tant, hi ha molts components desenvolupats. En les proves d'integració, tots els components s'integren junts i es validen.

Proves d’usabilitat

Proves d’usabilitat

Una aplicació bancària dóna servei a una àmplia varietat de clients. És possible que alguns d’aquests clients no tinguin les habilitats i la consciència necessàries per realitzar les tasques bancàries a través de l’aplicació.

Per tant, l'aplicació bancària s'hauria de provar per obtenir un disseny senzill i eficaç per fer-la útil en diferents grups de clients. Com més senzilla i fàcil d'utilitzar sigui la interfície, el major nombre de clients es beneficiarà de l'aplicació bancària.

Es tracta d’examinar el nivell de facilitat que tenen els usuaris empresarials o els clients dels bancs per utilitzar l’aplicació. Aquesta prova no la realitza el desenvolupador o el verificador, sinó que la realitzen els usuaris empresarials.

Per exemple, Avui en dia tothom utilitza aplicacions mòbils. L'aplicació bancària ha de ser fàcil d'utilitzar i fàcil d'entendre i utilitzar per l'usuari final.

Tipus de proves d’usabilitat

Proves d'usabilitat comparatives: Es tracta de proves basades en la comparació, on la facilitat d’ús d’un lloc web o aplicació amb un altre. L'objectiu d'aquesta prova és proporcionar la millor experiència d'usuari.

Proves d’usabilitat exploratòria: L’objectiu d’aquestes proves és identificar quines funcions hauria de tenir la nova aplicació o programari per satisfer les necessitats del client del banc.

A continuació es mostren els avantatges i els inconvenients de les proves d’usabilitat

preguntes d'entrevistes de domini d'assegurances d'analistes de negocis

Avantatges:

  • Els usuaris finals de l'aplicació solen participar en les proves, de manera que s'obté informació de primera mà.
  • En lloc de dedicar temps a l'anàlisi i la discussió sobre una característica que un producte hauria de tenir o no, és millor obtenir les aportacions de l'usuari final directament.
  • Podem detectar qualsevol problema potencial per endavant.

Desavantatges:

  • Com que diversos usuaris finals participen en les proves, les seves opinions, si no són precises, poden afectar el requisit.
  • El feed dels usuaris finals es pot veure influït.

Proves de rendiment

Alguns períodes de temps, com ara el dia de pagament, el final de l'exercici, les temporades festives, poden provocar canvis o augment del trànsit habitual a l'aplicació. Per tant, s’haurien de fer proves exhaustives del rendiment perquè els clients no es vegin afectats per fallades en el rendiment.

Un exemple significatiu del passat en què els clients bancaris es van veure afectats personalment a causa de fallades en el rendiment és l’aturada informàtica de dilluns cibernètics de NatWest i RBS en què els clients tenien la seva targeta de dèbit i crèdit rebuda de les transaccions entre botigues del país.

Proves d’acceptació d’usuaris

Això es fa implicant els usuaris finals per assegurar-se que l'aplicació compleix els escenaris del món real i que els usuaris seran acceptats si es publica.

En l’escenari actual la majoria dels projectes bancaris estan utilitzant : Metodologies Agile / Scrum, RUP i d’integració contínua i paquets d’eines, com ara VSTS i Rational Tools de Microsoft.

Com hem esmentat anteriorment sobre RUP, RUP significa Rational Unified Process, que és una metodologia de desenvolupament de programari iterativa introduïda per IBM que comprèn quatre fases en què es duen a terme activitats de desenvolupament i proves.

Són quatre fases
i) Inception
ii) Col·laboració
iii) Construcció i
iv) Transició

RUP implica àmpliament eines IBM Rational.

Exemples de casos de prova per a aplicacions bancàries

Casos de prova per a la nova sucursal

  • Creeu una branca nova amb dades de prova vàlides i no vàlides.
  • Creeu una branca nova sense dades.
  • Creeu una nova sucursal amb les dades de sucursal existents.
  • Verifiqueu les opcions de restabliment i cancel·lació.
  • Actualitzeu els detalls de la sucursal amb dades de prova vàlides i no vàlides.
  • Actualitzeu els detalls de sucursal amb les dades de prova de sucursal existents.
  • Verifiqueu si es pot desar la nova sucursal.
  • Verifiqueu que l'opció de cancel·lació funcioni.
  • Verifiqueu la supressió de sucursal amb i sense dependències.
  • Comproveu si l'opció de cerca de sucursals funciona.

Casos de prova per a un nou paper

  • Creeu un rol nou amb dades de prova vàlides i no vàlides.
  • Creeu un rol nou sense dades.
  • Verifiqueu que es pugui crear un nou rol amb les dades de prova existents.
  • Verifiqueu la descripció i els tipus de rol.
  • Verifiqueu que l'opció de cancel·lació i restabliment funcioni.
  • Verifiqueu el procés de supressió de funcions amb i sense dependència.
  • Verifiqueu els enllaços a la pàgina de detalls del rol.
  • Verifiqueu l'inici de sessió d'administrador sense dades de prova.
  • Verifiqueu tots els enllaços d'inici per al rol d'administrador.
  • Verifiqueu que l'administrador pugui canviar la contrasenya amb dades de prova vàlides i no vàlides.
  • Verifiqueu que la sessió d’administrador ha finalitzat correctament.

Casos de prova per a clients i banquers

  • Verifiqueu si tots els enllaços de visitants i clients funcionen correctament.
  • Verifiqueu l'inici de sessió del client amb dades de prova vàlides i no vàlides.
  • Verifiqueu l’inici de sessió del client sense dades.
  • Verifiqueu l'inici de sessió del banquer sense dades.
  • Verifiqueu l'inici de sessió del banquer amb dades de prova vàlides o no vàlides.
  • Verifiqueu que el client o el banquer pugui tancar la sessió correctament.

Prova de casos per a usuaris nous

  • Verifiqueu si es pot crear l'usuari nou amb dades de prova vàlides i no vàlides.
  • Creeu un usuari nou amb les dades de prova de sucursal existents
  • Verifiqueu si l'opció de cancel·lació i restabliment funciona correctament.
  • Actualitzeu les dades de l'usuari amb dades de prova vàlides i no vàlides.
  • Verifiqueu la supressió del nou usuari.
  • comproveu si es pot verificar el nou usuari.
  • Verifiqueu els paràmetres d'entrada obligatoris.
  • Verifiqueu els paràmetres d'entrada opcionals.
  • Verifiqueu si es pot crear un usuari sense paràmetres opcionals.

Prova de casos per a la creació d’un compte nou

  • Creeu un compte nou amb dades d'usuari vàlides i no vàlides.
  • Verifiqueu si es poden actualitzar les dades de l'usuari.
  • Verifiqueu si es pot desar un usuari nou.
  • Creeu un compte nou amb les dades de l’usuari existent.
  • Verifiqueu que l'usuari pugui ingressar l'import al compte recentment creat (i actualitzeu el saldo).
  • Verifiqueu que l'usuari pugui retirar una quantitat del compte nou (després del dipòsit i actualitzar el saldo).
  • En el cas del salari, l'usuari ha de comprovar el nom de l'empresa i altres dades.
  • Verifiqueu si es proporciona el número de compte principal en cas de compte secundari.
  • Verifiqueu les dades d’usuari proporcionades en els casos del compte corrent.
  • Verifiqueu les proves proporcionades per a un compte conjunt en cas de compte conjunt.
  • Verifiqueu si podeu mantenir un saldo zero al compte salarial.
  • Verifiqueu si podeu mantenir un saldo zero o un saldo mínim per al compte no salarial.
  • Verifiqueu que el nou usuari pugui tancar la sessió correctament.

Casos de prova per a aplicacions de banca en xarxa

  • Comproveu si l'usuari pot obrir el lloc bancari.
  • Comproveu si tots els enllaços del lloc funcionen.
  • Verifiqueu si l'usuari pot crear un compte nou.
  • Comproveu si l'usuari pot iniciar sessió amb un nom d'usuari i una contrasenya vàlids i no vàlids.
  • Verifiqueu si el nom d’usuari o la contrasenya estan en blanc mentre s’inicia la sessió, no s’hauria de permetre a l’usuari iniciar la sessió i es mostrarà un missatge d’alerta.
  • Comproveu si l'usuari té permís per canviar la contrasenya.
  • Si s'introdueix un usuari o una contrasenya no vàlids, es mostrarà el missatge d'error adequat.
  • No s’ha de permetre que els usuaris amb una contrasenya no vàlida iniciïn sessió.
  • Verifiqueu que després de repetits intents d’inici de sessió amb una contrasenya incorrecta, s’hauria de mostrar a l’usuari un missatge d’error i bloquejar-lo.
  • Comproveu si l'usuari pot realitzar algunes transaccions bàsiques.
  • Verifiqueu que l'usuari pugui afegir un beneficiari amb dades vàlides i no vàlides.
  • Verifiqueu si l'usuari pot suprimir el beneficiari.
  • Verifiqueu que l'usuari pugui fer transaccions amb el nou beneficiari afegit.
  • Després de la transacció, verifiqueu si s’actualitzen els comptes de l’usuari i del beneficiari.
  • Comproveu si l'usuari pot introduir l'import en nombre decimal.
  • Verifiqueu si l'usuari no pot introduir números negatius al camp Import.
  • Verifiqueu si l'usuari pot fer transaccions amb saldo mínim o sense.
  • Verifiqueu si l'usuari pot fer un RD nou.
  • Verifiqueu que es mostri el missatge adequat en cas que la transacció es faci amb un saldo insuficient.
  • Comproveu si es demana confirmació a l'usuari abans de fer qualsevol transacció.
  • Verifiqueu si es proporciona un rebut de confirmació en cada transacció reeixida.
  • Verifiqueu si l'usuari pot transferir diners a diversos comptes.
  • comproveu si l'usuari pot cancel·lar la transacció.
  • Verifiqueu que els detalls del compte també reflecteixin les transaccions financeres realitzades.
  • Verifiqueu que la funció de temps d'espera estigui implementada.
  • comproveu que en cas de temps d’espera de sessió, l’usuari hauria de tornar a iniciar la sessió.
  • comproveu que es realitzi un temps d’espera de sessió adequat en cas d’inactivitat.
  • comproveu que, mentre realitza la transacció, l'usuari es porta al mode segur.
  • Verifiqueu si l'usuari pot tancar la sessió correctament.
  • Verifiqueu les opcions de cerca i restabliment.

Conclusió

En aquest article, hem parlat quant de complexa podria ser una aplicació bancària i què són els fases típiques de la prova de l'aplicació . A part d'això, també vam discutir les tendències actuals seguides per les indústries de TI, incloses les metodologies i eines de desenvolupament de programari.

No dubteu a compartir la vostra experiència o consultes sobre aquest tema.

Lectura recomanada

^