今はもう動かない？それとも、まだ動かない？〜静的テスト
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
推しの子一期が終わったし、更に水星の魔女も地獄楽一期も終わってしまって僕は何を糧に生きればええんや？と抜け殻になりかけてたよ。
でも、来週から文スト新シーズンがスタートするから何とか生きていけそうな気がするんだ。やったね！
生きる糧も見つかったので今回からは静的テストについてのお話を進めていけるよ。
静的テストは端的に言うとソフトウェアを動かさずに評価することだよ。
そして、ソフトウェアを実行して評価するテストの方を動的テストと呼んで区別しているよ。
良い子のみんなや多くの人がソフトウェアテストと聞いてイメージするのが動的テストの方じゃないかな？
静的テストの対象範囲
ほとんどの成果物に対して静的テストでの調査が可能とされているよ。
• 仕様(ビジネス要件、機能要件、セキュリティ要件など)
• エピック、ユーザーストーリー、受け入れ基準
• アーキテクチャーおよび設計仕様
• コード
• テストウェア(テスト計画書、テストケース、テスト手順、自動化テストスクリプトなど)
• ユーザーガイド
• Web ページ
• 契約、プロジェクト計画、スケジュール、予算計画
• 構成のセットアップとインフラストラクチャーのセットアップ
• モデルベースドテストで使用するアクティビティ図などのモデル
ほとんどがソフトウェアに関連資料のドキュメントだね。
テストベースになる要件、仕様に関するドキュメントやテストウェアのテスト計画書、テストケースと言ったドキュメントに対して行う静的テストがレビューと呼ばれているよ。
レビューは、読んで理解できるあらゆる作業成果物に適用可能とされているんだ。
これによって開発の初期段階から静的テストによる評価が可能になって、早期テスト、シフトレフトに貢献できるんだね。
一方でコードやモデルなどの形式的な構造で作成された作業成果物に対して行う静的テストが静的解析と呼ばれているんだ。
静的解析は静的解析ツールによって問題点の調査が可能となっているよ。
静的テストのメリット
静的テストには、さまざまなメリットがあるんだ。
• 欠陥の検出と修正をより効率的に、しかも動的テストを実行する前に行うことができる。
• 動的テストでは容易に検出できない欠陥を識別できる。
• 要件の不整合、曖昧性、矛盾、欠落、不正確性、冗長性を明らかにして、設計時またはコーディ ング時に欠陥が混入するのを防止できる。
• 開発の生産性を向上できる(設計の改善、保守性の高いコードなど) 。
• 開発にかかるコストと時間を削減できる。
• テストにかかるコストと時間を削減できる。
• ライフサイクルの終盤または本番リリース後に検出される欠陥数が減少し、ソフトウェアの存続期間にわたる全体的な品質コストを削減できる。
• レビューへの参加過程でチームメンバー間のコミュニケーションを改善できる。
要件/設計仕様レビュー、バック ログを洗練させる作業などソフトウェア開発ライフサイクルの初期から静的テストを行うことで動的テストを実行する前に欠陥を早期に検出でき、ライフサイクルの終盤に検出した欠陥よりも、はるかに低コストで除去、修正できるのは大きなメリットだよね。
動的テストで見つけにくい欠陥を見つけたり、早期の改善によって動的テストまでにソフトウェアの品質向上に期待もできるよ。
それでも動的テストってやるの？
静的テストのメリットを見ると動的テスト要る？と思えるかもしれないけど、それぞれに異なる種類の欠陥を検出することが求められてるから、相互に補完する関係になるんだ。
ソフトウェア上で特定のパスがほとんど実行されない（相当にレアケース）、または到達が難しい操作などの動的テストでは見つかりにくい欠陥は静的テストで見つけることが期待されてるよ。
動的テストが外部から見える振る舞いに焦点を置くことが典型的であるのに対し、静的テストは作業成果物の整合性と内部品質を向上させることも特徴の一つなんだ。
静的テストは動的テストに比べて、以下の欠陥を早期かつ安価に検出して修正できると述べられているよ。
• 要件の欠陥(例えば、不整合、曖昧性、矛盾、欠落、不正確性、冗長性)
• 設計の欠陥(例えば、非効率なアルゴリズムやデータベース構造、高い結合度、低い凝集度)
• コードの欠陥(例えば、値が定義されていない変数、宣言されているが使用されることのない変 数、到達不能コード、重複したコード)
• 標準からの逸脱(例えば、コーディング標準を遵守していない)
• 正しくないインターフェース仕様(例えば、呼び出し側のシステムと呼び出される側のシステム
で異なる単位の使用)
• セキュリティの脆弱性(例えば、バッファオーバーフローが発生する可能性)
• テストベースのトレーサビリティもしくはカバレッジが不十分もしくは不正確(例えば、受け入 れ基準に対するテストケースが欠落している)
また、不適切なモジュール化、低いコンポーネント再利用性、分析が困難で新しい欠陥の混入なしに修正することが困難なコードと言った保守性欠陥のほとんどは、静的テストでのみ検出できるとされているよ。
一歩で動的テストではソフトウェア実行でしか見つからない欠陥を見つけることが期待されることになるね。
OSやブラウザや機器などの環境の差で発生する欠陥やインターフェース間の通信などが対象となるんだ。
静的テスト、動的テストの違いを理解して組み合わせることで、よりテストの効果を高めることができるよ。
ちなみに静的テストの有用性ばかりをアピってるけど、どうせならメリットとデメリットの両方を書いて欲しいところだよね。
例えば静的テストは要求や仕様変更が多いプロジェクトだとレビュー回数も増え工数が増加してしまうとかあると思うんだけど、どうなんだろう？
良い子のみんなもメリット、デメリットを考えて、そこから理解を深めておくと実際の現場で困らないと思うよ。
次回からは静的テストの中でもドキュメント類の調査、レビューについて解説していよ予定だよ。
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？