インストーラーのテスト。 理論

ソフトウェアインストールテストは、ソフトウェアの更新または削除だけでなく、正常なインストールと構成の検証を目的としています。

現時点では、インストーラー（それ自体も適切なテストを必要とする特別なプログラム）を使用した最も一般的なソフトウェアのインストール。



実際の状況では、インストーラーはそうではない場合があります。 この場合、指示またはreadmeファイルの形式のドキュメントを使用して、必要なすべてのアクションとチェックを段階的に説明するソフトウェアを個別にインストールする必要があります。



すでに実行されている環境にアプリケーションがデプロイされている分散システムでは、単純な一連の指示では不十分な場合があります。 これを行うには、多くの場合、アプリケーションのインストール手順だけでなく、障害が発生した場合の前のバージョンへのロールバック手順を含む展開計画が作成されます。 インストール計画自体も、試運転中の問題を回避するためにテスト手順を実行する必要があります。 これは、ダウンタイムの1分ごとに評判が失われ、大量の資金があるシステム（銀行、金融会社、バナーネットワークなど）でインストールが実行される場合に特に当てはまります。 したがって、インストーラのテストは、ソフトウェアの品質を確保するための最も重要なタスクの1つと呼ぶことができます。



これは、計画の作成、インストールの段階的な検証、およびインストールのロールバックとの統合アプローチであり、インストールテストまたはインストールテストと呼ぶことができます。



カットの下には、テスト中に何を覚えておくべきかについてのテキストがたくさんあります。

テストインストーラーの機能：

インストーラーは、ソフトウェアのインストール（インストール）、更新と削除（アンインストール）を主な機能とする「通常の」プログラムです。

誰もが一般的な知恵を知っています。「 彼らは衣服で迎えられますが、心で護衛されます 。」 インストールアプリケーションは、製品の第一印象を作り出す衣服そのものです。 そのため、インストールテストが最も重要なタスクの1つです。



通常のプログラムであるインストーラーには、次のような多くの機能があります。

●オペレーティングシステムとの深い相互作用とその依存関係（ファイルシステム、レジストリ、サービス、ライブラリ）。

●ネイティブおよびサードパーティのライブラリ、コンポーネント、またはドライバーの、異なるプラットフォームとの互換性。

●使いやすさ：直感的なインターフェイス、ナビゲーション、メッセージ、ヒント。

●インストールアプリケーションの設計とスタイル。

●アプリケーションの異なるバージョンのユーザー設定とドキュメントの互換性。

●その他。



これらの機能がインストールプログラムのテストに真剣に取り組んでいない場合は、インストーラーの正しい操作の重要性を示すリスクの小さなリストを示します。

●ユーザーデータの損失のリスク。

●オペレーティングシステムがクラッシュするリスク。

●アプリケーションの動作不能のリスク。

●アプリケーションの誤動作のリスク。



同時に、他のプログラムと同様に、インストーラーにはいくつかの機能要件が課せられます。 それらを機能のリストと組み合わせて、今後のテスト作業の量を示すより完全な図を取得します。 さらに、要件のリストに基づいて、次の質問に答える必要があります。「何をテストしますか？」、そしてその後だけ-「どのようにテストしますか？」。



現代の豊富なパーソナルコンピュータ、サーバー、およびオペレーティングシステムでは、異なるプラットフォームに同じソフトウェアをインストールする必要があります。 このため、インストーラーは、環境に応じてインストールする場所と場所を理解する必要があります。

インストールプログラムで何をテストしますか？

さらに詳細に「 何 ？」と書きます。 インストーラーの正しい動作を評価するために確認する必要があります。

●インストール（インストール）。

●インストールパッケージ内のファイルリストの正確性：

さまざまな種類のインストールまたはインストールパラメータを選択すると、ファイルのリストとそのパスも異なる場合があります。

不要なファイルが存在しない（インストールパッケージに含まれていないプロジェクトファイルがユーザーのディスクに到達しないようにする）。

●OSへのアプリケーションの登録。

●ファイルを操作するための拡張子を登録します。

新しい拡張機能。

既存の拡張機能用。

●アプリケーションを配置するユーザーのアクセス権：

システムレジストリを操作する権利。

ファイルおよびフォルダーのアクセス許可（ ％Windir％\ system32など） 。

●インストールウィザード（インストールウィザード）の正確さ。

●複数のアプリケーションを一度にインストールします。

●同じワークステーションの異なる作業ディレクトリに同じアプリケーションをインストールします。

●アップデート。

●ファイルリストの正確さ、および余分なファイルがないこと：

さまざまなインストールパラメータでファイルのリストを確認します。

余分なファイルの不足。

●生成されたデータの下位互換性：

更新前に作成されたデータの安全性と正しい操作。

新しいバージョンで作成されたデータを使用して、古いバージョンのアプリケーションを正しく機能させる能力。

●アプリケーションの実行中に更新します。

●更新を中止します。

●アンインストール（アンインストール）。

●アプリケーションの正しい削除：

インストールプロセス中にインストールされたライブラリおよびサービスレコードのシステムレジストリからの削除。

物理アプリケーションファイルを削除する

以前のファイルの関連付けを削除/復元します。

アプリケーションでの作業中に作成されたファイルの安全性。

アプリケーション実行中の削除。

アプリケーションフォルダへのアクセスを制限してアンインストールします。

適切な権限のないユーザーによる削除。

インストールをテストする方法は？

ファイルのリストを取得する前に、ファイル自体を確認する必要があります-インストール後。

最も正しいのは、インストールパッケージインストーラーからファイルの一覧を取得することです。 「ソフトウェアをインストールした後にリストを作成して作成してください。すべてがそこにあります」というフレーズは挑発であり、それに屈しない方がよいでしょう。

プログラムに、たとえばMSからの証明書によって署名されたファイルが含まれている場合、アプリケーションが動作するのに必要ではなくなった一時ファイル（* .tmpなど）が見つかる可能性があります。 同じインストールパッケージで、異なるオペレーティングシステムの下に異なるファイルセットをインストールできることに注意してください。 したがって、テストはOSごとに個別に行う必要があります。



ほとんどすべてのOSで、作業ライブラリとサービスレコードを登録することが重要です。 たとえば、Windowsでは、システムレジストリをチェックして、新しいデータを正しく記録し、新しい/新しいアプリケーションを登録する必要があります。

プログラムが動作するように設計されているドキュメントを開くときに、このタイプのファイルを開くプログラムを選択するダイアログが表示されるか、別のアプリケーションによって開かれる場合、拡張機能をOSに登録するときにエラーが発生します。



良い方法では、インストールプログラムは最初にユーザーアカウントをチェックし、権利の問題を直ちに正しく報告する必要があります。 ただし、サービスフォルダーに追加の制限がインストールされるというオプションは除外されません。 たとえば、「 \ Program Files 」、「 \ Windows 」、「 ％Windir％\ system32 」などのフォルダーのいずれかが書き込みのために閉じられている場合、自分で状況をシミュレートし、書き込みが不可能な場合のアプリケーションの動作を確認することもできます正しいパス上のファイル。 一部のファイルがなければ、アプリケーション全体の機能が影響を受けない可能性があります。 この場合、ファイルをログにコピーする際の問題を示すだけで十分であり、エラーメッセージを表示しないでください。



アプリケーションのインストールウィザードの完全なテストを実施する必要があります。

アプリケーションは、それ自体とは別に、別の製品を配置する場合がよくあります。 個別のサードパーティアプリケーションまたは独自の製品のデモのいずれかです。 通常、インストールプロセス中、これはインストールウィザードの別の一連のステップではなく、そのような製品がインストールされていることを示す小さなメッセージです。 テスト中、いくつかの製品が一貫してインストールされているという事実に特に注意を払う必要があります。 それらの1つがインストール後に再起動を必要とする場合、特にドライバーがシステムのあちこちに深く配置されている場合、2つ目は正しくインストールされない可能性があります。 興味深いのは、2つのアプリケーションのインストールの接合部で正確に発生するエラーです。

同じワークステーションの異なる作業ディレクトリにインストールできるアプリケーションがありますが、同時に競合状態を引き起こすことなく、互いに独立して動作します。 しかし、これは常にそうではありません。 ディスク、メモリ、システムの共有リソースへのアクセスと競合する可能性があります。 これらはすべて、最も徹底的な方法でテストする必要があります。

更新する

下位互換性テストには次の手順が含まれます。

●更新プログラムのインストール後、ドキュメント、フォーム、保存（ゲームの場合）など、アプリケーションによって以前に作成されたすべてのオブジェクトが開き、エラーなく動作するはずです。 この動作は下位互換性と呼ばれます。 もちろん、更新が変更に影響しなかった場合、ユーザー設定は同じままにする必要があります。

●もちろん、更新の目的がファイル形式と構造を変更することではない場合、新しいバージョンで作成された同じタイプのドキュメントは古いバージョンで正しく開く必要があります。 新しい形式が導入されている場合、新しいバージョンにはドキュメントを古い形式で保存する機能が必要です。

●更新されたアプリケーションが実行されている場合、ユーザーはアプリケーションの実行中に更新ができないという警告を受け取る必要があります。



更新プロセスはいつでも停止できますが、元のアプリケーションは変更せずに動作状態に維持する必要があります。 バージョン1をインストール済みで、バージョン2にアップグレードしようとしているが、気が変わってインストールプロセスが中断したとします。 この場合、インストーラーはすでに行われたすべての変更を返し、更新に使用された一時ファイルを消去し、作業を完了する必要があります。 ただし、バージョン1アプリケーションは引き続き動作します。

削除（アンインストール）

インストールプロセス中に作成されたもの（システムレジストリ内のレジストリエントリ、 ％Windir％\ system32システムディレクトリ内のライブラリ、ファイルなど）を削除することをお勧めします。 条件付きで、アンインストールのテストプロセスはいくつかの部分に分けることができます。

●インストール中にインストールされたシステムレジストリエントリ、サービスレコード、およびライブラリリンクがシステムレジストリから削除されていることを確認します。

●アプリケーションファイルの物理的な削除を確認します。

●アプリケーションをアンインストールした後、インストール中に登録されたファイル拡張子が削除され、既存のもの（インストール前に登録されたもの）が復元されることを確認します。

●アプリケーションでの作業中に作成されたデータの安全性を確認します。 プログラム自体のカタログのどこか深いところにある可能性があります。 これは、ゲームまたはその他のユーザー作成データから保存するサービススクリプトであり、削除するとユーザーに損害を与える可能性があります。 MS Officeをアンインストールすると、すべてのドキュメントが一緒に削除されることを想像してください。 したがって、このようなデータはユーザーの確認なしに削除することはできません。

●アンインストールされたアプリケーションが実行されている場合、ユーザーはアプリケーションの実行中にアンインストールができないという警告を受け取る必要があります。



プログラムディレクトリがアクセス権によって削除のために閉じられている場合、インストーラの動作を確認する価値があります。 この場合、削除プロセスは実行されず、ユーザーは適切なメッセージを受信する必要があります。

インストールウィザードのテスト

ほとんどの場合、インストーラーはウィザード形式のアプリケーションであり、特定の要件があります。テストの推奨事項については以下で説明します。



賢い人々はこう書いた：「魔法使いは悪だ。」 これに同意することも同意しないこともできますが、まだテストする必要があります。 インストールウィザードの次のテスト計画が提案されます。

●最初から最後までのすべてのパスを特定し、各パスに優先順位を付けます。 これにより、優先度の低いルートを通過する際の不必要なコストと労力を回避できます。

●GUIを忘れてください。 インターフェイス要素に縛られることなく、テストケースを記述してください。 たとえば、チェックボックス/ラジオボタンのGUIコントロールまたは2項目メニューは、trueとfalseの間の選択にすぎません。重要なのは、最終的に影響するものです。

●ウィザードの合格結果に従って、ファイル（リストの形式でプロパティを説明するファイル：property = value）を取得し、それをエクスポート手順に渡す場合、この場合、チェックを2つの段階に分割することができます。ファイルを消去し、エクスポートが正しく機能していることを確認します。 2番目は、GUIを介して正しいファイルが取得されたことを確認することです。

●ページを行ったり来たりするような、通常のタイプのテストウィザードを実行することを忘れないでください。

何も変更せずに、すべての回答を保存する必要があります。 前のページで何かを変更した場合、次のページでは適切な変更または回答のリセットを行う必要があります。

●ウィザードが間違った答えに適切に応答し、先へ進むことができないことを確認します。

●キャンセル（閉じる）ボタンは、ウィザードのすべてのページで常に機能するはずです。

●インストールウィザードの可能なパスごとにテンプレート結果を作成します（理想的には、異なる入力データ用に複数のパスを作成します）。 次に、可能であれば、自動または手動で結果をテンプレートの結果と比較します。

●他に影響を与えないオプション、および他に影響を与えないオプションを強調表示します。 これらのオプションの動作は、他のオプションから分離してテストできます。

インストーラーのクロスプラットフォームテスト

強調したい別のポイントは、インストーラーのクロスプラットフォームテストです。これは、インストール、更新、および削除の3つの機能すべてに対して実行する必要があります。

●インストーラーは、さまざまなOSバージョン、サービスパック、インストールされた更新プログラムで正常に動作しています。

●異なるOSでインストールする場合、ファイル、ドライバー、およびライブラリを確認します。

●さまざまなオペレーティングシステムのファイル、フォルダー、およびシステムレコードへのアクセス権を確認します。

●アプリケーションファイルに設定されている権限を確認します。



テスト手順を簡素化するために、必要な構成が列に配置されるテーブル、およびテストラインの下のテストケースまたは関数を作成することをお勧めします。 列と行の交差点でテストするプロセスでは、結果を記入します。これにより、テストの進捗状況と「クロスプラットフォーム」要件への準拠を視覚的に表示できます。



アプリケーションが複数のOSで動作する必要がある場合、インストーラーはその作業の過程で必要な一連の機能を確認する必要があります。 ある種のサービスパックをどこかにインストールするか、別のライブラリを使用する必要がある可能性があります。

ケーススタディ：「Windows Vistaへのインストールでは、アプリケーションを閉じる必要があります。 起動すると、プログラムはこのバージョンがこのOSでは動作しないというメッセージを考えて表示します。 そうです、[OK]をクリックします。 その後、コンピューターは数秒間考えて、次を報告します。「アプリケーションが正しく完了しませんでした。 互換モードで実行してみましょうか？ 私たちのアプリケーションは再び自動的に起動しますが、今回は「バタンと」配置されます。 Vistaの機能と方法はわかりませんが、セキュリティコードをやり直す必要がありました。」



ドライバーとライブラリーのインストールに関して、インストールされたファイルのリストの確認は類推によって実行され、このチェックの特定の重要性に注意する必要があります。 すべてのドライバーとライブラリーが異なるプラットフォームで同等に機能するわけではありません。

ケーススタディ：「一部のドライバーでは、OSが実行されているファイルシステムに依存しています。 より正確には、いくつかのタイプのエラー。 NTFSではすべてが正常に機能するが、FAT32では正常に機能しない場合がありました。 理由は、レジストリにドライバーをインストールするときの無効なエントリでした。

インストーラーがファイル、フォルダー、およびシステムレコードへのアクセス権を持っていることを確認する必要があります。 これは、UNIXファミリーのOSでインストールする場合に特に重要であり、さまざまなカテゴリーのユーザーのリソースへのアクセスが厳しく制限されています。 UNIXシステムへのインストール時/後に、ファイルに適切な権限が必要です。 つまり ファイルが実行するように設計されている場合、実行可能になっている必要があります。たとえば、構成ファイルの場合、変更などの許可が必要です。

---

私の友達のアイデアはダートスです。