2024/07/24

1

ソフトウェアテストは、品質改善のためにもっともポピュラーな方法

2

ホワイトボックステストとは

プログラムの論理構造がただしいかチェックする

ホワイトボックステストの種類

• ステートメントカバレッジ
  • プログラム内部の命令文をテストする
  • if条件がTrueになる条件をテスト

2024/07/25

1

プログラムのバグは、20%のコードから80%のバグがでるらしい

2

• ブランチカバレッジ

  • すべての条件分岐を一回以上試す。
  • すべてをもうらすることはできないので、カバレッジ基準をきめて全体の60%~90%テストする。

• カバレッジを100%達成したからといって、すべてのバグを発見できるわけではない。

  • ループ処理やエラー処理など

ホワイトボックステストの復権

• アジャイル開発によって、ホワイトボックステストが実施しやすくなった。
• TDD
  • red テストが失敗するコード
  • green テストが何かしらの形で成功するコード
  • クリーン　コードをきれいにする。

2024/07/26

3

ブラックボックステスト

出力、入力、保存、計算の4つをテストする。

• 同値分割法
  • 入力と出力のテスト
  • 入力閾値を同値クラスターに分割してテストする。
  • すべてのパターンを網羅することはできないため、省略してもよいが省略した箇所でバグが出ないようにする。
  • 同一の意味合いをもつテストケースを避けることができる。
• 協会値分割法
  • 入力の境界値をテストする。
  • 有効と無効の一番近い境界をテストする。
• デシジョンテーブル
  • 入力と出力の組み合わせが、複雑な場合に使用する。
  • 入力との組み合わせと、その出力を明記してテストする。

• GUIのテスト
  • 状態と遷移（イベント）を定義する。
  • 状態遷移マトリックスで、各状態のときに想定されるイベントを網羅し、想定外のイベントが起きないか確認する。
  • ただし、状態が多いと人力では確認できないので、ツールを使用するとよい。
• ランダムテスト
  • 境界などを使用せずランダムにテストする。
  • 一部のバグを見つけることができるが、見つけられるのは氷山の一角

参考

• ディシジョンテーブルの作り方
  • 条件の組み合わせと動作の対応表をつくり、特定の条件で想定どおり動作が起こるかテストする。
• ディジョンテーブルと境界値テストの関連
  • ディジョンテーブルのTF判定の中に、境界値テストを組み入れることがある。
    • 例：金額は有効値か？←これに対して、境界値テストをいれる

4

探索的テスト

• テストケースベースのテストと比べて、効率的にテストできる。
• 事前にテストケースを想定するのではなく、ソフトウェアを使いながら、テストする。

どうやるか？

• クライテリアをきめる。
• 探索的テストを実行する。
• バグを記録する。

補足資料

• https://service.shiftinc.jp/column/9102/
  • アドホックテストと違い、事前の目的・クライテリアを決める、試行をドキュメントに残すという工程をいれることで、場当たり的なテストになることを防ぐ。
• https://shiftasia.com/ja/column/探索的テストとは/
  • 不具合の検出ではなく、品質の担保をするのであれば、テストケースベースのテストを行う。
• https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf
  • スライド形式でわかりやすい。

5

非機能要件のテスト

• 非機能要求はそれぞれのカテゴリーごとにテストする必要がある。
• テストで需要な非機能要求は
  • パフォーマンス
  • セキュリティ
  • 信頼性
• 他にもいろいろあるが、機能要求のテストでカバーできることが多い。

パフォーマンステスト

• パフォーマンステストは後回しにしない。
  • パフォーマンステストで発見されるバグは、根本的なところに原因があることがある。
• パフォーマンスの要件は明確にする

セキュリティテスト

• モジュールに分解してテストする。
• ファジングテスト
• ツールを使うとよい。

信頼性テスト

• バグは有限であると仮定してテストする。
• MTBF（平均故障間隔）
  • 信頼度成長曲線

6

テストプランの書き方

• IEEE829 に従って書く
• https://qiita.com/momotar47279337/items/ae46cf3a7481c71d0dab

7

ソフトウェ品質のメトリクス

• バグの数
  • バクにも重要なバクから軽微なバグまで存在するため、単純に数でみない。
• バグの修正時間
  • 出荷時期が近づくに連れて、修正時間は短くなるはず。
• コードの複雑性
  • 有向グラフから判定する指標もある。

参考

• pythonコードの複雑性（サイクロマチック数）を測定するパッケージ
  • https://pypi.org/project/mccabe/

8

テストの自動化ツール

• 訓練をつんだ人ではないと、テストを自動化するのは難しい
• テスト自動化のメンテナンスに時間がかかる。

9

組み合わせテストをやめる

• 組み合わせテストは、膨大な数になる
• すべての組み合わせにより起こるバグは、テストではなくアーキテクトの問題
• 単体テストに注力したほうがよい

低品質なモジュールをたたく

• 20%のモジュールから、80%のバグがうまれる。
• 変更頻度の高いモジュールはバグがうまれやすいらしい