Java 面接の質問の概要 | Java 面接の質問の概要 12 - テスト モジュール

テスト

試験に必要な資質

基本的な理論的知識、プログラミング言語スキル、自動テスト ツール、および基本的なコンピューターの知識

ビジネス分析機能: ビジネス プロセスの分析、テスト対象のビジネス データの分析、テスト対象システムのフレームワークの分析、ビジネス モジュールの分析、テストに必要なリソースの分析、およびテスト完了目標の分析

欠陥洞察能力：一般的な欠陥を発見する能力、目に見えない問題を発見する能力、関連する問題を発見する能力、隠れた問題を発見する能力、問題をできるだけ早く発見する能力

チームワーク能力、合理的な分業、チームメンバーのタスク完了の支援、テストタスクへの協力、開発と協力して欠陥を再現する、進捗状況を監督する

専門的な技術力、テストの基礎知識、プログラミング、コンピュータネットワークの知識を習得

問題解決能力、技術的問題、仕事上の問題、コミュニケーション上の問題。

コミュニケーション能力と表現力、技術担当者、製品担当者、上司、部下とのコミュニケーション。

巨視的な制御能力、テスト時間の効果的な制御、テストコストの効果的な制御、テスト計画の効果的な策定、効果的なリスク評価、テストの方向性の効果的な制御。

ソフトウェア開発とソフトウェアテストの違いは何ですか?

ソフトウェア開発は、コードを記述してソフトウェアを生成するプロセスであり、ゼロからのプロセスです。ソフトウェアテストとは、ソフトウェアに問題がないか、オンライン化できるかどうかをテストすることで、ソフトウェアをより良くし、品質管理の役割を果たします。ソフトウェア開発には製品の出力がありますが、ソフトウェア テストには製品の出力がありませんが、これはソフトウェア テストの重要性に影響を与えません。

テストケースはどの段階で作成されますか?

テスト ケースはできるだけ早い段階で作成する必要があり、テスト ケースは通常、テスト設計段階、つまり「要件仕様書」と「テスト計画」が完了した後に作成されます。

wモデル

プロジェクト固有の作業をテストする

テスト環境の構築
、テスト ケースの作成
、テスト ケースの実行
、テスト計画の作成、テスト レポート、
テストとバグ フォームの送信、バグ
修正の追跡
、自動テストの実行、スクリプトの作成、実行、分析、レポート、
パフォーマンス テストの実行、ストレステスト、およびその他のテストの実行、分析、チューニング、レポート作成

QR コード決済をテストするように頼まれた場合、どのようなシナリオを検討しますか?

1. 機能テストケース
   カードのタイプ:
   タイプ 1 アカウント: デビット カード、クレジット カード、各口座開設銀行
   タイプ 2 アカウント: WeChat の口座変更などの仮想アカウント、Alipay の Yu'E Bao、
   電子アカウントの加盟店タイプの QR コード (WeChat、 Alipay、Huiyi、UnionPay）
   支払限度額（一回限度額、累積限度額、日額累計、月額累計、支払回数）
   返金（返金入口、返金進捗状況、返金結果）
   精算
   資金の流れ（弊社控除金額が正しいか、その他相手の支払い金額が正しい） 金額と期限
   支払い結果と取引詳細の表示
   連続スキャンコード支払い、毎日のスキャンコード支払い制限と金額制限
   QRコードの有効期間
   カメラ許可の有無低画素の
   フロントカメラとリア
   カメラ 携帯電話は可能スキャン コードは成功しません
   互換性、互換性 (携帯電話メーカーによって、独自のカメラ機能の実装に一貫性がありません)

2. セキュリティ:
   1. タイムアウト制限はありますか?
   2. ユーザーの操作中に関連情報がログ ファイルに書き込まれるかどうか、追跡可能かどうかなどをテストします
   。暗号化が正しいか、暗号化前後の情報の整合性。

3. パフォーマンス
   1. ユーザー操作の応答時間
   2. システムのスループット (TPS)
   3. システムのハードウェア リソース (CPU、ハードディスク、ディスク)
   4. ネットワーク リソースの占有率など

4. 異常シナリオ
   異常事態（カード異常、残高不足）

WeChatが赤い封筒の送信機能をテスト

WeChatでの紅包送信テストは、機能（正常＋異常）、パフォーマンス、セキュリティ、互換性、インターフェース、使いやすさの側面からテストできます。

1. 機能テスト

   1. 赤い封筒の金額と赤い封筒の枚数の入力ボックスには数字のみが入力できます。

   2. 赤い封筒に入力できる金額の最大および最小は 200 0.01 です。

   3. 福の赤い封筒は最大何枚まで送れますか? 福の赤い封筒の数が上限を超えた場合、通知はありますか?

   4. 赤い封筒の金額が最大範囲を超えた場合、対応するプロンプトはありますか?

   5. 送信された赤い封筒の数が最大範囲を超えた場合、プロンプトは表示されますか?

   6. 残高が不足している場合、赤い封筒の配達は失敗します。

   7. 赤い封筒の説明文に、漢字、英語、記号、絵文字、純数字、漢字、英語記号を入力できますか? それらを混合して入力することはできますか?

   8. 紅封の金額を入力する場合、数字しか入力できませんか？

   9. 赤い封筒の説明には何文字まで入力できますか? 10

   10. 赤い封筒の説明、金額、および赤い封筒の番号ボックスがコピー アンド ペースト操作をサポートするかどうか

   11. 赤い封筒の説明内の絵文字は削除できます

   12. あなたが送った赤い封筒を他の人が受け取ることはできますか?

   13. 2人に渡された赤い封筒を受け取ることはできますか？

   14. 24 時間以内に請求されなかった赤い封筒は元の口座に返却できますか?

   15. 24 時間以上請求されていない赤い封筒を受け取ることはできますか?

   16. ユーザーは赤い封筒を何度も受け取ることができますか?

   17. 赤い封筒を送る人は、複数人分の赤い封筒を受け取ることができますか?

   18. 赤い封筒の金額の小数点以下の桁数に制限はありますか?

   19. リターンキーを押すと赤い封筒の送信をキャンセルできます

   20. インターネットが切断されている場合、赤い封筒を受け取ることはできません

   21. 自分の支払い方法を選択できますか?

   22. 残高が不足した場合、支払い方法は自動的に照合されますか?

   23. 赤い封筒送信インターフェイスで赤い封筒を送受信した以前の記録を確認できますか?

   24. 赤い封筒の記録の情報は、赤い封筒の送受信の実際の記録と一致しますか?

   25. 支払いの際には、パスワードまたは指紋を使用して支払うことができます。

   26. 小数点を直接入力する場合は、小数点の前に 0 が必要です。

   27. 支払いが完了したら、チャットの世界に戻ります

   28. 発行した赤い封筒の量と受け取った赤い封筒の量は一致する必要があります

   29. 赤い封筒を続けて複数回送ることは可能ですか？

   30. 金額を0と入力すると「赤い封筒にお金を入れる」がグレーアウトされます

2. パフォーマンス テスト
   1. ネットワークが弱い場合の赤い封筒の取得と赤い
   封筒の送信時間 2.
   さまざまなネットワーク速度での赤い封筒の取得と送信 3. 赤い封筒の送受信に成功した後のジャンプ時間
   4. 消費電力赤い封筒の送受信について
   5. 返却 支払いが到着するまでの時間

3. 互換性
   1. iOS と Android の両方で赤い封筒を送信できるかどうか
   2. コンピューターが WeChat の赤い封筒を取得できるかどうか

4. インターフェーステスト
   1. 赤い封筒を送信するインターフェースにタイプミスがない
   2. 赤い封筒を送信および受信するインターフェースのレイアウトが適切である
   3. 赤い封筒を送信および受信するインターフェースの色が適切に一致している

5. 安全性試験

   1. 相手が別の場所から WeChat ID でログインした場合、リマインダーは表示されますか?
   2. 赤い封筒を受け取ると、赤い封筒を送った人の金額が減り、受け取った人の金額も減ります。 3.赤い封筒の
   送信に失敗しても、キャッシュ カードの残高と金額は減りません
   4 . 赤い封筒の送信が成功すると、WeChat Pay から通知が届きますか?

6. ユーザビリティテスト
   1. 赤い封筒の説明を音声入力可能
   2. 支払い方法は指紋決済またはパスワード決済が可能

一般的に使用されるブラック ボックス テスト方法について教えてください。どのような状況でどちらを使用するのですか?

同値クラス分割、境界値解析、誤差推論法、原因影響図法、決定表分析法、直交検定法、関数図法、シナリオ法；

等価クラス分割: 等価クラス分割の方法は、プログラムの入力領域をいくつかの部分 (複数の等価クラスとも言えます) に分割し、テストのために各部分から少数の代表的なデータを選択します。

境界値分析手法: 境界値分析手法は、入力または出力の境界値をテストするブラック ボックス テスト手法です。境界値分析は通常、同値クラス分割法の補足として使用され、この場合、そのテスト ケースは同値クラスの境界から取得されます。

エラー推測法: テスターが経験、知識、勘に基づいてソフトウェアのエラーを発見し、プログラムに存在する可能性のあるさまざまなエラーを推測し、対象を絞ったテストを実施します。

特性要因図法：さまざまな入力の組み合わせをグラフィカルな方法で分析してテストケースを設計する手法で、プログラムの入力条件のさまざまな組み合わせを確認するのに適しています。

デシジョンテーブル分析手法: デシジョンテーブルは、複数の論理条件の下で異なる操作を実行する状況を分析して表現するツールです。

直交テスト方法: 直交とは、多数のテスト点から適切な数の代表点を選択することです。直交実験計画法とは、複数の因子と水準を研究する計画法であり、直交性、高効率、経済性に基づいた実験計画法です。

ファンクションダイアグラム方式: プログラムの機能記述は、通常、動的記述と静的記述から構成されます。動的仕様は、入力データの順序または転送の順序を記述します。静的記述は、入力条件と出力条件の対応を記述します。

シナリオ方式: ほとんどのソフトウェア システムは、ビジネス プロセスを制御するためにイベント トリガーを使用します。イベントがトリガーされたときのシナリオがシナリオを形成し、シナリオのさまざまなトリガー シーケンスがユース ケースを構成します。

ホワイトボックステストとブラックボックステストの違いは何ですか?

ブラックボックステスト:

ブラックボックステストは、機能テストやデータドリブンテストとも呼ばれ、製品が持つべき機能をもとに、各機能が正常に使用できるかどうかをテストするもので、テストの際にはプログラムをブラックボックスとして見立て、テストを行います。テスターは、プログラムの内部構造や内部特性を考慮せず、プログラムの機能が要求仕様に従って正常に使用されるかどうか、入力データを正しく受信できるかどうかだけをチェックして、プログラムのインターフェイスをテストします。生成 情報を正しく出力し、外部情報 (データベースやファイルなど) の整合性を維持します。

「ブラック ボックス」手法では、プログラムの外部構造に焦点を当て、内部の論理構造は考慮せず、ソフトウェア インターフェイスとソフトウェア機能をテストします。「ブラック ボックス」手法は徹底的な入力テストであり、考えられるすべての入力をテスト状況として使用することによってのみ、この方法でプログラム内のすべてのエラーを検出できます。実際にはテスト ケースは無限に存在するため、すべての合法的な入力をテストするだけでなく、合法ではないが可能な入力もテストする必要があります。

一般的に使用されるブラック ボックス テスト方法には、同値クラス分割法、境界値分析法、原因と結果図法、シナリオ法、直交実験計画法、デシジョン テーブル駆動分析法、誤差推測法、関数図分析法などがあります。

ホワイトボックステスト:

ホワイトボックス テストは、構造テストまたはロジック駆動テストとも呼ばれ、テスト対象のユニットが内部でどのように動作するかをテストします。プログラムの制御構造に基づいてテストケースを設計し、主にソフトウェアやプログラムの検証に使用されます。ホワイトボックステスト手法は、プログラムの内部論理構造を調べ、すべての論理パスをテストする徹底的なパステスト手法ですが、すべてのパスをテストしたとしても、エラーが存在する可能性があります。理由: 網羅的パス テストでは、プログラム自体が設計仕様に違反しているかどうか、つまり、間違ったプログラムであるかどうかを確認できません。網羅的パス テストでは、パスの省略によるプログラムのエラーの有無を検出できません。網羅的パス テストでは、関連するデータを見つけることができません。関連するエラーに。

ホワイト ボックス テストが従う必要がある原則は次のとおりです: 1. モジュール内のすべての独立したパスが少なくとも 1 回テストされることを確認する; 2. すべての論理値が真 (true) と偽 (false) についてテストされる必要がある; 2状況; 3. プログラムをチェックする 内部データ構造により、その構造の妥当性が保証されます; 4. 上限と下限および動作可能な範囲内ですべてのループを実行します。

一般的に使用されるホワイト ボックス テスト方法:

静的テスト: コード検査、静的構造解析、コード品質測定、ドキュメントテストなど、プログラムの実行を必要としないテスト。人間の論理的思考の利点を最大限に活用して手動で実行することも、手動で実行することもできます。ソフトウェア ツール (Fxcop) を使用して自動的に実行されます。

動的テスト：機能確認やインターフェーステスト、カバレッジ分析、パフォーマンス分析、メモリ分析など、プログラムを実行してコードを実行し問題点を見つける必要があります。

ホワイト ボックス テストのロジック カバレッジには、ステートメント カバレッジ、決定カバレッジ、条件カバレッジ、決定/条件カバレッジ、条件の組み合わせのカバレッジ、およびパス カバレッジが含まれます。6 つのカバレッジ標準のエラー検出能力は、弱いものから強いものへと変化します。

1. ステートメントの適用範囲 各ステートメントは少なくとも 1 回実行されます。

2. 各決定をカバーする各分岐は、少なくとも 1 回実行する必要があります。

3. 各判定をカバーする各条件は、さまざまな可能な値を取る必要があります。

4. 判定・条件網羅は、判定網羅条件網羅を同時に満たします。

5. 条件の組み合わせは、各判定の条件の各組み合わせをカバーし、少なくとも 1 回出現します。

6. パス カバレッジにより、プログラム内のすべての可能なパスを少なくとも 1 回実行できるようになります。

テストスキャンコード支払い、テストシナリオ

QRコードシナリオのユースケース

QR コードを書き込むユースケースは次のように分類できます。
1. 生成された QR コードが正しく認識され、支払者が携帯電話でスキャンできるかどうか。

2. QRコードは正しいですか? コードを読み取った後の機能は正しいですか(本来はコレクションコードですが、支払いコードが生成されると正しくなくなります)

3. QRコードのサイズと鮮明さ

4. QRコードを更新するかどうか（通常、支払いコードは変更されませんが、支払いコードは定期的に更新されます）

5. QRコードからの距離。QRコードの角度としては、正面からコードをスキャン、横からコードをスキャン、水平方向と垂直方向にコードをスキャン、写真を撮った後にローカルでコードをスキャンします。異なる Android デバイスと iOS デバイスを使用して QR コードをスキャンした場合、QR コードは正常に表示されますか?

コードのスキャンシーン

QR コードのスキャンは、支払者の使用シナリオです。

1. ネットワーク環境、ネットワークがない場合でも QR コードをスキャンできますか
? 2. コードをスキャンするときに、金額を自分で入力できますか、それとも固定の支払い金額ですか (個人支払いの場合はユーザーが入力します)金額を自由に選択し、生成された注文のコードをスキャンします。これは固定金額です）
3. 販売者によって生成された固定注文の場合、ユーザーは金額を変更できますか？
4. 加盟店が生成する確定注文の場合、ユーザーは一度支払った後に再度支払うことはできますか？
5. 複数のユーザーが QR コードをスキャンして同時に支払い、固定注文の支払いは 1 回のみです。

支払いシナリオ

1. 支払い金額シナリオ:

   1. 支払い金額を空、0、負の数値にできるかどうか
   2. 支払い金額の小数点以下の最大桁数 (通常は小数点以下 2 桁、分単位で正確)
   3. 1 回の取引の最大
   金額 4. 1日

2. 支払い方法:
   1. 支払い方法: 残高、余額宝、花北、クレジット カード、銀行カード
   2. 支払い順序、デフォルトの支払い順序 (または自分で設定した支払い順序)
   3. 最初の支払い残高が不十分な場合、デフォルトで 2 番目の支払いを使用できますか?
   4. 銀行カードごとに限度額が異なるなど、支払い方法ごとに 1 回の取引に制限があります。

3. 支払いパスワード:
   ユーザーが支払い方法と支払い金額を選択したら、次のステップは取引パスワードを入力することです
   1. パスワードで支払う、指紋で支払う、または顔スキャンで支払う
   2. 正しいパスワード、取引は成功します
   3. 間違ったパスワード、トランザクションが失敗する
   4. トランザクションが失敗した後、再度支払うことはできますか
   ? 5. ユーザーが支払いをキャンセルします
   6. ユーザーは支払いを行わず、期限切れおよびタイムアウトにします。

4. 支払いステータス:
   支払い後、支払いステータスが表示されます。
   1. 支払い失敗、注文ステータス
   2. 支払い成功、注文ステータス
   3. ユーザーによる支払いキャンセル、注文ステータス
   4. 支払いタイムアウト、注文ステータス

5. 調整:
   1. 支払者が正常に支払った後、金額は減りますか?
   2. 受取人が支払いを受け取った後、すぐに届きますか、それとも遅れますか?
   3. 受取人がインターネットにアクセスできない場合、相手方が支払った後、正常に完了しました。次回インターネットに接続したときに支払い記録を確認できますか
   ? 4. もちろん、Alipay には言語ブロードキャストもあります: Alipay は xx 元を受け取りました

6. 返金:
   支払者が支払いを行った後、突然後悔した場合、返金機能が関与します
   1. 返金は元のルートに戻るのか、それとも何ですか?
   2. 即時支払いまたは手動処理?
   3. 返金時に手数料は引かれますか？
   4. 返金後、注文ステータスが変わります

7. 手数料：

   手数料といえば、相手がHuabeiで支払い、クレジットカードを使用した場合、手数料に関する問題がありますが、
   1.相手がHuabeiで支払い、クレジットカードを使用した場合、手数料の控除率は正しいですか？
   2.返金の際、手数料は含まれますか？

8. 赤い封筒とクーポン
   1. 支払者が使用できるプラットフォーム用赤い封筒を持っている場合、プラットフォーム用赤い封筒から差し引くことができるかどうか、受取人は赤い封筒の影響を受けない 2. クーポンの使用も
   あり、全額割引クーポン、重ねて使えるかどうか、固定商品クーポン
   3 .返金の際、これらの赤い封筒やクーポンは無効になるのでしょうか、それとも同じように返却されるのでしょうか？

余額宝のテストケース

ユーザーの観点:
機能テスト: ユーザーが QR コードまたは支払い用の QR コードを正常に生成できるかどうか、QR コードが表示された後に画面が明るいモードに変更できるかどうか、ユーザーが「Huabei」などの別の支払い方法を正常に選択できるかどうか「」、「口座残高」、「楽宝」、「銀行口座」など。QR コードをスキャンした後、ユーザーは成功した支払いインターフェイスを受け取ることができますか。また、インターフェイスは、支払い情報、割引を使用するかどうか、割引などを含む、ユーザーが支払った金額を正しく表示できますか。
インターフェイステスト: Alipayを開いた後、インターフェイスが正しく表示されるか、QRコードインターフェイスが正しいか、支払いの各ステップのインターフェイスが正しいかどうか。フロントエンド インターフェイス エラーが発生しないか、インターフェイスを開けません。
使いやすさテスト: ユーザーの支払いプロセス全体における操作手順がシンプルかつ便利であるかどうか。
互換性: スキャン コード支払い機能をテストして、さまざまな携帯電話ブランドやさまざまなオペレーティング システムで互換性があるかどうかを確認します。
セキュリティテスト: QRコードがセキュリティ時間を超えた場合、新しいQRコードに自動的に更新されますか。支払いプロセス全体のセキュリティメカニズムが正常に実装できるかどうかをテストします。
ストレステスト: QR コードを継続的にスキャンして、強い圧力下でスキャンコード支払い機能がどのように機能するかをテストします。
ネットワーク テスト: さまざまなネットワーク環境やネットワーク信号強度の下で支払いプロセス全体が停止しているかどうか、および停止ポイントが発生する可能性がある場所をテストします。
マーチャントの観点:
機能テスト: コード スキャナーがユーザーの携帯電話の QR コードを正常にスキャンできるかどうか、コードを正常にスキャンした後にお金を受け取ることができるかどうか、および支払いインターフェイスが正常に生成できるかどうか。Alipay バックエンド、販売者のバックエンド、ユーザーの携帯電話が支払い結果情報を正常に送信できるかどうか。
ユーザビリティテスト: QRコードをスキャンしてお金を集める機能が、さまざまな照明条件や画面の明るさの下で正常に完了できるかどうか。

WeChat で写真を送信するためのテスト ケース

機能テスト：

• 送信する元の画像をクリックし、受信者が元の画像を受信するかどうか
• 写真は正常に送受信できますか？
• 一度に送信できる写真の最大数
• 写真の数に制限はありますか? 最新バージョンの WeChat では、最大 99 枚の連続写真を送信できます。
• 画像のサイズが大きすぎる場合でも送信できますか？
• 画像サイズが小さすぎる場合は送信できますか？
• png、jpg、jpgeなどのさまざまな形式の写真を送信できますか
• 画像を送信した後、受信者がクリックして元の画像を表示しなかった場合、元の画像が無効になるまでどのくらいの時間がかかりますか?
• アルバム内で写真を選択できるか、写真を直接撮影して送信できるか
• 送信された写真は取り下げることができますか?
• 写真の送信に失敗した場合、もう一度送信できますか?
• 送った写真は削除できますか？

性能試験：

• 写真を送信します。アップロードにはどのくらい時間がかかりますか?
• 写真の受信にはどのくらい時間がかかりますか? 所要時間内ですか?

互換性テスト:

• 異なる携帯電話システム、異なるバージョン、異なるブラウザ、異なる携帯電話モデル、異なるコンピュータのバージョンとシステムが互換性があります。
• ネットワーク状況が悪い場合でも正常にメッセージを送受信できますか?

インターフェースには以下が表示されます。

• 双方のアバターは正常ですか？
• メッセージは正常に表示されていますか？

シナリオ組み合わせテスト（ネットワークテスト）：

• ネットワーク状態が悪い、またはネットワークがない友人にメッセージを送信した場合、ネットワーク状態が回復すると正常に受信されますか?
• ネットワーク状態が悪い、またはネットワークがない友人に音声またはビデオ メッセージを送信する場合、ネットワーク状態が回復したときにメッセージは表示されますか?
• テキスト メッセージを編集する場合、音声またはビデオ チャットが中断された後、編集中のチャット ボックスに戻るかどうか
• 音声またはビデオ チャット中に電話やテキスト メッセージが着信すると、プロンプトが表示されますか?
• 音声またはビデオチャット中に電話機が低電力モードになると、プロンプトが表示されますか?

WeChat モーメントを送信するためのテスト ケース

WeChat モーメント テスト ケース_Zhao jc のブログ-CSDN ブログ_WeChat モーメント テスト ケース

ピックアップテストのやり方

クライアントまたは Web ブラウザをシミュレートしてサーバーにリクエストを送信し、リクエストを受信したサーバーは、受信したデータを処理してクライアントに応答を返します。

1. リクエストが正しいかどうかを確認します。デフォルトでは、リクエストが成功すると、システムはステータス コード 200 を返します。リクエストが正しくない場合は、ステータス コード 400、404、500 などを返します。

2. データを判断します: 返されたデータの正確さと完全性

3. セキュリティの決定: インターフェイスは通常、インターネット上に任意に公開されることはなく、他のユーザーが自由に呼び出すことができます。通常、インターフェイスにはリクエストの数やリクエストの頻度の制限など、いくつかの制限を設けます。

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

インターフェースのドキュメント

インターフェーステキスト

主に次の部分が含まれます。

• インターフェースの説明
• リクエスト方法
• リクエストURL
• リクエストパラメータ
• 戻りデータ
• インスタンスを返す

インターフェースのユースケース設計原則

インターフェイス テストの原理は、クライアントがサーバーにリクエスト メッセージを送信することをシミュレートすることです。リクエスト メッセージを受信した後、サーバーは対応するメッセージを処理してクライアントに応答を返し、クライアントはその応答を受け取ります。

インターフェイス テストで使用される方法は、実際にはブラック ボックス テストと一致しており、インターフェイスのテストはインターフェイスのない機能テストとして理解することもできます。ただ、インターフェイステストにはテストポイントが多く、インターフェイス上で検証する必要があるさまざまな機能ポイントに加えて、インターフェイスのセキュリティ、インターフェイスのパフォーマンスなども含まれます。

一般的なテスト ケースの設計は、単一のインターフェイス パラメーターの検証からビジネス機能ポイント全体の検証まで及ぶ必要があり、一部のセキュリティや異常な状態も検証できます。

WeChat撤退テストケース

1. 機能テスト:

• 出金可能な金額より多い/少ない/等しい金額を入力してください
• 入力した出金額が引き出し可能な金額を超えた場合、プロンプトは表示されますか?
• 出金金額入力ボックスに数字以外の文字を入力できるかどうかと小数点以下の最大桁数
• 複数の送信ボタンを接続して、繰り返し送信を実行します
• 送信後、キャッシュ カードがバインドされていない場合、一時的にキャッシュ カードを追加してキャッシュ カードを選択するように求めるプロンプトが表示されますか?
• 出金時に入力した取引パスワードが正しいか確認する
• 引き出しタイムアウトを確認します。
• 出金に失敗した場合は資金が返金される
• iOS、Android、Web での出金シナリオを確認します。

2.UIインターフェース:

• インターフェイスのレイアウトがずれていませんか?
• タイプミスはありますか？
• スタイルは統一されていますか？

3.パフォーマンス:

• 出金額が届くまでどのくらい時間がかかりますか?
• 到着した金額の通知はありますか?
• 金額が正常に出金されると、出金可能金額の欄は対応する金額だけ減りますか?

4.安全性:

• 引き出し金額が対応する口座に正常に入金されたかどうか
• 出金時にパスワード認証/指紋認証はありますか?

5. 弱いネットワーク:

• ネットワーク互換性 2/3/4/5g
• ネットワーク異常

6.使いやすさ:

• 操作は簡単で分かりやすいですか？

WeChat ログイン インターフェイスのテスト ケース

1. 機能テスト：
   1. 正しいユーザー名とパスワードを入力して送信ボタンをクリックし、正しくログインできるか確認してください。
   2. 間違ったユーザー パスワードを入力し、ログインが失敗したかどうか、および対応するプロンプト メッセージがあるかどうかを確認します。
   3. ログインに成功した後、正しいページにジャンプできますか?
   4. 携帯電話番号や WeChat QR コードを使用するなど、別のログイン方法を選択してログインできるかどうかを確認します
   5. ユーザー名を記憶する機能
   6. ログインに失敗した後、パスワード機能を記録できません
   7. パスワードが平文以外で表示される場合は、アスタリスクやドットなどの記号を使用してパスワードを置き換えます。
   8. 確認コードがある場合は、文字が歪んで認識しにくいかどうか、更新ボタンが使いやすいかなどを考慮してください。
   9. ログインページのパスワードを忘れた場合や登録、ログアウト等の接続は正しいですか？
   10. 大文字キーボードがオンになっている場合、パスワードを入力するときにプロンプ​​ト メッセージが表示されます。
   11. 何も入力せずに送信ボタンをクリックすると、プロンプトメッセージが表示されますか?
2. インターフェーステスト:
   1. レイアウトは合理的で、ボタンや入力ボックスはきちんとしていますか?
   2. 入力ボックスとボタンの長さと高さが要件を満たしているか
   3. インターフェースのデザインスタイルやUIのデザインスタイルは統一されていますか？
   4. インターフェース内のファイルは簡潔で理解しやすいですか? タイプミスはありますか?
3. 性能試験：
   1. ログイン画面を開き、所要時間が所要時間内であるかどうかを確認してください。
   2. 正しいユーザー名とパスワードを入力後、ログインに成功してページに遷移するまでの時間が規定時間内であるか確認してください。
   3. 多数のユーザーのログインをシミュレートし、一定の圧力下でログイン ジャンプが正しく実行できるかどうかを確認します。
4. 安全性テスト:
   1. ログイン成功後に生成される Cookie が盗まれることに同意しますか?
   2. ユーザー名とパスワードが暗号化された方法で Web サーバーに送信されるかどうか
   3. ユーザー名とパスワードの検証はサーバー側で行う必要があります
   4. パスワードとユーザー名の入力ボックスは SQL インジェクションから保護する必要があります。
   5. ブルートフォースクラッキングを防止し、ログイン数が表示されているかどうかを検出します
   6. 同じマシン上での複数のユーザーのログインをサポートするかどうか
   7. 同じユーザーが複数のマシンにログインできますか?
5. 互換性テスト
   1. 携帯端末とPC端末のそれぞれの機能は正しいですか？
   2. 同じプラットフォーム上の異なる WeChat バージョンにログインするのは普通のことですか?
   3. 異なる解像度での表示は正常ですか?
6. ローカリゼーションテスト
   1. 異なる言語環境でもページは正しく表示されますか?

ページをテストする方法

1. UIテスト:
   1. ページレイアウト、ページスタイルチェック、コントロール長が正しいかどうか
   2. ショートカットキーをサポートするかどうか
2. 機能テスト：
   1. ページ上の個々のコントロールをテストする
   2. パスワードボックスがプレーンテキストで表示されるかどうか、および入力がスペースを削除して処理されるかどうか
3. セキュリティ テスト: SQL インジェクション、スクリプト インジェクション テスト、バックグラウンド検証テスト、より重要なフォームの場合、バックグラウンド セキュリティ テスト、データが暗号化されているかどうか
4. 互換性テスト
5. 性能試験

ショッピングカートのテストケース

1. インターフェイスのテスト
   1. インターフェイスのレイアウトと組版は適切ですか?
   2. タイプミスはありますか？
   3. 異なる販売者の製品間に明らかな違いはありますか?
2. 機能テスト：
   1. ログインしていない場合
      1. 商品をショッピングカートに追加するとログインページにジャンプしますので、ログイン成功後に追加した商品が存在するか確認してください。
      2. ショッピングカートメニューをクリックするとログインページにジャンプします
   2. ログイン後
      1. すべてのリンクは正しいですか?
      2. 商品がショッピングカートに正常に追加できるかどうか
      3. ショッピングカートに入れる商品に制限はありますか?
      4. アイテムの合計数は正しいですか?
      5. 削除機能は使いやすいですか？
      6. 表示されている価格は正しいですか？
      7. 商品テキストが長すぎる場合に完全に表示できるかどうか
      8. 店名が長すぎても全文表示されます。
      9. クーポンが使える商品にはマークが付いていますか？
      10. 新しく追加されたショッピング カートのアイテムの並べ替え
      11. ショッピングカートのチェックアウト機能は使いやすいですか？
3. 互換性テスト
   1. さまざまなブラウザ
   2. さまざまなモバイル端末
4. 使いやすさ：
   1. 削除を促すメッセージはありますか?
   2. トップに戻る機能はありますか?
   3. 商品のチェックアウト時に詳細を表示するかどうか
5. 性能試験
   1. 圧力試験
   2. 同時実行テスト

開発に必要な機能をテストする

ホワイト ボックス テストやブラック ボックス テストなどのソフトウェア テストの理論的基礎が必要

プログラミング言語の基本的な知識が必要です

コンピューターの基本

必須：

ビジネス分析機能: ビジネス全体のプロセスの分析、テスト対象のビジネスのデータの分析、テスト対象のシステムのアーキテクチャの分析、テスト対象のビジネスのモジュールの分析、テストに必要なリソースの分析、およびテストの分析完了目標

欠陥洞察能力、一般的な欠陥発見能力、チームメンバーの問題解決の支援、協力してテストタスクを完了する、開発と協力して欠陥を再現する、プロジェクトの全体的な進行状況を監督する

専門的なスキル、テストの基本原則をマスターし、コンピューターの知識をマスターし、テスト ツールの使用に習熟する

問題解決能力、技術的問題、業務上の問題

コミュニケーション力・表現力、技術担当者、製品担当者、上司・部下とのコミュニケーション

商品テキストが長すぎても全文表示できるか
8. 店舗名が長すぎても全文表示できるか
9. クーポンとして使用できる商品にマークがついているか
10. 新規追加商品の並び替えショッピングカート
11. ショッピングカートのチェックアウト機能は使いやすいですか?
3. 互換性テスト

1. さまざまなブラウザ
2. さまざまなモバイル端末
3. 使いやすさ：
   1. 削除を促すメッセージはありますか?
   2. トップに戻る機能はありますか?
   3. 商品のチェックアウト時に詳細を表示するかどうか
4. 性能試験
   1. 圧力試験
   2. 同時実行テスト

開発に必要な機能をテストする

ホワイト ボックス テストやブラック ボックス テストなどのソフトウェア テストの理論的基礎が必要

プログラミング言語の基本的な知識が必要です

コンピューターの基本

必須：

ビジネス分析機能: ビジネス全体のプロセスの分析、テスト対象のビジネスのデータの分析、テスト対象のシステムのアーキテクチャの分析、テスト対象のビジネスのモジュールの分析、テストに必要なリソースの分析、およびテストの分析完了目標

欠陥洞察能力、一般的な欠陥発見能力、チームメンバーの問題解決の支援、協力してテストタスクを完了する、開発と協力して欠陥を再現する、プロジェクトの全体的な進行状況を監督する

専門的なスキル、テストの基本原則をマスターし、コンピューターの知識をマスターし、テスト ツールの使用に習熟する

問題解決能力、技術的問題、業務上の問題

コミュニケーション力・表現力、技術担当者、製品担当者、上司・部下とのコミュニケーション

巨視的な制御能力、テスト時間の効果的な制御、テストコストの効果的な制御、テスト計画の効果的な実行、効果的なリスク評価、およびテストの方向性の効果的な制御。