ボタンを押し、表示されるサービスの利用規約に同意してください。次のページでは、いくつかのコードスニペットとその他の説明を提供します。使用してトラッキングしたい異なるページすべてに貼り付けることです。タグの下に所有するか、アプリケーションのコードと混同しないような適切な場所に配置してください。変更内容を開発用サーバー、またはあなたのコードが必要な場所にアップロードしてください。これで、あなたのサイトは解析データの報告を始めることができるはずです。ホームページに戻り、あなたのサイトについて収集したデータを見始めることができるはずです(もちろん、いくつかのデータが実際に収集されるまで、少し時間を空ける必要があります)。既定では、このようにレポートタブが表示されるはずです。アナリティクスを使用して見ることができるデータは膨大で、そのすべてについて説明する時間はありません。アナリティクスをはじめようでは、初心者に有益なレポート(など)についてのガイダンスを提供しています。選択すると、ユーザーが使用するブラウザーや演算子を確認することができます。アナリティクスを使用する場合、誤解を招くような偏見に注意する必要があります。モバイルにわざわざ対応していないということにつながるかもしれません。モバイルユーザーは一人もいないことになります。テスト要件に含める必要があります(何をテストすべきかは、「よくあるアクセシビリティの問題の対処」の記事で詳しく説明します)。状況固有のニーズも認識しておく必要があります。指定されている場合、モバイルIEのサポートを優先させた方が良いでしょう。最終的な対応表ですから、最終的な対応表は次のようなものに仕上がります。アクセシビリティは一般的なテストに合格していること。ニッチな現代のブラウザー。これから何をテストしていくのか?コードベースに新しい機能を追加してテストする必要がある場合、テストを開始する前に、合格しなければ受け入れられないテスト要件のリストを書き出す必要があります。これらの要件は、視覚的なものであっても機能的なものであってもかまいません。以下の例のものがあるとします(ソースコードを参照してください。ライブ実行版もあります)。この機能のテスト基準は、次のように書くことができます。グレード:ボタンは、ユーザーの主な制御機構(マウス、キーボード、タッチなど、それが何であれ)により起動できるようにする必要があります。ボタンを押すと、情報ボックスが現れたり消えたりすること。テキストは読み取り可能でなければなりません。画面の内側から画面リーダーを使用する視覚障碍を持つユーザーも、テキストにアクセスできること。グレード:情報ボックスは、現れたり消えたりするときにスムーズにアニメーションする必要があります。グラデーションとテキストの影が現れて、ボックスの見栄えがよくなるようにします。動作しないことに気づいたかもしれません。トランジションに対応していない場合は、機能検出ライブラリーを使用して、異なる形で機能を実装する必要があります(このコースの後半の機能検出を実装するを参照してください)。ボタンがキーボードだけで使用できないことにもお気づきでしょう。これも改善する必要があります。トグルのキーボード制御を実装するか、他にも全く別のメソッドを使用することができるかもしれません。これらのテスト基準は、以下の理由で有益なものです。テストを実施する際に、以下に従うべき手順の集合を与えます。これらはまた、自動化されたテストを書くための基礎となります。テストラボを用意するブラウザーテストを実施するための一つのオプションは、自分自身でテストを行うことです。そのためには、実際の物理的な端末とエミュレートされた環境(エミュレータまたは仮想マシンのいずれかを使用)を組み合わせて使用することになると思います。一般的には、テストしたいブラウザを実行する実機があった方がよいでしょう。この方が、動作や全体的な使い勝手の面で最も高い精度が提供されます。低レベルの機器ラボとしては、おそらく以下のようなものが必要でしょう。含めることができます。含めることができます。純正のブラウザーが含まれます。含めることができます。以下のようなものも、入手できれば良いオプションです。