15

ビルド、単体テストの実行、静的コード分析の実行、ドキュメントの生成を行う継続的インテグレーションプロセスがすでにあります。ただし、これを拡張して、自動パフォーマンステストを含めたいと思います。この場合、.NETWebアプリケーションに取り組んでいます。

JMeter(CIプロセス以外)でいくつかのパフォーマンステストを行いましたが、これがCIプロセスに含めるのに最適なツールかどうかわかりませんか?セレンはオプションですか?WAPT Pro?

どのレベルでパフォーマンスをテストする必要がありますか?一連の「パフォーマンスユニットテスト」が必要ですか?JMeter(または同様のもの)を本番環境のような環境で実行し、リクエストに1秒以上かかる場合は失敗する必要がありますか?このようなものは分散が大きすぎませんか?

では、CIの一部として自動パフォーマンステストを含めていますか?何をテストし、どのツールを使用しますか?あなたの経験はどのようなものでしたか?

4

6 に答える 6

10

まず、JMeterはコマンドラインから実行でき、これを行うときに変数を渡すことができるため、CIに含めるのに適しています。私はこのタスクにそれをお勧めします。

ただし、一般的には、Perfを統合します。CIへのテストは困難です。これが理由の多くをすでにリストしているので、制限を理解しているので、すでに途中まで進んでいます。そしてそれは摩擦です:Perfを持つことは可能です。CIでテストしますが、限られた範囲でのみテストします。

良いアプローチは、これらの原則のいくつかに従っていると思います。

CIで全負荷(またはソークまたは容量)テストを実行することはできません。これは実用的ではありません。 結果は主観的なものであり、人間による解釈が必要であり、テストの実行には時間がかかります。ただし、リクエストの応答時間を測定する、より単純で削減された一連のテストを実行してから、次のいずれかの応答時間を評価できます。

  • NFRまたは予想される範囲に対して-つまり。1秒未満である必要があります。
  • 以前の結果に対して-すなわち。前回のビルドより10%以上逸脱してはなりません。

自動ロード/パフォーマンスを実行することもできます。ビルドプロセスの外部で-フルボリュームで-テストします。「セミCI」。 では、テストを自動化して一晩実行し、午前中に結果を確認することはできますか?

繰り返します。 それを実行して結果を取得し、テストとそれらを時間の経過とともにどのように解釈するかを微調整するだけです。シンプルに保ち、役立つと思われる領域に焦点を合わせます。ファンファーレで立ち上げないでください。プロセスに自信が持てるようになるまで静かにしてから、ビルドに失敗して人々にそのことを伝え始めてください。最初は、多くの偽陰性が発生する可能性があります。

結果を計測する これを行います。多くの。CIはすべて早期に失敗することであるため、目標を達成するときにそれを採用する場合、それを達成するための最善の方法は、テストを早期に頻繁に実行することですが、それに関する問題は、データに埋もれてしまうリスクです。したがって、データを処理して関連情報を提示するための効果的な方法は、非常に役立ちます。

レッドフラッググリーンフラッグまでのプロセス全体を自動化することはできませんが、可能な限りその道を進むように努める必要があります。

最後に、リードのパフォーマンスから非常に良い話がありました。この主題をカバーするGoogleのテスター。今は少し古いですが、原則はまだ残っています。さらに、数週間以内に、英国のメディア企業であるChannel4が、彼らがこれにどのように取り組んだかについて話し合うミートアップに行きます。スライドをお願いできるかもしれません。

于 2013-02-10T21:38:38.783 に答える
2

> CIで全負荷(またはソークまたは容量)テストを実行することはできません。これは実用的ではありません。

今週ここ米国で開催されたTISQA会議の後、CI自動化を使用して、完全で複雑な負荷テストをますます自動化する必要があると自信を持って言う傾向があります。

意味のあるテスト結果をサポートするために、より現実的なインフラストラクチャで構成された、より大規模な負荷テストラボで別のCIインスタンスを実行することを検討することもできます。負荷テストプロセス自体は、個別のソフトウェア開発プロセス(設計、構築、展開、実行、分析、繰り返し)と同じです。現在、すべてのパフォーマンスツールのほとんどが、SOASTA、LoadRunner / PC、JMeter、Neotys、Blazemeter、Flood.ioなどのCIソリューションへのよりエレガントで堅牢な統合をサポートしています。

ただし、注意すべき3つの点があります-オリバーのコメントと同様です:-パフォーマンス結果にはさらに多くのニュアンスがあります...明確に合格または不合格だけでなく-アプリの変更と同期するためのスクリプトのメンテナンスを忘れないでください-同期/スケーリング本番環境での負荷テストラボも自動化される可能性があります

必要に応じて、私自身のTISQAプレゼンテーションのスライドのいくつかをここで確認してください。これは、ライフサイクル全体でCI+パフォーマンスを使用する方法の始まりかもしれません。たとえば、PRODで変更されたときに「構成を監視」し、それらの変更を負荷テスト環境に同期するCIインスタンスを作成してみませんか?

于 2014-03-14T19:19:36.263 に答える
1

JMeterもSeleniumもCIのツールではありません。JMeterはパフォーマンステストツールであり、Seleniumは自動機能テスト用のツールです。したがって、パフォーマンステストをビルドプロセスに統合するには、JMeterを任意のCIサーバー(Jenkins、Bamdooなど)で使用できます。

AFAIK、最近JenkinsでJMeterを使用する一般的な解決策は2つあります。

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

  2. 別の方法-JMeterテストクラウドを使用します。このサービスは、アプリケーションのビルド後にリモートテストを開始できるJenkinsプラグインを提供します。この場合、テストサーバーの構成について気にする必要はありません。

PS Blazemeterで働いている間、客観的な情報を提供したかったのです。うまくいけば、それは役に立ちます。

于 2013-02-08T12:36:37.840 に答える
0

あなたが尋ねたあなたの質問で-セレンはオプションですか?

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

小さなAmazonVM(ami)では、このアプローチを使用して約25人の仮想ユーザーをシミュレートしています。したがって、ニーズが500 VUのオーダーである場合は、次のような利点があるため、これを調査します。-

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

機能テストはパフォーマンステストとして再利用されるため、1つのツールで専門家になり、再利用するだけで再利用できます。

于 2013-03-29T15:40:49.433 に答える
0

パフォーマンステストと継続的インテグレーションの統合を検討しているのはあなただけではありません。一般に、多くの組織化によって、非機能的なテストは無視されるか、ソフトウェア配信プロセスの最後まで残されていました。CI / CDの非機能要件の自動検証に対する態度の前向きな変化と、より多くの関心を見ることができます。これには、パフォーマンス、アクセシビリティ、セキュリティがさまざまな程度で含まれます。パフォーマンステストにSeleniumを使用することについて言及しました。私は何人かの人々がそれをする(しようとする)ことを知っています、そしてそのような試みの1つがどれほど失敗したかさえ見ました。なぜ人々がそれを検討するのかを完全に理解していますが、これには近づかないことをお勧めします。反対のことをする非常に正当な理由がない限り。一般的に、想像以上に達成するのは難しいです。

JMeterを選択したCIサーバーと統合するのに役立つ新しいツールがあり、TeamCityとJenkins専用の機能がいくつかあります。

https://github.com/automatictester/lightning

機能のリクエストは大歓迎です。

于 2015-07-26T16:15:12.990 に答える
0

パフォーマンスがアプリケーションの重要な部分であり、最初から継続的に気にかけている(または気にかけたい)場合は、統合と展開のパイプラインの一部として維持することを目指しています。そうです。

.NETの世界(およびそれ以降)には、このエクスペリエンスを提供し、お気に入りのCI/CDソフトウェアでシームレスにセットアップするのに役立つ多くのツールがあります。

  • k6.iohttps://k6.io/-以前はLoadImpactと呼ばれていました)-環境の外部でパフォーマンスチェックを実行し、結果とともにパイプラインに報告することができます。構成と統合が簡単で、ストレステストや負荷テストなどのより「賢い」テストシナリオに最適です。
  • sitespeed.iohttps://www.sitespeed.io/)-私の2番目のお気に入りで、非常に使いやすく、FEのパフォーマンスとテストを追跡するためのツールを簡単に構成できます(例:Seleniumで実行)
  • Locusthttps://locust.io/)-独自の環境での負荷テスト用。Azure上にサーバーの独自の「ファーム」を作成するためのARMテンプレートを使用した優れたリポジトリ:https ://github.com/ORBA/azure-locust
  • dynatracehttps://www.dynatrace.com/)-完全に認定されたAPM=多数の機能と可能性を備えたアプリケーションパフォーマンス監視/管理ツール
  • Roslyn Analyzer(FxCopAnalyzers)、StyleCopAnalyzers、EditorConfig、およびコードがビルドおよびデプロイメントパイプラインにプッシュされる前でも、コード内の一般的な(パフォーマンス関連も!)問題を検出するその他の方法
  • 灯台レポート-最も一般的な問題への「ポインター」として実行され、プロセス中の通知などのPRコメントとして含まれる場合もあります(多くのGithubアクションまたはDevOpsパッケージがそれを実行しています)

つまり、そうです。上記のすべてと、さらに多くの機能をパイプラインのステップとして配置できます。私たちのセットアップでは、現在、監査を行っているステージング環境とUAT環境の間に、静的コード分析、パフォーマンステスト(FE&BE)、セキュリティスキャン、侵入テスト(OWASP ZAP)などのステージ全体があります。テストがしきい値または期待値と一致しない場合(明らかに不要な劣化を導入したくない場合)、ここで停止し、リファクタリングに戻って問題を修正してからUATと本番環境に到達します。それがあなたと多分他の誰かを助けることを願っています。


最近の講演(下のスライド)でもいくつかの調査結果を収集しました。これは、このトピックに関する一連のブログに変換され、最初のブログはすでに公開されています。

  1. 「ModernWebPerformanceTesting」に関する私の講演のスライドデッキ:https ://slides.com/zajkowskimarcin/modern-web-performance-testing/
  2. 同じトピックに関するシリーズの最初のブログ:https ://wearecogworks.com/blog/the-importance-of-modern-web-performance-testing-part-1
于 2020-04-28T00:04:26.443 に答える