知識ゼロから学ぶソフトウェアテスト
https://images-na.ssl-images-amazon.com/images/I/51FdJMD2ETL._SX356_BO1,204,203,200_.jpg
ソフトウェアテストの種類や設計から丁寧に解説されている。文字大きくて読みやすいけど、いわゆる私が書きたいテストとちょっと違う。どういうんだろう。言葉を知らないのでうまくいえないけど、いわゆるテスター呼ばれる専門の人がやるようなテストの話なのかなと。これが必要なのかどうか、今はわからないのでとりあえずメモだけ残して本は手放すことにする。
バグを全部見つけるのは無理だと心得ろ!
エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない
矛盾しているようだけど、どっちもただしい
プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する
プログラムのバグは特定の箇所に集中している、ということ
品質向上のための投資は、投資額が修正にかかる費用を超過するか、『もっとましなことをすべきだ』と誰か言い出すまで増加し続ける
完璧でなく、十分な品質を持つソフトウェアを開発するためにテストを行う
テストの技法
ホワイトボックステスト
プログラムの論理構造が正しいかを解析するテスト
プログラムの論理構造に対する理解や知識が必要
そもそものソフトウェアの仕様の間違いはホワイトボックステストでは発見できない
なぜなら、論理構造が正しいかに焦点を当てているから
TDDの隆盛でホワイトボックステストが見直されるきっかけになったらしい
ブラックボックステスト
プログラムを一種のブラックボックスと見立てて、様々な入力を与えてソースを見ずにテストを行う手法
ソフトウェアは入力処理、計算、出力、保存の4つのふるまいをテストすればOK
ホワイトボックステスト
制御パステスト
論理構造で制御されている経路をテストしていく
ステートメントカバレッジ
基本のテストでもあり、これだけでは役に立たない or 最低限を満たしていないとされる
コード内の命令文(ステートメント)を最低一回は実行する
一つの経路についてのみテストをした、という状態
ブランチカバレッジ
判定条件がTrue、Falseの結果を少なくとも一回ずつ持つようにテストケースを書く
ソフトウェア全体に対して実行するのは大変すぎるので特定の箇所をサンプリングしてブランチカバレッジテストを実行する、などして用いられる
カバレッジ基準=一般の商用ソフトウェアなら60~90%程度で十分
カバレッジテストにかかる費用はカバレッジ率が100%に近づくほど、等比級数的に増加していく
カバレッジテストで検出できないバグ
プログラムの無限ループ
要求仕様自体の間違い、機能が備わっていない、などのバグ
データに関するバグ
タイミングに関するバグ
ブラックボックステスト
同値分割法
入力領域を同値クラスという部分集合として考え、その部分集合に含まれる値を同値とみなす
入力値に連続した有効な範囲が1つあるということは、無効値の部分集合が2つと、有効値の部分集合が1つある状態
テストケースの数を減らしながら有効なテストを書くことが可能
境界値分析法
プログラムの「境界」にはバグが潜んでいる
On-Offポイント法=境界に一番近い2つの異なる点を選んでテストする
異なる処理になるが一番近い値、でテストすることで境界部分のプログラムの挙動を確認できる
デシジョンテーブル
すべての入力の組み合わせを表にして、その入力に対する動作もしくは出力を明記する
項目が多くなると対応できないというデメリットがある
項目が少なく、かつ複雑な動きをするソフトウェアには有効なテスト
GUIをテストする
遷移状態をテストする
ランダムテスト
何も考えずに入力や操作を行う手法
探索的テスト
テストの1つのスタイル
個人のテスト活動で、継続的にテスト活動を洗練させる
テスト関連の学習→テスト設計→テスト実行→テスト報告
上記をプロジェクト期間中並行して行う
製品について学習しながらテストを設計して実行してバグ報告をするのを並行して行う。より熟練した一個人が責務をもってテストにあたることができるのがメリット。製品について学習する、というのはつまり触ってみながら仕様を理解してテストケースを構築してテスト実行していく、というもの。非機能要求に対するテストには向かないが、ユーザービリティに対しては効果がある。
非機能要求
XX性と言われるものたち
それぞれのXX性はトレードオフの関係になっていることが多い
いっぱいありすぎたので抜粋、大事なの3つをあげる
機密性
信頼性
パフォーマンス
パフォーマンステストがプロジェクトの後半で通らないと悲惨なことになるので早めに行う
テストプラン
IEEE829のテストプランテンプレートというのがある
これにしたがって作れば必要十分
「テストしない機能」の項目はけっこう大事
たとえば外部ライブラリはテストするのか、外注煮出した部分のテストはするのか、など
ソフトウェアのリスク
リスク=問題の起こる確率 X 問題が起こった場合のダメージ
複雑度
複雑なものをつかっているか
例えば非常に複雑な暗号モジュールを導入しているとか
新規性
新しい技術をつかっているか
例えば新しいCPUを使っているとか
変更
大きな危険性のある変更を行っているか
上位依存性
開発製品がある製品に依存しているか
例えばWinの新しいバージョンのOSに依存している場合とか
マイクロソフトがつかってるメトリックス
バグのメトリックス
時間軸でのバグの発見数
コンポーネントごとのバグの発見数(多すぎないか少なすぎないか)
テストのメトリックス
コードカバレッジ
テスト担当者以外のバグの発見数
テストケースの数、テストの自動化率
ソースコードのメトリックス
追加、削除、変更されたコードの行数
KLOCs:どれくらいソースコードの行数が増加しているか
コードの複雑度:McCabeのルール
ソフトウェアの信頼性メトリックス
実際の顧客が最も使うと思われるオペレーションをした際のMean Time Between Failure(MTBF)
信頼性成長曲線
ストレステストを行った際のMTBF
ビルドのメトリックス
ビルドにかかる時間
ビルドで見つかった問題
ビルドが失敗した原因
スケジュールのメトリックス
当初に立てたスケジュールと実際のズレ