アプリ手動テスト学習

1. アプリ試験の基礎知識

1.1 APP アプリケーション システムのアーキテクチャ

ここに画像の説明を挿入

アプリとウェブの類似点と相違点

類似点:
(1) APP と Web のバックエンド サーバーは同じです
(2) フロント エンドとバック エンドの両方が対話に HTTP プロトコルを使用します (一部の APP は対話にソケットも使用します)
相違点:
(1) APP は C /S アーキテクチャ、および Web B/S 構造です
(2) APP を使用する場合は、ダウンロードしてインストールする必要があります アップグレードする必要がある新しいバージョンがあります Web はブラウザで直接アクセスできます。また、この更新では、ユーザーがアップグレードする必要はありません

1.2APP プロジェクト環境とリリース プラットフォーム

(1) 開発環境
(2) テスト環境
(3) プレリリース環境: 本番環境のデータベース (新しいコード + オンライン データベース) に接続して
基本的なビジネスをテストします; アップグレードがデータベース構造の変更を伴う場合は、実稼働環境のデータは、テスト用にテスト データベースにバックアップする必要があります; データ操作の書き込みに関しては、独自のテスト アカウントを使用する必要があり、オンライン ユーザーの実際のアカウントを使用することはできません (4) グレースケール リリース
戦略:
グレースケール リリース: プロジェクトがオンラインで展開される場合、複数のインスタンスがあります。マシンが実行されているため、新しい機能が正常かどうかを確認するために、1 ~ 3 台のグレースケール マシン (トラフィックの一部をグレースケール マシンに転送) があります。失敗した場合は、いくつかをロールバックするだけで済みます。これはより便利な
戦略です。グレースケール マシンが多すぎないようにする必要があります。グレースケール時間は通常 1 週間から 1 か月続きます。グレースケール リリースはマシンに影響しません。ユーザーの使用; 操作に問題がある場合は、問題を修正します。問題が深刻な場合は、コードをロールバックして、オンライン ユーザーが正常に使用できるようにする必要があります。操作に問題がない場合は、他のサーバーを更新します。 (5) 本番環境アプリケーションのオンライン公開プロセス:
テスト
完了 - レビューのためにアプリ マーケット (アプリ ストア、モバイル アプリ ストア、APP ストア) にアプリ パッケージを提出します。各 APP パッケージへのプラットフォーム チャネル番号 - プラットフォーム番号をテスト用の対応する APP パッケージにパッケージ化 - リリースのために正式に提出

1.3APP アジャイル開発モデル

ウォーターフォール モデル:

要件分析 - 要約関与 - 詳細設計 - コーディング - テスト - 運用と保守
特徴: 長い開発サイクル、遅い反復速度、変化するニーズに適応できない

アジャイル開発モデル

ユーザーニーズの進化を核として、ソフトウェア開発は段階的かつ反復的に行われ、プロジェクトは
複数のサブプロジェクトに分割され、各サブプロジェクトは個別にリリースされ、早期に使用できるようになります。タイムリーにユーザーからのフィードバックを収集し、リリースされていないプロジェクトを調整してユーザーを満足させます。

代表的なアジャイル開発フレームワーク:スクラム

ここに画像の説明を挿入

役割:
プロダクト オーナー プロジェクト マネージャー (現在のプロジェクトの調整と調整) 開発チーム (開発、テスト、UI)
開発プロセス:
プロダクト オーナーが要件を収集 - 出力するプロダクト機能リスト - 計画会議を開催する (優先度の高い機能をレビューする) - イテレーション (要件レビュー、開発、テスト、毎日のスタンドアップ ミーティング) - 反省会 (問題のレビュー、フォローアップ計画)

1.4APP アプリケーションのテスト プロセス (1 回の繰り返し)

ここに画像の説明を挿入

2.APPテストプロジェクト実戦

2.1 APP アプリケーションのテストのポイント

2.2 ビジネス機能テスト

2.3 互換性テスト

2.4 インストール、アンインストール、およびアップグレードのテスト

2.5 クロスイベントテスト

2.6プッシュメッセージテスト

2.7 性能試験

おすすめ

転載: blog.csdn.net/Ambition_ZM/article/details/129916342