3.1 静的技法とテストプロセス　★★

3.1.1 静的技法の特徴　★★

コードを実行したりテスト対象を動作させなくても実施できるというメリットがある。

静的技法の種類は、以下に分類できる。

  • インスペクションなどのレビュー
  • 構造分析
  • 複雑度分析
  • モジュール／オブジェクト分析

静的技法は内部構造を意識して実施されることが多いため、動的テストに比べてソフトウェアの構造上の欠陥を容易に検出できる。

一方、不正な動きや故障を検知することは苦手。

両者は互いに補い合っているため、両方を実施することで最大の効果が期待できる。

3.1.2 レビューの目的と効果　★

目的は、テスト対象を熟知した技術者によるソフトウェアの構造上の欠陥を検出すること。

早期にレビューを実施し、欠陥を検出・修正することで、以下の効果が期待できる。

  • 開発生産性が向上する
  • 開発期間が短縮できる
  • テストのコストや時間を減らせる
  • システムのライフサイクルを通じたコストを削減できる
  • 欠陥の数が減る

副次的な効果として、以下も期待できる。

  • 良好なコミュニケーションがとれるようになる
  • 動的テストでは見つけにくい、要件定義などで漏れている機能や処理を見つけることができる

3.1.3 静的テストと動的テスト　★★

各技法には得意なものと不得意なものがある。

ソフトウェアの内部構造に関する欠陥の検出は、レビューや静的解析が有効。

パフォーマンスや使用感(ユーザビリティ)などは、実際にテスト対象を動作させないと、正確に確認することは不可能。

静的テストの方が、動的テストより簡単に見つけることができる欠陥は以下の通り。

  • 規格からの逸脱
  • 要件の欠陥
  • 設計の欠陥
  • 保守の不十分性
  • インタフェース仕様の不正

3.2 レビュープロセス　★★

レビューは開発者が行うものと考える人が多いが、テスト技術者が参加するものもある。

3.2.1 レビューの必要性　★

レビューの必要性を理解していない技術者も多い。「レビューは不要で動的テストだけ行う」という技術者までいる。

思い込みによる欠陥が多く、レビューによる効果は大きい。

3.2.2 公式レビューの活動　★

公式レビュー：事前に計画、準備をするなどの決まったレビュープロセスをもったレビュー。以下6つの活動がある。

  • 計画
    • マネージャはとりまとめ担当者(モデレータ)を決定し、目的を定める。
    • 必要な人材を選出する。
    • レビューのスケジュールを立てる。
    • 開始基準と終了基準を定義する。
  • キックオフ
    • 計画の立案が完了した後に行う。
    • レビュー目的に対する理解を深めることが目的。
  • 個々の準備
    • 資料を読み、問題点／質問／コメントをまとめ、チェックリストを作成する。
  • レビューミーティング
    • モデレータ、作成者、レビューアで議論する。議事録を取ることもある。
    • 課題を一覧にまとめる。
  • 再作業
    • 課題の一覧をもとに、成果物の修正を行う。
  • フォローアップ
    • 課題および欠陥を正しく対処したかを検証する。
    • 修正内容の難易度および修正量を勘案して、再度レビューが必要かどうか判断する。

3.2.3 役割と責任　★

以下の5つの役割を持つ人が存在する。

  • マネージャ
    • プロジェクトマネージャが担当することが多い。レビューの実施方針を決定する。
    • プロジェクト全体のスケジュールや進捗状況をもとに、レビューのスケジュールを立てる。
    • レビューの目的が適切かどうか判断する。
    • モデレータを任命する。※マネージャはレビューミーティングには参加しない方が良いと言われている。
  • モデレータ
    • レビューミーティングのとりまとめ役。
    • 計画・見積、レビューアの人選、レビューの運営、ミーティング後のフォローアップ等。
  • 作成者
    • レビュー対象の成果物に責任を持つ人。
    • レビューに必要な資料の作成およびミーティングの結果をもとに課題を検討し、修正作業を行い、結果をまとめる。
  • レビューア
    • ある特定の分野に詳しい人が適任。
    • キックオフで自分の役割を確認し、必要な準備を行い、ミーティングの場で必要な指摘を行う。
  • 書記(記録係)
    • 公式性の高いレビューの場合、レビューで取り上げたすべての課題、問題点、未解決事項を記録する。

3.2.4 レビューの種類　★★

代表的なレビューの種類として、次の4つがある。

  • 非公式レビュー
    • 決まったプロセスはない
    • 2人1組でプログラミングしたり、リーダが設計やコードを技術指導的にレビューする形式をとることがある
    • レビュー結果をドキュメント化することがある
    • レビューアにより効果が様々である
    • 主な目的はコストや時間をかけずにある程度の効果を出すこと
  • ウォークスルー
    • 作成者が進行を主導する
    • シナリオをもとに同僚のグループが机上で処理をたどる形式を取ることがある
    • 制約をつけないセッション
    • レビューアの事前準備ミーティングを行うことがある
    • 指摘の一覧を含む、レビューレポートを準備することがある
    • (作成者以外が)記載者になることもある
    • 運営により、きわめて非公式のものから高度に公式なものまである（通常は非公式）
    • 主な目的は、ソフトウェアの内容を学習し、理解し、欠陥を見つけること
  • テクニカルレビュー
    • 欠陥摘出には、同僚や技術のエキスパートが参加し(管理者が参加する場合もある)、そのプロセスはあらかじめ定義し、ドキュメント化してある
    • 管理者の参加しないピアレビューとして進めることがあるかもしれない
    • 経験を積んだモデレータ(作成者ではない)が進行を主導するのが理想
    • レビューアが事前ミーティングを準備する
    • チェックリストを作ることがある
    • 指摘一覧、ソフトウェア成果物が要求事項を満たしているかどうかの判定、そして適宜、指摘事項に関連する推奨事項を含むレビューレポートを準備する
    • 運営により、きわめて非公式のものから高度に公式なものまである
    • 主な目的は、ディスカッションすること、判断を下すこと、別の方法を評価すること、欠陥を見つけること、技術的な問題を解決すること、仕様や計画、規定、標準に準拠していることをチェックすることである
  • インスペクション
    • 経験を積んだモデレータ(作成者ではない)が進行を主導する
    • 同僚によるチェックが一般的
    • 各人の役割が決まっている
    • メトリクスの収集が含まれる
    • 規則やチェックリストを使い形式に基づいたプロセスを進める
    • ソフトウェア成果物の受入に対する開始、終了基準を決める
    • インスペクション前の準備が必要である
    • インスペクションのレポートや指導一覧を書く
    • 形式の決まったフォローアッププロセスがある
    • プロセス改善が含まれる場合がある
    • ドキュメントを読み上げる人を加えたりする
    • 主な目的は欠陥の検出である

3.2.5 レビューを成功させるために　★★

レビューを成功させるポイントは次の通り。

  • レビュー開始前に目的を明確にする
  • レビューの目的にふさわしい人に参加してもらう
  • テスト担当者は、レビューに寄与する価値あるレビューアであり、また、製品について学ぶことで、より早いテスト準備を可能にする
  • 欠陥を多く見つけることは目的に合致しており、歓迎すべきことである
  • 人の問題や心理的な要素も扱う(作成者にとってそれもプラスの経験にする)
  • レビューは信頼の下で実施される。その結果は参加者の評価に使用しない
  • 目的を達成するために、対象のソフトウェアあるいはレビューアのタイプやスキルレベルに応じて最適のレビュー技術を適用する
  • 欠陥を効率良くみつけるためにチェックリストを遣ったり、各人の役割を決める
  • インスペクションのような公式性が高いレビューの場合、レビュー実施の技術教育を実施する
  • レビュープロセスを正しく進めるには、管理者の支援が必要(たとえば、プロジェクトのスケジュールにレビュー時間をあらかじめ確保するなど)
  • レビューの方法を学習したり、プロセスを改善したりすることも目的である

3.3 ツールによる静的解析　★★

手で行う静的テスト技法をレビューという。

人手ではなくツールで行う場合は、静的解析と呼ぶ。

設計データやソースコード、実行コードなどを機械的、形式的にチェックおよび解析する。

3.3.1 静的解析ツールの機能　★

ソースコードのチェック、基本的なツールとしてはコンパイラがある。一般的には、コンパイルエラーを取り除いた後の解析を静的解析という。

  • コーディング規約に従っているか
  • 論理上のミスはないか
  • 欠陥に繋がる記述はないか

3.3.2 静的解析の効果　★

レビュー前に単純なミスを修正でき、レビュー時間の節約になる。見落としを防げる。

融通が利かず、不要な個所の欠陥として指摘してしまうことがある。

3.3.3 静的解析と動的解析の違い　★

動的テスト：欠陥によって引き起こされる現象を見つけるだけなので、真の原因にたどり着くまでに時間やテクニックが必要。ただし、動的に状態や論理が変化することによるエラーを見つけられる。

静的解析ツール：欠陥の箇所そのものを指摘するので、素早く欠陥を修正することができる。逆に、コードに現れない仕様の欠陥は見つけることができない。

3.3.4 静的解析ツールによる欠陥指摘の具体例　★★

if(a = 0) {　←[==]が正しい。静的解析ツールで検証

a++　　　　←[;]がない。コンパイラで検証

} else {

a=5;　　　　←[5]ではなく[0]が正しい。レビューや動的テストで検証

}

3.3.5 静的解析ツールによって指摘できる欠陥　★

  • 値を定義していない変数の参照や、定義はしてあるが使わない、または不適切に宣言されている変数
  • 引数の矛盾など、モジュールやコンポーネント間などのインターフェースの不整合
  • 到達できないコード(デッドコード)
  • 欠落した、誤ったロジック(潜在的な無限ループ)
  • 過度に複雑な構造
  • 標準、または個別のコーディング規約への違反
  • セキュリティの脆弱性
  • 書式に関するルール違反
  • クラスや関数の宣言に関するルール違反
  • CからC++、ビット幅の異なるCPUなど、ほかの環境へ移行する際に注意すべきルール

3.3.6 ツールによる静的解析の注意　-

静的解析は万能のツールではないので、素直に他の適切な手段を取ったほうが良い場合もある。

特に、仕様の欠陥は検出困難

3.3.7 静的解析ツールでのメトリクス　-

サイクロマティック複雑度 M = L(リンク) – N(ノード) + 2P(独立した処理部分の数)

10以内に収めるのが良いと言われている。

Follow me!