「知識ゼロから学ぶソフトウェアテスト」を読んだ(5章まで)

1章　はじめに

1.1 テスト担当者の心得

• バグを全部見つけるのは無理だと心得ろ
• エラーは見つからないだろうという仮定のもとにテストの計画を立てては行けない
• プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例
• ソフトウェアテストで重要なのは、どの部分にバグが出やすいのか、そこにどのようなテスト手法を適用すれば十分な品質が得られるかを知ることである

1.2 完全無欠なソフトウェアテストは可能か？

• No

2章 ソフトウェアテストの基礎

ホワイトボックステストとは、プログラムの論理構造が正しいかを解析するテスト

2.1 どんなテスト手法が有効か

ホワイトボックステストは論理構造の正しさをテストするため、
ソフトウェアの使用が間違っていることから起こるバグは発見できない
(ホワイトボックステスト>ブラックボックステストではない)

2.2 プログラムの振る舞いをテストする

制御パステストは、プログラムがどのような振る舞いをして、
どのように制御・実行されていくかをテストする

2.4 ステートメントカバレッジ

コードの中の分岐命令を一度実行するテスト
非常に弱いテスト

2.5 ブランチカバレッジ

分岐コードそれぞれが、True, Falseの1回ずつ持つテストを行う
最低でもブランチカバレッジを実行するべき

2.6 カバレッジ基準

80%

2.7 カバレッジテストで検出できないバグ

カバレッジテストで全てのバグを見つけるのは理論的に不可能

2.7.1 プログラムのループに関するバグ

ループに関しては、カバレッジ基準が定義されていない

2.7.2 要求仕様自体の誤りや機能が備わっていないバグ

仕様自体が間違っていたらバグは検出できない

2.7.3 データに関するバグ

2.7.4 マルチタスクや割り込みに関するバグ

未解決領域のバグ

3章　エンジニアが最もよく使う手法

4つの振る舞いをテストすれば良い
入力処理、出力処理、データ保存、計算

3.1 ブラックボックステストの基本

境界値分析法は、ブラックボックステストの中の基本中の基本
入力処理、出力処理のテスト

3.2 バグの住む場所を探す

3.2.1 境界をテストするには

境界のどの値をテストするかを考えるには、On-Offポイント法を用いるのが一般的
異なる処理が行われる一番近い二地点をとる。

3.3 複雑な入出力のためのテスト

ディシジョンテーブルも非常に古くから使われている。
全ての入力の組み合わせを表に指定、その入力に対する動作もしくは出力を明記する
多数の入力処理、多数の出力処理のテスト

3.4 GUIをテストする

有限状態マシンを利用

3.4.1 状態遷移とは

ユーザーの行動に制限を加えるために状態が生まれる

3.4.2 状態遷移テストで見つかるバグ

• 期待していない状態に遷移するバグ
• 遷移自体がない場合

3.5 ブラックボックステストのまとめ

1. 入力ダイアログボックスがあれば -> 境界値テストを行う
2. 複数の入力ダイアログボックスがあれば -> ディシジョンテーブルテストを行う
3. ダイアログボックスの遷移があれば -> 状態遷移テストを行う

4章　探索的テスト

探索的テストとは、

• ソフトウェアテストの一つのスタイル
• 個人に自由意志を持たせるとともに責任をより明確に
• 一個人のテスト活動
• 継続的にテスト活動を洗練

4.1 テストケースベースのテスト

効率性は、テストケースベース<探索的

4.1.1 明らかにバグを見つける活動で、バグを見つけられる

探索度合いが深ければバグが見つかる

4.1.2 探索的テストのバグの例

4.1.3 「テスト設計・ケース作成を早い段階で行う」デメリット

• ターゲットのソフトウェアがないため、手探りでやっているケースが多い
• ソフトウェアテストの工数増大をもたらす

4.1.4 「同じテストケースをたくさん実行する」デメリット

• テストを実行しながら、どこか他の部分に問題がないかを考え、テストをすることができない
• ソフトウェアで弱いところを見つけたら、そこに重点を置き、その部分を十分にテストすることができない

4.2 探索的テストのサンプル

4.2.1 クライテリア決め

機能性、安定性などの判定基準を決める

4.2.2 探索的テストのタスク実行

1. ターゲットソフトウェアを決める
2. 機能をリストアップする
3. 弱いエリアを見つける
4. 各機能のテストおよびバグの記録
5. 継続的なテストの実行

4.3 非機能要求に対する探索的テストのアプローチ

探索的テストの唯一のデメリットは、非機能要求のテストにあまり向かないこと
ユーザビリティ以外の非機能要求に向かない、機能要求ではテストケーステストより良い結果

5章　要求仕様のテスト

要求のエラーは最も修正に費用がかかる

5.1 漠然たるユーザー要求を機能要求に落とし込む

要求の間違いや抜けが発見されるので、修正コストもあらかじめ見積もる必要がある
要求仕様を記述する際に必要なこと

• 完全である
• 正当である
• 実現可能である
• 必要である
• 優先順位がついている
• 曖昧さがない
• テスト可能である

5.2 要求に優先順位をつける

要求に優先順位をつけることで、WBSを書くときにその順位で開発が進められる

5.3 テスト可能な要求

テスト可能な要求は、
ステート -> 条件もしくはアクション -> 特定された結果
を書ける

5.3.1 要求の網羅

要求カバレッジ率は100%が必要

5.4 ユーザーストーリーと要求

ユーザーストーリーは、より良いプロダクトを作るための、プロダクトオーナーと開発チームでの約束

• ストーリーは、顧客と開発チームによって自然言語で書かれ、両者によって理解可能
• ストーリは短く簡潔で的を得ている
• それぞれのストーリーは、ユーザーが何かしらの価値を与えるものでないといけない
• 独立している
• 交渉可能
• 価値がある
• 見積もり可能
• 小さい
• テスト可能

5.4.1 アジャイルでのユーザーストーリー・要求品質

6章　非機能要求のテスト

非機能要求テストはそれぞれの非機能要求に対してテストのアプローチが異なる

6.1 期待通りの性能を引き出すために

パフォーマンステストとは、ソフトウェアを設計もしくは企画する段階で設定された性能が期待通りに出ているかをチェックするためのテスト

• 要求定義通りのテストケースを書かない
• パフォーマンステストは後回しにしない

6.1.1 パフォーマンステストの5つのステップ

1. アーキテクチャバリデーション
2. パフォーマンスベンチマーク
3. パフォーマンス回帰テスト
4. パフォーマンスチューニング、アクセプタンステスト
5. 24x7 パフォーマンスモニター

6.2 攻撃に耐えうるソフトウェアの構築

6.2.1 セキュリティに特化した非機能要求のようなもの

• 機密性
• 完全性
• 可用性

6.2.2 攻撃の歴史と種類

6.2.3 モジュール指向のテスト

1. アプリケーションを基本モジュールに分解する
2. モジュールに対する入力を定義する
3. その入力によってモジュールの脆弱性が露見するかどうかを判断する
4. 脆弱性があると考えられるモジュールにさまざまなデータを入力する

6.2.4 ファジングテスト

セキュリティ分野のランダムテストはファジングテストと呼ばれる

6.2.5 OWASP ZAP (Zed Attack Proxy)

OWASP ZAP とは無料でWebアプリを自動的にテストできるツール

6.2.6 静的解析ツール

2013年時点では、静的解析は有用なツールでしたが、現在はプログラムでセキュリティ担保をしようというのが主流。

6.2.7 基本的なテストアプローチ

• 解析
• 変更もしくは削除
• 監視

6.2.8 ペネトレーションテスト

ハッキングしてすでに知られているセキュリティバグや、知られていないバグをあらかじめ発見すること。ハッカーに見つけられて攻撃される前に。

6.3 信頼性

信頼度成長曲線の基本の式
$$m(t) = a(1 - e^{-bt})$$
$m(T)$ は、時間軸に対する信頼性
$a$は、期待するフォールト(バグ)の総数
$b$は、バグの発見率

7章 テストの自動化という悪魔

7.1 その自動化ツールは役に立っていますか？

自動化コードをメインテナンスしなければならない場合がある

7.1.1 テストの自動化はなぜ失敗するのか

成果を見せるためにテストの自動化を行うが、メインテナンスがバカにならない

7.1.2 自動化に向くテスト

• スモークテスト (最低限の動作確認)
• パフォーマンステスト
• APIのテスト

7.1.3 自動化に向かないテスト

• 回帰テスト(ソフトウェアの変更後も全ての機能が正常に動作することを保証するためのテスト手法)
• グラフィックスやサウンドなどメディア関連のテスト

7.2 テスト担当者が陥りやすい罠

• 何ら戦略なく自動化への期待だけが大きすぎる
• トレーニングコースの欠如もしくはレベルの低さ
• 誤ったツール選択

7.3 自動化設計戦略

• 線形スクリプト
• 構造化スクリプト
• 共有スクリプト
• データ駆動スクリプト
• キーワード駆動スクリプト
  下を目指すべき

7.4 新たなソフトウェアテストのステージ

	テストケース	実行時間・メインテナンス費用・デバック時間
単体テスト	多	少
インテクレーションテスト	中間	中間
UIテスト	少	多

8章 ソフトウェアテスト運用の基本

8.1 最悪のソフトウェアを出荷しないようにするには

$$テストにかかった費用 + サポートにかかる費用 = 最小値$$
が成り立つテスト計画を立てる必要がある

8.2 テストプランの書き方

8.2.1 IEEE829のテストプランテンプレート

8.2.2 テストプラン文書番号

何らかの管理番号(ver1, Nobember12-2024など)

8.2.3 レファレンス

テストプランに関連するドキュメントを列挙する

8.2.4 はじめに

「テストアイテム」「テストするべき機能」の要約

8.2.5 テストアイテム

出荷する製品の詳細を書く

8.2.6 テストするべき機能

8.2.7 テストする必要のない機能

8.2.8 人員計画、トレーニングプラン

遅れの出ているソフトウェア開発プロジェクトに人員を追加するとさらに遅れる

8.2.9 人員や時間をどう見積もるか

8.2.10 スケジュール

以下略