フロントエンドテストとは何ですか?

⚡ スマートサマリー

フロントエンドテストは、プレゼンテーション層のグラフィカルユーザーインターフェース、機能性、ユーザビリティ、パフォーマンスを検証し、レイアウトの崩れ、スクリプトの不具合、ページの表示速度の低下などを、実際のユーザーが遭遇する前に発見します。

  • 🔘 まず範囲から: スクリプト作成を開始する前に、対象となるブラウザ、オペレーティングシステム、デバイスを文書化された計画書で確定します。
  • ☑️ 3つのトリガー: CSSの回帰、 Javaスクリプトの破損チェックとパフォーマンスチェックは、ほとんどのフロントエンドスイートの基盤となっている。
  • レイヤードスイート: ユニットテスト、コンポーネントテスト、エンドツーエンドテスト、ビジュアルリグレッションテスト、アクセシビリティチェックは、それぞれ異なる障害を検出します。
  • 🧪 ツールミックス: ジャスミン、 SeleniumCSSLintとBackstopJSはJestと並んで配置されています。 Cypress そして劇作家。
  • 🛠️ より速い走り: ヘッドレスブラウザ、DOMレンダリングの削減、そしてテストケースの分離により、回帰テストのサイクルが短縮されます。
  • 📈 パフォーマンスの焦点: PageSpeed Insightsで測定されるコアWebバイタルは、インターフェースがユーザーに迅速に届くかどうかを示します。

WebアプリケーションにおけるGUI、機能性、ユーザビリティのフロントエンドテスト

フロントエンドテストとは何ですか?

フロントエンドテスト これは、 グラフィカル·ユーザー·インターフェース (GUI)、機能性、ユーザビリティ ウェブアプリケーション テストが実施されます。目標は、プレゼンテーション層が連続的なアップデートを通じて欠陥のない状態を維持することを確認することです。

例えば、フォームフィールドに名前を入力する際に​​、数字は受け付けられないようにする必要があります。GUI要素の配置を確認することも、日常的な例です。

これに加えて、フロントエンドテストは以下の項目について実施されます。

  • CSS回帰テスト: フロントエンドのレイアウトを損なうような、軽微なCSSの変更。
  • Javaスクリプトの変更 それによってフロントエンドが機能しなくなる。
  • 性能チェック インターフェースがどれだけ早く使いやすくなるか、という点において。

フロントエンド Web サイトのテスト計画を作成するには?

フロントエンドのテスト計画を作成するのは、シンプルな4つのステップからなるプロセスです。

ステップ1) テスト計画を管理するためのツールを見つけましょう。

ステップ2) フロントエンドテストの予算を決定する。

ステップ3) プロセス全体のタイムラインを設定してください。

ステップ4) プロジェクトの範囲を決定します。範囲には以下が含まれます。

  • Operaユーザーが使用するシステムとブラウザ
  • 観客が使用する人気のデバイス
  • 聴衆の技術的熟練度
  • 視聴者のインターネット接続速度

フロントエンドテスト計画を作成する理由とは?

下の図は、計画において明確にしておくべき2つの側面を示しています。

対象となるブラウザとオペレーティングシステムを網羅したフロントエンドテスト計画

プランでは、どのブラウザと OS プロジェクトで網羅しなければならない事項は多岐に渡る。組み合わせは無数にあるため、計画を立てることで労力とコストの両方を削減できる。

この計画には2つの明確な利点がある。

  • これにより、プロジェクトの範囲が完全に明確になります。
  • プロジェクトが展開される際に、安心感を与えてくれる。

フロントエンドテストを改善するためのヒント

より良いフロントエンドテスト計画を構築するためのヒント:

  • 予算、リソース、時間を慎重に準備してください。
  • ヘッドレスブラウザを使用すると、テストの実行速度が向上します。
  • テストでの DOM レンダリングの量を削減して、実行を高速化します。
  • テストケースを分離することで、バグの根本原因を迅速に特定し、修正サイクルを短縮できます。
  • テストスクリプトを再利用可能にして、より迅速に 回帰サイクル.
  • テストスクリプトには一貫した命名規則を使用してください。
  • それぞれを結んでください テストケース 一つの目に見える行動へ。

フロントエンドテストツール

スクリプト、スタイルシート、ビジュアルをすべて網羅する単一のツールは存在しないため、チームは複数のツールを組み合わせて使用​​する。

JavaScriptテストツール:Jasmine

ジャスミン テストのための行動駆動型開発フレームワークです Javaスクリプト このコードは、技術的な詳細よりもビジネス価値を重視し、簡潔な構文を持ち、他のフレームワークに依存していません。JSSpec、ScrewUnit、JSpec、RSpecなどの単体テストフレームワークを活用しています。現在では、JestとVitestが広く使われている代替フレームワークです。

機能テストツール: Selenium

Selenium ブラウザやプラットフォームを横断したエンドツーエンドのテストを実行します。 Windows, macOS Linux と、テストを記述できる Java, PythonC#やその他の言語。 Selenium IDE 録音と再生機能を追加するため、最初のスクリプトにはコードは必要ありません。 Cypress そして劇作家は、組み込みの待ち時間で同じ領域をカバーし、 tracる。

CSSとビジュアルツール:CSSLintとBackstopJS

CSSLint は、で書かれたオープンソースのリンターです。 Javaブラウザとコマンドラインの両方で実行できるスクリプト。現在は積極的にメンテナンスされていないため、チームは現在、StylelintまたはESLintのCSSサポートを使用してスタイルシートのリンティングを行っています。

バックストップJS ビジュアル回帰テストを処理します。ヘッドレスChromeでページをレンダリングし、各スクリーンショットを承認済みの参照画像と比較し、ビューポートサイズと合否判定条件を設定できます。

フロントエンドテストツールには、2つの課題が当てはまります。

  • テスト自動化 初期段階では多大な努力が必要となる。
  • ツールによっては、特定のオペレーティングシステムやブラウザのバージョンとの互換性に問題が生じる場合があります。

フロントエンドのパフォーマンスの最適化

フロントエンドのパフォーマンス テストは、ページがどれくらい速く読み込まれて使用可能になるかという 1 つの質問に答えます。アプリケーションが高負荷にさらされる前に、単一ユーザー向けに調整することは良い習慣です。 性能試験.

フロントエンドのパフォーマンスの最適化が重要なのはなぜですか?

かつてパフォーマンス最適化とは、サーバーのチューニングを意味していた。なぜなら、ほとんどのウェブサイトは静的であり、処理はサーバー側で行われていたからである。

ウェブアプリケーションが動的になるにつれ、フレームワークコード、サードパーティ製スクリプト、画像、フォントなど、ブラウザ側で処理される作業が大幅に増加した。その結果、クライアント側のコード自体がボトルネックとなってしまった。

フロントエンドのパフォーマンス最適化の利点は何ですか?

  • クライアント側の問題は、サーバーのボトルネックと同様にユーザーエクスペリエンスに直接的な悪影響を与えるため、どちらも注意を払う必要がある。
  • 訪問者の待ち時間の大部分は、サーバーが応答した後、つまりダウンロード、解析、レンダリングといった処理に費やされるため、フロントエンドの作業の方が目に見える効果が大きい場合が多い。
  • 画像の圧縮、スクリプトの実行延期、メディア用の領域確保といった対策は、バックエンドを再構築するよりも安価です。
  • コアウェブバイタル — 最大コンテンツペイント、次のペイントへのインタラクション、累積レイアウト Shift ―結果を共有するスコアボードに表示する。

フロントエンドパフォーマンステストツール

1. PageSpeed Insightsの評価による

PageSpeed​​ Insightsの is GoogleLighthouseの無料ページ分析サービスです。Lighthouse監査を実行し、Core Web Vitalsをレポートし、読み込み時間を短縮するための提案を表示します。LighthouseはChrome DevToolsにも同梱されています。

2. Pingdom

Pingdom ウェブサイトのパフォーマンス監視サービスです。ページの表示速度が低下したり、オフラインになったりした場合に顧客に警告を発するため、ユーザーから問題が報告される前に問題が表面化します。

機能と特徴:

  • ウェブページのすべての部分を検査します
  • パフォーマンスの概要を提供します
  • Tracパフォーマンス履歴
  • 複数の場所からテストできる

よくあるご質問

フロントエンドテストは、ユーザーが目にする部分(レイアウト、操作性、応答性)を検証します。バックエンドテストは、インターフェースの背後にあるサーバー、API、データベースを検証します。この2つは相互補完的な関係にあり、リリースには両方のテストが必要です。

一般的なテストスイートは、関数に対する単体テスト、レンダリングされたウィジェットに対するコンポーネントテスト、ユーザー体験に対するエンドツーエンドテスト、スクリーンショットに対するビジュアルリグレッションテスト、およびアクセシビリティスキャンといった複数のテスト層で構成されています。各層は、他の層が見逃した不具合を検出します。

基準となるスクリーンショットが承認され、その後の実行結果はピクセル単位で比較されます。差異は人間が承認または却下し、機能的なアサーションでは検出できないレイアウトの崩れなどを検出します。

はい。スキャナーは同じパイプラインでラベルの欠落、コントラスト不良、フォーカス順序の乱れを検出します。キーボードとスクリーンリーダーの処理は手動のままなので、 アクセシビリティテスト 完全に自動化されることは決してない。

AIは、ユーザーストーリーからテストケースのドラフトを作成し、安定したセレクタを提案し、マークアップの変更後にロケーターを自己修復し、ほぼ同一の視覚的な差分をクラスタリングします。 Rev依然として重要です。生成されたアサーションによって欠陥が固定化される可能性があります。

GitHubコパイロット 開いているファイルからコンポーネントのテスト、モック、ページオブジェクトを作成し、定型コードの多くを削減します。ただし、非同期動作や想定していなかったビジネスルールについては、開発者による確認が必要です。

どちらもです。フォーム、ナビゲーション、レイアウトのスナップショットといっ​​た繰り返し確認が必要な項目は、ビルドごとに自動化されます。一方、探索的な作業、視覚的な判断、ユーザビリティの観察は、人間の解釈に依存するため、手動で行われます。

分析に任せましょう。実際のトラフィックの大部分を占めるブラウザ、バージョン、画面サイズをカバーし、古いベースラインを1つ追加し、残りはスポットチェックとして扱います。 モバイルテスト.