what is difference between sit vs uat testing
この記事では、SITとUATの主な違いについて説明します。また、システム統合テストとユーザー受け入れテストの方法についても学習します。
一般に、テストはテスターと開発者の両方によって行われます。それらのそれぞれは、アプリケーションをテストするために独自のパターンに従います。
システム統合テストまたはSITはテスターによって実行されますが、一般にUATとして知られるユーザー受け入れテストは最後にエンドユーザーによって実行されます。この記事では、SITとUATの両方を詳細に比較し、2つの主な違いを理解するのに役立ちます。
探検しよう！
学習内容：
SITとUAT：概要
一般に、テストのレベルには次の階層があります。
- ユニットテスト
- コンポーネントテスト
- システムテスト
- システム統合テスト
- ユーザー受け入れテスト
- 製造
間の主な違いを分析しましょう システム統合テスト（SIT） そして ユーザー受け入れテスト（UAT）。
システム統合テスト（SIT）
2つの異なるサブシステム/システムは、任意のプロジェクトのある時点で結合されます。次に、このシステム全体をテストする必要があります。したがって、これはシステム統合テストと呼ばれます。
SITの作業手順
- 個々のユニットは、最初に別々のビルドに統合する必要があります。
- システム全体を全体としてテストする必要があります。
- テストケースは、ソフトウェア要件に基づいた適切なソフトウェアを使用して作成する必要があります。
- このテストでは、UIエラー、データフローエラー、インターフェイスエラーなどのエラーを見つけることができます。
例：
ヘルスケアサイトが持っていると考えてみましょう 3つのタブ 最初はつまり 患者情報、教育、以前の医療記録 。ヘルスケアサイトが追加されました 新しいタブ と呼ばれる 注射情報。
次に、新しいタブの詳細またはデータベースを既存のタブとマージし、システム全体を4つのタブでテストする必要があります。
4つのタブがある統合サイトをテストする必要があります。
統合サイトは次のようになります。
SITで使用されるテクニック
- トップダウンアプローチ
- ボトムアップアプローチ
- ビッグバンアプローチ
＃1）トップダウンアプローチ
名前自体が示すように、それは上から下への実行に従うことを意味します。これは、メイン機能またはモジュールをテストし、次にサブモジュールを順番にテストする方法です。ここで、連続する実際のサブモジュールが統合のためにすぐに存在しない場合、どうするかという疑問が生じます。
これに対する答えは、 スタブ。
スタブはいわゆるプログラムとして知られています 。彼らはとして機能します ダミーモジュール 必要なモジュール機能を制限された方法で実行します。
サブモジュールの統合は難しいため、スタブは、実際のモジュールが統合の準備ができるまで、ユニット/モジュール/サブモジュールの機能を部分的に実行します。
低レベルのコンポーネントは、統合するためにスタブに置き換えることができます。したがって、トップダウンアプローチは、構造化言語または手続き言語に従う場合があります。 1つのスタブを実際のコンポーネントに置き換えた後、次のスタブを実際のコンポーネントに置き換えることができます。
上記の図の実行は、モジュールA、モジュールB、モジュールC、モジュールD、モジュールE、モジュールF、モジュールGになります。
スタブの例：
セレンでのMavenの使用は何ですか
＃2）ボトムアップアプローチ
このアプローチは、下から上への階層に従います。ここでは、最初に下位モジュールが統合され、次に上位モジュールが統合されてテストされます。
最下部のモジュールまたはユニットがマージされ、テストされます。下位ユニットのセットはと呼ばれます クラスター 。サブモジュールをメインモジュールと統合している間、メインモジュールが利用できない場合は、 運転手 メインプログラムのコーディングに使用されます。
ドライバーは呼び出しプログラムと呼ばれます 。
このアプローチでは、欠陥の漏れが少なくなります。
サブモジュールを上位レベルまたはメインモジュールに統合するために、上の図に示すようにドライバーモジュールが作成されます。
＃3）ビッグバンアプローチ
簡単に言うと、ビッグバンアプローチでは、すべてのユニットを一度に接続し、すべてのコンポーネントをテストする必要があります。ここではパーティションは作成されません。欠陥漏れが発生してはなりません。
このアプローチは、ゼロから開発されたばかりのプロジェクトや、大幅な機能強化が行われたプロジェクトに役立ちます。
ユーザー受け入れテスト（UAT）
テスターが完成したテスト済みプロジェクトをクライアント/エンドユーザーに渡すときはいつでも、クライアント/エンドユーザーはプロジェクトを再度テストして、正しく設計されているかどうかを確認します。これは、ユーザー受け入れテストと呼ばれます。
テストを実行するには、両方に適切なテストケースを作成する必要があります。
(画像 ソース )
開発者は、機能要件仕様書に基づいてコードを開発します。テスターはそれをテストし、バグを報告します。しかし、クライアントまたはエンドユーザーは、システムが正確にどのように機能するかしか知りません。したがって、彼らはシステムを最後からテストします。
UATの作業手順
- UAT計画は、要件に基づいて作成する必要があります。
- シナリオは、要件から構築する必要があります。
- テストケースとテストデータを準備する必要があります。
- テストケースを実行して、バグがないかチェックする必要があります。
- バグがなく、テストケースに合格した場合は、プロジェクトを承認して本番環境に送信できます。
- 欠陥やバグが見つかった場合は、リリースの準備のためにすぐに修正する必要があります。
UATテストの種類
- アルファおよびベータテスト： アルファテストは開発サイトで実行されますが、ベータテストは外部環境（外部企業など）で実行されます。
- 契約受け入れテスト： 契約では、事前定義された承認済みの仕様を満たす必要があります。
- 規制受け入れテスト： 名前が示すように、テストは規制に反して行われます。
- 運用受け入れテスト： 設計された操作またはワークフローは、期待どおりである必要があります。
- ブラックボックステスト： 深く掘り下げることなく、ソフトウェアはその重要な目的のためにテストされる必要があります。
SITとUATの主な違い
| SIT | UAT |
|---|---|
| これは、テスターと開発者によって実行されます。 | これは、エンドユーザーとクライアントによって実行されます。 |
| サブユニット/ユニットの統合はここでチェックされます。インターフェイスをテストします。 | 全体のデザインはここでチェックされます。 |
| 個々のユニットは、システムが要件に従って機能するように統合およびテストされています。 | システムは、ユーザーの希望に応じて、製品の主な機能について全体としてテストされます。 |
| これは、テスターの要件に基づいて行われます。 | これは、エンドユーザーが製品をどのように使用する必要があるかについてのユーザーの視点に基づいて行われます。 |
| SITは、システムが組み立てられるとすぐに実行されます。 | UATは、製品リリースの直前に最終的に実行されます。 |
結論
システム統合テストは、主にシステムのインターフェイス要件をテストするために行われます。一方、ユーザー受け入れテストは、エンドユーザーがシステム全体の機能を検証するために行われます。両方のテストに適切なテストケースを作成する必要があります。
SITは、3つの手法（トップダウン、ボトムアップ、ビッグバンのアプローチ）で実行できます。 UATは、5つの方法（アルファおよびベータテスト、契約受け入れテスト、規制受け入れテスト、運用受け入れテスト、およびブラックボックステスト）を使用して実行できます。
システムテストで見つかった欠陥は簡単に修正できます。欠陥に基づいてさまざまなビルドを作成できます。一方、UATで見つかった欠陥は、テスターにとってブラックマークと見なされ、受け入れられません。
UATでは、ビジネス担当者またはクライアントは、開発された製品がビジネス環境でのニーズを満たしていることに満足する必要があります。 SITは、システムの機能要件を満たす必要があります。
この記事で、SITとUATに関するすべての質問が明確になったことを願っています。