静的テストとは何ですか? ソフトウェアテスト手法

替え：

トーマス・ハミルトン

更新中2024 年 2 月 24 日

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

静的テスト コードを実行せずにソフトウェアアプリケーションの欠陥をチェックするために使用されるソフトウェアテスト手法です。静的テストは、開発の初期段階でのエラーの特定と解決が容易なため、エラーを回避するために行われます。また、動的テストでは見つからないエラーを見つけるのにも役立ちます。

これに相当するのは、コードの実行時にアプリケーションをチェックする動的テストです。の詳細な違いについては、このチュートリアルを参照してください。静的テストと動的テスト.

静的テスト手法には主に次の XNUMX 種類があります。

手動検査: 手動検査には、手動で行われたコードの分析が含まれます。 レビュー。
ツールを使用した自動分析: 自動分析は基本的にツールを使用して実行される静的分析です。

静的テスト手法

非公式 Revレビュー
チュートリアル
技術的 Revレビュー
検査
静的分析
- データフロー
- 制御フロー

静的テストに使用されるツール

静的テストに使用されるさまざまなツールは次のとおりです。

テストとは何か Revええ？

静的テストにおけるレビューは、プログラムの設計における潜在的な欠陥を見つけるために実施されるプロセスまたは会議です。レビューのもう一つの意義は、チームメンバー全員がプロジェクトの進捗状況を知ることができ、時には考え方の多様性から優れた提案が生まれることもあります。文書は人によって直接検査され、矛盾が整理されます。

Revビューはさらに 4 つの部分に分類できます。

非公式のレビュー
チュートリアル
技術レビュー
検査

間に Revプロセステストに参加する参加者は次の 4 種類です。

モデレータ: エントリのチェック、手戻りのフォローアップ、チームメンバーの指導、会議のスケジュールを実行します。
著者: 見つかった欠陥を責任を持って修正し、ドキュメントの品質を向上させます。
筆記: レビュー中に欠陥のログを記録し、レビュー会議に参加します
Revもっと: 材料に欠陥がないか確認し、検査します。
マネージャー: レビューの実行を決定し、レビュープロセスの目標が確実に達成されるようにします。

静的テスト中に発見しやすい欠陥の種類は次のとおりです。

基準からの逸脱
保守不可能なコード
設計上の欠陥
要件が欠落している
一貫性のないインターフェイス仕様

通常、静的テスト中に発見される欠陥は、セキュリティの脆弱性、宣言されていない変数、境界違反、構文違反、一貫性のないインターフェイスなどが原因です。

静的テストプロセスを成功させるためのヒント

ソフトウェアエンジニアリングで静的テストプロセスを実行するための役立つヒント。

本当に重要なことだけに集中する
レビュー活動を明示的に計画し、追跡します。ソフトウェアのウォークスルーと検査は通常、同僚のレビューに組み込まれます。
例を使って参加者をトレーニングする
人の問題を解決する
プロジェクト文化としてプロセスを形式的に保つ
継続的な改善 – プロセスとツール
テスト実行の大幅な遅延を解消することで、テストのコストと時間を削減できます。

なぜ静的テストなのか?

静的テストは以下の理由で実行されます

欠陥の早期検出と修正
開発期間の短縮
テストのコストと時間の削減
開発生産性向上のために
テストの後の段階で欠陥を減らすため

静的テストでテストされる内容

静的テストでは、以下のことがテストされます。

単体テストケース
ビジネス要件文書 (BRD)
ユースケース
システム/機能要件
試作
試作仕様書
DB フィールド辞書スプレッドシート
テストデータ
トレーサビリティマトリックスドキュメント
ユーザーマニュアル/トレーニングガイド/ドキュメント
テスト計画戦略文書/テストケース
自動化/パフォーマンステストスクリプト

静的テストの実行方法

静的テストを実行するには、次の方法で行います。

アプリケーションの設計を完全に検査する検査プロセスを実行します。
レビュー対象のドキュメントごとにチェックリストを使用して、すべてのレビューが完全にカバーされていることを確認します。

静的テストを実行するためのさまざまなアクティビティは次のとおりです。

ユースケースの要件の検証: すべてのエンドユーザーアクションと、それらに関連付けられた入力および出力が識別されていることを検証します。ユースケースがより詳細で徹底的であればあるほど、テストケースはより正確で包括的なものになります。
機能要件の検証: 機能要件が必要な要素をすべて特定していることを保証します。また、データベースの機能、インターフェイスのリスト、ハードウェア、ソフトウェア、およびネットワークの要件についても調べます。
Archi構造 RevIEW: サーバーの場所、ネットワーク図、プロトコル定義、負荷分散、データベースへのアクセス、テスト機器などのすべてのビジネスレベルのプロセス。
プロトタイプ/画面モックアップの検証: この段階には、要件とユースケースの検証が含まれます。
フィールド辞書の検証: UI のすべてのフィールドは、フィールドレベルの検証テストケースを作成するのに十分なレベルで定義されています。フィールドの最小/最大長、リスト値、エラーメッセージなどがチェックされます。

まとめ

静的テストは、欠陥をできるだけ早く発見することです。
静的テストは動的テストの代替ではなく、両方とも異なる種類の欠陥を検出します
Reviewsは静的テストに効果的な手法です
Rev視覚化は欠陥を見つけるのに役立つだけでなく、要件の不足、設計上の欠陥、保守不可能なコードを理解するのにも役立ちます。このプロセスを支援するツールを探している場合は、ここにいくつかの包括的なリストがあります。最高のコードレビューツールあなたが役に立つと思うかもしれません。

よろしければ：