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

動的テスト

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

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

動的テストの例

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

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

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

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

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

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

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

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

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

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

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

動的テストの種類

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

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

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

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

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

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

当学校区のテストはまた XNUMX つのタイプに分類されます。

彼らは

機能テスト
非機能テスト

機能テスト

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

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

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

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

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

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

動的テスト手法

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

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

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

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

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

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

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

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

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

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

テストの実行

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

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

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

動的テストの利点

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

動的テストの欠点

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

結論

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