ソフトウェアテスト vol.1

Study software test

目的

  • バグ出し
  • 品質保証
    • 納品物に含まれることもある

WaterFall

設計→
　　実装→
　　　　テスト
それぞれにテストがある。
1.用件定義→ 8.受け入れテスト
2.外部設計→ 7.総合テスト
3.内部設計→ 6.結合テスト
4.実装→5.単体テスト

  • 完璧なものを渡すことが条件。
    • 自分の段階で品質を落とさない、むしろ上げる。
  • 実装→単体テストは一人で完結するから重要。

keyword:検収
keyword:スパイラルプロトタイプ
今回は結合テスト、総合テストの話。

演習問題：テストケースの作成

次のプログラムに付いてテストケースを作成
入力した三角形の種類を答えるプログラム
・正三角形
・二等辺三角形
・ただの三角形
　１−１００までの整数のみ受け付ける
仕様にないものも書きなさい。

回答
正三角形 3 3 3
二等辺 3 3 10
ただの 4 5 6
整数外 10.3 34.2 98.1
範囲外 103 800 489
文字 a b c
入力が1つのみ(範囲内) 5
入力が1つのみ(範囲外) 101
入力が1つのみ(文字) a
入力が1つのみ(整数以外) 10.3
入力が2つのみ(範囲内) 5 3
入力が2つのみ(範囲内/同じ値) 5 5
入力が2つのみ(範囲外) 101 900
入力が2つのみ(文字) a b
答え合わせ

Lv.1

  • 正常系：表示結果確認
    • ２辺のみ同じ長さで二等辺三角形
      • 3通り全部実施(5-5-3,5-3-5,3-5-5)
        • １〜１００を受付
          • すべてに1入力
          • それぞれに0入力

Lv.2

  • 異常系：入力形式の異常
  • 異常系：入力値の異常

Lv.3

  • 異常系：三角形にならない

→仕様抜け：対象システムの理解が重要

プログラム自体は簡単でもテストの難しさはそれに関係ない。
きっちりやるとかなり難しい。

テスト技法

技法を使う目的

  • すべてを入力するわけにはいかないので省略。

どう省略するか？

  • バグがありそうなところだけをもれなくテストする。
    • もれなく・効率的に。

種類

ブラックボックステスト

  • 中が見えない
  • 箱の中は見ず入力と出力で判断する。
同値分割
  • 入力値を意味毎に分ける
  • それぞれの代表値でテスト
    • もれなく→意味別に全部網羅
    • 効率的に→代表値だけ
分割の範囲
  • 動作が変わらない値に分類
    • 仕様上、変わらない
    • 経験上、変わらない
  • 工数と重要度を考えて判断
どれを代表値にする？
  • バグが出そうなもの
    • 経験上出やすい:「ソ」とか
    • 理論上出やすい:境界値分析
  • よく使われる値
境界値分析
  • 処理の境目にバグがひそみやすい
    • for文で不等号を間違えるなど

ページャーの例

  • 5件未満は目次が表示しない
  • 6件以上は目次を表示する場合

→5と6が境界値

0は例外的な値
  • 0はバグが出やすい

→常にテストするべき

    • 数字の0
    • 0件表示
      • null,空文字列,falseとも関係
最低限行いたい点
  • 0件表示
  • 5件表示
  • 6件表示

→0は常にテスト対象
1件のみ表示は５件表示とほぼ同じテストになる。

ホワイトボックステスト

制御パステスト
  • C0網羅(命令網羅)
    • 命令をテスト
    • 分岐条件は範囲に入らない
  • C1網羅(分岐網羅)
    • 分岐条件をテスト
    • 命令も一緒に確認される
  • C2網羅(条件網羅)
    • 全組み合わせチェック
    • 命令の「組み合わせ」が確認される

→もれなく・効率的には無理。
どこまでやるか？

  • 重要な部分
  • ロジックが難しい部分

→ブラックボックステストでは検出できない部分を補う

コーディング視点から

  • 分岐が多いとテスト条件が増える
    • if・forを減らす、単純にする
  • コードが難しいとテストすべき箇所が増える
    • 簡潔なコードを書くようにする

奇麗なコードとはテストのしやすいコード。
「よいコード」はテストも楽になる

100%は困難

  • リソースがらみのテストは難しい
  • テストをしたくなっても再現困難なコード
    • 例外処理に不安のあるコードは書かない
      • 実績があるコードに書き換える etc...

モンキーテスト

  • でたらめな入力をするテスト
  • バグ出ししか出来ない
    • 品質保証にはならない
  • バグを見つけても氷山の一角

問題点はあるが良いところを使う

  • あやしいところを集中的に。
    • 計画的なテストは浅く広くになりがち
  • むちゃくちゃなテストが出来る
  • 開発者以外にやってもらう
  • 自動化して長時間実行
    • 日本語変換等同値分割しにくいものなどに有利