🐦 👨‍🍳 🎮 プロジェクトは、燃え尽きるまで煙テストでカバーします。 🏠 🤖 🤱🏼

こんにちは、Habr！社内セミナーで、私のリーダー、つまりテスト部門の責任者が、「テストは不要」という言葉でスピーチを始めました。ホールでは、誰もが静かで、椅子から落ちようとする人もいました。彼は考えを続けました。テストなしでは、複雑で高価なプロジェクトを作成することはかなり可能です。そして、おそらく、それは動作します。しかし、製品が正常に機能することを知って、あなたがどれほど自信を感じるか想像してみてください。

Badooのリリースはかなり一般的です。たとえば、サーバー部分とデスクトップWebは1日に2回リリースされます。そのため、複雑で低速なテストが開発の障害になることを直接知っています。簡単なテストは幸福です。そこで、今日は、Badooがどのように煙テストを行っているかについてお話します。

煙検査とは

この用語は、オーブンを組み立て、すべてのプラグを閉じ、それをflood濫させ、煙が意図した場所からのみ来ることを見たストーブメーカーによって最初に使用されました。 ウィキペディア

元のアプリケーションでは、スモークテストは最も単純で明白なケースをテストするように設計されており、それなしでは他のタイプのテストは不当に冗長になります。

簡単な例を見てみましょう。アプリケーションのプリプロダクションはbryak.comにあります（実際のサイトとの偶然の一致はランダムです）。テスト用に新しいリリースを準備してアップロードしました。最初に確認する価値があるものは何ですか？アプリケーションがまだ開いていることを確認することから始めます。 Webサーバーが「200」で応答する場合、すべてが正常であり、機能のチェックを開始できます。

そのようなチェックを自動化する方法は？原則として、ブラウザを起動し、目的のページを開き、必要なとおりに表示されることを確認する機能テストを作成できます。ただし、このソリューションにはいくつかの欠点があります。まず、これは長いものです。ブラウザを起動するプロセスは、検証自体よりも時間がかかります。第二に、これには追加のインフラストラクチャの保守が必要です。このような簡単なテストのために、ブラウザを備えたサーバーをどこかに維持する必要があります。結論：問題を異なる方法で解決する必要があります。

初めての煙テスト

Badooでは、サーバー側はほとんどがPHPで記述されています。明らかな理由で、単体テストはそれに書かれています。したがって、すでにPHPUnitがあります。技術を不必要に生成しないために、PHPでも煙テストを作成することにしました。 PHPUnitに加えて、URLを操作するためのクライアントライブラリ（libcurl）と、それを操作するためのPHP拡張機能であるcURLが必要です。

実際、テストはサーバーに必要な要求を行い、答えを確認するだけです。すべてがgetCurlResponse（）メソッドといくつかのタイプのアサーションに関連付けられています。

メソッド自体は次のようになります。

public function getCurlResponse( $url, array $params = [ 'cookies' => [], 'post_data' => [], 'headers' => [], 'user_agent' => [], 'proxy' => [], ], $follow_location = true, $expected_response = '200 OK' ) { $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if (isset($params['cookies']) && $params['cookies']) { $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); } if (isset($params['headers']) && $params['headers']) { curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); } if (isset($params['post_data']) && $params['post_data']) { $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line); } if ($follow_location) { curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); } if (isset($params['proxy']) && $params['proxy']) { curl_setopt($ch, CURLOPT_PROXY, $params['proxy']); } if (isset($params['user_agent']) && $params['user_agent']) { $user_agent = $params['user_agent']; } else { $user_agent = USER_AGENT_DEFAULT; } curl_setopt($ch, CURLOPT_USERAGENT, $user_agent); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $response = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) { $this->assertTrue( (bool)$response, 'Empty response was received. Curl error: ' . curl_error($ch) . ', errno: ' . curl_errno($ch) ); $this->assertServerResponseCode($response, $expected_response); } curl_close($ch); return $response; }

メソッド自体は、指定されたURLでサーバー応答を返すことができます。入力は、Cookie、ヘッダー、ユーザーエージェント、およびリクエストの作成に必要なその他のデータなどのパラメーターを受け入れます。サーバーからの応答を受信すると、メソッドは応答コードが予期されたものと一致することを確認します。そうでない場合、これを報告するエラーでテストがクラッシュします。これは、転倒の原因を特定しやすくするためです。テストが何らかのアサートに該当し、ページに要素がないことを伝えると、エラーは、応答コードが予想される「200」ではなく「404」であるというメッセージよりも情報量が少なくなります。

要求が送信され、応答が受信されると、要求がログに記録されるため、将来、必要に応じて、テストがクラッシュまたは中断した場合に一連のイベントを簡単に再現できます。これについては以下で説明します。

最も簡単なテストは次のようになります。

 public function testStartPage() { $url = 'bryak.com'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent('<body>', $response, 'Error: test cannot find body element on the page.'); }

このようなテストは1秒未満で合格します。この間に、開始ページが「200」で応答し、その上にbody要素があることを確認しました。同じ成功を収めて、ページ上の要素をいくつでも確認できます。テストの期間はそれほど変わりません。

そのようなテストのプラス：

速度-テストは必要に応じて何度でも実行できます。たとえば、コードが変更されるたびに。
動作するために特別なソフトウェアとハードウェアを必要としないでください。
作成と保守が簡単です。
彼らは安定しています。

最後の段落について。つまり、プロジェクト自体と同じくらい安定しています。

最初の煙テストを書いてから3日が経過したと想像してください。もちろん、この間、テストで見つかったすべての不正ページをカバーしました。私たちは少し喜んで座りましたが、プロジェクトで最も重要なことはすべて認可されていることに気付きました。これをテストする機会を得る方法は？

許可されたページと許可されていないページの違いは何ですか？サーバーの観点から見ると、すべてが単純です。ユーザーを識別するための情報がリクエストに含まれている場合、許可されたページが返されます。

最も簡単なオプションは認証Cookieです。リクエストに追加すると、サーバーは「認識します」。このようなCookieは、存続期間が非常に長い場合、テストでハードコーディングできますが、認証ページにリクエストを送信することで自動的に受信できます。 2番目のオプションを詳しく見てみましょう。

私たちのサイトでは、認証ページは次のようになります。

ユーザーのユーザー名とパスワードを入力する必要があるフォームに興味があります。

任意のブラウザーでこのページを開き、インスペクターを開きます。ユーザーデータを入力し、フォームを送信します。

インスペクタにリクエストが表示されたので、テストでシミュレートする必要があります。明らかな（ログインとパスワード）に加えて、どのデータがサーバーに送信されるかを確認できます。プロジェクトごとに異なります。リモートトークン、以前に受信したCookieのデータ、ユーザーエージェントなどです。これらの各パラメーターは、承認要求を作成する前にテストで取得する必要があります。

任意のブラウザーの開発者ツールで、cURLとしてコピーを選択することにより、リクエストをコピーできます。このフォームでは、コマンドをコンソールに挿入して表示できます。そこで、パラメータを変更または追加してテストできます。

このようなリクエストに応じて、サーバーはCookieを返します。Cookieは承認済みのページをテストするために追加のリクエストに追加されます。

認証はかなり長いプロセスであるため、ユーザーごとに認証Cookieを一度だけ取得し、どこかに保存することを提案します。たとえば、このようなCookieは配列に格納されています。キーはユーザーのログインであり、値はそれらに関する情報です。次のユーザーのキーがまだない場合は、承認します。もしあれば、私たちはすぐに興味のあるリクエストをします。

承認されたページをチェックするテストコードの例は次のようになります。

 public function testAuthPage() { $url = 'bryak.com'; $cookies = $this->getAuthCookies('employee@bryak.com', '12345'); $response = $this->getCurlResponse($url, ['cookies' => $cookies]); $this->assertHTMLPresent('<body>', $response, 'Error: test cannot find body element on the page.'); }

ご覧のとおり、認証Cookieを受信し、それをさらにリクエストに追加するメソッドが追加されました。メソッド自体は非常に簡単に実装されます。

 public function getAuthCookies($email, $password) { // check if cookie already has been got If (array_key_exist($email, self::$known_cookies)) { return self::$known_cookies[$email]; } $url = self::DOMAIN_STAGING . '/auth_page_adds'; $post_data = ['email' => $email, 'password' => $password]; $response = $this->getCurlResponse($url, ['post_data' => $post_data]); $cookies = $this->parseCookiesFromResponse($response); // save cookie for further use self::$known_cookies[$email] = $cookies; return $cookies; }

メソッドは最初に、この電子メールに対して以前に受信した認証Cookieがあるかどうかを確認します（この場合、ログインまたはその他の可能性があります）。ある場合、彼はそれを返します。そうでない場合、彼は許可ページ（たとえば、bryak.com / auth_page_adds）に必要なパラメーター（電子メールとユーザーパスワード）を要求します。この要求への応答として、サーバーはヘッダーを送信しますが、その中には興味のあるCookieがあります。次のようになります。

 HTTP/1.1 200 OK Server: nginx Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: name=value; expires=Wed, 30-Nov-2016 10:06:24 GMT; Max-Age=-86400; path=/; domain=bryak.com

これらの単純な正規表現を使用して、これらのヘッダーから名前Cookieとその値（この例ではname = value）を取得する必要があります。答えを解析するメソッドがあります。次のようになります。

 $this->assertTrue( (bool)preg_match_all('/Set-Cookie: (([^=]+)=([^;]+);.*)\n/', $response, $mch1), 'Cannot get "cookies" from server response. Response: ' . $response );

Cookieを受信した後、許可するリクエストに安全に追加できます。

落下試験の分析

上記から、このようなテストはサーバー要求のセットであることがわかります。リクエストを作成し、回答を操作し、次のリクエストを作成します。頭の中に考えが忍び込んでいます。このようなテストが10回目のリクエストに該当する場合、その理由を理解するのは簡単ではないかもしれません。あなたの人生を簡素化するには？

まず、テストの微粒化を最大化することをお勧めします。 1つのテストで50の異なるケースをチェックしないでください。テストが単純であるほど、将来的にはテストが容易になります。

アーティファクトを収集することも役立ちます。テストがクラッシュすると、最後のサーバーレスポンスをHTMLファイルに保存し、アーティファクトストレージにスローします。このファイルは、テストの名前を指定することでブラウザーから開くことができます。

たとえば、私たちのテストは、ページ上でHTMLの一部を見つけることができないという事実に基づいています。

 <span class=”link”>Link<span>

コレクターに移動して、対応するページを開きます。

このページは、ブラウザの他のHTMLページと同じ方法で操作できます。 CSSロケーターを使用して、欠落している要素を見つけ、実際に存在しない場合は、変更されたか失われたかを判断できます。バグを見つけたかもしれません！要素が適切に配置されている場合、おそらくどこかでテストを間違えた可能性があります。この方向を注意深く見なければなりません。

ロギングは、生活を簡素化するのにも役立ちます。簡単に繰り返すことができるように、フォールンテストが行ったすべてのリクエストを記録しようとします。第一に、これにより、エラーを再現するために手で同様の一連のアクションをすばやく行うことができ、第二に、もしあれば頻繁に落ちるテストを識別することができます。

解析エラーの支援に加えて、上記のログは、テストした承認済みページと未承認ページのリストの作成に役立ちます。それを見れば、ギャップを簡単に探して埋めることができます。

最後になりましたが、私はアドバイスすることができます-テストは可能な限り便利でなければなりません。それらを実行するのが簡単であるほど、より頻繁に使用されます。秋の報告をより理解しやすく簡潔にすればするほど、彼らはより注意深く研究されます。アーキテクチャが単純であればあるほど、より多くのテストが作成され、新しいテストを作成する時間が短くなります。

テストを使用するのが不便であると思われる場合-ほとんどの場合、それはあなたには見えません。これはできるだけ早く対処する必要があります。そうしないと、ある時点でこれらのテストにあまり注意を払わなくなり始める危険性があり、これがすでに生産エラーのスキップにつながる可能性があります。

言葉で言えば、その考えは明白に思えます、私は同意します。しかし、実際には、私たちは皆、努力することがたくさんあります。そのため、作成を単純化および最適化し、バグなしで生き続けます。 :)

まとめ

現在、私たちは*ティムシチを開いています*ワウ、すでに605のテスト。すべてのテストは、並行して実行されない場合、4分以内に合格します。

この間、次のことを確信しています。

私たちのプロジェクトはすべての言語で開かれています（そのうち40以上が実稼働しています）。
主要国については、適切な支払方法のセットとともに正しい支払形態が表示されます。
基本的なAPIリクエストは正しく機能します
リダイレクトの着陸は正しく機能します（適切なユーザーエージェントを使用したモバイルサイトを含む）。
すべての内部プロジェクトが正しく表示されます。

これらすべてをSelenium WebDriverでテストするには、さらに多くの時間とリソースが必要になります。

もちろん、これはSeleniumに代わるものではありません。正しいクライアントの動作とクロスブラウザのケースを確認する必要があります。サーバーの動作を確認するテストのみを置き換えることができます。しかし、これに加えて、予備テストを迅速かつ簡単に実行できます。スモークテストの段階でエラーが発生し、「そこからスモークが発生しない」場合、修正前にヘビー級の長いセレンテストを実行することは可能ですか？これはあなたの裁量です！ :)

ご清聴ありがとうございました。

Vitaliy Kotov、QAオートメーションエンジニア。

プロジェクトは、燃え尽きるまで煙テストでカバーします。

煙検査とは

初めての煙テスト

ログイン

落下試験の分析

まとめ

More articles: