[まとめ] 知識ゼロから学ぶ ソフトウェアテスト

ソフトウェアテストの基本ーホワイトボックステスト

ホワイトボックステスト

• プログラムの論理構造が正しいかを解析するテスト
• 論理構造の正しさのみをテストする＝ソフトウェアの仕様がまちがっていることから起こるバグは発見できない

制御パステスト法

• プログラムがどのような振る舞いをして、どのように制御され実行されていくかをテストする。
• カバレッジ率（coverage rate）
• カバレッジテスト
  • ステートメント（命令文）カバレッジ
    • コードの中の命令文を少なくとも1回は実行
  • ブランチカバレッジ
    • 分岐コードに対してそれぞれの判定条件が TRUE、FALSE の結果を少なくとも1回ずつ持つようにテストケースを書く
    • ステートメントカバレッジよりはテストケースを網羅できるが、その分テストケースの数が多くなる
    • ブランチカバレッジよりも強いカバレッジ手法はいくつもある
• データフローパステスト法

ブラックボックステスト

同値分割法・境界値分析法

ユーザーによる様々な入力に対してソフトウェアが十分対応できるかを確認するテスト手法。
それぞれセットで用いることが多い。

同値分割法

入力領域を「同値クラス」という部分集合に分割する。その部分集合に入る入力値を等価とみなす作業。

• 有効同値：プログラムが期待する入力値
• 無効同値：有効同値以外のあらゆる値

有効同値は、論理的にはどんな数値でもいいが、一般的にはユーザーがよく使いそうな値を設定する

無効同値はテストケース多くなる傾向にある→省略する必要がある

0 は常に特別な値 (= 常に境界値) とし、入力値として 0 が含まれている場合は、必ずテストケースに含めること

境界地分析法

プログラムで「境界」と呼ばれる場所は常にバグが潜んでいる。

「境界」：無効同値と有効同値の間の値

ディシジョンテーブル

• すべての入力パターン (状態) を表にし、入力に対する動作もしくは出力を明記する。
• 非常に小さいソフトウェアか、おおきなソフトウェアの一部分をテストするときに使うのが最適

状態遷移テスト

• 「状態」をモデル化してテストを行う手法
• 期待されるバグ
  • 期待していない状態に遷移するバグ＝条件分岐が正しく行われていない
  • 遷移自体がない場合 = ある状態からある状態へ遷移できないバグ
• デメリット
  • 状態の数が多くなるとモデルが複雑化し、テスト項目が増えすぎてテストできなくなる
  • モデリングに時間がとられて、テストする時間が減る

ランダムテスト

• やみくもテスト手法（別名：アドホックテスト、アドリブテスト、ランダムテスト、モンキーテスト）
• ランダムテストで見つからないバグは多岐にわたる
  • やってみるとバグがたくさん見つかるが、あくまで氷山の一角 (全体の 数 10 % 程度)

エラー推測

• 仮説的推論
  • データを集めて、なぜこういうデータになったかという仮設を立てる
  • 個々のデータについて、なぜ上記の仮説にあてはめるかという説明付けをする
• Whittacker のエラー発見テクニック
  • 下記4つの処理に対しテストケースを作成すること効率的かつ致命的なバグを発見できる
    • 新規プロジェクトで有効
  • 入力処理
    • 入力部分があれば、様々なデータサイズやデータタイプを入力してみる
    • データの入力制限があれば、他の方法でその制限を超える入力をする
  • 出力処理
  • データ処理
  • 計算処理
• 既存のプロジェクトの場合の仮説の組み立て手順
  • 以前の開発バージョンのサイクルの中でどのようなバグが発見されたかの傾向を見つける
  • どのような種類のバグ (データ, コントロール など) が多く発生したのか調べる

システムテスト

システムテストと機能テスト

機能テストは前工程、システムテストは後工程

負荷テスト

• 非機能要件を洗い出す
• 負荷テストは自動化する

パフォーマンステスト

• パフォーマンスの要求定義に書かれた通りのテストケースを書かない。
• 要求定義どおりに動かないようなテストケースを設計する。
• 設計から見直す場合もあるので、後回しにせず、定期的に実行するのが理想

ユーザビリティテスト

• 実際に使うユーザーもしくはそれに近い人に使用してもらい、 UI などの使い勝手や仕様をチェックしてもらう。ユーザー側に立って、要求が満たされているかどうかを確認する。
• 筆者的に、ユーザビリティテストは、開発者やテスト担当者が行うべきではなく、第三者機関などのそのソフトウェアを知らない人にテストしてもらうのがベスト。

セキュリティテスト

バッファオーバーフローとフォーマットバグ

というものがある

セキュリティ機能テスト

• 開発ができること
  • コードレビュー・静的解析ツール
• QA もできること
  • 境界値分析を用いた入力テスト (心得)

セキュリティシステムテスト

• 主な攻撃の種類
  • 不正プログラム（malicious code）
  • 情報漏洩・なりすまし（パスワード）
  • クロスサイトスクリプティング
  • スパイウェア
• テスト手法
  • 解析
  • 変更もしくは削除
  • 監視

スモークテスト

• ビルド確認テスト
  • 開発者の単純なミスでソフトウェアが全く動かなくなっていないか
  • ビルドされたソフトウェアが十分テストにたえられるものか
  • コードにある真のバグを見つけられる状態にあるのか

回帰テスト（リグレッションテスト）

• バグがちゃんと直っているか確認（大前提）
• バグを直すことで、他に関連するバグが発生していないかの確認
• バグはプログラムのある一部分に固まっている。どこかにバグが発生したら、その機能にバグが起こりやすいという認識をもち、隠れたバグを探す。
• 回帰テストの自動化について
  • リリースタイミングに行われる＝頻繁におこなわれるテストではないので、自動化のメリットはあまりない。

ソフトウェアテスト運用の基本ーテスト成功の方程式

コストと品質のバランス

テストにかかった費用＋サポートにかかる費用＋メンテナンスにかかる費用＝最小値

テストプラン

• IEEE 829 のテンプレートがある
• 「テストするべき機能」と「テストする必要がない機能」をちゃんと定めるべし
• スケジュール
  • テストスケジュールは開発スケジュールに依存する (大前提)

ソフトウェアテストにおけるリスク

リスク = 問題の発生確率 × 発生した場合のダメージ

• 複雑度
• 新規性
• 変更
• 上位依存性

リリース判断

• プロジェクト開始前に「リリース基準」を設けておくとよい
  • 指標となるもの：残存バグ件数, 重要度が高いバグがない, TC の成功率 など
• 直前の修正は、深刻なものでない限りは、基本的にはしないほうが良い

ソフトウェア品質管理の基本ーソフトウェア品質のメトリクス

メトリックス = 品質を客観的に測る指標。
品質はアウトプットが見えにくい

マイクロソフトのメトリクス例

• バグのメトリックス
  • 時間軸でのバグ発見数
  • コンポーネントごとのバグの発見数
• テストのメトリックス
  • コードカバレッジ
  • テスト担当者以外のバグの発見数
  • テストケースの数、テストの自動化率
• ソースコードのメトリックス
  • 追加・削除・更新されたコードの行数
  • KLOCs (どのくらいコードの行数が増加したか)
  • コードの複雑度 (McCabe のルール)
• スケジュールのメトリックス
  • はじめに立てたスケジュールと実際のずれ

メトリックスデータ（品質の指標）を取る

• なるべく誤差がなく人間の私情・恣意に左右されないものを選ぶ
  • 不適：テストケースの数
  • 適切：バグの数
• 開発するソフトウェアの品質を十分代表するものを選ぶ
  • 「木を見て森を見ず」にならない

バグの数を管理する（バグメトリックス）

• バグの重要度
  • 単純なバグの数だけでなく、重要度（高 ~ 中 ~ 小）を含めて指標とするべき
  • バグの数が同じでも、重要度の高いバグが少なければ、安定した品質と言える
• バグの修正にかかる時間
  • バグの修正にかかる時間は、リリース直前になればなるほど短くなるのが理想
    • 直前まで新規機能を追加したり、バグの修正が困難だったたするとそうはいかない…
• モジュール・コンポーネントごとのバグの数
  • テスト担当者のスキルにも影響するため、一概にバグ数だけで判断しないよう注意する

コードカバレッジメトリックス (最重要メトリックス)

カバレッジが XX % を達成していなければ、リリースしない

その他のメトリックス

• ソースコードメトリックス
  • コードの行数
• 複雑度