은행 도메인 애플리케이션 테스트 프로젝트
토마스 해밀턴
⚡ 스마트 요약
은행 도메인 애플리케이션 테스트는 민감한 거래를 처리하는 금융 소프트웨어의 기능, 성능 및 보안을 검증합니다. 이 튜토리얼에서는 도메인 지식, 은행 애플리케이션의 특징, 테스트 단계, 샘플 테스트 케이스, 그리고 금융 서비스(BFSI) 부문에 특유한 위험에 대한 주요 완화 전략을 설명합니다.
뱅킹 도메인 테스트
뱅킹 도메인 테스트 소프트웨어 테스트는 은행 애플리케이션의 기능, 성능 및 보안을 검증하는 과정입니다. 은행 애플리케이션 테스트의 주요 목적은 은행 소프트웨어의 모든 활동과 기능이 오류 없이 원활하게 실행되고 소프트웨어가 안전하게 보호되는지 확인하는 것입니다.
BFSI(은행, 금융 서비스 및 보험) 부문은 IT 서비스의 최대 소비처입니다. 은행 애플리케이션은 기밀 금융 데이터를 직접 처리하므로 은행 소프트웨어에서 수행되는 모든 작업이 안정적이고 오류 없이 실행되어야 합니다. 은행 소프트웨어는 자금 이체 및 입금, 잔액 조회, 거래 내역 확인, 출금 등의 기능을 수행합니다. 은행 애플리케이션 테스트는 이러한 기능이 올바르게 실행될 뿐만 아니라 해커의 공격으로부터 안전하게 보호되는지 확인하는 데 중요합니다.
테스트에서 도메인이란 무엇입니까?
테스트 중인 도메인 이 용어는 소프트웨어 테스트 프로젝트가 만들어진 산업 분야를 나타냅니다. 소프트웨어 프로젝트 및 개발을 논의할 때 자주 사용되는 용어입니다. 예를 들어 보험, 은행, 소매, 통신 분야 등이 있습니다.
개발하는 동안ping 어떤 분야든 특정 도메인 관련 프로젝트에서는 도메인 전문가의 도움을 받는 것이 일반적입니다. 도메인 전문가는 해당 분야의 전문가이며 애플리케이션에 대해 속속들이 알고 있기 때문입니다.
도메인 지식이 중요한 이유는 무엇입니까?
소프트웨어 제품 테스트에 있어 도메인 지식은 필수적입니다. 도메인 지식은 테스트 범위, 결함 발견, 이해관계자의 신뢰도를 직접적으로 향상시키기 때문입니다. 은행 업무 흐름을 이해하는 테스터는 도메인 지식이 없는 테스터가 놓치는 예외적인 상황(edge cases)을 찾아낼 수 있습니다.
뱅킹 도메인 지식 - 소개
은행업 분야의 개념은 매우 광범위하며 크게 두 가지 하위 분야로 나눌 수 있습니다.
- 전통적인 은행 부문
- 서비스 기반 은행 부문
아래 표는 이 두 하위 부문이 포함하는 서비스를 나열합니다.
| 부문 | 포함 된 서비스 |
|---|---|
| 전통적인 은행 부문 | 핵심 금융 서비스, 기업 금융, 소매 금융 |
| 서비스 기반 은행 부문 | 핵심 금융, 기업 금융, 소매 금융, 대출, 무역 금융, 프라이빗 뱅킹, 소비자 금융, 이슬람 금융, 고객 서비스 채널/프론트엔드 서비스 제공 |
프로젝트 범위에 따라 위에 나열된 서비스 중 하나 또는 전부를 테스트해야 할 수 있습니다. 테스트를 시작하기 전에 테스트 대상 서비스에 대한 충분한 배경 지식을 확보하십시오.
뱅킹 애플리케이션의 특성
테스트를 시작하기 전에 모든 은행 애플리케이션에 기대되는 표준 기능을 파악하는 것이 중요합니다. 그래야 이러한 기능을 구현하는 데 초점을 맞춰 테스트를 진행할 수 있습니다. 표준 은행 애플리케이션은 다음과 같은 요구 사항을 충족해야 합니다.
- 수천 개의 동시 사용자 세션을 지원합니다.
- 거래 계좌, 공과금 납부, 신용 카드 등 다양한 애플리케이션과 연동할 수 있습니다.
- 빠르고 안전한 거래를 처리하세요.
- 대용량 저장 시스템을 포함시키세요.
- 고객 문제 해결을 위한 높은 수준의 감사 기능을 제공합니다.
- 복잡한 비즈니스 워크플로우를 처리합니다.
- Mac, Linux, Unix 등 다양한 플랫폼 사용자를 지원합니다. Windows).
- 여러 위치에 있는 사용자를 지원합니다.
- 다국어 사용자를 지원합니다.
- 다양한 결제 시스템(VISA, AMEX, MasterCard)에 대한 사용자 지원을 제공합니다.
- 대출, 소매 금융 등 다양한 서비스 부문을 지원합니다.
- 완벽한 재난 관리 메커니즘을 제공하십시오.
테스트할 은행 애플리케이션 유형
지도 이전ping 테스트 단계에서 어떤 은행 애플리케이션이 일반적으로 테스트 범위에 포함되는지 아는 것이 도움이 됩니다.
- 핵심 뱅킹 시스템(CBS): 예금, 대출 및 계좌 관리를 위한 중앙 엔진.
- 인터넷 뱅킹: 고객용 송금 및 요금 납부 웹 포털.
- 모바일 뱅킹: iOS 및 Android 생체인식 및 알림 기능을 갖춘 앱.
- ATM 및 키오스크 소프트웨어: 현금자동입출기(ATM)에 내장된 소프트웨어.
- 지불 게이트웨이 : 카드, UPI 및 전자지갑 거래 처리기.
- 대출 및 재무 모듈: 백오피스 신용 및 외환 앱.
뱅킹 애플리케이션 테스트의 테스트 단계
테스트 범위에 포함되는 애플리케이션이 확인되면 일반적으로 다음과 같은 단계를 거쳐 테스트가 진행됩니다.
- 요구 사항 분석 : 비즈니스 분석가는 특정 은행 애플리케이션에 필요한 요구사항을 수집하고 문서화하는 업무를 수행합니다.
- 요구 사항 Review : 품질 분석가, 비즈니스 분석가 및 개발 리더는 요구사항 문서를 검토하고 기존 워크플로를 손상시키지 않는지 교차 확인합니다.
- 비즈니스 요구 사항 문서: 품질 분석가는 검토된 모든 요구사항을 포괄하는 비즈니스 요구사항 문서를 작성합니다.
- 데이터베이스 테스트: 은행 애플리케이션 테스트에서 가장 중요한 부분입니다. 데이터 무결성, 데이터 로딩, 데이터 마이그레이션, 저장 프로시저, 함수 유효성 검사 및 비즈니스 규칙을 검증합니다.
- 통합 테스트 : $XNUMX Million 미만 통합 테스팅개발된 모든 구성 요소는 통합되어 함께 검증됩니다.
- 기능 테스트 : 표준 테스트 활동은 다음과 같습니다. 테스트 케이스 준비, 테스트 케이스 검토 및 실행은 이 단계에서 수행됩니다.
- 보안 테스트 : 소프트웨어에 보안 결함이 없는지 확인합니다. QA 팀은 시스템 침입을 시도하는 긍정적 및 부정적 시나리오를 모두 포함하고, 권한 없는 사용자가 취약점을 발견하기 전에 보고해야 합니다. 은행은 또한 일회용 비밀번호와 같은 다중 계층 접근 인증을 시행해야 합니다. 자동화 도구는 일반적으로 다음과 같은 용도로 사용됩니다. 보안 테스트 들 IBM AppScan과 HP WebInspect는 다음과 같습니다. 수동 테스트 주로 Proxy Sniffer, Paros Proxy 및 HTTP Watch를 사용합니다.
- 사용성 테스트: 장애가 있는 사용자도 다른 사용자와 마찬가지로 시스템을 쉽게 사용할 수 있도록 보장합니다. 예를 들어, 접근성을 위해 음성 안내 및 점자 키패드가 장착된 ATM이 있습니다.
- 사용자 수락 테스트: 최종 단계는 최종 사용자가 실제 환경에서 애플리케이션이 올바르게 작동하는지 확인하는 단계입니다.
Net Banking 로그인 애플리케이션에 대한 샘플 테스트 케이스
모든 은행 애플리케이션에서 보안은 최우선 사항입니다. QA 팀은 테스트 준비 과정에서 시스템을 철저히 조사하고 권한 없는 사용자가 취약점을 발견하기 전에 이를 보고할 수 있도록 긍정적 시나리오와 부정적 시나리오를 모두 포함해야 합니다. 즉, 부정적 테스트 케이스뿐만 아니라 파괴적 테스트도 작성해야 합니다.
아래 표는 은행 애플리케이션에 대한 일반적인 테스트 사례를 요약한 것입니다.
| 지역 | 샘플 테스트 케이스 |
|---|---|
| 관리자 | 유효한 데이터와 유효하지 않은 데이터를 사용한 관리자 로그인 확인; 데이터 없이 관리자 로그인; 모든 관리자 홈 링크; 유효한 데이터, 유효하지 않은 데이터 및 기존 데이터를 사용한 관리자 비밀번호 변경; 관리자 로그아웃. |
| 새로운 지점 | 유효한 데이터, 유효하지 않은 데이터 및 기존 데이터를 사용하여 새 브랜치를 생성합니다. 데이터 없이 브랜치를 생성하고, 초기화 및 취소합니다. 유효한 데이터, 유효하지 않은 데이터 및 기존 데이터를 사용하여 브랜치를 업데이트하고, 취소합니다. 종속성 포함 및 종속성 없이 브랜치를 삭제하고, 브랜치를 검색할 수 있습니다. |
| 새로운 역할 | 유효한 데이터, 유효하지 않은 데이터, 기존 데이터를 사용하여 새 역할을 생성하고, 데이터 없이 생성하고, 역할 설명과 유형을 확인하고, 역할을 취소하고 재설정하고, 종속성 유무에 관계없이 역할을 삭제하고, 역할 세부 정보 페이지의 링크를 확인합니다. |
| 고객 및 방문객 | 모든 방문자 및 고객 연결을 확인합니다. 고객은 유효한 데이터, 유효하지 않은 데이터 또는 데이터 없음으로 로그인할 수 있으며, 은행원도 유효한 데이터, 유효하지 않은 데이터 또는 데이터 없음으로 로그인할 수 있습니다. |
| 새 사용자 | 유효한, 유효하지 않은, 기존 지점 데이터를 사용하여 새 사용자를 생성합니다. 데이터 없이 사용자를 생성합니다. 사용자를 취소하고 초기화합니다. 유효한, 유효하지 않은, 기존 데이터를 사용하여 사용자를 업데이트합니다. 사용자를 취소합니다. 사용자를 삭제합니다. |
은행 영역 테스트의 어려움과 해결 방안
탄탄한 테스트 단계와 템플릿을 갖추고 있더라도, 은행 프로젝트에서 테스터들은 여러 가지 반복적인 어려움에 직면합니다. 아래의 해결 방안들은 실제 프로젝트에서 효과가 입증되었습니다.
| 과제 | 완화 |
|---|---|
| 실제 운영 데이터에 접근하여 이를 테스트 데이터로 복제하는 것은 어렵습니다. | 데이터 마스킹, 합성 테스트 데이터 및 시스템 통합 테스트를 통해 테스트 데이터가 규제 준수 요건을 충족하고 기밀성을 유지하도록 보장합니다. |
| 기존 은행 시스템에서 새로운 시스템으로의 마이그레이션, 즉 루틴, 절차 및 데이터 업로드를 포함한 모든 과정은 가장 큰 과제입니다. | 데이터 마이그레이션 테스트를 완료하고 기존 시스템과 새 시스템 모두에서 회귀 테스트 케이스를 실행하여 결과가 일치할 때까지 비교합니다. |
| 요구사항이 제대로 문서화되지 않아 기능적인 공백이 발생할 수 있습니다. 비기능적 요구사항은 종종 문서화되지 않아 테스터가 테스트해야 할지 여부를 알 수 없습니다. | 테스터는 요구사항 분석 단계부터 참여하여 비즈니스 요구사항을 적극적으로 검토해야 합니다. |
| 시스템이 원하는 정책 및 절차를 준수하는지 확인합니다. | 규정 준수 및 규제 정책 테스트를 수행합니다. |
| 은행 애플리케이션이 인터넷과 통합됨에 따라 범위와 일정이 확대되고 있습니다. 모바일 은행업. | 은행 애플리케이션에 외부 인터페이스가 많은 경우, 통합 테스트를 위한 충분한 시간을 계획에 포함시켜야 합니다. |
