本棚登録 : 
感想 : 
- Amazon.co.jp ・本 (253ページ)
- / ISBN・EAN: 9784822282516
作品紹介・あらすじ
最小・最善のテストケースを設計するためのツールが詰まった小さいけれどすごい本。
感想・レビュー・書評
-
コメント0件をすべて表示
-
今までなんとなくやってきた現場でのテストについて、体系的に整理することができた。
同値分割や境界値などは、本書でも記載されている通り既に意識されていることが多いが、デシジョンテーブルやペア構成、ドメイン分析等は、テストの目的を意識して活用することは難しいかもしれないと思った。
ただそれができるようになると、このソフトウェア仕様であればこのテスト手法がやりやすい、と迅速でより安全なテストを推進することができると信じて、本書の内容を活用していきたいです。
0
-
テスト対象の業務ロジックに応じて適切な図表を使い、テストケースを作成する
【感想】
業務の外部結合テストがスケジュール上かなりしんどくて、少しでも知識武装して気持ちを楽にしたいとの思いで手に取った本（テスト自体は1か月前ぐらいに終わってしまっているが）。読んで正解、今まで何となくやってきたテストの方法、経験がきちんとしたコンセプトで整理された。テストケースを作成するための図表がそれぞれの技法ごとに載っていて、実務への転用イメージも沸きやすい。自分の業務上で学んだテスト技法を利用したいときは、その図表を使ってテストケースの作成を進めればよい。 SEとしてプロジェクト推進をする最初に、こういったテスト法の本はさらって読んでおくべきだな。
【本書を読みながら気になったコト】
デシジョンテーブルはテスト設計の基本中の基本と言われるが、これは本来要件定義、基本設計のツールであったはず
→テスト技法に詳しくなり、パターンの洗い出しの技術が上がれば、設計の記述も上がる
《ブラックテスト技法》
〇同値クラステスト
独立した変数に対するテスト
図表：引数と期待する結果の組み合わせ
〇境界値テスト
独立した変数に対するテスト
同値クラステストケースに、境界値も加える
図表：引数と期待する結果の組み合わせ
〇デンジョンテーブルテスト
複数の条件に基づく行動、結果をテスト
図表：複数条件と行動、期待する結果の組み合わせ
→デンジョンテーブルと呼ぶ
〇ペア構成
環境やインプット値をペア毎ケースを作成しテスト
図表：存在するパターンを縦、横に並べた表
→直交表と呼ぶ
〇状態遷移テスト
あるオブジェクトの状態が複数存在、変化しうる際のテスト
図表：状態遷移図をまず作って、状態遷移図表を作る
状態遷移図表には、
・現在の状態
・イベント
・アクション
・次の状態
を含める。
全ての遷移パスを実行するテストケース作成、実施が望ましい
〇ドメイン分析テスト
同値クラステスト、境界値テストと違い、複数の変数を同時にテストする
・y = ax のような二次元表を利用する
・on off in out の概念を使ってテストケースを作る
図表：ドメインテストマトリックス
・複数変数を縦に並べ、変数ごとに on off in out で分割
・変数のon off in outごとに代表値を設定し、あり得る組み合わせごとに横の列を増やす
・列ごとに期待される結果を記載
〇ユースケーステスト
業務に沿ったシナリオを作成しテストする
図表：ユースケースシート
・操作内容、操作ステップ、期待する結果などを含める
《ホワイトボックステスト技法》
〇制御フローテスト
意図した通りに分岐して進むか、コードをテストする
図表：フローダイアグラム
→フローダイアグラムをテストケースの洗い出しとして利用
実際にコードが引数ごとに、フローダイアグラム通りに動くかは各プログラミング言語のツールでテストする
→存在するパスを全て通るようにテストができるのが理想
〇データーフローテスト
変数が定義、生成、使用、消滅される順序を記述し、ケース作成、テストする
図表：フローダイアグラム
→フローダイアグラムをテストケースの洗い出しとして利用
実際にコードが引数ごとに、フローダイアグラム通りに動くかは各プログラミング言語のツールでテストする
《テストパラダイム》
〇スクリプトテスト
事前に計画、テストケースを綿密に作成し、テストを行う
〇探索的テスト
テストを進め、その結果に応じて必要なテストを考案、ケース作成してテストする
→両方併用してテストを進められるのが理想
0
-
『初めて学ぶソフトウェアのテスト技法』
リー・コープランド
ブラックボックステスト編
1. ユースケースは仕様を理解するために使えそう。誰が、何のために、どんなステップで何をするとシステムがどうするか書いた表。主な成功シナリオを書いて、そこから関連する失敗シナリオを書く。表を埋めて、自分で埋まらない箇所は実装者に聞くなどするといいかも。しかしユースケース表だけでは十分なテストケースは書けない。
2. ドメイン分析テストは、原始的なほぼ境界値テスト。一つの項目について①境界ギリギリで合格、②境界ギリギリで不合格の2通りを試す。その間他の項目は境界値でもなんでもない普通に合格する無難な値（代表値）にしておく。一つの項目が終わったら、次の項目に移り、上記の2通り試す。その間その他の項目は代表値。その繰り返し。単一の機能の問題（シングルモード欠陥）は発見できるがダブルモード欠陥は見つけられない。
3. ペア構成テストが神。全ての組み合わせで成功を保証するために使う。ある違うの組み合わせの時には違う結果を期待するのであれば使えない（その際はディシジョンテーブル）。高い不具合発見率を少ないケースで実現。76〜98%の欠陥はペア構成テストで発見できたはずとある（64ページ）。ほとんどの不具合はシングルモード欠陥もしくはダブルモード欠陥なので、全ペアを試験すればいい。全組み合わせをしている時間はない。http://www.satisfice.comのAllpairsというツールや、http://aetgweb.argreenhouse.comのTelcordiaのAETGツールは制約条件も加えられる。しかし、一回のトランザクションで取りうる全ての入力や条件のペアは試せるが、複数のトランザクションからなる一連の流れは表現できない（その際は状態遷移図）。
4. 状態遷移表、及び状態遷移図は複数のトランザクションの一連の流れをテストできる。全ての遷移を少なくとも一回は行うようにケースを書くことが推奨。
5. ディシジョンテーブルはルールが複雑である時に使う。ある条件とある条件の時はある期待結果とある期待結果、など。可能な組み合わせを全て書き出し、全ての期待結果を一覧で確認すべき時に使う。
ホワイトボックステスト編
1. 制御フローテストは全てのコードを通過し、全ての条件分岐で全ての条件の組み合わせを試す方法。テスト実施者にコードの理解が必要且つ、コードが多いとあまりも時間を食ってしまう可能性がある。レベル1は100%ステートメントカバレッジで全てのコードを通過する。レベル2は100%ディシジョンカバレッジで全て条件分岐で真と偽の分岐結果を通る。レベル3はコンディションカバレッジで、if分のかっこ内の全ての条件文の真と偽の結果を判定する。
Holodeck は例外的な状況をシミュレーションできる。
0
-
ソフトウェアのテストをする上で何を検証し、どんなロジックでテストを組むのか、というテスト手法に関して学ぶことができます。情報学の用語や概念も一部あるので、入門書より難易度は少し高めに感じました。
0
-
＜きっかけ＞
テストについて教わったことがないなと思ったため
一度体系的に学習しておきたいと思ったため
＜感想＞
ソフトウェアテスト技法について体系的にまとめられていた。途中途中に挟まれるユーモアあふれる文章は、やっぱりも元洋書だなって感じ。知らない手法もいくつかあり、ペア構成テストやドメイン分析テストなどがその例だが、理解しきれておらず実用にもっていくのはなかなか難しい。何回か読み込む必要があると思う。最後に、刺さった言葉を一つ。「子供のテストでは、～結果は自分の意図したものだと～事実の起きた後に言う。本物のテストは～実行される前に結果は予測され、文書化されている。」つい手から動かしてしまうので胸に刻んでおきたい。
0
-
一つのトピックの分量は少なくコンパクトにまとめてあり、開発者の私がテスト、とりわけ Verification について勉強するのには、先日読んだ高橋さんの本とあわせて、ちょうど良かった。
特にデシジョンテーブル、直交表、全ペア生成などに関しては、その立脚点がうまく解説されていたように思う。
また、各種の手法の pros/cons をしっかりと取り上げているところは好感のポイント。
探索型のテスト、という概念は私にとって新鮮だった。
0
-
タイトルどおりテスト技法のカタログ的な内容だが、それぞれの特徴やアプローチを具体的に解説してくれていて、なかなか面白く読めた。これから専門に入門しようとしてる人や、プログラマやPMで詳しい知識を得たい人に。
ところで各章の初めにある引用がブラックで謎すぎる。
0
-
Section1と2は、のテスト技法について詳しい説明があり、参考になった。
演習問題もあるが正解が無いため、使えない。
Section4の15章の欠陥（障害）の分類も、自分が分類するときの、参考になった。
ただ、すべての分類を掲載してほしかった。
上記以外は記述量が少なく、参考にならない。
0
