知識ゼロから学ぶソフトウェアテスト【改訂版】(高橋 寿一)|翔泳社の本
  1. ホーム >
  2. 書籍 >
  3. 知識ゼロから学ぶソフトウェアテスト【改訂版】

知識ゼロから学ぶソフトウェアテスト【改訂版】


形式:
書籍
発売日:
ISBN:
9784798130606
定価:
2,640(本体2,400円+税10%)
仕様:
A5・240ページ
カテゴリ:
開発管理
キーワード:
#開発環境,#開発手法,#プログラミング,#システム運用
紙の書籍
本書籍には新版があります
知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書

テスト技術者必読のロングセラー!8年振りのリニューアル登場

エンジニアとしての心得やソフトウェアテストにできること、できないこと、など初心者がまず知っておかなければならないことがらにはじまり、必ず実施される各種テスト手法の基礎とポイント、アジャイルなど新しい開発手法に対応したテストの考え方など、テスト技術者にとって不可欠な知識と情報を、親しみやすい記述や例示で判りやすく解説した一冊です。テスト技術者の入門書かつ最適の定番書として、ソフトウェア開発現場のニーズに即した内容を取捨選択のうえ、カラー化して一層読みやすくパワーアップして再登場しました!

ソフトウェアテストに携わる初歩のエンジニア/テスト技術者を育成・要請する立場の方におすすめです。

画像01

第1章 はじめに

1.1 テストをはじめる前にー「バグ」とは何かを考えるー
1.2 どんなソフトウェアにもバグは潜んでいるーソフトウェアの不良とはー
1.3 バグが原因で起きた宇宙開発の大事故
1.4 テスト担当者の心得ー先人の言葉に学ぶソフトウェアテストの奥義ー
1.5 完全無欠なソフトウェアテストは可能かー100万のテストケースでも十分とは言えないー
1.6 ソフトウェアテストの実力診断テストーあなたのテスト能力をチェックするー

第2章 ソフトウェアテストの基本ーホワイトボックステストー

2.1 ホワイトボックステストとはープログラムの内部構造を徹底的に分析するー
 2.1.1 どんなテスト手法が有効か
2.2 プログラムの振る舞いをテストするー制御パステスト法ー
2.3 大人気ゲームソフトのバグ
2.4 ステートメントカバレッジ
2.5 ブランチカバレッジ
2.6 カバレッジ基準
 2.6.1 カバレッジテストでカバーされないコード
2.7 カバレッジテストで検出できないバグ
 2.7.1 プログラムのループ
 2.7.2 要求仕様自体の誤りや機能が備わっていないバグ
 2.7.3 データに関するバグ
 2.7.4 マルチタスクや割り込みに関するバグ
2.8 カバレッジテストの罠
2.9 ホワイトボックステストの復権(TDD)
 2.9.1 アジャイルなどというもの
 2.9.2 TDDの単体テストを書く
 2.9.3 リファクタリング(コードのクリーン)

第3章 エンジニアが最もよく使う手法ーブラックボックステストー

3.1 ブラックボックステストの基本ー同値分割と境界値分析法ー
 3.1.1 簡単な同値分割・境界値分析の例
3.2 どんな入力も正しく処理するにはー同値分割法ー
 3.2.1 テストケースを書いてみよう〜非常に強いテストケース〜
 3.2.2 テストケースの数を減らすには〜実践的なテストケース〜
3.3 バグの住む場所を探すー境界値分析法ー
 3.3.1 テストケースを書いてみよう
 3.3.2 境界をテストするには〜On-Offポイント法
 3.3.3 経験則によるテストケース
3.4 複雑な入出力のためのテストーディシジョンテーブルー
3.5 GUIをテストするー状態遷移テストー
 3.5.1 状態遷移とは
 3.5.2 状態遷移テストで見つかるバグ
3.6 サルにもできるテスト?ーランダムテストー
3.7 まとめ

第4章 探索的テスト

4-1 テストケースベースのテストーversus探索的テストー
 4.1.1 「テスト設計・ケース作成を早い段階で行う」デメリット
 4.1.2 「同じテストケースをたくさん実行する」デメリット
4-2 探索的テストのサンプル 
 4.2.4 クライテリア決め
 4.2.5 探索的テストのタスク実行
4-3 非機能要求に対する探索的テストのアプローチ
4-4 探索的テストまとめ

第5章 機能あらざるもののテスト、最難関のテストに挑むー非機能要求のテストー

5.1 非機能要求のテストの困難さ
5.2 期待通りの性能を引き出すためにーパフォーマンステストー
 5.2.1 パフォーマンステストの五つのステップ
5.3 攻撃に耐えうるソフトウェアの構築ーセキュリティテストー
 5.3.1 セキュリティテストの重要性
 5.3.2 攻撃の歴史と種類
 5.3.3 モジュール指向のテスト
 5.3.4 静的解析ツール
 5.3.5 基本的なテスト手法
5.4 信頼性ってちゃんと知ってます?知ったかぶりしてません?ー信頼制度成長曲線ー

第6 ソフトウェアテスト運用の基本ーテスト成功の方程式ー

6.1 最悪のソフトウェアを出荷しないようにするにはーコストと品質のバランスー
6.2 テストプランの書き方ーIEEE 829テストプランテンプレートー
 6.2.1 IEEE 829のテストプランテンプレート
 6.2.2 テストプラン文書番号(Test Plan identifier)
 6.2.3 レファレンス(References)
 6.2.4 はじめに(Introduction)
 6.2.5 テストアイテム(Test-items)
 6.2.6 テストするべき機能(Features to be tested)
 6.2.7 テストする必要のない機能(Features not to be tested)
 6.2.8 アプローチ(Approach)
 6.2.9 人員計画、トレーニングプラン(Staffing and treaning needs)
 6.2.10 人員や時間をどう見積もるか
 6.2.11 スケジュール(Schedule)
 6.2.12 テストスケジュールは開発スケジュールに依存する
 6.2.13 スケジュールをコントロールするコツ
 6.2.14 リスクとその対策(Risks and contingencies)
 6.2.15 承認(Approvals)
 6.2.16 終了基準
 6.2.17 テストプランの理想と現実
6.3 テストケースの書き方ー効率的なテストケースの作成と管理ー
 6.3.1 テストケースの記述例
 6.3.2 テストケース管理ツールを使う
 6.3.3 テストケースはいくつ必要か
6.4 テストケースの実行ーどのテストをどの順番で実行するかー
6.5 テスト開始のタイミングーテスト担当者はどの段階でプロジェクトに参加するかー
6.6 出荷前日にバグが発見されたときの対処法ー出荷延期を判断するポイントー

第7章 ソフトウェア品質管理の基本ーソフトウェア品質のメトリックスー

7.1 品質を目に見えるものにするにはーメトリックス選択の基本ー
 7.1.1 バグの数を管理するバグメトリックス
 7.1.2 バグ修正にかかる時間
 7.1.3 モジュールで見つかるバグ
7.2 コード行数からわかる意外な事実ーソースコードメトリックスー
7.3 複雑なコードほどバグが出やすいー複雑度のメトリックスー
7.4 Microsoftはどんなメトリックスを使っているのかー無駄のないメトリックス選択の例ー
7.5 汝、人を謀るー測るーなかれーメトリックスの間違った使い方ー

第8章 テストの自動化という悪魔ーなぜ自動化は失敗するのかー

8.1 その自動化ツールは役に立っていますか?ーテスト自動化の功罪ー
 8.1.1 テストの自動化はなせ自動化は失敗するのか
8.2 テスト担当者が陥りやすい罠ーテスト自動化の本当の問題点ー

第9章 それでもテストがうまくいかない人へ

9.1 組み合わせテストをやめる
9.2 品質の低いモジュールを徹底的に叩く
 9.2.1 Googleアルゴリズム

本書は付属データの提供はございません。

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影(表紙画像)をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影(表紙画像)以外のご利用については、こちらからお問い合わせください。

追加情報はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付(書籍の最終ページ)に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2022年01月21日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 033
下から2行目
5刷
以下にループの原因
以下に無限ループの原因

※リフローEPUBの場合、2章の「2.7.1 プログラムのループ」の3つ目の段落が該当箇所になります。
2018.03.12
1刷 051
3章の大見出し「3.1 ブラックボックステストの基本」のサブタイトル
6刷
―同値分割法と境界分析法―
―同値分割法と境界分析法―
2019.02.21
1刷 051
3章の最初の大見出し(見出し番号3.1)
2刷
ブラックボックステスの基本
ブラックボックステストの基本

目次(p.vii)、章扉(p.49)および同ページのハシラも同様です
2014.01.31
1刷 057
下から3行目
5刷
テストケーを一つ割り当てています。
テストケースを一つ割り当てています。

※リフローEPUBの場合、3章の「3.2.2 テストケースの数を減らすには ~実践的なテストケース~」の2つめの段落が該当箇所になります。
2018.02.28
1刷 070
表3-2
2刷
「状態」列の2行目 C1:B=正しい 「A1:計算値出力」行の「ルール2」のチェックマーク
→ C2:B=正しい → 空白に
2014.09.22
1刷 076
図3-18の右下
2刷
Open Save diaiog
Open Save dialog

i(アイ)をl(エル)に訂正
2015.02.03
1刷 106
下から3行目
8刷
確かめるためる非機能要求のテストがあります。
確かめるために非機能要求のテストがあります。
2022.01.21
1刷 111
図5-5 品質特性のトレードオフ
3刷
列方向、行方向に各2つある「正確性」
最上段・左端の「正確性」は「正当性」
(画像クリックで拡大)
2015.10.05
1刷 113
「要求定義通りのテストケースを書かない」下から2行目
6刷
要求定義通を逸脱するような
要求定義を逸脱するような

※リフローEPUBの場合、5章の「5.2 期待通りの性能を引き出すために」の小見出し「要求定義通りのテストケースを書かない」の本文が該当箇所になります。
2019.02.21
1刷 151
下から3行目~4行目
6刷
推奨するような以下のような
推奨する以下のような

※リフローEPUBの場合、6章の図6-1のすぐ下の段落が該当箇所になります。
2019.02.21
1刷 180
下から4行目
2刷
ゴンルツ曲線
ゴンルツ曲線

※リフローEPUBの場合、7章の「7.1.1 バグの数を管理するバグメトリックス」の3つめの段落が該当箇所になります。
2015.02.03
1刷 191
コード
5刷
func1( ) {   if(i > 0)   {     switch(n)     {       case 0:         //do something       case 1:         //do something       case 3:         //do something       default:         //do something
func1( ) {   if(i > 0)   {     switch(n)     {       case 0:         //do something         break;       case 1:         //do something         break;       case 3:         //do something         break;       default:         //do something         break;

4か所に「break;」を追加

※リフローEPUBの場合、7章の「7.3 複雑なコードほどバグが出やすい」内のColumn「コードの複雑度」のコードが該当箇所になります。
2018.06.18
1刷 192
図:ルートとノードで表したフローチャート
5刷

(画像クリックで拡大)

(画像クリックで拡大)

※リフローEPUBの場合、7章の「7.3 複雑なコードほどバグが出やすい」内のColumn「コードの複雑度」の図「ルートとノードで表したフローチャート」が該当箇所になります。
2018.04.23
1刷 194
<ソフトウェアの信頼性メトリックス>3項目目
5刷
●ストレステストを行った際のMTTF
●ストレステストを行った際のMTBF

※リフローEPUBの場合、7章の「Microsoftはどんなメトリックスを使っているのか」にある小見出し<ソフトウェアの信頼性メトリックス>の3つめの箇条書きが該当箇所になります。
2018.04.23
1刷 194
脚注「*4」
5刷
同などのことと
同等のことと
2018.04.23
1刷 210-211
P210末尾からP211先頭
2刷
もしあなたのチームがall-pair all-pairなり直交表なり
もしあなたのチームがall-pairなり直交表なり

「all-pair」が重複しているのを修正

※リフローEPUBの場合、9章の「組み合わせテストをやめる」の2つめの段落が該当箇所になります。
2014.09.19

感想・レビュー

みん さん

2018-04-02

Microsoftなど代表的な企業で行われているテスト手法、一般的なテストの心得、考え方などが学べて良かったです。テストの自動化を自分でスクリプト書いて行う方法は是非ともやってみたいと思いました。若手SEには大変オススメな一冊だと思います。

リットン さん

2021-12-20

自分で書いたプログラムのテストをどうしようかなと思って読んだ。テストの専門家、テストの部署っていうのが開発会社にはいるんだなあ。。。素人目にはTDD的な細かくテストしていく感じが良さそうな気がしたけど。結局、どうテストをしたらいいかはよくわからなかったけど、そもそもどんなサイズのプログラムもこうやればオッケーみたいなマニュアルはなくて、どこまでテストすべきかも含めて考えるべきなんだなあと感じた。

よっしー@challenge さん

2021-07-04

システムテストの考え方を棚卸し。ホワイトボックで論理構造を確認、ブラックボックスで入出力の妥当性検証。BTは境界値分析、複数の入出力ケースはディシジョンテーブル、GUIは画面遷移にて。非機能はパフォーマンスの他、信頼性(障害時の切り替え処理)等。 テストプランはIEEE829を参考に。(ベースは1998で良い。バージョンによっては難解。。) テスト実行順は重要度の高い部分から!改修期間を考慮。大規模の場合は2:8の法則にて品質が低い部分を叩くのが有効。入門書とはいえユーザー企業目線ではちょっと難しかった