what is infrastructure testing
このインフラストラクチャテストの包括的なガイドでは、その利点、課題、インフラストラクチャテストのツールと方法論について説明しています。
インフラストラクチャは多くのプロジェクトで共有されています。インフラストラクチャテストは、ソフトウェア製品の実行に必要なハードウェアとソフトウェアの依存関係のテストです。これは、ターゲットインフラストラクチャに関連する製品リスクをカバーするのに役立ちます。
このチュートリアルは、インフラストラクチャテストを最初から学ぶのに役立ちます。メリットと課題、実行できるユーザー、実行するタイミング、このテストを実行するための手法など、完全な詳細について説明します。このチュートリアルでは、インフラストラクチャテストツールについても説明します。
学習内容：
インフラストラクチャとは何ですか？
ITインフラストラクチャエコシステムには、オペレーティングシステムプラットフォーム（Windows、UNIX、Linux、macOSなど）、コンピュータハードウェアプラットフォーム（Dell、IBM、Sun、HP、Appleなど）、インターネットプラットフォーム（Apache、Cisco、Microsoft IIS、.NETなど）が含まれます。 ）、データ管理およびストレージ（IBM DB2、Oracle、SQL Server、MySQLなど）およびエンタープライズソフトウェアアプリケーション（SAP、Oracle、Microsoftなど）。
インフラストラクチャテストとは何ですか？
すべてのソフトウェアには、そのアクションを実行するためのインフラストラクチャが必要です。インフラストラクチャテストは、ハードウェア、ソフトウェア、およびネットワークを対象とするテストプロセスです。これには、ITフレームワークのさまざまなものから構成値を読み取り、それらを意図した結果と比較するコードのテストが含まれます。
失敗のリスクを軽減します。このテストには、テストの演習、ITアプリケーションと基本的なインフラストラクチャが、実行、適応性、揺るぎない品質、アクセシビリティ、パフォーマンス、およびスケーラビリティを実現するように調整されていることを保証する手順が組み込まれています。目的は、テスト環境、テストツール、およびオフィス環境の間のインフラストラクチャをテストすることです。
インフラストラクチャテストが必要な理由
組織は、ビジネスアプリケーションが完全にテストされていることを確認するために、多くの費用を費やしています。ただし、基本的な基盤、つまりこれらのアプリケーションをホストおよび伝達するインフラストラクチャは、時々テストされ、一般的に過小評価されています。
l1レベルのデスクトップサポートインタビューの質問と回答
ハードウェアまたはソフトウェアコンポーネントの障害のリスクを軽減するには、インフラストラクチャテストが必要です。ソフトウェアの新しいインフラストラクチャ設計が準備されると、このテストを実行する必要があります。新しいインフラストラクチャ機能が意図したとおりに機能しているかどうかを確認する必要があります。新しいインフラストラクチャモジュールがプロジェクトに統合されると、問題が発生する可能性が高くなります。
スケーラブルなインフラストラクチャでテストが計画されていない場合、インフラストラクチャの障害が発生します。したがって、混乱や土壇場での問題を防ぐために、このテストを実行する必要があります。
このテストは、さまざまなテストプロセスで効率的に検出されなかった欠陥を特定するために必要です。ハードウェアとソフトウェアのリソースが変更されるたびに、ソフトウェアアプリケーションを分析することが重要になります。これは、システムの効率とパフォーマンスを分析するために行われます。
プロジェクトはインフラストラクチャに高いコストを伴うため、このテストタイプのタイムリーな実装が必要です。したがって、プロジェクトのリスクに伴うコストを最小限に抑えるには、このテストに関する十分な知識が必要です。障害を回避するには、このテストが業界標準として必要です。
インフラストラクチャテストの利点は何ですか？
インフラストラクチャテストの計画的かつ徹底的なアプローチは、ソフトウェア製品だけでなく組織にも多くのメリットをもたらします。
以下に、いくつかのメリットを示します。
- 生産の失敗の減少。
- 生産実行前の欠陥識別の改善。欠陥のずれがゼロのインフラストラクチャの品質を本番環境にアップグレードします。
- テストの実行が迅速化され、早期の稼働が可能になります。
- これは、運用およびビジネスにおける年間コスト削減に役立ちます。
- ソフトウェアが体系的かつ制御された手順で動作することを確認します。
- ダウンタイムの削減。
- サービス品質の向上。
- 安定した環境の可用性。
- リスクに伴うコストの削減。
- より良いユーザーエクスペリエンス。
インフラストラクチャテストの課題
企業がインフラストラクチャテストを採用しようとするときに直面するいくつかの課題を見てみましょう。
＃1）リモート環境
テスト環境またはリソースは、地形的に離れた場所に配置されているため、テストチームは、機器、ハードウェアコンポーネント、ソフトウェアコンポーネント、ネットワークなどに関連する課題を管理するために、その地域のサポートグループに依存しています。特にチームが異なるタイムゾーンにある場合、遅延。
＃2）専任チームの不在
チーム間の知識の欠如は、このテストを実行するための主要な課題です。スケジュール、計画、カバレッジ、ステータスレポートなど、すべてのアクティビティに関連する情報を維持するには、専任のチームが必要です。
＃3）テスト環境問題の調査
多くの場合、テスト環境の問題は解決できず、調査が必要です。問題が解決するまで、関係するチームとの調整が必要です。
＃4）一箇所で環境を維持する
テスト環境の共通の保管場所、それらの古い互換性、および最新バージョンを維持することは、このテストを実行する際に大きな課題となります。すべてのバージョンの接続の詳細と構成は維持されません。
＃5）手作業
ツールが利用できないため、このテストに関連するアクティビティのほとんどは手作業を必要としません。これは人為的エラーとプロセスの遅延につながります。
＃6） インフラストラクチャテストの標準定義の欠如
ほとんどの人はまだ実装とプロセスに気づいていません。不適切な知識と理解は、しばしば実装の困難につながります。プロセスを安定させるために影響を与える可能性のある多くの新しい問題が発生します。
＃7）孤立したチーム
チームの場所の間には大きなギャップがあります。これは通常、透明性の欠如と不十分なチームワークにつながります。
インフラストラクチャテストを実行できるのは誰ですか？
このテストタイプには、さまざまなチームが関与しています。 これらについて以下に説明します。
＃1）インフラストラクチャテストチーム
インフラストラクチャテストチームには、このテストに関連する豊富な知識があります。彼らはまた、品質保証チームにも関わっています。このチームは、ITインフラストラクチャをテストする方法を知っています。このチームは、このタイプのテストのテストケースを設計する方法を知っています。
＃2）システム管理者チーム
システム管理者チームは、ネットワークレベルのインフラストラクチャをテストすることがよくあります。チームは、経験に基づいてテストケースを設計および文書化します。彼らは、ネットワークの変更後にアプリケーションが影響を受けないようにする責任があります。
＃3）インフラ整備チーム
このチームは非常に重要な役割を果たしています。彼らは早い段階で関与し、要件に従ってテスト環境を設定する責任があります。彼らは、インフラストラクチャ環境のテスト計画と保守に参加します。
＃4）品質保証チーム
QAチームは、回帰テストを実行する責任があります。また、統合テストにも関与しています。さまざまなインフラストラクチャごとに作成されたさまざまなテスト環境でテストを実行します。
＃5）プロジェクトマネージャー
プロジェクトマネージャーは、プロジェクトを処理する責任があります。彼らは、このテストタイプに必要なテストケースの計画、設計、文書化に関与しています。プロジェクトマネージャーはすべてのチームと同期しています。
インフラストラクチャテストをいつ実行するか？
インフラストラクチャ関連の変更が導入されるたびに、このテストを実行する緊急の必要性があります。
このような変更の例は次のとおりです。
- システム内の新しいパッチが開発されます。
- 新しいシステムアップデートが発生します。
- オペレーティングシステムの更新。
- データベースのバージョン/構造がアップグレードされます。
- サーバーのメモリのアップグレードがある場合。
- 新しいツールの実装。
- セキュリティ修正。
- ソフトウェアの更新。
データベースまたはデータセンターの移行が発生した場合、このテストタイプがより重要になることがあります。アプリケーションに多様で急速な変化があり、インフラストラクチャの移行が関係している場合は、さらに焦点を当てる必要があります。
また、ソフトウェア用の新しいデバイスのサポートが導入されたときにも実行されます。
例：
- 新しいラップトップ/デスクトップ
- 新しいモバイルデバイス
- 新しいサードパーティツール
インフラストラクチャテストの方法論
これにはさまざまなモジュールがあります。 それらのいくつかを以下に示します。
- サーバー/クライアントインフラストラクチャ
- データ移行
- クラウドでのインフラストラクチャテスト
- ネットワークレベルのテスト
- インストール/アンインストール/展開
- テスト環境インフラストラクチャ
- TDDアプローチ
＃1）サーバー/クライアントインフラストラクチャ
サーバーには、Webサーバー、ファイルサーバー、メールサーバー、プロキシサーバー、仮想サーバー、およびハードウェア上の物理サーバーが含まれます。クライアントには、OS、アプリケーション、ユーザー設定などが含まれます。サーバーはさまざまなサービスを実行し、これらのサービスはクライアントが使用できます。
主な目的は、サーバー、デスクトップ、オペレーティングシステム、およびハードウェアの品質をテストすることです。サーバー/クライアントコンポーネントは、本番環境でインフラストラクチャのパフォーマンスが向上することを確認するためにテストされます。また、アプリケーションのインストールまたはアンインストールのテスト、ブラウザーの互換性テスト、さまざまなバージョンのOSとの統合テストおよびユーザー設定も含まれます。
手順：
- 最も重要なことは、利害関係者から要件を収集することです。
- 必要なインフラストラクチャの理解に従って、テスト計画を設計します。
- 次に、オペレーティングシステムのサポート、アップグレードシナリオ、サーバー/クライアントインフラストラクチャテストの範囲、および機能テストをカバーするテストケースが設計されます。
- テストケースの承認後、QAチームは各シナリオと対応するテストケースを実行します。
アップグレード、構成の変更など、サーバー/クライアントに関連するすべての変更は、QAセットアップですでにテストされているため、本番環境で発生する可能性のある影響が少なくなります。また、本番環境にデプロイする前に、さまざまなOSバージョンがテストされます。さらに、本番環境で問題が発生した場合は、バックアップを確保するためにフォールバック手順が事前にテストされます。
＃2）データ移行
データ移行には、古いバージョンから新しいバージョンに移行されたデータ、あるサーバーから別のサーバーに移行されたデータ、および異なる構成に移行されたデータが含まれます。
データ移行テストの主な目的は、さまざまなバージョン、サーバー、新しいビルドでデータ移行をテストすることです。アプリケーションをテストして、移行による影響がないことを確認します。データ移行テストは、アプリケーションのパフォーマンスと遅延を検証するためにも実行されます。
手順：
- 移行の前後にアプリケーションをテストします。
- データ移行の前後にサーバーをテストして、変更が観察されないことを確認します。
- データ移行後、アプリケーションのパフォーマンスに変化が見られないことをテストします。
- さまざまなバージョンのデータベースでアプリケーションをテストします
- 新しいビルドがデータベースのすべてのバージョンと互換性があることをテストします。
- さまざまなデータベースバージョンでサーバーのさまざまな構成設定をテストします
データ移行テストの助けを借りて、サーバーの不一致構成を発見できます。データ移行の実行中にサーバービルドの問題が存在する場合は、運用展開の前に解決できます。データ移行テストは、製品の品質と安定性を向上させます。このテストは、後でアプリケーションを実稼働環境にデプロイする際のインストールテストに役立ちます。
＃3）クラウドでのインフラストラクチャテスト
情報とデータは主に仮想サーバーに保存され、これらのサーバーはAWSなどのクラウドコンピューティングベンダーによって維持および管理されます。
主な目的は、さまざまなバージョンのアプリケーションのクラウドサービスを認定することです。クラウド上のアプリケーションのアーキテクチャをテストします。実際のアプリケーションがクラウド上でシミュレートされ、アプリケーションのパフォーマンスとスケーラビリティがテストされます。
手順：
- さまざまな構成でアプリケーションの負荷をテストします。
- 回帰テストを実行し、アプリケーションが負荷テストに影響を与えないことを確認します。
- アプリケーションがクラウド環境で互換性のあるブラウザーであるかどうかをテストします。
- クラウドへのアプリケーションのインストールをテストします。
- さまざまなクラウド環境でアプリケーションが期待どおりに機能しているかどうかをテストします。
クラウドでのインフラストラクチャテストにより、本番環境でのアプリケーションのエラーのない実装が保証されます。これは、アプリケーションのパフォーマンス、スケーラビリティ、および安定性を知るのに役立ちます。ハードウェア、ソフトウェア、インフラストラクチャなど、クラウドにあるリソースを活用するのに役立ちます。
＃4）ネットワークレベルのテスト
ネットワークは、アプリケーションのインフラストラクチャの最も重要な部分です。ネットワークは、サーバー、クライアント、およびその他のネットワーク間の通信に役立ちます。ネットワークには、プロキシサーバー、インターネット接続用のインフラストラクチャなど、さまざまなモジュールがあります。
主な目的は、過剰なリソース使用量、サーバーのダウンタイム、システム構成、運用に必要なインフラストラクチャ、オペレーティングシステムのパッチなど、ネットワークレベルの問題を制御および管理することです。
手順：
- アプリケーションの将来の更新について、ネットワーク層をテストします。
- 実稼働環境で障害が発生した場合のフォールバック手順をテストします。
- システムテスト、UATテスト、セキュリティテストを実行します。
- テストケースを設計し、テストデータを準備します。
- 新しいリリース後にサーバー/ネットワークレベルのサービスが影響を受けないことを確認してください。
- 分離されたネットワークをテストします。
- VPN、Wi-Fi、LANなどのさまざまなネットワークでのアプリケーションのパフォーマンスへの影響をテストします。
ネットワークレベルのインフラストラクチャテストにより、回復時間が改善されます。これにより、バックアップと復元のメカニズムが保証されます。アプリケーションのセキュリティにも役立ちます。
＃5）インストール/アンインストール/展開
インストールの実行中にインフラストラクチャをテストする主な目的は、新しいクライアントがアプリケーションを使用するときはいつでも、アプリケーションを初めてインストールするときに問題が発生しないことを確認することです。アプリケーションのアンインストールは、アプリケーションの終了プロセスをテストするために実行されます。
経験豊富な人のための手動テスト面接の質問と回答
手順：
- アプリケーションのインストールに必要なインストーラーパッケージをテストします。
- 追加のライブラリをテストし、パッケージをビルドします。
- アプリケーションのインストールとアンインストールに必要な時間をテストします。
- 別のオペレーティングシステムにアプリケーションをインストールします。
- 必要なディスク容量をテストします。
- アプリケーションのアンインストール後にすべてのファイルが削除されるかどうかをテストします。
インストール/アンインストール/展開中にインフラストラクチャをテストすることで、特定の時間にアプリケーションをネットワーク経由でインストールできることを確認します。パッチを後でインストールできるかどうかを確認します。アプリケーションに必要なストレージの改善に役立ちます。
＃6）テスト環境インフラストラクチャ
テスト環境は、ハードウェア、ソフトウェア、ツール、およびプロセスのコレクションです。テストを正確かつ効率的に実行するには、テスト環境が必要です。テスト環境には、テスターが仕事を遂行するために適切なネットワーク、PC、および電源が提供される職場も含まれます。
主な目的は、ソフトウェアのインストール、アプリケーション構成のセットアップを確認し、テスト計画、テスト実行をサポートする適切なテストツールを選択することです。また、テスト実行の継続性も保証します。
手順：
- プロジェクトの定期リリース用のテスト環境をセットアップします。
- ホットフィックスリリースのテスト環境を作成します。
- サーバーおよびクライアント環境の問題を管理するためのソリューションを作成します。
- テスト計画、テスト設計、および実行のためのテストツールを完成させます。
- バグをデバッグおよび報告するためのツールを決定します。
- テスト環境を設定するためのドキュメントを作成します。
ツールとテスト環境の使用には、複数の利点があります。より高い品質が観察されます。ツールを使用すると、生産性が向上します。テスト活動は、処理された方法で実行されます。テスト環境のドキュメントは、チームの新しいメンバーがよりよく理解するのに役立ちます。
＃7）TDDアプローチ
テスト駆動開発またはTDDフレームワークは、最初に要件ドキュメントに基づいてテストケースを記述し、次にテストに従って機能を実装する方法です。
主な目的は、プロジェクトに必要なインフラストラクチャリソースを知ることです。目的は、セキュリティ、運用、および本番用のインフラストラクチャを定義および編成することです。
手順：
- インフラストラクチャ要件の設計ドキュメント。
- アプリケーションに必要なインフラストラクチャをカバーするテスト計画を設計します。
- インフラストラクチャテストを含むテストケースを設計します。
- さまざまな構成をテストします。
TDDアプローチは、プロジェクトの複雑さを改善するのに役立ちます。インフラストラクチャへの変更は、本番環境にプッシュする前にテストされます。テストはすでに設計されているため、さまざまな可能な構成を実装できます。
インフラストラクチャテストツール
シェフ、パペット、 そして Ansible 同じ目的を果たすさまざまなツールです。これらのツールは、アプリケーションに必要なさまざまなサーバーの展開と構成に使用されます。これらのツールは、インフラストラクチャに関連する複雑なタスクがある場合に非常に役立ちます。チームは、これらのツールを使用して、複数のサーバーでタスクを一緒に実行することが容易になります。
これらのツールを使用するチームは、複数のアプリケーション、依存関係、およびライブラリを迅速に展開します。その他のアクティビティには、サーバー、バイナリ、ログファイル、回復メカニズム、バージョンのアップグレード、データベース管理が含まれます。
＃1）シェフ
特徴： ChefはRubyドメイン固有言語をサポートしています。したがって、開発者以外の人がこのツールを学ぶことは困難になります。言語サポートは困難ですが、このツールは可用性が高くなっています。 Chefは、マスタースレーブ構成に従います。マスタースレーブメカニズムでは、いずれにせよ障害が発生した場合に、プライマリサーバー（chef-server）をバックアップサーバーに置き換えることができます。
アプリケーションをデプロイし、インフラストラクチャを構成し、Chefを使用してネットワークを構成することもできます。高度なセキュリティは確保されていません。
価格： Puppetよりも安価ですが、Ansibleよりも高価です。その価格は、100ノードまで約$ 13.5k /年です。
ウェブサイト： チーフ
＃2）人形
特徴： PuppetはRubyで構築されており、DSLとEmbeddedRubyをサポートしています。プログラマーは、Puppetを使用するように選択した場合にのみ、構成を管理できます。システム管理者チームは、このツールの構成も認識しています。マスターマスターアーキテクチャに従います。アクティブなマスターで障害が発生した場合、別のマスターで置き換えることができます。
Puppetは、ホストごとに異なる構成を設定する際に、マシンのスケーラビリティに役立ちます。構成に変更が加えられた場合、このツールはグローバルに変更を加えるのに役立ちます。また、それほど安全性の高いツールではありません。
価格： その価格は、最大100ノードで年間約11,000ドルから2万ドルと最も高くなっています。
ウェブサイト： 傀儡
＃3）Ansible
特徴： AnsibleはPythonで記述されており、YAMLコマンドスクリプトもサポートしています。 Pythonは人間が読める形式であるため、このツールはシステム管理者にとって理想的です。単一のアクティブノードで実行されますが、障害が発生した場合は、セカンダリノードもあります。
Ansibleは非常にスケーラブルです。つまり、問題なく多数のノードを管理できます。 Puppetと比較して、Ansibleはスケーラビリティの点でより便利です。 ChefやPuppetとは異なり、SSHを使用した安全性の高いツールです。
価格： その価格は、最大100ノードでPuppetやChefよりもはるかに年間約1万ドル低くなっています。
ウェブサイト： Ansible
結論
企業はインフラストラクチャに高いコストを負担するため、ソフトウェア開発ライフサイクルにはインフラストラクチャテストが必要です。このチュートリアルでは、メリット、課題、テクニック、このテストタイプに関係する人々などのさまざまなトピックについて説明します。インフラストラクチャテストツールの概要についても説明します。