types migration testing
移行テストの種類：
これは 第2部チュートリアル 私たちの中で データ移行テストチュートリアル シリーズ。
移行テストは、データを損失することなくレガシーシステムから新しいシステムにデータを移動するために不可欠であり、移行テストにもいくつかの種類があります。
このチュートリアルを通じて、IT業界でリアルタイムで頻繁に発生する移行テストの種類について詳しく教えてください。
学習内容：
移行の種類
以下は、通常非常に頻繁に発生するさまざまなタイプの移行です。
- アプリケーションの移行
- データベースの移行
- サーバーの移行
- OSの移行
移行テストのアプローチ、戦略、テストのフェーズに関する限り、それは私たちが私たちで学んだことと同じです チュートリアル＃1 。
チュートリアル1の各移行テストフェーズでカバーする必要がある一般的なテストシナリオである「移行テスト」に加えて、使用している移行タイプに固有の特定の検証も実行する必要があります。
以下に示すのは、上記の各タイプの移行に対して効率的な移行テストを保証するために追加のテストを実行する必要がある場合の特定の領域です。
＃1）アプリケーションの移行
アプリケーション移行は、アプリケーション全体をある環境またはプラットフォームから別の環境またはプラットフォームに移行するタイプです。
アプリケーション移行のいくつかの利点を以下に示します（新しいアプリケーションによって異なります）。
- 運用および保守コストを削減します
- 他のシステムへの依存を減らします
- ビジネスにおけるリスクを排除または軽減します
- システムのパフォーマンスを向上させます
- テクニカルサポートと管理を強化します
- 追加機能とバグ修正（ある場合）をサポートします
- テクノロジーの変化
アプリケーション移行の簡単な表現：
アプリケーション移行のいくつかの例：
- アプリケーションをに移行する クラウドプラットフォーム
- アプリケーションをASPからASP.Netテクノロジ、ASP.NetからWindowsAzureテクノロジなどに移行します。
ここでのテストアクティビティは次のとおりです。
- 要件を分析し、安定した要件を特定する
- テストの範囲を分析する
- 新しいアプリケーションに対してレガシーアプリケーションのすべてのフローを分析およびテストします
- 移行されたアプリケーションで新しいフローがある場合はテストします
一般に、テストシナリオは次のようになります。
私） アプリケーションがアップグレードされた場合、
- アップグレードされた機能とともに、以前のすべての機能を検証します–すべてが正しく機能するはずです
- 既存のデータと新しいデータについてアプリケーションをテストします。どちらも正しく機能するはずです。
- 例： 既存のデータを更新し、既存のデータを削除し、既存のデータを検索し、既存のデータのレポートを生成してみてください。新しいデータを使用して、アカウント/データの作成を検証し、新しく追加されたデータを更新し、新しく追加されたデータを削除し、新しく追加されたデータで検索し、新しく追加されたデータのレポートを生成します
II） アプリケーションを新しいテクノロジーに移行する場合：
ソフトウェアテストのテスト計画とは
- アプリケーション全体が正しく機能するかどうかを確認します
- 新しいテクノロジーが引き続きアプリケーションのすべてのコンポーネントをサポートしているかどうかを確認します。 例えば 、 プラグイン/アドオン/環境値/パスは変更されず、エラーなしで正しく機能するはずです。
- 考えられるすべてのオペレーティングシステム、ブラウザバージョンなどと互換性があるかどうかを確認します。
- 古いデータがアプリケーションに保持され、新しいデータが新しいテクノロジーで正常に機能するかどうかを確認します
＃2）データベースの移行
データベース移行は、アプリケーションのデータベース内のすべてのデータが別のデータベースに移行されるタイプの移行です。
このタイプの移行では、アプリケーションが安定していて、データベース内のデータが正しく有効である必要があります。したがって、データベース間を移行する際には、形式、タイプ、値などが重要になります。
データベース移行のいくつかの利点を以下に示します（新しいデータベースによって異なります）。
- アプリケーションは、膨大な顧客データをサポートするために、バックエンドに複数のデータベースを持つことができます
- データの強化を実現できます
- データの適切な分析は、データ品質の向上に役立ちます
- データサンプリングとデータクレンジングは、データベースをクリーンで効果的に保つのに役立ちます
- データ分析を実行するには
データベース移行のいくつかの例：
- あるRDBMSから別のRDBMSへの移行
- RDBMSからMongoDBへの移行
- InformixHC4からHC6またはHC7へのアップグレード
ここでのテストアクティビティは次のとおりです。
- 移行後のテスト中にレガシーデータベースが更新されていないことを確認します
- フィールドレベルとテーブルレベルでのマッピングが変更されていないことを確認します
- データが正確かつ完全に移行されているかどうかを確認する
- 移行前および移行後のテストアクティビティ
一般に、テストシナリオは次のようになります。
私） 同じタイプのデータベースへの移行の場合、、
- 新しいデータベースで実行されたクエリが古いデータベースと同じ結果をもたらすかどうかを確認します
- 古いデータベースと新しいデータベースのレコード数が同じであるかどうかを確認します。ここでは適切な自動化ツールを使用します
- 冗長性がなく、新しいデータベースが古いデータベースとまったく同じように機能することを確認します
- スキーマ、関係、テーブル構造が変更されていないか、古いデータベースイメージと一致するように設定されているかどうかを確認します
- アプリケーションで行われた変更が新しいデータベースを正しい値とタイプで更新するかどうかを確認します
- 新しいデータベース接続がアプリケーションのすべてのコンポーネントに提供された後かどうかを確認します。アプリケーション、サーバー、インターフェース、ファイアウォール、ネットワーク接続など。
- 新しいデータベースのクエリパフォーマンス（複雑なクエリの実行にかかる時間）が以前のパフォーマンスを超えていないことを確認します
II） 移行が異なるタイプのデータベースである場合、上記の検証ポイントに加えて、いくつかまたはそれ以上の注意を払う必要があります。
- すべてのフィールドのデータ処理を確認します。主な課題は、カレンダーの日付、浮動小数点数、16進数などのデータの処理です。
＃3）サーバーの移行
サーバー移行は、サーバーデータをあるサーバーから別のサーバーに移動する移行の一種です。ここで、構成もサーバーデータとともに新しいサーバーに移行されます。
サーバー移行のいくつかの利点を以下に示します（新しいサーバーによって異なります）。
- 強化された構成
- 信頼性の向上
- ログがより明確になると、コンポーネント間の要求/応答の分析に役立ちます
- 強化されたパフォーマンス
サーバー移行の簡単な表現：
サーバー移行の例：
- Windowsからメインフレームサーバーへの移行
- HPBoxからIBMBoxへ
ここでのテストアクティビティは次のとおりです。
- 新しいサーバーへの準拠のテスト
- 新しいサーバーでのデータ処理のテスト
- ディレクトリ名、ファイル共有などが変更されていないことを確認するか、構成に従って手動で変更します
- 新しいサーバーでデータの破損や変更がないことを確認します
一般に、テストシナリオは次のようになります。
- APIを介してアプリケーションとサーバー間の要求応答を確認します
- アプリケーションで実行されたすべてのアクションのクライアントサーバーログを確認します
- システム全体がテストに合格するかどうかを確認します
- すべてのテスト条件下でインターフェイステストが正常に機能しているかどうかを確認します
- 環境が安定していて、その環境でホストされているサーバーに接続に問題がないかどうかを確認します。つまり、移行後に環境問題が発生しないようにする必要があります
＃4）OSの移行
OS移行は、アプリケーションをあるオペレーティングシステムから別のオペレーティングシステムに移行するタイプの移行です。ベースプラットフォーム自体が変更され、互換性の大きなリスクがあるため、これには多くの課題が伴います。ネットワーク、構成、インターフェイス、およびその他の多くのコンポーネントでさえ、再設計が必要です。
OS移行のいくつかの利点を以下に示します（新しいOSによって異なります）。
- クラウドベースのプラットフォームに移行した場合の仮想化の向上
- 運用および保守の低コスト
- スピード、サポート、生産性、セキュリティの向上
OS移行の簡単な表現：
OS移行の例：
- WindowsからLinuxへの移行
- WindowsからMACへの移行
- サーバーとしてのクラウドベースのソフトウェアへの移行（ SaaS ）
- クラウドベースのVMなどへの移行。
ここでのテストアクティビティは次のとおりです。
- 新しいOSの依存関係を分析する
- 構成の変更がアプリケーションのタイプに応じて影響を与えるため、アプリケーションを理解してテストする
- 従来のOSと比較すると、アプリケーションのフローが異なる場合があります。したがって、広範なテストが必要です
- 新しいOSで可能なすべての組み合わせによる広範な互換性テスト
一般に、テストシナリオは次のようになります。
- アプリケーションがスタンドアロンの場合のハードウェアとソフトウェアの互換性を確認する
- OSの値がアプリケーションの動作に影響を与えないことを確認します。システム全体のテストに合格する必要があります
- 新しいOSでアプリケーションのパフォーマンスが妨げられていないかどうかを確認します
結論
したがって、発生している移行のタイプと、移行のタイプに基づいてテストする特定の側面を特定することで、発生する可能性のあるすべてのボトルネックを確認できます。
移行または移行後のいずれかは、ラボでのテスト中に事前に特定でき、それらを修正することで軽減でき、「 移行 '。
以下のコメント、質問、考えを共有してください。