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

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

著

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

購入はこちら

企業・教育機関での一括購入

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

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

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

※本電子書籍は同名出版物を底本とし作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

（翔泳社）

画像01
目次の登録はありません。
本書は付属データの提供はございません。

お問い合わせ

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

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

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

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

追加情報はありません。
この商品の「よくある質問」はありません。

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

書籍の種類:電子書籍

書籍の刷数:全刷


※重版をした際に、内容が修正されている場合があります。「刷数の確認方法（例）」の図を参考に、お手元の書籍の刷数をご確認ください。下の「書籍の刷数」の欄で刷数を選択すると、お持ちの書籍の刷数に合わせて、正誤情報を絞り込むことができます。

書籍によっては表記が異なる場合がございます


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

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

　書籍の刷数で正誤情報を絞り込みたい場合は選択してください。

　書籍の種類:

最終更新日:2022年01月21日
ページ数 内容 書籍修正刷 電子書籍訂正 発生刷 登録日
033
下から2行目
誤 以下にループの原因
正 以下に無限ループの原因
備
考		 ※リフローEPUBの場合、2章の「2.7.1　プログラムのループ」の3つ目の段落が該当箇所になります。
5刷 済 1刷 2018.03.12
051
3章の大見出し「3.1 ブラックボックステストの基本」のサブタイトル
誤 ―同値分割法と境界分析法―
正 ―同値分割法と境界値分析法―
6刷 済 1刷 2019.02.21
051
3章の最初の大見出し（見出し番号3.1）
誤 ブラックボックステスの基本
正 ブラックボックステストの基本
備
考		 目次（p.vii）、章扉（p.49）および同ページのハシラも同様です
2刷 済 1刷 2014.01.31
057
下から3行目
誤 テストケーを一つ割り当てています。
正 テストケースを一つ割り当てています。
備
考		 ※リフローEPUBの場合、3章の「3.2.2　テストケースの数を減らすには　～実践的なテストケース～」の2つめの段落が該当箇所になります。
5刷 済 1刷 2018.02.28
070
表3-2
誤 「状態」列の2行目　C1：B=正しい 「A1：計算値出力」行の「ルール2」のチェックマーク
正 → C2：B=正しい → 空白に
2刷 済 1刷 2014.09.22
076
図3-18の右下
誤 Open Save diaiog
正 Open Save dialog
備
考		 i（アイ）をl（エル）に訂正
2刷 済 1刷 2015.02.03
106
下から3行目
誤 確かめるためる非機能要求のテストがあります。
正 確かめるために非機能要求のテストがあります。
備
考		 ※リフローEPUBの場合、表5-1の2つ上の段落が該当箇所になります。
8刷 済 1刷 2022.01.21
111
図5-5 品質特性のトレードオフ
誤 列方向、行方向に各2つある「正確性」
正 最上段・左端の「正確性」は「正当性」
（画像クリックで拡大）
3刷 済 1刷 2015.10.05
113
「要求定義通りのテストケースを書かない」下から2行目
誤 要求定義通を逸脱するような
正 要求定義を逸脱するような
備
考		 ※リフローEPUBの場合、5章の「5.2 期待通りの性能を引き出すために」の小見出し「要求定義通りのテストケースを書かない」の本文が該当箇所になります。
6刷 済 1刷 2019.02.21
151
下から3行目～4行目
誤 推奨するような以下のような
正 推奨する以下のような
備
考		 ※リフローEPUBの場合、6章の図6-1のすぐ下の段落が該当箇所になります。
6刷 済 1刷 2019.02.21
180
下から4行目
誤 ゴンベルツ曲線
正 ゴンペルツ曲線
備
考		 ※リフローEPUBの場合、7章の「7.1.1　バグの数を管理するバグメトリックス」の3つめの段落が該当箇所になります。
2刷 済 1刷 2015.02.03
191
コード
誤 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「コードの複雑度」のコードが該当箇所になります。
5刷 済 1刷 2018.06.18
192
図：ルートとノードで表したフローチャート
誤
（画像クリックで拡大）
正
（画像クリックで拡大）
備
考		 ※リフローEPUBの場合、7章の「7.3 複雑なコードほどバグが出やすい」内のColumn「コードの複雑度」の図「ルートとノードで表したフローチャート」が該当箇所になります。
5刷 済 1刷 2018.04.23
194
＜ソフトウェアの信頼性メトリックス＞3項目目
誤 ●ストレステストを行った際のMTTF
正 ●ストレステストを行った際のMTBF
備
考		 ※リフローEPUBの場合、7章の「Microsoftはどんなメトリックスを使っているのか」にある小見出し＜ソフトウェアの信頼性メトリックス＞の3つめの箇条書きが該当箇所になります。
5刷 済 1刷 2018.04.23
194
脚注「*4」
誤 同などのことと
正 同等のことと
5刷 済 1刷 2018.04.23
210-211
P210末尾からP211先頭
誤 もしあなたのチームがall-pair all-pairなり直交表なり
正 もしあなたのチームがall-pairなり直交表なり
備
考		 「all-pair」が重複しているのを修正

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

感想・レビュー

みん さん

2018-04-02

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

リットン さん

2021-12-20

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

よっしー@challenge さん

2021-07-04

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

関連情報