ソフトウェアテストの教科書を読んだメモ
komaki/こまきちソフトウェア品質における狩野モデル
komaki/こまきち仕様上欠陥ではなくても、ユーザーが不満に感じるものであれば拾い上げて、品質を高めるべき
komaki/こまきちV字モデル以外にW字モデルがあることを知らなかった
komaki/こまきちウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。
これは言い換えれば間違いを起こし得ない人間が行う前提で作られているということで、経験値が浅い人間が関わるものではなかったのか？
そうなるとだいぶ狭い世界で考えられたもので、破綻するのは当然すぎる。
komaki/こまきちテストの種類
- 単体テスト
- 機能確認テスト
- 制御フローテスト
- 命令分岐が全て実行されているか
- データフローテスト
- データが定義されてから使用されて消滅するまでの確認テスト
- システムテスト
- 確認テスト
- 修正確認
- リグレッションテスト
- スモークテスト：テスト前にテストをするに値する品質か簡易的にテスト
- リリースチェック
- 評価テスト
- セキュリティテスト
- ユーザービリティテスト
- これ基準どうするの
- 障害許容性テスト
- 負荷テスト
- 環境テスト
- 機能確認テスト
- 確認テスト
komaki/こまきちディシジョンテーブル
テストの条件が複雑なため、仕様を元に入力の組み合わせを整理するための図
komaki/こまきちこういう表作るのめちゃくちゃ苦手。可能なら作りたくない。。。
komaki/こまきちこれ本当に有効な方法なのか？
見る側も辛くないか？
komaki/こまきちまずは全ての組み合わせを検討し、そこからテスト不要なものを削除していき作成し続ける。
これを作成した時点で確かにテストケースはある程度検討を終えているが、予想３営業日かかりそう。
komaki/こまきち直交表とALL-pair法
テストケースを考える上で組み合わせを検討する際に、全てをテストしなくて良いようにより効率的に組み合わせを検討する手法。
komaki/こまきちテスト作成ツールの1つ
komaki/こまきち直交表
2つの因子の組み合わせを網羅させる。
直交表は「不具合が起こる要因のほとんどは2つまでの要因の組み合わせによるものだ」という考えに基づいています。
komaki/こまきちこれは今もやってるな
komaki/こまきちAll-pair法(ペアワイズ法)
２因子間の値の組み合わせ”だけ”はすべて網羅する
ある文献*1ではソフトウェアのバグの7割から9割が1つまたは2つの因子の組み合わせによって発生していることが記されています。
直交表と思想一緒や
komaki/こまきち直交表との違い
直交表…組み合わせ内で1つの値が全て同じ数づつ出現しなければならない
All-pair法…１回以上出現すればいい（必要な最小限のテストケースを生成することが目的）