だから、私がテストを始めたとき、私はアクセシブルな理論を読みました、上司は簡単な質問で2回目のインタビューを始めました-他のタイプのテストに対するモバイルテストの特異性は何ですか？ それから私はこの質問にほぼ答えることができました。 今、私は自分のために次の原則を選び出します。
原則1：継続的なモビリティ
モバイルソフトウェアとデスクトップソフトウェアの主な違いは、iPhoneを使って動き回り、大学の食堂でWi-Fiを無駄にキャッチし（特徴的な手の動きをさせます）、走り回り、一般的にすべての可能なモーションセンサーを中国の職人が作り上げた最大限までロードすることです。 この死を忘れることも同様です。 誰かがオフィスの周りを走り回って画面の向きを変えたり、接続を失って復元したりするのは愚かだと言うかもしれません。 これに、私は人生から2つの反例があります：
- 画面の向きを事前に変更して、アプリケーションをバックグラウンドから復元しようとすると、アプリケーションがクラッシュします。
- このデバイスが写真を撮ったときにデバイスを「振る」ときにアプリケーションがクラッシュします（アプリケーションは元々、写真を作成するために作成されました）。
原則2：ライブベイトでワイファイをキャッチする
ほとんどの最新のアプリケーションは、何らかの形でネットワークを使用します。 これは常に「完全な接続」とはほど遠いものです。 したがって、少なくとも4つの方法でアプリケーションをテストすることが絶対に必要です。
- ポジティブなケース（優れた絶え間ないコミュニケーションの存在）;
- 永続的で優れたコミュニケーションの存在。
- コミュニケーションの欠如;
- コミュニケーションの喪失。
ほとんどのユーザーはクラッシュを目にすることはほとんどありませんが、アプリケーション（ユーザー）の接続に問題がある場合、アプリケーションの負荷が低く、データを保存すると、アプリケーションの使用を停止できます。 通信が不足している場合は、少なくともいくつかのプレースホルダーを表示する必要があります（これにより、ユーザーはアプリケーションが現在データをロードできないことを理解できます）。 まあ、テスターの甘いところはコミュニケーションの損失です。 ユーザーは常にこれに直面しますが、ここで最も重要なことは、可能であればデータの損失を避けることです。
原則3：中断
良い意味で、この原則はリスト全体の先頭にあるべきです。 結局、割り込みはモバイルシステム自体の基本原則の1つでありながら、アプリケーションに最も大きな損害をもたらします。 アプリケーションを使用している間、ユーザーは
- 予期せずに電話を受ける（SMS、リマインダー、通知など）。
- 他のアプリケーションをしばらく開いて後でアプリケーションに戻るために、アプリケーションを閉じます。
- デバイスをしばらくの間スリープ状態にします。
これらの刺激物に対するアプリケーションの反応は、機能テストの直後に確認する必要があります。 ここに、無害な（インターフェースが少し移動した）から重大な（アプリケーションがクラッシュし、データが失われ、完全なahtung）までの興味深い状況の深theがあります。
原則4：オペレーティングシステムとハードウェアの機能
この原則は明らかですが、モバイルデバイスにインストールされているOSとハードウェアは、デスクトップよりもソフトウェアのパフォーマンスに大きな影響を与えると考えています。 なんで？
- AndroidとApple OSは、デスクトップシステムとは大きく異なります。 アクティビティ（およびそのスタック）、意図、ブロードキャストレシーバー、マニフェストファイル（アクセス許可とユーザー機能を示す）、リソースへのアクセス、キャッシュ、およびアプリケーションデータ-これらのすべて、およびその他を、少なくとも簡単に調査して、アプリケーションはこの特定の環境で実行されるため、（アプリケーションの）障害またはデータの損失につながる可能性があります。 これは、状態間の遷移のテスト、メモリリークの検出テストなどにつながります。 これはすべて、アプリケーションの品質を完全に保証するために必要です。
- 進歩はまだ止まっているわけではありませんが、スマートフォンのハードウェアはデスクトップシステムと比較してまだ非常に限られています。 アプリケーションがRAMをどの程度使用するか、システムがこのメモリから自動的に「切り取る」条件、アプリケーションがこの状況でどのように動作するかが特に重要です。
原則5：ヒューマンファクター
アプリケーションが幅広い対象者向けに設計されている場合、ソフトウェア開発から無限に遠く離れた多くの人々がアプリケーションとはまったく異なる動作をするという事実に備えてください。 ここで、すべての湾曲した手でアプリケーションを使用する可能性のあるすべてのケースを計算できるわけではないことを理解することが重要です。 ただし、アプリケーションがメインユーザーケースですべての機能を正しく実行することを確認する必要があります。 また、データをロードするのを待たずに、愚かなユーザーとしてアプリケーションを実行し、すべてを突っついて、アクティビティを開いたり閉じたりして、自分自身を保護することも良いです 「ぼやけた目」の問題は、あなたの女の子、友人、親relativeをプロセスに巻き込むことで解決されます。 彼らにアプリケーションを渡して、彼らがそれをどのように使用するかを見てください。 これにより、最初に何をテストし、何を探すべきかの概算（もちろん、概算はサンプルサイズに依存します）がわかります。
結論の代わりに
もちろん、ある程度までは、この原則の選択は主観的で議論の余地があり、おそらくこの記事は（私にとってもあなたにとっても）大げさか間違っているように思われます。 一方、この記事が有用であり、モバイルアプリケーションをテストする際に最も重要なことを具体化し、忘れないようにするのに役立つことを願っています。 そして最後に、経験を交換したいと思います。
モバイルテストのどの原則を使用していますか？