ソフトウェアが期待通りに動かない事による不都合

  1. 経済的な損失
  2. 時間の浪費
  3. 信用の失墜
  4. 傷害や死亡事故

ソフトウェアの欠陥の原因

  1. エラー(error)
    • 「間違った結果を生み出す人間の行為」
  2. フォールト(fault)
    • 「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」
    • ≒ バグ、欠陥
    • プログラマのエラー(error)によって、プログラムにフォールト(fault)が埋め込まれる
  3. 故障(failure)
    • 「コンポーネントやシステムが期待した機能、サービス、結果を提供できないこと」
    • フォールト(fault)が、発現して故障(failure)になる。
    • フォールト(fault)のあるコンポーネントが使われることがなければ故障(failure)は発生しない
    • フォールト(fault)が無くても、放射能や電磁波、コンピュータウイルスにより故障(failure)が発生する
  4. インシデント(incident)
    • 「ソフトウェア・システムを実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しない事象」
    • ≒ 不具合、傷害
    • テスト環境や期待値の設定が間違っている場合があるので、インシデント(incident)があることが、直ちに故障(failure)があることを意味しない

テストの役割

  1. リスクを低減する
    • リスク = 不確実 x 損失
    • プロジェクトリスク(ヒト・モノ・カネ)
    • プロダクトリスク
      • ソフトウェアやシステムで失敗する可能性のある領域
      • テストが漏れたことにより発生しうる損失や損害に対するリスク
    • リスクベースのアプローチ
      • 適用するテスト技法を決める
      • テストを実行する範囲を決める
      • 重大な欠陥をなるべく早く検出する(テストの優先順位を変える)
      • テスト以外でリスクを減らす方法を積極的に取り入れる
  2. 使い勝手などの非機能要件に関わる課題を発見し、修正することで製品の魅力を高める
  3. 契約や法律上の適格要件や各業界の標準に合致していることを証明するため

品質


  1. 当たり前品質
    • その製品の機能そのものが意図したとおりに動くこと
  2. 魅力的品質
    • その製品が使いたくなるような特徴を持つこと

品質とテスト

  1. 品質を確保する
    • テストを行いインシデントを解消する
  2. 品質を計測する
    • 客観的に判断できる指標で品質を判断する
    • ISO/IEC9126
      品質特性品質副特性
      機能性合目的性,正確性,相互運用性,セキュリティ,適合性
      信頼性成熟性,障害許容性,回復性,適合性
      使用性理解性,習得性,運用性,魅力性,適合性
      効率性時間効率性,資源効率性,適合性
      保守性解析性,変更性,安定性,試験性,適合性
      移植性環境適応性,設置性,共存性,置換性,適合性
  3. プロセス改善のための情報提供をする
    • 同じ原因のフォールト(fault、欠陥)を作り込まない

テストの十分性

テスト作業

作業概要担当者
テスト実行前作業計画リソース配分、期間、終了条件の決定テストリーダー・マネージャー
テスト条件の選択何をテストするのかを決定するテスト担当者
テストケースの設計テスト条件を網羅して確認できるようにテストケースを設計するテスト担当者
テスト実行中の作業実行結果のチェックテスト担当者
テスト終了基準の検証テストマネジャー
テスト結果の報告実施結果・インシデントの対応結果・終了基準の達成度合いをステークホルダーに報告テストマネージャ
テスト実行後の作業テストウェアの整理テストウェアを「資産」化して引き継げるようにする
全体を通して行われる作業コントロール進捗管理・カバレッジ・終了基準の達成状況のモニタリングテストマネージャ

テスト計画

  1. テストの目的を定める
    • 欠陥の検出を主眼にする? 外部IFとの疎通確認をする?
    • 対象範囲の決定
      • サブシステムをテスト対象とするか・システム全体をテスト対象とするか
    • リスクの列挙
      • テストの目的を達成するときに傷害となる要因を挙げる
  2. テストポリシーや戦略を作る
    • テストの目的の具体化 = 終了基準の設定
    • ステークホルダー間で合意をとる
  3. テストの実施方法の決定
    • テスト技法
    • テストアイテム
    • カバレッジ
    • テストウェア
    • テストチームの立ち上げ
  4. テストに必要なリソースを決める
    • 人員・テスト環境・端末など
  5. テストの分析のスケジュールの立案
    • 分析材料をそろえる( RFP を始めとする各種設計書 )
    • 分析のスケジュールを立てる(テスト技術紗々のスキルを勘案すること)
  6. テストの実装・実行・検証のスケジュールの立案
    概算スケジュールリーダークラス以上の開発担当者やプロジェクトマネージャによる概算
    詳細スケジュールテストを実施する開発担当者の積み上げ

テストの分析と設計

  1. テストベースをレビューする
    • RFP、企画書、設計仕様書、アーキテクチャ定義書、社内標準・・・文書化されていない設計
  2. テストベースやテスト対象のテスト容易性を評価する
  3. テストアイテム、仕様、動作、構造などの分析に基づいて、テスト条件を識別し優先順位を付ける
  4. テストケースを設計し、優先順位を付ける
    • テスト条件の設計法 : 大項目→中項目
    • 2つの網羅性を満たすように設計する
      1. 要求や仕様に対するカバレッジ
      2. コードカバレッジ
    • テスト条件の観点
      ユーザ指向フォールト指向
      要件指向ブラックボックステスト
      設計指向ホワイトボックステスト
  5. テスト要件やテストケースをサポートする上で必要なテストデータを識別する
  6. テスト環境を設計し、必要なインフラストラクチャやツール類を洗い出す

テストの実装と実行


  1. テストケースを開発、実装し、優先順位を付ける
  2. テスト手順を開発し、優先順位を付け、テストデータを作成し、テストハーネスを準備し、テストの自動実行スクリプトを書く
  3. 効率よくテストを実行するため、テスト手順をベースにしてテストスイートを作る
  4. テスト環境を正しくセットアップしたことを確認する
  5. テスト手順に従い、テスト手順を人力、もしくはテストツールで実行する
  6. テストの実行結果のログをとり、テスト対象のソフトウェア、テストツール、テストウェアのIDとバージョンを記録する
  7. 実行結果と期待された結果を比較する
  8. テスト実行結果と期待された結果が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する
  9. 実行結果と期待する結果が一致しないケース毎にテスト作業を繰り返す
    確認テストそのインシデントが発生しなくなることを確認する
    回帰テスト関連箇所のテストをやり直し、修正により欠陥を作り込んでいないか or 隠れていた欠陥が無いかを確認する

終了基準の確認とレポート

  1. ドキュメント化
    • 提供を計画しているシステムの内どれがリリースされたかをチェック
    • インシデントレポートの終了作業
    • 未対策の欠陥を変更記録に載せる
    • システム受領(研修に必要なドキュメントを準備)
  2. 次回でも使えるように、テストウェア、テスト環境、テストのインフラストラクチャーをまとめる。
  3. テストウェアを保守部門に引き渡す
  4. 次回のリリースやプロジェクトのために教訓とすべきことを糧にして、テストの成熟度を改善する

テストのコントロール

  1. テスト結果の計測と分析
  2. テストカバレッジ・終了基準のモニタリングと文書化
    • メトリックスの収集と分析
      収集日々
      分析日々〜週次
      • テストの準備作業が完了した割合
      • テスト環境準備で完了した割合
      • テストケースの実行した割合
      • 欠陥情報 (欠陥密度 = 欠陥の数 ÷ プログラムの規模)
        ※「規模」の定義が微妙。いつから何を計るのか決めないと意味のない数字になる
      • 要件・リスク・コードにおけるカバレッジ
      • テスト担当者の主観的な信頼度
      • テスト作業のマイルストーン
      • テストに要するコスト
    • 分析結果は、ステークホルダー全員で共有する
  3. 欠陥修正の影響調査
    • インシデント対処のタイミングを管理する
    • 優先順位、インシデント同士の依存関係、再テストの必要な範囲の特定
  4. 意志決定
    • テストの中断・再開・終了
    • 手に負えなくなったらエスカレーションする

テスト種類と目的

  1. ドキュメントテスト(要件定義書のレビューなど)
    • 欠陥の作り込みの防止
  2. 開発時のテスト(コンポーネントテスト・統合テスト・システムテスト)
    • ソフトウェアの欠陥を修正する
    1. コンポーネントテスト
      • スタブとドライバを使う
      • 非機能(性能)。メモリリーク(リソース)。ロバストネス。ブランチカバレッジ(構造テスト)
    2. 統合テスト
      • コンポーネント間の相互作用
      • 非機能(性能)。トランザクション。OSや外部IFとの相互作用
    3. システムテスト
      • セキュリティテストを行う
      • 本番環境に近い環境でテストを行う
      • 機能・非機能のテストを行う
      • ブラックボックステスト(納入準備)で行う
  3. 受け入れテスト
    • 対象ソフトウェアの品質レベルが十分であることの確認と提示
  4. 保守テスト
    • ソフトウェアの変更時に、新たなエラーが潜んでいないかを確認する
  5. 運用テスト
    • 信頼性や可用性などのシステムの特性を確認する

要件定義              受け入れテスト
  基本設計          システムテスト
    詳細設計     統合テスト
      実装    コンポーネントテスト(ユニットテスト)

デバッグはテストぢゃないよ

テスト欠陥から発生する故障を発見する
デバッグ欠陥の原因を突き止めてソースコードを修正し、正しく修正されたことを家訓する開発作業

テストの7原則

  1. テストは欠陥があることしか示せない
    • 欠陥がないことは示せない
  2. 全数テストは不可能
  3. 初期テスト
    • 作り込んでしまった欠陥を見つけるのは早いほうが良い
  4. 欠陥の偏在
  5. 殺虫剤のパラドックス
    • 同じ観点からのテストばかりをしていると、バグに耐性が出てくる(その観点からはバグが見つからなくなる)
  6. テストは条件次第
    • 実地に使われる環境に近いテストケースを作る
    • 24h365d止められないシステムなのか? 夜間は止められるのか?
  7. 「バグゼロ」の落とし穴
    • あるとき取りまとめたインシデントが全て対処されたとしても、そのインシデント対処の過程で新たなバグ(fault)が埋め込まれているかもよ

テストの独立性

独立性テスト実行者概要
最低開発者本人先入観による影響大。欠陥は一番多く発見できる
開発チーム作成者では見逃してしまうところや、クセによる誤りを指摘できる
社内テスト部門客観的なテストが可能
最高外部団体の認証法令や業界標準規格に準拠していることを証明するため

機能テスト・非機能テスト・構造テスト・確認テスト・回帰テスト

  1. 機能テスト
    • 機能 = 「What(何をするのか)」≠「How(どうやって)」
    • 機能テスト = 機能が仕様通りに実装されているのかのテスト = ブラックボックステスト = 仕様ベースのテスト技法
    • ISTQB では、セキュリティは、セキュリティ機能のテスト (一般的には非機能っぽいけど)
  2. 非機能テスト
    • 非機能 = 「How(どうやって)」 ≠ 「What(何をするのか)」
    • コンポーネントテスト・統合テスト・システムテスト・受け入れテスト、それぞれの段階で非機能テストを行う
    • ISO/ICE9126の観点を参考する
      • 性能テスト
      • ロードテスト
      • ストレステスト
      • ユーザビリティテスト
      • 相互運用性テスト
      • 保守性テスト
      • 信頼性テスト
      • 移植性テスト
  3. 構造テスト
    • システムテストレベルでも構造テストを行うことがあることに注意(制御フロー・ワークフロー)
  4. 確認テスト、回帰テスト
    確認テスト対処したインシデントが発生しなくなることを確認する
    回帰テスト関連箇所のテストをやり直し、修正により欠陥を作り込んでいないか or 隠れていた欠陥が無いかを確認する
  5. 保守テスト
    • 保守テストを行うとき
      1. ソフトウェアの変更作業を行ったとき
      2. 新しい環境への移行作業を行ったとき
      3. システムの入れ替え(改修作業)を行ったとき
    • 影響度分析を行う
    • 影響度分析を元に回帰テストの範囲を決める

静的テスト


  1. レビュー
    フェーズ概要担当者
    1.計画期間見積もり、関係者の招集、開始基準・終了基準の定義マネージャ、モデレータ(まとめ役)
    2.キックオフ全員
    3.個々の準備事前資料(問題点、質問、コメント、静的解析ツールのレポート)の作成・配布、cチェックリストの作成。配付資料の読み込み各担当者
    4.レビューミーティング議事録と課題一覧を忘れずに全員、書記
    5.再作業課題解決各担当者
    6.フォローアップ(a)修正結果の確認、(b)メトリックス(品質データ)の収集、(c)終了基準を満たしているかの確認検証者
     
    公式主導者概要・備考
    非公式レビュー非公式特になしXPのペアプログラミングも非公式レビューの一種
    ウォークスルー非公式作成者
    テクニカルレビュー非公式経験を積んだモデレータ
    インスペクション公式経験を積んだモデレータ記録を残す
     
    • モデレータはまとめ役。レビュアーは特定の分野の専門家
  2. ツールによる解析
    • 構造分析
    • 複雑度分析(ソースコード分析ソフトを使う)
    • モジュール/オブジェクト分析
    • サイクロマティック複雑度
      • M = L - N + 2P
      • L : 分岐数(Link) --> 分岐が収束するときのアークの数も数える
      • N : 行数(Node)
      • P : ブロック(Part)
        if( a == b ){ //L=1
          a++;
        } else {      //L=2
          a = 0;
        }             //L=4(ifとelseが統合されるので2)
      • M = 4 - 4 + 2 x 1 = 2

テストの設計手順

  1. テスト条件を決定し、テストを設計する
    • テスト対象 = 「テストアイテム」= 何をテストするか
    • テスト条件 = テストアイテムをどういう切り口でテストするか
      1. 機能
      2. 構造的要素
      3. トランザクション
      4. 品質特性
    • テストの設計
      • テスト条件をどのような方法でテストするかの戦略を決める
      • その優先順位、影響範囲を付記する
  2. テストケースを定義する
    • テスト条件を具体的にどのようにテストするかを定義する
      • 要件との間に明確なトレーサビリティがあること
      • 期待する出力も記述してあること
    • 一つのテスト条件に付き最低一つ以上のテストケース
  3. テスト手順仕様書を定義する
    • 複数のテストケースをどのような環境でどのような順番で実行するか
    • テスト担当者の力量に合わせた粒度で記述することが必要

テストのアプローチ


  1. 分析的アプローチ
  2. モデルベースアプローチ(過去の指標値を使う)
  3. 方法論的アプローチ
  4. プロセス準拠アプローチ
  5. 動的で経験則に基づいたアプローチ
  6. コンサルテーションベースのアプローチ
  7. 回帰的アプローチ

アプローチ方法を決める要素

  1. リスク
  2. スキル・経験
  3. 規則
  4. 特性(プロダクトや業界の)

テストの設計手法

ISTQBの呼び名一般的な呼び名
仕様ベースブラックボックステスト
構造ベースホワイトボックステスト
経験ベース

仕様ベース

  1. 同値分割法
    • 入出力の組を同値クラスにまとめて、同値クラス内の代表的なデータをテストする
    • 値による同値クラス (0〜100、100〜1000 など)
    • 時間による同値クラス (イベント発生前、後 など)
    • カバレッジ = テストケース数 ÷ 同値クラス数
  2. 境界値分析
    • 0〜100の同値クラスについて
    • ISTQB では、-1,0,100,101 を境界値分析としてテストしろと言っている
    • 一般的には、-1,0,1,99,100,101 をテストするのが無難
    • カバレッジ = テストケース数 ÷ (同値クラス数 x 2)
  3. デシジョンテーブルテスト
    • x,y,z が入力。a,b が出力とすると
      規則1規則2規則3
      条件x15100
      条件y26200
      条件z37300
      結果a10nullerror
      結果b20-1
      とか
    • 順列組み合わせでテストケースを列挙しやすい
    • カバレッジ = テスト実施数 ÷ 規則数
  4. 状態遷移テスト
    • 状態遷移図
    • 状態遷移表
      状態1状態2
      イベント1状態2になる状態1になる
      イベント2状態1のまま状態2のまま
    • chowカバレジ(0スイッチ)=セル網羅基準
      状態遷移表を全網羅しているかのカバレッジ
      状態1 → イベント1 → 状態2
      状態1 → イベント2 → 状態1
      状態2 → イベント1 → 状態1
      状態2 → イベント2 → 状態2
    • chowカバレジ(1スイッチ)
      2つの遷移と3つの遷移を網羅しているかのカバレッジ
      状態1 → イベント1 → 状態2 → イベント1 → 状態1
      状態1 → イベント1 → 状態2 → イベント2 → 状態2
      状態1 → イベント2 → 状態1 → イベント1 → 状態2
      状態1 → イベント2 → 状態1 → イベント2 → 状態1
      状態2 → イベント1 → 状態1 → イベント1 → 状態2
      状態2 → イベント1 → 状態1 → イベント2 → 状態1
      状態2 → イベント2 → 状態2 → イベント1 → 状態1
      状態2 → イベント2 → 状態2 → イベント2 → 状態2
  5. ユースケーステスト
    • ユースケーステストのフォーマット
      項目概要・備考
      ユースケース名
      目的
      アクタ
      事前条件
      事後条件
      基本フロー
      代替えフロー基本フローと事前・事後条件が同じだが、マイナーな操作
      例外フロー基本フローと事前・事後条件が違う
      備考
      • ユースケース図ではなく、ユースケース記述からテストケースを作る

構造ベース

経験ベース

テストの見積もり

構成管理とテスト

IEEE829-1998

ドキュメント体系

PRJECT DOCUMET        TEST ITEM
(プロジェクトドキュメント)     (テスト実施対象)
ITEM DOCUMENT           |
(開発関連ドキュメント)       |
 ↓                     | 
TEST PLAN               |
(テスト計画)            |
 ↓                     |
TEST DESIGN SPEC        |
(テスト設計仕様)        |
 ↓                     |
TEST CASE SPEC          |
(テストケース仕様)      ↓
 ↓                    TEST ITEM TRANSMITTAL REPORT
TEST PROCEDURE SPEC    (テスト実施対象伝達報告書)
(テスト手順仕様)        |
 ↓                     ↓
[ ■■■■■ TEST EXCLUSION ■■■■■ ]
 ↓
TEST LOG
TEST INCIDENT REPORT
 ↓
TEST SUMMARY REPORT

テスト計画書の構成

テスト計画書の内容

テストレポートの内容

インシデントレポートの内容

インシデントレポートの目的

  1. 開発者に、問題を明らかにし、原因を特定して解決していけるように情報を提供する
  2. テストリーダーに、テスト実行中のシステムの品質や、テストの進捗に関する情報を提供する
  3. テストプロセスの改善のためのヒント提供する

インシデントレポートの対処手順

              -------- Failure
             ↓           ↑
Open ----> Assign ----> Test ----> Close ---> End
              |
               -------> Reject -------------> End

Computer


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS   sitemap
Last-modified: 2009-08-29 (土) 11:05:38 (2660d)
ISBN10
ISBN13
9784061426061