how test banking domain applications
뱅킹 애플리케이션 테스트에 대한 완벽한 가이드 : BFSI (뱅킹, 금융 서비스 및 보험) 테스트 프로세스 및 팁
뱅킹 애플리케이션은 오늘날의 소프트웨어 개발 및 테스트 업계에서 가장 복잡한 애플리케이션 중 하나입니다.
뱅킹 애플리케이션을 그렇게 복잡하게 만드는 것은 무엇입니까? 은행 애플리케이션과 관련된 복잡한 워크 플로를 테스트하려면 어떤 접근 방식을 따라야합니까?
이 기사에서는 뱅킹 애플리케이션 테스트와 관련된 다양한 단계와 기술을 강조 할 것입니다.
학습 내용 :
은행 애플리케이션을 테스트하는 방법?
뱅킹 애플리케이션에서 수행하는 다양한 기능은 다음과 같습니다.
먼저 뱅킹 애플리케이션의 특성을 이해하겠습니다.
- 수천 개의 동시 사용자 세션을 지원하는 다중 계층 기능
- 대규모 통합 : 일반적으로 은행 애플리케이션은 Bill Pay 유틸리티 및 거래 계정과 같은 수많은 다른 애플리케이션과 통합됩니다.
- 복잡한 비즈니스 워크 플로우
- 실시간 및 일괄 처리
- 초당 높은 트랜잭션 비율
- 안전한 거래
- 일상적인 거래를 추적하는 강력한보고 섹션
- 고객 문제 해결을위한 강력한 감사
- 대용량 저장 시스템
- 재해 / 복구 관리.
위에 나열된 10 가지 포인트는 은행 애플리케이션의 가장 중요한 특성.
뱅킹 애플리케이션에는 작업 수행과 관련된 여러 계층이 있습니다.
예를 들어 , ~ 은행 애플리케이션에는 다음이있을 수 있습니다.
- 브라우저를 통해 최종 사용자와 상호 작용하는 웹 서버
- 웹 서버에 대한 입력 및 출력을 확인하는 중간 계층
- 데이터 및 절차를 저장하는 데이터베이스
- 초당 수조 건의 트랜잭션을 수행하는 대용량 메인 프레임 또는 기타 레거시 시스템이 될 수있는 트랜잭션 프로세서.
은행 애플리케이션 테스트에 대해 이야기하는 경우 다음을 보장하기 위해 여러 소프트웨어 테스트 기술을 포함하는 종단 간 테스트 방법론 :
- 모든 뱅킹 워크 플로우 및 비즈니스 요구 사항의 전체 범위
- 응용 프로그램의 기능적 측면
- 애플리케이션의 보안 측면
- 데이터 무결성
- 동시성
- 사용자 경험
뱅킹 애플리케이션을 그렇게 복잡하게 만드는 것은 무엇입니까?
- 은행 소프트웨어는 주로 기밀 재무 데이터를 처리하므로 소프트웨어 성능은 오류가없고 안전해야합니다.
- 개발자는 애플리케이션이 원하는 보안 방식으로 실행되도록하기 위해 이러한 애플리케이션을 개발하는 데 복잡한 디자인을 선호합니다.
- 은행 업무는 끊임없이 변화하는 세상입니다. 오늘날 뱅킹은 오프라인 지점, ATM, 온라인 뱅킹 및 고객 관리와 같은 다양한 채널을 사용하여 고객에게 제공됩니다.
- 기술의 출현으로 많은 지갑이 금융 거래를 위해 은행 시스템에 연결되는 시장에 넘쳐났습니다.
- 뱅킹은 또한 고성능으로 연중 무휴 24 시간 가동 될 것으로 예상됩니다. 소프트웨어 업그레이드, 즉각적인 수정 등은이 가용성에 영향을주지 않습니다.
- 은행 세계는 또한 은행 규제의 형태로 정부가 가져 오는 끊임없는 변화에 큰 영향을받습니다. 세금 구조의 변화는 은행 시스템에도 영향을 미칩니다.
- 은행 시스템은 또한 새로운 기술에 관한 한 최신 상태를 유지해야합니다. 빅 데이터 처리와 같은 데이터 분석 및 데이터 사이언스를 사용하여 빅 데이터에서 본능을 얻는 것은 은행 세계에서 견인력이 증가하고 있습니다.
위에서 언급 한 점은 개발자가 주변에 소프트웨어 응용 프로그램을 만들 수있는 은행 시스템을 복잡하게 만듭니다.
뱅킹 애플리케이션 테스트의 중요성
- 뱅킹 애플리케이션을 테스트하면 모든 활동이 잘 실행될뿐만 아니라 보호 및 보안 상태가 유지됩니다.
- 뱅킹 소프트웨어는 수천 개의 종속성으로 복잡하고 테스트 프로세스에는 더 많은 시간, 리소스 및 지속적인 모니터링이 필요합니다.
- 여기에 재정이 관련되어 있으므로 지침을 엄격하게 따라야합니다. 테스터와 개발자 모두 좋은 도메인 지식이 있어야합니다.
- 가장 중요한 것은 금융 거래에서 법과 규정이 올바르게 시행되고 있는지 확인해야한다는 것입니다. 이것은 테스트를 통해서만 보장 될 수 있습니다.
- 또한 애플리케이션과 애플리케이션이 배포 된 인프라가 업무 중단없이 특히 피크 업무 시간 동안로드를 처리 할 수 있는지 확인하는 것도 중요합니다. 이는 성능 테스트를 수행하여 확인할 수 있습니다.
- 오늘날의 디지털 세상에서 모든 사람이 염려하는 한 가지는 보안입니다. 은행 애플리케이션과 그 안에서 수행되는 금융 거래는 침입 시도로부터 안전해야합니다. 이는 보안 테스트를 수행하여 확인할 수 있습니다. 보안 테스트는 금융 거래를 보호하기 위해 산업 표준을 시행하는 데 도움이됩니다.
- 뱅킹 애플리케이션의 다양한 모듈이 적절하게 통합되고 고객의 목표를 달성하도록하는 것도 중요합니다. 시스템 통합 테스트는이 작업을 수행하는 데 도움이됩니다.
뱅킹 앱 테스트 워크 플로
은행 애플리케이션 테스트와 관련된 일반적인 단계 아래 워크 플로에 나와 있습니다. 각 단계를 개별적으로 논의 할 것입니다.
이것은 애플리케이션을 테스트하는 Waterfall 모델입니다.
# 1) 요구 사항 수집
요구 사항 수집 단계 기능 사양 또는 사용 사례로 요구 사항 문서를 포함합니다. 요구 사항은 고객 요구 사항에 따라 수집되고 은행 전문가 또는 비즈니스 분석가가 문서화합니다.
은행 자체에는 여러 하위 도메인이 있고 하나의 본격적인 은행 애플리케이션이 이러한 모든 도메인을 통합하기 때문에 전문가는 둘 이상의 주제에 대한 요구 사항을 작성하는 데 관여합니다.
예를 들어, 은행 애플리케이션에는 이체, 신용 카드, 보고서, 대출 계정, 청구서 지불, 거래 등을위한 별도의 모듈이있을 수 있습니다.
# 2) 요구 사항 검토
요구 사항 수집의 결과물은 QA 엔지니어, 개발 책임자 및 피어 비즈니스 분석가와 같은 모든 이해 관계자가 검토합니다.
기존 비즈니스 워크 플로 나 새 워크 플로가 위반되지 않았는지 교차 확인합니다. 모든 요구 사항이 확인되고 검증됩니다. 후속 조치 및 요구 사항 문서 개정도 동일한 기준으로 수행됩니다.
# 3) 비즈니스 시나리오 준비
이 단계에서 QA 엔지니어는 요구 사항 문서 (기능 사양 또는 사용 사례)에서 비즈니스 시나리오를 도출합니다. 비즈니스 시나리오는 모든 비즈니스 요구 사항이 포함되는 방식으로 파생됩니다. 비즈니스 시나리오는 세부 단계가없는 높은 수준의 시나리오입니다.
또한 비즈니스 분석가는 이러한 비즈니스 시나리오를 검토하여 모든 비즈니스 요구 사항이 충족되는지 확인합니다. BA가 낮은 수준의 세부 테스트 사례를 검토하는 것보다 높은 수준의 시나리오를 검토하는 것이 더 쉽습니다.
예를 들면 , 디지털 뱅킹 인터페이스에서 고정 예금을 여는 고객은 비즈니스 시나리오가 될 수 있습니다. 마찬가지로, 넷 뱅킹 계좌 생성, 온라인 입금, 온라인 이체 등과 관련된 다양한 비즈니스 시나리오를 가질 수 있습니다.
# 4) 기능 테스트
이 단계에서는 기능 테스트가 수행되고 다음과 같은 일반적인 소프트웨어 테스트 활동이 수행됩니다.
테스트 케이스 준비 : 이 단계에서 테스트 케이스는 비즈니스 시나리오에서 파생되고 하나의 비즈니스 시나리오는 여러 긍정적 인 테스트 케이스와 부정적인 테스트 케이스로 이어집니다. 일반적으로이 단계에서 사용되는 도구는 Microsoft Excel, Test Director 또는 Quality Center입니다.
테스트 사례 검토 : 동료 QA 엔지니어의 리뷰
테스트 케이스 실행: 테스트 케이스 실행은 QC, QTP 등과 같은 도구를 포함하는 수동 또는 자동 일 수 있습니다.
뱅킹 애플리케이션의 기능 테스트는 일반 소프트웨어 테스트와 상당히 다릅니다. 이러한 애플리케이션은 고객의 돈과 민감한 재무 데이터로 작동하기 때문에 철저한 테스트를 거쳐야합니다. 중요한 비즈니스 시나리오를 다루지 않아야합니다.
또한 애플리케이션을 테스트하는 QA 리소스는 은행 도메인에 대한 기본 지식이 있어야합니다.
# 5) 데이터베이스 테스트
뱅킹 애플리케이션은 UI 수준과 데이터베이스 수준 모두에서 수행되는 복잡한 트랜잭션을 포함하므로 데이터베이스 테스트는 기능 테스트만큼 중요합니다. 데이터베이스는 복잡하고 응용 프로그램에서 완전히 분리 된 계층이므로 데이터베이스 전문가가 테스트를 수행합니다. 다음과 같은 기술을 사용합니다.
- 데이터 로딩
- 데이터베이스 마이그레이션
- DB 스키마 및 데이터 유형 테스트
- 규칙 테스트
- 저장 프로 시저 및 함수 테스트
- 트리거 테스트
- 데이터 무결성
데이터베이스 테스트의 주요 목적은 다음을 확인하는 것입니다.
- 애플리케이션은 데이터 손실없이 데이터베이스에서 데이터를 저장하고 검색 할 수 있습니다.
- 완료된 트랜잭션을 커밋하고 중단 된 트랜잭션을 되돌려 저장된 데이터의 불일치를 방지합니다.
- 권한이있는 애플리케이션과 사용자 만 데이터베이스와 기본 테이블에 액세스 할 수 있습니다.
데이터베이스 테스트에는 주로 세 가지 방법이 있습니다.
- 구조 테스트
- 기능 테스트
- 비 기능 테스트
구조 테스트
여기에는 데이터베이스, 스키마, 테이블, 뷰, 트리거, 액세스 제어 등과 같은 데이터베이스 개체 테스트가 포함됩니다. 테이블의 데이터 유형이 애플리케이션의 해당 변수와 동기화되었는지 확인합니다. 테이블에서 데이터 및 참조 무결성을 검증합니다.
예를 들어, 애플리케이션의 금액 필드는 테이블에서 10 진수 / 부동 소수점 데이터 유형을 가져야합니다.
– 표준을 준수하려면보기를 통해 사용자에게 액세스 제어를 제공해야합니다.
기능 테스트
여기에는 사용자 요구 사항을 충족하는 데이터베이스 테스트가 포함됩니다. 달성하는 방법에는 블랙 박스 테스트와 화이트 박스 테스트의 두 가지가 있습니다.
예를 들어, 우리가 온라인 송금을 할 때, 송금인 계정은 인출되어야하고 수취인 계정은 정확히 같은 금액으로 입금되어야합니다. 거래가 실패하면 전체 거래를 되돌려 야하며 발신자 계정은 인출되거나 환불되지 않아야합니다.
비 기능 테스트
여기에는 부하 및 스트레스 테스트와 성능 최적화가 포함됩니다. 로드 테스트는 데이터베이스 성능에 영향을주지 않고 동시에 수행 할 수있는 가장 많은 수의 트랜잭션을 식별하는 데 도움이됩니다.
예를 들어, 로드 및 스트레스 테스트의 입력을 기반으로 뱅킹 애플리케이션은 피크 업무 시간 동안 애플리케이션에 더 많은 리소스를 추가하고 업무 외 시간 동안 리소스를 줄이기로 결정할 수 있습니다. 이를 통해 은행은 자원을 최적으로 사용하고 비용을 절감 할 수 있습니다.
# 6) 보안 테스트
보안 테스트는 일반적으로 테스트주기의 마지막 단계입니다. 보안 테스트를 시작하기위한 전제 조건은 기능 및 비 기능 테스트를 완료하는 것입니다. 보안 테스트는 전체 애플리케이션 테스트주기의 주요 단계 중 하나입니다.이 단계에서는 애플리케이션이 연방 및 산업 표준을 준수하는지 확인합니다.
보유하는 데이터의 특성으로 인해 뱅킹 앱은 매우 민감하며 해커 및 사기 행위의 주요 표적이됩니다. 보안 테스트는 애플리케이션에 침입자 나 공격자에게 민감한 데이터를 노출 할 수있는 웹 취약점이 없는지 확인합니다. 또한 응용 프로그램이 OWASP와 같은 표준을 준수 함을 보장합니다.
이 단계에서 주요 작업은 IBM AppScan 또는 IBM AppScan과 같은 도구를 사용하여 수행되는 전체 애플리케이션 스캔입니다. HP WebInspect (이것들이 가장 많이 사용되는 도구입니다).
스캔이 완료되면 스캔 보고서가 게시됩니다. 이 보고서에서 오 탐지가 필터링되고 나머지 취약성은 개발 팀에보고되어 각 문제의 심각도에 따라 문제를 해결하기 시작합니다.
침투 테스트도이 단계에서 수행되어 오류 전파를 확인합니다. 플랫폼, 네트워크 및 OS에 걸쳐 엄격한 보안 테스트를 수행해야합니다.
기타 보안 테스트를위한 수동 도구 사용은 파로스 프록시 , HTTP 감시 , Burp 스위트 , 및 확고히 하다.
보안 테스트의 주요 목적은 소프트웨어 애플리케이션에있을 수있는 모든 취약성을 정확히 찾아내는 것입니다.
보안 테스트는 다음에 대해 애플리케이션을 테스트합니다.
- 외부 공격 또는 악의적 인 의도로 애플리케이션을 해킹하려는 시도.
- 소프트웨어 응용 프로그램의 모든 허점은 악용되어 데이터 또는 금전적 손실을 초래할 수 있습니다.
- 애플리케이션을 호스팅하는 네트워크, 서버 및 워크 스테이션의 모든 취약성.
다음은 다양한 유형의 보안 테스트입니다.
취약점 테스트 : 다양한 취약점을 확인하기 위해 자동화 된 프로그램을 개발하고 실행합니다.
보안 검색 : 이 변종은 네트워크 및 시스템 취약성을 조사하고 관련 위험을 줄이는 솔루션을 제공합니다.
침투 테스트 : 이 보안 테스트의 변형은 취약성과 허점을 포착하려는 해킹 시도를 모방하며, 그렇지 않으면 데이터베이스 또는 애플리케이션 데이터에 액세스 할 수 있습니다.
보안 감사 : 여기에는 보안 결함에 대한 애플리케이션 및 관련 네트워크 감사가 포함됩니다.
위험 평가 : 이 변종은 악의적 인 의도로 취약성 또는 허점이 악용되는 경우 위험 수준을 평가하기위한 분석을 수행합니다. 이러한 위험은 낮음, 중간, 높음으로 분류 할 수 있습니다. 위험 수준에 따라 테스트 팀은 위험을 줄이거 나 방지하기 위해 적절한 조치를 권장합니다.
윤리적 해킹 : 이는 조직이 애플리케이션이나 네트워크에서 악용 될 수있는 허점을 식별하기 위해 시스템에서 수행합니다. 이러한 종류의 해킹의 목적은 애플리케이션이나 네트워크를 훔치거나 손상을 입히는 것이 아닙니다.
자세 평가 : 이것은 보안 스캔, 위험 평가 및 윤리적 해킹으로 구성된 포괄적 인 평가입니다.
SQL 주입 : SQL 주입을 사용하여 서버 데이터베이스에 액세스 할 수 있습니다. 테스트는 코드가 올바르게 작동하는지 확인하기 위해 수행되며 사용자의 다음 입력을 기반으로 데이터베이스에서 쿼리를 실행합니다.
- 브래킷
- 아포스트로피
- 쉼표
- 인용 부호
BFSI 앱 테스트의 다른 단계
위의 주요 단계 외에도 통합 테스트, 사용성 테스트, 사용자 승인 테스트 및 성능 테스트와 같은 여러 단계가 관련 될 수 있습니다.
이러한 단계에 대해서도 간략히 설명하겠습니다.
통합 테스트
아시다시피 뱅킹 애플리케이션에는 이체, 청구서 지불, 예금 등과 같은 여러 가지 모듈이있을 수 있습니다. 따라서 많은 구성 요소가 개발되었습니다. 통합 테스트에서 모든 구성 요소가 함께 통합되고 검증되었습니다.
사용성 테스트
뱅킹 애플리케이션은 다양한 고객에게 서비스를 제공합니다. 이러한 고객 중 일부는 앱을 통해 뱅킹 작업을 수행하는 데 필요한 기술과 인식이 부족할 수 있습니다.
따라서 뱅킹 애플리케이션은 여러 고객 그룹에서 사용할 수 있도록 간단하고 효율적인 디자인을 테스트해야합니다. 더 간단하고 사용하기 쉬운 인터페이스는 더 많은 고객이 뱅킹 응용 프로그램의 혜택을받을 수 있다는 것입니다.
비즈니스 사용자 또는 은행 고객이 애플리케이션을 사용하는 데있어 얼마나 쉬운 지 검토하는 것입니다. 이 테스트는 개발자 나 테스터가 수행하지 않고 비즈니스 사용자가 수행합니다.
예를 들어, 요즘은 누구나 모바일 앱을 사용합니다. 뱅킹 앱은 사용자 친화적이어야하며 최종 사용자가 이해하고 사용하기 쉬워야합니다.
사용성 테스트 유형
비교 사용성 테스트 : 이것은 하나의 웹 사이트 또는 응용 프로그램을 다른 웹 사이트와 쉽게 사용할 수있는 비교 기반 테스트입니다. 이러한 테스트의 목표는 최상의 사용자 경험을 제공하는 것입니다.
탐색 적 사용성 테스트 : 이 테스트의 목적은 은행의 고객 요구 사항을 충족하기 위해 새 응용 프로그램이나 소프트웨어에 어떤 기능이 있어야하는지 확인하는 것입니다.
다음은 사용성 테스트의 장단점입니다.
데스크탑 지원 엔지니어 인터뷰 질문 및 답변
장점 :
- 응용 프로그램의 최종 사용자는 일반적으로 테스트에 참여하므로 직접 피드백을 얻습니다.
- 제품에 있어야 할 기능에 대한 분석 및 토론에 시간을 소비하는 것보다 최종 사용자로부터 직접 입력을받는 것이 좋습니다.
- 잠재적 인 문제를 미리 파악할 수 있습니다.
단점 :
- 여러 최종 사용자가 테스트에 참여하기 때문에 정확하지 않더라도 그들의 의견이 요구 사항에 영향을 미칠 수 있습니다.
- 최종 사용자의 피드가 영향을받을 수 있습니다.
성능 시험
월급 날, 회계 연도 말, 축제 시즌과 같은 특정 기간은 앱의 일반적인 트래픽에 변화를 가져 오거나 급증 할 수 있습니다. 따라서 고객이 성능 장애의 영향을받지 않도록 철저한 성능 테스트를 수행해야합니다.
은행 고객이 성능 실패로 인해 개인적으로 영향을받은 과거의 중요한 예는 NatWest 및 RBS 사이버 먼데이 IT 중단으로, 고객이 직불 카드를 사용하고 신용 카드가 전국 상점에서 거래가 거부 된 경우입니다.
사용자 수락 테스트
이는 최종 사용자를 참여시켜 애플리케이션이 실제 시나리오를 준수하고 라이브 상태가되면 사용자가 수락하도록합니다.
오늘의 시나리오에서 대부분의 은행 프로젝트는 : Agile / Scrum, RUP 및 지속적 통합 방법론과 Microsoft의 VSTS 및 Rational 도구와 같은 도구 패키지
위에서 RUP에 대해 언급했듯이 RUP는 Rational Unified Process의 약자로, IBM이 도입 한 반복적 인 소프트웨어 개발 방법론으로, 개발 및 테스트 활동이 수행되는 4 단계로 구성됩니다.
4 단계는
i) 시작
ii) 협업
iii) 건설 및
iv) 전환
RUP에는 IBM Rational 도구가 광범위하게 포함됩니다.
은행 애플리케이션에 대한 샘플 테스트 케이스
새 지점에 대한 테스트 사례
- 유효하고 유효하지 않은 테스트 데이터로 새 분기를 만듭니다.
- 데이터없이 새 분기를 만듭니다.
- 기존 분기 데이터로 새 분기를 만듭니다.
- 재설정 및 취소 옵션을 확인하십시오.
- 유효하고 유효하지 않은 테스트 데이터로 분기 세부 사항을 업데이트하십시오.
- 기존 분기 테스트 데이터로 분기 세부 정보를 업데이트합니다.
- 새 분기를 저장할 수 있는지 확인하십시오.
- 취소 옵션이 작동하는지 확인하십시오.
- 종속성이 있거나없는 분기 삭제를 확인합니다.
- 지점 검색 옵션이 작동하는지 확인하십시오.
새로운 역할에 대한 테스트 사례
- 유효하고 잘못된 테스트 데이터로 새 역할을 만듭니다.
- 데이터없이 새 역할을 만듭니다.
- 기존 테스트 데이터로 새 역할을 만들 수 있는지 확인합니다.
- 역할 설명 및 역할 유형을 확인하십시오.
- 취소 및 재설정 옵션이 작동하는지 확인하십시오.
- 종속성이 있거나없는 역할 삭제 프로세스를 확인합니다.
- 역할 세부 사항 페이지에서 링크를 확인하십시오.
- 테스트 데이터없이 관리자 로그인을 확인하십시오.
- 관리자 역할에 대한 모든 홈 링크를 확인하십시오.
- 관리자가 유효하고 잘못된 테스트 데이터로 비밀번호를 변경할 수 있는지 확인합니다.
- 관리자가 성공적으로 로그 아웃했는지 확인하십시오.
고객 및 은행가를위한 테스트 사례
- 모든 방문자 및 고객 링크가 제대로 작동하는지 확인하십시오.
- 유효하고 잘못된 테스트 데이터로 고객 로그인을 확인하십시오.
- 데이터없이 고객 로그인을 확인하십시오.
- 데이터없이 은행가 로그인을 확인하십시오.
- 유효하거나 유효하지 않은 테스트 데이터로 은행원 로그인을 확인하십시오.
- 고객 또는 은행가가 성공적으로 로그 아웃 할 수 있는지 확인합니다.
신규 사용자를위한 테스트 케이스
- 유효하고 유효하지 않은 테스트 데이터로 새 사용자를 만들 수 있는지 확인합니다.
- 기존 분기 테스트 데이터로 새 사용자 만들기
- 취소 및 재설정 옵션이 제대로 작동하는지 확인하십시오.
- 유효하고 잘못된 테스트 데이터로 사용자 세부 정보를 업데이트합니다.
- 새 사용자의 삭제를 확인하십시오.
- 새 사용자를 확인할 수 있는지 확인하십시오.
- 필수 입력 매개 변수를 확인하십시오.
- 선택적 입력 매개 변수를 확인하십시오.
- 선택적 매개 변수없이 사용자를 작성할 수 있는지 확인하십시오.
새 계정 생성을위한 테스트 사례
- 유효하고 잘못된 사용자 데이터로 새 계정을 만듭니다.
- 사용자 세부 정보를 업데이트 할 수 있는지 확인합니다.
- 새 사용자를 저장할 수 있는지 확인하십시오.
- 기존 사용자의 데이터로 새 계정을 만듭니다.
- 사용자가 새로 생성 된 계정에 금액을 입금 할 수 있는지 확인하고 잔액을 업데이트합니다.
- 사용자가 새 계정에서 금액을 인출 할 수 있는지 확인합니다 (입금 및 잔액 업데이트 후).
- 급여의 경우 계정은 사용자가 제공 한 회사 명 및 기타 세부 사항을 확인합니다.
- 보조 계정의 경우 기본 계정 번호가 제공되었는지 확인하십시오.
- 현재 계정의 경우 제공된 사용자 세부 정보를 확인하십시오.
- 공동 계정의 경우 공동 계정에 대해 제공된 증거를 확인하십시오.
- 급여 계정에서 제로 잔액을 유지할 수 있는지 확인합니다.
- 비급여 계정에 대해 잔액을 0으로 유지할 수 있는지 또는 최소 잔액을 유지할 수 있는지 확인합니다.
- 새 사용자가 성공적으로 로그 아웃 할 수 있는지 확인하십시오.
Net Banking 애플리케이션의 테스트 사례
- 사용자가 은행 사이트를 열 수 있는지 확인하십시오.
- 사이트의 모든 링크가 작동하는지 확인하십시오.
- 사용자가 새 계정을 만들 수 있는지 확인합니다.
- 사용자가 유효하고 잘못된 사용자 이름과 암호로 로그인 할 수 있는지 확인하십시오.
- 로그인하는 동안 사용자 이름 또는 암호가 비어 있는지 확인하십시오. 사용자는 로그인 할 수 없으며 경고 메시지가 표시됩니다.
- 사용자가 비밀번호를 변경할 수 있는지 확인하십시오.
- 유효하지 않은 사용자 또는 암호를 입력하면 적절한 오류 메시지가 표시됩니다.
- 잘못된 암호를 가진 사용자는 로그인 할 수 없습니다.
- 잘못된 암호로 반복적으로 로그인을 시도한 후 사용자에게 오류 메시지가 표시되고 차단되는지 확인합니다.
- 사용자가 몇 가지 기본 트랜잭션을 수행 할 수 있는지 확인하십시오.
- 사용자가 유효하고 유효하지 않은 세부 정보로 수혜자를 추가 할 수 있는지 확인합니다.
- 사용자가 수혜자를 삭제할 수 있는지 확인합니다.
- 사용자가 새로 추가 된 수혜자에게 거래를 할 수 있는지 확인합니다.
- 거래 후 사용자와 수익자의 계정이 모두 업데이트되었는지 확인합니다.
- 사용자가 10 진수로 금액을 입력 할 수 있는지 확인합니다.
- 사용자가 금액 필드에 음수를 입력 할 수 없는지 확인하십시오.
- 사용자가 최소 잔액이 있거나없는 거래를 할 수 있는지 확인합니다.
- 사용자가 새 RD를 수행 할 수 있는지 확인합니다.
- 잔액이 부족한 거래의 경우 적절한 메시지가 표시되는지 확인하십시오.
- 거래가 완료되기 전에 사용자에게 확인을 요청하는지 확인하십시오.
- 성공적인 각 트랜잭션에 대해 승인 영수증이 제공되었는지 확인하십시오.
- 사용자가 여러 계정으로 돈을 이체 할 수 있는지 확인합니다.
- 사용자가 거래를 취소 할 수 있는지 확인합니다.
- 계정 세부 정보도 수행 한 금융 거래를 반영하는지 확인합니다.
- 시간 제한 기능이 구현되었는지 확인하십시오.
- 세션 시간 초과시 사용자가 다시 로그인해야하는지 확인하십시오.
- 활동이없는 경우 적절한 세션 시간 초과가 수행되었는지 확인하십시오.
- 트랜잭션을 수행하는 동안 사용자가 보안 모드로 전환되는지 확인하십시오.
- 사용자가 성공적으로 로그 아웃 할 수 있는지 확인합니다.
- 검색 및 재설정 옵션을 확인하십시오.
결론
이 기사에서 우리는 은행 애플리케이션이 얼마나 복잡 할 수 있는지 그리고 무엇입니까 애플리케이션 테스트와 관련된 일반적인 단계 . 그 외에도 소프트웨어 개발 방법론 및 도구를 포함하여 IT 산업이 뒤 따르는 현재 동향에 대해서도 논의했습니다.
이 주제에 대한 경험이나 질문을 자유롭게 공유하십시오!
추천 도서
- 투자 은행 애플리케이션을 테스트하는 방법 (34 개 이상의 중요 테스트 시나리오 포함)
- 소매 금융 시스템을 테스트하는 방법
- 건강 관리 신청서를 테스트하는 방법 – 1 부
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 알파 테스트 및 베타 테스트 (전체 가이드)
- 시험 입문서 eBook 다운로드
- 기능 테스트 대 비 기능 테스트
- 응용 프로그램 설치 및 Appium 테스트를위한 준비