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

制作 : 宗 雅彦 
  • 日経BP
3.68
  • (13)
  • (31)
  • (35)
  • (2)
  • (0)
本棚登録 : 360
レビュー : 24
  • Amazon.co.jp ・本 (253ページ)
  • / ISBN・EAN: 9784822282516

作品紹介・あらすじ

最小・最善のテストケースを設計するためのツールが詰まった小さいけれどすごい本。

感想・レビュー・書評

並び替え
表示形式
表示件数
  • kindle価格:2400円/獲得ポイント:1200pt/実質価格:1200円

    >古典書であるボーリス バイザー氏の『実践的プログラムテスト入門』『ソフトウェアテスト技法』は、いきなり読むと難しいと感じたり、入門者向けの高橋 寿一氏の『知識ゼロから学ぶソフトウェアテスト 【改訂版】』では、簡単すぎると思った方にはピッタリだと思います。

  • 一つのトピックの分量は少なくコンパクトにまとめてあり、開発者の私がテスト、とりわけ Verification について勉強するのには、先日読んだ高橋さんの本とあわせて、ちょうど良かった。

    特にデシジョンテーブル、直交表、全ペア生成などに関しては、その立脚点がうまく解説されていたように思う。

    また、各種の手法の pros/cons をしっかりと取り上げているところは好感のポイント。

    探索型のテスト、という概念は私にとって新鮮だった。

  • タイトルどおりテスト技法のカタログ的な内容だが、それぞれの特徴やアプローチを具体的に解説してくれていて、なかなか面白く読めた。これから専門に入門しようとしてる人や、プログラマやPMで詳しい知識を得たい人に。
    ところで各章の初めにある引用がブラックで謎すぎる。

  • Section1と2は、のテスト技法について詳しい説明があり、参考になった。
    演習問題もあるが正解が無いため、使えない。

    Section4の15章の欠陥(障害)の分類も、自分が分類するときの、参考になった。
    ただ、すべての分類を掲載してほしかった。

    上記以外は記述量が少なく、参考にならない。

  • 最少のテストケースで最大の効果をあげるためのツールを満載

    第1章 テストのプロセス
    第2章 ケーススタディの説明
    Section 1 ブラックボックステスト技法
    Section 2 ホワイトボックステスト技法
    Section 3 テストのパラダイム
    Section 4 支援技法
    Section 5 最後の考察事項

    ■第1章 テストのプロセス
    ソフトウェアテストの定義
    「テストとは、テストされるソフトウェアの品質を測定して改善するために、テストウェアをエンジニアリングし、利用し、保守しながら、同時並行的に進めるライフサイクルプロセスである。」(P.12)

    •テストとは 「実際どうなっているか」と「本来はどうあるべきか」の比較
    •この本の役割 ◦テスト設計を有効かつ効率よく行うための技法
    •テストケースの構成
    ・入力
    ・出力 ■期待値(オラクル)
    ・実行の順番 ■ランダム or シーケンシャル
    •すべてをテストすることは不可能

    ■Section 1 ブラックボックステスト技法
    ブラックボックステストは、要件と仕様書だけをよりどころにしたテスト戦略です。ホワイトボックステストとの違いは、ブラックボックステストではテスト対象ソフトウェアの内部パス、構造や実装に関する知識を必要としないことです。
    (pp.26)

    ★組み合わせの数が非常に大きいときは、すべての変数のすべての値のすべての組み合わせをテストするのではなく、全てのペアのテストをします。テストケースが大幅に減ります。
    このペア構成テストの効果を理論的に保障してくれる「ソフトウェア欠陥物理学」は存在しません。
    ただ多くのプロジェクトでそれが成功しているという事実です。(P.88)
    → 直行表★★★

    状態遷移図はテストすべき状態、イベント、アクション、遷移を明確にしてくれるので、テスト作業の指針として役に立ちます。
    抜け漏れのない体系的な分析を行いたいときは、状態遷移表のほうが使いやすい手法です。
    (P.104)

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

    ■Section 2 ホワイトボックステスト技法
    ホワイトボックステストは、テスト対象ソフトウェアの内部パス、構造、実装に関する知識をよりどころにしたテスト戦略です。ブラックボックステストとの違いは、ホワイトボックステストを実施するには通常、詳細なプログラミングのスキルが必要になることです。
    (pp.126)

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

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

    計画が現在進行形のプロセスである以上、計画は現時点でわかっている情報と知識に基づいた暫定的な産物であり、新しい情報や理解が得られた際は常に見直しの対象となる、と認識すべきです。
    P192

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

    ■Section 5 最後の考察事項
    ・腕の良い職人には、道具が入ったバケツが必要
    ・そして、どの状況でどの道具を使うべきかがわかっていること
    ・能力レベルの3つのカテゴリ
     1.知識
     2.理解
     3.応用 → よって実践が大事


    ■引用著作
    ・基本から学ぶソフトウェアテスト
    ・ソフトウェアテスト293の鉄則
    ・体系的ソフトウェアテスト入門
    ・ソフトウェアテスト12の必勝プロセス
    ・基礎から学ぶテストプロセス管理
    ・ソフトウェアテスト技法

    ■目次
    第1章 テストのプロセス
    第2章 ケーススタディの説明
    Section 1 ブラックボックステスト技法
     第3章 同値クラステスト
     第4章 境界値テスト
     第5章 デシジョンテーブルテスト
     第6章 ペア構成テスト
     第7章 状態遷移テスト
     第8章 ドメイン分析テスト
     第9章 ユースケーステスト
    Section 2 ホワイトボックステスト技法
     第10章 制御フローテスト
     第11章 データフローテスト
    Section 3 テストのパラダイム
     第12章 スクリプトテスト
     第13章 探索的テスト
     第14章 テストの計画
    Section 4 支援技法
     第15章 欠陥の分類
     第16章 テストの終了判定
    Section 5 最後の考察事項
    付録A ブラウン&ドナルドソンのケーススタディ
    付録B ステートレス大学の登録システムのケーススタディ

    システムの規模がどのようなものであっても、すべての異なる論理パスの組み合わせと、すべての異なる入力データの組み合わせに対してテストを行うことは不可能です。
    リソースの制約があるので、それぞれテストするなんらかの意味を持つ無限の選択肢の中から、テスト担当者がほんの小さな部分(サブセット)を選んでテストする以外に、方法はありません。
    この書籍の目的は、このようなサブセットを分析、設計、選択して、欠陥をより多く検出できるテストケースを作成できるように読者を支援することです。
    (pp.1)

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

  • -

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

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

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

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

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

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

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

全24件中 1 - 10件を表示

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

はじめて学ぶソフトウェアのテスト技法 Kindle版 はじめて学ぶソフトウェアのテスト技法 リー・コープランド

リー・コープランドの作品

はじめて学ぶソフトウェアのテスト技法を本棚に登録しているひと

ツイートする