1.インターフェースとは何ですか？
インターフェース：主に、サブモジュールまたはサブシステム間で相互作用および相互作用する部分。
ここで説明するインターフェイスは、広い意味で、クライアントとバックエンドサービス間のプロトコル、プラグイン間の通信用のインターフェイス、モジュール間のインターフェイス、クラスによって提供されるメソッドはインターフェイスとして理解できます。
インターフェイステスト：モジュールまたはシステム間のインターフェイスのテストを指します。
2.インターフェイステストでよく発生するバグと問題
（1）着信パラメータの不適切な処理により、プログラムがクラッシュする;
（2）タイプのオーバーフローにより、データの読み取りと書き込みに一貫性
がなくなる; （3）オブジェクトのアクセス許可が検証されていない、他のユーザーの機密情報にアクセスできる;
（4）状態の不適切な処理、ロジックの混乱につながる;
（5）不完全なロジック検証、および不正な利益を得るための抜け穴の悪用。
3.ユースケース設計のアイデア
インターフェイステストのユースケース設計では、主に入力とインターフェイス処理、および出力の3つの側面を考慮します。
（1）入力の場合はパラメータタイプに従って設計できます。
（2）インターフェイス処理の場合はロジックに従って設計できます。
（3）出力については、その結果に基づいて分析・設計を行うことができます。
3.0ユースケーステンプレート
3.1入力の設計
インターフェイスの場合、入力は入力パラメータです。一般的なパラメータタイプは次のとおりです。
（1）数値タイプ（int、long、float、doubleなど）
（2）文字列タイプ
（3）配列またはリンクリスト
（4）構造
構造（struct）は、いくつかの要素、実際の要素の組み合わせです。また、数値、文字列、配列、またはリンクされたリストです。
以下では、数値、文字列、配列、またはリンクリストの3つのパラメータタイプのユースケース設計について詳しく説明します。
3.1.1数値
パラメータ数値パラメータは、主に設計の次の側面を考慮します。
パラメータが値の範囲を指定する場合、値の範囲外の等価クラスの値の範囲、および値の境界を考慮する必要があります。必要に応じて、値の範囲内の各値をトラバースする場合があります。
たとえば、権限をチェックするためのインターフェイス：TaskChecker.checkTask（int taskID）taskIDの値の範囲は1〜35である場合、設計は次のことを考慮します。
1-35范围内和范围外的值；
1-35的边界：0，1,35,36；
**类型的特殊值：-1,0
数据类型的边界值：int的最小值最大值；**
因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
一般的な問題とリスク：
特別な値の不適切な処理により、プログラムが異常終了します。
タイプの境界が
値の範囲外の値をオーバーフローしても、正しいエラー情報が返されません。
3.1.2文字列タイプ
文字列タイプパラメータは、主に文字列の長さと内容を考慮します。
たとえば、アラームクロックを設定するインターフェイスDateUtil.getDayOfDDHH（String ddhh）は、ユースケースで考慮
することができます。長さは4桁で、4桁未満です。 4桁以上、
境界値：文字列の最大長、
特殊値：空の文字、
文字列の内容のタイプ：数値、非数値、
特殊文字。
**如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。**
考えられる問題とリスク：
着信する非特定タイプのプログラムが異常終了します。
超長文字が処理されないため、保存と表示が異常になります。
ユーザーに表示されるその他の機密文字。
3.1.3配列またはリンクリストタイプ
パラメータタイプが配列またはリンクリストの場合、ユースケースを考慮することができます。
たとえば、タスクのバッチ送信用のインターフェイスsubmitTask（int [] taskID）、パラメータのユースケース設計の考慮事項：
通常値：1〜5アクセス許可、範囲外：6アクセス許可;
境界値：境界値1-35、リクエストは最大値と最小値を許可します;
特別な値：0;
正当なIDと不正な;
重複したIDなど。
考えられる問題とリスク：
アイテムが0の場合、プログラムは異常終了します。
重複するアイテムが処理中に重複排除されない場合、結果は異常になります。
3.2ロジックデザインの場合
インターフェイスにロジック処理が必要な場合、ロジックデザインのユースケースを次の観点から分析できます。
3.2.1制約条件の分析
（1）数値制限：スコア制限、ゴールドコイン制限、レベル制限など。
例：Qコインの交換には、参加するために50を超えるポイントが必要です。
（2）ステータス制限：ログインステータスなど。
例：ユーザー情報を同期するには、最初にアカウントにログインする必要があります。
（3）関係の制限：拘束された関係、友情関係など。
たとえば、家族の不正防止機能は、バインドされた家族の着信情報のみを照会できます。
（4）権限制限：管理者など。
制約テストは、機能テストでよく発生し、インターフェイステストでより重要になります。その重要性は、ユーザーが操作を実行するときに、操作のフロントエンドで制限条件が実行された可能性があるため、ユーザーがこのインターフェイスの要求を直接トリガーできないことです。しかし実際には、UIのバグや技術的な手段によるインターフェースへの直接呼び出しなど、他の手段がある場合は、インターフェースがこれらの条件に対して制限されているかどうかが特に重要です。
たとえば、一般的な例：5Qコインを交換するには200ポイントかかりますが、ポイントが足りないため、償還ボタンが灰色でクリックできません。
通常のユーザーは操作できませんが、交換は実際にはバックエンドのインターフェースです。ページボタンの制限をバイパスし、バックエンドインターフェースを直接呼び出して交換する場合はどうでしょうか。交換できますか？もちろん、期待は転換できません。したがって、積分の数値限界をインターフェースでテストする必要があり、それは非常に重要です。
他の制約も同様です：
時間制約：22：00より前;
数値制約：200ポイント;制限5;
ステータス制約：携帯電話マネージャーにログイン;
その他の制約も同様です。
一般的な問題とリスク：
制約条件の判断が不十分であり、ユーザーが特別な手段で利益を得るように導く
3.2.2操作対象の分析
通常、操作は対象を対象とします。たとえば、ユーザーが電話番号をバインドし、電話番号が操作の対象となり、この電話番号の通話料金とトラフィックも対象になります。
オブジェクト分析は、主に合法および違法なオブジェクトを操作するためのものです。たとえば、次の使用例：
ユーザーAが電話P1の通話料金
について問い合わせる：ユーザーAが電話P1トラフィック
について問い合わせる、ユーザーAが電話P2トラフィックについて問い合わせる、ユーザーAが電話P2トラフィックについて問い合わせる
。
バックグラウンドロジック処理では、電話がバインドされている場合、バックグラウンドの観点から電話料金とトラフィックを照会できます。ただし、ユーザー側では、Aが電話の通話料金について問い合わせられるように、Aにバインドされた電話である必要があります。したがって、同様のオブジェクトのテストも不可欠です。
一般的な問題とリスク：
ユーザーは、権限の範囲外の他のユーザー情報や機密情報にアクセスして、この情報を利益のために使用することができます
3.2.3状態遷移分析
テスト中のロジックはステートマシンに抽象化でき、各状態は機能ロジックに従ってある状態から別の状態に切り替わります。このシーケンスを中断して、ある状態から次の状態ではない別の状態に切り替えると、ロジックが中断され、ロジックの問題が発生します。
特定の状態から新しい状態への変更は、遷移インターフェイスによって異なります。変換インターフェイスの場合、Fun23などの入力状態が決定されます。この関数は、状態2を状態3にのみ変換でき、状態1を状態3に変換することはできません。次に、テストポイントは次のようになります。
（1）状態が状態2の場合、インターフェイスFun23（）を呼び出し、状態が状態3に切り替わります。
（2）状態が1、3などの場合、インターフェイスFun23（）を呼び出すと、状態を切り替えることができません。
たとえば、タスクを実行する場合、タスクには3つの状態があります。受信されていない、受信されているが送信されていない、完了しています。
次に、次のように設計できます。
（1）通常の状態の切り替え：未請求状態、タスクを受信した後、受信状態になります。タスクを受信して送信すると、完了状態になります。完了後、タスクを再度受信できます。
（2）異常状態切り替え：タスクを受け取らずにタスクを送信し、タスクの条件を満たす、タスクを受け取ったときに再度受け取るなど。
一般的な問題とリスク：
特別な方法を使用して、他の方法では不可能な状態を達成し、それによって利益を追求することができます。
3.2.4時系列分析
一部の複雑なアクティビティでは、アクティビティは指定された順序で一連のアクションによって実行されます。これらのアクションはアクションフローを形成します。この順序で実行することによってのみ、期待される結果を得ることができます。
通常のプロセスでは、これらのアクションはプログラム呼び出しに従って順番に実行され、中断されることはありません。インターフェイステストでは、タイミングがインストールされていない場合に問題が発生するかどうかを考慮する必要があります。
たとえば、クライアントデータの同期はクライアントによってトリガーされ、その間、ユーザーは同期に介入できません。機能テスト中に確認できるのは、同期を正常に実行できるかどうかです。さらに分析すると、同期プロセスには実際には一連のアクションが含まれます。
シーケンス図から、バックグラウンドには3つのインターフェイスがあることがわかります。ログインしてユーザーIDを取得し、ローカルデータを報告し、ローカルの競合を報告します。同期を完了するには、3つのインターフェイスを順番に呼び出して実行する必要があります。次に、インターフェイステストで、実行する上記のインターフェイスの実行シーケンスを中断すること、結果はどうなるか、および例外が発生するかどうかを検討できます。例：ユーザーIDを取得した後、ローカルデータは報告されませんが、ローカルの競合は直接報告されます。
一般的な問題とリスク：
非順次実行後、データは異常になり、プログラムの他の異常も現れる可能性があります。
順序を乱すことで利益を得る
3.3出力の設計出力の設計
は、実際にはインターフェイスから返された結果を分析しています。
3.3.1出力結果の
場合インターフェイス処理の正しい結果は1つだけですが、エラー例外の戻り結果には多くの場合と多くの値があります。多くの種類の結果があることがわかっている場合は、さまざまな結果のユースケースを設計できます。たとえば、統合タスクを送信するとき、通常は正しさとエラーを返すことを考えます。エラーは、無効なタスク、無効なログイン状態を考える場合がありますが、すべてのエラーコードを完全にカバーできない場合があり、インターフェイスは定義された戻りコードを返し、さらに設計します。例：
リターンコードをオーバーライドすることも、ユースケースデザインのアイデアです。
一般的な問題とリスク：
（1）エラーのフロントエンド処理が不十分な場合、フロントエンドの例外が発生します。
（2）エラープロンプトの処理が不適切な場合、ユーザーにはあいまいなエラーコードが表示されます。
（3）エラープロンプトが不適切な場合、ユーザーは何が問題だったのかわかりません。の解き方。
3.3.2インターフェイスのタイムアウト
インターフェイスは通常の状況で戻る可能性があるので、インターフェイスが戻らない場合はどうなりますか？つまり、インターフェイスタイムアウト後の処理も、考慮する必要のあるテストの一部です。タイムアウトが適切に処理されない場合、次の問題が発生する可能性があります。
（1）タイムアウト処理が実行されなかったため、プロセス全体がブロックされました。
（2）タイムアウト後、返されたインターフェイスが受信され、ロジックが混乱しました。
3.4その他のテスト設計
3.4.1廃止されたインターフェイステスト
廃止されたプロトコルは以前の定義を参照していますが、要件の変更またはその他の理由により、現在のバージョンは使用されていません。これらのインターフェースは使用されなくなりましたが、コードが時間内に削除されなかった可能性があります。技術的な手段を使用してこれらのインターフェイスを呼び出すと、追加のメリットが得られる場合があります。
たとえば、タスクの前にクリーンアップタスクがある場合、バージョン要件でクリーンアップタスクをダウンロードタスクに置き換えます。新しいバージョンのクライアントでは、クリーニングタスクを完了するためのインターフェイスは呼び出されなくなりましたが、インターフェイスが閉じられていない場合、ユーザーは引き続きsubmitTask（int taskID）インターフェイスを要求して、クリーニングタスクを完了してポイントを獲得できます。
したがって、古いバージョンとの互換性を考慮しながら、新しいバージョンでは、関連する廃止されたインターフェイスもチェックして、ユーザーが追加のメリットを享受できないようにする必要があります。
3.4.2インターフェース設計の合理性の分析
インターフェース定義が合理的であるかどうかは、次の側面から分析できます。
（1）インターフェースフィールドが冗長である
かどうか、（2）インターフェースが冗長である
かどうか、（3）インターフェースが呼び出し元が期待する情報を返すかどうか;
（4）すべての呼び出しのニーズを満たす
インターフェイスの定義かどうか; （5）呼び出しが便利なインターフェイス定義かどうか。
3.5完全な例
以下は、上記の方法でインターフェース設計を使用する方法を分析するための完全な例です。
モジュールは他のモジュールへのインターフェースを提供し、ユーザーはタスクを要求します。インターフェースは次のように定義されます。
4.まとめ
インターフェイスのユースケース設計方法では、入力と出力の設計はユニバーサルであり、両方ともインターフェイスの設計時に使用できます。インターフェイスロジックの設計には、1つ以上の適切な方法を適用できます。インターフェイスのユースケースを設計する場合、テスト対象のロジックをカバーするために最適な方法を選択する必要があります。