アプリのテスト

アプリのテストは、特に複数のプラットフォームや端末に対応する場合、非常に重要です。必要なテストの回数や種類は、対応する端末やプラットフォームによります。テストの種類には以下のようなものが挙げられます。

  • 速度
  • パフォーマンス効率
  • 入出力の検証
  • タッチと双方向性

これらが基本的なテストの種類ですが、テストの際は他にも考慮すべきアイデアがいくつかあります。

Web 環境の違い

異なる Web 環境に取り組む際に留意すべきいくつかのことを以下に挙げます。

ベンダー接頭辞

ブラウザが対応している JavaScript と CSS の新機能には、-webkit-moz-o-ms といったベンダー接頭辞が付いている場合があります。使用する予定の環境と接頭辞付き機能について正しく理解しましょう。

注: 特定の端末のみで使用できる機能の使用は、適切なフォールバックを提供するか、非常に限られた端末でそのアプリが使われることを想定していない限り避けるべきでしょう。

機能判別

特定の機能は一部の環境のみ対応が行われている場合もあります。機能判別 は特定のプラットフォームでどのツールが使用可能か知る最善の方法です。例えば、位置情報 API への対応を判別するには、以下のようなコードを書くのです。

if("geolocation" in navigator) {
  // 位置情報が使用可能です。使いましょう
}

CanIUse.com では、特定の機能に関するブラウザや端末の対応状況が詳しい表にまとめられています。Modernizr のようなヘルパーライブラリは、ページ読み込みの際に機能を自動的に判別し、それに応じて対応情報を提供します。

レスポンシブデザイン

メディアクエリ の使用と設計への配慮によって、設計に関する問題を防ぐことが可能です。一般的な落とし穴としては、拡大あるいは縮小される要素にベクターグラフィックスを使っていなかった、全端末上で固定サイズの要素を使っていた、端末の向きを変えてテストしていなかった、あるいは単にアプリを別の解像度で見ていなかった、などが挙げられます。Screenflyresponsivepx などのサービスは、アプリを異なるサイズでテストするのに役立ちますが、手動テストのために便利な対応端末を入手することの代わりになるものはありません。

異なる端末が異なる画面解像度を持つ場合に起こりうる問題についても考えてみてください。その典型例が、Apple が新しい 2048x1536 のディスプレイを備えた第 3 世代 iPad を発表したときに起きた問題です。

こちらの記事も参照してください。

単体テスト

単体テストはあらゆる開発において一般的な手法であり、Web アプリのテストも違いはありません。CSS と JavaScript の単体テストも、アプリケーションのコードがモジュール化されている場合は非常に簡単です。一般的な JavaScript 単体テストフレームワークとしては、JasmineQUnitYUI Test などがあります。それぞれのサイトに、そのフレームワークをどのように使うかコードサンプルが載っています。

パフォーマンス

パフォーマンステストは、アプリによって実行されるタスクに完全に依存するため、具体的な方法の策定が難しい場合もあります。HTTP リクエストを減らす (JavaScript ファイルの連結や CSS スプライトが役立ちます)、JavaScript や CSS を最小化する、スクリプトをページの最下部に置く、Expires ヘッダを適切に設定するといった基本的な Web コーディング指針がすべて当てはまります。YSlow チームが、従うと良い、より 有益な Web パフォーマンスベストプラクティス を提供しており、そのすべてがあなたの Web アプリを改善することでしょう。GoogleHTML5Rocks のサイトにも Web パフォーマンスベストプラクティス一覧が載っています。

Document Tags and Contributors

タグ:
Contributors to this page: ethertank, Yoshino
最終更新者: Yoshino,