test.md

テストケース洗い出し方

※機能要件のみ

#テストケースベースのテスト手法

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

プログラマがコードを確認して行うプログラムが論理的に正しいか解析するテスト

論理構造の正しさのみをテストするので、ソフトウェアの仕様が間違えていることから起こる不具合の発見ができない

##制御パステスト法

平たく言うとフローチャートをカバーさせるテスト

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

ソフトウェアテストの基礎的な手法、面倒なので嫌がる人が多い

エンジニアの不安を解消して、自信を与えてくれるテスト手法

##コードカバレッジ

どれだけ、フローチャートをカバーしているかを数値化したもの

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

A	B	C
T	F	F
F	F	T
T	F	T

if(a || b){
	// todo 1
}
if(c){
	// todo 2
}

命令文を通過している度合い todo1, todo2を通過している場合は100%になる

###ブランチカバレッジ(C1)

A	B	C
T	T	F
T	F	F
F	T	F
F	F	F
F	F	T
F	T	T
T	F	T
T	T	T

分岐条件をそれぞれ判定条件が TRUE/ FALSE それぞれ１回ずつ持つようにテストケースを書いてある度合い

todo1を処理して例外投げるケース todo1を処理せずにtodo2を処理する・しないケースそれぞれテストするとカバレッジ100%

###コンディション（C2)

テスト対象のすべての判定条件が，テストによってどれくらい実行されたかを評価する

複数の条件文が組み合わされている場合，個々の条件文について「true」の場合と「false」の場合の両方が実行されれば，網羅されたことになります。

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

##一般的に以下の項目を処理を検証できれば問題ないと言われる

入力を処理する
出力を処理する
計算を行う
データを保存する

SoftwareTest is easy James Whittaker

元Google、現MS

##同値分割法・境界分析法

ブラックボックステストの基本、もっともよく使われる.

入力と出力がターゲットになる

-- ユーザの様々な入力に大してソフトウェアが十分に対応できるかを確認するテスト手法。（別名いじわるテスト）

入力データを分析して境界値に対する処理が適切に行われる事を確認

##同値分割法入力領域を同値クラスという部分集合に分割し、その部分集合に入る入力値を等価とみなす作業。

入力値を有効同値、無効同値に分ける。有効同値は期待する入力無行同値はそれ以外

例: 要求仕様: 入力A：1以上1000未満、入力B：1以上1000未満、出力：A * B

if(argA > 0 && argA < 1000){
	//正常値
} else{
	// 異常値
}

網羅するテストケース

入力A	入力B	結果(◯☓)	A	B
20	20	◯◯	nop	nop
-20	-20	☓☓	1未満	1未満
-20	1000	☓☓	1未満	1000以上
1000	-1	☓☓	1000以上	1未満
1000	3000	☓☓	1000以上	1000以上
100	0	◯☓	LGTM	0以下
10000	100	◯☓	1000以上	LGTM
...

#きりがない

すべてのテストケースを網羅することはコストがかかるので現実的でないのである程度省略する必要がある

テストケースを省略する事はやむを得ないが、省略したテストケースでバグを出してはいけない

テストケースの設計は難しいね

Jorgenson()のテスト設計

入力A	入力B
20	20
-20	-20
1000	1000
0	0

##境界値分析

境界はエラーしやすい

>=, >, ==, <=, <=

閉包関係バグ

###境界をテストしよう 1以上、1000未満境界値=0,1,999,1000

On-Off ポイント法

off	on	on	on	off
0(off)	1(on)	500(on)	999(on)	1000(off)

境界値とは異なる処理が行われる一番近い2点の2地点のこと

##ディシジョンテーブル

テストケースが組み合わさった時に問題が置きないか確認するために使用する

状態	ルール1	ルール2	ルール3	ルール4
入力１	T	T	F	F
入力2	T	F	T	F
動作
計算出力	◯	◯
エラー出力	☓	◯	◯	◯

※Aが正常値であれば問題ないケース

この手法の課題は表を使ったテスト自体が小さなソフトウェアか、大きなソフトウェアの一部しか使うことができないので、テストケースが複雑なものに大して扱う事ができない

#まとめまずは境界値をテストする

入力が複数ある場合はディシジョンテーブルを使用して、組み合わせのテストを行う

#探索的テスト

ソフトウェアテストの一つのスタイルソフトウェアの機能を学習しながら、テスト設計とテスト実行を同時に行う

※すべてのテストを網羅するのは時間的成約から望むべくもない、そして行ったとしてもバグは大して見つからない。ならば、ソフトウェアの機能に沿ったテストを行えば良い

テストケースベースのテスト手法よりも効率の面で優れている。要求がいい加減で変化しやすい状況にすごく向いてる（最初は探索的テストで後からテストケースベースにpivotするの良いかも）TDDで開発して、後から細かいテストケース流してをいじめるとか

探索的テストは機能をリストアップして、弱そうな箇所を検証する手法です。

リファクタの時に使える

http://jasst.jp/symposium/jasst14kyushu/pdf/S3.pdf

ozw-sei/test.md

Select an option

No results found

Select an option

No results found

ozw-sei commented Jun 8, 2017

Uh oh!