静的テストとは何ですか? ソフトウェアテスト手法
トーマス・ハミルトン
⚡ スマートサマリー
静的テストは、コードを実行せずにアプリケーションの欠陥をチェックするソフトウェアテスト手法であり、ウォークスルーやインスペクションなどのレビューに加え、自動分析ツールを活用することで、エラーを早期に検出し、開発コストと時間を削減します。
静的テストとは何ですか?
静的テスト コードを実行せずにソフトウェア アプリケーションの欠陥をチェックするために使用されるソフトウェア テスト手法です。 静的テストは、開発の初期段階でのエラーの特定と解決が容易なため、エラーを回避するために行われます。 また、動的テストでは見つからないエラーを見つけるのにも役立ちます。
これに相当するのは、コードの実行時にアプリケーションをチェックする動的テストです。 の詳細な違いについては、このチュートリアルを参照してください。 静的テストと動的テスト.
静的テスト手法には主に次の XNUMX 種類があります。
- 手動検査: 手動検査には、手動で行われたコードの分析が含まれます。 レビュー。
- ツールを使用した自動分析: 自動分析は基本的にツールを使用して実行される静的分析です。
静的テスト手法
- 非公式 Revレビュー
- チュートリアル
- 技術部門 Revレビュー
- 検査
- 静的分析
- データフロー
- 制御フロー
静的テストに使用されるツール
静的テストに使用されるさまざまなツールは次のとおりです。
テストとは何か Revええ？
静的テストにおけるレビューは、プログラムの設計における潜在的な欠陥を見つけるために実施されるプロセスまたは会議です。 レビューのもう一つの意義は、チームメンバー全員がプロジェクトの進捗状況を知ることができ、時には考え方の多様性から優れた提案が生まれることもあります。 文書は人によって直接検査され、矛盾が整理されます。
Revビューはさらに 4 つの部分に分類できます。
- 非公式のレビュー
- チュートリアル
- 技術レビュー
- 検査
間に Revプロセステストに参加する参加者は次の 4 種類です。
- モデレータ: エントリのチェック、手戻りのフォローアップ、チームメンバーの指導、会議のスケジュールを実行します。
- 著者: 見つかった欠陥を責任を持って修正し、ドキュメントの品質を向上させます。
- 筆記: レビュー中に欠陥のログを記録し、レビュー会議に参加します
- Revもっと: 材料に欠陥がないか確認し、検査します。
- マネージャー: レビューの実行を決定し、レビュー プロセスの目標が確実に達成されるようにします。
静的テスト中に発見しやすい欠陥の種類は次のとおりです。
- 基準からの逸脱
- 保守不可能なコード
- 設計上の欠陥
- 要件が欠落している
- 一貫性のないインターフェイス仕様
通常、静的テスト中に発見される欠陥は、セキュリティの脆弱性、宣言されていない変数、境界違反、構文違反、一貫性のないインターフェイスなどが原因です。
静的テストプロセスを成功させるためのヒント
ソフトウェア エンジニアリングで静的テスト プロセスを実行するための役立つヒント。
- 本当に重要なことだけに集中する
- 明確に計画し、 track レビュー活動。ソフトウェアのウォークスルーと検査は、一般的にピアレビューに組み込まれます。
- 例を使って参加者をトレーニングする
- 人の問題を解決する
- プロジェクト文化としてプロセスを形式的に保つ
- 継続的な改善 – プロセスとツール
- テスト実行の大幅な遅延を解消することで、テストのコストと時間を削減できます。
なぜ静的テストなのか?
静的テストは以下の理由で実行されます
- 欠陥の早期検出と修正
- 開発期間の短縮
- テストのコストと時間の削減
- 開発生産性向上のために
- テストの後の段階で欠陥を減らすため
静的テストでテストされる内容
静的テストでは、以下のことがテストされます。
- 単体テストケース
- ビジネス要件文書 (BRD)
- 適用例
- システム/機能要件
- 試作
- 試作仕様書
- DB フィールド辞書スプレッドシート
- テストデータ
- Trac能力マトリックス文書
- ユーザーマニュアル/トレーニングガイド/ドキュメント
- テスト計画戦略文書/テスト ケース
- 自動化/パフォーマンス テスト スクリプト
静的テストの実行方法
静的テストを実行するには、次の方法で行います。
- アプリケーションの設計を完全に検査する検査プロセスを実行します。
- レビュー対象のドキュメントごとにチェックリストを使用して、すべてのレビューが完全にカバーされていることを確認します。
静的テストを実行するためのさまざまなアクティビティは次のとおりです。
- ユースケースの要件の検証: すべてのエンドユーザー アクションと、それらに関連付けられた入力および出力が識別されていることを検証します。 ユースケースがより詳細で徹底的であればあるほど、テストケースはより正確で包括的なものになります。
- 機能要件の検証: 機能要件が必要な要素をすべて特定していることを保証します。 また、データベースの機能、インターフェイスのリスト、ハードウェア、ソフトウェア、およびネットワークの要件についても調べます。
- Archi構造 RevIEW: サーバーの場所、ネットワーク図、プロトコル定義、負荷分散、データベースへのアクセス、テスト機器などのすべてのビジネスレベルのプロセス。
- プロトタイプ/画面モックアップの検証: この段階には、要件とユースケースの検証が含まれます。
- フィールド辞書の検証: UI のすべてのフィールドは、フィールド レベルの検証テスト ケースを作成するのに十分なレベルで定義されています。 フィールドの最小/最大長、リスト値、エラー メッセージなどがチェックされます。
