how test banking domain applications
銀行アプリケーションをテストするための完全ガイド：BFSI（銀行、金融サービス、および保険）のテストプロセスとヒント
銀行のアプリケーションは、今日のソフトウェア開発およびテスト業界で最も複雑なアプリケーションの1つです。
銀行のアプリケーションがこれほど複雑な理由は何ですか？ 銀行業務アプリケーションに関連する複雑なワークフローをテストするには、どのようなアプローチに従う必要がありますか？
この記事では、バンキングアプリケーションのテストに関連するさまざまな段階と手法に焦点を当てます。
学習内容：
銀行のアプリケーションをテストする方法は？
バンキングアプリケーションによって実行されるさまざまな機能は次のとおりです。
まず、銀行アプリケーションの特徴を理解しましょう。
- 何千もの同時ユーザーセッションをサポートする多層機能
- 大規模集積回路：通常、銀行アプリケーションは、BillPayユーティリティやTradingAccountsなどの他の多数のアプリケーションと統合されます。
- 複雑なビジネスワークフロー
- リアルタイムおよびバッチ処理
- 1秒あたりのトランザクション数が多い
- 安全なトランザクション
- 日々の取引を追跡するための堅牢なレポートセクション
- 顧客の問題をトラブルシューティングするための強力な監査
- 大容量ストレージシステム
- 災害/復旧管理。
上記の10点は 銀行アプリケーションの最も重要な特性。
銀行のアプリケーションには、操作の実行に関係する複数の層があります。
例えば 、へ 銀行のアプリケーションには次のものがあります。
- ブラウザを介してエンドユーザーと対話するためのWebサーバー
- Webサーバーの入力と出力を検証するための中間層
- データと手順を保存するデータベース
- 1秒あたり数兆のトランザクションを実行する大容量のメインフレームまたはその他のレガシーシステムである可能性のあるトランザクションプロセッサ。
銀行のアプリケーションのテストについて話す場合、それは 以下を保証するための複数のソフトウェアテスト手法を含むエンドツーエンドのテスト方法論。
- すべての銀行ワークフローとビジネス要件のトータルカバレッジ
- アプリケーションの機能面
- アプリケーションのセキュリティ面
- データの整合性
- 並行性
- ユーザー体験
銀行のアプリケーションがこれほど複雑な理由は何ですか？
- 銀行のソフトウェアは主に機密の財務データを扱うため、ソフトウェアのパフォーマンスはエラーがなく安全である必要があります。
- 開発者は、これらのアプリケーションを開発するための複雑な設計を好み、アプリケーションが望ましい安全な方法で実行されるようにします。
- 銀行業は絶えず変化する世界です。今日の銀行業務は、実店舗の支店、ATM、オンラインバンキング、カスタマーケアなどのさまざまなチャネルを使用して顧客が利用できるようになっています。
- テクノロジーの出現により、金融取引のために銀行システムに接続する市場に多くの財布が殺到しました。
- 銀行業務も24時間年中無休で高性能で稼働することが期待されています。ソフトウェアのアップグレード、即時修正などがこの可用性に影響を与えることは許可されません。
- 銀行業界はまた、銀行規制という形で政府によってもたらされた絶え間ない変化の影響を強く受けています。税制の変更は銀行システムにも影響を及ぼします。
- 銀行システムも、新しいテクノロジーに関する限り、最新のものである必要があります。ビッグデータ処理やデータサイエンスを使用したビッグデータからの本能の取得などのデータ分析は、銀行業界で注目を集めています。
上記の点により、開発者が銀行システムを複雑にして、その周りにソフトウェアアプリケーションを作成することができます。
銀行アプリケーションのテストの重要性
- バンキングアプリケーションをテストすることで、すべてのアクティビティが適切に実行されるだけでなく、保護および保護されたままであることが保証されます。
- 銀行のソフトウェアは何千もの依存関係で複雑であり、テストプロセスにはより多くの時間、リソース、および継続的な監視が必要です。
- ここでは財政が関係しているため、ガイドラインに厳密に従う必要があります。テスターと開発者の両方が、ドメインに関する十分な知識を持っている必要があります。
- 最も重要なことは、金融取引において法規制が正しく施行されていることを確認する必要があります。これは、テストによってのみ確認できます。
- また、アプリケーションと、アプリケーションがデプロイされているインフラストラクチャが、特にピーク時の営業時間中に、中断を引き起こすことなく負荷を処理できることを確認することも重要です。これは、パフォーマンステストを実行することで確認できます。
- 今日のデジタル世界では、誰もが懸念していることの1つは、セキュリティです。銀行のアプリケーションとその中で実行される金融取引は、侵入の試みから保護されている必要があります。これは、セキュリティテストを実行することで確認できます。セキュリティテストは、金融取引を保護するための業界標準の実施に役立ちます。
- また、銀行アプリケーションのさまざまなモジュールが適切に統合され、クライアントの目的を達成できるようにすることも重要です。システム統合テストは、このタスクの達成に役立ちます。
バンキングアプリのテストワークフロー
銀行アプリケーションのテストに関連する典型的な段階 以下のワークフローに示されています。各段階について個別に話し合います。
これは、アプリケーションをテストするウォーターフォールモデルです。
＃1）要件の収集
要件収集フェーズ 機能仕様またはユースケースとしての要件の文書化が含まれます。要件は顧客のニーズに応じて収集され、銀行の専門家またはビジネスアナリストによって文書化されます。
銀行自体には複数のサブドメインがあり、1つの本格的な銀行アプリケーションがこれらすべてのドメインの統合になるため、専門家は複数の主題に関する要件の作成に関与します。
例えば、 銀行のアプリケーションには、転送、クレジットカード、レポート、ローンアカウント、請求書の支払い、取引などの個別のモジュールが含まれる場合があります。
＃2）要件レビュー
要件収集の成果物は、QAエンジニア、開発リーダー、ピアビジネスアナリストなどのすべての利害関係者によってレビューされます。
彼らは、既存のビジネスワークフローにも新しいワークフローにも違反していないことをクロスチェックします。すべての要件が検証および妥当性確認されます。フォローアップアクションと要件ドキュメントの改訂は、これに基づいて行われます。
＃3）ビジネスシナリオの準備
この段階で、QAエンジニアは、要件ドキュメント（機能仕様またはユースケース）からビジネスシナリオを導き出します。ビジネスシナリオは、すべてのビジネス要件がカバーされるように導き出されます。ビジネスシナリオは、詳細な手順がない高レベルのシナリオです。
さらに、これらのビジネスシナリオは、ビジネスアナリストによってレビューされ、すべてのビジネス要件が満たされていることを確認します。 BAは、低レベルの詳細なテストケースを確認するよりも、高レベルのシナリオを確認する方が簡単です。
例えば 、デジタルバンキングインターフェイスで定期預金を開く顧客は、ビジネスシナリオになる可能性があります。同様に、ネットバンキングアカウントの作成、オンライン預金、オンライン転送などに関連するさまざまなビジネスシナリオがあります。
＃4）機能テスト
この段階では、機能テストが実行され、次のような通常のソフトウェアテストアクティビティが実行されます。
テストケースの準備： この段階では、テストケースはビジネスシナリオから派生し、1つのビジネスシナリオがいくつかのポジティブなテストケースとネガティブなテストケースにつながります。通常、この段階で使用されるツールは、Microsoft Excel、Test Director、またはQualityCenterです。
テストケースレビュー： ピアQAエンジニアによるレビュー
テストケース 実行： テストケースの実行は、QC、QTPなどのツールを使用して手動または自動で行うことができます。
銀行のアプリケーションの機能テストは、通常のソフトウェアテストとはかなり異なります。これらのアプリケーションは顧客のお金と機密性の高い財務データで動作するため、徹底的にテストする必要があります。重要なビジネスシナリオをカバーするために残しておくべきではありません。
また、アプリケーションをテストしているQAリソースは、銀行ドメインの基本的な知識を持っている必要があります。
＃5）データベーステスト
バンキングアプリケーションには、UIレベルとデータベースレベルの両方で実行される複雑なトランザクションが含まれるため、データベーステストは機能テストと同じくらい重要です。データベースは複雑で、アプリケーション内の完全に独立したレイヤーであるため、そのテストはデータベーススペシャリストによって実行されます。次のような手法を使用します。
- データの読み込み
- データベースの移行
- DBスキーマとデータ型のテスト
- ルールテスト
- ストアドプロシージャと関数のテスト
- トリガーのテスト
- データの整合性
データベーステストの主な目的は、次のことを確認することです。
- アプリケーションは、データを失うことなく、データベースからデータを保存および取得できます。
- 保存されているデータの不一致を回避するために、完了したトランザクションをコミットし、中止したトランザクションを元に戻す必要があります。
- 許可されたアプリケーションとユーザーのみがデータベースと基礎となるテーブルにアクセスできます。
データベーステストには、主に3つの方法があります。
- 構造試験
- 機能テスト
- 非機能テスト
構造試験
これには、データベース、スキーマ、テーブル、ビュー、トリガー、アクセス制御などのデータベースオブジェクトのテストが含まれます。テーブルのデータ型がアプリケーションの対応する変数と同期していることを確認します。テーブル内のデータと参照整合性を検証します。
例えば、 アプリケーションの金額フィールドは、テーブル内で10進数/浮動小数点のデータ型である必要があります。
–標準に準拠するために、ユーザーにはビューを介したアクセス制御を与える必要があります。
機能テスト
これには、ユーザーの要件を満たすデータベースのテストが含まれます。達成するには、ブラックボックステストとホワイトボックステストの2つの方法があります。
例えば、 オンライン送金を行う場合は、送信者アカウントから引き落としを行い、受信者アカウントにまったく同じ金額を入金する必要があります。トランザクションが失敗した場合は、トランザクション全体を元に戻し、送信者アカウントから借方または貸方に戻さないでください。
非機能テスト
これには、負荷とストレスのテストとパフォーマンスの最適化が含まれます。負荷テストは、データベースのパフォーマンスに影響を与えることなく同時に実行できるトランザクションの最大数を特定するのに役立ちます。
例えば、 負荷テストとストレステストからの入力に基づいて、銀行のアプリケーションは、ピークの営業時間中にアプリケーションにリソースを追加し、営業時間外にリソースを削減することを決定できます。これは、銀行がリソースを最適に活用し、お金を節約するのに役立ちます。
＃6）セキュリティテスト
セキュリティテストは通常、テストサイクルの最終段階です。セキュリティテストを開始するための前提条件は、機能テストと非機能テストの完了です。セキュリティテストは、アプリケーションが連邦および業界の標準に準拠していることを確認するため、アプリケーションテストサイクル全体の主要な段階の1つです。
銀行のアプリはデータの性質上、非常に機密性が高く、ハッカーや不正行為の主な標的になります。セキュリティテストでは、機密データを侵入者や攻撃者にさらす可能性のあるWebの脆弱性がアプリケーションにないことを確認します。また、アプリケーションがOWASPなどの標準に準拠していることも保証します。
この段階での主要なタスクは、IBMAppScanやなどのツールを使用して実行されるアプリケーションスキャン全体です。 HP WebInspect （これらは最も人気のあるツールです）。
スキャンが完了すると、スキャンレポートが公開されます。このレポートでは、誤検知が除外され、残りの脆弱性が開発チームに報告され、各問題の重大度に応じて問題の修正が開始されます。
このステップでは、侵入テストも実行され、エラーの伝播が明らかになります。プラットフォーム、ネットワーク、およびOS全体で厳密なセキュリティテストを実行する必要があります。
その他いくつか セキュリティテスト用の手動ツール 使用されている パロスプロキシ 、 Httpウォッチ 、 Burp Suite 、および 要塞化。
セキュリティテストの主な目的は、ソフトウェアアプリケーションが持つ可能性のある脆弱性を特定することです。
セキュリティテストは、以下に対してアプリケーションをテストします。
- 外部からの攻撃、または悪意を持ってアプリケーションをハッキングしようとする試み。
- ソフトウェアアプリケーションの抜け穴が悪用され、データや金銭的損失が発生する可能性があります。
- アプリケーションをホストするネットワーク、サーバー、およびワークステーションの脆弱性。
以下は、さまざまなタイプのセキュリティテストです。
脆弱性テスト： さまざまな脆弱性をチェックするために、自動化されたプログラムが開発および実行されます。
セキュリティスキャン： この亜種は、ネットワークとシステムの脆弱性の調査を中心に展開し、関連するリスクを軽減するためのソリューションを提供します。
ペネトレーションテスト： このセキュリティテストの変種は、データベースやアプリケーションデータにアクセスできた可能性のある脆弱性や抜け穴をキャプチャするハッキングの試みを模倣しています。
セキュリティ監査： これには、セキュリティの失効についてアプリケーションと関連ネットワークの監査が含まれます。
リスクアセスメント： この亜種は、脆弱性または抜け穴が悪意のある目的で悪用された場合に、リスクのレベルを評価するための分析を行います。このようなリスクは、低、中、高に分類できます。リスクのレベルに基づいて、リスクを軽減または回避するための適切な対策がテストチームによってアドバイスされます。
倫理的ハッキング： これは、組織がシステム上で実行して、アプリケーションまたはネットワークで悪用される可能性のある抜け穴を特定します。この種のハッキングの目的は、アプリケーションやネットワークを盗んだり、損害を与えたりすることではありません。
姿勢評価： これは、セキュリティスキャン、リスク評価、および倫理的ハッキングで構成される包括的な評価です。
SQLインジェクション： SQLインジェクションを使用して、サーバーデータベースにアクセスできます。テストは、コードが正しく機能していることを確認するために実行されます。コードは、ユーザーからの次の入力に基づいてデータベースでクエリを実行します。
- ブラケット
- アポストロフィ
- カンマ
- 引用符
BFSIアプリのテストの他の段階
上記のメインステージとは別に、統合テスト、ユーザビリティテスト、ユーザー受け入れテスト、パフォーマンステストなどのさまざまなステージが含まれる場合があります。
これらの段階についても簡単に説明しましょう。
統合テスト
ご存知のように、銀行のアプリケーションでは、送金、請求書の支払い、預金など、いくつかの異なるモジュールが存在する可能性があります。したがって、多くのコンポーネントが開発されています。統合テストでは、すべてのコンポーネントが統合され、検証されます。
ユーザビリティテスト
銀行アプリケーションは、さまざまな顧客にサービスを提供します。これらの顧客の中には、アプリで銀行業務を実行するために必要なスキルと認識が不足している場合があります。
したがって、銀行のアプリケーションは、さまざまな顧客グループで使用できるように、シンプルで効率的な設計についてテストする必要があります。シンプルで使いやすいインターフェースは、より多くの顧客が銀行アプリケーションの恩恵を受けることです。
それは、ビジネスユーザーや銀行の顧客がアプリケーションを使用する際の使いやすさのレベルを調べることです。このテストは、開発者やテスターによって実行されるのではなく、ビジネスユーザーによって実行されます。
例えば、 今日、誰もがモバイルアプリを使用しています。バンキングアプリは、エンドユーザーにとって使いやすく、理解しやすく、使いやすいものでなければなりません。
ユーザビリティテストの種類
比較ユーザビリティテスト： これは比較ベースのテストであり、あるWebサイトまたはアプリケーションを別のWebサイトまたはアプリケーションで使いやすくします。このようなテストの目標は、最高のユーザーエクスペリエンスを提供することです。
探索的ユーザビリティテスト： このテストの目的は、銀行の顧客の要件を満たすために、新しいアプリケーションまたはソフトウェアが持つべき機能を特定することです。
以下は、ユーザビリティテストの長所と短所です。
2年間の経験のためのphpインタビューの質問と回答
利点：
- 通常、アプリケーションのエンドユーザーはテストに関与するため、直接のフィードバックが得られます。
- 製品に必要かどうかについての分析と議論に時間を費やすよりも、エンドユーザーから直接入力を取得する方が適切です。
- 潜在的な問題を事前に把握できます。
短所：
- 複数のエンドユーザーがテストに関与しているため、正確でない場合でも、彼らの意見が要件に影響を与える可能性があります。
- エンドユーザーからのフィードが影響を受ける可能性があります。
性能試験
給料日、会計年度の終わり、お祭りの季節などの特定の期間は、アプリの通常のトラフィックに変化や急上昇をもたらす可能性があります。したがって、お客様がパフォーマンス障害の影響を受けないように、徹底的なパフォーマンステストを実施する必要があります。
銀行の顧客がパフォーマンス障害のために個人的に影響を受けた過去の重要な例は、顧客がデビットカードとクレジットカードを持っていたNatWestとRBSのサイバーマンデーITの停止で、国内の店舗間での取引が拒否されました。
ユーザー受け入れテスト
これは、アプリケーションが実際のシナリオに準拠し、稼働するとユーザーに受け入れられるようにするために、エンドユーザーを関与させることによって行われます。
今日のシナリオでは 銀行プロジェクトの大部分は使用しています ：アジャイル/スクラム、RUP、継続的インテグレーションの方法論、およびMicrosoftのVSTSやRationalToolsなどのツールパッケージ。
上記のRUPについて述べたように、RUPはRational Unified Processの略で、IBMによって導入された反復的なソフトウェア開発方法論であり、開発およびテスト活動が実行される4つのフェーズで構成されています。
4つのフェーズは
i）開始
ii）コラボレーション
iii）建設と
iv）移行
RUPには、IBMRationalツールが広く含まれています。
銀行アプリケーションのサンプルテストケース
新しいブランチのテストケース
- 有効なテストデータと無効なテストデータを使用して新しいブランチを作成します。
- データなしで新しいブランチを作成します。
- 既存のブランチデータを使用して新しいブランチを作成します。
- リセットとキャンセルのオプションを確認します。
- 有効および無効なテストデータでブランチの詳細を更新します。
- 既存のブランチテストデータでブランチの詳細を更新します。
- 新しいブランチを保存できるかどうかを確認します。
- キャンセルオプションが機能していることを確認します。
- 依存関係がある場合とない場合のブランチの削除を確認します。
- ブランチ検索オプションが機能しているかどうかを確認します。
新しい役割のテストケース
- 有効なテストデータと無効なテストデータを使用して新しい役割を作成します。
- データなしで新しい役割を作成します。
- 既存のテストデータを使用して新しい役割を作成できることを確認します。
- 役割の説明と役割の種類を確認します。
- キャンセルとリセットのオプションが機能していることを確認します。
- 依存関係がある場合とない場合の役割削除プロセスを確認します。
- 役割の詳細ページでリンクを確認します。
- テストデータなしで管理者ログインを確認します。
- 管理者ロールのすべてのホームリンクを確認します。
- 管理者が有効および無効なテストデータを使用してパスワードを変更できることを確認します。
- 管理者が正常にログアウトすることを確認します。
顧客と銀行家のテストケース
- すべての訪問者と顧客のリンクが正しく機能しているかどうかを確認します。
- 有効なテストデータと無効なテストデータを使用して、顧客のログインを確認します。
- データなしで顧客のログインを確認します。
- データなしでバンカーのログインを確認します。
- 有効または無効なテストデータを使用してバンカーのログインを確認します。
- 顧客または銀行員が正常にログアウトできることを確認します。
新規ユーザー向けのテストケース
- 有効なテストデータと無効なテストデータを使用して新しいユーザーを作成できるかどうかを確認します。
- 既存のブランチテストデータを使用して新しいユーザーを作成します
- キャンセルとリセットのオプションが正しく機能しているかどうかを確認します。
- 有効および無効なテストデータでユーザーの詳細を更新します。
- 新しいユーザーの削除を確認します。
- 新しいユーザーを確認できるかどうかを確認します。
- 必須の入力パラメーターを確認します。
- オプションの入力パラメーターを確認します。
- オプションのパラメーターなしでユーザーを作成できるかどうかを確認します。
新しいアカウントを作成するためのテストケース
- 有効なユーザーデータと無効なユーザーデータを使用して新しいアカウントを作成します。
- ユーザーの詳細を更新できるかどうかを確認します。
- 新しいユーザーを保存できるかどうかを確認します。
- 既存のユーザーのデータを使用して新しいアカウントを作成します。
- ユーザーが新しく作成されたアカウントに金額を入金できることを確認します（そして残高を更新します）。
- ユーザーが新しいアカウントから金額を引き出すことができることを確認します（入金後、残高を更新します）。
- 給与の場合、アカウントは会社名とその他の詳細がユーザーによって提供されていることを確認します。
- セカンダリアカウントの場合、プライマリアカウント番号が提供されているかどうかを確認します。
- 現在のアカウントの場合に提供されるユーザーの詳細を確認します。
- 共同口座の場合は、共同口座に提供された証明を確認してください。
- 給与勘定でゼロ残高を維持できるかどうかを確認します。
- 非給与勘定のゼロ残高または最小残高を維持できるかどうかを確認します。
- 新しいユーザーが正常にログアウトできることを確認します。
ネットバンキングアプリケーションのテストケース
- ユーザーが銀行のサイトを開くことができるかどうかを確認します。
- サイト上のすべてのリンクが機能しているかどうかを確認します。
- ユーザーが新しいアカウントを作成できるかどうかを確認します。
- ユーザーが有効および無効なユーザー名とパスワードでログインできるかどうかを確認してください。
- ログイン時にユーザー名またはパスワードのいずれかが空白であるかどうかを確認します。ユーザーにログインを許可しないでください。アラートメッセージが表示されます。
- ユーザーがパスワードの変更を許可されているかどうかを確認してください。
- 無効なユーザーまたはパスワードが入力された場合、適切なエラーメッセージが表示されます。
- 無効なパスワードを持つユーザーはログインを許可されるべきではありません。
- 間違ったパスワードで何度もログインを試みた後、ユーザーにエラーメッセージが表示され、ブロックされることを確認します。
- ユーザーがいくつかの基本的なトランザクションを実行できるかどうかを確認します。
- ユーザーが有効な詳細と無効な詳細を使用して受取人を追加できることを確認します。
- ユーザーが受取人を削除できるかどうかを確認します。
- ユーザーが新しく追加された受取人と取引できることを確認します。
- 取引後、ユーザーと受取人の両方のアカウントが更新されているかどうかを確認します。
- ユーザーが10進数で金額を入力できるかどうかを確認します。
- ユーザーが金額フィールドに負の数を入力できないかどうかを確認します。
- ユーザーが最小残高の有無にかかわらずトランザクションを実行できるかどうかを確認します。
- ユーザーが新しいRDを実行できるかどうかを確認します。
- 残高が不足している取引の場合に適切なメッセージが表示されることを確認します。
- トランザクションを実行する前に、ユーザーが確認を求められているかどうかを確認してください。
- トランザクションが成功するたびに確認応答が提供されるかどうかを確認します。
- ユーザーが複数のアカウントに送金できるかどうかを確認します。
- ユーザーがトランザクションをキャンセルできるかどうかを確認します。
- アカウントの詳細が、行われた金融取引も反映していることを確認します。
- タイムアウト機能が実装されていることを確認します。
- セッションがタイムアウトした場合、ユーザーが再度ログインする必要があることを確認します。
- 非アクティブな場合に備えて、適切なセッションタイムアウトが実行されていることを確認します。
- トランザクションの実行中に、ユーザーがセキュアモードになっていることを確認します。
- ユーザーが正常にログアウトできるかどうかを確認します。
- 検索とリセットのオプションを確認します。
結論
この記事では、 銀行のアプリケーションがどれほど複雑になる可能性があるか そして何ですか アプリケーションのテストに関連する一般的なフェーズ 。それとは別に、ソフトウェア開発の方法論やツールを含むIT業界が従う現在の傾向についても説明しました。
このトピックに関するあなたの経験や質問を自由に共有してください！
推奨読書
- 投資銀行アプリケーションをテストする方法（34以上の重要なテストシナリオを含む）
- リテールバンキングシステムをテストする方法
- ヘルスケアアプリケーションをテストする方法–パート1
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- アルファテストとベータテスト（完全ガイド）
- PrimereBookダウンロードのテスト
- 機能テストと非機能テスト
- アプリケーションのインストールとAppiumテスト用の準備