インターフェース
1.コンセプト
システムとコンポーネント間のデータ転送と対話のためのチャネル。
2. タイプ
プロトコル別：http、tcp、IP
言語別：C++、java、php 。。
範囲による分割:
1) システム間:
複数の内部システム間、
内部システムと外部システム間、
2) プログラム間:
メソッド間、関数間、モジュール間
インターフェイスのテスト
1.コンセプト
インターフェイステストは、システムまたはコンポーネント間のインターフェイスをテストすることです。渡されたデータの正しさと論理的な依存関係の正しさを検証してください。
2. 原則
インターフェイスのテストは主にテスト対象、つまり
サーバー 2.1 をテストする方法を目的としています。
クライアントをシミュレートし、サーバーにリクエストを送信します。
2.2 テストには何を使用しますか?
ツール: fiddler、postman、Jmeter
コード: python + UnitTest フレームワーク + Requests フレームワーク
2.3 何をテストするか?
クライアント要求に応じてサーバーから返された応答データが、予期した結果と一致しているかどうかをテストします。
人間の目の比較の
主張
3. 特徴
品質管理を前進させるというコンセプトに沿って、
ページ操作では発見できない問題点を発見できる、低コストで効果の高い
インターフェイステスト
、ユーザー視点でシステムをテストするインターフェイステスト、ユーザー視点でシステムをテストするインターフェイステスト、などを実現しています。
4. 実施方法
ツール: JMeter、Postman、フィドラー
コード: Python + リクエスト + UnitTest
自動インターフェイステストとは何ですか?
ツールとコードを使用して、サーバーにリクエストを送信するクライアントをシミュレートし、アサーションを使用して、期待される結果が実際の結果と一致するかどうかを自動的に判断します。
HTTP プロトコルの概要
1.HTTP
HTTP : (ハイパーテキスト転送プロトコル) ハイパーテキスト転送プロトコルは、要求と応答モデルに基づくアプリケーション層プロトコルであり、インターネット上で最も広く使用されているネットワーク プロトコルでもあります。
特徴:
クライアント/サーバーモードをサポート、
シンプル、高速
、柔軟
、コネクションレス
、ステートレス
2. URL形式
概念：（Uniform Resource Locator）Uniform Resource Locatorの機能
：ネットワーク環境において、データリソースを一意に定義する
3.HTTPリクエスト
機能: クライアント (アプリ、ブラウザ) は、サーバーにリクエストを送信するときにプロトコル (http リクエスト プロトコル) を使用します。
サーバーへのデータ送信の構文形式を指定します。
3.1 リクエストフォーマット
リクエスト行: http リクエストの最初の行。リクエストメソッド (スペース) URL (スペース) プロトコルバージョン
リクエストヘッダー: 構文形式: k:v
User-Agent : リクエスト送信元のブラウザータイプを記述します
Content-Type : リクエストボディのデータタイプを記述します
空行: http を表します
リクエストを終了するリクエスト ヘッダーBody : リクエストの送信時に送信されるデータ。データ型 Content-Type! の値。
post と put にはリクエスト本文がありますが、
get と delete にはリクエスト本文がありません。
3.2 リクエストライン
http リクエスト メソッド: 大文字と小文字の両方
GET: クエリ。—— リクエスト本文なし
POST: 追加。(ログイン時によく使用されます)
put: 変更します。
削除：削除します。—— リクエストボディなし
3.3 リクエストヘッダー
データ形式: k: v
Content-Type:
application/json: JSON データ形式
application/x-www-form-urlencoded: フォーム フォーム データ
3.4 リクエストボディ
GET と DELETE には
PUT と POST がありません。
データ型は Content-Type 値の影響を受けます。
4.HTTPレスポンス
サーバー側は、クライアントから送信された http リクエストに対する応答データを返します。—— http 応答!
クライアントに送り返されるデータの編成形式を指定します。
応答行（ステータス行）： プロトコルバージョン（スペース） ステータスコード（スペース） ステータス説明
レスポンスヘッダ： 構文形式： k:v
Content-Type： レスポンスボディのデータ型を記述します。
空行: 応答ヘッダーの終わりを表します
応答本文: ほとんどは空ではありません。(リクエストが成功した場合: データが返送され、リクエストが失敗した場合: エラー情報が返送されます)
データ型は Content-Type 値の影響を受けます。
4.1 ステータス行
ステータスコード:
1xx : 命令情報を表します。リクエストが受信され、処理を待機していることを示します。
2xx : リクエストが正常に処理され、受信されたことを示します。共通: 200、201
3xx : リダイレクトの場合、アクセスするリソースを再指定してアクセスする必要があります。
4xx : クライアントエラーを表します。共通: 404、403
5xx : サーバー側のエラー。
ステータス コードの説明: 通常、ステータス コードに一意に対応します。200 —— OK; 404 —— ファイルが見つかりません
4.2 レスポンスヘッダー
構文形式: k: v
Content-Type: 値は、応答本文のデータ・タイプです。
Content-Length: 応答本文のサイズ。記述する必要はありません。ブラウザが自動的に取得します。一度書いたら、それは正確でなければなりません。
4.3 レスポンスボディ
クライアントに送り返されるメッセージの内容。一般的なものには、HTML Web ページ、XML、JSON などがあります。
インターフェイスのスタイル
1.伝統的なスタイルのインターフェース
特徴:
request メソッド。get と post のみを使用します。
URL は一意ではありません。同じ操作で異なる URL
ステータス コードに対応でき、使用方法は比較的簡単です。最も一般的なのは 200 です。
2. RESTful スタイルのインターフェース
特徴:
各 URL はリソースを表します;
このリソースの特定のプレゼンテーション層はクライアントとサーバーの間で転送されます;
プレゼンテーション層: データの異なるプレゼンテーション形式 (同じデータ オブジェクトを表す画像やテキストなど) クライアントは
4 つの HTTP を渡します動詞 (GET、post、delete、put) はサーバー側のリソースを操作して「プレゼンテーション層状態の変換」を実現します。
インターフェイス間で渡されるデータに最も一般的に使用される形式は JSON です。
インターフェイスのテストプロセス
- 要件を分析し、要件ドキュメント (製品) を生成します。
(インターフェース文書の開発と生成) インターフェース文書を解析します。 - インターフェイスのテスト ケースを生成します (レビューのために送信します)。
- テストケースを実行する
- ツール: postman、jmeter、fiddler
- コード: Python + リクエスト +UnitTest
- 欠陥を提出して追跡します。
- テストレポートを生成します。
- (オプション) インターフェース自動化継続的統合
インターフェースのドキュメント
インターフェイス情報を説明する開発者によって作成されたドキュメント。開発チームはインターフェース文書に従って開発作業を行い、常にインターフェース文書を維持し、遵守する必要があります。
機能:
フロントエンド開発者とバックエンド開発者がより適切に連携し、作業効率を向上させることができます。（統一された参照ファイルあり）
プロジェクトの繰り返しやプロジェクト担当者の変更時に、後の担当者が閲覧・保守するのに便利
テスターがインターフェーステストを行うのに便利
「ログイン」を例に挙げると：
リクエストメソッド：POST
URL: http://ihrm-test.itheima .net/api/sys/login
リクエストヘッダー: Content-Type: application/json
リクエスト本文: {"mobile":"13800000002", "password":"123456"}
レスポンスステータス コード: 200
エラー コード:
10000: 操作は成功しました。
20001: ユーザー名またはパスワードが間違っています。
99999: 申し訳ありませんが、システムがビジー状態です。後でもう一度お試しください。
インターフェースのユースケース設計
インターフェイスの使用例を設計する理由:
テスト ポイントの欠落を防ぎ、
作業の割り当てと作業負荷と時間を評価することを明確かつ簡単にするためです。
1. インターフェーステストのテストポイント
テストポイントはテストディメンションと呼ばれます
1.1 機能テスト
1.1.1 単一インターフェース機能
手動テストにおける単一のビジネス モジュールは通常、インターフェイスに対応します。
- ログインビジネス——>ログインインターフェース
- ショッピング カート ビジネスに追加—>ショッピング カート インターフェイスに追加
- 注文ビジネス——>注文インターフェース
- 決済ビジネス——>決済インターフェース
- ツールとコード付き。フロントエンドインターフェイスをバイパスし、インターフェイスに必要なデータを整理し、インターフェイスのテストを実行します。
1.1.2 ビジネスシナリオ機能
ユーザーの実際の利用シーンに合わせて、インターフェースのビジネスシナリオを整理します。
- ビジネス シナリオを整理する場合、通常はフォワード テスト (手動テストと同じ) のみを実行する必要があります。
- 一般に、ほとんどのビジネス シナリオをカバーするには、使用するユース ケースを最小限にすることをお勧めします。
- ログイン——商品を探す——ショッピングカートに入れる——注文する——支払い——評価する
1.2 性能試験
応答時間、
スループット
、同時実行数、
サーバー リソースの使用率
1.3 セキュリティテスト
攻撃セキュリティ - 専門のセキュリティ テスト エンジニアによって完了
ビジネス セキュリティ - テストの方向
性 機密データが暗号化されているかどうか
SQL インジェクション: ユーザーがデータを入力できる
SQL ステートメントを作成する SQL インジェクション セキュリティ、ユーザーが悪意を持って作成した SQL ステートメントはクエリ データベースを実行しない
2. デザイン手法と考え方
2.1 マニュアル設計との類似点
手動テストに対応する機能テスト ポイントは、インターフェイス テストに対応する機能と完全に一致しています。
例: tpshop モールのログイン ページ、手動機能テスト ケースの設計ポイント:
1) ページ レイアウトが要件を満たしているかどうか、
2) ユーザー名入力ボックスをテストして、入力されたデータが正しいかどうかを確認する、
3) パスワード入力ボックスをテストして確認する入力されたデータが正しいかどうか;
4) 検証コード入力ボックスをテストして、入力されたデータが正しいかどうかを確認します。
tpshop モール ログイン ページ、インターフェイス テスト ケースの設計ポイント:
1) ユーザー名入力ボックスに対応するユーザー名の値が正しいか
どうかをテストします。2) パスワード入力ボックスに対応するパスワードの値が正しいか
どうかをテストします。3)検証コード入力ボックスに対応する値 verify_code の値は正しいです。
2.1 マニュアル設計との違い
入力ボックスに書き込まれたデータが正しいかどうかを確認する手動テスト。
インターフェーステストは、パラメータに対応するパラメータ値が正しいかどうかをテストします。
インターフェイスのテストは、パラメーター値だけでなく、パラメーター自体に対しても実行されます。
- 前方パラメータ:
必須パラメータ: すべての必須 (必須) が含まれる
組み合わせパラメータ: すべての必須 + 1 つ以上の任意のパラメータ
すべてのパラメータ: すべての必須 + すべての任意のパラメータ - 逆パラメータ：
複数パラメータ： 必須パラメータが1つ以上追加されています（任意に指定可能）
パラメータが少ない： 必須パラメータが1つ以上欠落しています
パラメータなし： 必須パラメータがありません
エラーパラメータ： パラメータ名の入力が間違っています
3. 単一インターフェースのテストケース
手動テストケース文書の 8 つの主要要素:
番号、ユースケース名 (タイトル)、モジュール、優先順位、事前設定条件、テストデータ、操作手順、期待される結果
インターフェーステストケースドキュメント 10要素：
番号、ユースケース名（タイトル）、モジュール、優先度、事前設定条件、リクエストメソッド、URL、リクエストヘッダー、リクエストボディ（リクエストデータ）、期待結果
3.1 インターフェース文書の分析
ログイン インターフェイスを例に挙げます。
リクエストメソッド：投稿
URL：「システム情報」のプロトコルとドメイン名 + /api/sys/login
リクエストヘッダー：Content-Type：application/json
リクエストボディ：{"mobile": "13800000002", "password": "123456" "}
期待される結果: {"success":true,"code":10000,"message":"操作は成功しました!","data":"f5050a1b-7919-444c-9ec4-3c1a7286536d"} data: 値ログインが
成功した場合 生成されたトークン データ。このデータは定期的に変更されます。
| シリアルナンバー | ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|---|
| ログイン_001 | 無事着陸しました | ログイン | p1 | アカウントが登録されました | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800000002”,“パスワード”:“123456”} | ステータス コード: 200 {"success":true,"code":10000,"message":"操作成功!","data":"f5050a1b-7919-444c-9ec4-3c1a7286536d"} |
3.2 ログインモジュールのインターフェーステストケースのテストポイント
3.2.1 数値
- 前方
ログインに成功しました - 反転
ユーザー名が空です
ユーザー名に特殊文字が含まれています ユーザー
名が11桁（12桁）を超えています ユーザー名が
11桁（10桁）未満です
ユーザー名が登録されていません
パスワードが空です
。パスワードに特殊文字と文字が含まれています。
パスワードは 1 桁です。
パスワードは 100
桁です。パスワードが間違っています。
3.2.2 パラメータ
- 転送
必須パラメータ: 正しいユーザー名 + 正しいパスワード
組み合わせたパラメーター: 無視
すべてのパラメーター: 正しいユーザー名 + 正しいパスワード - 反転
複数のパラメータ: 複数の abc: "123"
少数のパラメータ (モバイル以外): ユーザー名なし、正しいパスワード パラメータなし
: パラメータなし 間違ったパラメータ
(携帯電話番号パラメータ名が間違っています): abc:1381234567、パスワード: "123456"
ユーザー名関連:
| シリアルナンバー | ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|---|
| ログイン_002 | ユーザー名が空です | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“”,“パスワード”:“123456”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_003 | ユーザー名に特殊文字が含まれています | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800&#abc”,“パスワード”:“123456”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_004 | ユーザー名が11桁を超えています（12桁） | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“138000000023”,“パスワード”:“123456”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_005 | ユーザー名が 11 桁未満 (10 桁) | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“1380000000”、“パスワード”:“123456”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_006 | ユーザー名が登録されていません | ログイン | p2 | データベースに存在しない携帯電話番号 | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“16700542479”、“パスワード”:“123456”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
パスワード関連:
| シリアルナンバー | ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|---|
| ログイン_007 | パスワードが空です | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800000002”,“パスワード”:“”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_008 | パスワードに特殊文字と文字が含まれています | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800000002”,“パスワード”:“123&%rt”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_009 | パスワード1桁 | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800000002”,“パスワード”:“1”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_010 | パスワード 100桁 | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {"mobile":"13800000002","password":"100 文字のパスワードを入力してください"} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
| ログイン_011 | 間違ったパスワード | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800000002”、“パスワード”:“888888”} | ステータス コード: 200 {"成功":false,"コード":20001,"メッセージ":"ユーザー名またはパスワードが正しくありません","データ":null} |
パラメータ関連:
| シリアルナンバー | ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|---|
| ログイン_012 | 必須パラメータ（すべてのパラメータ） | ログイン | p2 | / | 役職 | {プロトコル+ドメイン名}/api/sys/login | コンテンツタイプ:アプリケーション/json | {“モバイル”:“13800000002”,“パスワード”:“123456”} | 状态码：200 {“success”:true,“code”:10000,“message”:“操作成功！”,“data”:"f5050a1b-7919-444c-9ec4- 3c1a7286536d "} |
| login_013 | 多参 | 登录 | p2 | / | POST | {协议+域名}/api/sys/login | Content-Type:application/json | {“abc”:“123”,“mobile”:“13800000002”,“password”:“123456”} | 状态码：200 {“success”:true,“code”:10000,“message”:“操作成功！”,“data”:"f5050a1b-7919-444c-9ec4- 3c1a7286536d "} |
| login_014 | 少参（少mobile） | 登录 | p2 | / | POST | {协议+域名}/api/sys/login | Content-Type:application/json | {“password”:“123456”} | 状态码：200 {“success”:false,“code”:20001,“message”:“用户名或密码错误”,“data”:null} |
| login_015 | 无参 | 登录 | p2 | / | POST | {协议+域名}/api/sys/login | Content-Type:application/json | / | {“success”:false,“code”:99999,“message”:“抱歉，系统繁忙，请稍后重试！”,“data”:null} |
| login_016 | 错误参数（mobile参数名错误） | 登录 | p2 | / | POST | {协议+域名}/api/sys/login | Content-Type:application/json | {“abc”:“13800000002”,“password”:“123456”} | 状态码：200 {“success”:false,“code”:20001,“message”:“用户名或密码错误”,“data”:null} |
3.2.3 业务场景测试用例
用户怎么用，怎样设计业务。
用最少的测试用例，尽量覆盖最多的接口
- 分析测试点
针对 员工管理 业务场景：
登录 —— 添加员工 —— 查询员工 —— 修改员工 —— 再次查询 —— 删除员工 —— 查询员工列表 - 添加员工
请求方法：post
URL： {协议+域名}/api/sys/user
请求头：
Content-Type： application/json
Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
请求体（请求数据）：{“username”:“爱因斯坦”,“mobile”:“17289432100”,“timeOfEntry”:“2021-07-12”,“formOfEmployment”:1,“departmentName”:“测试0607”,“departmentId”:“1412421425733664768”,“workNumber”:“234”,“correctionTime”:“2021-07-30T16:00:00.000Z”}
预期结果：
状态码：200
{“success”:true,“code”:10000,“message”:“操作成功！”, “data”:{“id”:“113749504”}}
| 用例名称 | 模块 | 优先级 | 预置条件 | 请求方法 | URL | 请求头 | 请求体(请求数据） | 预期结果 |
|---|---|---|---|---|---|---|---|---|
| 添加员工 | 员工管理 | p0 | 登录成功 | POST | {协议+域名}/api/sys/user | Content-Type： application/json， Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d | {“username”:“爱因斯坦”,“mobile”:“17289432100”,“timeOfEntry”:“2021-07-12”,“formOfEmployment”:1,“departmentName”:“测试0607”,“departmentId”:“1412421425733664768”,“workNumber”:“234”,“correctionTime”:“2021-07-30T16:00:00.000Z”} | 状态码：200 {“success”:true,“code”:10000,“message”:“操作成功！”, “data”:{“id”:“113749504”}} |
- 查询员工
请求方法：GET
URL： {协议+域名}/api/sys/user/:target
请求头：
Content-Type： application/json
Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d （具体数据 来源 登录成功返回的 响应体中的 data的值）
请求体:
无
返回数据：
状态码：200
"code": 10000, "message": "操作成功！", "data": { 所查询的员工的详细信息} }
| 用例名称 | 模块 | 优先级 | 预置条件 | 请求方法 | URL | 请求头 | 请求体(请求数据） | 预期结果 |
|---|---|---|---|---|---|---|---|---|
| 查询员工 | 员工管理 | p1 | 登录成功 | GET | {协议+域名}/api/sys/user/:target | Content-Type： application/json， Authorization： Bearer f5050a1b-7919-444c-9ec4-3c1a7286536d | / | ステータス コード: 200 {"success": true, "code": 10000, "message": "操作は成功しました!", "data": {クエリされている従業員の詳細} } |
- 従業員を変更すると
、変更された従業員 ID (変更されるデータ) を表すデータ内の ID が返されます。
| ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|
| 従業員の変更 | 従業員管理 | p0 | ログイン成功 | 置く | {プロトコル+ドメイン名}/api/sys/user/:target | Content-Type： application/json、認可： Bearer xxx | {"ユーザー名":"ペッパピッグ"} | ステータス コード: 200 {"success":true,"code":10000,"message":"操作は成功しました!", "data":{"id":"xxx"}} |
- 従業員の削除
| ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|
| 従業員の削除 | 従業員管理 | p0 | ログイン成功 | 消去 | {プロトコル+ドメイン名} /api/sys/user/:target | Content-Type： application/json、認可： Bearer xxx | / | ステータス コード: 200 {"success":true,"code":10000,"message":"操作は成功しました!","data":null} |
- 従業員リストのクエリ
| ユースケース名 | モジュール | 優先度 | 前提条件 | リクエスト方法 | URL | リクエストヘッダー | リクエストボディ（リクエストデータ） | 期待される結果 |
|---|---|---|---|---|---|---|---|---|
| 従業員リストのクエリ | 従業員管理 | p0 | ログイン成功 | 得る | {プロトコル+ドメイン名} /api/sys/user?page=1&size=10 | Content-Type： application/json、認可： Bearer xxx | / | ステータス コード: 200 { “success”: true, “code”: 10000, “message”: “操作は成功しました!”, “data”: { “total”: xxxx, “rows” [ {},{}, … 10 人の従業員の詳細] } } |