動的テストとは種類、テクニック、例

動的テスト

動的テスト ソフトウェア コードの動的な動作をテストするために使用されるソフトウェア テスト方法です。 動的テストの主な目的は、動的変数または定数ではない変数を使用してソフトウェアの動作をテストし、ソフトウェア ランタイム環境の弱点を見つけることです。 動的な動作をテストするには、コードを実行する必要があります。

テストは検証と検証であり、テストを完了するには 2 つの V が必要であることは誰もが知っています。 2 つの V のうち、検証は静的テストと呼ばれ、もう XNUMX つの「V」の検証は動的テストと呼ばれます。

動的テストの例

例を挙げて動的テストの実行方法を理解しましょう。

「ユーザー名」と「パスワード」という XNUMX つのフィールドがあり、ユーザー名が英数字に制限されているログイン ページをテストしているとします。

ユーザーがユーザー名を「Guru99」と入力すると、システムは同じものを受け入れます。 一方、ユーザーが Guru99@123 として入力すると、アプリケーションはエラー メッセージをスローします。 この結果は、コードが動的に動作していることを示しています。 ユーザー入力に基づいて。

動的テストとは、入力を提供し、アプリケーションの実際の動作と予想される動作を比較することによって、実際のシステムを操作することです。 言い換えれば、エラーを見つけることを目的としてシステムを操作することです。

したがって、上記の記述に基づいて、動的テストは、適切なソフトウェアを構築するために、さまざまな環境下でエンド ユーザーとしてソフトウェア アプリケーションを検証するプロセスであると言えます。

動的テストでは何を行うのでしょうか?

動的テストの主な目的は、ソフトウェアのインストール中およびインストール後にソフトウェアが適切に動作することを確認し、大きな欠陥のない安定したアプリケーションを確保することです (この声明は、エラーのないソフトウェアは存在せず、欠陥の存在を示すことができるのはテストのみであるためです)欠席ではありません)

動的テストの主な目的は、ソフトウェアの一貫性を確保することです。 これについて例を挙げて説明します。

銀行アプリケーションには、「口座」セクション、「資金移動」、「請求書支払い」などのさまざまな画面があります。これらすべての画面には、いくつかの文字を受け入れる金額フィールドが含まれています。

[マイ アカウント] フィールドに金額が次のように表示されているとします。 25,000 および資金移動として $25,000 そして請求書支払い画面として $25000 金額は同じでも、金額の表示方法が異なるため、ソフトウェアに一貫性がありません。

一貫性は機能に限定されるものではなく、パフォーマンス、使いやすさ、互換性などのさまざまな標準も参照するため、動的テストを実行することが非常に重要になります。

動的テストの種類

動的テストは XNUMX つのカテゴリに分類されます

  • ホワイト Box テスト
  • ブラック Box テスト

以下の図は、動的テストの種類、テストのレベルなどを示しています。

動的テスト

それぞれの種類のテストとその意図された目的について簡単に説明します

ホワイト Box テストホワイト Box テスト 内部構造/設計がテスターに​​既知であるソフトウェア テスト方法です。 ホワイトの主な目的 Box テストとは、コードに基づいてシステムがどのように動作しているかをチェックすることです。 主に開発者またはホワイトによって実行されます。 Box プログラミングに関する知識を持ったテスター。

ブラック Box テスト - ブラック Box テスト 内部構造/コード/設計をテストする方法です。 NOT テスターに​​は既知です。 このテストの主な目的は、テスト対象のシステムの機能を検証することであり、このタイプのテストは完全なテスト スイートを実行する必要があり、主にテスターに​​よって実行され、プログラミングの知識は必要ありません。

また, テストはまた XNUMX つのタイプに分類されます。

彼らは

  • 機能テスト
  • 非機能テスト

機能テスト

機能テストは、開発されたすべての機能が機能仕様に従っていることを検証するために実行され、QA チームによって作成された機能テスト ケースを実行することによって実行されます。機能テスト段階では、入力を提供し、出力を検証することによってシステムがテストされ、実際の結果と期待される結果を比較します。

機能テストにはさまざまなレベルがあり、そのうち最も重要なものは次のとおりです。

  • 単体テスト – 通常、ユニットはテスト可能な小さなコードです。 単体テスト ソフトウェアの個々のユニットで実行され、開発者によって実行されます。
  • 統合テスト統合テスト 単体テストの後に実行されるテストであり、テスト可能な個々のユニットをすべて組み合わせて実行され、開発者またはテスターに​​よって実行されます。
  • システムテストシステムテスト システムが要件どおりに動作するかどうかを確認するために実行され、通常は完全なシステムの準備ができたときに実行されます。ビルドまたはコードが QA チームにリリースされるときにテスターに​​よって実行されます。
  • 受け入れ試験 – 受け入れテストは、システムがビジネス要件を満たしており、使用の準備ができているか、展開の準備ができているかどうかを検証するために実行され、通常はエンド ユーザーによって実行されます。

非機能テスト: 非機能テストは、機能面には焦点を当てず、主にメモリ リーク、システムのパフォーマンス、堅牢性などのシステムの非機能特性に焦点を当てるテスト手法です。 非機能テストはすべてのテスト レベルで実行されます。

非機能テスト手法は数多くありますが、その中で最も重要なものは次のとおりです。

  • 性能試験 性能試験 システムの応答時間が、必要なネットワーク負荷の下で要件に従って正常であるかどうかをチェックするために実行されます。
  • 回復テスト – 回復テストは、システムがクラッシュやハードウェア障害からどの程度回復できるかを検証する方法です。
  • 互換性テスト – 互換性テストは、さまざまな環境間でシステムがどのように動作するかを検証するために実行されます。
  • セキュリティテスト セキュリティテスト アプリケーションの堅牢性を検証するために実行されます。つまり、許可されたユーザー/ロールのみがシステムにアクセスしていることを確認します。
  • ユーザビリティテスト ユーザビリティテスト エンドユーザーによるシステムの使いやすさを検証し、ユーザーがシステムをどの程度快適に使用しているかを検証する方法です。

動的テスト手法

動的テスト手法 in STLC テストの要件分析、テスト計画、テスト ケースの設計と実装、テスト環境のセットアップ、テスト ケースの実行、バグの報告、そして最後にテストの終了などのさまざまなタスクで構成されます。 動的テスト手法のすべてのタスクは、テスト プロセスの前のタスクの完了に依存します。

STLC では、実際の動的テスト プロセスはテスト ケース設計から始まると言えます。各アクティビティについて説明します。tails.

動的テストのチュートリアル: 種類、手法、プロセス

プロセスに入る前に、動的テストで従う必要がある戦略について説明します。

テスト戦略は、利用可能なリソースと期間に主に焦点を当てる必要があります。 これらの要素に基づいて、テストの目的、テストの範囲、テストのフェーズまたはサイクル、環境の種類、直面する可能性のある想定または課題、リスクなどを文書化する必要があります。

戦略が定義され、経営陣に承認されると、実際のプロセス テスト ケースの設計が開始されます。

テスト設計と実装とは何ですか

このフェーズでは、次のことを特定します。

  • テストする機能
  • テスト条件の導出
  • カバレッジ項目の導出
  • テストケースを導出する

テスト環境のセットアップ

テスト環境が常に運用環境と同様であることを確認する必要があります。このフェーズでは、ビルドをインストールし、テスト マシンを管理する必要があります。

テストの実行

このフェーズでは、テスト ケースが実際に実行されます。

バグレポートをキャプチャしました

実行に基づいて、期待された結果と実際の結果が異なる場合、テスト ケースは失敗としてマークされ、バグが記録される必要があります。

動的テストの利点

  • 動的テストでは、難しすぎる、または複雑すぎると考えられ、静的分析ではカバーできない未発見の欠陥を明らかにできます。
  • 動的テストでは、ソフトウェアをエンドツーエンドで実行し、ソフトウェアにエラーがないことを保証し、それによって製品とプロジェクトの品質が向上します。
  • 動的テストはセキュリティ上の脅威を検出するための不可欠なツールになります

動的テストの欠点

  • 動的テストは、大量のリソースを必要とするアプリケーション/ソフトウェアまたはコードを実行するため、時間がかかります。
  • 動的テストはソフトウェアのライフサイクルの早い段階で開始されず、後の段階で問題が修正されるとコストの増加につながる可能性があるため、プロジェクト/製品のコストが増加します。

結論:

In ソフトウエアエンジニアリング, 検証と検証は、ソフトウェア製品が要求仕様を満たしていることを確認するために使用される XNUMX つの手段です。 静的テストには検証が含まれますが、動的テストには検証が含まれます。 これらを組み合わせることで、コスト効率の高い高品質のソフトウェアを提供できます。