テスターとして、すべてが正常に動作しているときは大好きですが、人生は汚いハックに満ちています。 私はSeleniumをPythonに結び付けて自動化するのが好きですが、リソースが限られているという問題に直面したとき、「すべて同じで、より高速に」できるツールを急いでいます。 この投稿では、JMeterは負荷テストと機能テストの両方に最適なツールであることを説明します。
私の仕事は、モバイルアプリケーションのAPIをテストすることでした。 彼女の特徴は次のとおりです。
- タイミングがかつてないほど引き締められます。
- すべてのメソッドの仕様がありますが、文字通りその場で変更されます。
- プロジェクトは混乱しています。 山で死んだり病気になった場合、新しい人をプロジェクトに紹介するのは非常に費用がかかり、困難になります。
- JenkinsをCIシステムとして使用します。 テストは、めったに使用されず、生で、過度に複雑なプラグインなしで簡単に立ち上がるはずです。
- 必須のストレステスト。ただし、その時間はほとんどありません。
- このAPIのモバイルアプリケーション自体は、他の都市とはまったく異なるチームによって作成されています。 テストする唯一の方法は、クエリへの応答を見ることです。
Pythonに手をつなぐ習慣がありましたが、頭の中で何かが変わりました。 「親愛なる友人」、私は自分に言った、「もしあなたがPythonで書くチームの唯一の人なら、誰があなたが書いたものを理解し、あなたが不在でも仕事を続けるだろうか？」
別のツールを明示的に探す必要がありました。 そして、私は愛するJMeterをまったく別の視点から見ました。JMeterはもちろん、外部からは多くのことを望んでいますが、小さなスクリプトではなく、理解できるテスト構造を持っています。 そのため、どのマシンからでも自分の代わりにランダムテストを実行するように同僚に依頼できます。 プログラマーでさえ、これは「手で実行する」よりもはるかに便利であることを理解しています。
箱から出してすぐに必要なものはすべて（まあ、ほとんど）です。
- 変数、正規表現、JSON構文解析、Cookieおよび膨大な量のグッズを処理します。
- Jenkins用のシンプルで使いやすいプラグイン。すべてを接続できます。
- 負荷テストの場合、新しいスクリプトを記述する必要はありません。既存のスクリプトをわずかに変更するだけです。
少し恥ずかしかったのは、JenkinsがJMeterを単に負荷テストツールと見なしていたため、見つかったバグの履歴が[パフォーマンスレポート]タブにあったことです。
テストプロセス自体について簡単に説明します。
- 1仮想ユーザーの標準スレッドグループ。
- テストの各グループは、単純なコントローラーに囲まれています（特徴的なプロパティは1つだけです。すべての要求が次々に送信されます。これは、テストケースのように必要なものです）。
- 個々のテストケースは、個別のシンプルコントローラーにも含まれています。 非常に簡単なテストケース、たとえば、承認なしで取得しようとしたときに401コードが返されるかどうかを確認するテストは、個別のテストケースとして作成されます。
千の言葉の代わりに。 完成した生地の小片を次に示します。
多くのテストの1つ。 グループはSimple Controllerで分割されます。 HTTPリクエスト、正規表現エクストラクター、レスポンスアサーション、ユーザー定義変数、ランダム変数などがあります。
ほとんどのテストは、必要なユーザーの作成から始まります。 ここで唯一の「ハードコーディングされた場所」は、データベースに新しい要素を作成する管理者の承認です。
面白いことに、ユーザーを作成するメソッドが作成されましたが、削除は管理パネルから手動でのみ行われました。 個々のケースのロジックを複雑にせず、Seleniumで個別のテストを追加してユーザーをクリーンにし、テスト自体内で作成されたユーザーを削除しませんでした。 このことについて、プログラマーから感謝を受け取りました。管理者ページのページネータを書き始めたとき、データベースにはすでに何千人ものテストユーザーがいました。
結果を確認するために、各リクエストの後に長いアサーションがあります。 彼女は、受信したデータの精度をチェックします：http-responseコード、メッセージ。
デバッグ用の単純なツリービューを除き、すべてのグラフとレポートを無効にしました。 すべてのバグはJenkinsで直接表示できます。負荷テストでは、独自のプラグインを使用してLoadSophiaにすぐにアップロードし、そこで拾う方が便利でした。
プログラマが次のビルドが失敗した理由についてのメッセージのように見えるのは、次のとおりです。
さらに詳細に。 400コード待機-404を返しました：
このブラックブックと不明瞭さの結果 ：
開発のために定められた1,200時間のうち、50時間は自動テストの記述と実際のメンテナンスに費やされました。 バグ修正-70時間。 そしてそれらの約半数は、顧客と開発者の誤解に関連していた。 結果はとても良いです。 すべてを手動でチェックする代わりに、プログラミングにかかる時間よりもほとんど時間がかかります。 プログラマは、新しいアセンブリごとにシステム全体で何かがうまくいかないかをすぐに見ました。
自動テストの起動と変更に関する問題がなかったため、プログラマとテスターの両方に問題はありませんでした。 * .jmxもXMLであるため、テストはメモ帳で直接変更される場合がありました。
負荷テストを行うために、システムの弱点がどこで、どのテストが遅いかを計算して、不必要なテストをしばらくオフにしました。 新しいJMeterパンを使用しても問題はありませんでした。 すべてが文書化され、すべてが明確です。
遭遇した困難のうち：
- oAuth認証を実装するJMeterのプラグインは非常に古く、oAuth 2.0では機能しません。 ソーシャルネットワークを介した認証に関連する機能のごく一部を個別にテストする必要がありました。
- SeleniumとJMeterを結び付けることも、疑わしい喜びです。 UI Adminsも個別にテストされました。
- JMeterインターフェースを経験していない人にとって、最初の知り合いは
網膜剥離である軽度の障害で終わります。
PSわずかな余談。 最近の記事の1つでは、分解によってテスターの作業を削減する方法、さらに重要なこととして、テスト市場の問題について説明しました。 記事の冒頭で説明した「テスターの悪循環」に対する市場の反応の1つは、テストスキルの標準化です。 これにより、雇用主は市場で問題を解決できる必要な専門家を見つけることができると確信するようになります。 テスターは、知識があれば市場で迷子にならないことを知っています。 この場合、JMeterを使用して機能テストを行うことは、学術的な決定ではありません。 しかし、それは時間と1ポンドの神経を減らし、同様の結果をもたらしました。 私には、JMeterとSeleniumの最も基本的な基礎しか知らない友人がいましたが、非常に尊敬される1社に両手を広げて連れて行かれました。 まれにしか使用されていないライブラリを知っているかどうか、人生のどのインタビューでも尋ねられたことはありません。 彼らは主にJMeter、Selenium（およびこれらのソリューションについて書いていること）について再度尋ねました。 「最も重要な、最も重要なツールのいくつかをよく知っており、適用方法を知っている」アプローチは、テスター、雇用主、および市場全体の生活を楽にします。