このセクションでは、ソフトウェア開発ライフサイクルの際に使用できるさまざまな種類のソフトウェア テストについて理解します。
みなさんご存じのとおり、 ソフトウェアテスト 顧客の前提条件に従ってアプリケーションの機能を分析するプロセスです。
ソフトウェアにバグがないこと、または安定していることを確認したい場合は、さまざまな種類のソフトウェア テストを実行する必要があります。テストはアプリケーションのバグをなくす唯一の方法であるためです。
さまざまな種類のソフトウェア テスト
ソフトウェア テストの分類は、次のようなさまざまなテスト活動の一部です。 テスト戦略、テスト成果物、定義されたテスト目標など 。ソフトウェア テストは、ソフトウェアを実行して欠陥を見つけることです。
テストタイプを設ける目的は、 テスト対象者 (テスト中のアプリケーション)。
テストを開始するには、 要件、アプリケーションの準備完了、必要なリソースが利用可能 。説明責任を維持するには、それぞれのモジュールを異なるテスト エンジニアに割り当てる必要があります。
ソフトウェアテストは主に次の 2 つの部分に分かれています。
手動テストとは何ですか?
自動化ツールを使用せずにクライアントのニーズに応じてソフトウェアまたはアプリケーションをテストすることは、 手動テスト 。
つまり、 という手順であると言えます。 検証と検証 。手動テストは、要件仕様に矛盾するアプリケーションまたはソフトウェアの動作を検証するために使用されます。
手動テスト ケースを実行するために、テスト ツールに関する正確な知識は必要ありません。あらゆるアプリケーションで手動テストを実行しながら、テストドキュメントを簡単に準備できます。
手動テストの詳細情報を取得するには、リンク https://www.javatpoint.com/manual-testing をクリックしてください。
手動テストの分類
ソフトウェアテストでは、手動テストはさらに次のように分類できます。 3つの異なるタイプのテスト 、それは次のとおりです。
理解を深めるために、それらを 1 つずつ見てみましょう。
ホワイトボックステスト
ホワイトボックス テストでは、開発者はコードをテスト チームまたは関係するテスト エンジニアに引き渡す前に、コードのすべての行を検査します。
その後、コードはテスト中ずっと開発者に注目されます。このプロセスが次のように呼ばれるのはそのためです WBT (ホワイトボックステスト) 。
言い換えれば、次のように言えます。 開発者 特定のソフトウェアの完全なホワイトボックス テストを実行し、特定のアプリケーションをテスト チームに送信します。
ホワイト ボックス テストを実装する目的は、ソフトウェアに対する入力と出力のフローを強調し、アプリケーションのセキュリティを強化することです。
ホワイトボックステストとも呼ばれます オープンボックス試験、ガラスボックス試験、構造試験、クリアボックス試験、透明ボックス試験 。
ホワイト ボックス テストに関する詳しい知識を得るには、次のリンクを参照してください: https://www.javatpoint.com/white-box-testing 。
ブラックボックステスト
別のタイプの手動テストは次のとおりです。 ブラックボックステスト 。このテストでは、テスト エンジニアが要件に照らしてソフトウェアを分析し、欠陥やバグを特定して、開発チームに送り返します。
次に、開発者はそれらの欠陥を修正し、ホワイト ボックス テストを 1 回実行して、テスト チームに送信します。
ここで、バグを修正するということは、欠陥が解決され、特定の機能が所定の要件に従って動作することを意味します。
ブラック ボックス テストを実装する主な目的は、ビジネス ニーズまたは顧客の要件を指定することです。
言い換えれば、ブラック ボックス テストは、顧客の要件に従ってアプリケーションの機能をチェックするプロセスであると言えます。このテストではソース コードは表示されません。それがそれがとして知られている理由です ブラックボックステスト 。
ブラック ボックス テストの詳細については、次のリンクを参照してください: https://www.javatpoint.com/black-box-testing 。
ブラックボックステストの種類
ブラック ボックス テストはさらに、以下で説明する 2 つの部分に分類されます。
機能テスト
テスト エンジニアは、要件仕様に照らしてすべてのコンポーネントを系統的にチェックします。これは、テスト エンジニアとして知られています。 機能テスト 。機能テストは次のようにも知られています。 コンポーネントのテスト 。
機能テストでは、値を指定し、出力を定義し、実際の出力を期待値と検証することによって、すべてのコンポーネントがテストされます。
機能テストは、実際のコードではなくアプリケーションの要件に重点を置くため、ブラックボックス テストの一部です。テストエンジニアは、システムではなくプログラムのみをテストする必要があります。
機能テストの詳細については、以下のリンクを参照してください。 https://www.javatpoint.com/function-testing 。
機能テストの種類
別の種類のテストがいくつかの部分に分かれているのと同様に、機能テストもさまざまなカテゴリに分類されます。
多様な 機能テストの種類 以下が含まれます:
それでは、それらを 1 つずつ理解してみましょう。
1.単体テスト
単体テストは、ソフトウェアをテストするための機能テストの最初のレベルです。この場合、テスト エンジニアはアプリケーションのモジュールを個別にテストするか、呼び出されるすべてのモジュール機能をテストします。 単体テスト 。
単体テストを実行する主な目的は、単体コンポーネントの性能を確認することです。ここで、ユニットとは、ソフトウェアまたはアプリケーションのテスト可能な単一の機能として定義されます。そして、指定されたアプリケーション開発フェーズ全体を通じて検証されます。
単体テストに関する完全な情報を取得するには、次のリンクをクリックしてください: https://www.javatpoint.com/unit-testing 。
2. 結合テスト
単体テストの実装に成功したら、統合テストに進みます。これは機能テストの第 2 レベルであり、依存するモジュール間のデータ フローまたは 2 つの機能間のインターフェイスをテストします。 統合テスト 。
統合テストを実行する目的は、各モジュール間のステートメントの正確性をテストすることです。
結合テストの種類
統合テストはさらに次の部分に分かれています。
増分統合テスト
モジュール間に明確な関係がある場合は常に、増分統合テストを実施します。 2 つのモジュールを取り上げ、それらが正常に動作しているかどうか、それらの間のデータ フローを分析するとします。
これらのモジュールが正常に動作している場合は、もう 1 つモジュールを追加して再度テストできます。そして、同じプロセスを継続してより良い結果を得ることができます。
言い換えれば、モジュールを段階的に追加し、モジュール間のデータ フローをテストすることは、 増分統合テスト 。
増分統合テストの種類
増分統合テストはさらに次の 2 つの部分に分類できます。
これらのタイプの統合テストについて簡単に説明します。
1. トップダウンの増分統合テスト
このアプローチでは、モジュールを段階的にまたは段階的に追加し、モジュール間のデータ フローをテストします。追加するモジュールが次のとおりであることを確認する必要があります。 先代の子 。
2. ボトムアップの増分統合テスト
ボトムアップのアプローチでは、モジュールを段階的に追加し、モジュール間のデータ フローを確認します。また、追加するモジュールが 前の人の親 。
非増分統合テスト/ビッグバン方式
データ フローが複雑で、親と子を分類することが非常に難しい場合は、非増分統合アプローチを採用します。非増分方式は、次のようにも知られています。 ビッグバン方式 。
統合テストとその種類に関する完全な情報を取得するには、リンク https://www.javatpoint.com/integration-testing を参照してください。
3. システムテスト
単体テストと統合テストが完了したら、システム テストに進むことができます。
システム テストでは、テスト環境は実稼働環境と並行して行われます。としても知られています 端から端まで テスト中。
このタイプのテストでは、ソフトウェアの各属性を調べ、最終機能がビジネス要件に従って動作するかどうかをテストします。そしてソフトウェア製品を完全なシステムとして分析します。
システム テストに関する完全な情報を取得するには、次のリンクをクリックしてください: https://www.javatpoint.com/system-testing 。
非機能テスト
ブラックボックステストの次の部分は、 非機能テスト 。ソフトウェア製品のパフォーマンスや使用されているテクノロジに関する詳細情報を提供します。
非機能テストは、ソフトウェアの製造リスクと関連コストを最小限に抑えるのに役立ちます。
非機能テストは以下の組み合わせです。 パフォーマンス、負荷、ストレス、ユーザビリティ、互換性テスト 。
非機能テストの詳細については、リンク https://www.javatpoint.com/non-function-testing を参照してください。
非機能テストの種類
非機能テストはテストのさまざまな部分に分類されます。これについては、さらに詳しく説明します。
1. パフォーマンステスト
パフォーマンス テストでは、テスト エンジニアは負荷を加えてアプリケーションの動作をテストします。
このタイプの非機能テストでは、テスト エンジニアは次のようないくつかの側面にのみ焦点を当てます。 応答時間、負荷、スケーラビリティ、安定性 ソフトウェアまたはアプリケーションの。
性能試験の分類
パフォーマンス テストには、次のようなさまざまな種類のテストが含まれます。
パフォーマンス テストの実行中に、特定のアプリケーションにある程度の負荷をかけて、アプリケーションのパフォーマンスをチェックします。 負荷テスト 。ここで、負荷は目的の負荷以下である可能性があります。
これは、ソフトウェアの最大動作量とボトルネックを検出するのに役立ちます。
負荷テストに関連する完全な情報を取得するには、以下のリンクを参照してください。
https://www.javatpoint.com/load-testing。
これは、一般的な機能制限を超えてソフトウェアの使いやすさと堅牢性を分析するために使用されます。
ストレス テストは主に重要なソフトウェアに使用されますが、あらゆる種類のソフトウェア アプリケーションにも使用できます。
データ構造 Java
ストレス テストの詳細については、次のリンクを参照してください: https://www.javatpoint.com/stress-testing 。
分析上、特定のバランスにおける負荷を強化または削減することによるアプリケーションのパフォーマンスは、 スケーラビリティテスト 。
スケーラビリティ テストでは、次のことも確認できます。 システム、プロセス、またはデータベースの能力 上向きのニーズに応えるために。そしてこの中で、 テストケース 効率的に設計および実装されます。
次のリンクをクリックして、スケーラビリティ テストに関連する詳細情報を取得します。
https://www.javatpoint.com/scalability-testing。
安定性テストは、正確な時間負荷を適用することでアプリケーションのパフォーマンスを評価する手順です。
主にアプリケーションの恒常性の問題と開発製品の効率をチェックします。このタイプのテストでは、ストレスの多い状況でもシステムの欠陥を迅速に発見できます。
安定性テストの詳細については、以下のリンクを参照してください。
https://www.javatpoint.com/stability-testing。
2. ユーザビリティテスト
別のタイプの 非機能テスト は ユーザビリティテスト 。ユーザビリティテストでは、アプリケーションの使いやすさを分析し、ソフトウェアのエンドユーザーインターフェイスのバグを検出します。
ここで、用語は、 使いやすさ アプリケーションの次の側面を定義します。
- アプリケーションは理解しやすいものでなければなりません。つまり、すべての機能がエンドユーザーに見える必要があります。
- アプリケーションのルック アンド フィールは優れている必要があります。つまり、アプリケーションは見た目が良く、エンドユーザーが使いやすいものである必要があります。
ユーザビリティテストの詳細については、次のリンクを参照してください。
https://www.javatpoint.com/usability-testing。
3. 互換性テスト
互換性テストでは、特定のハードウェアおよびソフトウェア環境におけるアプリケーションの機能をチェックします。アプリケーションが機能的に安定したら、次に進みます。 互換性テスト 。
ここ、 ソフトウェア これは、さまざまなオペレーティング システムや他のブラウザでアプリケーションをテストできることを意味します。 ハードウェア つまり、さまざまなサイズでアプリケーションをテストできるということです。
互換性テストについて詳しく知るには、以下のリンクを参照してください。
https://www.javatpoint.com/compatibility-testing 。
グレーボックステスト
の別の部分 手動テスト は グレーボックステスト 。それは ブラックボックステストとホワイトボックステストのコラボレーション 。
グレーボックスのテストには、テストケースを設計するための内部コーディングへのアクセスが含まれているためです。グレー ボックス テストは、テストだけでなくコーディングの知識がある人によって実行されます。
言い換えれば、1 人のチームが両方を実行した場合、次のように言えます。 ホワイトボックスとブラックボックスのテスト 、それは考えられます グレーボックスのテスト 。
グレー ボックス テストの詳細情報を取得するには、以下のリンクを参照してください。
https://www.javatpoint.com/grey-box-testing。
自動化テスト
ソフトウェア テストの最も重要な部分は自動テストです。特定のツールを使用して、人間の介入なしに手動設計のテスト ケースを自動化します。
自動テストは、ソフトウェア テストの効率、生産性、範囲を強化するための最良の方法です。
これは、手動で迅速に繰り返し実行されたテスト シナリオを再実行するために使用されます。
言い換えれば、いくつかのツールを使用してアプリケーションをテストするときは常に、 自動化テスト 。
アプリケーションやソフトウェアでさまざまなリリースやいくつかの回帰サイクルが行われるときに、自動テストを実施します。プログラミング言語を理解していなければ、テスト スクリプトを書いたり、自動テストを実行したりすることはできません。
自動テストの詳細については、以下のリンクを参照してください。
https://www.javatpoint.com/automation-testing。
他の種類のソフトウェア テスト
ソフトウェア テストでは、上記で説明したテストの一部ではない他の種類のテストもありますが、これらのテストは、ソフトウェアまたはアプリケーションをテストする際に必要です。
これらの種類のテストを 1 つずつ理解しましょう。
で 煙テスト 、徹底的で厳密なテストを 1 回行う前に、アプリケーションの基本的かつ重要な機能をテストします。
または 考えられるすべての正と負の値をチェックする前に、 煙テスト 。スモーク テストを実行する主な目的は、アプリケーションのコアおよび主要機能のワークフローを分析することです。
煙テストの詳細については、次のリンクを参照してください。
https://www.javatpoint.com/smoke-testing。
健全性テスト
これは、すべてのバグが修正され、これらの変更によって追加の問題が発生していないことを確認するために使用されます。健全性テストはスクリプト化されていないため、文書化することができません。新しく追加された機能とコンポーネントが正しいかどうかをチェックします。
健全性テストに関する詳細情報を取得するには、以下のリンクを参照してください。
https://www.javatpoint.com/sanity-testing。
回帰試験
回帰テストは、最も一般的に使用されるタイプのソフトウェア テストです。ここで、用語は、 回帰 これは、影響を受けていないアプリケーションのそれらの部分を再テストする必要があることを意味します。
回帰テストは自動化ツールに最適なテストです。プロジェクトの種類とリソースのアクセスしやすさに応じて、回帰テストは次のようになります。 再テスト 。
開発者によってバグが修正され、そのバグ修正によってシミュレートされる可能性のあるアプリケーションの他の機能をテストすることを、 回帰試験 。
言い換えれば、あるプロジェクトに新しいリリースがあるたびに回帰テストを実行でき、新しい機能が以前のリリースの古い機能に影響を与える可能性があると言えます。
回帰テストに関する詳しい知識を得るには、以下のリンクを参照してください。
https://www.javatpoint.com/regression-testing 。
ユーザー受け入れテスト
ユーザー受け入れテスト (UAT) は、ドメイン エキスパート/顧客、またはクライアントと呼ばれる個別のチームによって実行されます。そして、最終製品を受け入れる前にアプリケーションを知ることは、次のように呼ばれます ユーザー受け入れテスト 。
ユーザー受け入れテストでは、ビジネス シナリオと、 UAT環境 。このテストでは、顧客の承認を得るために UAI の前にアプリケーションをテストします。
ユーザー受け入れテストの詳細については、以下のリンクをクリックしてください。
https://www.javatpoint.com/acceptance-testing。
探索的テスト
要件が欠落している場合は常に、早期の反復が必要です。重要なアプリケーションの場合、テスト チームには経験豊富なテスターがいます。新しいテストエンジニアがチームに加わり、私たちは次の目標を達成します。 探索的テスト 。
探索的テストを実行するには、まずアプリケーションをあらゆる方法で調べ、テスト ドキュメントを作成し、アプリケーションの流れを理解してから、アプリケーションをテストします。
探索的テストに関する完全な情報を取得するには、次のリンクをクリックしてください。
https://www.javatpoint.com/exploratory-testing。
アドホックテスト
ビルドがチェックされたシーケンスに入ったらすぐにアプリケーションをランダムにテストすることは、次のように知られています。 アドホックテスト 。
とも呼ばれます サルの検査とゴリラの検査 。アドホック テストでは、クライアントの要件に矛盾するアプリケーションをチェックします。それが、としても知られている理由です 陰性検査 。
エンドユーザーが何気なくアプリケーションを使用していると、バグを発見する可能性があります。それでも、専門のテスト エンジニアはソフトウェアを徹底的に使用するため、同様の検出を特定できない可能性があります。
アドホック テストの詳細情報を取得するには、次を参照してください。
https://www.javatpoint.com/adhoc-testing。
セキュリティテスト
これはソフトウェア テストの重要な部分であり、ソフトウェア アプリケーションの弱点、リスク、または脅威を判断するために使用されます。
セキュリティテストの実施は、外部からの厄介な攻撃を回避し、ソフトウェアアプリケーションのセキュリティを確保するのに役立ちます。
言い換えれば、セキュリティ テストは主に、データが安全でソフトウェアの動作プロセスに耐えられるかどうかを定義するために使用されると言えます。
セキュリティ テストの詳細については、次のリンクを参照してください: https://www.javatpoint.com/security-testing 。
グローバリゼーションテスト
別の種類のソフトウェア テストは次のとおりです。 グローバリゼーションテスト。 グローバリゼーションテストは、開発されたソフトウェアが多言語に対応しているかどうかをチェックするために使用されます。ここで、言葉は、 グローバリゼーション アプリケーションやソフトウェアをさまざまな言語に対応させることを意味します。
グローバリゼーション テストは、アプリケーションが複数の言語と複数の機能をサポートすることを確認するために使用されます。
現在のシナリオでは、アプリケーションが世界中で使用できるように準備されているため、いくつかのテクノロジーが強化されていることがわかります。
グローバリゼーション テストに関連する完全な情報を入手するには、次のリンクを参照してください。
https://www.javatpoint.com/globalization-testing。
結論
このチュートリアルでは、さまざまな種類のソフトウェア テストについて説明しました。しかし、依然として 100 以上のカテゴリのテストのリストが存在します。ただし、各種類のテストがすべての種類のプロジェクトで使用されるわけではありません。
以下のような最も一般的に使用されるタイプのソフトウェア テストについて説明しました。 ブラックボックステスト、ホワイトボックステスト、機能テスト、非機能テスト、回帰テスト、アドホックテストなど 。
また、さまざまな組織で代替の分類やプロセスが使用されていますが、一般的な概念はどこでも似ています。
これらのテストの種類、プロセス、実行アプローチは、プロジェクト、要件、範囲が変わると常に変化します。