Yandexでのテスト。 SSH自体を介したWebサービス、またはサービス全体のスタブの作成方法

あなたは練習マジシャンマネージャーです。 または戦闘開発者。 またはプロのテスター。 または、クライアント/サーバーコンポーネントを含むシステムの開発と使用に無関心でない人だけかもしれません。 港は船が来る場所であるだけでなく、「ssh」は蛇が作る音だけではないこともご存知だと思います。 また、1つまたは複数のマシンにあるサービスが互いにアクティブに通信していることを認識しています。 ほとんどの場合、HTTPを介して。 また、バージョンごとに、この通信の形式を制御する必要があります。







次のリリースでは、それぞれが「正しいリクエストを正確に送信していますか？」または「必要なすべてのパラメーターをこのサービスに正確に送信していますか？」という質問をしていたと思います。 ネガティブなシナリオの存在とポジティブなシナリオの存在を誰もが認識すべきです。 この知識は、「What if ..？」シリーズから積極的に質問を提起する必要があります。 サービスが2時間の遅延で接続の処理を開始した場合はどうなりますか？ サービスがJSON形式のデータではなくabracadabraに応答した場合はどうなりますか？



そのようなことは、開発プロセスでしばしば忘れられます。 この種の問題をチェックすることは複雑であるため、このような状況の可能性は低く、その他の理由もあります。 しかし、重大な瞬間に奇妙なエラーやアプリケーションがクラッシュした場合、ユーザーは永遠に怖がってしまい、ユーザーは製品に戻らなくなります。 Yandexでは、こうした質問を常に念頭に置き、有用なアイデアを使用して、テストプロセスを可能な限り最適化するよう努めています。 このようなチェックを簡単、直感的、 自動化した方法については、この記事で説明します。

塩

モバイルアプリケーションからサーバーへ、ある部分から別の部分へ、サービスからサービスへとどのように、そして何が転送されるかを知るための多くの長い間知られている方法があります。

最も一般的で深刻な準備を必要としない最初の方法は、特別なプログラムをデータ送信または受信のソースの1つに接続することです。 このようなプログラムは、 トラフィックアナライザーまたはより頻繁にスニファーと呼ばれます 。

2番目は、パーティの1つを完全に人工的な実装に置き換えることです。 このアプローチでは、特定の場合の動作の明確なシナリオを決定し、このサービスに送られるすべての情報を保存することができます。 このアプローチは、スタブ（ モックオブジェクト ）を使用して呼び出されます 。 両方を見ていきます。

スニファーを使用する

サービス間通信に影響する変更の新しいリリースまたはデバッグが行われます。 必要なインターセプタープログラム（ WireSharkまたはTcpdump）を用意しています。 ホスト、ポート、インターフェースにフィルターを適用することにより、目的のノードへのトラフィックのインターセプトを開始します。 私たちは「暗いこと」を行い、必要なコミュニケーションを開始します。 傍受を停止します。 それを分解し始めます。 各サービスの解析プロセスには独自のプロセスがありますが、通常、大切なGET、POST、PUTなどのテキストのヒープ内でのけいれん的な検索を常に思い出させます。 見つけた？ その後、リリースごとにこれを繰り返します。 これは今回帰テストです！ 見つかりませんでしたか？ 理由を理解するまで、フィルターのさまざまな組み合わせでこれを繰り返します。

リリースからリリースまで？

これは手動で1回実行できます。 または2。 多分3。 そして、彼女はそれに飽きるでしょう。 そして、5回目のリリースでは、このコミュニケーションに時間がかかります。 通信が何らかの通知を伴うコールバック呼び出しである場合、間接的にこれに気付くのは特に困難です。 リリースごとに繰り返される、多くの時間と労力を要する機械的アクションは自動化する価値があります。 JAVAで行う方法 他の言語でも同様の方法でこれを行うことができると確信していますが、特に、Yandexテスト自動化用のJUnit4 + Mavenバンドルは正常に機能し、それ自体が実証済みです。



サービスを統合的にテストすると仮定します。つまり、別のマシンで起動すると戦闘モードのように見え、SSHを介してサービスに接続します。 ライブラリをSSHで動作さ せ、サーバーに接続し、 tcpdumpを実行して、ファイルにできることをすべて取り込みます（すべてが手に似ています）。 テストの後、プロセスを強制的に終了し、grep、awk、sedなどを使用して必要なものをファイルで探します。 次に、テストの結果のプロセス。 あなたはそれをしましたか？ いや？ 必要ありません！

なぜこれをしないのですか？

「不必要」は「不可能」を意味しないことに注意してください。

できます。 次の理由により、簡単な方法があります。

• 大きな文字列のコンポーネントへの解析は、常に多くの特定のコードであり、保守が困難です。
• HTTPメッセージの解析は、何百ものライブラリで長い間行われてきました。 なぜ最初に百をしますか？

私たちはまさにこの方法を試しました。 最初は便利に思えました-sshを介してtcpdumpを開始および停止し、出力で必要な部分文字列を見つけるだけでした。 最初のサポートの問題はほとんどすぐに始まりました。検索クエリでは、クエリパラメータの順序がランダムであることが判明しました。 参照行をいくつかに分割し、各エントリを確認する必要がありました。 リクエストが見つからなかった場合も、エラーメッセージは意気消沈していました。大量のテキストは、自分自身を構成する適切な方法を提供しませんでした。 非同期リクエストが頭痛に追加され、アクションの数分後に表示される可能性があります。 出力に必要な部分文字列を見越して、一定の遅延を伴うめまい構造を構築する必要がありました。 テストコードは、テストしたコードよりも複雑になることがありました。 次に、この部分をテストする別の方法を探し始めました。

Webサービスの代わりにスタブを使用する

テストについて話しているので、おそらくグリッドをスニファーの形にするだけでなく、サービス全体の1つを置き換える可能性がすべてあります。 このアプローチでは、「クリーンな」リクエストが人工サービスに到達し、メッセージのエンドポイントの動作を制御する機会があります。 そのような目的のために、素晴らしいWireMockライブラリがあります。 そのコードは、プロジェクトのGitHubページで表示できます 。 一番下の行は、Webサービスが適切なREST APIを提供するということです。これは、ほとんどすべての方法で構成できます。 これはJAVAライブラリですが、スタンドアロンアプリケーションとして実行する機能があり、jreを使用できます。 そして、詳細なドキュメントを含む簡単なセットアップ。



任意の応答コード、任意のコンテンツ、および応答を保存して自分で送信する機能を備えた実際のサービスへの透過的な要求リダイレクトがあります。 特に注意すべきことは、タイムアウト、通信の切断、無効な応答など、否定的な動作を再現する機会です。 美人！ ライブラリは、Jetty、TomcatなどにダウンロードできるWARとしても機能します。 そして、最も重要なことは、このライブラリはJUnitルールのようなテストで直接使用できることです！ 彼女自身が、ボディ、アドレス、パラメーター、ヘッダーを分割することにより、リクエストの解析を行います。 残っているのは、適切なタイミングで来て基準を満たすすべての人のリストを取得することです。

スタブを使用してチェックを自動化する

続行する前に、検討する2番目のオプション（モックオブジェクト）を使用して、簡単で視覚的な自動テストを提供するために必要な手順を決定する必要があります。

ステージのそれぞれが、それほど困難なく手動で行うことも可能であることは注目に値します。

スキーム

何をチェックしていますか？ スキーマ内の{}



：

_ -> {} -> _.







より正確には、回路は次のようになります。

_ -> _ :( ): {}.







したがって、いくつかのことを行う必要があります。

• サービススタブを上げて、特定のメッセージを受け入れるように強制し、OKで応答します（または、シナリオに応じてOKではありません）。 WireMockがこれを行います。
• サービススタブへのメッセージの配信を確認します（スキームで->
  
  
  
  ）。 この段階については別に説明します。
• 来たものを検証する。 2つのオプションがあります-検証にWireMockツールを使用するか、WireMockツールからリクエストのリストを取得し、それらにマッチャーを適用します。

人工的なWebサービスを上げる

サービスを手動で上げる方法については、wiremock Webサイトの「スタンドアロンの実行」セクションで詳しく説明されています。 JUnitでの使用方法も説明されています。 しかし、今後これが必要になるので、少しコードを示します。



テストの開始時に目的のポートでサービスを起動し、終了後に終了するJUnitルールを作成します。

 @Rule public WireMockRule wiremock = new WireMockRule(LOCAL_MOCKED_PORT);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストの開始は次のようになります。

 @Test public void shouldSend3Callbacks() throws Exception { //       stubFor(any(urlMatching(".*")).willReturn(aResponse() .withStatus(HttpStatus.OK_200).withBody("OK"))); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、本体「OK」でコード200で要求されたアドレスに応答するように、上げられたWebサービスを構成します。 構成するためのいくつかの簡単なステップの後、イベントを開発するためのいくつかのオプションがあります。 まず、クライアントからテストが実行されているマシンへのポートへのアクセスに問題はありません。 この場合、テストケース内で必要なアクションを実行するだけで、その後検証に進みます。 2番目-ssh経由でのみアクセスできます。 それでも、ポートはファイアウォールで覆われています。 ここでは、sshポートフォワーディング（またはssh-tunneling）が役立ちます。 これについては以下で説明します。

パッケージを短くする

REMOTE（-Rスイッチを使用）と、それに応じてマシンへのsshアクセスが必要です。 これにより、テストサービスがローカルポートにアクセスできるようになり、自分のポートを聞くことができます。 そして、すべてが機能します。

簡単に言えば、sshポート転送（またはssh-tunneling）は、リモートマシンのポートからローカルマシンのポートにssh接続を介してパイプすることです。 使用方法については、 www.debianadmin.comをご覧ください。

このプロセスを自動化しているため、テストでこのメカニズムを便利に使用する方法を詳細に検討します。 一番上のレベル-junitルールインターフェイスから始めましょう。 これにより、テストを開始する前に__: -> ssh -> ____:_



をスキップし、完了後にトンネルを閉じることができます。

ポート転送JUnitルールの作成

Ganymed SSH2ライブラリを思い出してください。 Mavenを使用して接続します。

 <!--https://code.google.com/p/ganymed-ssh-2/--> <dependency> <groupId>ch.ethz.ganymed</groupId> <artifactId>ganymed-ssh2</artifactId> <version>${last-ganymed-ssh-ver}</version> </dependency>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（リリースバージョンは、常にMaven Centralで確認できます。）



このライブラリを使用して、sshを介してトンネルを作成する例を開きます。 4つのパラメーターが必要であることを理解しています。 テストはローカルポートを介して「話す」ことを前提としているため、 __



を127.0.0.1



と同等と__



ます。

次の3つのパラメーターを指定する必要があります。

 @Rule public SshRemotePortForwardingRule forward = onRemoteHost(props().serviceURI()) .whenRemoteUsesPort(BIND_PORT_ON_REMOTE) .forwardToLocal().withForwardToPort(LOCAL_MOCKED_PORT);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.forwardToLocal()



は次のとおりです。

 public SshRemotePortForwardingRule forwardToLocal() { try { hostToForward = InetAddress.getLocalHost().getHostAddress(); } catch (UnknownHostException e) { throw new RuntimeException("Can't get localhost address", e); } return this; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JUnitルールをExternalResource



継承者として作成すると便利です。トンネルを許可して上げるbefore()



とトンネルと接続を閉じるafter()



再定義します。



接続自体は次のようになります。

 logger.info(format("Try to create port forwarding: `ssh %s -l %s -f -N -R %s:%s:%s:%s`", connection.getHostname(), SSH_LOGIN, hostOnRemote, portOnRemote, hostToForward, portToForward )); connection.requestRemotePortForwarding(hostOnRemote, portOnRemote, hostToForward, portToForward);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

検証する

くぐもったサービスでリクエストを正常にキャッチしたら、残っているのはそれらをチェックすることだけです。 最も簡単な方法は、組み込みのWireMockツールを使用することです。

 //     ,      verify(3, postRequestedFor(urlMatching(".*callback.*")) .withRequestBody(matching("^status=.*")));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より柔軟な方法は、必要なクエリのリストを取得し、特定のパラメーターを取得したら、それらにチェックを適用することです。

 List<LoggedRequest> all = findAll(allRequests()); assertThat("    1   ", all, hasSize(greaterThan(0))); assertThat("      ", all.get(0).getBodyAsString(), containsString("Wow, it's callback!"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Yandexでの仕組み

上記はすべて、深刻な一般的なアプローチです。 全体または一部の多くの場所で使用できます。 現在、統合レベルでのスタブの使用は、サービスのさまざまな機能を置き換える多くの大規模プロジェクトでうまく機能しています。 たとえば、Yandexには、ファイルに関する情報を独立してではなく別のサービスを通じて記録するファイルアップロードサービスがあります。 ファイルのダウンロードを開始しました-リクエストを送信しました。 ロードされ、カウントされたチェックサム-別の要求。 ファイルのウイルスをチェックし、ファイルの操作を続行する準備ができました-もう1つです。 次の各段階は、前の段階への回答に応じて継続しますが、サービス間の接続数は制限されます。



リクエストが本当になくなり、ファイルに関するすべての情報が正しい形式で含まれていることを確認するにはどうすればよいですか？ リクエストは受け入れられたが応答がなかった場合にどうなるかを確認するにはどうすればよいですか？ 最初に、イベントの発生というポジティブなシナリオを確認します。データベースに書き込むサービスを人工的なものに置き換え、トラフィックを受信して​​分析します。 （上記のコード例は、テストで行われることのコピーです。）スーパーユーザー権限を持たない自動テストが、ローカルマシン上の特定のポートにバインドできるように、sshを介したトンネルが必要でした。リクエストを送信するポイントは、継続的にローカルアドレスとポートです。



ポジティブなシナリオのテストに成功したので、ネガティブなもののチェックを追加することは難しくありませんでした。 WireMockの応答遅延時間をファイルダウンロードサービスの待機時間よりも大きい値に増やすだけで、リクエストを送信するためのいくつかの試行を開始することができました。

 //    ,      61  //(     1) stubFor(any(urlMatching(".*")).willReturn(aResponse() .withFixedDelay((int) SECONDS.toMillis(61)) .withStatus(HttpStatus.OK_200).withBody("")));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

120秒で確認し、60秒でサービスへの応答を待っている間に2つの要求が到着し、重要な瞬間にファイルダウンロードサービスがハングしないことを確認しました。

 waitFor(120, SECONDS); verify(2, postRequestedFor(urlMatching(".*service/callback.*")) .withRequestBody(matching("^status_xml.*")));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、開発者はこのようなイベントの開発を想定しており、この状況ではこの場所では、ダウンロードに関する情報は失われません。 同様に、いずれかのサービスでバグが見つかりました。 これは、サービスがすぐに応答されない場合、外部監視サービスによって強制的に閉じられるまで、接続が数時間開いたままになるという事実にありました。 これにより、短時間でネットワークに問題が発生した場合、接続制限が完全に使い果たされる可能性があり、他のクライアントは数時間待機する必要があります。 以前にこれを確認したのは良いことです

他に何を言う価値がある

このアプローチには多くの制限があります。

• マシンへのsshアクセスが必要です。
• このマシンでポート転送を有効にする必要があります。
• ポートを取得してスタブに置き換える必要がある場合は、サービスを停止する必要があります。 これは、ユーザーがパスワードなしでサービスを停止する権利を必要としていることを意味します。 これは、1024までの番号のポートにも適用されます。
• 一部の組織では、管理者の許可なしにポートを転送できません。

ローカルポート転送

リモートに加えて、 -L



スイッチを使用したLOCAL（ローカル）もあります。 これにより、ローカルマシンの一部のポートを参照する上記のミラーは、ファイアウォールの背後に隠されたリモートマシンの内部ポートに到達できます。 このアプローチは、sshを使用してテスト対象のサーバーに入り、curl、wgetを呼び出すテストの代替手段となります。

代替案

テストでは、WireMockに加えて、アナログが興味深い場合があります： github.com/jadler-mocking/jadlerまたはgithub.com/robfletcher/betamax