ソフトウェアテスト - 決済機能テスト

かつて誰かが私にこの質問をしたことがあります。支払いプラットフォームとして、Kuaiqian、YeePay、ダイレクトバンクなどの複数のチャネルにアクセスでき、内部の製品プロセスは独自のものです。各チャネルとそれがサポートする銀行チャネルをテストするための、これより優れたテスト方法が業界にあるでしょうか?

回答: 決済プラットフォームの場合、決済チャネルに関連するテストは、決済チャネル機能のテスト、決済製品機能のテストに大別できます。

また、記事の最後にソフトウェアテストのビデオチュートリアルも用意しました。必要な場合は、直接視聴するか、記事の最後にある小さなカードをクリックして情報ドキュメントを無料で入手できます。

決済チャネルの機能テスト

主に、銀行、UnionPay、その他の外部決済チャネルとの機能、および実名認証などの非決済機能をテストします。

通常の状況では、支払いチャネルのインターフェイスは内部のサードパーティの支払いに対してのみ開かれており、支払いチャネルを外部の販売者に直接公開することはなく、外部の販売者向けの支払い製品としてパッケージ化されています。決済チャネルはサードパーティ決済会社の最も基本的な機能であり、さまざまな外部インターフェイスやサービスの呼び出しを伴うため、各チャネルが提供するテスト環境、準本番環境、本番環境の要件も異なります。同時に、サードパーティの支払い自体も必要になるため、対応するテスト環境、準本番環境、および本番環境の異なるバージョンを維持するのは非常に面倒であり、テストを完了するのは非常に面倒です。

試験方法

内部で統合テストゲートウェイを開発し（インターフェイス通信プロトコルがソケット、http、xmlなどであっても、テストを容易にするために通常はhttpに統一されます）、さまざまなチャネルのテスト入口を統合し、さまざまなチャネルに対応するインターフェイスパラメータを維持します。テスターが元の支払いリクエストをすばやく入力して送信するためのテンプレート。

ペイメントチャネルに送信した後、ペイメントチャネルがテスト環境または準テスト環境を維持している場合は、提供されたテストアカウントを直接使用して、実際のペイメントチャネルテストを完了できます。

それを提供しない場合は、件名と同様に、テストのために別のチャネルを通じてのみ銀行カードと法人口座を開くことができます。この場合、通常、最小制限がテストされます。

受験カードの適用、受験料の原資、日常管理は各企業の実情に応じて対応方針を策定することができ、企業が各種費用を負担し、関連プロセスを簡素化し、相応のインセンティブを設けることが最善である。たとえば、そのような費用は支払わないでください。払い戻しプロセスに非常に時間がかかります。

テストの目的

支払いチャネル機能の正確性、完全性、可用性を確認し、チャネルのブロックが解除され、機能が正常であるかどうかを検証します。

典型的な例としては、独自の決済チャネルの新機能を立ち上げ、本番環境のテストで問題が見つかった場合、本番環境でプロセスを実行するのは非常に面倒です。テスト版または安定版を使用できます。準本番環境でのテストゲートウェイテストの簡単な位置付けはオンライン化です. 新しいバージョンは生成機能、または支払いチャネルの問題、または本番環境ネットワークの問題に影響します。

製品の機能テストの費用を支払う

ここでの支払い製品は、サードパーティの支払い内の基本的な製品である場合もあれば、外部の販売業者に提供される製品またはインターフェイスである場合もあります。この場合、テストの焦点は支払いチャネルの基本機能ではなく、支払い製品の中核機能です。決済製品の場合、決済チャネルはブラックボックスであり、ブラックボックスによって提供されるサービスは信頼性が高く安定していると想定できます。

試験方法

決済チャネル用の一連のシミュレーションゲートウェイを内部で開発し、さまざまな決済チャネルの各インターフェイス機能をシミュレートし、支払いリクエストに応じて対応するシミュレーションメッセージを返します。支払いリクエストは実際には外部の支払いチャネルに送信されません。通常、シミュレーションゲートウェイと上記のテストゲートウェイは統合された方法で開発および展開されます。

支払いテストのアイデア

テストのポイントを分析する前に、まずはテストの考え方を整理しましょう。要約すると、あらゆるテストのアイデアは次のように要約できます。

最初のステップ: プロダクトの核となるビジネスプロセスを整理します。これがどのようなプロジェクトで、どのようなビジネスが実現され、どのように実現されるのかを理解します。

このステップは通常、企業の要件文書に基づいて行われます。製品が要件文書とともに業務フローチャートを提供している場合は、フローチャートに従うことで整理できます。製品がフローチャートを提供していない場合は、テスターが図面を作成する必要があります。要件の理解に基づいて、業務を整理する目的を達成するためのフローチャートを作成します。

ステップ2：プロセスに応じてモジュールを細分化し、機能モジュールごとに詳細なテストポイント設計と抽出を行う。

この単一関数のテストポイント抽出では、次の側面をカバーする必要があります。

通常の機能検証: 通常のビジネスプロセスと機能検証 (実際には単一機能のスモークテスト) をカバーすることが優先されます。最初にスモークテストが実行され、不合格の場合はテストを直接停止し、開発および修復後にテストを続行できます。

異常機能の検証: ユーザーによる製品の使用に近づけるために、意図的な操作によってエラーが発生するさまざまな異常シナリオを検証し、システムのフィードバックとプロンプトを確認し、ユーザーがシステムからフレンドリーな指示を確実に得られるかどうかを確認する必要もあります。操作ミスの場合。

さまざまな場所での操作により、システム例外やエラー報告が発生する可能性があるため、見逃さないように、例外を引き起こす可能性のあるすべての入力項目とオプションを見つける必要があります。ということで、3番目のステップです。

ステップ 3: 具体的な機能について、各入力項目とステップを見つけて、次の 3 つの角度からテストポイントを分析します。

1.長さ、データ型、必須項目、繰り返し

2. 需要制約 + 見えない需要

3. 機能間の相互作用

その中で、シナリオ法、同値クラス法、境界値法、エラー推測法など、ユースケースの具体的な設計法が必要となります。

ステップ 4: インターフェイス、使いやすさ、互換性、セキュリティ、パフォーマンスのプレッシャーなど、機能以外のテストポイントを検討する

上記のテストの考え方に基づいて、「決済機能」のテストポイントは次のように分析できます。

支払いを組み合わせるビジネスプロセスは次のとおりです

クリックして支払う ---> 支払い方法を選択 ---> 金額を確認 ---> パスワードを入力 ---> 支払いが完了

このプロセステストを完了することは、プロジェクトのスモークテストを完了することを意味します。次に、プロセスの各段階およびステップごとにテストを行い、例外を引き起こす可能性のあるテストポイントを詳細に分析する必要があるため、段階ごとに分けて次のように入力します。

非現金決済の時代、非現金決済は生活に欠かせないものとなり、携帯電話だけで全国を旅行できるようになりました（Alipayが前提、WeChatはリッチ<00>）。テスター、テストを支払うこれは非常に重要な部分でもあるため、私の仕事で遭遇したいくつかの問題を組み合わせて、一般的な支払いテストを要約しましょう。

1:支払いの分類

一般的に、オンライン決済は 2 つの消費モードに分かれています。1 つは淘宝網や京東などのショッピングサイトで直接金額を支払う方法、もう 1 つはジンドゥなどの仮想通貨を購入するためにチャージし、ゲームプラットフォームやその他の製品などの Web サイト内で仮想通貨を使用して消費する方法です。

2:機能テスト

次のステップはテスト作業ですが、最初に機能テストを行い、境界値、クラス分割、エラー推測、因果関係図などのさまざまなテスト手法を組み合わせて、比較的包括的なテストケースを整理しました。支払いプロセス全体と関連する支払いプロセスがあらゆる状況下で使用可能であることを確認するために、機能がテストされます。

3:インターフェーステスト

支払いプロセス全体で呼び出す必要があるインターフェイスを明確にし、販売者とサードパーティのプラットフォームのインターフェイスとパラメーターの要求方法を区別します。これには、インターフェイスの特定のパラメーターの暗号化、異常な注文番号の使用が含まれます。支払いシミュレーション、サーバー検査など。

4:セキュリティテスト

支払いには金額が関係するため、セキュリティテストの側面、支払いリクエストの偽造、金額の悪意のある改ざん、マーチャントインターフェイスを呼び出すためのサードパーティインターフェイスの悪意のあるシミュレーションなど、すべての問題を考慮する必要があります。明確に考慮する

5: テストポイント

支払いプロセスのテストポイント

1. 支払額は支払可能額と一致していますか?

(例: スキャンした支払い QR コードが、表示されている支払い金額と一致しているかどうか)。支払いは依然として支払いプロセス全体を行う必要があるため、注文の確認から最終的な支払いの成功に至るまで、どの段階でも問題が発生する可能性があります。

2. 同じ支払い方法でも、異なる支払いポータル

(例: 以下の図に示すように、Alipay には 2 つの支払い入口があります。QR コードをスキャンするか、Alipay Web ページを通じて支払いできます。テスト中は両方の入口をカバーする必要があります。

3. 支払いが成功した後、商品の購入が成功したかどうか

（例：会員サービス商品、商品購入などの購入後、通常は会員有効期限が遅れるか、支払いが完了した後、注文状況に変化がないか、商品の種類や数量は正しいかなど）

4. 支払いが成功した後、ユーザーの金額は正常に引き落とされますか?

支払金額テストポイント

通常の金額支払い
最小量: 0.01
意味のない価値：0元
最大金額: 支払われる最大金額を設定します
銀行カードやWeChatなどで1日の最大消費額または1回の最大消費額を設定
銀行カードまたはWeChat残高が不足している場合に支払う

支払いプロセスのテストポイント

通常通り支払い手続きを完了してください
電話連絡後、注文をキャンセルする
支払いが中断された後も支払いを継続する
支払い中断後に支払いを終了する
1回のご注文、1回のお支払い
複数注文の合算支払い
継続的にクリックして支払い、複数の購入があるかどうか

支払い方法テストポイント

Ali-Payで支払う
Alipayウェブ決済
WeChat支払い
銀行カードでの支払い
クーポンまたは割引（特定のオファーを含む）
支払いにクーポン/割引が使用されているかどうか、支払い可能金額と実際の支払い金額が正しいか
クーポン/割引が必須かどうか
支払い注文の返金が完了した後も、クーポン/割引は引き続き使用できますか?

最終的に、私はあなたのために、合計 212 ページのソフトウェアテスト面接ドキュメントのセットを編集しました。面接のために転職したい、昇進して給料を上げたい、職業上の問題を解決したいと考えている友人にとっては、非常に役立つはずです。皆さんの明るい未来を願っています。[記事の最後にある小さなカードをクリックすると、ソフトウェアテスト資料の完全なセットを無料で入手できます]

ビデオチュートリアルを視聴できる場所: