1つ目は、【インターフェーステストとは？インターフェイステストを行う理由]

インターフェイステストとインターフェイス自動化テストは、多くの人にとって常に混乱する概念でした。したがって、2 の概念を理解することが非常に重要です。
インターフェイス: 他のメソッド、サービス、またはアプリケーションで使用できる、ロジック処理機能を備えたプログラムコード。
インターフェースを呼び出す側にとって、インターフェースはブラックボックスとみなすことができ、ブラックボックス内のロジックを知ることなく、取り決めに従ってパラメータを渡し、返されたデータを受け取るだけで済みます。

1. インターフェースの役割

1. システム間の呼び出し。たとえば、UnionPay は、三者間の支払いを担当するアプリケーションによって呼び出される支払いインターフェイスを提供し、ユーザーが支払いリクエストを開始すると、アプリケーションは関連する必要なパラメータ値を支払いインターフェイスを通じて UnionPay サーバーに渡します。銀聯サーバーは処理完了後、アプリケーションのコールバックインターフェースを呼び出し、決済処理結果を返します。
2. フロントエンドアプリケーションがバックエンドサービスを呼び出します。たとえば、アプリケーションプログラムはサーバーのインターフェイスを呼び出し、サーバーは DAO [データアクセスオブジェクトデータアクセスオブジェクト] のインターフェイスを呼び出します。あるシステムの観点から見ると、アプリケーション自体は主に 2 つの部分で構成されます。1 つは対話部分、もう 1 つはデータ表示部分です。アプリケーションプログラムは、データアクセスオブジェクトのインターフェイスを通じてデータベースから対応するデータを取得し、サーバー側インターフェイスはデータをそれに応じて処理し、最終的にアプリケーションプログラムに返し、アプリケーションプログラムはそれを表示します。
3. サービス間の呼び出し。たとえば、登録済みユーザーは、まずユーザー情報を照会するサービスを呼び出し、登録されているかどうかを確認します。登録済みが返された場合、登録済みユーザーを担当するインターフェースは結果を前のページに返します。
インターフェイステストは、システムコンポーネント間のインターフェイスをテストするためのテストであり、主に外部システムと内部サブシステム間の相互作用ポイントを検出するために使用されます。テストの焦点は、データの相互作用、転送と制御の管理プロセス、およびシステム間の相互論理依存関係をチェックすることです。

2. インターフェーステストを行う理由

1. フロントエンドテストだけでは高いカバレッジを確保することは困難です。インターフェイステストでは、フロントエンドではシミュレートできない一部の入力パラメータを含む、さまざまな種類の入力パラメータをシミュレートでき、インターフェイスドキュメントの定義に従って比較的完全な入力パラメータ値を設計し、実装時の品質を保証することもできます。インターフェイス層の問題のほとんどは、アプリケーション自体の対話およびデータ表示の問題です。
2. インタラクティブなインターフェイステストや機能テストと比較して、インターフェイステストは自動化が容易で、実行がより安定し、メンテナンスコストが低くなります。
3. インターフェースの自動化は回帰テストなどに適しており、手動による回帰テストの人件費を削減できます。
4. フロントエンドシステムとバックエンドシステムが分離されているため、セキュリティの観点からフロントエンドのみに依存するだけではセキュリティ要件を満たせないため、フロントエンドを回避することは比較的容易であるため、バックエンドのセキュリティ要件を満たさなければなりません。入力検証も実行します。入力検証はインターフェイステストでのみ検証できます。

3. どのような種類のインターフェースがありますか?

インターフェースは一般に 2 つのタイプに分類されます。 1. プログラムの内部インターフェース 2. システムの外部インターフェース

システムの外部インターフェイス: たとえば、他の Web サイトやサーバーからリソースや情報を取得したい場合、他の人はデータベースをあなたと共有することは絶対にありません。彼らは、データを取得するために作成したメソッドを提供することしかできません。インターフェイスは、データ共有の目的を達成するために、彼が書いたメソッドを使用できます。

プログラム内のインターフェース: メソッド間、モジュールとモジュール間の対話、bbs システムなどのプログラム内でスローされるインターフェース、ログインモジュール、投稿モジュールなどがあり、必要な場合は最初にログインする必要があります。 post, then this 2 つのモジュールは対話する必要があり、内部システムが呼び出すためのインターフェイスをスローします。

2. 【インターフェース試験の分類】

インターフェースの分類:

1. Webサービスインターフェース

2. http APIインターフェース

webService インターフェイスは、soap プロトコルを介して http 経由で送信されます。リクエストメッセージと返信メッセージは両方とも XML 形式であり、テスト時に呼び出しテストを実行するために渡すツールのみを使用します。

webService は、soup、rmi、rpc などのプロトコルを使用します

http API インターフェイスは、http プロトコルを使用してパスを介した呼び出しを区別します。リクエストメッセージはキーと値の形式であり、返されるメッセージは通常 JSON 文字列です。get や post などのメソッドがあり、これらも最も一般的に使用されます2つのリクエスト方法。

JSON は、すべての言語で認識されるユニバーサルデータ型です。(jsonの本質は文字列です。他の言語とは何の関係もありません。少し処理した後にのみ他の言語のデータ型に変換できます。例えば、Pythonでは辞書に変換できますが、 Key-Valueの形式はJavaScriptではネイティブに変換できます（オブジェクト、Javaではクラスオブジェクトに変換可能など）

http インターフェイスと Web サービスインターフェイスの違い:

Httpservice は、post と get を通じて必要なものを取得します。Webservice
は、soap プロトコルを使用して必要なものを取得します。httpservice と比較して、より複雑なデータ型を処理できます。

http プロトコルは文字列を送信しますが、Web サービスはより複雑なオブジェクトにパッケージ化されます。

3、[http、Webサービス、Dubboインターフェースプロトコルを理解する]

1. インターフェース

API: アプリケーションプログラミングインターフェイス、アプリケーションプログラミングインターフェイス

1) インターフェースの分類

ハードウェアインターフェイス: 接続機能と適応。2 つのハードウェアデバイス間の接続方法 (たとえば、マウスとコンピュータは USB インターフェイスを介して接続されます)

ソフトウェアインターフェイス: ソフトウェアプログラム間のデータ対話用のチャネル (ユーザーインターフェイスはソフトウェアインターフェイスです)

2) ソフトウェアインターフェースの分類

プログラム内部インターフェイス: クライアントとサーバー間のインターフェイスであり、クライアントとサーバー間のデータ転送を実現するために使用されます。

外部インターフェイス: サードパーティを介したログイン、サードパーティの支払い、外部インターフェイスの呼び出しによる現在のシステムへの復帰など

3) 共通インターフェースプロトコル

webService インターフェイス: http 経由で送信するにはスーププロトコルを使用します。リクエストメッセージとリターンメッセージは両方とも XML 形式であり、一般的に使用されるテストツールはSoupUIです。

http プロトコルインターフェイス: 現在最も広く使用されており、HTTP プロトコルを使用してデータを送信します。一般的なリクエストメソッドには get、post などが含まれます。一般的に使用されるテストツールには postman、jmeter などがあります。

Dubbo、websocket、ws://...、ftp://、およびその他のプロトコル。

4) インターフェーステスト

本質は、特定のプロトコルに基づいてサーバーにリクエストを送信し、サーバーが応答を返し、応答データを分析して期待される戻り値と一致しているかどうかを判断し、関数が正しいかどうかを検証することです。。

2、HTTPプロトコルの解釈

1) http プロトコル: ハイパーテキスト転送プロトコル

2) https: 簡単に言えば、http の下に SSL 層を追加した http の安全なバージョンです (SSL のメインユーザー Web 用の安全な伝送プロトコル)

3) http のデフォルトのポート番号は 80 です。デフォルトのポートは URL で省略できます。

https のデフォルトのポート番号は 443 です。デフォルトのポートは URL で省略できます。

4) HTTPリクエスト処理

クライアント: PC側アプリケーションブラウザAPPアプレット

HTTP通信：クライアントからサーバーに送信されるリクエスト情報

　　　　　サーバーからクライアントに返される応答情報

クライアント: フロントエンド --> アクティブなリクエスト。対応するリクエストを開始できるクライアント。

サーバー: バックエンド --> 受動的受け入れ。

拡張子のURL:

5) HTTPリクエスト情報

请求行： 请求方法/请求网址/协议版本
请求头部：header
host
connection
upgrade-insecure-requests
user-agent：用户代理，通过客户端代理
referer
accept-encoding
cookie
备注：域名和IP地址之间是映射关系，域名是为了好记

データのリクエスト:

6) HTTPレスポンス情報

ステータス行: ステータス コード
メッセージ ヘッダー: 
  content-type: 返されるデータ形式
    test/html 
    application/json 
    application/xml

応答本文:

7) HTTP レスポンスのステータスコード

状态码           含义                 客户端client                                 服务器端server 
1xx      | Informational 信息     啥都不用做，知道就好                          信息收到了，后续会处理                               
2xx      | Successful 成功        啥都不用做，知道就好                          请求已正确处理                                               
3xx      | Redirection 重定向     重新请求返回的新地址                          client需要的内容，由于一些原因，比如地址已发生变化了，然后返回该内容的新地址 
4xx      | 客户端的错误            确保用正确的参数和信息正确，重新请求             请求已正确处理                               
5xx      | 服务器端的错误           都无需操作，服务器端改了bug后，重新发送请求      服务器端的代码的bug导致了出错

8) HTTPリクエストメソッド

取得と投稿の違い:

a) さまざまなアプリケーションシナリオ

　　取得するリソースを取得する

　　Post データの送信、新しいデータの作成/既存のデータの変更

b) パラメータの保存

　　get リクエストのパラメータはブラウザの URL に表示でき、クエリ文字列は ?param=value [つまりクエリ文字列メソッド] を介して渡されます。

　　post ではクエリ文字列を使用できますが、通常は使用できません。通常はリクエスト本文にクエリ文字列を含めます。

c) セキュリティ

getもpostもどちらが安全かというとそうではありません。パケットキャプチャでデータが確認できます。インターネットでは投稿の方が体内にデータが置かれ、目に見えないため安全だと言われていますが、実際はそうではありません。安全ではなく、get リクエストは URL 内で肉眼で直接確認できます

注: 暗号化はリクエストメソッドとは関係がなく、すべてを暗号化できます。

【Webサービスプロトコル】

http と Webservice は両方とも TCP/IP プロトコルに基づくアプリケーション層プロトコルです

Web サービスは、データを送信するための http ベースの SOAP プロトコル webservice=soap=http+xml に基づいています。Web サービスプロトコルは http+xml で構成されます。wsdl は xml で使用され、wsdl は記述言語 xml の形式です。

ソケットは、TCP/IP プロトコルをカプセル化した TCP/IP に基づく伝送プロトコルです。

ソケットと TCP は両方とも TCP/IP トランスポート層プロトコルに基づいています

注: Restful はインターフェイス仕様であり、インターフェイスプロトコルではありません。http プロトコルも RESTful インターフェイス仕様で使用されます。

現在、それらのほとんどは Web サービスプロトコルの代わりに http プロトコルを使用しているため、実際の操作はなく、理論を理解するために再現されているだけです。

1. WSDL Webサービスの作成:

1. [Webサービスプロジェクト]を作成します。

画像.png

WebServices Framework は JAX-WS を選択する必要があります。

画像.png

2. 簡単なテストケースを作成します。

パッケージcom.webservice;

パブリッククラス WebService{

public String printData(String printerName){
    String strRet = "Welcome to use WebService, " + printerName;
    
    System.out.println("Print from WebService:" + strRet);
    
    return strRet;
}

3. Web サービスの公開:
ツールバーの [新しい Web サービス] をクリックします。

画像.png

戦略では 2 番目の戦略 (Java クラスから Web サービスを作成) を選択します。

画像.png

[プロジェクトに WSDL を生成する] にチェックを入れます。

画像.png

[完了]をクリックすると、WEB-INF/wsdl に 2 つのファイルが生成されます。

image.png
 
WebServiceService.wsdl：这个文件是用来描述Web Service内容的
<?xml version="1.0" encoding="UTF-8"?>
 
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://webservice.com/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="WebServiceService" targetNamespace="http://webservice.com/">
<types>
<xsd:schema>
<xsd:import namespace="http://webservice.com/" schemaLocation="WebServiceService_schema1.xsd"/>
</xsd:schema>
</types>
<message name="printData">
<part element="tns:printData" name="parameters"/>
</message>
<message name="printDataResponse">
<part element="tns:printDataResponse" name="parameters"/>
</message>
<portType name="WebServiceDelegate">
<operation name="printData">
<input message="tns:printData"/>
<output message="tns:printDataResponse"/>
</operation>
</portType>
<binding name="WebServicePortBinding" type="tns:WebServiceDelegate">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="printData">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="WebServiceService">
<port binding="tns:WebServicePortBinding" name="WebServicePort">
<soap:address location="http://localhost:8080/WebService/WebServicePort"/>
</port>
</service>
</definitions>
 
WebServiceService_schema1.xsd：用来说明Web Service的命令及其参数
比如：sample里面的WebService是【printData】,有一个String类型的参数【arg0】，返回值一个String类型的值。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://webservice.com/" targetNamespace="http://webservice.com/" version="1.0">
 
<xs:element name="printData" type="tns:printData"/>
 
<xs:element name="printDataResponse" type="tns:printDataResponse"/>
 
<xs:complexType name="printData">
<xs:sequence>
<xs:element minOccurs="0" name="arg0" type="xs:string"/>
</xs:sequence>
</xs:complexType>
 
<xs:complexType name="printDataResponse">
<xs:sequence>
<xs:element minOccurs="0" name="return" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

WebService プロジェクトを Tomcat にデプロイするだけです。
(展開方法は省略します)

2. WSDL WebService の呼び出し:
方法 1: 呼び出す Web サービスクライアントの作成:
1. [Java プロジェクト] の作成:

画像.png

2. ツールバーの「新しい Web サービスクライアント」をクリックします。

画像.png

3. [WSDL URL]を選択します。

画像.png

4. [次へ]をクリックして作成が完了すると、src/com/webservice配下に関連ファイルが自動生成されます。(WebServiceTest.java以外は自分で作成した呼び出しファイルです)

画像.png

5.【WebServiceTest.java】を作成します

画像.png

コードは次のとおりです
。

パブリッククラス WebServiceTest{

public static void main(String[] args){
    WebServiceService wssPrintData = new WebServiceService();
    WebServiceDelegate wsdPrintData = wssPrintData.getWebServicePort();
    
    System.out.println(wsdPrintData.printData("sun"));
}

}

6.【WebServiceTest.java】右クリック→「実行」→「Javaアプリケーション」
出力結果：
WebServiceの利用へようこそ、sun

方法 2: HttpClient を使用して呼び出す:

package com.httpclientforwsdl;
 
import java.io.ByteArrayInputStream;
import java.io.InputStream;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
 
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.InputStreamRequestEntity;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.RequestEntity;
 
public class WebServiceHttpClientTest{

public synchronized static String accessService(String wsdl,String ns,String method,Map<String,String> params,String result)throws Exception{  
    //拼接参数  
    String param = getParam(params);  
    String soapResponseData = "";  
    //拼接SOAP  
    StringBuffer soapRequestData = new StringBuffer("");  
    soapRequestData.append("<soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">");  
    soapRequestData.append("<soap:Body>");  
    soapRequestData.append("<ns1:"+method+" xmlns:ns1=\""+ns+"\">");  
    soapRequestData.append(param);  
    soapRequestData.append("</ns1:"+method+">");  
    soapRequestData.append("</soap:Body>" + "</soap:Envelope>");  
    PostMethod postMethod = new PostMethod(wsdl);  
    // 然后把Soap请求数据添加到PostMethod中  
    byte[] b=null;  
    InputStream is=null;  
    try {  
        b = soapRequestData.toString().getBytes("utf-8");   
        is = new ByteArrayInputStream(b, 0, b.length);  
        RequestEntity re = new InputStreamRequestEntity(is, b.length,"text/xml; charset=UTF-8");  
        postMethod.setRequestEntity(re);  
        HttpClient httpClient = new HttpClient();  
        int status = httpClient.executeMethod(postMethod);  
        System.out.println("status:"+status);  
        if(status==200){  
            soapResponseData = getMesage(postMethod.getResponseBodyAsString(),result);  
        }  
    } catch (Exception e) {  
        e.printStackTrace();  
    } finally{  
        if(is!=null){  
            is.close();  
        }  
    }  
    return soapResponseData;  
}  
  
public static String getParam(Map<String,String> params){  
    String param = "";  
    if(params!=null){  
        Iterator<String> it  = params.keySet().iterator();  
        while(it.hasNext()){  
            String str = it.next();  
            param+="<"+str+">";  
            param+=params.get(str);  
            param+="</"+str+">";  
        }  
    }  
    return param;  
}  
  
public static String getMesage(String soapAttachment,String result){  
    System.out.println("message:"+soapAttachment);  
    if(result==null){  
        return null;  
    }  
    if(soapAttachment!=null && soapAttachment.length()>0){  
        int begin = soapAttachment.indexOf(result);  
        begin = soapAttachment.indexOf(">", begin);  
        int end = soapAttachment.indexOf("</"+result+">");  
        String str = soapAttachment.substring(begin+1, end);  
        str = str.replaceAll("<", "<");  
        str = str.replaceAll(">", ">");  
        return str;  
    }else{  
        return "";  
    }  
}  
  
/** 
 * @param args 
 */  
public static void main(String[] args) {   
    try {  
        Map<String,String> param = new HashMap<String,String>();  
        param.put("arg0", "sun");
        String wsdl="http://localhost:8080/WebService/WebServicePort?wsdl";  
        String ns = "http://webservice.com/";  
        String method="printData";  
        String response =accessService(wsdl,ns,method,param,"return");  
        System.out.println("main:"+response);  
          
    } catch (Exception e) {  
        e.printStackTrace();  
    }  
}

結果を示す：

status:200
七月 15, 2016 3:43:27 下午 org.apache.commons.httpclient.HttpMethodBase getResponseBody
警告: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
message:<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:printDataResponse xmlns:ns2="http://webservice.com/"><return>Welcome to use WebService, sun</return></ns2:printDataResponse></S:Body></S:Envelope>
main:Welcome to use WebService, sun

【ダボインターフェース試験方法】

1. Telnet に直接接続し、dubbo プロトコルを使用してメソッドを呼び出します。

(1) プロジェクトの設定ファイルで確認できます

dubbo.protocol.port=10022

これは、dubbo によって公開されているポートが 10022 であることを示しており、このポートには Telnet で直接アクセスできます。

telnet lcoalhost 10022 で確認できます

接続が成功したことを示します。

ls でサービスを表示する

サービス ls -l のメソッドを確認します。

次に、invoke を使用してインターフェイスをテストします。ここで、pom は fastjson 依存関係を追加する必要があることに注意してください。追加しないと、無効な json 引数が報告されます。原因: com/alibaba/fastjson/JSON dubbo

2.アイデアプラグインダボInvoke

アイデアプラグインスーパーマーケットで、dubbo invokeがinvokeを統合していることを発見しました。

プラグインDubboInvokeをダウンロードしてインストールします

外部に公開されるメソッドにアノテーションを追加する

/**
 *
 * @param name 姓名
 *             example=haha
 * @return
 */
String sayHello(String name);

電話をかける場合は、このインターフェイスが表示される場所をクリックしてください

プラグインの使用を選択します。ここで、serverAddress が dubbo のサービス IP ポートであることに注意してください。

次に、「invoke」をクリックして生成テストの結果を確認します。

4、[HTTPプロトコルの詳細]

Httpプロトコルの詳しい説明

考える：

ユーザーはブラウザを開いてURLを入力し、サーバーにデータを送信しますが、データはどのように送信すればよいのでしょうか?

Web サイトごとに独自のルールがあると、インターネット全体が混乱してユーザーのアクセスが不便になり、Web サイトごとに独自のクライアントソフトウェアを開発する必要があり、運営コストが増加します。

したがって、データを送信または受信するための基盤を全員が持つための統一されたルールが必要であり、HTTP プロトコルはこれに由来します。

1. HTTP プロトコルの概要

ＨＴＴＰプロトコルとは、ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ（ハイパーテキスト転送プロトコル）の略で、ワールドワイドウェブ（ＷＷＷ：ＷｏｒｌｄＷｉｄｅＷｅｂ）サーバとローカルブラウザとの間でハイパーテキストを伝送するための伝送プロトコルである。

HTTP はアプリケーション層に属するオブジェクト指向プロトコルであり、そのシンプルかつ高速な方式により分散ハイパーメディア情報システムに適しています。1990 年に提案され、数年間の使用と開発を経て、継続的に改良と拡張が行われてきました。HTTP プロトコルはクライアント/サーバーアーキテクチャで動作します。ブラウザは HTTP クライアントとして、URL を介してすべてのリクエストを HTTP サーバー、つまり WEB サーバーに送信します。Webサーバーは受信したリクエストに応じて応答情報をクライアントに送信します。

画像-20200924172049937

HTTP プロトコルを使用すると、新しいリクエストが送信されるたびに、対応する新しい応答が生成されます。プロトコル自体は、以前のすべての要求または応答メッセージに関する情報を保持するわけではありません。これは、大量のトランザクションをより速く処理し、プロトコルのスケーラビリティを確保するためであり、HTTP プロトコルは意図的にシンプルになるように設計されています。しかし、Web の継続的な発展に伴い、無国籍によるビジネスプロセスはますます困難になっています。たとえば、ユーザーがショッピング Web サイトにログインした場合、サイトの他のページにジャンプした後でも、ログインを継続できる必要があります。この例では、誰がリクエストを送信したかを把握できるようにするために、Web サイトはユーザーの状態を保存する必要があります。HTTP/1.1 はステートレスプロトコルですが、目的の状態保持機能を実現するために Cookie テクノロジーが導入されています。Cookie を使用し、HTTP プロトコルを使用して通信することで、状態を管理できます。Cookieについては後ほど詳しく説明します。

2.HTTPプロトコルとは何ですか

ハイパーテキスト転送プロトコル。ブラウザとサーバー間のデータ通信の形式を指定します。
ブラウザを HTTP クライアントとして使用し、URL を通じてすべてのリクエストを HTTP サーバー、つまり WEB サーバーに送信します。
サーバーがこのプロトコルに準拠していない場合は、ユーザーが Web アプリケーションをダウンロードし、Web アプリケーション経由でアクセスできるようにするクライアントを自分で開発する必要があります。そうしないと、ユーザーはブラウザ経由で Web アプリケーションにアクセスできません。

2、HTTP プロトコルの 4 つの主要な特徴

1. TCP/IPプロトコルに基づくアプリケーション層プロトコル

2. 要求応答モデルに基づく

HTTP プロトコルでは、リクエストがクライアントから送信され、最後にサーバーがクライアントのリクエストに応答して戻り値を返すことが規定されています。

つまり、ユーザーは最初にデータにアクセスしてクライアントからの通信を確立し、サーバーはリクエストを受信するまでデータを送信したりクライアントに応答したりしません。

画像-20200924172118199

3. 状態保存なし: ユーザー情報の状態を保存しません。

HTTP は状態を保存しないステートレスプロトコルです。HTTP プロトコル自体は、リクエストとレスポンスの間の通信状態を保存しません。つまり、HTTP レベルでは、プロトコルは送信されたリクエストや応答を保持しません。

要約: 私はあなたを何千回も見てきましたが、いつも初恋の人のように扱います。

画像-20200924172149501

HTTP プロトコルを使用すると、新しいリクエストが送信されるたびに、対応する新しい応答が生成されます。プロトコル自体は、以前のすべての要求または応答メッセージに関する情報を保持するわけではありません。

効果：

大量のトランザクションをより速く処理し、プロトコルのスケーラビリティを確保するために、HTTP プロトコルは意図的にシンプルに設計されています。

質問：

Webの継続的な発展に伴い、無国籍化により業務処理が困難になっている
たとえば、ユーザーがショッピング Web サイトにログインした場合、サイトの他のページにジャンプした後でも、ログインを継続できる必要があります。この例では、誰がリクエストを送信したかを把握できるようにするために、Web サイトはユーザーの状態を保存する必要があります。どのように達成するか

解決する：

HTTP/1.1 はステートレスプロトコルですが、目的の状態保持機能を実現するためにCookie テクノロジーが導入されています。
Cookie を使用し、HTTP プロトコルを使用して通信することで、状態を管理できます。

4. 接続がありません (短い)

コネクションレスの意味は、各接続が 1 つのリクエストのみを処理するように制限することです。サーバーがクライアントの要求の処理を完了し、クライアントの応答を受信すると、接続が切断されます。つまり、クライアントがリクエストを要求するとサーバーは応答し、その後は関係がありません。

効果: この方法により、送信時間を節約できます。

解決：

その後、WebSocket を使用して長時間接続を実現できます。これにより、双方が接続を確立し、デフォルトで切断されなくなります (これが QQ および WeChat チャットで使用されるものです)。

3. HTTPリクエストプロトコルとレスポンスプロトコル

HTTP プロトコルはクライアントとサーバー間の通信形式を指定するため、http プロトコルには、ブラウザーがサーバーにデータを送信するために従う必要があるリクエストプロトコルと、サーバーがブラウザーにデータを送信するときに従う必要があるリクエストプロトコルが含まれます。。

HTTP プロトコルはメッセージ形式をどのように指定しますか?

まずはソケットサーバーを渡しましょう

単純なソケットサーバー:

import socket
 
server = socket.socket()  # 默认就是基于网络的TCP协议
server.bind(("127.0.0.1", 8888))
server.listen(5)
while True:
    conn, addr = server.accept()
    data = conn.recv(1024)
    print(data)  # 将请求数据的打印出来
    conn.send(b"ok")
    conn.close()

次に、ソケットサーバーを実行して確認し、ブラウザの URL に「」と入力すると127.0.0.1:8888、ソケットサーバーは次のデータを受信します。

b'GET / HTTP/1.1\r\n              ## 请求首行
Host: 127.0.0.1:8080\r\n          ## 请求头 (下面都是,一大堆的K:V键值对)
Connection: keep-alive\r\n
Cache-Control: max-age=0\r\n
Upgrade-Insecure-Requests: 1\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.25 Safari/537.36 Core/1.70.3823.400 QQBrowser/10.7.4307.400\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8\r\n
Accept-Encoding: gzip, deflate, br\r\n
Accept-Language: zh-CN,zh;q=0.9\r\n
Cookie: csrftoken=WCzjKvmjOSdJbYKs0uIfPtiFfLl04FENb6p9CjypP7ZObcUpydaQPLZN0qPOVqwj\r\n
\r\n'     ## 换行
b''       ## 请求体

HTTP プロトコルの対話に使用されるメッセージは、HTTP メッセージと呼ばれます。要求側（クライアント）のＨＴＴＰメッセージはリクエストメッセージとして使用され、応答側（サーバ）のＨＴＴＰメッセージは応答メッセージとして使用される。
HTTP メッセージ自体は複数行のデータで構成されるワードテキストです。

画像-20200924172222493

次に、CSDN に再度アクセスして、ブラウザが受信した対応するデータを確認してみましょう。Web ページを右クリックして確認します ----> ネットワーク ----> 現在の Web ページの URL をクリック ----> ヘッダー---- >応答ヘッダーを表示

画像-20210315192622788

1. リクエストプロトコル

1.1 リクエストフォーマット

画像-20200924172250257

HTTP GETメソッドのリクエスト形式

フォーマット仕様:

// 请求首行 : 请求方法, 协议版本...
// 请求头 : 一大堆的 k:v 键值对
// 空行 \r\n : 用来标识作用
// 请求体 : 并不是所有的请求方法都有, 只要用来携带敏感性数据(get没有,post有)

リクエスト方法:
1. 「get」リクエスト: サーバーからデータをリクエストします (例: URL を入力して、対応するコンテンツを取得します)
2. 「post」リクエスト: データをサーバーに送信します (例: ログインし、ユーザー名とパスワードを入力し、検証のためにサーバーに送信します)

取得と投稿の違い

1. 都可以携带额外的参数 : 
    // GET 提交的数据会放在URL之后，以"?"分割URL和传输数据，参数之间以"&"相连
    // POST方法是把提交的数据放在HTTP包的请求体(Body)中.
2. 提交的数据大小限制 : 
    // 浏览器对URL长度有限制, 所以GET提交的数据大小有限制
    // POST方法没有数据大小限制
3. 数据的安全性 : 
    // GET方式提交数据, 会带来安全问题, 比如一个登录页面, 通过GET方式提交数据时, 用户名和密码将出现在URL上
    // 如果页面可以被缓存或者其他人可以访问这台机器, 就可以从历史记录获得该用户的账号和密码

2.HTTPレスポンス

サーバーがクライアントから HTTP リクエストを受信した後、HTTP リクエスト内のアクション要件に従って、サーバーは特定のアクションを実行し、結果 (HTTP レスポンスと呼ばれます) をクライアントに返します。

2.1 リクエストフォーマット

画像-20200924172428894

フォーマットの説明

// 响应首行 : 响应状态码, 协议版本....
// 响应头 : 一大堆 k:v 键值对
// 空行 \r\n : 用来标识作用
// 响应体 : 响应正文, 展示给用户的数据

HTTP 応答は、ステータス行、応答ヘッダー、応答本文の 3 つの部分で構成されます。
ステータス行: プロトコルのバージョンバージョン、ステータスコードステータスコード、応答フレーズを含む。
応答ヘッダー (サーバーヘッダー): サーバーを構築するソフトウェア、応答の送信時間、応答データの形式、および HTTP ステータスコード (HTTP ステータスコード) を含むその他の情報が含まれます。
レスポンスボディ：レスポンスの具体的なデータです。

応答ステータスコードの説明:

HTTP ステータスコードは 3 つの 10 進数で構成され、最初の 10 進数はステータスコードの種類を定義し、最後の 2 つの数字は分類機能を持ちます。ステータスコードが異なれば、意味も異なります。

画像-20200924172516228

// 用简单的数字来表示一串中文意思(状态或者描述性信息)
1XX : 1开头的,服务端已经接受到你的数据正在处理，你可以继续提交
2XX : 200 OK>>> : 请求成功
3XX : 重定向(当你在访问一个需要登陆之后才能看的页面你会发现会自动跳转到登陆页面)
4XX : 403当前请求不符合条件(没有权限), 404请求资源不存在
5XX : 服务器内部错误,无法完成请求

ps：上記の応答コードに加えて、同社は独自のステータスコードもカスタマイズする予定です

4. URL ユニフォームリソースロケーター

ユニフォームリソースロケータは、インターネットから取得できるリソースの場所とアクセス方法を簡潔に表現したもので、インターネット上の標準リソースのアドレスです。インターネット上のすべてのファイルには固有の URL があり、その URL には、ファイルの場所とブラウザがファイルに対して何を行うべきかを示す情報が含まれています。

フォーマット：

プロトコル: //IP:port(80)/path?name=lqz&age=18

? 前のものはリクエストパスです。その後はリクエストデータ部分です

形状： scheme:[//[user:password@]host[:port]][/]path[?query-string][#anchor]

注: ボックスはオプションです

スキーム : プロトコル (例: http、https、ftp)
user:password@ユーザーのログイン名とパスワード
host : サーバーのIPアドレスまたはドメイン名
port : サーバーのポート (プロトコルのデフォルトのポートである場合は、http 80 または https 443)
path : リソースにアクセスするためのパス
query-string: パラメータ。通常はキーと値のペアを使用して http サーバーに送信されるデータを作成します。
アンカー : アンカー (Web ページの指定されたアンカー位置にジャンプします)

インターフェイスのテスト計画を作成する

インターフェイステスト計画と機能テスト計画の目的は同じであり、どちらも要件を決定し、テスト環境とテスト方法を決定し、テストカラムの設計を準備し、インターフェイステストの進行計画を最初に策定することです。一般に、インターフェイステスト計画には、概要、テストリソース、テスト機能とキーポイント、テスト戦略、テストリスク、およびテスト標準が含まれます。

インターフェースのテストケースを作成してレビューする

機能テストと同様に、インターフェーステストを開始する前に、ボール要件文書やインターフェース文書などのプロジェクト関連文書に従ってインターフェーステストケースを作成し、レビューする必要があります。インターフェースのアイデアは図に示されています。

インターフェーステストの実行

書かれたインターフェイステストケースに従って、テストツール (Postman、JMeter、SoapUI など) を使用してインターフェイステストを実装し、見つかった問題を報告します。

インターフェース自動化の継続的統合の重要なポイント

プロジェクトのテスト中に、インターフェイスが追加、削除、または変更され、それに応じてテストケースが更新されるため、継続的統合のためのテストケースを維持し、プロジェクトインターフェイスの動作を監視するツール (GitHub など) が必要です。自動テストを通じてリアルタイムでテストします。インターフェイステストでは、継続的インテグレーションが中心的な内容であり、自動化によってのみ低コストと高歩留まりを実現できます。インターフェイス自動化テストの継続的統合には、主に次の内容が含まれます。
(1) プロセスの観点: 回帰フェーズでは、インターフェイス例外シナリオの対象範囲が強化され、徐々にシステムテストおよびスモークテストのフェーズに拡張され、最終的には完全なプロセスの自動化。
(2) 結果表示: より豊富な結果表示、傾向分析、品質統計と分析など。
(3) 問題の場所: エラー情報とログがより正確になり、問題の再現と場所の特定が容易になります。
(4) 結果検証：データベース情報検証などの自動検証機能を強化します。
(5) コードカバレッジ: コードカバレッジを向上させるために、現在のブラックボックスからホワイトボックスへのドロップを常に試みます。
(6) パフォーマンス要件: パフォーマンステストシステムを改善し、自動化された手段を通じてインターフェイスのパフォーマンスインジケーターが正常であるかどうかを監視します。

-----------------------

インターフェースのテストプロセスとユースケースの設計

インターフェイステストは、プロジェクトのテストプロセス全体の中で非常に重要な部分です。テストの対象はインターフェイスであるため、非常に早い段階でテストに介入し、コードロジックを完全に検証し、プログラムの問題を早期に発見することができ、より効率的です。 UI テスト: 極端で珍しいケースの検証も簡単になります。

インターフェイスのテストプロセス:

機能テストプロセスと同様に、完全なインターフェイステストプロセスは次のとおりです。

インターフェース文書と要件文書を分析する
インターフェイスのテスト計画を作成する
インターフェースのテストケースを書く
インターフェーステストの実行
インターフェーステストレポートを出力します。

一般的なインターフェイスのユースケース設計は、開発によって提供されるインターフェイスドキュメントと製品要件ドキュメントに基づいて行われます。まず、インターフェイスドキュメントをよく理解します。

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

インターフェイスドキュメントで特定のインターフェイス情報を記述する方法の例は次のとおりです。

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

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

インターフェースの説明
リクエストメソッド
リクエストURL
リクエストパラメータ
データを返す
インスタンスを返す

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

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

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

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

インターフェイスのユースケース設計ポイントの基本原則は次のとおりです。

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

ユースケースの範囲をどのように判断するか?

テストケースのカバレッジを迅速に評価する方法: 1) パラメーターの検証が完了しているかどうか (さまざまな境界やビジネスルールを含む) 2) ビジネス要件ポイントのカバレッジが完全かどうか (単一のインターフェイスビジネス機能、インターフェイスビジネス機能に依存) 3) インターフェイス例外シナリオのカバレッジは完了していますか (異常データ)

一般的なインターフェイスの使用例には、次の部分が含まれている必要があります。

ユースケース番号、モジュール名、インターフェース名、ユースケースタイトル、リクエストメソッド、リクエストURL、リクエストパラメータ（リクエストヘッダ、リクエストボディを含む）、期待される結果、実績など

全てが必要なわけではなく、実際の使用量の増減に応じて、実際のユースケーステンプレートは以下のようになります。

インターフェースのテストケース

------------

1. インターフェースのユースケーステンプレート

テストケースに関しては、テストステップと期待される結果という 2 つの最も重要な要素があることがわかっています。実は、インターフェースのテストでも同様で、インターフェースのテストの段階で最も重要なことは、あらかじめ設定されたリクエストをインターフェースに送信することを実現することであり、その結果は応答情報とその後の処理に重点を置く必要があります。したがって、インターフェースのテストケースのレイアウトは次の 2 つの形式が考えられます。実際の作業シナリオでは、インターフェイス間の連結および混合シナリオもテストする場合があることに注意してください。

2. テストレポートテンプレート

インターフェイステストレポートは、インターフェイスパフォーマンステストレポートと組み合わされることがよくありますが、個別にレポートする場合は、次の点を考慮してください。

テスト対象システムの導入、プロジェクトの開始計画など、テストプロジェクトに関連する背景情報を簡単に説明します。システムインターフェースの定義と設計について紹介します。たとえば、システムにはインターフェイスがいくつありますか? どのプロトコルを使用するか? どのような配送方法がありますか? リクエスト形式は何ですか? どのような返品基準を使用すればよいですか? テーブルの説明が利用可能です。このインターフェーステストの目的、範囲および目的の説明は、このインターフェーステストの「インターフェーステスト実施計画」の対応する内容と一致している必要があります。

テストの目的は、システムのインターフェース機能とロジック処理が検証され、「インターフェース定義マニュアル」の定義と要件に準拠し、システムのニーズを満たしていることを確認することです。テスト対象は主に、単一シナリオのインターフェイス機能テストと混合シナリオのインターフェイス機能テストに分かれます。この時点から、「プロジェクトインターフェイステストケース」から x-mind ダイアグラムを投稿することを検討できます。

その中で、テスト指標の範囲は主に、テスト対象インターフェイスの受信リクエストと返されたメッセージ、テスト対象インターフェイスの返されたステータス、テスト対象インターフェイスの対応するビジネスロジック処理、データ降下を伴う処理、およびシリアル複雑なシナリオにおける複数のインターフェイスの相互作用。Postman は Google のインターフェーステストプラグインであり、使いやすく、ユースケース管理、取得、投稿、ファイルアップロード、応答検証、変数管理、環境パラメータ管理などをサポートします。機能を備え、バッチで実行でき、ユースケースのエクスポートとインポートをサポートします。

テストリソース

テストレコードは、単一シナリオインターフェイステストとテスト結果データに分割できます。次に、テストで見つかった問題を組み合わせて、テスト結果全体を分析し、判断します。これらの問題には、インターフェイスビジネス機能エラーの欠陥、インターフェイス例外処理の欠陥、インターフェイス処理データの沈殿の欠陥、およびインターフェイスのセキュリティの欠陥が含まれます。

混合シーンインターフェース試験には、試験結果データと、この混合シーンインターフェース試験の試験結果データとが含まれる。

全体的なテスト結果を分析し、テストで見つかった問題に基づいて判断した後、パフォーマンステストの一般的な結論を導き出すことができます。一般に、テスト結果とテスト対象との比較がテストの結論として使用されます。

------

1 プロジェクトアドレス

https://gitee.com/HUJIAFANGFUJIDDD/vue_api_server.git

2展開

#cd /usr/local

#git clone https://gitee.com/HUJIAFANGFUJIDDD/vue_api_server.git (git がインストールされていない場合は、まず yum install git -y)

3 npmとnode環境をインストールする

wget https://npm.taobao.org/mirrors/node/v14.15.3/node-v14.15.3-linux-x64.tar.xz
 
xz -d node-v14.15.3-linux-x64.tar.xz
 
tar -xvf node-v14.15.3-linux-x64.tar
 
cd node-v14.15.3-linux-x64
 
# 建立软连接，变为全局
 
ln -s /usr/local/nodejs/node-v14.15.3-linux-x64/bin/npm /usr/local/bin/
 
ln -s /usr/local/nodejs/node-v14.15.3-linux-x64/bin/node /usr/local/bin/
 
vim /etc/profile
 
# 以下两个路径为加入nodejs路径
 
export NODE_HOME=/usr/local/nodejs/node-v14.15.3-linux-x64
 
export PATH=$NODE_HOME/bin:$PATH
 
# 配置生效
 
source /etc/profile
 
# 成功
 
node -v

4 vue_api_server プロジェクトディレクトリに移動し、npm install を実行して依存関係パッケージをインストールします。

5 Mysql をインストールします。既にお持ちの場合は、この手順を無視してください。

6 db ディレクトリに入り、mydb.sql を MySQL データベースにインポートします。

mysql>CREATE DATABASE `api_db_mysql` デフォルト文字セット utf8 COLLATE utf8_general_ci;

mysql>api_db_mysql を使用します。

mysql>ソース /usr/local/vue_api_server/db/mydb.sql

7 vue_api_server ディレクトリの下の config ディレクトリに入り、default.json ファイルを開きます。

変更内容は次のとおりです。

{
        "config_name" : "develop",

        "jwt_config" : {
                "secretKey":"itcast",

                "expiresIn":86400

        },

        "upload_config":{
                "baseURL":"http://192.168.234.133:8888",

                "upload_ueditor":"uploads/ueditor",

                "simple_upload_redirect":"http://192.168.234.133/reload"

        },

        "db_config" : {
                "protocol" : "mysql",

                "host" : "127.0.0.1",

                "database" : "api_db_mysql",

                "user" : "root",

                "password" : "Xsy@210721",

                "port" : 3306

        }

}

8 vue_api_server ディレクトリで、次のコマンドを実行します。

#node app.js

これらのログが返されると、デプロイが成功したことがわかります。

9 VUE_API_Server の使用

以前のサービス環境のデプロイメントが完了すると、サービスポート 8888 がデフォルトで監視され、インターフェイスの参照アドレスは http://192.168.234.133:8888/api/private/v1/ になり、データの戻り形式は一律に JSON を使用します。

ログインインターフェース:

ロールインターフェイスを取得します (Type=Bearer Token が承認に追加されており、トークン値は上記のログインインターフェイスによって返されたトークン値であることに注意してください)

知らせ：

ユーザーの作成やユーザーのクエリなどのビジネスインターフェイスの場合、ログイン認証 API からトークンを取得する必要があり、そのトークントークンを Authorization フィールドを使用してリクエストヘッダーに指定する必要があります。

プロジェクトには多くのインターフェイスがあり、ノード app.js を実行するとすべてのインターフェイスが出力されます。

【インターフェーステストツールの詳細説明】

インターフェーステストツール

　　インターフェイステストツールを次の図に示します。

1.バイオリン弾き

まず、これはHTTPプロトコルデバッグプロキシツールですが、平たく言えばhttpパケットをキャプチャするツールです。Web テストとモバイルテストの両方でこのツールを使用できます。http プロトコルであるため、このツールはインターフェイスのテストもサポートできます。後の記事で、ツール fiddler について具体的に紹介します。

2. PostMan
Postman は、非常に人気のある API デバッグツールです。実際、開発者はさらに多くのことを使用しています。テスターには、Jmeter、soapUI などのインターフェイステストの選択肢が増えるためです。ただし、開発プロセス中にインターフェイスをデバッグするには、Postman は確かにシンプルかつ便利で、強力です。これはGoogleのツールです

エンジニアが開発したChromeブラウザにインストールできるプラグインです。さまざまなインターフェイステストリクエストをサポートし、テストスイートを管理し、実行を自動化できます。弱点は、自動アサーション機能が強力ではないことです。jenkins およびコード管理ライブラリを使用した継続的な統合テストは不可能です。ただし、半手動、半自動のテストとしては優れていることは間違いありません。

テストツール。私は通常、自動化されたインターフェイステストケースを作成し、補助的なテストとデバッグのために postman を開きます。このツールもこの記事の後半で紹介します。

これは、TCP、UDP、HTTP などのさまざまなパケットのキャプチャをサポートするコンピュータ上のパケットキャプチャツールです。基礎となるネットワークデータテストを行う場合は、通常、それを使用する必要があります。インターフェイスのテストとしては、このソフトウェアは少し不親切です。データの更新が速すぎるため、各操作に対応するインターフェイスを見つけるのが困難です。したがって、あまり深くは触れません

このツールの紹介です。

4. SoupUI
SoapUI は、soap/http を介して Web サービスの機能/負荷/準拠テストをチェック、呼び出し、実装するオープンソースのテストツールです。このツールは個別のテストソフトウェアとして使用でき、プラグインを使用して Eclipse、maven2.X、Netbeans、intellij に統合することもできます。

SoapUI は、無料のオープンソースのクロスプラットフォーム機能テストソリューションです。使いやすいグラフィカルインターフェイスとエンタープライズレベルの機能を備えた SoapUI を使用すると、自動化された機能テスト、回帰テスト、コンプライアンステスト、負荷テストを簡単かつ迅速に作成して実行できます。テスト環境では、SoapUI は完全なテストカバレッジを提供し、すべてのテストをサポートします。

標準のプロトコルとテクノロジーがあります。

SoapUI は Java に基づいて開発され、複数のプラットフォームをサポートし、インストールが非常に簡単です。

これは、オープンソースの無料およびエンタープライズ版の有料ソフトウェアです。外部インターフェイスのテストでよく使用されます。このツールは、インターフェイス自動化テストとインターフェイスパフォーマンステストをサポートでき、また、jenkins との継続的統合テストもサポートできます。コミュニティの無料バージョンをダウンロードしてデモを試すことができます。

5. インターフェイステスト用の Java コードコード
は万能であり、メモを取るツールもそのコードから開発されます。インターフェイス自動テストにコードを使用する理由は何ですか? 一部のツールでは機能が制限されているため、多くの企業では特定の機能が必要ですが、ツールがそれらをサポートしていないため、コードを使用して開発する必要があります。通常、自動テストには Java を使用し、主に httpclient.jar を使用します。

このパッケージでは、junit や testng などの単体テストツールを使用してテストケースを開発し、継続的統合テスト用のジョブを jenkins 上に作成します。

6. インターフェイステスト用の Python コードは
Java と同じです。Python での非常に優れた強力なサードパーティライブラリリクエストを使用すると、インターフェイス自動化のユースケースを簡単に作成できます。Python の単体テストフレームワークは通常、unittest を使用します。テストレポートを生成するには、通常、HTMLTestRunner.py を選択します。同様に、継続的統合テストは jenkins を使用して実行できます。

7. LoadRunner は
、LR がパフォーマンステストのみを行うことができ、LoadRunner はインターフェイスの自動化やインターフェイスのストレステストも行うことができると考えるべきではありません。ただ、私たちの多くはインターフェイステストケースを開発するために LR 関数を使用する方法を知りません。

8. JMeter
JMeter は、loadrunner と同様にパフォーマンステストで有名で、一般にインターフェイスのパフォーマンステストに使用されます。たとえば、java+Jmeter+ant+jenkins はインターフェイスのパフォーマンス監視テストを実行します。

上記では、基本的にインターフェイス機能テスト、インターフェイス自動化テスト、インターフェイスパフォーマンステストをカバーする非常に多くのツールを紹介しました。

5. [Cookie、セッション、トークンの認証原理と実戦についての深い理解]------

Cookie はクライアントに保存される小さなテキストで、ユーザーの ID を識別するために使用できます。Cookie は、ブラウザーが次回同じサーバーに別のリクエストを行うときに保持されてサーバーに送信されます。

アドバンテージ：

Cookie を使用すると、サーバーは比較的低コストでユーザーセッションを識別できます。
Cookie は、Cookie を設定したドメイン名にのみ送信されるため、Cookie の相対的なセキュリティが確保されます。
Cookie は厳密な同一オリジンポリシーに従っていないため、親ドメインの Cookie を取得するようにサブドメインを設定することができ、この機能はシングルサインオンの実装に非常に役立ちます。
Cookie の有効期限を設定して、Cookie が有効期間内に使用されるようにすることができます。

欠点:

Cookie のサイズは 4K しかないため、大量のコンテンツを保持できません。
Cookie はクライアントに保存されるため安全性が十分ではなく、誰かが Cookie を乗っ取った場合、サーバーはセッション状態を使用しているのがユーザー本人なのかハッカーなのかを区別できません。
js による cookie の読み取りを禁止する設定がサーバー側にない場合、js はこのドメイン名で cookie を作成、変更、削除できるため、xss 攻撃を防ぐために、cookie を HttpOnly に設定する必要があります。
ブラウザが Cookie を無効にするように設定されている場合、サーバーは Cookie に基づいてユーザーセッションを追跡できません

疑似コード:

    @GetMapping("put")
    public void test2(HttpServletRequest request, HttpServletResponse response){
        // Cookie 为键值对数据格式
        Cookie cookie_username = new Cookie("cookie_username", "admin");
        // 即：过期时间，单位是：秒（s）
        cookie_username.setMaxAge(30 * 24 * 60 * 60);
        // 表示当前项目下都携带这个cookie
        cookie_username.setPath(request.getContextPath());
        // 使用 HttpServletResponse 对象向客户端发送 Cookie
        response.addCookie(cookie_username);
    }
 
    @GetMapping("del")
    public void test4(HttpServletRequest request, HttpServletResponse response){
        // 根据 key 将 value 置空
        Cookie cookie_username = new Cookie("cookie_username", "");
        // 设置持久时间为0
        cookie_username.setMaxAge(0);
        // 设置共享路径
        cookie_username.setPath(request.getContextPath());
        // 向客户端发送 Cookie
        response.addCookie(cookie_username);
    }

put リクエストを実行すると、クライアントで次のことが確認できます。

del リクエストを実行すると、クライアント側ではそのリクエストを確認できなくなります。

セッション
session は、サーバーに保存され、Cookie に基づいてユーザーセッションを識別するために使用されるもう 1 つのメカニズムです。ユーザーがリクエストを開始すると、サーバーはリクエストのセッションを作成し、関連する属性を設定できます。その後、サーバーはセッション ID を Cookie に入れてブラウザに返します。ブラウザは今後も常にこの Cookie を要求し、サーバーは sessionid を通じて対応するセッションを取得し、それがどのユーザーのセッションであるかを知ることができます。

回路図:

アドバンテージ：

ユーザー情報をサーバーに保存し、セキュリティを強化
ユーザーが Cookie を無効にしても、URL の後に結合することでセッション ID を渡すことができます。
有効期限を設定でき、セッションをより長く持続させるための更新メカニズムがあります。
セッションを使用すると、ページ間でパラメータを簡単に受け渡すことができます

欠点:

サーバーのストレージ負荷が増加し、セッションがメモリに配置されると、ユーザー数が多い場合にはメモリへの負担も大きくなります。
分散サーバーだとセッション情報がうまく同期できない

疑似コード:

    @GetMapping("put")
    public void test4( HttpSession session){
        session.setAttribute("session_username","admin");
    }
 
    @GetMapping("del")
    public void test5(HttpSession session){
        session.removeAttribute("session_username");
    }
 
    @GetMapping("get")
    public void test6( HttpSession session){
        System.out.println(session.getAttribute("session_username"));
    }
 
//    常用方法
//    public Object getAttribute(String name)
//    返回session对象中与指定名称绑定的对象，如果不存在则返回null
//
//    public Enumeration getAttributeNames()
//    返回session对象中所有的对象名称
//
//    public long getCreationTime()
//    返回session对象被创建的时间， 以毫秒为单位，从1970年1月1号凌晨开始算起
//
//    public String getId()
//    返回session对象的ID
//
//    public long getLastAccessedTime()
//    返回客户端最后访问的时间，以毫秒为单位，从1970年1月1号凌晨开始算起
//
//    public int getMaxInactiveInterval()
//    返回最大时间间隔，以秒为单位，servlet 容器将会在这段时间内保持会话打开
//
//    public void invalidate()
//    将session无效化，解绑任何与该session绑定的对象
//
//    public boolean isNew()
//    返回是否为一个新的客户端，或者客户端是否拒绝加入session
//
//    public void removeAttribute(String name)
//    移除session中指定名称的对象
//
//    public void setAttribute(String name, Object value)
//    使用指定的名称和值来产生一个对象并绑定到session中
//
//    public void setMaxInactiveInterval(int interval)
//    用来指定时间，以秒为单位，servlet容器将会在这段时间内保持会话有

put リクエストが実行されると、クライアントではそれを確認できなくなります。

getリクエストを実行します。これはサーバー側で確認できます。

del リクエストを実行してから get リクエストを実行します。これはサーバー上では認識されません。

分散セッションの問題については、「分散セッション共有の問題」を参照してください。

トークン

トークンとは、多くの人が翻訳してそのまま「トークン」と呼ぶ認証方式で、拡張性とセキュリティが高く、Web アプリケーションやモバイル開発アプリケーションでの使用に非常に適しています。

トークンにはさまざまな種類があり、一般的に使用される jwt (正式名は Json Web Token) は、ステートレスで分散された Web アプリケーション認可を実現できる JSON スタイルの軽量認可および ID 認証仕様です。

違い：

通常のトークン: サーバーはクライアントから送信されたトークン情報を検証し、データをクエリする必要があります。
jwt トークン: jwt トークン自体にユーザー情報が保存され、jwt トークンから直接解析できます。

最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それはそれほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。

これらの資料は、 [ソフトウェアテスト] の友人にとって最も包括的で完全な準備倉庫である必要があります。この倉庫は、最も困難な旅を通じて何万人もの。お役に立てれば幸いです。テストエンジニアに

1つ目は、【インターフェーステストとは？インターフェイステストを行う理由]

1. インターフェースの役割

2. インターフェーステストを行う理由

3. どのような種類のインターフェースがありますか?

2. 【インターフェース試験の分類】

インターフェースの分類:

http インターフェイスと Web サービス インターフェイスの違い:

3、[http、Webサービス、Dubboインターフェースプロトコルを理解する]

1. インターフェース

1) インターフェースの分類

2) ソフトウェアインターフェースの分類

3) 共通インターフェースプロトコル

4) インターフェーステスト

2、HTTPプロトコルの解釈

1) http プロトコル: ハイパーテキスト転送プロトコル

2) https: 簡単に言えば、http の下に SSL 層を追加した http の安全なバージョンです (SSL のメイン ユーザー Web 用の安全な伝送プロトコル)

3) http のデフォルトのポート番号は 80 です。デフォルトのポートは URL で省略できます。

4) HTTPリクエスト処理

5) HTTPリクエスト情報

6) HTTPレスポンス情報

7) HTTP レスポンスのステータスコード

8) HTTPリクエストメソッド

【Webサービスプロトコル】

1. WSDL Webサービスの作成:

1. [Webサービスプロジェクト]を作成します。

2. 簡単なテスト ケースを作成します。

3. Web サービスの公開:ツールバーの [新しい Web サービス] をクリックします。

2. WSDL WebService の呼び出し:方法 1: 呼び出す Web サービス クライアントの作成: 1. [Java プロジェクト] の作成:

2. ツールバーの「新しい Web サービス クライアント」をクリックします。

3. [WSDL URL]を選択します。

4. [次へ]をクリックして作成が完了すると、src/com/webservice配下に関連ファイルが自動生成されます。(WebServiceTest.java以外は自分で作成した呼び出しファイルです)

5.【WebServiceTest.java】を作成します

6.【WebServiceTest.java】右クリック→「実行」→「Javaアプリケーション」出力結果：WebServiceの利用へようこそ、sun

【ダボインターフェース試験方法】

1. Telnet に直接接続し、dubbo プロトコルを使用してメソッドを呼び出します。

(1) プロジェクトの設定ファイルで確認できます

ls でサービスを表示する

サービス ls -l のメソッドを確認します。

次に、invoke を使用してインターフェイスをテストします。ここで、pom は fastjson 依存関係を追加する必要があることに注意してください。追加しないと、無効な json 引数が報告されます。原因: com/alibaba/fastjson/JSON dubbo

2.アイデアプラグインダボInvoke

プラグインDubboInvokeをダウンロードしてインストールします

外部に公開されるメソッドにアノテーションを追加する

電話をかける場合は、このインターフェイスが表示される場所をクリックしてください

4、[HTTPプロトコルの詳細]

Httpプロトコルの詳しい説明

1. HTTP プロトコルの概要

2.HTTPプロトコルとは何ですか

2、HTTP プロトコルの 4 つの主要な特徴

1. TCP/IPプロトコルに基づくアプリケーション層プロトコル

2. 要求応答モデルに基づく

3. 状態保存なし: ユーザー情報の状態を保存しません。

4. 接続がありません (短い)

3. HTTPリクエストプロトコルとレスポンスプロトコル

1. リクエストプロトコル

2.HTTPレスポンス

4. URL ユニフォーム リソース ロケーター

インターフェイスのテスト計画を作成する

インターフェースのテストケースを作成してレビューする

インターフェーステストの実行

インターフェース自動化の継続的統合の重要なポイント

インターフェイスのテストプロセス:

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

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

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

ユースケースの範囲をどのように判断するか?

一般的なインターフェイスの使用例には、次の部分が含まれている必要があります。

インターフェーステストツール

5. [Cookie、セッション、トークンの認証原理と実戦についての深い理解]------

クッキー

put リクエストを実行すると、クライアントで次のことが確認できます。

疑似コード:

おすすめ

http インターフェイスと Web サービスインターフェイスの違い:

2) https: 簡単に言えば、http の下に SSL 層を追加した http の安全なバージョンです (SSL のメインユーザー Web 用の安全な伝送プロトコル)

2. 簡単なテストケースを作成します。

3. Web サービスの公開:
ツールバーの [新しい Web サービス] をクリックします。

2. WSDL WebService の呼び出し:
方法 1: 呼び出す Web サービスクライアントの作成:
1. [Java プロジェクト] の作成:

2. ツールバーの「新しい Web サービスクライアント」をクリックします。

6.【WebServiceTest.java】右クリック→「実行」→「Javaアプリケーション」
出力結果：
WebServiceの利用へようこそ、sun

4. URL ユニフォームリソースロケーター