インターフェイスの機能テスト

サーバー以来インタフェースを介してサービスとクライアントとの対話のさまざまなデータを提供するためのプラットフォームであるため、サーバーのテスト作業を最初の必要性は、インタフェースのテストです。テスターは、インタフェース機能は、システムのテストクライアントとサーバの接合時に正しい、その後、他のテスターを達成することを確認する必要があり、サーバーの界面欠陥がサーバインタフェース機能テストを通じて人材位置決め開発問題を容易に発生したため、クライアントの問題を除外することができるようになります。以下は、学んだ個人レッスンのためのサーバ・インタフェース機能テスト・プラットフォームです：

まず、インターフェースのテスト範囲

    図3に示すように、サーバ全体のインタフェース試験、新しいサービス機能のインターフェースをテストする、2;新しいテストインターフェース、1：サーバーのテスト要件は、インターフェースの試験範囲が分割されています。所望順次増加試験試験インタフェース、十分な条件下で、試験時間は、もちろん、すべてのインタフェースをテストするように設計する必要があるが、テストが短い場合、ユーザの動作例に係る第一のテストインタフェースの優先順位であるべきです部門、テストのために頻繁に呼び出しインタフェースの優先順位の必要性について。

第二に、インタフェースのテスト戦略

       テストプラットフォームサーバ・インタフェースを実施する前に、まずあるテストサーバーのプログラム・インタフェース、インタフェースのテスト、インタフェーステストプラットフォームのコンテンツ・サーバーの分析点を配置する必要があります。

インターフェイスのデザインレビュー

データ交換サーバとクライアントのためのインターフェースは、クライアントがデータを入力するネットワーク・プロトコル・サーバ・インタフェースを介してデータを渡し、そのため、サーバとクライアント・インターフェース・ドキュメントを介して第1の制約文書データは、対話データの有効性を確認する必要があります。

Nは整数型のデータ・ビットであります

n個の倍精度浮動小数点データ

n個の文字列データ範囲値

これは、クライアントの整数、浮動小数点、文字列データと入力インタフェースサーバとして有効であることができる最大値と最小値を必要とします。作品には、クライアントデータが自動的に切り捨てたり丸めサーバーを動作させるためにアップロードされていないことを確実にするために、ときに、サーバーの設計レビューを行うことができます。

インターフェイスの依存性チェック

    ポリシーはユーザーのみのための単一のインターフェースの試験方法になる上に、アクションが完了するために複数のインタフェースを呼び出すためのサーバーを引き起こす可能性があり、それは、ビジネスプロセス、複数のインタフェースの観点から関与業務の様々なも必要ですテストのためのコール間の依存性。

    インタフェースの依存性チェック値は、主インタフェース出力インタフェースの前記入力値によって達成されるので、試験前にインタフェースは、入力値がインターフェイスを分析する必要があるテストは、他のインターフェイスまたは出力するためにクライアントによって得られます、とき、テストケースの設計、テストするためのインタフェースの依存関係の説明を追加します。

インタフェース入力/出力の検証

サーバインタフェース機能テストはテストユニットと同様であり、設計のテストケースは、焦点は、サーバーインターフェース処理は実施の形態によれば、様々なインタフェースが分類されている入力/出力項目の正当性を検証するために、インタフェースモジュール上にあります。

最初のカテゴリ：条件判断インタフェース

       要求データを受信した後、このようなインターフェースは、入力パラメータ条件に応じて決定され、適切な結果コードが返され、典型的には、条件付きインターフェース関与する：認証にユーザインタフェースを、更新ステータスレポートは、パスワードの変更/インターフェースをリセット。したがって、入力/出力に焦点を当てた重点を検証します。

1）決意条件を検証します

決意の条件を確認するために、例えば、パスワードリセットインターフェイスに応じて決定されるエントリであるインターフェースを知る必要があります。

パスワードリセットインターフェイス

「インターフェイス機能」：ユーザーがランダムにユーザーのメールボックスに送信された新しいパスワードを生成するためにユーザがログインした後、パスワードの操作が起動忘れた、ユーザーがメールボックスの情報を入力し、ゲームセンターでは、サーバプラットフォームにサーバープラットフォームを要求を送信します。

「インターフェイスの方向」：ゲームセンター - >サーバプラットフォーム

「プロトコルに従ってください」：HTTPS、要求メッセージは、ポスト方式を使用して

パラメーター名	パラメータタイプ	パラメータ長	説明
ユーザーID	int型	10	ユーザーID番号
Eメール	弦	60	E-mailアドレス
キー	弦	50	インタフェース名
バージョン	弦	8	版数

応答メッセージ（sendMessageRes）

パラメーター名	パラメータタイプ	パラメータ長	説明
resultCode	int型	5	リターン結果コード42000成功したリターンを表し、

判定データにこの正確インタフェース（サーバがエラーを処理しない場合、キーは、インターフェイスの名前で、バージョンは決意に関与していないだけで記録するために使用される値は、バージョン番号、である）ユーザーID、電子メールの入力パラメータ、テストインターフェイスデザインインタフェースが処理できるかどうかを使用する場合、最初のインターフェイスのパラメータを決定しなければならないが確認され、これらのエントリは、メソッドのユーザIDに応じて、有効なデータにデザインエントリの電子メールさまざまな同値分割、境界値を使用し、その後、空にすることはできません、検証。

レスポンス2）異常データ

かかわらず、異常なシーンのパスワードリセットインターフェイスのインターフェイス機能の正常な動作を保証することはできません、ユーザーIDは、違法な存在せず、通常の状況を考慮し、メール形式の入力エラー、ユーザーのメールボックスの情報が存在しないか、アクティブにされていないだけのテストを検討する必要があります異常なシナリオでは、このような入力値の設計、および異常な状況に応じて、対応するプロンプト情報を表示するためにクライアントに正しい応答コードを確実にするために、返された応答コードのインターフェイスをチェックします。要するに、条件判定インターフェイス戦略は、様々な入力インタフェースの値をテストするために設計された試験条件の裁量です。

第二のカテゴリー：データクエリーインターフェイス

       要求データようなインターフェースを受信した後に、それは最初の要求が正当で検証し、その後項目クエリに要求データベースをユーザープロファイル/経験/イベント情報クエリ：バック一般に、対応するクライアントテーブルデータには、クエリインタフェースであるデータに関する、ゲームのリストを取得するには、オンラインのお問い合わせやその他のインターフェイスの数。例えばユーザーエクスペリエンスへのクエリインターフェイス：

ユーザーエクスペリエンス問合せインタフェース

「インターフェイス機能」：ゲームセンターでユーザーがログインした後、あなたが経験、グレードのタイトル、今日のために経験値天井のプロジェクトのレベルを含む、彼らはそれぞれのゲームのプロジェクトを体験情報を照会することができます。

「インターフェイスの方向」：ゲームセンター - >サーバプラットフォーム

ポスト方式を使用してHTTP + XML、リクエストメッセージ：「プロトコルに従ってください」

パラメーター名	パラメータタイプ	パラメータ長	説明
ユーザーID	int型	10	ユーザーID番号
webkey	弦	60	現在ログオンしているユーザー指定のキーに割り当てられています
キー	弦	50	インタフェース名
バージョン	弦	8	版数
すべてであります	int型	1	ノー1;はい：0すべてのスポーツ経験するかどうかをユーザに問い合わせます
sportItemID	弦	50	スポーツIDは、isAll = 1が空白にすることはできません場合は、クエリの経験を指定し、スポーツ

応答メッセージ（sendMessageRes）

パラメーター名	パラメータタイプ	パラメータ長	説明
sportItemID	弦	50	スポーツID
sumExp	int型	11	運動経験の合計値
expLevel	int型	3	経験レベル
minExp	int型	11	この最小レベルの経験
expOrder	int型	11	経験ランキング
maxExp	int型	11	この最大レベルの経験
todayExp	int型	11	今日の経験を積みます
todayExpLimit	int型	11	経験キャップ今日
指定	弦	30	タイトル（経験値に対応します）
winCount	int型	11	勝利の上映
lossCount	int型	11	失敗したスクリーニング
isMaxExp	int型	1	経験合計値が0なしに最大化され、1であります

このインタフェースは、最初webkey要求に応じて判断する正当なものである場合、要求パラメータユーザーID、isAll、sportItemIDに応じてデータテーブルに対応するデータを問い合わせます。同じ条件としてインタフェースに加えて、決意のWebKey項目、要求パラメータのユーザID、isAll、sportItemID設計/合法正当と正常/異常検査値に基づくだけでなく、我々は、結合、データベースクエリの結果を確認する必要が決定されます。

1）かどうか、正しい関連データテーブルに基づいてクエリ。

2）クエリの結果を表正しいエントリは、種々の設計検証の異なるテーブル試験データにおける多関節問い合わせ、同じアイテムに関するデータテーブルから取得するかどうかを確認。

正しい出力インタフェースかどうかを確認するための値に対応する項目の範囲nullまたは最小値と最大値クライアントように3）、データテーブル内のデータ項目に対応するクエリ結果を変更します。

第三のカテゴリー：インターフェースの論理演算

       要求されたデータの受信後にそのようなインタフェースは、論理的な一連の動作を行い、その後、データ処理の結果に基づいてデータベースを更新し、通常、インタフェース論理演算を伴うであろう次のとおり同期競合の結果、商品の支払い、データインターフェイスのさまざまを報告しています。一例として、同期インタフェースに競争結果：

同期インタフェースの競技結果

「インターフェイス機能」：ゲームサーバ、ユーザはサーバプラットフォームに渡された結果をレースになるたびに、プラットフォームのサーバーは、ユーザーのトーナメントランキングレース結果に基づいてユーザを更新し、データベースに保存されています。

「インターフェイスの方向」：ゲームサーバ - >サーバプラットフォーム

HTTPS + XML、ポスト方式を使用して要求メッセージ：「プロトコルに従ってください」

パラメーター名	パラメータタイプ	パラメータ長	説明
ユーザーID	int型	10	ユーザーなかっI洞ありません
webKey	弦	64	現在ログオンしているユーザー指定のキーに割り当てられています
キー	弦	50	インタフェース名
バージョン	弦	8	版数
gymkanaCode	弦	30	ゲームは現在、ゲームに関与している、このパラメータはnullがゲームの普通のユーザーを示しています
sportItemID	弦	50	ゲームアイテムID
sportItemName	弦	50	プロジェクト名のゲーム
sportServerID	弦	50	ゲームサーバIP
matchSystem	int型	3	競争システムを実行するためにレーシング： 100米:1; 400米:2; 800米:4; 1500米:8; 4×100米:16;
matchId	弦	50	一意のIDはアップカミング
記録	ダブル		当前用户成绩 （如record=8.123456）。非正常结束比赛时，即isWinner＝3或4，如果是单人跑，isWinner=5，record=-1
unit	String	20	成绩单位
isWinner	Int	2	当前用户是否赢了0=输,1=赢，2＝未完成，3＝主动退出，4＝被迫退出
competitorID	Int	10	对手idong号
competitorRecord	double		当前对手成绩，规则同record
competitorIsWinner	int	2	对手输赢，规则同isWinner
starttime	String	14	开始时间(yyyy-MM-dd HH:mm:ss)
endtime	String	14	结束时间(yyyy-MM-dd HH:mm:ss)

响应消息（sendMessageRes）

参数名称	参数类型	参数长度	说明
resultCode	Int	5	结果返回码，返回42000表示处理成功
score	Int	11	本次得分
preRank	Int	11	赛前积分在赛后的排名
rank	Int	11	积分排名
upRankFlag	Int	1	排名上升：1；排名不变：0；排名下降：-1
isUpLevel	Int	1	经验值是否升级 0 否；1 是
exp	Int	11	本次增加的经验值
expLevel	Int	3	经验值等级
designation	String	30	称号（对应于经验值）
cPreRank	Int	11	对手赛前积分在赛后的排名
cRank	Int	11	对手赛后积分排名
cUpRankFlag	Int	1	对手排名上升：1；排名不变：0；排名下降：-1
encourageWord	String	15	鼓励语句

    此接口比数据查询接口又更加复杂，除了用条件判断和数据查询类接口的策略对此接口进行测试用例设计之外，还需要验证对接口的算法规则进行检查，因为此接口涉及根据用户比赛成绩(record)进行排名然后返回其得分及排名情况(score、rank、upRankFlag、exp)，通过对相关数据表中的数据进行查看方式，接口算法规则验证包括：

1）用户胜利、失败、中途主动/被动退出、规定时间内未完成比赛情况下，此场比赛得分(scroe)是否正确；

2）最後の結果よりも、ユーザーの競争の結果は、時間が短い、長い、平らなケースを取り、ランキング（upRankFlag）が正確です。

3）最初、最後、時間がかかり、最後の結果より短い/長い/平坦な場合にユーザーの競争の結果は、ユーザの順位（ランク）は正しいです。

4）ユーザの勝利、敗北、ハーフウェイアクティブ/パッシブ出口、レースが所定の時間内に完了せず、経験レベルの様々なユーザ経験の範囲は、経験値は式に従って計算正しいスコアです。

    インタフェース論理操作はさらに、データベース操作を挿入または更新することに関するものであるので、データベースは、そのようなデータの精度ようにShihai特性試験、問題考慮する必要がMySQLの浮動小数点データは、ときに精度誤差（131,072.32挿入フロート（保存された場合、データベース10,2）データのタイプ131,072.31になるであろう）、そして計算、統計、スコア比較可能なデータの量のために、従って必要性は、固定小数点型を使用するのが最適です。

    最後のテストサーバーインターフェイスに十分な条件も重要なコードのテスト杭を書き込むことによって、効果的にクロスボーダーのこのタイプを使用して文字列を読み取った結果として、文字配列を見つけることができ、ホワイトボックステストでインターフェースコードのさらにテストを行う必要があるならばBUGは、ブラックボックスを通じ見つけることは容易ではありません。次のジョブは、テストツールによってサーバ・インタフェース機能テストを実行する方法です。