内容ソフトウェアテスト前史 (1/2)a-lifelong-tester.cocolog-nifty.com/publications/WACATE... · 2012-01-19 · 抽象モジュールオブジェクト指向ソフトウェア工学

HISTORY OF SOFTWARE TESTING

(C) K. Tatsumi 2010(C) K. Tatsumi 20101

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

辰巳辰巳辰巳辰巳辰巳辰巳辰巳辰巳敬三敬三敬三敬三敬三敬三敬三敬三

20102010年年年年年年年年1212月月月月月月月月1919日日日日日日日日

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

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

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)(1/2)

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

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

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

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

� 最初最初最初最初ののののプログラマープログラマープログラマープログラマー

�Ada Byron, Lady Lovelace

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

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




ソフトウェアテストソフトウェアテストソフトウェアテストソフトウェアテスト前史前史前史前史ソフトウェアテストソフトウェアテストソフトウェアテストソフトウェアテスト前史前史前史前史

� 最初最初最初最初ののののテスターテスターテスターテスターはははは ?

(2/2)(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)

▲ ▲ ▲ ▲ ▲

1965196519651965 19701970197019701950195019501950 1955195519551955 1960196019601960 20102010201020102000200020002000 20052005200520051975197519751975 1980198019801980 1985198519851985 1990199019901990 1995199519951995

ハードウェアハードウェアハードウェアハードウェア

ソフトウェアソフトウェアソフトウェアソフトウェア

開発技法開発技法開発技法開発技法////開発方法論開発方法論開発方法論開発方法論

マネジメントマネジメントマネジメントマネジメント////プロセスプロセスプロセスプロセス

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアソフトウェアソフトウェアソフトウェア

ハードウェアハードウェアハードウェアハードウェア

世界世界世界世界((((米国米国米国米国))))

日本日本日本日本

稼働稼働稼働稼働システムシステムシステムシステム

稼働稼働稼働稼働システムシステムシステムシステム

ITITITITパラダイムパラダイムパラダイムパラダイムのののの変遷変遷変遷変遷 (*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)(1/2)




� 1980年代年代年代年代: コストコストコストコストのののの時代時代時代時代

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

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

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

� 1990年代年代年代年代: 品質品質品質品質のののの時代時代時代時代

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

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

1950 1980 19901960 1970 2000 2010

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

ソフトウェアソフトウェアソフトウェアソフトウェア・・・・マネジメントマネジメントマネジメントマネジメントのののの観点観点観点観点ソフトウェアソフトウェアソフトウェアソフトウェア・・・・マネジメントマネジメントマネジメントマネジメントのののの観点観点観点観点 (2/2)(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. 1. デバッグデバッグデバッグデバッグ指向指向指向指向のののの時代時代時代時代デバッグデバッグデバッグデバッグ指向指向指向指向のののの時代時代時代時代 ((～～～～～～～～19561956年年年年年年年年))

� デバッグデバッグデバッグデバッグととととテストテストテストテストがががが区別区別区別区別されていなかったされていなかったされていなかったされていなかった時代時代時代時代� ソフトウェアはハードウェアの信頼性の一部

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

異常原因の究明である』

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

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

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

� McCracken, "Digital Computer Programming,“

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

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

評価指向

論証指向破壊指向

デバッグデバッグデバッグデバッグ指向指向指向指向予防指向

1950 1980 19901960 1970 2000 2010




2. 2. 論証指向論証指向論証指向論証指向のののの時代時代時代時代論証指向論証指向論証指向論証指向のののの時代時代時代時代 (1957(1957年年年年～～～～年年年年～～～～19781978年年年年年年年年))

� テストテストテストテストははははプログラムプログラムプログラムプログラムがががが仕様仕様仕様仕様をををを満足満足満足満足していることをしていることをしていることをしていることを示示示示すすすすためのものためのものためのものためのもの� Baker, "Digital Computer Programming"の書評, 1957

• 『デバッグとテストという二つのフェーズを区別すべき』– デバッグ：コーダの目論見どおりにプログラムが動くことを確認

– テスト：解決しようとした問題が解決されていることを確認

� 大規模プロジェクト(1950年後半～1960年代)

• 軍や航空・宇宙関係のシステム開発– SAGE(防空管制システム), SABRE(航空座席予約システム),

宇宙(マーキュリー計画,ジェミニ計画,アポロ計画)

• コンピュータメーカでの基本ソフトウェア開発– IBM OS/360 (参考) Brooksの「人月の神話」

� ソフトウェア工学の歴史の幕開け(1968, 1969)

• NATO Software Engineering 会議「テストではバグの存在は示せるがバグがないことは示せない」(Dijkstra,1969)

(1/2)(1/2)

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

破壊指向

予防指向

1950 1980 19901960 1970 2000 2010




2. 2. 論証指向論証指向論証指向論証指向のののの時代時代時代時代論証指向論証指向論証指向論証指向のののの時代時代時代時代 (1957(1957年年年年～～～～年年年年～～～～19781978年年年年年年年年))

� テストのコミュニティの開始• 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)(2/2)

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

破壊指向

予防指向

1950 1980 19901960 1970 2000 2010




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

� テストテストテストテストとはとはとはとは、、、、エラーエラーエラーエラーをみつけるつもりでをみつけるつもりでをみつけるつもりでをみつけるつもりでプログラムプログラムプログラムプログラムをををを実実実実行行行行するするするする過程過程過程過程（（（（（（（（テストテストテストテストのののの成功成功成功成功とはとはとはとはエラーエラーエラーエラーをををを見見見見つけることつけることつけることつけること））））� Myers, "The Art of Software Testing," 1979

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

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

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

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

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

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

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

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

テスト設計技法の目的

1950 1980 19901960 1970 2000 2010

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

破壊破壊破壊破壊指向指向指向指向

予防指向




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

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

"Guideline for Lifecycle Validation, Verification, and Testing of Computer Software"• ライフサイクルの中で、解析、レビュー、テストの活動

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

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

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

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

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

1950 1980 19901960 1970 2000 2010

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

破壊指向

予防指向




5. 5. 予防指向予防指向予防指向予防指向のののの時代時代時代時代予防指向予防指向予防指向予防指向のののの時代時代時代時代 (1988(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

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

破壊指向

予防指向予防指向予防指向予防指向




BeizerBeizerののののテストテストテストテスト道道道道ののののテストテストテストテスト道道道道

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

• フェーズ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)(1/2)




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

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

� Elmendorf, "Controlling the functional testing

of an operating system," 1969

• Elmendorfは1965年からOS/360の

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

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

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

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

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

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

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

(2/2)(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/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)(1/2)

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

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

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

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

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

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

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

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

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




制御制御制御制御フローテストフローテストフローテストフローテスト制御制御制御制御フローテストフローテストフローテストフローテスト (2/2)(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)(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 : 夢の実現に向けた研究課題




テストテストテストテスト技術技術技術技術ののののテストテストテストテスト技術技術技術技術のののの66つのつのつのつの側面側面側面側面つのつのつのつの側面側面側面側面

� テストは

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

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

� WHY : テストテストテストテストのののの目的目的目的目的

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

� HOW : テストテストテストテストのののの選択方法選択方法選択方法選択方法

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

� HOW MUCH : テストテストテストテストのののの量量量量テスト充分性、網羅度合い、信頼性尺度

� WHAT : テストテストテストテスト対象対象対象対象

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

� WHERE : 観測場所観測場所観測場所観測場所社内(in house)、疑似環境、実環境

� WHEN : 実施時期実施時期実施時期実施時期

ライフサイクルのどこで



(C) K. Tatsumi 2010

ソフトウェアテストソフトウェアテストソフトウェアテストソフトウェアテストのののの研究研究研究研究ロードマップロードマップロードマップロードマップSoftware testing research roadmap

テストベースドテストベースドテストベースドテストベースド・・・・

モデリングモデリングモデリングモデリング

10 0 % 自動自動自動自動テストテストテストテスト

有効性最大化有効性最大化有効性最大化有効性最大化

テストテストテストテスト工学工学工学工学

普遍的普遍的普遍的普遍的テストテストテストテスト理論理論理論理論

テストテストテストテストプロセスプロセスプロセスプロセス

信頼性信頼性信頼性信頼性テストテストテストテスト

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)(1/2)

� テストプロセステストプロセステストプロセステストプロセス (Testing process)

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

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

� テストテストテストテスト基準基準基準基準 (Test criteria)

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

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

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

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

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




達成達成達成達成テーマテーマテーマテーマ達成達成達成達成テーマテーマテーマテーマ (2/2)(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)(1)普遍的普遍的普遍的普遍的テストテストテストテスト理論理論理論理論普遍的普遍的普遍的普遍的テストテストテストテスト理論理論理論理論� テスト技術の支援と育成に役立つ包括的な理論

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

<研究課題>

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

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

� テストテストテストテスト有効性有効性有効性有効性 (Test effectiveness)

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

� 合成合成合成合成テストテストテストテスト (Compositional testing)

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

� 実証体系化実証体系化実証体系化実証体系化 (Empirical body of evidence)

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




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

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

<研究課題>

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

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

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

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

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

� テストテストテストテスト結果判定結果判定結果判定結果判定 (Test oracles)

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




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

手段として自動化が重要

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

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

<研究課題>

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

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

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

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

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

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




夢夢夢夢夢夢夢夢: : (4)(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

のののの力力力力でででで歴史歴史歴史歴史をつくろうをつくろうをつくろうをつくろうのののの力力力力でででで歴史歴史歴史歴史をつくろうをつくろうをつくろうをつくろう

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

Documents

内容 ソフトウェアテスト前史 (1/2)a-lifelong-tester.cocolog-nifty.com/publications/WACATE... · 2012-01-19 · 抽象モジュール オブジェクト指向ソフトウェア工学

内容ソフトウェアテスト前史 (1/2)a-lifelong-tester.cocolog-nifty.com/publications/WACATE... · 2012-01-19 · 抽象モジュールオブジェクト指向ソフトウェア工学