高橋寿一のレビュー一覧
-
Posted by ブクログ
AIとソフトウェアテスト 信頼できるシステムを構築するために
他著：Adam Leon Smith
他著：Rex Black
他著：James Harold Davenport
出版社：インプレス
本書は、ＡＩと品質に関するトピックをめぐる書とあります。
ＡＩシステムの生成した、仕様書やプログラムコードは本当に信頼に値するものなのか、その保証を求めるために本書を購入したが答えはなかった。ＡＩが生成した成果物の妥当性と、ＡＩ駆動開発が生み出したシステム全体を担保する基準は決して同じではないとおもいますが、同じものを入力しても、時として別のコードを生成するＡＩについては、何を基準にすればいいのか、頭が混乱する一方である。
オントロジ―という概念があり、ＡＩに適用している内容を見る限り、これまでのＩＴのアプローチとは明らかに区別がしたいのだというのは伝わってきた
コンテキスト
アクティビティ
手法
成果物
環境
テストプロセス
テストフェーズ
リソース
手順 等々、旧来のテストと見た目あまり変わらないと感じるが、その生成プロセスがことなっているのでしょうか。
一方、機械学習を含めて、学習したＡＩシステムに対する信頼性は。こちらは、USAや、EUにある程度のガイドラインがありました。
顧客にAI駆動開発の成果物を納品し、また、受け入れを行う場合に何をもって、発注したものと、相違ないことを確認できるのでしょうか。
ほしいのは、クライアントから、「AI駆動で生成した方法論・ドキュメントを確認した。ここの内容であれば、問題はない。発注しよう」ということばであり、納品物をみて、「AI駆動で生成した成果物を確認した。ここの内容であれば、問題はない。検収しよう」というひとことなのですか。
気になったのは、以下です。
信用できるＡＩなのかどうかのガイドライン
米国立標準技術研究所(NIST)の2020年米国防授権法(NDAA)のガイドラインに合致しているかどうか
ＡＩの品質に関する問題事項
①仕様のない自動化
②不確かな回答、どうやったらその答えが正しいかどうかを判断できるのか
③入力の複雑さ
④システムの複雑さ
⑤自己最適化、システムがどのように最適化をするのか 等
ＡＩの品質測定モデル
タイプⅠエラー キリンなのに、猫と認識している、擬陽性問題
タイプⅡエラー 猫なのに、キリンと認識している、偽陰性問題
ＡＩの品質規制
①一般データ保護規制(GDPR:2016)
②EUのAI規制(2024)
③国際ソフトウェアテスト資格認定委員会(ISTQB:2021)
機械学習システムのテスト
ホワイトボックステスト ×
ブラックボックステスト 〇
テストレベル
ユニットテスト(UT)
コンポーネントテスト
統合テスト（IT)
システムテスト（ST）
受入テスト（UAT)
モデルテスト
入力データテスト この２つはＡＩ固有
テスト技術
ペアワイズテスト 入力のペアをつくって操作する
メタモルフィックステスト 以前のテストの実行結果をつかって新しいテストケースを作り出す
敵対的テスト モデル脆弱性を、侵入チームがチェックする
バックツーバックテスト 並列テスト、差分テスト
リグレッションテスト（回帰テスト）デグレードがおきていないかのチェック
モックの利用
テスト駆動開発
・コードは書くよりも読む機会のほうが１０倍多い⇒ 読みやすさの追及
・ユニットテスト生成
ＵＩテストの自動化
・テスト実行の並列化
・テストの優先順位付け
・モンキーテスト ランダム入力
・ファズテスト 乱数
・ビジュアルテスト
バグの管理
異常検知
オントロジー駆動型ソフトウェアテスト
・Ｗｅｂサービスオントロジー
・Ｏｎｔｏ Ｔｅｓｔ オントロジー
・ソフトウェアテストオントロジー
・ソフトウェアテストオントロジーの参照オントロジー
・ＡＩ－Ｔオントロジー
品質保証を支援するための概念モデルを使う
目次
本書の注記／本書情報及び正誤表のＷｅｂページ
推薦のことば
図表一覧
略語
用語
序文
翻訳・監修者まえがき
第1章 イントロダクション《Adam Leon Smith》
1-1 AIテストの課題
1-2 まとめ
第2章 信用できるAIと品質《Adam Leon Smith》
2-1 AIに対する信用
2-2 AIの品質問題
2-3 AIソフトウェアの品質測定モデル
2-4 AIの品質規制
2-5 まとめ
第3章 品質とバイアス《James Harold Davenport》
3-1 バイアス定義の推論と帰結
3-2 日常生活におけるバイアス
3-3 意図しないバイアス
3-4 シンプソンのパラドックス
3-5 まとめ
第4章 機械学習システムのテスト《Adam Leon Smith》
4-1 テスト担当者の役割
4-2 MLの性質
4-3 テストのメトリクス
4-4 テスト技術
4-5 AI固有の特性をテストする
4-6 非決定論的システム
4-7 透明性、説明可能性、解釈可能性
4-8 まとめ
第5章 AIベースのテストの自動化《Jeremias Rößler》
5-1 品質保証
5-2 マニュアルテストと自動テスト
5-3 ユニットテストの自動化
5-4 UIレベルのテストの自動化
5-5 ソフトウェア品質保証における他のタスクへのAIの適用
5-6 テスト支援ツールの評価
5-7 AIにとって今後も困難が予想される課題
5-8 まとめ
第6章 ソフトウェアテストのオントロジー《Joanna Isabelle Olszewska》
6-1 オントロジーについて
6-2 オントロジーとAI
6-3 ソフトウェアテストのためのオントロジー利用
6-4 オントロジー駆動のソフトウェアテスト動向
6-5 まとめ
第7章 デジタルツインのメタバースにおけるシフトライトテスト《Jonathon Wright》
7-1 テストのシフトライトアプローチ
7-2 コグニティブエンジニアリング原理
7-3 シフトライトにおけるデジタルツインコンセプト
7-4 ［ケーススタディ］パンデミック時に地域社会の安全を支援する
7-5 ［ ケーススタディ］スマートシティのデータ交換――メタバースにおけるテスト
7-6 メタバースへの移行
7-7 革命より進化
7-8 まとめ
翻訳・監修者あとがき
著者紹介
原書発行元のＢＣＳについて
翻訳・監修者紹介
参考文献
索引
ISBN：9784295021445
判型：A5
ページ数：232ページ
定価：2800円（本体）
2025年11月21日初版発行 -
-
-
-
-
-
Posted by ブクログ
今までの経験した現場のことしか言えないが、本書のテーマである、Shift Leftして開発作業を楽にするという考え方を実践している開発現場は少ない。アジャイル開発だとドキュメントはいらないかと勘違いしていたけれど、最低限、クラス図とシーケンス図はあるべきとか、MVC分離は必須とか、関数の出口は1つにすべきとか、単体テストをしっかりやるならウォーターフォール開発も否定されるものではないとか、得るものがたくさんあった。レビューは、間違いを指摘するというより、質問によって本人が気づくことに重点が置かれるものという点に納得。Microsoftでは当然のように行われている単体テストを嫌いな日本人が多いという記述にはちょっと驚き。海外と比べて日本の方がちゃんとやっていそうなイメージだったので。Androidアプリの単体テストの方法が丁寧に書かれていて分かりやすい。
-
-
-
-
-
Posted by ブクログ
上流品質を上げることでプロジェクト後半の大量のバグをなくそう、という主張には大きく同意した。どうしても開発工程では完成させるのが目的になってしまい、単体テストで網羅することを疎かにしがちだ。
ただ全体を見渡せばシステムテスト、ユーザーテストでバグが頻出するほうが切なく、同じバグでも解消に非常に時間を要すという経験もある。
本書では理論的な品質工学も交えながら、それでも平易に上流工程でのテストの進め方、心構えを短い章立てで教えてくれる。
少し各章のつながりが分かりづらく、まとまりがないようにも感じられるが、エッセンスを取り入れるという意味では本書の構成も有用と思えた。 -
-
-
-
Posted by ブクログ
ソフトウェア開発において近年ますます重要性を増すも理想に近付くのはいつまで経っても難しいテストを基礎から解説した一冊。数々の企業で様々なソースコードを読んできた著者の経験を基に「上流品質の上げ方」が懇切丁寧に説明されている。コンサルというバックグラウンドゆえか人員追加やタスク増加を暗黙の前提としない方針で書かれているのも地味だけど助かる。文章も平易で割とサクッと読めるが、熟練エンジニアの方は薄い内容だと感じるかもしれない。ただ、サクッと読めるボリュームだからこそ「自分は理解できてるから要らないよ」と過信せずに一度謙虚に読んでみるのが良いと思う。
-
-
-
Posted by ブクログ
ネタバレ## テストで大事なこと
- テストで大事なのは、どの部分にバグが出やすいか、そこをどのようにテストすれば十分な品質が得られるかを知ること
- バグは平均的に散らばっているものではない。バグの出やすい箇所、出にくい箇所がある。(80%のバグが20%のコードに含まれているというデータもある)
- テストは限られた時間で行う最大公約数的な仕事。時間がないからテストしないという選択肢はない
- James曰く、「ソフトウェアは4つの仕事しかしない。なので、その4つの振る舞いをテストすれば良い」
- 4つとは、 `入力を処理する`、 `出力を処理する`、 `計算を行う`、 `データを保存する` それらに対して適切にテストすれば、ほとんどのバグが発見できる
- テストケースを省略するのはやむを得ないが、その省略されたテストケースでバグを出してはいけない
- テストするのに「良いデータ」と「悪いデータ」が存在する
- 良いデータ例
- ユーザーがよく使いそうなデータ
- プログラムが許す最小のデータ
- プログラムが許す最大のデータ
- ゼロ
- 悪いデータ例
- 非常に小さなデータ(-99999,0.0000001など)
- 非常に大きいデータ(999999,1099999など)
- 長いデータ(abdajohadamklmdklamombamoaなど)
- 無効なデータ
- とっとと楽して60%のバグを見つけ、そのほかのバグがなぜ発生したか、どうやって防止するかに時間を費やすかが、より建設的なテスト担当者の役割
- 品質を目に見えるものにするには
- なるべく誤差がなく人間の市場や恣意に左右されないものを選ぶ
- 開発するソフトウェアの品質を十分代表するものを選ぶ
- Googleのバグ予測システムでは、いつ何回修正されたかしか見ていない。修正された回数が多いほど、修正が最近ほどバグが潜んでいるということ。
# テスト手法
## ホワイトボックステスト
- プログラムの論理構造が正しいかを解析するテスト
- 人間の時間をたくさん使って内部構造を解析しテストする
- 論理構造の正しさのみをテストするため、 `ソフトウェアの仕様が間違っていることから起こるバグは発見できない。`
### 制御パステスト
- プログラムがどのような振る舞いをして、どのように制御されていくかをテストする手法
- カバレッジ率の値を取るために使われる
- 制御パステストによるコードカバレッジテストの本質は、フローチャートをちゃんとカバーすることにある
### ステートメントカバレッジ
- 制御パステストの一部
- ステートメントカバレッジだけでテストを終了することは危険
- 分岐条件がカバーしきれないなど、非常に弱いテスト手法
### ブランチカバレッジ
- `分岐コードに対してそれぞれの判定条件がTrue/Falseの結果を少なくとも1回ずつ持つようにテストケースを書く`
- 分岐を網羅するため、テストケースの数がかなり増える点が問題点
- バグの発生状況を見てから、バグがたくさん出る部分に対してブランチカバレッジを実行するのは悪くないアイデア
## ブラックボックステスト
- ブラックボックステストは、プログラムをブラックボックスと見立てて、 `様々な入力を行うことによって、ソースコード利用せずテストを行う手法`
### 同値分割法
- 同値分割とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を透過とみなす作業
- つまり、可能な入力値のうち同様の入力値は等価とみなしてテストする手法
- 同値クラスの分け方は
- 有効同値：プログラムが期待する入力値
- 無効同値：有効同値以外の入力値
- 実践的な同値クラスの選び方は、 `ポイントは代表する同値が全てのエレメントを網羅しているか`です
### 境界値分析法
- 同値分割法とセットで使われる手法
- プログラムで「境界」と呼ばれる場所は常にバグが潜んでいるので、強化位置近くは詳しくテストする必要がある
## ランダムテスト/アドホックテスト
- テストケースを考えず、行き当たりばったり、なんら考えなしに入力や操作を行う手法
### まとめ
テストは
1. まずは強化位置テストを行い、境界地にまつわるバグを全て潰す
2. ディシジョンテーブルテスト行う
3. 状態遷移テストを行う
## 探索的テスト
- ソフトウェアの理解とテスト設計とテスト実行を同時に行うテスト
- すべてのテストを実施するのは時間的に無理、できてもすべてのバグは見つからない。
それならいちいちテストケースを書く代わりに、製品を 学習 したうえでテスト 設計 して 実行 してバグ報告を 並行 してやっちゃえば手っ取り早い。 というスタイル
- 探索的テストの唯一のデメリットは、非機能要求(=品質特定)のテストにあまり向かない
## 非機能要求のテスト
- 非機能要求(=品質特定)とは、「ソフトウェアが持つべき特性」で、機能的な側面と非機能的な側面の両方の属性を示したもの。
- とくに大事なのは、機密性、信頼性、パフォーマンス
### パフォーマンステスト
- ソフトウェアを設計もしくは企画する段階で設定されたソフトウェアの性能が期待された通り出ているかをチェックするためのテスト
- レスポンスタイムや、入力データサイズなどの設計前にソフトウェアのパフォーマンスを定義する -