뱅킹 도메인 애플리케이션 테스트: 샘플 테스트 사례

뱅킹 도메인 테스트

뱅킹 도메인 테스트 기능, 성능 및 보안에 대한 뱅킹 애플리케이션의 소프트웨어 테스트 프로세스입니다. 뱅킹 애플리케이션을 테스트하는 주요 목적은 뱅킹 소프트웨어의 모든 활동과 기능이 오류 없이 원활하게 실행되고 보호되는 상태를 유지하는지 확인하는 것입니다.

BFSI(은행, 금융 서비스 및 보험) 부문은 IT 서비스의 가장 큰 소비자입니다. 뱅킹 애플리케이션은 기밀 금융 데이터를 직접 처리합니다. 뱅킹 소프트웨어가 수행하는 모든 활동은 오류 없이 원활하게 실행되어야 합니다. 뱅킹 소프트웨어는 자금 이체 및 예금, 잔액 조회, 거래 내역, 출금 등과 같은 다양한 기능을 수행합니다. 뱅킹 애플리케이션을 테스트하면 이러한 활동이 제대로 실행될 뿐만 아니라 해커로부터 보호되는 상태도 유지됩니다.

라이브 뱅킹 테스트 프로젝트에 무료로 참여하세요

테스트에서 도메인이란 무엇입니까?

테스트 중인 도메인 소프트웨어 테스팅 프로젝트가 만들어지는 산업에 지나지 않습니다. 소프트웨어 프로젝트나 개발에 관해 이야기할 때 이 용어가 자주 언급됩니다. 예를 들어 보험 도메인, 은행 도메인, 소매 도메인, 통신 도메인 등이 있습니다.

일반적으로 특정 도메인 프로젝트를 개발하는 동안 도메인 전문가의 도움을 구합니다. 도메인 전문가는 해당 주제의 마스터이며 제품이나 애플리케이션의 내부를 알고 있을 수 있습니다.

도메인 지식이 중요한 이유는 무엇입니까?

도메인 지식은 모든 소프트웨어 제품을 테스트하는 데 필수적이며 다음과 같은 고유한 이점이 있습니다.

뱅킹 도메인 지식 - 소개

은행 도메인 개념은 방대하며 기본적으로 두 부문으로 세분화됩니다.

전통적인 은행 부문
서비스 기반 금융 부문

다음은 은행의 두 하위 부문이 포함하는 서비스 표입니다.

전통적인 은행 부문	코어 뱅킹 기업 금융 소매 금융
서비스 기반 금융 부문	핵심 Corporate 소매 차관 무역 금융 프라이빗 뱅킹 소비자 금융 이슬람 뱅킹 고객 전달 채널/프런트엔드 전달

프로젝트 범위에 따라 위의 서비스 제공 중 하나 또는 모두를 테스트해야 할 수도 있습니다. 테스트를 시작하기 전에 테스트 중인 서비스에 대한 배경 지식이 충분한지 확인하세요.

뱅킹 애플리케이션의 특성

테스트를 시작하기 전에 모든 뱅킹 애플리케이션에서 기대되는 표준 기능을 알아두는 것이 중요합니다. 따라서 이러한 특성을 달성하기 위해 테스트 노력을 기울일 수 있습니다.

표준 뱅킹 애플리케이션은 아래에 언급된 이러한 모든 특성을 충족해야 합니다.

수천 개의 동시 사용자 세션을 지원해야 합니다.
뱅킹 애플리케이션은 거래 계좌와 같은 다른 수많은 애플리케이션과 통합되어야 합니다. Bill 공과금, 신용카드 등을 지불합니다.
빠르고 안전한 거래를 처리해야 합니다.
대용량 저장 시스템을 포함해야 합니다.
고객 문제를 해결하려면 높은 감사 능력이 있어야 합니다.
복잡한 비즈니스 워크플로를 처리해야 합니다.
다양한 플랫폼(Mac, Linux, Unix, Windows)
여러 위치의 사용자를 지원해야 합니다.
다국어 사용자를 지원해야 합니다.
다양한 결제 시스템(VISA, AMEX, MasterCard) 사용자를 지원해야 합니다.
다양한 서비스 부문(대출, 소매 금융 등)을 지원해야 합니다.
완벽한 재난 관리 메커니즘

뱅킹 애플리케이션 테스트의 테스트 단계

뱅킹 애플리케이션 테스트를 위한 다양한 테스트 단계는 다음과 같습니다.

요구 사항 분석 : 이는 비즈니스 분석가가 수행합니다. 특정 뱅킹 애플리케이션에 대한 요구 사항을 수집하고 문서화합니다.
요구 사항 Review : 품질 분석가, 비즈니스 분석가 및 개발 리더가 이 작업에 참여합니다. 이 단계에서는 요구사항 수집 문서를 검토하고, 워크플로에 영향을 주지 않는지 확인하기 위해 교차 점검합니다.
비즈니스 요구 사항 문서: 검토된 모든 비즈니스 요구 사항이 포함된 품질 분석가가 비즈니스 요구 사항 문서를 준비합니다.
데이터베이스 테스트: 은행 애플리케이션 테스트에서 가장 중요한 부분입니다. 이 테스트는 데이터 무결성, 데이터 로딩, 데이터 마이그레이션, 저장 프로시저, 기능 유효성 검사, 규칙 테스트 등을 보장하기 위해 수행됩니다.
통합 테스트 : $XNUMX Million 미만 통합 테스팅 개발된 모든 구성요소는 통합되고 검증됩니다.
기능 테스트 : 다음과 같은 일반적인 소프트웨어 테스트 활동 테스트 케이스 준비, 테스트 케이스 검토 및 테스트 케이스 실행은 이 단계에서 수행됩니다.
보안 테스트 : 소프트웨어에 보안 결함이 없는지 확인합니다. 테스트 준비 중에 QA 팀은 부정적인 테스트 시나리오와 긍정적인 테스트 시나리오를 모두 포함하여 시스템에 침입하여 무단 개인이 시스템에 액세스하기 전에 이를 보고해야 합니다. 해킹을 방지하기 위해 은행은 일회용 비밀번호와 같은 다층적인 접근 검증도 구현해야 합니다. 을 위한 보안 테스트, 다음과 같은 자동화 도구 IBM AppScan 및 HPWebInspect는 다음과 같은 경우에 사용됩니다. 수동 테스트 Proxy Sniffer, Paros Proxy, HTTP watch 등과 같은 도구가 사용됩니다.
사용성 테스트: 이는 다양한 능력을 갖춘 사람들이 일반 사용자처럼 시스템을 사용할 수 있도록 보장합니다. 예: 장애인을 위한 청각 및 점자 시설을 갖춘 ATM
사용자 수락 테스트: 애플리케이션이 실제 시나리오와 호환되는지 확인하기 위해 최종 사용자가 수행하는 테스트의 마지막 단계입니다.

Net Banking 로그인 애플리케이션에 대한 샘플 테스트 케이스

모든 은행 애플리케이션에는 보안이 가장 중요합니다. 따라서 테스트 준비 중에 QA 팀은 승인되지 않은 개인이 시스템에 액세스하기 전에 시스템에 몰래 들어가 취약점을 보고하기 위해 부정적인 테스트 시나리오와 긍정적인 테스트 시나리오를 모두 포함해야 합니다. 여기에는 부정적인 테스트 사례 작성이 포함될 뿐만 아니라 파괴적인 테스트도 포함될 수 있습니다.

다음은 모든 은행 애플리케이션을 확인하기 위한 일반 테스트 사례입니다.

샘플 테스트 케이스
관리자용	유효한 데이터와 유효하지 않은 데이터로 관리자 로그인을 확인하세요. 데이터 없이 관리자 로그인 확인 모든 관리자 홈 링크 확인 유효한 데이터와 유효하지 않은 데이터로 관리자 변경 비밀번호를 확인하세요. 데이터 없이 관리자 변경 비밀번호 확인 기존 데이터로 관리자 변경 비밀번호 확인 관리자 로그아웃 확인
새로운 지점의 경우	유효한 데이터와 유효하지 않은 데이터로 새 분기를 만듭니다. 데이터 없이 새 분기 만들기 기존 지점 데이터로 새 지점 생성 재설정 확인 및 취소 옵션 유효한 데이터와 잘못된 데이터로 분기 업데이트 데이터 없이 분기 업데이트 기존 지점 데이터로 지점 업데이트 취소 옵션 확인 종속성이 있거나 없는 분기 삭제 확인 지점 검색 옵션 확인
새로운 역할의 경우	유효한 데이터와 유효하지 않은 데이터로 새 역할을 만듭니다. 데이터 없이 새 역할 만들기 기존 데이터로 새 역할 확인 역할 설명 및 역할 유형 확인 취소 및 재설정 옵션 확인 종속성이 있거나 없는 역할 삭제 확인 역할 세부 정보 페이지에서 링크 확인
고객 및 방문객을 위한	모든 방문자 또는 고객 링크를 확인하세요. 유효한 데이터와 유효하지 않은 데이터로 고객 로그인을 확인합니다. 데이터 없이 고객 로그인 확인 데이터 없이 은행원의 로그인을 확인하세요 유효하거나 유효하지 않은 데이터로 은행가의 로그인을 확인하십시오.
신규 사용자의 경우	유효한 데이터와 유효하지 않은 데이터로 새 사용자를 만듭니다. 데이터 없이 새 사용자 만들기 기존 지점 데이터로 새 사용자 생성 취소 및 재설정 옵션 확인 유효한 데이터와 잘못된 데이터로 사용자 업데이트 기존 데이터로 사용자 업데이트 취소 옵션 확인 사용자 삭제 확인

뱅킹 도메인 테스트 및 완화의 과제

뱅킹 도메인을 테스트하는 동안 테스터가 직면할 수 있는 문제는 다음과 같습니다.

과제	완화
테스트를 위해 프로덕션 데이터에 액세스하고 이를 테스트 데이터로 복제하는 것은 어렵습니다.	테스트 데이터가 규정 준수 요구 사항 및 지침을 충족하는지 확인하십시오. 데이터 마스킹, 합성 테스트 데이터, 테스트 시스템 통합 등의 기술을 통해 데이터의 기밀성을 유지합니다.
뱅킹 시스템 테스트에서 가장 큰 과제는 모든 루틴, 절차 및 계획을 테스트하는 등 기존 시스템에서 새 시스템으로 시스템을 마이그레이션하는 과정입니다. 또한 마이그레이션 후 데이터를 가져오고, 업로드하고, 새 시스템으로 전송하는 방법	데이터 마이그레이션 테스트가 완료되었는지 확인하세요. 회귀 테스트 사례가 기존 시스템과 새 시스템에서 실행되고 결과가 일치하는지 확인하세요.
요구 사항이 잘 문서화되지 않아 테스트 계획에 기능적 격차가 발생할 수 있는 경우가 있을 수 있습니다. 많은 비기능적 요구사항은 완전히 문서화되지 않았으며 테스터는 이를 테스트할지 여부를 모릅니다.	테스터는 요구 사항 분석 단계부터 프로젝트에 참여해야 하며 비즈니스 요구 사항을 적극적으로 검토해야 합니다.
가장 중요한 점은 해당 시스템이 원하는 정책과 절차를 따르고 있는지 확인하는 것입니다.	규정 준수 또는 규제 정책 테스트를 수행해야 합니다.
뱅킹 애플리케이션이 인터넷이나 인터넷 같은 다른 애플리케이션과 통합됨에 따라 범위와 일정이 늘어납니다. 모바일 은행	뱅킹 애플리케이션에 외부 인터페이스가 많은 경우 통합 테스트에 대한 시간 예산이 고려되었는지 확인하세요.

요약

은행 영역은 사이버 도난에 가장 취약한 영역이며, 소프트웨어를 보호하려면 정밀한 테스트가 필요합니다. 이 튜토리얼은 뱅킹 도메인 테스트에 무엇이 필요하고 그것이 얼마나 중요한지에 대한 명확한 아이디어를 제공합니다. 다음을 이해해야 합니다.

대부분의 뱅킹 소프트웨어는 다음에서 개발됩니다. 메인 프레임 and 유닉스
테스트는 소프트웨어 개발 중에 발생할 수 있는 결함을 줄이는 데 도움이 됩니다.
업계 표준에 대한 적절한 테스트 및 규정 준수로 기업이 처벌을 받지 않게 됩니다.
모범 사례는 회사의 좋은 결과, 평판 및 더 많은 비즈니스를 발전시키는 데 도움이 됩니다.
수동 테스트와 자동 테스트 모두 각각의 장점과 유용성을 가지고 있습니다.

우리의 가입 라이브뱅킹 도메인 테스트 프로젝트

당신은 좋아할 것입니다 :