Android APP のテスト プロセスと一般的な問題は何ですか?

1. 自動テスト

自動テストには、主にいくつかの部分、UI 機能の自動テスト、インターフェイスの自動テスト、その他の特殊な自動テストが含まれます。

1.1UI 機能の自動テスト

UI 機能の自動テスト (自動テストとも呼ばれます) は、主に UI インターフェイスに基づく自動テストであり、UI 機能のクリックはスクリプトを通じて実現されます。 . 手動テストを自動化に置き換えます。

このテストの利点は、反復性の高いインターフェイス機能の機能テストのためにテストの人員を効果的に解放し、スクリプトの実行を使用して機能を迅速かつ効率的に返すことができることです。

しかし、この種のテストには、維持コストが高い、判断を誤りやすい、互換性が不十分であるなどの欠点があることも明らかです。インターフェースの操作に基づいているため、インターフェースの安定性がスクリプトを維持する上での最大の制約となっています。インターフェイスの対話が頻繁に変更されるということは、テスト ケース スクリプトを常に更新する必要があり、大量のテスト リソースを占有することになります。

#=

誤った判断が起こりやすいのは、主に UI 制御に基づく識別では、ネットワークの状況、デバイスの構成、テスト環境などにより、読み込み速度の低下や異常な読み込みが発生しやすく、その結果、テストが中断される可能性があるためです。ケースの実行プロセス中の一部の判断は不正確であり、テストの精度に影響を与えます。互換性が不十分であるとは、主に、異​​なるデバイス、異なるオペレーティング システム、異なるハードウェア環境などでテスト スクリプトを実行すると、予測不可能な状況が発生し、不正確なテスト ケースの実行結果が生じることを意味します。

上記のメリット・デメリットの比較を踏まえ、当社のUI機能自動テストでは、主にAPPのコアパスのテストを実装し、繰り返し回数が多い機能モジュールのUIテストを実施します。実行、繰り返しの検証、低頻度の UI インターフェイス変更機能の自動テストの実装。

繰り返し実行や検証を何度も繰り返す必要があるため、自動化後の利用率が高く、UIインターフェースの変更頻度も低いため、その後のメンテナンスコストも高くありません。 , これら 3 種類のユースケースは、入出力が比較的多い部分については、UI 機能の自動テストの実践を最優先に行います。

UI 機能の自動テストのプロセスでは、関連するコントロール、テスト ケース、テスト セットを効果的に分類して管理し、反復可能な作業をタイムリーにマージしてリソースの無駄を削減できます。 UI機能が変更された場合も、より少ないコストで保守できるため、保守コストを削減できます。

1.2 インターフェイスの自動テスト

UI 機能の自動テストのセクションでは、自動化の制約である安定性について説明しました。 UI インターフェースが不安定であるからこそ、UI 機能の自動化コストは相対的に高くなります。したがって、UI 機能よりも安定していて自動化に適した部分、それがインターフェースであると当然考えられます。

APP のインターフェイスは、さまざまな段階でのプロダクト マネージャーのさまざまな要求により変更される可能性がありますが、その背後にあるインターフェイスは通常比較的安定しており、自動テストを実行するのに有益です。

APP によって呼び出されるインターフェイスを準備し、機能モジュールに従って並べ替えて要約し、自動化のために優先順位を付け、各インターフェイスの意味、さまざまなパラメーターの値の範囲、および処理方法を理解する必要があります。さまざまな入力 さまざまな出力を生成する状況を調査し、エラーまたは例外の戻り値を要約して、インターフェイス テストの有効性と完全性を確認します。

インターフェイス自動化テストの開始後、インターフェイスのドキュメントを開発エンジニアと協力して維持する必要があります。インターフェイスの増加または減少、または既存のインターフェイスへの関連変更があった場合、テスト エンジニアはすぐに知ることができます。インターフェイス自動テストのユースケースに対応する調整を行います。

1.3 その他の特別な自動テスト

上記の 2 つのカテゴリの自動化に加えて、自動化を使用していくつかの特別なテストを実行し、テストの品質とテストの効率を向上させることもできます。ここでは、どのタスクを自動化することで実現できるのか、どのテストを自動化してテスト効率を向上させることができるのか、どの機能ポイントを自動化して長期的なテスト監視を実現できるのかなど、日々のテスト作業の中で真剣に考える必要があります。

例えば、私が担当しているプロジェクトではある機能があるのですが、手動テストでは限られたクリック数でしか検証できず、クリック頻度も低いのですが、スクリプトを利用することで、テスト プロセス中に実装できます。クリック操作をより速く、より長くするには、自動化を使用して実現できます。自社のテスト機器だけでなく、別のデバイスでも実行できる自動テストは効果的で、テスト効率とテスト品質の向上につながります。このテストはさまざまな理由から UI 機能自動化の一連のユースケースには追加されませんが、現在のバージョンでは、自動化は実際に非常に役立つ助けをもたらしており、これは私たちが提唱する必要があるものです。

つまり、さまざまな自動テスト ツールやテスト手法を使用してテストを支援できることは、評価に値します。

2. パフォーマンステスト

私が担当するプロジェクトのテスト体制では、主に時間軸でのパフォーマンステスト、時間軸でのパフォーマンステストの3次元でのパフォーマンステストが行​​われます。リソースのディメンションと流暢性テスト。

2.1 時間の次元

時間次元でのパフォーマンス テストは、主にクリック操作後の機能機能の時間応答を指します。私たちは、最初の画面の読み込み時間、クリック後の応答ジャンプの開始時間などに精通しています。

時間次元でパフォーマンス テストを実行するには、さまざまな方法があります。画面記録を使用して時間を計算したり、プログラム内のタイムスタンプを使用して時間を計算したり、サードパーティのスクリプトを使用して時間を計算したりすることもできます。時間、または画像認識を通じて可能 時間を計算する技術など

テスト プロセス中、プロジェクト自体と併せてツールに関する事前調査を行う必要があります。これは 1 回限りのテストでしょうか、それとも将来的に継続的なテストが必要ですか?その後の長期使用のためにツールに変換されますか? それは単一のデバイス上にありますか? それを使用するには、ツールがオープンソースであるか、その後の統合のためのデータ インターフェイスを提供するかにかかわらず、さまざまなデバイス環境で使用するための互換性を考慮する必要があります。チームのテスト プラットフォームなど。

2.2 リソース ディメンション

リソース ディメンションのパフォーマンス テストは、主に、CPU、メモリ、電力、トラフィックなど、APP の使用中のさまざまなシステム リソースの消費を指します。

テスト ツールの選択は、さまざまなテスト端末によって異なります。テスト中に監視する必要がある寸法もプロジェクトに基づいて決定されます。ここでは、具体的なテスト方法については説明しません。

ここで言及する必要があるのは、リソース ディメンションでのパフォーマンス テストでは、作業の 2 つの部分を実行できるということです。1 つはテスト プロセス中のパフォーマンス テストで、もう 1 つはオンライン パフォーマンス データの収集です。

テスト プロセス中のパフォーマンス テストは、ビジネス テストのニーズに基づいて評価できます。どのシナリオをテストする必要がありますか? 現在のバージョンの 1 回限りのテストですか? それとも後続の各バージョンの比較が必要なテストですか?このバージョンのみをテストする必要がありますか? マシンのパフォーマンス データを複数のデバイスで収集する必要があります。このアプリでテストするだけでよく、競合製品と比較してテストする必要があります。

これに基づいて、後で再利用するために自動スクリプトを使用してテスト ケースを実装する必要があるかどうかを評価します。その後、過去のバージョンとの長期的な比較テストが必要な場合は、テスト結果の信頼性を高めるために、テスト環境とテスト機器が可能な限り一貫していることを確認する必要があります。

もう 1 つ追加すべき小さな点は、テスト データの処理と計算が自動化されたスクリプトを通じて実現できるため、人的コンピューティング リソースのコストが節約できることです。必要に応じて、単純なプラットフォームを構築し、その後の分析や参照のためにすべてのテスト データをプラットフォームに保存することもできます。

オンライン パフォーマンス データを収集するには、開発エンジニアは機能の実装プロセス中に関連データを報告する必要があり、機能のリリース後は、オンライン データを取得、処理、計算して、潜在的な問題を発見する必要があります。開発エンジニアのログとエラーが発生したユーザーのログを連携することで、関連するパフォーマンスの問題の特定、分析、解決を実現できます。

2.3 流暢性テスト

ユーザー エクスペリエンスを最も直観的に感じるため、流暢性テストは多くのパフォーマンス テストでも必須です。流暢性テストの実行方法についてここで詳しく説明する必要はありませんが、注意する必要がある点がいくつかあります:

1 つ目は、流暢性テストのユースケースをどのように計画するかです。 2 つ目は、流暢性テスト後のテスト結果データを分析して改善するためにどのように使用するかです。3 つ目は、APP のリリース後にオンライン データから流暢性を監視する方法です。

流暢性テスト ケースの設計に関しては、APP のコア機能と共通のユーザー パスに基づいて設計する必要があります。単に考えるのではなく、この部分をサポートするオンライン データを用意することが最善です。それ。データのサポートによって取得された、APP 内のほとんどのユーザーのジャンプ パスに注目する必要があります。さらに、テスト プロセス中にオンライン データで監視される遅延が発生しやすいパスにも注意を払う必要があります。

流暢性テスト後のデータの分析と使用、およびオンライン流暢性データのモニタリングには、テスト エンジニアと開発エンジニアによる共同計画と共同調査が必要です。この記事では詳しく説明しません。

3. 安定性テスト

この部分については、アプリリリース前のテスト段階とリリース後のオンライン運用段階の2段階からスタートして、別々に働きます。

テスト段階では、Monkey テストとコード レビューを中心とした安定性テストを実行できます。資格のあるチームは、この段階で静的コード スキャン ツールを使用することもできます。モンキーテストでは、設備や環境、テストの頻度などに注意し、途中で発見された問題点をある程度分析し、問題が発生しやすい部分に注意を払う必要があります。コード ウォークスルーを、機能テスト中にクラッシュしやすいモジュールと組み合わせて、主要なウォークスルーを実行し、開発とペア プログラミングを促進し、これらのモジュールで発生する可能性のある問題をチェックすることができます。静的コード スキャンに関しては、開発学生はスキャンされた問題を解決し、関連する問題の漏洩を避けるために適切なコーディング習慣を身に付ける必要があります。

運用フェーズでは、外部ネットワーク クラッシュ データのレポートと分析に関する安定性テストを実施できます。この部分の解決は開発エンジニアに大きく依存しますが、このプロセス中に、テスト エンジニアは報告されたデータを分析し、一般的なシステムやモデルなどのクラッシュの基本データを特定して、日々の安定性を改善および最適化することができます。 。

以上がAndroid APP のテスト プロセスと一般的な問題は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。