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

動的テストとは何ですか?

動的テスト 動的テストは、ソフトウェアコードの動的な動作をテストするために使用されるソフトウェアテスト手法です。動的テストの主な目的は、動的変数（定数ではない変数）を用いたソフトウェアの動作を調べ、ソフトウェア実行環境における弱点を見つけることです。動的な動作をテストするには、コードを実行する必要があります。

テストは 検証と検証テストを完了するには、検証と妥当性確認の両方が必要です。検証は静的テストによって行われ、要件、設計ドキュメント、コードを実行せずに確認します。妥当性確認は動的テストによって行われ、ビルドを実行して、アプリケーションが実際に行うことと、本来行うべきことを比較します。

以下の表は、両者の違いを一目でわかるように示しています。

側面	静的テスト（検証）	動的テスト（検証）
Code 実行された	いいえ	はい
典型的な活動	Revビュー、ウォークスルー、検査、静的解析	すべてのテストレベルにおけるテストケースの実行
質問への回答	私たちは製品を正しく構築していますか?	私たちは適切な製品を構築しているでしょうか?
見つかった欠陥	曖昧な要件、コーディング標準違反、デッドコード	出力エラー、メモリリーク、タイミングエラー、統合エラー
開始	アーティファクトが存在するとすぐに	実行可能なビルドが存在する場合
修理の相対的なコスト	欠陥が早期に発見されるため、コストは低くなります。	欠陥が後から表面化するため、より高い。

動的テストの例

簡単な実例を通して、動的テストが実際にどのように動作するかを示します。

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

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

したがって、動的テストとは、実際のシステムを操作し、入力を与え、アプリケーションの実際の動作を期待される動作と比較することを意味します。言い換えれば、エラーを見つけることを目的としてシステムを操作することです。

したがって、動的テストとは、エンドユーザーが行うように、さまざまな環境下でソフトウェアアプリケーションを検証し、適切なソフトウェアを構築するプロセスである。

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

動的テストの主な目的は、ソフトウェアがインストール中およびインストール後に正しく動作し、重大な欠陥のない安定したアプリケーションを提供することです。完全にエラーのないソフトウェアは存在せず、テストによって欠陥の存在は明らかになりますが、欠陥の不在を証明することはできません。

動的テストは、この例が示すように、ソフトウェア全体の一貫性を確保する上でも役立ちます。

銀行アプリには、マイアカウント、資金移動、 Bill 支払い。すべてに金額入力欄があります。

「マイアカウント」フィールドに金額が25,000と表示され、「資金移動」には$25,000と表示され、 Bill 給与画面には25000ドルと表示されます。金額は同じですが、表示方法が異なるため、ソフトウェアの動作に一貫性がありません。

一貫性とは、機能性だけにとどまりません。パフォーマンス、ユーザビリティ、互換性といった基準も含まれるため、動的テストが非常に重要なのです。

動的テストの種類

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

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

下の図は、2つのカテゴリーを、それぞれの下位に位置するテストレベルに対応付けたものです。

各種類とその用途については、以下で説明します。

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

ブラック Box テスト 内部構造、コード、設計をテスターが知らない状態で実施するテスト手法。主な目的は、テスト対象システムの機能性を検証することである。このタイプのテストでは、テストスイート全体を実行する必要があり、主にテスターが実施し、プログラミングの知識は不要である。

ブラックボックステストは、さらに2つのタイプに分類されます。

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

機能テスト

機能テスト 開発されたすべての機能が機能仕様に合致していることを検証するために実行されます。これは、機能テストを実行することによって実行されます。 テストケース QAチームによって作成されました。このフェーズでは、入力を与え、出力を検証し、実際の結果と期待される結果を比較することによって、システムのテストが行​​われます。

機能テストにはさまざまなレベルがあり、その中でも最も重要なのは以下の4つです。

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

非機能テスト

非機能テスト 非機能テストとは、機能面ではなく、メモリリーク、パフォーマンス、堅牢性といったシステムの非機能属性に焦点を当てたテスト手法です。非機能テストは、すべてのテストレベルで実施されます。

非機能テストの手法は数多く存在するが、その中でも最も重要なのは以下の5つである。

• 性能試験 — 要求仕様に基づき、想定されるネットワーク負荷の下で、システムの応答時間が正常であるかどうかを確認します。
• 回復テスト ―システムがクラッシュやハードウェア障害からどれだけ適切に復旧できるかを検証します。
• 互換性テスト ― さまざまな環境下でシステムがどのように動作するかを検証します。
• セキュリティテスト — アプリケーションの堅牢性を検証し、承認されたユーザーと役割のみがシステムにアクセスできるようにします。
• ユーザビリティテスト エンドユーザーによるシステムの使いやすさと、ユーザーがシステムをどれだけ快適に使いこなせるかを検証します。

動的テスト手法

型が確定したので、次の問題は、動的テストサイクルを実際にどのように実行するかということである。

動的テスト技術 STLC 動的テストは、テストの要件分析、テスト計画、テストケースの設計と実装、テスト環境のセットアップ、テストケースの実行、バグ報告、そして最終的なテスト完了といった一連のタスクで構成されます。動的テストにおける各タスクは、テストプロセスにおける前のタスクの完了に依存します。

STLC（ソフトウェアテストライフサイクル）において、実際の動的テストプロセスはテストケースの設計から始まります。下の図は一連のアクティビティを示しており、それぞれのアクティビティについて後述します。

プロセスを開始する前に、動的テストで採用する戦略について合意しておく必要がある。

テスト戦略は、主に利用可能なリソースと期間に焦点を当てるべきです。これら2つの要素に基づいて、テストの目的、テストの範囲、テストのフェーズまたはサイクル、環境の種類、想定される前提条件や課題、およびリスクをすべて文書化する必要があります。

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

テスト設計と実装

この段階で、チームは以下の点を特定します。

• テストする機能
• これらの機能から導き出されたテスト条件
• 試験条件から導き出された補償項目
• カバレッジ項目から派生したテストケース

ブラックボックス テスト設計手法 同値分割、境界値解析など、 決定表テスト (NAIST) と 状態遷移テスト これらは、テスト条件を具体的な実行可能なケースの集合に変換するものです。

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

その テスト環境 常に本番環境と同様の状態であるべきです。このフェーズでは、ビルドのインストール、テストマシンの管理および構成が行われます。

テスト実行

このフェーズでは、テストケースが実際に実行されます。手動または オートメーションそして、実際の結果は予想結果と比較して記録される。

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

実行結果に基づいて、期待される結果と実際の結果が一致しない場合は、テストケースを失敗とマークし、バグをログに記録する必要があります。 欠陥管理 プロセス。

動的テストの利点

• 動的テストは、静的解析では全く検出できない、あるいは複雑すぎて見つけられないと考えられる欠陥を明らかにする。
• このソフトウェアはエンドツーエンドで実行されるため、製品とプロジェクトの両方の品質が向上します。
• 動的テストは、稼働中のシステムにおけるセキュリティ上の脅威を検出するための不可欠な手段である。
• メモリリーク、タイミングの問題、統合の失敗など、実行時のみに発生する障害は、ここでのみ顕在化し、他の場所では顕在化しない。

動的テストの欠点

• 動的テストは、アプリケーションやコードの実行に大量のリソースが必要となるため、時間がかかります。
• ソフトウェアライフサイクルの早い段階で着手されないため、プロジェクトのコストが増加します。後の段階で修正される問題は、修復コストが高くなるためです。
• 本番環境に近い環境と現実的なテストデータは必須条件であり、どちらも構築と維持に労力を要する。

よくあるご質問