継続的な統合におけるパフォーマンステスト？

Question

私たちは、ビルド、ユニットテストの実行、スタティックコード分析の実行、ドキュメントの生成など、継続的な統合プロセスを既に行っています。ただし、これを拡張して自動パフォーマンステストを含めることをお勧めします。この場合、.NET Webアプリケーションを作成しています。

私たちはJMeter（CIプロセス外）でいくつかのパフォーマンステストを行っていますが、これがCIプロセスに組み込むのに最適なツールかどうかわかりません。セレンはオプションですか？ WAPTプロ？

どのレベルでパフォーマンスをテストする必要がありますか？私たちは一連の「パフォーマンスユニットテスト」を持っているべきですか？プロダクションのような環境でJMeter（または類似のもの）を実行する必要があります。要求が1秒以上かかると失敗しますか？このようなものはあまりにも高い分散を持っていないでしょうか？

あなたはCIの一部として自動パフォーマンステストを組み入れていますか？何をテストし、どのツールを使用しますか？あなたの経験は何ですか？

Answer 1

まず、JMeterはコマンドラインから実行できるため、これを行う際に変数を渡すことができるため、CIに組み込むのに適しています。私はこの仕事のためにそれをお勧めします。

一般的に、Perfを統合しています。 CIへのテストは困難です。あなたはすでにこれが理由である理由の多くを既に列挙していますので、あなたがその限界を理解しているので、あなたはすでに半分のところにいます。そしてそれはこすりです：Perfを持つことは可能です。 CIのテストは限られていますが、

私は良いアプローチは、これらの原則のいくつかは次のことを考える：

あなたが全負荷を実行します（またはソークや容量）することはできませんCIでのテストを、それは実用的ではありません。 結果は主観的で人間の解釈が必要であり、テストを実行するには時間がかかります。しかし、要求の応答時間を測定する簡単で細かいテストを実行し、次にこれらの応答時間を評価することができます。

• NFRまたは予想される範囲 - つまり、 1秒未満でなければなりません。
• 上記の結果に対して、すなわち、最後のビルドよりも10％以上ずれてはいけません。

自動化されたload/perfを実行することもできます。フルボリュームでのテスト - ビルドプロセスの外。 'Semi CI' 一晩中実行するテストを自動化して、午前中に結果を確認できますか？

反復。 テストを開始して結果を得て、テストを細かく調整し、時間の経過とともにテストをどのように解釈するかを開始してください。それをシンプルに保ち、役に立つと思われる領域に焦点を合わせます。ファンファーレで起動しないでください。プロセスに自信を持ってビルドに失敗し、そのことを人に伝えるようになるまで静かにしてください。最初は偽のネガティブなものがたくさんあります。

機器の結果 これを行う。たくさん。 CIはすべて早期に失敗することになりますので、目的を達成するには、テストを早期に実行するのが最良の方法ですが、その問題はデータに埋もれる危険があります。したがって、データをクランチして関連情報を提示する効果的な方法は、かなり役立ちます。

プロセス全体を自動化してRed Flag Green Flagにすることはできませんが、可能な限りそのパスを遠ざけようとする必要があります。

最後に、Perfのリーダーであるa very good talkがありました。この主題を扱うGoogleのテスターです。今はちょっと古いですが、原則はまだありません。さらに、数週間後にイギリスのメディア会社、Channel4が、彼らがどのようにこれに近づいてきたかについて話し合うmeetupに行く予定です。スライドの一部を聞くことができます。

Answer 2

JMeterもSeleniumもCI用のツールではありません。 JMeterはパフォーマンステストツール、Seleniumは自動機能テストのツールです。だから、パフォーマンステストをビルドプロセスに統合しているために、あなたはCIサーバのいずれかとのJMeterを使用することができます。

：ジェンキンス、Bamdooなど

私の知る限り、この頃ジェンキンスとのJMeterを使用しての2つの一般的な解決策があります

1. JMeterプラグインを使用してJenkins/Hudsonを使用すると、ビルドプロセスの完了後にパフォーマンステストタスクを開始できます。この場合、JMeterが設定された適切な数の負荷ジェネレータが必要です。

2. 別の方法 - JMeter testing cloudを使用します。このサービスはJenkins pluginを提供します。これにより、アプリケーションの構築後にリモートテストを開始できます。この場合、テストサーバーの設定には注意する必要はありません。

P.S.私がBlazemeterのために働いている間、私は客観的な情報を提供したいと思っていました。希望、それは役に立ちます。

Answer 3

あなたの質問には、セレンはオプションですか？

内部グリッドのコンピュータまたはパブリッククラウドを使用してCIから実行している場合は、ヘッドレスブラウザドライバでSelenium WebDriverを使用してパフォーマンステストを検討する必要があります。

小さなAmazon VM（ami）では、私はこのアプローチを使ってシミュレートされた約25人のVirtual Usersを取得します。したがって、あなたのニーズが500VUの場合は、次のようなメリットがあります。 -

ヘッドレスブラウザがこれを自動的に処理するため、URLの書き換えなどの「相関」はなくなりました。

機能テストは、パフォーマンステストとして再利用されているため、1つのツールはエキスパートになり、再利用は再利用されません。

Answer 4

> CIで完全ロード（またはソークまたは容量）テストを実行することはできませんが、現実的ではありません。

今週は米国内のTISQA conferenceの後、私は自信を持って、より多くの、より多くの完全な複雑な負荷テストをCIオートメーションで自動化する必要があると言います。

重要なテスト結果をサポートするためのより現実的なインフラストラクチャで構成された大規模な負荷テストラボでは、別個のCIインスタンスを実行することを検討することさえあります。ロードテストプロセス自体は、別個のソフトウェア開発プロセス（設計、構築、デプロイ、実行、分析、リピート）とは異なります。ほとんどのパフォーマンスツールのほとんどは、SOASTA、LoadRunner/PC、JMeter、Neotys、Blazemeter、Flood.ioなど、CIソリューションのより洗練された堅牢な統合をサポートしています。オリバーのコメントに似て -

しかし、ここでは、に注意する3つのことをです： - パフォーマンスの結果に多くのニュアンスがあるのです...だけではなく、明らかPASSまたは をFAIL - との同期を保つために、スクリプトのメンテナンスを忘れないでくださいアプリの変更 - 負荷テストラボをプロダクションと同期/スケールすることも自動化される可能性があります。

ご希望の場合は、自分のTISQAプレゼンテーションhereからスライドの一部を確認してください。ライフサイクル全体でCI +パフォーマンスを使用する方法の出発点になるかもしれません。そのような場合、なぜPRODで変更され、それらの変更を負荷テスト環境に同期させるような "構成を監視する" CIインスタンスがないのでしょうか？

Answer 5

パフォーマンステストと継続的な統合を統合するのはあなただけではありません。一般に、非機能テストは無視されたり、ソフトウェア配布プロセスの終わりに多くの組織化によって残されていました。私は、CI/CDの非機能要件の自動検証における姿勢のより良い変化とより大きな関心を見ることができます。これには、パフォーマンス、アクセシビリティ、セキュリティなど、さまざまなものが含まれます。あなたはパフォーマンステストのためにSeleniumを使って言及しました。私はそれをやろうとしている人も知っていて、そのような試みのどれが成功しなかったかを見ていました。人々がそれをやろうと考えている理由を完全に理解していますが、私はこれを避けることを提案します。あなたが反対をする理由がない限り、一般に、考えるよりも達成が難しいです。 Seleniumは、GUIテスト目的でCIに組み込むための優れたツールですが、パフォーマンステストへの組み込みは多少面倒です。

あなたはチームシティーとジェンキンスのためのいくつかの専用の機能で、お好みのCIサーバとのJMeterの統合を支援する新しいツールが、今がある：

https://github.com/automatictester/lightning

機能の要求は歓迎されています。