知識ゼロから学ぶソフトウェアテスト 改訂版: アジャイル・クラウド時代のソフトウェアテスト

著者 : 高橋寿一

• 翔泳社 (2013年12月1日発売)

作品紹介・あらすじ

アプリケーション開発、システム開発、組み込み開発、さらにはアジャイル、クラウドまで、テスト界の第一人者による現場で必須の手法+学術的根拠のエッセンス。

感想・レビュー・書評

[コーヒー好きさんの感想 · 2023年5月6日]

タイトルの通り、知識ゼロの方を対象として書かれた本だと感じた。そのため様々な手法を幅広く、浅く書かれているぶん、それぞれの内容を深く学びたいと思われた場合、参考著書などを活用して別の書籍を読む必要がある。

ソフトウエアテストを最初に学ぶ人にとって、初手に読む本としては良いと思う。

[atsuwo3さんの感想 · 2022年4月14日]

【ホワイトボックステスト】
ホワイトボックステストは論理構造の正しさのみをテストするため、ソフトウェアの仕様が間違っていることから起こるバグは発見できない

［制御パステスト法］
カバレッジ率に使われる
フローチャートをちゃんとカバーする
ブランチカバレッジは最低限必要

［TDD］
基本は赤・緑・リファクター
TDDの本質は確実に品質保証するというより、スピードを持って開発し、そして変更に対して耐性を持つこと
TDDはホワイトボックステストの一部しか実践していない

【ブラックボックステスト】
ソフトウェアテストは簡単で楽しい
テスト技術の進化は非常に遅い、陳腐化しない

ソフトウェアというのは四つの仕事しかない
入力、出力、計算、保存

・同値分割法と境界分析法
入力と出力の部分

［同値分割］
同値分割とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を等価とみなす作業
入力値を二つの部分集合に分ける
1つは有効同値、もう1つは無効同値
テストケース
要求仕様（1）
入力A：1から999まで入力可能
入力B：1から999まで入力可能
出力C：A×B
実践的な同値クラステスト
有効同値クラスのテストケース
A =300 B =400
無効同値クラスのテストケース
A=-20 B =-20
A=1100 B=1100
A=0 B=0 ゼロは常に特別な値なので、入力できる場合は必ずテストケースに入れること
網羅している範囲を塗りつぶすと判りやすい

［境界値分析法］
「無効同値と有効同値との間の値」もしくは「有効同値と有効同値の間の値」は常にバグが潜んでいる
要求仕様
1ページ未満の印刷をユーザーが要求した場合はエラーを表示すること
テストにはOn-Offポイント法が一般的
四つのタイプのバグがある
タイプ1：>と>=の間違い（閉包関係バグ」
タイプ2：数字の書き間違いやスペックの読み違いなど
タイプ3：境界がない
タイプ4：余分な境界
正しいテストケース例
テストケース1：1を入力
　結果：正常な処理がなされること
テストケース2：0を入力
　結果：エラー処理がなされること
「二点」とは、異なる処理が行われる一番近い二地点のこと

要求仕様（1）の場合のテストケースなら
0：常にバグになりやすい数
1：有効な値の下限
499：有効な値の真中
999：有効な値の上限
1000：無効な値の下限

経験則によるテストケース　良いデータと悪いデータを入力
良いデータ
・ユーザーがよく使いそうなデータ
・プログラムが許す最小のデータ
・プログラムが許す最大のデータ
・ゼロ（もしくは悪いデータとして）
悪いデータ
・非常に小さなデータ（-99999999、0.000001など）
・非常に大きなデータ（999999999、10999999など）
・長いデータ（abcdefghijklmnopqrstu.txtなど）
・無効なデータ

［ディジョンテーブル］
すべての入力の組み合わせを表にし、その入力に対する動作もしくは出力を明記
表には、状態、ルール（状態の組み合わせ）、動作（アクション）がまとめられる
この方法は複雑な状態が絡み合う機能のテストで力を発揮
項目が少なく複雑な動きをするものには有効

［状態遷移］
xclipboardなどのツールを使いましょう
テストが向いているソフトウェア
・GUIソフトウェア
・オブジェクト指向ソフトウェア
・通信プロトコルテスト
特に通信プロトコルは絶対にしましょう

［ランダムテスト］
あまり役に立たない
ただし、後述のセキュリティテストにのみ有効

ブラックボックステストはもっとも重要で、もっとも時間を費やし、もっとも簡単なテスト

まず境界値テスト、もし入力エリアが二つ以上ならディジョンテーブルテスト、ダイアログボックスの遷移があれば状態遷移テスト

【探索的テスト】
ざっくりいうと、製品を学習した上でテスト設計して実行してバグ報告を並行する。ただし、プロに責任持ってやらせる

サンプル
二つの活動を定義する
・クライテリア（判断基準、例えばpass/fail基準）はを決める
・探索的なタスクを実行する
五つに分けることができる
1. ターゲットソフトウェアを決める
2. 機能をリストアップする
例えば
・すべてのオンラインヘルプをチェック
・すべてのメニューをチェック
・サンプルデータの使用性をチェック
・すべてのダイアログボックスのチェック
・すべてのデータ、インターフェイス、ウインドウをダブルクリック
・すべてのデータ、インターフェイス、ウィンドウを右クリックなど
3. 弱いエリアを見つける
・データ交換が発生する機能（オブジェクトの埋め込み、ファイル変換）
・ほかのソフトウェアとイベントを共有する機能（目覚まし機能、メール送信）
・あまり使わないと思われる複雑に組み合わさったデータ入力をハンドルする機能
・ファイルをネットワーク越しにオープンさせる機能
・エラーや例外処理からの復帰機能
・OSとデータを交換させる機能（初期値）
・OSにサイズが依存する機能（メモリが少ない状態、サイズの大きいファイル）
4. 各機能のテスト及びバグの記録
テストケースは書かない
5. 継続的なテストの実効
上記活動を繰り返すと共に、ひと工夫入れても良い、例えば
・テスト担当者が複数いるのなら、担当範囲を交換して同じ結果が出るかを確認する
・もしそのソフトウェアがさまざまな環境で動作するのなら、環境を変えてテストを行う（たとえば複数種類のWebブラウザ状態で、他など）
・バグ修正によりほかの機能に悪い影響が出ていないかを確認する
・重要機能に対してシンプルなテストを実行し、ソフトウェア全体の品質レベルが下がってないかを確認する

唯一のデメリットは非機能要求テストにあまり向かない

探索的テスト＋スキルのあるテスト担当者の最強コンビでは、すごく短い時間で最強の結果が出る

【非機能要求のテスト】
ざっくりと、機密性、信頼性、パフォーマンス
［パフォーマンステスト］
注意点
・パフォーマンスの定義は明確に
・要求定義通りのテストケースを書かない
・パフォーマンステストは後まわしにしない
パフォーマンステストで発見されるバグは最悪のバグ
テスト五つのステップ
1. アーキテクチャバリデーション
2. パフォーマンスベンチマーク
3. パフォーマンス回帰テスト
4. パフォーマンスチューニング、アクセプタンステスト
5. 24×7パフォーマンスモニタ
実データもしくは近いデータで、同じサイズで

［セキュリティテスト］
残念ながらセキュリティテストという分野は存在していない
まだテスト手法が未発達
ファジングテスト手法がランダムテストみたく主要になっている
ファジングツールは商用、オープンソース共にある

［信頼度成長曲線］
計算ツールが、「広島大学」「信頼性」で検索すれば見つかるかも

【ソフトウェアテスト運用の基本】
［テストプラン］
IEEE 829のテストプランテンプレート
・テストする必要のない機能　この項は意外と重要
・人員計画、トレーニングプラン　初期はコアメンバー、その後テスト要員を追加が良い方法
・スケジュール　至難の業。開発スケジュールに依存する部分が大きい。
・リスクとその対策　もっとも書きにくい部分

テストプランの理想と現実
たくさんのプランを見て、自分なりのプランを見つけることをお勧めします
「できるだけ」ちゃんと書く程度で良い

［テストケースの書き方］
いつ、誰がやっても同じような結果が得られるように書かないといけない
管理ツールを使うのが良い（testlink）

［テストケースの実行］
下記のログを取る
・日付　テストを実効した日付
電車テスト結果　テストが成功したのか失敗したのか
・実施者　誰がテストを実行したのか
・ビルド番号　どのビルドでテストを実行したのか
・環境　どんなコンピュータで実行したか、その際のOSの種類は、など
重要な機能のテストから実行

［テスト開始のタイミング］
早く始めるほど良い

［出荷前日にバグが発見されたときの対処法］
明らかにセキュリティ上の問題がある場合を除いて修正は思い留まるべき

【ソフトウェア品質管理の基本】
テストという作業は、アウトプットが非常に見えにくいもの
指標のことを「メトリックス」
バグの数を管理するメトリックス、重要度の高いバグの数を用いるのが良い
バグの修正にかかる時間を管理するメトリックス、減らない時は結構やばい

［ソースコードメトリックス］
開発チームの健全性が見えることがある
コード行数からバグ密度を計測するのは懐疑的

［複雑度のメトリックス］
20を超えるのはなかなか危険

［無駄のないメトリックス選択の例］
Microsoftの場合
<バグのメトリックス>
・時間軸でのバグの発見数
・コンポーネントごとのバグの発見数（バグが多過ぎないか、もしくは少な過ぎないか）
<テストのメトリックス>
・コードカバレッジ
・テスト担当者以外のバグの発見数
・テストケースの数、テストの自動化立
<ソースコードのメトリックス>
・追加、削除、変更されたコードの行数
・KLOCs：どのくらいソースコードの行数が増加しているか
・コードの複雑度：McCabeのルール
<ソフトウェアの信頼性のメトリックス>
・実際の顧客がもっとも使うと思われるオペレーションをした際のMTBF
・信頼性成長曲線
・ストレステストを行った際のMTTF
<ビルドのメトリックス>
・ビルドにかかる時間
・ビルドで見つかった問題
・ビルドが失敗した原因
<スケジュールのメトリックス>
・当初に立てたスケジュールと実際のズレ

［メトリックスの間違った使い方］
人の能力や個人の仕事の結果を測ってはいけない

【テストの自動化という悪魔】
テストの自動化を成功させるには、自動化コードの保守コストを低く保つこと
［自動化に向くテスト］
・スモークテスト　たくさんの回数繰り返すため
・パフォーマンステスト　たくさんの人を集めるより、ツールでたくさんの人をシミュレートした方が良い
・APIのテスト　APIはそれほど変わらないため
［自動化に向かないテスト］
・回帰テスト
・グラフィックスやサウンドなどメディア関連のテスト

【それでもテストがうまくいかない人へ】
組み合わせテストをやめる　テストで見つけるのではなく、アーキテクチャを工夫して問題を出ないようにする

品質の悪いモジュールを徹底的に叩く　80/20の法則
Googleバグ予測システム　いつ何回か修正されたかしかみない、パラメータは回数と時間の2つ
これが複雑度より進化したもの


まさにテストとは言うのが知れる、良き初心者向けの本だった。
とてもわかりやすく、読みやすかった。

[Mouto9さんの感想 · 2022年4月9日]

IEEE 829のテストプランテンプレート
テストプラン文書番号
リファレンス
はじめに
テストアイテム
テストするべき機能必要のない機能
アプローチ
人員計画トレーニング計画
スケジュール
リスクとその対策
承認
に終了基準を追記

自動化はスモークテスト、パフォーマンステストAPIテストに向いてる

[granfassさんの感想 · 2021年3月21日]

会社内での輪読会で採用しました。
各テストの手法やメリット・デメリットはもちろんのこと、テストに対する心構えや著者の経験談なども掲載されており、少しソフトウェアテストの概念や概要を知るにはとても取っつきやすいと感じました。
また、実際のコードなどが頻繁に出てくる事はないため、SE以外の方にも分かりやすいかと思います。

ただ、ユニットテストや結合テストのそれぞれの具体的な製品やフレームワークについての記載はほとんどないため、この点を知りたい方は別の書籍を手に取ることをおすすめします。

[kwnsさんの感想 · 2020年8月3日]

業務で行うテストの際、チーム内で抜け漏れが発生しがちなので改善したく、まずテストに関する基礎知識が不足していると感じたので読んだ。基本的な考え方や、用語、具体的な方法などに頭の中でインデックスを貼るのに十分な内容だった。

中身の断片
「バグを全部見つけるのは無理だと心得ろ！」
ホワイトボックステストとブラックボックステスト。
境界値テスト→ディシジョンテーブルテスト→状態遷移テスト、それ以上バグが出たら非機能要求の問題。
TDDの本質はスピードを持って開発し変更に対して耐性を持つこと。

[読んだ本登録用 さんの感想 · 2020年7月31日]

ソフトウェアテストの勉強は大体この一冊である程度網羅できる
テストを勉強したい方にはうってつけ

[hatsuさんの感想 · 2020年6月6日]

## テストで大事なこと

- テストで大事なのは、どの部分にバグが出やすいか、そこをどのようにテストすれば十分な品質が得られるかを知ること
- バグは平均的に散らばっているものではない。バグの出やすい箇所、出にくい箇所がある。(80%のバグが20%のコードに含まれているというデータもある)
- テストは限られた時間で行う最大公約数的な仕事。時間がないからテストしないという選択肢はない
- James曰く、「ソフトウェアは4つの仕事しかしない。なので、その4つの振る舞いをテストすれば良い」
- 4つとは、 `入力を処理する`、 `出力を処理する`、 `計算を行う`、 `データを保存する` それらに対して適切にテストすれば、ほとんどのバグが発見できる
- テストケースを省略するのはやむを得ないが、その省略されたテストケースでバグを出してはいけない
- テストするのに「良いデータ」と「悪いデータ」が存在する
- 良いデータ例
- ユーザーがよく使いそうなデータ
- プログラムが許す最小のデータ
- プログラムが許す最大のデータ
- ゼロ
- 悪いデータ例
- 非常に小さなデータ(-99999,0.0000001など)
- 非常に大きいデータ(999999,1099999など)
- 長いデータ(abdajohadamklmdklamombamoaなど)
- 無効なデータ
- とっとと楽して60%のバグを見つけ、そのほかのバグがなぜ発生したか、どうやって防止するかに時間を費やすかが、より建設的なテスト担当者の役割
- 品質を目に見えるものにするには
- なるべく誤差がなく人間の市場や恣意に左右されないものを選ぶ
- 開発するソフトウェアの品質を十分代表するものを選ぶ
- Googleのバグ予測システムでは、いつ何回修正されたかしか見ていない。修正された回数が多いほど、修正が最近ほどバグが潜んでいるということ。

# テスト手法

## ホワイトボックステスト

- プログラムの論理構造が正しいかを解析するテスト
- 人間の時間をたくさん使って内部構造を解析しテストする
- 論理構造の正しさのみをテストするため、 `ソフトウェアの仕様が間違っていることから起こるバグは発見できない。`

### 制御パステスト

- プログラムがどのような振る舞いをして、どのように制御されていくかをテストする手法
- カバレッジ率の値を取るために使われる
- 制御パステストによるコードカバレッジテストの本質は、フローチャートをちゃんとカバーすることにある

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

- 制御パステストの一部
- ステートメントカバレッジだけでテストを終了することは危険
- 分岐条件がカバーしきれないなど、非常に弱いテスト手法

### ブランチカバレッジ

- `分岐コードに対してそれぞれの判定条件がTrue/Falseの結果を少なくとも1回ずつ持つようにテストケースを書く`
- 分岐を網羅するため、テストケースの数がかなり増える点が問題点
- バグの発生状況を見てから、バグがたくさん出る部分に対してブランチカバレッジを実行するのは悪くないアイデア

## ブラックボックステスト

- ブラックボックステストは、プログラムをブラックボックスと見立てて、 `様々な入力を行うことによって、ソースコード利用せずテストを行う手法`

### 同値分割法

- 同値分割とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を透過とみなす作業
- つまり、可能な入力値のうち同様の入力値は等価とみなしてテストする手法
- 同値クラスの分け方は
- 有効同値：プログラムが期待する入力値
- 無効同値：有効同値以外の入力値
- 実践的な同値クラスの選び方は、 `ポイントは代表する同値が全てのエレメントを網羅しているか`です

### 境界値分析法

- 同値分割法とセットで使われる手法
- プログラムで「境界」と呼ばれる場所は常にバグが潜んでいるので、強化位置近くは詳しくテストする必要がある

## ランダムテスト/アドホックテスト

- テストケースを考えず、行き当たりばったり、なんら考えなしに入力や操作を行う手法

### まとめ

テストは

1. まずは強化位置テストを行い、境界地にまつわるバグを全て潰す
2. ディシジョンテーブルテスト行う
3. 状態遷移テストを行う

## 探索的テスト

- ソフトウェアの理解とテスト設計とテスト実行を同時に行うテスト
- すべてのテストを実施するのは時間的に無理、できてもすべてのバグは見つからない。
それならいちいちテストケースを書く代わりに、製品を 学習 したうえでテスト 設計 して 実行 してバグ報告を 並行 してやっちゃえば手っ取り早い。 というスタイル
- 探索的テストの唯一のデメリットは、非機能要求(=品質特定)のテストにあまり向かない

## 非機能要求のテスト

- 非機能要求(=品質特定)とは、「ソフトウェアが持つべき特性」で、機能的な側面と非機能的な側面の両方の属性を示したもの。
- とくに大事なのは、機密性、信頼性、パフォーマンス

### パフォーマンステスト

- ソフトウェアを設計もしくは企画する段階で設定されたソフトウェアの性能が期待された通り出ているかをチェックするためのテスト
- レスポンスタイムや、入力データサイズなどの設計前にソフトウェアのパフォーマンスを定義する

[u1000さんの感想 · 2019年6月3日]

再読予定

[名古屋大学理学図書室さんの感想 · 2019年4月16日]

ソフトウェアテストの基礎とポイントをわかりやすく解説。理図書 007.61||Ta33b 12038768

[Tohkoさんの感想 · 2019年3月13日]

・初中級者ぐらいに良い
・完璧ではなく十分な品質を目指す、バグの集中など、実践的な考え方が載っている

著者プロフィール

横浜国立大学国際社会科学研究科教授

「2017年 『現代都市法の課題と展望』 で使われていた紹介文から引用しています。」