ソフトウェアテスト・ヒストリーの学び方 (wacate 2010冬...

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

(C) K. Tatsumi 2010 (C) K. Tatsumi 2010 1

ソフトウェアテスト・ヒストリーの学び方

辰巳敬三

2010年12月19日

～タメにならなければ学ばない。

面白くなければ学ぶ資格がない。

WACATE 2010冬

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

(C) K. Tatsumi 2010 2

自己紹介 : マイヒストリー 1

97

5

19

90

20

00

19

80

19

85

20

10

19

95

20

05

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

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

(C) K. Tatsumi 2010 3

内容

ソフトウェアテスト前史

コンピュータとソフトウェア技術の歴史

テストの考え方の進化

テスト技法の歴史

日本の品質・テスト技術の歴史

世界のテスト技術の研究最前線

まとめ

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING



コンピュータの原型

(1/2)

Charles Babbage(英国)の「解析機関」

• 1837年に設計を開始 (完成には至らず)

• 入力（プログラムとデータ）はパンチカード

• 出力はプリンター、曲線プロッター、ベル

最初のプログラマー

Ada Byron, Lady Lovelace

• 解析機関のプログラムを作成(1843年)

– Babbageの講演記録の翻訳の注釈の中に記述

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING



最初のテスターは ?

(2/2)

Ada Loverace女史はプログラマの第1号として、19世紀、

Charles Babbageの壮大にして未完成に終わったコン

ピュータのプログラム作成にたずさわったが、「あと1週間

あれば大丈夫です、バベッジ博士。それですべて終わり

ます」と何度も言っていたにちがいない。幸いにもハード

ウェアが完成しなかったため、Loverace女史は机上デ

バッグに巻き込まれずにすんだ。

(ボーリス・バイザー,「ソフトウェアテスト技法」,1994,日経BP)

Boris Beizerによると・・・

• 『テストやデバッグの最初の議論はAdaのメモに遡る』

• Software System Testing and Quality Assurance [Beizer,1984] では

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


内容


コンピュータとソフトウェア技術の歴史テストの考え方の進化




まとめ

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


コンピュータとソフトウェア技術の歴史

別紙の歴史年表参照 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

・・・・・・△ ▲ ▲ ▲ GQM(Basili) (ｿﾌﾄｳｪｱ製品の品質) (ｿﾌﾄｳｪｱ製品の評価) (ｿﾌﾄｳｪｱ測定ﾌﾟﾛｾｽ)

Lines of Code(LOC) Token count(Halstead) Function Point(Albrecht) COCOMO(Boehm) ▲

Putnamモデル IEEE Std 1061

▲ ▲信頼度成長(Coutinho) ▲ (Software Quality Metrics Methodology)

信頼性モデル(Jelinski&Moranda) 非同次ポアソン過程(Goel&Okumoto)

▲ ▲

サイクロマチック複雑度(McCabe) ソフトウェアサイエンス(Halstead)

◆

Software Metrics(Gilb)

▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲

Program Test Methods Symposium 1st Workshop 2nd 3rd

▲ ▲ on Software Testing Workshop Workshop Testing, Verification, International Symposium on Software Testing and Analysis (ISSTA) ▲

Courant Symposium IEEE Symposium on Computer Software Reliability and Analysis (TAV) ▲ ▲ ▲ ICST on Debugging Techniques ▲ ROSATEA ROSATEA

in Large Systems International Conference on Reliable Software (Role of Software Architecture in Testing and Analysis)

▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲

(デシジョンテーブル考案) テストツールへの原因結果グラフデシジョンテーブルテスト同値分割/限界値分析直交表直交表 Pairwise

デシジョンテーブルの利用 ▲ ▲ (富士通) (AT&T)

▲ (同値分割/限界値分析の考え方) ▲ ドメインテスト ▲

Gedanken-experiments on sequential machines (Elmendorf) 状態遷移テストの ▲ Component-based Software Testing

(順序機械の思考実験)(Moore) カバレッジ(n-switch) Object-oriented Testing ▲

有限状態機械(FSM)ベースの ▲ ▲ ▲ ▲ Architecture-based Testing

テスト生成の研究の先駆けパス解析カバレッジ(TER)カバレッジ(Cx) データフローテスト

▲

基礎パステスト(McCabe) ▲

▲ ▲ ▲ Operational profiles(Musa)

▲ 変異テスト IEEE 829 IEEE 1008 (運用プロファイル)

インスペクション (Test Documentation) (Unit Testing)

▲ ▲

FIPS 101 IEEE 1012 ▲ ▲

(Lifecycle V,V&T) (V&V Plans) SW-TMM TPI

▲ ▲ ▲ ▲ ▲ ▲ ▲

Checking a Large Routine (Turing) Digital Computer Programming Program Testing & Validating Program Test Methods The Art of Software Testing Software Testing Techniques 2nd Ed. Testing Object-Oriented Systems

▲ (McRacken) (Gruenberger) (Hetzel) ▲ (Myers) ▲ (Beizer) (Binder)

Computing Machinery and Intelligence ▲ ▲ ▲ Software Reliability (Myers) Software Testing Techniques

(Turing) Review of Evaluation of the Functional Testing Program Style,・・・, Debugging, and Testing (Beizer)

"Digital Computer Programming" of Control Programs (Elmendorf) ▲ (Tassel) ▲

(Baker) Debugging Techniques in Large Systems Tutorial: Program Testing Techniques

(Rustin) ▲ (Miller)

Theory of Test Data Selection (Goodenough & Gerhart)

★ (電子協・ソフトウェアエンジニアリング専門委員会) ▲ ★ ★

日本電子工業振興協会発足ソフトウェアエンジニアリングに関する調査(第1回) IPA Σ プロジェクト IPA SEC

★ ★ ▲ ▲

情報処理学会設立ソフトウェア工学研究会設置 ICSE in Tokyo COMPSAC in Tokyo

★ ● ● ● ●ソフトウェア製品生産管理 ● ● ● ●

会誌「情報処理」創刊ソフトウェア特集号ソフトウェア・エンジニアリングソフトウェアツールソフトウェア工学の現状と動向ソフトウェアマネジメントソフトウェアプロセスソフトウェア管理技術

■ ■プログラムの検査(岸田)

ソフトウェアの検査の考え方(菅野) ■ソフトウェアのテスト技法(中所)

★ ▲SPCシンポジウム(第1回)

ソフトウェア生産管理(SPC)研究委員会設立

◆ ◆ ◆ ◆

ソフトウェア・エンジニアリング(菅野) ソフトウェアの検査と品質保証(石井) ソフトウェア品質保証の考え方と実際(保田) ソフトウェア品質知識体系(SQuBOK)

◆

ソフトウェア品質管理実例集(森口)▲ ▲

ソフトウエアの品質管理と生産性ソフトウエアの品質管理特集▲ ★

ソフトウェアシンポジウム(第1回) ソフトウェア技術者協会(SEA)設立(ソフトウェア産業振興協会) ★ ▲

ソフトウェアテストソフトウェアテストシンポジウム(第1回)

★ ■ ● ● 技術者交流会(TEF)発足 (JaSST) ▲

「ビジネスコミュニケーション」誌創刊プログラム・テスト(渋谷・藤原) オンライン・テストの手法実践的ソフトウェア・エンジニアリング

★ ■ ■ ■

「bit」誌創刊ソフトウェア・エンジニアリングへの道ソフトウェア・テスティングソフトウェアのテスト技法

(宮本) (岸田) (玉井)

◆ ◆

ソフトウェア・エンジニアリング-現状と展望(宮本) ソフトウェアのテスト技法(玉井)

★ ● ● ●

ソフトウェア工場(日立)設立日立評論日立評論日立評論(新しいソフトウェア生産技術特集)(ソフトウェア生産技術特集) (ソフトウェア生産技術特集)

● ◆

雑誌FUJITSU 富士通におけるソフトウェア品質保証の実際(久保)

(信頼性特集号) ● ●

東芝レビュー NEC技報

(ソフトウェア生産技術特集) (ソフトウェア生産技術特集)◆ ◆日本のソフトウェア戦略(クスマノ)

Japan's Software Factories (Cusumano)◆ ◆ ◆ ◆

プログラム・テスト法 (Hetzel) ソフトウェア・テストの技法 (Myers) ソフトウェアテスト技法(Beizer) 実践的プログラムテスト入門(Beizer)

◆実践プログラミング技法(Tassel) ◆

◆ソフトウェアの信頼性(Myers) 基礎から学ぶソフトウェアテスト(Kaner)

▲ ▲ ▲ ▲

AGENT<日立> 直交表<富士通> CFD技法<NEC> HAYST法<富士ゼロックス>

AGENT-機能図式<日立>

(*1) 「過去の情報政策と情報産業に関する調査・分析について」調査報告書, 独立行政法人情報処理推進機構, 2004年3月

(*2) The Future Engineering of Software: A Management Perspective (Basili, Musa), 1991 © K.Tatsumi, 2010(*3) A View of 20th and 21st Century Software Engineering (Boehm), 2006(*4) The Growth of Software Testing (Gelperin & Hetzel), 1988

1965 19701950 1955 1960 20102000 20051975 1980 1985 1990 1995

ハードウェア

ソフトウェア

開発技法/開発方法論

マネジメント/プロセス

コンピュータの歴史とソフトウェアテスト・品質技術の歴史

コンピュータ時代の幕開け

「計算機」パラダイムの時代

「日の丸コンピュータ」の開発促進期

分散処理ネットワークの普及期

IBMを中心とする市場開拓期

ミニコンと汎用機ソフト市場の成長期

ﾊﾟｿｺﾝ, ﾜｰｸｽﾃｰｼｮﾝの誕生・普及期

オープンシステムへの転換期

「情報処理」パラダイムの時代

インターネットの急成長期

社会インフラとしてのIT浸透期

「ネットワーク」パラダイムの時代

ソフトウェア

ハードウェア

世界(米国)

日本

稼働システム

稼働システム

ITパラダイムの変遷 (*1)

コンピ

ュータの歴史

ソフトウ

ェア技術の歴史

品質モデル、品質測定

テスト、レビュー技術

会議・シンポジウム

品質特性・品質モデル

プログラム規模コスト見積もり

ソフトウェア信頼性モデル

プログラムの複雑度

クラウド・コンピューティングの時代？

ソフトウェア・マネジメントの観点(*2)

ソフトウェア・エンジニアリングの進化(*3)

品質の時代機能の時代スケジュールの時代コストの時代

<反> 並行プロセス対順次プロセス<反> ソフトウェア工芸(Crafting) <合と反> 形式化とウォータフォールプロセス <合> 生産性と拡張性<正> ハードウェア工学的なソフトウェア工学 <反、部分的に合> 俊敏性と価値

予防指向論証指向破壊指向評価指向デバッグ指向

コミュニティ、書籍・雑誌

企業の発刊雑誌

テスト関連翻訳書籍

日本考案のテスト技法

● 特集■ 論文、雑誌記事◆ 書籍★ 組織発足など

情報処理学会

電子協

日本科学技術連盟

日本品質管理学会

ソフトウェア技術者協会(SEA)

日本規格協会

ソフトウェアテスト技術者交流会(TEF)

電電公社関連

共立出版

日本

シンポジウム

テスト技法

V&V、テストプロセス

書籍/文献

テストの考え方の進化 (*4)

世界(米国)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


[出典] Basili, Musa, “The Future Engineering of Software: A Management Perspective,“ 1991

1960年代: 機能の時代

ITが社会に入り始めた

社会的ニーズに応えられる機能の開発が主要課題

1970年代: スケジュールの時代ソフトウェア危機(NATO会議,1968年)

計画期間内にソフトウェア開発を完了させることが主要課題

工程を明確化したライフサイクルモデルが紹介され始めた

ex. Royce waterfall model、品質モデル

1950 1980 1990 1960 1970 2000 2010

スケジュールの時代コストの時代品質の時代機能の時代

ソフトウェア・マネジメントの観点 (1/2)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


1980年代: コストの時代

ハードウェアコストの継続的低減、パソコンの出現

ソフトウェアの価格の高さに目が向き始め、コスト/生産性が主要課題

各種のコストモデルが提案され、適用され始めた ex. Function Point、Putnamモデル、COCOMO

1990年代: 品質の時代

ソフトウェアに対する社会の依存度の増大

マスマーケットでの利用者が増え、ソフトウェアの故障や使いにくさが深刻な事態を招くことが広く認識されはじめる

1950 1980 1990 1960 1970 2000 2010

スケジュールの時代コストの時代品質の時代機能の時代

ソフトウェア・マネジメントの観点 (2/2)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


ソフトウェア工学の進化

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のプレゼンテーションスライドから引用

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


内容


ソフトウェア技術の発展過程

テストの考え方の進化テスト技法の歴史



まとめ

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING



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年～ )

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


1. デバッグ指向の時代 (～1956年)

デバッグとテストが区別されていなかった時代

ソフトウェアはハードウェアの信頼性の一部

『難しいのは間違いを検出することではなく、

異常原因の究明である』

(Gill <EDSAC開発メンバー>, 1951)

プログラムを書いたらチェックする(check it out)程度の認識

checkout, debugging, testingの定義はまだ不明確

McCracken, "Digital Computer Programming,“

1957 (最も初期のプログラミング教科書)

• ”Program Checkout”の章でデバッグやテストを説明

評価指向

論証指向破壊指向

デバッグ指向予防指向

1950 1980 1990 1960 1970 2000 2010

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


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 1990 1960 1970 2000 2010

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


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 1990 1960 1970 2000 2010

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


3. 破壊指向の時代 (1979年～1982年)

テストとは、エラーをみつけるつもりでプログラムを実行する過程（テストの成功とはエラーを見つけること）

Myers, "The Art of Software Testing," 1979

テストでは、経済学的・心理学的な観点が大切

• 投資対効果の最大化を目的とすべき

(限られたテストで検出できるエラー数を最大に)

• 『完全なテストは不可能であるから、いかなるプログ

ラムのテストも不完全にならざるを得ない。だから、

作戦としては、この不完全さをできる限り減らすこと

であることが明らかである。』

⇒ これが、きちんとテスト設計することの意味であり、

テスト設計技法の目的

1950 1980 1990 1960 1970 2000 2010


破壊指向

予防指向

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


4. 評価指向の時代 (1983年～1987年)

ソフトウェアのライフサイクルを通じた評価活動の中にテストが位置付けられた時代 FIPS 101 (米国標準局(NBS)規格), 1983

"Guideline for Lifecycle Validation, Verification, and Testing of Computer Software"

• ライフサイクルの中で、解析、レビュー、テストの活動

を統合する方法論、各フェーズのVV&T技法

⇒ ソフトウェアの品質は単一の技法で保証できる

ものではない。個々のプロジェクトで吟味して

選んだ技法群を使うことにより品質のよい

ソフトウェアの開発が可能になる

1950 1980 1990 1960 1970 2000 2010


破壊指向

予防指向

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


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 1990 1960 1970 2000 2010

論証指向デバッグ指向評価

指向

破壊

指向予防指向

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


Beizerのテスト道

テスト担当者の精神面による区分

• フェーズ0 : テストとデバグには何の差もない。デバグ以外

にはテストには特別な目的はない。

• フェーズ1 : テストの目的は、ソフトウェアが動くことを示す

ことである。

• フェーズ2 : テストの目的は、ソフトウェアが動かないという

ことを示すことにある。

• フェーズ3 : テストの目的は、何かを証明することではなく、

プログラムが動かないことによって発生する

危険性をある許容範囲にまで減らすことである。

• フェーズ4 : テストは行動ではない。テストをしないで品質の

高いソフトウェアを作るための精神的な訓練である。

[出典] B. Beizer, "Software Testing Techniques,2nd Ed.," 1990

(電通大・西先生の命名)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


内容




テスト技法の歴史日本の品質・テスト技術の歴史


まとめ

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


テスト技法の歴史 : 胎動期

テスト技法の多くが確立する1970年以前の状況

1960年代前半はテストに関する論文は少ない

テスト文献数(累積)

1969年-57件、1973年-200件、1977年-400件以上

内容的にもテストの手順やテストの自動化に関するもので、テスト技法に関する内容は見受けられない。

1960年代後半

IBMのOS/360の開発プロジェクト (Brooksの「人月の神話」)

• 1966年リリース、1967年に本格的マルチタスクOSのMVTをリリース

かなりのテスト作業が行われ、テストプロセス、テスト技法、テストマネジメントに関するノウハウが蓄積された筈

(1/2)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


テスト技法の歴史 : 胎動期

IBM社のElmendorfのテスト制御プロセス

Elmendorf, "Controlling the functional testing

of an operating system," 1969

• Elmendorfは1965年からOS/360の

ソフトウェアテストを担当

• この論文から、きちんとしたテストプロセス

が実践されていたことが伺える。

• このプロセスによりテストを自由放任から

統率へ、芸術から科学的なアプローチに

変えていくことができると言っている。

予防指向プロセス, Wモデルの先駆け

(2/2)

設計

仕様化

実装

テスト

プログラム目標

テスト目標

プログラム仕様書

調査

識別

評価

レビュー

監視

機能バリエーション

テスト計画

テスト仕様書

テスト資材

プログラム

テスト結果

【開発工程】【テストプロセス】

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


同値分割、限界値分析

入力データを「同じ出力結果が得られるグループ」に分割して各グループ(同値クラス)の代表値、および同値クラスの端に着目してテストケースを作成

<歴史>

同値分割、限界値分析という名称でテスト技法として確立したのは、1979年のIBMのMyersの"ソフトウェア・テストの技法"

Myers以前からテストデータ選定の考え方はあった

• 1967年のElmendorfの論文には、ソフトウェアの機能のバリエーションを変数とその状態で定義し、状態として正常値、最大値、最小値、それらを越える値を含める考え方が書かれている

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


原因結果グラフ

外部仕様を、原因(入力条件)と結果(出力や状態)の論理関係、および原因間の関係(制約条件)を示すグラフで表現し、それにもとづいてテストケースを作成

<歴史>

Myersの"ソフトウェア・テストの技法"(1979年)で紹介されたことにより広く知られるようになった

技法を考案したのはElmendorf(1970年頃)

• スイッチング回路の故障点の発見のための手法を元に、制約条件の考え方を追加してソフトウェアの機能を記述できるようにした

• 原因結果グラフからテストケースを作成するツールTELDAP(TEst Library Design Automation Program)を開発。ハードウェアの論理回路のテストパターン作成ツールを元に作成

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


デシジョンテーブルテスト

プログラムの仕様を条件部とアクション部からなるデシジョンテーブルに整理してテストケースを作成

<歴史> 1958年：システム設計の道具としてGeneral Electric(GE)

社やSutherland社でデシジョンテーブルを考案 1960年：GE社はデシジョンテーブルから直接ソースコード

を生成するプログラム言語TABSOLを開発 1965年：RCA社のScheffがテスト設計にデシジョンテーブ

ルを用いた論文を発表 • 条件部にテストカテゴリとパラメタを、アクション部に結果とテストア

クションを整理

• 縦の列(ルール)をテストケースとして自動テストツールへ入力

1975年：Goodenough&Gerhartはテスト理論の論文でプログラム構造に基づくテストをデシジョンテーブルで設計する方法(Condition table method <条件表法>)を提案

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


直交表/Pairwiseテスト

任意の二つの因子間で組み合わせが網羅されるようにテストケースを作成

(直交表やpair生成ツールを使用) <歴史>

実験計画法は1920年代に英国のFisherが農業実験の合理化のために開発した手法。これをもとに田口玄一博士が品質工学(タグチメソッド)を開発

テストへの直交表の適用は、1983年に富士通で開始、同時期に米国でもMandlがAdaコンパイラのテストに適用

米国で活用されるようになったのは、AT&T社(Bell Labs, Bellcore)の成果が発表された1990年代半ばから。

• 1992年に直交表によるテスト設計ツールOATSを開発 • 1994年に制約条件を考慮した組み合わせ表ツールCATSを開発 • 1994年に逐次的な手法によるPairwise生成ツールAETG を商用化

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


組み合わせテスト

(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 2010 1950 1960 1970 ‘85 ‘95 ‘05

組み合わせ手法

入力条件分析手法

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


制御フローテスト (1/2)

プログラムの制御の流れをフローグラフで表現し，基準に従ってグラフを網羅するテストケースを作成

<歴史> グラフ理論の適用

• 1960年にソフトウェア開発(コンパイラ)へグラフ理論を適用(Karp)

• 1963年にテスト設計へ適用。フローチャートをグラフ化し、ブール行列に変換後、分岐点に着目してテストを設計(MillerとMaloney)

• 1976年にMaCabeがグラフ理論を元にプログラムの複雑度を表すサイクロマチック複雑度、基礎パステスト法を提案

カバレッジの計測 • 1960年代前半には意図したルートが通過したかどうかの計測開始

• IBM社のPoughkeepsie地区でコードカバレッジ・ツールを開発 – [Warner,1964] : COBOLとFORTRANソースプログラムを対象にした

ハードウェアの命令語モニタについてのいちばん最初の解説書

– [Hirsh,1967] : ソフトウェアのステートメントカバレージとブランチカバレージアナライザについての初期の論文

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


制御フローテスト (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基準+ループ網羅、・・・

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


データフローテスト

プログラムの制御フローを元に、変数の定義、変数の使用の関係に着目してパスを選択することによりテストケースを作成

<歴史>

1960年後半、コンパイラ分野でプログラム最適化技術としてデータフロー解析の研究が進められた(IBM社のAllenら)

1974年の米国コロラド大学のOsterweilとFosdickのデータフローテストの論文がテスト技術としては最初と思われる

その後、データフローテスト基準の提案や制御フローテストも含めた構造テストの基準間の包含関係の研究が進められている(RappsとWeyuker,1982 など)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


状態遷移テスト

プログラムの仕様を状態遷移図や状態遷移表を使って整理し、それにもとづいてテストケースを作成

<歴史>

状態遷移図や状態遷移表は、元来は有限オートマトン（有限状態機械:FSM）の仕様を記述するためのもの

• デジタル回路の設計ソフトウェア、コンパイラのための字句解析(言語理論)、通信プロトコルのような有限状態をとるシステムのチェックをするソフトウェアなどの分野に用いられている計算モデル

1956年のMooreの論文"Gedanken-experiments on sequential machines"(順序機械の思考実験)がFSMベースのテスト生成の研究の先駆け

1978年にChowが状態遷移テストにおけるカバレッジ基準"n-switch cover"を提案

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


内容





日本の品質・テスト技術の歴史世界のテスト技術の研究最前線

まとめ

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


日本の品質・テスト技術の歴史 (1/3)

1958年テストに関する初期の文献藤原, "大型電子計算機 IBM 704をプログラムテストして," 1958

• 気象庁の数値予報のプログラムのテストをしたときの状況の報告

1964年プログラムの検査に関する議論情報処理学会, 「情報処理」ソフトウェア特集, 1964

• 仕様を決める段階からその検査をやる組織というものが加わって、最終製品についてつくった側とは独立に、いろいろなテスト・プログラムをかけて検査するというようなことをやっていかなければいけないんじゃないかと思います。

• 検査部門というのは工程の状況を把握するための情報をとる感覚器官。それを工程に正しくフィードバックして初めて工程をよい状態に維持できるし、ときには改善も可能になるんだというような解釈が、近代的品質管理における検査の職能である。

1969年日立製作所でソフトウェア工場を開設工場制度におけるソフトウェアの検査機能を確立

1971年、富士通も出荷前のソフトウェア製品検査を制度化

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING



1972年ソフトウェアの検査の考え方菅野, “ソフトウェア検査の考え方,” 1972

• われわれは、過去数年間ソフトウェア検査の確立に努力してきた。当初ソフトウェアにおいては、検査という語は存在していなかった。単に言葉がなかったばかりではなく、検査という行為もそれまではなかったといってよかろう。このような周辺事情のなかで、ソフトウェアは製品であるという認識のもとに、近代的ソフトウェア・エンジニアリング確立の一つとして、現在まで検査技術の設定に努力し、一応軌道に乗った様相で、ソフトウェア検査業務を遂行している現状である。

1974年検査技術の開発坂田, "ソフトウェアの生産管理における予測技

法の定式化," 電子通信学会, 1974 • 静的な予測および故障率推移モデル

成長曲線やゴンペルツ曲線などを使った品質予測手法

• 動的な予測:先取評価手法先取り評価手法(QP:Quaity Prove)(探針と呼ばれている)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING



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、富士通の調査報告

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


内容






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

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING



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 : 夢の実現に向けた研究課題

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


テスト技術の6つの側面

テストは

実行サンプルの観測と結果の判定

テスト技術を特徴づける6つの側面

WHY : テストの目的

バグの検出、製品の出荷判断、UIのユーザビリティ評価、・・・

HOW : テストの選択方法

アドホック、ランダム、系統的な方法

HOW MUCH : テストの量

テスト充分性、網羅度合い、信頼性尺度

WHAT : テスト対象

ユニット、コンポーネント／サブシステム、システム(全体)

WHERE : 観測場所

社内(in house)、疑似環境、実環境

WHEN : 実施時期

ライフサイクルのどこで

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

(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

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


達成テーマ (1/2)

テストプロセス (Testing process)

テスト技術やツールの開発プロセスへの組み込み

Vモデルなどのプロセス、新モデル(Agile/TDD)

テスト基準 (Test criteria)

テスト基準を利用した系統的なテストケース選択

テスト基準の比較 (Comparison among test criteria)

テスト技法の評価、テスト基準の階層化

オブジェクト指向テスト (Object-oriented testing)

OO開発に伴う新しいリスクや問題への対応

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


達成テーマ (2/2)

コンポーネントベースド・テスト (Component-based testing)

コンポーネントを使って組み立てたシステムのテスト

テストしやすくするために、適切な情報、あるいはテストケース自体(Built-in Testing)をコンポーネントへパッケージ

独立にテストされたコンポーネントのテスト結果から、組み立てたシステムの特性を推定(継続課題)

プロトコル・テスト (Protocol testing)

プロトコルの仕様と実装の適合性検証

信頼性テスト (Reliability testing)

運用プロファイルによるテストで頻度の多い障害を除去

信頼性モデルに基づくテスト

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


夢

(1) 普遍的テスト理論 (Universal test theory)

テスト技術の支援と育成に役立つ包括的な理論

各々のテスト技法の強み弱みが理解でき、適切な技法が選択できる指針のフレームワーク

(2) テストベースド・モデリング (Test-based modeling)

モデルからテストを設計するのではなく効果的にテストできるモデルを開発者が考慮(テスト容易化設計のように)

(3) 100%自動テスト (100% automatic testing)

テスト入力の生成手法、テストプロセス自動化手順

ソフトウェアの組み込み、テスト環境構築、テストケース生成・実行・レポートを自動的に行う統合テスト環境

(4) 有効性最大化テスト工学 (Efficacy-maximized test engineering)

高品質ソフトウェアの開発のための実践的テスト手法、ツール、プロセスに関する費用対効果の高い工学技術

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


夢: (1)普遍的テスト理論テスト技術の支援と育成に役立つ包括的な理論

各々のテスト技法の強み弱みが理解でき、適切な技法が選択できる指針のフレームワーク

<研究課題>

テストの仮説の明確化 (Explicit test hypotheses)

• 各テスト技法が前提とする仮定(ex. こういうプログラムのときに、こういうバグを検出)を明らかにすることにより、テストの目的を明確化

テスト有効性 (Test effectiveness)

• 各種テスト基準の有効性を評価し、テスト技法の組み合わせを支援

合成テスト (Compositional testing)

• 個々のテスト結果の再利用、コンポーネントベースの信頼性理論

実証体系化 (Empirical body of evidence)

• テスト理論の構築と進化の基礎となる実証データの体系

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


夢: (2)テストベースド・モデリングモデルからテストを設計するのではなく効果的にテストでき

るモデルを開発者が考慮(テスト容易化設計のように)

<研究課題>

モデルベースド・テスト (Model-based testing)

• 異なるモデル(遷移、事前・事後条件、シナリオベース)の組み合わせ

• ソフトウェア・プロセスへのMBTプラクティスの統合(実行可能なテストの生成、要件からテストへのトレーサビリティの維持)

アンチ・モデルベースド・テスト (Anti-model-based testing)

• モデルがない、あるいはアクセスできない場合(商用ソフト-COTS-、レガシーコンポなど)はプログラムの実行結果から帰納的にモデル化

テスト結果判定 (Test oracles)

• まだ人の目に頼るところが多く、複雑度や重要性が増大している今日では不十分。テスト自動化の障壁

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


夢: (3)100%自動テストソフトウェアの量、複雑性の増加に対して品質を維持する

手段として自動化が重要

テスト入力の生成手法、テストプロセス自動化手順

ソフトウェアの組み込み、テスト環境構築、テストケース生成・実行・レポートを自動的に行う統合テスト環境

<研究課題>

テスト入力の生成 (Test input generation)

• モデルベースドテスト生成、ランダムテスト生成、search-based test generation(メタヒューリスティックな探索手法-遺伝アルゴリズムなど)

ドメイン固有テストアプローチ (Domain-specific test approaches)

• 特定ドメイン(DB、GUI、Webアプリ、航空、通信)のテスト技法は研究されているが、ドメイン知識を利用する方法論の研究は少ない

オンライン・テスト (On-line testing)

• 動的解析や自己テスト手法を用いて、実運用でのシステムの振る舞いをモニターしてテストする技術

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


夢: (4)有効性最大化テスト工学高品質ソフトウェアの開発のための実践的テスト手法、

ツール、プロセスに関する費用対効果の高い工学技術主要な障壁はシステムの複雑度の増大

<研究課題>

進化の制御 (Controlling evolution)

• 稼働後も動的に進化するソフトウェアの品質の維持。進化の中での回帰テストの意義の理解、および回帰テスト選択手法の修正と拡張

利用人口・資源の活用 (Leveraging user population and resources)

• 動的にフィールドから収集したデータを使って社内の品質保証活動を拡大(ex. 多数のユーザのコンフィグレーション情報をテストに活用)

テストパターン (Testing patterns)

テストのコストの理解 (Understanding the costs of testing)

• テストの予算の効果的な使用、各テスト技法の費用対効果の見積もり

テスター教育 (Education of software testers)

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING


夢: 横断的な課題

<研究課題>

最新開発パラダイムにおけるテスト手法 (Testing within the emerging development paradigm)

• サービス指向コンピューティングにおけるサービス指向アプリケーションのテスト

• サービスのテストではオンライン・テストが特に重要(アプリケーションの振る舞いを観察する唯一の方法は稼働中のモニタリング)

機能特性と非機能特性の整合性テスト (Coherent testing of functional and extra-functional properties)

• 従来の機能テストには時 (いつ、時間) や、リソース使用量やワークロードの考慮がない

• モデルベースのアプローチの研究が進んでいるが、非機能特性の制約を考慮できるモデルへの拡張が必要

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

(C) K. Tatsumi 2010

まとめ : あらためて『温故知新』 [出典] 論語百選 http://shamada.net/weblog/rongo/ から引用

温故而知新 • 故(ふる)きを温(たず)ねて新しきを知る、以(もつ)て師と為るべし。

• 「古典や歴史を学んで、そこから現代に通用する新しい意義を見出すことができれば、立派な指導者になれるだろう」

學而時習之 • 学びて時にこれを習う、亦た説（よろこ）ばしからずや。朋遠方より来たる有り、

亦楽しからずや。人知らずして慍（うら）みず、亦君子ならずや。

• 「学んでは適当な時期におさらいをする、いかにも心嬉しいことだ。友が遠い所からからも尋ねて来る、いかにも楽しいことだ。他人が理解してくれなくても気することはない、凡人にはできないことだから」

學而不思則罔 • 学びて思わざれば則(すなわ)ち罔(くら)く、思いて学ばざれば則ち殆(あやう)し。

• 「学ぶだけで、じっくりと自分の頭で思索してみなければ、真に活きた学問とはならない。逆に、自分の頭で思い巡らすだけで、博く学ぶことをしなければ、危なっかしくて頼りにならない」

誨女知之乎 • 女(なんじ)に之(これ)を知るを誨(おし)えんか。之を知るを之を知ると為(な)し、

知らざるを知らずと為す。是れ知るなり。

• 「お前に知るとはどういうことか教えようか。知っていることは知っているとし、知らないことは知らないとはっきりさせる。これが本当に知るということだ」

http://shamada.net/weblog/rongo/

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

HIS

TO

RY

OF

SO

FT

WA

RE

TE

ST

ING

(C) K. Tatsumi 2010

の力で歴史をつくろう

ご清聴ありがとうございました