ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬クロージングセッション) 20101219

HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20101
ソフトウェアテスト・ヒストリーの学び方
辰巳敬三
2010年12月19日
～タメにならなければ学ばない。
面白くなければ学ぶ資格がない。
WACATE 2010冬

(C) K. Tatsumi 20102
自己紹介 : マイヒストリー1975
1990
2000
1980
1985
2010
1995
2005
1976-富士通入社、ソフトウェア事業部検査部
1990-ソフトウェア品質管理ガイドブック(共著)
2007-ソフトウェア品質知識体系ガイド(SQuBOK)(共著)
2009-ソフトウェアテスト・ヒストリー(テストPress Vol.8)
2009-続ソフトウェアテスト・ヒストリー日本編(テストPress Vol.9)
1976-メインフレームOSの製品検査 1990-UNIX/PCソフトウェア製品検査
1999-製品適用サービス
2006-知財/特許
2009-高度情報通信人材育成支援センター
1989-富士通におけるｿﾌﾄｳｪｱ品質保証の実際(共著)
1990-ソフトウェア品質管理事例集(共著)
1987-Conceptual Support for Test Case Design
1987-Test Case Design Support System

(C) K. Tatsumi 20103
内容
 ソフトウェアテスト前史
 コンピュータとソフトウェア技術の歴史
 テストの考え方の進化
 テスト技法の歴史
 日本の品質・テスト技術の歴史
 世界のテスト技術の研究最前線
 まとめ

ソフトウェアテスト前史
 コンピュータの原型
(1/2)
 Charles Babbage(英国)の「解析機関」
• 1837年に設計を開始 (完成には至らず)
• 入力（プログラムとデータ）はパンチカード
• 出力はプリンター、曲線プロッター、ベル
 最初のプログラマー
 Ada Byron, Lady Lovelace
• 解析機関のプログラムを作成(1843年)
– Babbageの講演記録の翻訳の注釈の中に記述

ソフトウェアテスト前史
 最初のテスターは ?
(2/2)
Ada Loverace女史はプログラマの第1号として、19世紀、
Charles Babbageの壮大にして未完成に終わったコン
ピュータのプログラム作成にたずさわったが、「あと1週間
あれば大丈夫です、バベッジ博士。それですべて終わり
ます」と何度も言っていたにちがいない。幸いにもハード
ウェアが完成しなかったため、Loverace女史は机上デ
バッグに巻き込まれずにすんだ。
(ボーリス・バイザー,「ソフトウェアテスト技法」,1994,日経BP)
 Boris Beizerによると・・・
• 『テストやデバッグの最初の議論はAdaのメモに遡る』
• Software System Testing and Quality Assurance
[Beizer,1984] では

内容
コンピュータとソフトウェア技術の歴史
 まとめ

コンピュータとソフトウェア技術の歴史
 別紙の歴史年表参照
2010.11.18 辰巳
▲ ▲ ▲ ▲
EDSAC(最初のﾉｲﾏﾝ型ｺﾝﾋﾟｭｰﾀ) IBM System/360 IBM System/370 Cray-1(スパコン)
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲
UNIVAC1(世界初の商用ｺﾝﾋﾟｭｰﾀ) DEC PDP-1 DEC PDP-8 Apple PC IBM PC ▲ Apple Macintosh iPhone iPad
▲ ▲ ▲ Sun-1 ▲ ▲
IBM 701 IBM 704 Intel 4004MPU Sun SPARC Intel Pentium Pro
(科学演算用) ● ●
(Apple社設立) (Sun Microsystems社設立)
▲ ▲ ▲ ▲ ▲ ▲ ▲
OS/360 UNIX CP/M MS-DOS UNIX System V Linux Windows NT
(4004MPU用OS) Netware ▲ ▲ ▲
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ Windows 3.1 ▲ J2EE .NET ▲
SpeedCode FORTRAN FORTRAN COBOL LISP PL/I C言語 ▲ C++ ▲ Java ▲ Ajax
開発開始 ▲ ALGOL Smalltalk-72 Smalltalk-80 Eiffel ▲ ▲Internet Explorer Ruby on Rails
FLOW-MATIC ▲ Netscape ▲ ▲
● ● HTML/HTTP/WWW XML ● SOAP ●
(Microsoft社設立) (Free Software Foundation) (Apache Software Foundation) (Eclipse Foundation)
▲SAGE(防空管制システム) ▲ ● ● ▲ ▲
▲SABRE(航空座席予約システム) CompuServe America Online Amazon.com Amazon Web Services Amazon EC2
▲マーキュリー計画 (商用オンラインサービス) ● ● Google Docs & Spreadsheets
▲ジェミニ計画 Yahoo! Google ☆
▲アポロ計画発表 ▲アポロ11号有人月面着陸 ● ● クラウド・コンピューティング
eBay Salesforce.com
▲ ▲ ▲ ▲ ▲ ▲ ▲
ETL Mark I<電気試験所> FUJIC<富士写真フイルム> NEAC2200<日本電気> DIPS-1<電電公社> PC-8001 PC-9001 UNIXサーバ
(日本初のディジタル式自動計算機) (日本初の電子計算機)[真空管式] FACOM230<富士通> ▲ ▲ <日本電気> <日本電気> <日立,日本電気,富士通,三菱,沖>
[リレー式] ▲ HITAC8000<日立> 国産メーカ・3グループ化計算機完成 ▲ ▲
▲ ETL MarkⅢ<電気試験所>[トランジスタ式] Mシリーズ<富士通・日立> FM-8<富士通> PCサーバ
FACOM100 ▲MUSASINO-1<電電公社>(日本初のパラメトロン計算機) ACOSシリーズ<日本電気・東芝> <三菱,富士通,日立> ▲
[リレー式] ▲HIPAC MK-1[パラメトロン式] COSMOシリーズ<三菱・沖電気> ▲ Express5800<日本電気>
▲NEAC-1101[パラメトロン式] 日本語ワープロJW-1<東芝> (WinNT3.5搭載PCサーバ)
▲ ▲ ▲
NEAC-1101用ローダなど NEAC2200用の最初のOS DIPS-103-10OS
HIPAC-101用記号入力ルーチン HITAC-5020用モニタ (タイムシェアリングシステム用OS)
▲ ▲ ▲
自動プログラム(FORTRAN)など(HIPAC 103用) FACOM 230-20/30用モニタ MCPII OSIV<富士通>、OS<日立>
▲ (マルチプログラミング処理) ACOS<日本電気・東芝>
FORTRAN/アセンブラ/IOCS/SORT(FACOM 222A) UTS<三菱電機>
▲ ▲ ▲ ▲ ▲ ▲ ▲
日本最初の商用コンピュータ稼働国鉄座席予約システム国鉄オンライン座席予約システムMARS101 JUNET PC-VAN Yahoo! JAPAN アマゾン・ジャパン
UNIVAC120(真空管式) ▲ MARS1 JAL国内線座席予約システム ▲ ▲ ▲
東京証券取引所、野村證券気象庁予報部東京オリンピック・リアルタイム記録管理システム NIFTY 楽天市場 iモード
▲ ▲ ▲ ▲
三和銀行三井銀行オンラインバンキング全銀システム ▲ ▲ ジャパンネット銀行
(初の銀行への導入) 第一次金融オンラインシステム第二次金融オンラインシステム第三次金融オンラインシステム (日本初のネット銀行)
▲ ▲ ▲ ▲1st NCSE(ICSE)
NATO Software Engineering Conference Symposium on Computer Software Reliability
▲ ▲ ▲ ▲ ▲ ▲
構造化定理段階的詳細化構造化設計 CASE Booch法 UML UML 2.0
▲ ▲ ▲ (Computer aided ▲ ▲ ▲
構造化プログラミングトップダウンプログラミング▲ データフロー図 software engineering) オブジェクトモデル化技法デザインパターンｱｽﾍﾟｸﾄ指向ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ
▲ 抽象データ型 ▲ ▲ ▲
▲ 抽象モジュール ▲ オブジェクト指向ソフトウェア工学 Software Architecture テスト駆動開発(TDD)
形式手法 ERモデル ▲
▲ ▲ 契約による設計 ▲
ワーニエ法ジャクソン法アジャイル宣言(Agile Manifesto)
▲ ▲ ▲ ▲ ▲
Waterfall Model(Royce) DoD-2167 DoD-2167A MIL-498 XP
▲ ▲ ▲
Spiral Model(Boehm) ISO/IEC 12207 ISO/IEC 15288
▲ ▲ (ｿﾌﾄｳｪｱﾗｲﾌｻｲｸﾙﾌﾟﾛｾｽ) ▲ (ｼｽﾃﾑﾗｲﾌｻｲｸﾙﾌﾟﾛｾｽ)
ISO 9000 CMM CMMI
▲ ▲ ▲ △ ▲ ▲ ▲
プログラム品質特性(Ruben) 品質特性(Boehm) 品質モデル(McCall) ▲ ISO9126標準化開始 ISO/IEC 9126 ISO/IEC 14598 ISO/IEC 15939
1965 19701950 1955 1960 20102000 20051975 1980 1985 1990 1995
ハードウェア
ソフトウェア
開発技法/開発方法論
マネジメント/プロセス
コンピュータの歴史とソフトウェアテスト・品質技術の歴史
コンピュータ時代の幕開け
「計算機」パラダイムの時代
「日の丸コンピュータ」
の開発促進期
分散処理ネットワーク
の普及期
IBMを中心とする
市場開拓期
ミニコンと汎用機ソフト
市場の成長期
ﾊﾟｿｺﾝ, ﾜｰｸｽﾃｰｼｮﾝ
の誕生・普及期
オープンシステムへの
転換期
「情報処理」パラダイムの時代
インターネットの
急成長期
社会インフラとしての
IT浸透期
「ネットワーク」パラダイムの時代
ソフトウェア
ハードウェア
世界
(米国)
日本
稼働システム
稼働システム
ITパラダイム
の変遷 (*1)
コ
ン
ピ
ュ
ー
タ
の
歴
史
ソ
フ
ト
ウ
ェ
ア
技
術
の
歴
史
品質モデル、品質測定
会議・シンポジウム
品質特性・品質モデル
クラウド・コンピューティン
グの時代？
ソフトウェア・マネジメントの観点(*2)
ソフトウェア・エンジニアリングの進化(*3)
品質の時代機能の時代スケジュールの時代コストの時代
<反> 並行プロセス対順次プロセス<反> ソフトウェア工芸(Crafting) <合と反> 形式化とウォータフォールプロセス <合> 生産性と拡張性<正> ハードウェア工学的なソフトウェア工学 <反、部分的に合> 俊敏性と価値
世界
(米国)

[出典] Basili, Musa, “The Future Engineering of Software: A Management Perspective,“ 1991
 1960年代: 機能の時代
 ITが社会に入り始めた
 社会的ニーズに応えられる機能の開発が主要課題
 1970年代: スケジュールの時代
 ソフトウェア危機(NATO会議,1968年)
 計画期間内にソフトウェア開発を完了させることが主要課題
 工程を明確化したライフサイクルモデルが紹介され始めた
ex. Royce waterfall model、品質モデル
1950 1980 19901960 1970 2000 2010
スケジュールの時代コストの時代品質の時代機能の時代
ソフトウェア・マネジメントの観点 (1/2)

 1980年代: コストの時代
 ハードウェアコストの継続的低減、パソコンの出現
 ソフトウェアの価格の高さに目が向き始め、コスト/生産性が
主要課題
 各種のコストモデルが提案され、適用され始めた
ex. Function Point、Putnamモデル、COCOMO
 1990年代: 品質の時代
 ソフトウェアに対する社会の依存度の増大
 マスマーケットでの利用者が増え、ソフトウェアの故障や使
いにくさが深刻な事態を招くことが広く認識されはじめる
1950 1980 19901960 1970 2000 2010
スケジュールの時代コストの時代品質の時代機能の時代
ソフトウェア・マネジメントの観点 (2/2)

ソフトウェア工学の進化
 Boehmのヘーゲル的進化ビュー
 ソフトウェア工学の歴史を弁証法で捉える
テーゼ(正) 対アンチテーゼ(反) → ジンテーゼ(合)
自律;
バイオ・
コンピュー
ティング
1990年代 2010年代2000年代1970年代 1980年代1960年代1950年代
COTS
工芸品
としての
ソフトウェア
テーゼ
(正)
ジン
テーゼ
(合)
アンチ
テーゼ
(反)
形式化;
ウォータ
フォール
生産性;
再利用;
オブジェクト;
ピープルウェア
計画駆動の
ソフトウェア
成熟度
モデル
アジャイル
メソッド
ハードウェア
のような
ソフトウェア
の扱い
リスクベース・
アジャイルと
計画駆動の
ハイブリッド;
モデル駆動開発
ソフトウェア
工学と
システム工学
の統合
バリューベース法;
コラボレーション;
グローバル開発;
エンタープライズ・
アーキテクチャ
ソフトウェアと
ハードウェアの違い,
技術者の不足
多くの欠陥
スケーラビリティ,
リスクマネジメント
プロトタイピング
Time to Market,
迅速な変化
スケーラビリティ
ドメイン工学
リスクマネジメント
準拠
プロセス・オーバヘッド
ソフトウェアの
付加価値
ソフトウェア－
システム工学
グローバルな
Systems
of
Systems
[出典] B. Boehm, A View of 20th and 21st Century Software Engineering, 2006のプレゼンテーションスライドから引用

内容
 ソフトウェア技術の発展過程
テストの考え方の進化
 まとめ

テストの考え方の進化
 D. Gelperin and W. Hetzel,
“The Growth of Software Testing,” 1988
• テストの歴史的成長過程を5段階に区分
• 区切りは各段階開始のマイルストーンとなった文献
 1. デバッグ指向の時代 ( ～1956年)
 2. 論証指向の時代 (1957年～1978年)
 3. 破壊指向の時代 (1979年～1982年)
 4. 評価指向の時代 (1983年～1987年)
 5. 予防指向の時代 (1988年～ )

1. デバッグ指向の時代 (～1956年)
 デバッグとテストが区別されていなかった時代
 ソフトウェアはハードウェアの信頼性の一部
 『難しいのは間違いを検出することではなく、
異常原因の究明である』
(Gill <EDSAC開発メンバー>, 1951)
 プログラムを書いたらチェックする(check it out)程度の認識
checkout, debugging, testingの定義はまだ不明確
 McCracken, "Digital Computer Programming,“
1957 (最も初期のプログラミング教科書)
• ”Program Checkout”の章でデバッグやテストを説明
評価
指向
論証指向
破壊
指向デバッグ指向予防指向
1950 1980 19901960 1970 2000 2010

2. 論証指向の時代 (1957年～1978年)
 テストはプログラムが仕様を満足していることを示す
ためのもの
 Baker, "Digital Computer Programming"の書評, 1957
• 『デバッグとテストという二つのフェーズを区別すべき』
– デバッグ：コーダの目論見どおりにプログラムが動くことを確認
– テスト：解決しようとした問題が解決されていることを確認
 大規模プロジェクト(1950年後半～1960年代)
• 軍や航空・宇宙関係のシステム開発
– SAGE(防空管制システム), SABRE(航空座席予約システム),
宇宙(マーキュリー計画,ジェミニ計画,アポロ計画)
• コンピュータメーカでの基本ソフトウェア開発
– IBM OS/360 (参考) Brooksの「人月の神話」
 ソフトウェア工学の歴史の幕開け(1968, 1969)
• NATO Software Engineering 会議
「テストではバグの存在は示せるがバグがないことは示せない」(Dijkstra,1969)
(1/2)
論証指向デバッグ指向
評価
指向
破壊
指向
予防指向
1950 1980 19901960 1970 2000 2010

2. 論証指向の時代 (1957年～1978年)
 テストのコミュニティの開始
• Debugging Techniques in Large Systems シンポジウム(1970年)
• 最初のテストのシンポジウムの開催(1972年6月)
The Computer Program Test Methods Symposium
• 最初のテストの書籍
Hetzel(Ed.), "Program Test Methods," 1973
 テスト技術の研究の拡大
• 最初のテストケース設計の理論付け
Goodenough, Gerhart, "Toward a Theory of Test Data Selection," 1975
• テスト・ワークショップの開始 (現在のISSTAの源流)
Software Testing and Test Documentation Workshop, 1978
<参考>1973年, Wulfの品質属性の定義, Boehmらの品質モデル
(2/2)
評価
指向
破壊
指向
予防指向
1950 1980 19901960 1970 2000 2010

3. 破壊指向の時代 (1979年～1982年)
 テストとは、エラーをみつけるつもりでプログラムを実
行する過程（テストの成功とはエラーを見つけること）
 Myers, "The Art of Software Testing," 1979
テストでは、経済学的・心理学的な観点が大切
• 投資対効果の最大化を目的とすべき
(限られたテストで検出できるエラー数を最大に)
• 『完全なテストは不可能であるから、いかなるプログ
ラムのテストも不完全にならざるを得ない。だから、
作戦としては、この不完全さをできる限り減らすこと
であることが明らかである。』
⇒ これが、きちんとテスト設計することの意味であり、
テスト設計技法の目的
1950 1980 19901960 1970 2000 2010
評価
指向
破壊
指向
予防指向

4. 評価指向の時代 (1983年～1987年)
 ソフトウェアのライフサイクルを通じた評価活動の中
にテストが位置付けられた時代
 FIPS 101 (米国標準局(NBS)規格), 1983
"Guideline for Lifecycle Validation, Verification, and
Testing of Computer Software"
• ライフサイクルの中で、解析、レビュー、テストの活動
を統合する方法論、各フェーズのVV&T技法
⇒ ソフトウェアの品質は単一の技法で保証できる
ものではない。個々のプロジェクトで吟味して
選んだ技法群を使うことにより品質のよい
ソフトウェアの開発が可能になる
1950 1980 19901960 1970 2000 2010
評価
指向
破壊
指向
予防指向

5. 予防指向の時代 (1988年～)
 ソフトウェアライフサイクルと並行して進められる予防
指向のテストプロセス
 テスト方法論STEP (Systematic Test and Evaluation Process)
Hetzel, "The Complete Guide to Software Testing 2nd Ed.," 1988
• ソフトウェアライフサイクルと並行してテスト活動を実施
• テスト計画の立案、テストの設計、テストのメトリクスの収集方法、
リスク分析法などから構成
現在の“Wモデル”につながる考え方
＜補足＞ Hetzelは既に1973年の"Program Test Methods"で
「テストは設計とコーディングの全プロセスにおいて
計画されなければならない」
と書いている。
1950 1980 19901960 1970 2000 2010
評価
指向
破壊
指向
予防指向

Beizerのテスト道
 テスト担当者の精神面による区分
• フェーズ0 : テストとデバグには何の差もない。デバグ以外
にはテストには特別な目的はない。
• フェーズ1 : テストの目的は、ソフトウェアが動くことを示す
ことである。
• フェーズ2 : テストの目的は、ソフトウェアが動かないという
ことを示すことにある。
• フェーズ3 : テストの目的は、何かを証明することではなく、
プログラムが動かないことによって発生する
危険性をある許容範囲にまで減らすことである。
• フェーズ4 : テストは行動ではない。テストをしないで品質の
高いソフトウェアを作るための精神的な訓練である。
[出典] B. Beizer, "Software Testing Techniques,2nd Ed.," 1990
(電通大・西先生の命名)

内容
テスト技法の歴史
 まとめ

テスト技法の歴史 : 胎動期
テスト技法の多くが確立する1970年以前の状況
 1960年代前半はテストに関する論文は少ない
 テスト文献数(累積)
1969年-57件、1973年-200件、1977年-400件以上
 内容的にもテストの手順やテストの自動化に関するもので、
テスト技法に関する内容は見受けられない。
 1960年代後半
 IBMのOS/360の開発プロジェクト (Brooksの「人月の神話」)
• 1966年リリース、1967年に本格的マルチタスクOSのMVTをリリース
かなりのテスト作業が行われ、テストプロセス、テスト技法、
テストマネジメントに関するノウハウが蓄積された筈
(1/2)

テスト技法の歴史 : 胎動期
 IBM社のElmendorfのテスト制御プロセス
 Elmendorf, "Controlling the functional testing
of an operating system," 1969
• Elmendorfは1965年からOS/360の
ソフトウェアテストを担当
• この論文から、きちんとしたテストプロセス
が実践されていたことが伺える。
• このプロセスによりテストを自由放任から
統率へ、芸術から科学的なアプローチに
変えていくことができると言っている。
予防指向プロセス, Wモデルの先駆け
(2/2)
設計
仕様化
実装
テスト
プログラム目標
テスト目標
プログラム仕様書
調査
識別
評価
レビュー
監視
機能バリエーション
テスト計画
テスト仕様書
テスト資材
プログラム
テスト結果
【開発工程】【テストプロセス】

同値分割、限界値分析
 入力データを「同じ出力結果が得られるグループ」に
分割して各グループ(同値クラス)の代表値、および
同値クラスの端に着目してテストケースを作成
<歴史>
 同値分割、限界値分析という名称でテスト技法として確立
したのは、1979年のIBMのMyersの"ソフトウェア・テストの
技法"
 Myers以前からテストデータ選定の考え方はあった
• 1967年のElmendorfの論文には、ソフトウェアの機能のバリエー
ションを変数とその状態で定義し、状態として正常値、最大値、最
小値、それらを越える値を含める考え方が書かれている

原因結果グラフ
 外部仕様を、原因(入力条件)と結果(出力や状態)の
論理関係、および原因間の関係(制約条件)を示すグ
ラフで表現し、それにもとづいてテストケースを作成
<歴史>
 Myersの"ソフトウェア・テストの技法"(1979年)で紹介され
たことにより広く知られるようになった
 技法を考案したのはElmendorf(1970年頃)
• スイッチング回路の故障点の発見のための手法を元に、制約条件
の考え方を追加してソフトウェアの機能を記述できるようにした
• 原因結果グラフからテストケースを作成するツールTELDAP(TEst
Library Design Automation Program)を開発。ハードウェアの論
理回路のテストパターン作成ツールを元に作成

デシジョンテーブルテスト
 プログラムの仕様を条件部とアクション部からなるデ
シジョンテーブルに整理してテストケースを作成
<歴史>
 1958年：システム設計の道具としてGeneral Electric(GE)
社やSutherland社でデシジョンテーブルを考案
 1960年：GE社はデシジョンテーブルから直接ソースコード
を生成するプログラム言語TABSOLを開発
 1965年：RCA社のScheffがテスト設計にデシジョンテーブ
ルを用いた論文を発表
• 条件部にテストカテゴリとパラメタを、アクション部に結果とテストア
クションを整理
• 縦の列(ルール)をテストケースとして自動テストツールへ入力
 1975年：Goodenough&Gerhartはテスト理論の論文でプロ
グラム構造に基づくテストをデシジョンテーブルで設計する
方法(Condition table method <条件表法>)を提案

直交表/Pairwiseテスト
 任意の二つの因子間で組み合わせが網羅されるよ
うにテストケースを作成
(直交表やpair生成ツールを使用)
<歴史>
 実験計画法は1920年代に英国のFisherが農業実験の合
理化のために開発した手法。これをもとに田口玄一博士が
品質工学(タグチメソッド)を開発
 テストへの直交表の適用は、1983年に富士通で開始、同
時期に米国でもMandlがAdaコンパイラのテストに適用
 米国で活用されるようになったのは、AT&T社(Bell Labs,
Bellcore)の成果が発表された1990年代半ばから。
• 1992年に直交表によるテスト設計ツールOATSを開発
• 1994年に制約条件を考慮した組み合わせ表ツールCATSを開発
• 1994年に逐次的な手法によるPairwise生成ツールAETG を商用化

組み合わせテスト
(1957: Decision table)
～1967: Equivalence partitioning,
Boundary value analysis
1970: Cause Effect Graph
[Elmendorf]
(1983～)1985: Orthogonal Latin Squares
[R. Mandl]
(1983～)1984: 直交表/組合せ表
[佐藤,下川(富士通)]
1987: ATAF
[辰巳(富士通)]
(198x～)1992: OATS
[Brownlie, Prowse, Phadke]
(1990～)1994: CATS
[Sherwood]
(1992～)1994: AETG
[Cohen, et. al]
1998: IPO
[Lei, Tai]
2000: Covering arrays
[Williams]
2000: CTE XL
[Daimler Chrystler]
(2000～)2004: PICT
[Microsoft]
2007: FireEye 2009:ACTS
(IPOG)[Lei, Kuhn]
AT&T社, Bellcore社
で開発
1988: Category-partition method
[Ostrand, Balcer]
1993: Classification-tree method
[Grochtmann, Grimm]
(1976: テスト要因分析)
[富士通]
(199x～)2004: 直交表(HAYST法)
[富士ゼロックス]
1980 1990 2000 20101950 1960 1970 ‘85 ‘95 ‘05
組み合わせ手法
入力条件分析手法

制御フローテスト (1/2)
 プログラムの制御の流れをフローグラフで表現し，基
準に従ってグラフを網羅するテストケースを作成
<歴史>
 グラフ理論の適用
• 1960年にソフトウェア開発(コンパイラ)へグラフ理論を適用(Karp)
• 1963年にテスト設計へ適用。フローチャートをグラフ化し、ブール
行列に変換後、分岐点に着目してテストを設計(MillerとMaloney)
• 1976年にMaCabeがグラフ理論を元にプログラムの複雑度を表す
サイクロマチック複雑度、基礎パステスト法を提案
 カバレッジの計測
• 1960年代前半には意図したルートが通過したかどうかの計測開始
• IBM社のPoughkeepsie地区でコードカバレッジ・ツールを開発
– [Warner,1964] : COBOLとFORTRANソースプログラムを対象にした
ハードウェアの命令語モニタについてのいちばん最初の解説書
– [Hirsh,1967] : ソフトウェアのステートメントカバレージとブランチカバ
レージアナライザについての初期の論文

制御フローテスト (2/2)
<歴史> (つづき)
 動的解析システム(カバレッジ計測ツール)
• 1970年代初めに各社で本格的な動的解析システムを開発
– TRW社のPACE(Product Assurance Confidence Evaluator) [Brown,1972]
– McDonnell Douglas社のPET(Program Evaluater and Tester) [Stucki,1972]
– General Research社のRXVP [Miller,1974] など
 カバレッジ基準
• TER(Test Effectiveness Ratio:テスト有効度) [Brown,1972]
– TERとして命令網羅、分岐網羅を定義
• C0, C1, C2, ・・・ [Miller,1975]
– 1975年時点では、
C0 : プログラマの直感、C1 : 命令網羅、C2 : 判定条件網羅、・・・
– 1977年頃に、
C0 : 命令網羅、C1 : 判定条件網羅、C1p : 判定条件/条件網羅、
C2 : C1基準+ループ網羅、・・・

データフローテスト
 プログラムの制御フローを元に、変数の定義、変数
の使用の関係に着目してパスを選択することにより
テストケースを作成
<歴史>
 1960年後半、コンパイラ分野でプログラム最適化技術とし
てデータフロー解析の研究が進められた(IBM社のAllenら)
 1974年の米国コロラド大学のOsterweilとFosdickのデータ
フローテストの論文がテスト技術としては最初と思われる
 その後、データフローテスト基準の提案や制御フローテスト
も含めた構造テストの基準間の包含関係の研究が進めら
れている(RappsとWeyuker,1982 など)

状態遷移テスト
 プログラムの仕様を状態遷移図や状態遷移表を使っ
て整理し、それにもとづいてテストケースを作成
<歴史>
 状態遷移図や状態遷移表は、元来は有限オートマトン（有
限状態機械:FSM）の仕様を記述するためのもの
• デジタル回路の設計ソフトウェア、コンパイラのための字句解析(言
語理論)、通信プロトコルのような有限状態をとるシステムのチェッ
クをするソフトウェアなどの分野に用いられている計算モデル
 1956年のMooreの論文"Gedanken-experiments on
sequential machines"(順序機械の思考実験)がFSMベー
スのテスト生成の研究の先駆け
 1978年にChowが状態遷移テストにおけるカバレッジ基準
"n-switch cover"を提案

内容
日本の品質・テスト技術の歴史
 まとめ

日本の品質・テスト技術の歴史 (1/3)
 1958年テストに関する初期の文献
 藤原, "大型電子計算機 IBM 704をプログラムテストして," 1958
• 気象庁の数値予報のプログラムのテストをしたときの状況の報告
 1964年プログラムの検査に関する議論
 情報処理学会, 「情報処理」ソフトウェア特集, 1964
• 仕様を決める段階からその検査をやる組織というものが加わって、最終製品につい
てつくった側とは独立に、いろいろなテスト・プログラムをかけて検査するというよう
なことをやっていかなければいけないんじゃないかと思います。
• 検査部門というのは工程の状況を把握するための情報をとる感覚器官。それを工
程に正しくフィードバックして初めて工程をよい状態に維持できるし、ときには改善も
可能になるんだというような解釈が、近代的品質管理における検査の職能である。
 1969年日立製作所でソフトウェア工場を開設
 工場制度におけるソフトウェアの検査機能を確立
 1971年、富士通も出荷前のソフトウェア製品検査を制度化

 1972年ソフトウェアの検査の考え方
 菅野, “ソフトウェア検査の考え方,” 1972
• われわれは、過去数年間ソフトウェア検査の確立に努力
してきた。当初ソフトウェアにおいては、検査という語は
存在していなかった。単に言葉がなかったばかりではな
く、検査という行為もそれまではなかったといってよかろ
う。このような周辺事情のなかで、ソフトウェアは製品で
あるという認識のもとに、近代的ソフトウェア・エンジニア
リング確立の一つとして、現在まで検査技術の設定に努
力し、一応軌道に乗った様相で、ソフトウェア検査業務を
遂行している現状である。
 1974年検査技術の開発
 坂田, "ソフトウェアの生産管理における予測技
法の定式化," 電子通信学会, 1974
• 静的な予測および故障率推移モデル
成長曲線やゴンペルツ曲線などを使った品質予測手法
• 動的な予測:先取評価手法
先取り評価手法(QP:Quaity Prove)(探針と呼ばれている)

 1980年～テスト技法の研究開発
 1980年 AGENT(Automated GENeration system for Test cases)、日立
• 原因結果グラフからテストケースを生成するツールAGENTの開発
 1984年 AGENT機能図式、日立
• 機能仕様の動的部分を状態遷移で、静的部分をデシジョンテーブルや原因結果グ
ラフで表現し、これらを組み合わせてテストケースを生成する機能仕様表現形式
 1984年ソフトウェアテストへの直交表の適用、富士通
• 直交表を応用してテストケースを生成する方法とツールの開発
 1988年 CFD(Case Flow Diagram)、NEC ※現在はCause Flow Diagramと呼んでいる
• 原因流れ図で仕様を整理し、デシジョンテーブルを作成する技法
 1991年 Japan's Software Factories
 日本のソフトウェア開発が米国の驚異の的に
• Cusumano, "Japan's Software Factories: A Challenge to U.S. Management",
1991 (日本のソフトウェア戦略-アメリカ式経営への挑戦, 三田出版会, 1993)
• MITのCusumano教授の日立、東芝、NEC、富士通の調査報告

内容
世界のテスト技術の研究最前線
 まとめ

世界のテスト技術の研究最前線
 A. Bertolino, "Software Testing Research:
Achievements, Challenges, Dreams," 2007
• 2007年ソフトウェア工学国際会議(29th ICSE) Future
of Software Engineering trackの論文
• Bertolinoはソフトウェアエンジニアリング基礎知識体系
(SWEBOK)の5章 Testingの執筆者
 Achievements : 達成できたテーマ
 Dreams : 4つの夢
 Challenges : 夢の実現に向けた研究課題

テスト技術の6つの側面
 テストは
 実行サンプルの観測と結果の判定
 テスト技術を特徴づける6つの側面
 WHY : テストの目的
バグの検出、製品の出荷判断、
UIのユーザビリティ評価、・・・
 HOW : テストの選択方法
アドホック、ランダム、系統的な
方法
 HOW MUCH : テストの量
テスト充分性、網羅度合い、
信頼性尺度
 WHAT : テスト対象
ユニット、コンポーネント／サブ
システム、システム(全体)
 WHERE : 観測場所
社内(in house)、疑似環境、
実環境
 WHEN : 実施時期
ライフサイクルのどこで

(C) K. Tatsumi 2010
ソフトウェアテストの研究ロードマップ
Software testing research roadmap
テストベースド・
モデリング
100% 自動テスト
有効性最大化
テスト工学
普遍的テスト理論
テスト
プロセス
信頼性
テスト
WHY How How much What Where When
プロトコル
テスト
テスト基準
テスト基準の比較
コ
ン
ポ
ー
ネ
ン
ト
ベ
ー
ス
ド
・テ
ス
ト
オ
ブ
ジ
ェ
ク
ト
指
向
テ
ス
ト
テスター教育
テストパターン
進化の制御
ユーザ人口や資源の活用テストのコストの理解
テスト入力の生成
オンライン・テスト
テスト
結果判定
モデルベースド・テスト
アンチ・モデルベースド・テスト
テストの仮説
の明示
テスト有効性
実証体系化
合成テスト
ドメイン固有
テストアプローチ
Achievements Challenges Dreams
テストの目的テストの選択方法テストの量テスト対象観測場所実施時期
[出典] A. Bertolino, “Software Testing Research: Achievements, Challenges, Dreams,” FOSE’07, p.85-103, 2007, Figure 1

達成テーマ (1/2)
 テストプロセス (Testing process)
 テスト技術やツールの開発プロセスへの組み込み
 Vモデルなどのプロセス、新モデル(Agile/TDD)
 テスト基準 (Test criteria)
 テスト基準を利用した系統的なテストケース選択
 テスト基準の比較 (Comparison among test criteria)
 テスト技法の評価、テスト基準の階層化
 オブジェクト指向テスト (Object-oriented testing)
 OO開発に伴う新しいリスクや問題への対応

達成テーマ (2/2)
 コンポーネントベースド・テスト (Component-based testing)
 コンポーネントを使って組み立てたシステムのテスト
 テストしやすくするために、適切な情報、あるいはテスト
ケース自体(Built-in Testing)をコンポーネントへパッケージ
 独立にテストされたコンポーネントのテスト結果から、組み
立てたシステムの特性を推定(継続課題)
 プロトコル・テスト (Protocol testing)
 プロトコルの仕様と実装の適合性検証
 信頼性テスト (Reliability testing)
 運用プロファイルによるテストで頻度の多い障害を除去
 信頼性モデルに基づくテスト

夢
(1) 普遍的テスト理論 (Universal test theory)
 テスト技術の支援と育成に役立つ包括的な理論
 各々のテスト技法の強み弱みが理解でき、適切な技法が選択できる指
針のフレームワーク
(2) テストベースド・モデリング (Test-based modeling)
 モデルからテストを設計するのではなく効果的にテストできるモデルを
開発者が考慮(テスト容易化設計のように)
(3) 100%自動テスト (100% automatic testing)
 テスト入力の生成手法、テストプロセス自動化手順
 ソフトウェアの組み込み、テスト環境構築、テストケース生成・実行・レ
ポートを自動的に行う統合テスト環境
(4) 有効性最大化テスト工学 (Efficacy-maximized test engineering)
 高品質ソフトウェアの開発のための実践的テスト手法、ツール、プロセ
スに関する費用対効果の高い工学技術

夢: (1)普遍的テスト理論
 テスト技術の支援と育成に役立つ包括的な理論
 各々のテスト技法の強み弱みが理解でき、適切な技法が
選択できる指針のフレームワーク
<研究課題>
 テストの仮説の明確化 (Explicit test hypotheses)
• 各テスト技法が前提とする仮定(ex. こういうプログラムのときに、こうい
うバグを検出)を明らかにすることにより、テストの目的を明確化
 テスト有効性 (Test effectiveness)
• 各種テスト基準の有効性を評価し、テスト技法の組み合わせを支援
 合成テスト (Compositional testing)
• 個々のテスト結果の再利用、コンポーネントベースの信頼性理論
 実証体系化 (Empirical body of evidence)
• テスト理論の構築と進化の基礎となる実証データの体系

夢: (2)テストベースド・モデリング
 モデルからテストを設計するのではなく効果的にテストでき
るモデルを開発者が考慮(テスト容易化設計のように)
<研究課題>
 モデルベースド・テスト (Model-based testing)
• 異なるモデル(遷移、事前・事後条件、シナリオベース)の組み合わせ
• ソフトウェア・プロセスへのMBTプラクティスの統合(実行可能なテスト
の生成、要件からテストへのトレーサビリティの維持)
 アンチ・モデルベースド・テスト (Anti-model-based testing)
• モデルがない、あるいはアクセスできない場合(商用ソフト-COTS-、レ
ガシーコンポなど)はプログラムの実行結果から帰納的にモデル化
 テスト結果判定 (Test oracles)
• まだ人の目に頼るところが多く、複雑度や重要性が増大している今日
では不十分。テスト自動化の障壁

夢: (3)100%自動テスト
 ソフトウェアの量、複雑性の増加に対して品質を維持する
手段として自動化が重要
 テスト入力の生成手法、テストプロセス自動化手順
 ソフトウェアの組み込み、テスト環境構築、テストケース生
成・実行・レポートを自動的に行う統合テスト環境
<研究課題>
 テスト入力の生成 (Test input generation)
• モデルベースドテスト生成、ランダムテスト生成、search-based test
generation(メタヒューリスティックな探索手法-遺伝アルゴリズムなど)
 ドメイン固有テストアプローチ (Domain-specific test approaches)
• 特定ドメイン(DB、GUI、Webアプリ、航空、通信)のテスト技法は研究さ
れているが、ドメイン知識を利用する方法論の研究は少ない
 オンライン・テスト (On-line testing)
• 動的解析や自己テスト手法を用いて、実運用でのシステムの振る舞い
をモニターしてテストする技術

夢: (4)有効性最大化テスト工学
 高品質ソフトウェアの開発のための実践的テスト手法、
ツール、プロセスに関する費用対効果の高い工学技術
 主要な障壁はシステムの複雑度の増大
<研究課題>
 進化の制御 (Controlling evolution)
• 稼働後も動的に進化するソフトウェアの品質の維持。進化の中での回
帰テストの意義の理解、および回帰テスト選択手法の修正と拡張
 利用人口・資源の活用 (Leveraging user population and resources)
• 動的にフィールドから収集したデータを使って社内の品質保証活動を
拡大(ex. 多数のユーザのコンフィグレーション情報をテストに活用)
 テストパターン (Testing patterns)
 テストのコストの理解 (Understanding the costs of testing)
• テストの予算の効果的な使用、各テスト技法の費用対効果の見積もり
 テスター教育 (Education of software testers)

夢: 横断的な課題
<研究課題>
 最新開発パラダイムにおけるテスト手法
(Testing within the emerging development paradigm)
• サービス指向コンピューティングにおけるサービス指向アプリケーショ
ンのテスト
• サービスのテストではオンライン・テストが特に重要(アプリケーションの
振る舞いを観察する唯一の方法は稼働中のモニタリング)
 機能特性と非機能特性の整合性テスト
(Coherent testing of functional and extra-functional properties)
• 従来の機能テストには時 (いつ、時間) や、リソース使用量やワークロードの考
慮がない
• モデルベースのアプローチの研究が進んでいるが、非機能特性の制約を考慮
できるモデルへの拡張が必要

(C) K. Tatsumi 2010
まとめ : あらためて『温故知新』
[出典] 論語百選 http://shamada.net/weblog/rongo/ から引用
 温故而知新
• 故(ふる)きを温(たず)ねて新しきを知る、以(もつ)て師と為るべし。
• 「古典や歴史を学んで、そこから現代に通用する新しい意義を見出すことがで
きれば、立派な指導者になれるだろう」
 學而時習之
• 学びて時にこれを習う、亦た説（よろこ）ばしからずや。朋遠方より来たる有り、
亦楽しからずや。人知らずして慍（うら）みず、亦君子ならずや。
• 「学んでは適当な時期におさらいをする、いかにも心嬉しいことだ。友が遠い所
からからも尋ねて来る、いかにも楽しいことだ。他人が理解してくれなくても気
することはない、凡人にはできないことだから」
 學而不思則罔
• 学びて思わざれば則(すなわ)ち罔(くら)く、思いて学ばざれば則ち殆(あやう)し。
• 「学ぶだけで、じっくりと自分の頭で思索してみなければ、真に活きた学問とは
ならない。逆に、自分の頭で思い巡らすだけで、博く学ぶことをしなければ、危
なっかしくて頼りにならない」
 誨女知之乎
• 女(なんじ)に之(これ)を知るを誨(おし)えんか。之を知るを之を知ると為(な)し、
知らざるを知らずと為す。是れ知るなり。
• 「お前に知るとはどういうことか教えようか。知っていることは知っているとし、
知らないことは知らないとはっきりさせる。これが本当に知るということだ」

(C) K. Tatsumi 2010
の力で歴史をつくろう
ご清聴ありがとうございました

ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬 クロージングセッション) 20101219

More Related Content

What's hot

Viewers also liked

Similar to ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬 クロージングセッション) 20101219

More from Keizo Tatsumi