はじめて学ぶソフトウェアのテスト技法

投稿元：

レビューを見る

本当に始めて学ぶのに最適ですね。いろんな情報が載っていて、これからテストについてDeepに学ぼうとしている私には最適な入門書です。

投稿元：

レビューを見る

研究室の本。じっくり読もうとするとしんどい部分もあるが、集中して読むとかなり分かりやすく解説してある。特に各テスト手法の解説は概念の説明と具体的な例が順序良く説かれていて理解しやすいよう配慮してある。

投稿元：

レビューを見る

ソフトウェアテストってどうやるんだろう？
どんなものがあるんだろう？
っていうのを解決してくれる本。

技法の説明がとても丁寧でわかりやすい。
でもどこで使うかとかは書いていない。
それは実践で学んでいくらしい。

投稿元：

レビューを見る

単体テストの項目抽出に興味がある人には有益。
演習があるのにその答えが見当たらないのが謎。

SectionIIまで読み終わったところで中断（ユースケーステストはスキップ）。SectionIII以降はまた後日。
ペア構成テストとドメイン分析テストは疑問が残るので、再度読み返す必要がある。

「ソフトウェアテスト実践ワークブック」が気になるので要チェック。

投稿元：

レビューを見る

書名どおり、これからソフトウェアの「テスト技法」を勉強しようという人に最適な本です。この本に書いてあることは基本中の基本なのでテストエンジニアであれば知っていて当然のことばかりです。この本を読んでから、バイザーへ進むと良いと思います。
この本の各章は、「テストのプロセス、ケースステディの説明、同値クラステスト、境界値テスト、デシジョンテーブルテスト、ペア構成テスト、状態遷移テスト、ドメイン分析テスト、ユースケーステスト、制御フローテスト、データフローテスト、スクリプトテスト、探索的テスト、テストの計画、欠陥の分類、テストの終了判定」となっています。

「ペア構成テスト」の章では、直交表と、全ペアアルゴリズム(pairwise, All-pair)について記載されています。この章で、各種直交表が掲載されているWebページが載っていました。

http://www2.research.att.com/~njas/oadir/index.html

投稿元：

レビューを見る

■ブラックボックステストの技法
・同値クラステスト
・境界値テスト
・デシジョンテーブルテスト
・ペア構成テスト
・状態遷移テスト
・ドメイン分析テスト
・ユースケーステスト

■ホワイトボックステストの技法
・制御フローテスト
・データフローテスト

■テストのパラダイム
・スクリプトテスト（事前計画テスト）
・探索的テスト（例：20の扉。頭の中に思い描いているものを20個の質問（Yes-Noで答えられる質問）を通じて当てるゲーム。仮に全ての質問を事前に計画しておいたとしたら、当てることはできないだろう。質問の結果を次の質問のインプットとする方法。）

投稿元：

レビューを見る

今回は必要な部分だけを斜め読み。
和訳なので文章が所々読みにくかったり、作者の思いが分かりづらい例文が多いが、体系的にまとめられていて非常にためになった。

投稿元：

レビューを見る

ソフトウェアテストの手法や考え方など基礎となるところが網羅されていると思う。
パーっと読み進めていき、まだまだ理解が足りないところもあるが、なんとなくテストの手法や不具合の定義など曖昧な部分が明確になった。
ソフトウェア開発者として、テストの手法などは確実に認知しておく必要があると思うので、この本はおすすめです。

TDDなどユニットテストなどを書くにも制御フローテストや境界値テスト、同値テストなどの考え方は知っておくべき内容だと思う。

投稿元：

レビューを見る

去年、"テストしなければ！"と思ったのですが、結局何がなんだかわからないままほぼ一年がたちました。

最近ようやくTDD的に出来るようになってきました。

http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

を読んだのが一番でかかったように思います。

次にでかいのがこの本を読んだことのように思います。

投稿元：

レビューを見る

長いことソフトウエア開発の仕事に携わってきたが、ふと「テスト」というものについてちゃんと勉強したことがないことに気付き、業務上の必要もあって、敢えて初心者向けの本書を選んだのだが、結果大変勉強になった。
ソフトウエア開発従事者なら、一度は読んでおくべき良書だと思う。

投稿元：

レビューを見る

　どうすれば少ないテストケースで有効なテストが実施できるかについて具体的な例とともに解説している。同値クラステストや境界値テストといったおなじみの技法から、デシジョンテーブルテスト、ペア構成テスト、状態遷移テストなどあまり知られていないものも紹介している。またブラックボックステストとホワイトボックステストの違いであるとか、テストの進め方についても言及している。
　テストの進め方についてはスクリプトテストと呼ばれるテスト計画を立て、テストケースを設定しテストを行う従来型のテストの他に、テストケースを事前に決定できなかったり、前に実行した結果が大きく影響する、あるいは要件が曖昧であったりする場合に使用する探索的テストを紹介している。このどちらかが優れているというわけではなく必要に応じて使い分けたり融合させるべきだとしており、実用を重視した内容となっている。
　実用重視と言えばテストの支援として欠陥の分類と終了判定を取り上げている。欠陥を分類することはテストの方向性やどこに重点を置くかを決めるのに有効というだけでなく開発プロセスにおいても有効であり手元においておくべき内容であると感じた。
一方テストの終了判定は皮肉交じりの内容となっていた。これは決してふざけているのではなく、テストの終了判定がいかに難しいかを如実に表しており、テスト経験者なら共感するであろうことが書かれている。
　新人にテストを任せるというある種の企業文化が存在しているが、本書を読むと果たしてそれは正しいのかと疑問に思う。仕事を理解する上でテストという作業が有効であることは間違いないが、やはりテストの重要性を鑑みればリスクが高いと言わざるを得ない。また、ソフトウェアテストの重要性が高まっているものの、テストを専門にするエンジニアが少ないように感じる。そろそろテスト専門エンジニアの育成を考えてみるべき時なのかもしれない。

投稿元：

レビューを見る

テストとはなんぞやと聞かれて、
種類ややり方を整理してくれている本。
もう一度体系立ててまとめるときにどうぞ。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
●テストとは、テストされるソフトウェアの品質を測定して改善するために、
　ソフトウェアテストをエンジニアリングし、利用し、保守しながら、
　同時並行的に進めるライフサイクルプロセスである。（P.12）

●組み合わせの数が非常に大きいときは、
　全てのペアのテストをします。
　このペア構成テストの効果を理論的に保障してくれる
　「ソフトウェア欠陥物理学」は存在しません。
　ただ多くのプロジェクトでそれが成功しているという事実です。（P.88）

○状態遷移図はテストすべき状態、イベント、アクション、遷移を明確にしてくれるので、
　テスト作業の指針として役に立ちます。（P.104）

○テストをいつ終了するかを判定するための基本的な条件を5つ挙げると、
　以下のようになるでしょう。
　・事前に決めたカバレッジの目標値を達成した
　・欠陥検出率が、事前に決めたしきい値以下に下がった
　・「次」の欠陥を見つけるのに要する限界コストが、
　　その欠陥で生じると予想される損害額よりも大きくなった
　・プロジェクトチームが、製品をリリースしてもよいという合意に達した
　・上司による「いいから出荷しろ」の一言

投稿元：

レビューを見る

テスト技法についてシンプルにまとめられた本だと思う。自分にとっては特に新鮮な情報はなかったため、ただ応用・実践の難しさに憂鬱になるばかり。

投稿元：

レビューを見る

境界値テスト等、慣れた人はごく自然にやるテストについて書かれている。タイトルに偽りなし。
しかし古いというか固いというか、ちょっと時代遅れな気がする。