高信頼化ソフトウェアのための開発手法ガイドブッ …（参考）NGT（Notation...

© 2011 Fuji Xerox Co., Ltd. All rights reserved.

高信頼化ソフトウェアのための開発手法ガイドブックセミナー

テスト網羅性をとるための新しい考え方

ソリューション・サービス営業本部／秋山浩一

■IPA/SECセミナー

2011年10月24日（月）

© 2011 Fuji Xerox Co., Ltd. All rights reserved. 2

1985 年富士ゼロックス入社

現在はHAYST法のコンサル業務に従事

NPO法人 ASTER理事

JaSST東京実行委員

JSTQBステアリング委員

SQiP研究会委員長（2011年～）

ISO/IEC JTC 1/SC7 WG26委員

香川大学大学院在学中

古川研究室

SESSAMEは2011年5月に入会

自己紹介

2

© 2011 Fuji Xerox Co., Ltd. All rights reserved. 3 © 2010 Fuji Xerox Co., Ltd. All rights reserved. 3

テスト技法の位置づけ

テストの目的

Projectリスクの軽減

“こんなはずでは”を撲滅

静的技法

レビュー

静的解析

Productリスクの軽減

“バグ検出”で品質向上

動的技法

構造ベース

ステートメント

デシジョン

仕様ベース

機能テスト

XX品質特性確認テスト

経験ベース

エラー推測

探索的テスト

要求達成度合の確認

“カタログ値”の品質保証

品質計測技法

IN DO OUT


並行状態グラフペトリネット到達グラフ

タイミング

直交表・HAYST法ペアワイズ・k-way 網羅的ピンポイント

シナリオ業務フロー

異常値・特異値分析エラー推測

単一機能

論理関係

状態遷移時間/順序性

並列処理

ピンポイント的な静的解析結果の活用

統計的テストリスクベース

欠陥仮説法

S1 S2

同値分割法境界値分析

ドメイン分析

ランダム

CFD法原因結果グラフ

デシジョンテーブル

機能リストに基づく単機能確認テスト

a1

a2

b1

b2

b3 a3 モデル

チェッキング

C1 E1

C2 ∧

探索的テスト例外ユースケース

α・βテスト

制御カバレッジ A B

C

データフローカバレッジ

全数テスト

事象同期グラフ割り込み処理テスト

網羅的静的解析

ユースケース

ファズテストランダムテスト

機能図式状態遷移テスト

値の変化

A

ポジショニングマップ

組合せ A B

C D


テストの全体像

テストの厚み

リスク

戦略方針

テストアーキテクチャドキュメント

テストアーキテクチャ

テスト対象分析結果

ドキュメント IN OUT

問題 •問題リスト

要求 •要求/要件仕様書

仕様 •機能仕様書

設計 •モデル化/最適化

コード •成果物

振る舞い

構造

品質 •品質特性

側面 •テストタイプ

分類 •詳細テストタイプ

設計 •テストレベル

プロセス •作業プロセス

振る舞い

構造

曖昧

具体

曖昧

具体


従来のテストの問題点

テストに頼りすぎる

テストだけでSWの欠陥をすべて見つけようとする

「要件－仕様－設計－コード－テスト」について、トレーサビリティが取れていない

品質の見える化が不十分

テストに渡されるソフトウェアの品質がわからない

テストが終わった段階のソフトウェアの品質が不明

テストケースの質が悪い

テスト全体が俯瞰できないため網羅的なテストになっていない（テストに対する要求の分析が無いまま、いきなり仕様書から直接テストケースを作成している）

テスト技法が適切に使われていない


6.1 テスト要求分析

テスト要求分析手法

ツリー型： NGT、Tiramis、TAME

表形式： FV表、ゆもつよメソッド

テスト要求分析ですること

テスト対象の情報収集お客様に属する情報（解決すべき問題、要求、QCD）

プロジェクトに属する情報（進捗状況、選択技術、急所）

テスト要求分析手法を使用しテスト全体を明らかにする

テスト要求分析の実施方法

テストベースを収集し全員参照可能とする（構成管理）

テストベースを整理しテスト目的やテスト対象を扱いやすい単位にまで分解体系化しテスト全体を明らかにする

※『高信頼化ソフトウェアのための開発手法ガイドブック』の章番号と対応しています。


（参考）NGT（Notation for Generic Testing）とは

テストのモデリングのための記法で、テスト観点をツリー型に列挙・整理・検討・詳細化・体系化する

電気通信大学の西康晴先生が提唱している手法詳細は、JaSST ’06 東京,

「テスト設計におけるモデリングのための記法」（西康晴先生） http://jasst.jp/archives/jasst06e/pdf/E2-3.pdf

© NISHI, Yasuharu1

テスト要求/アーキテクチャモデルの例：NGT

GUI 機能データ動作環境

プラットフォームネットワーク

OS ハードウェア

OSの種類 OSのバージョン IEのバージョン

電子メール


6.2 テスト観点とテストアーキテクチャ設計

テスト観点

テスト時に注目するポイント

テストエキスパートの考え方

テストアーキテクチャ設計（※ 本書の方法）

テストの網羅性を高めるために構造を明らかにするテスト観点をタイプ分けする

テスト観点タイプを組み合わせてテストの構造を作成する

テスト観点

観点1 観点2 観点3 観点4

登録する

照会する

更新する

検索する

多い・少ない

許容・禁止

超過・不足

増加・減少

エンドツーエンド型

同時に組み合わせて

連結・連動中に

Ａの後にＢを

出力の読みやすさ

エラーメッセージ

テスト観点

観点1 観点2 観点3 観点4

登録する

照会する

更新する

検索する

多い・少ない

許容・禁止

超過・不足

増加・減少

エンドツーエンド型

同時に組み合わせて

連結・連動中に

Ａの後にＢを

出力の読みやすさ

エラーメッセージ

例）機能網羅テスト {テスト対象}に{テスト観点1}させる ↓ {アドレス帳機能}に{登録する}させる


6.2.1 テスト観点

本書で取った方法（「何を」気にしているのか？）

テストの方法を単語レベルまで分解（166-167頁） → エンタプライズ系代表企業10社の現状調査 → テスト観点の要素を抽出（構造、接続、方式、連動、機能、性能、リソース、操作性、構成、業務、運用、障害、保守、移行、導入、本番等々）

テスト観点の要素を、特定の性質に着目し分類 →

それらをテスト観点ツリーにまとめる

テスト観点ツリーの親ノードと子ノードの関係を精査

同様に兄弟ノードの抽象化の度合い（粒度）を精査

テスト観点分類例テスト観点1 動詞「登録する」、「照会する」、「検索する」テスト観点2 形容詞・副詞「大量の」、「連続して」、「素早く」テスト観点3 関係・組み合わせ「エンド・ツー・エンド型で」、「同時に組み合わせて」テスト観点4 期待結果「出力の読みやすさ」


6.2.2 テストアーキテクチャ設計

本書で取った方法

テスト対象を発見する

テスト全体の枠組み（＝テストレベル）が決まる


6.2.2 テストアーキテクチャ設計（続き）

本書で取った方法

テスト観点1に、Tiramisで使用している基本構造構成要素を加え、テストタイプを豊かにする

目的

誰が

どこで（環境）

事前条件（状態）

イベント（トリガー）

入力

処理（動作）

出力

事後条件（状態）

誰に

処理

事前状態事後状態

入力出力

イベント目的

環境

誰が誰に


6.2.2 テストの構造

自然言語の文法

春は曙、夏は夜、秋は夕暮れ、冬はつとめて

｛A｝は｛B｝

テストタイプ名も文法で整理できる！

命令網羅試験 → ｛命令｝を｛網羅｝する試験

分岐網羅試験 → ｛分岐｝を｛網羅｝する試験

｛テスト対象｝に｛テスト観点1｝させる試験

複雑なテストタイプも文法を複雑にすることで対応可能

派生構造

組合せ構造

期待結果構造

（この構造以外にも存在するかもしれない）


6.2.2 4つのテスト構造

基本構造

テスト観点1とTiramisを使用して振る舞いを定義する

派生構造

基本構造にテスト観点2を追加することでシステムの使用条件を考慮したテスト構造を作る

組合せ構造

テスト観点1とテスト観点3を使用して組合せ構造を作る

どのように振る舞いを組み合わせるのかを決める

期待結果構造

基本構造、派生構造、組合せ構造のそれぞれに対してテスト観点4を適用し期待結果を網羅させることを考える


6.3.1 直交表を活用した網羅的な組合せテスト

何故ソフトウェアテストは難しいのか

機能に対する確認

入力の多さによる組合せの発散 → 全部をテストできない！

非機能に対する確認

お客様の非機能要件が不明

コンテキストの多様性

機能入力

出力

入力の多さによる組合せの発散

例）プリンタドライバで約１兆の組合せ

• 過負荷で入力が来ない

• シビアなタイミングで入

力がバッティング

正しい入力のためには

良い操作性が必要

テストの網羅性をあきらめてしまう組合せ、順序、タイミング

計画

実際

結合テスト

＝ＯＫ

バグ件数

設計～結合テストｼｽﾃﾑﾃｽﾄ AT

バグ件数計画と実績

対計画の 2～3倍のバグ発生

開発部門評価機能

SST Exitバグ検出率が低い

第三者評価部門

リリース後もだらだらとバグが出続ける


機能組合せテスト設計の課題

経験則でランダムに組み合わせると網羅率が低下する

機能組合せを網羅的に行うとテスト項目数が爆発する

対策前の組合せ網羅率経験で作りこみ約30%

直交表の活用

1. 網羅率向上 2. テスト項目数低減

対策

対策後の組合せ網羅率 HAYST法＞80%

プリンタドライバ機能組合せテスト

お客様は様々な機能の組み合わせでプリント

出力結果

＜ソフトウェア機能組み合わせテスト＞

禁則処理

多因子多水準 70因子280水準

用紙向き両面

原稿サイズ

カラーモード画質

N-Up トレイ Finisher

18種類

2種類 2種類

21種類 3種類

7種類 6種類 2種類

0

5000

10000

15000

20000

25000

30000

35000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

単純に考えると組合せテストは

指数関数的増加！

理由

HAYST法とは


直交表の活用＜想定＞

•文字化け不具合が発生した。プリンタドライバの設定であやしそうなところは、 o 印刷モード（速度優先、画質優先） o DPI（600、300） o ドライバのバージョン（At Launch、Post Launch） o フォントの置き換えモード（ﾌﾟﾘﾝﾀﾌｫﾝﾄを使用、True Typeを使用、ﾌｫﾝﾄ置き換えﾃｰﾌﾞﾙを使用）の4点。

＜実験の目的＞

•印刷モード×DPI×Launch×Fontの組合せを色々変えてどの組合せで問題が発生しているか調査する。

速度優先

画質優先

600dpi

300dpi

At Launch

Post Launch

ﾌﾟﾘﾝﾀﾌｫﾝﾄ

True Type

置き換える


全部の組合せを作成した場合

＜全ての組合せ＞ •モード×DPI×Launch×Font ＝ 2×2×2×3 ＝ 24回実験を行えば全てのパターンを評価することができる

＜問題点＞

•実験数が24件と多い •さらに、詳細設定--文字（4種類存在する）の組合せも行いたくなったら24×4 ＝ 96回も実験する事になり現実的で

ない

速度優先

画質優先

600dpi

300dpi

At Launch

Post Launch


True Type

置き換える

No. 印刷モード DPI Launch Font1 速度優先 600 At Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ2 速度優先 600 At Launch True Type3 速度優先 600 At Launch 置き換える4 速度優先 600 Post Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ5 速度優先 600 Post Launch True Type6 速度優先 600 Post Launch 置き換える7 速度優先 300 At Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ8 速度優先 300 At Launch True Type9 速度優先 300 At Launch 置き換える10 速度優先 300 Post Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ11 速度優先 300 Post Launch True Type12 速度優先 300 Post Launch 置き換える13 画質優先 600 At Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ14 画質優先 600 At Launch True Type15 画質優先 600 At Launch 置き換える16 画質優先 600 Post Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ17 画質優先 600 Post Launch True Type18 画質優先 600 Post Launch 置き換える19 画質優先 300 At Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ20 画質優先 300 At Launch True Type21 画質優先 300 At Launch 置き換える22 画質優先 300 Post Launch ﾌﾟﾘﾝﾀﾌｫﾝﾄ23 画質優先 300 Post Launch True Type24 画質優先 300 Post Launch 置き換える


入力の組合せ評価：直交表と割り付け

＜実験計画法（直交表実験）＞ •モード×DPI×Launch×Font ＝ 2×2×2×3 ＝ 24実験を8実験で済ます •組合せが公平な表（例えば列の和を求めたら全て4になる）

• L8直交表（8回の実験ができる表。割り当てられるのは2水準の因子が最大7個まで） • 水準が増えた場合は列を合体して割り当てる

モード

速度優先

画質優先

速度優先

画質優先

速度優先

画質優先

速度優先

画質優先

DPI

600

300

600

300

300

600

300

600

Launch

At

Post

Post

At

At

Post

Post

At

Font

ﾌﾟﾘﾝﾀ

ﾌﾟﾘﾝﾀ

TrueType

TrueType

TrueType

TrueType

置き換え

置き換え

No.

1

2

3

4

5

6

7

8

1 2 3 4 5 6 7

0 0 0 0 0 0 0

0 0 0 1 1 1 1

0 1 1 0 0 1 1

0 1 1 1 1 0 0

1 0 1 0 1 0 1

1 0 1 1 0 1 0

1 1 0 0 1 1 0

1 1 0 1 0 0 1

1

2

3

4

5

6

7

8

L8

1

2 4

3 5

6

7

2水準 3水準

4 5 6 1, 2,3

速度優先

画質優先

600dpi

300dpi

At Launch

Post Launch


True Type

置き換える

0

1

0

1

0

1

0

3

2

1

まとめて3水準が入る因子にする

因子

直交表線点図

モード DPI Launch Font


＜参考＞：乱数ではどうなる？

＜乱数ではどうなる？＞乱数を使用したら値がばらけるのでうまくいくのでは？ここでは，

π = 3. 1415926535 8979323846 2643383279 5028841971 6939937510 5820974944 5923078164 0628620899 8628034825 3421170679 8214808651 3282306647 0938446095 5058223172 5359408128 4811174502 8410270193 8521105559 6446229489 5493038196 4428810975 6659334461 2847564823 3786783165 2712019091 4564856692 3460348610 4543266482 1339360726 0249141273

を使用して偶数を０奇数を１として表を作成してみる。

1 2 3 4 5 6 7

1

2

3

4

5

6

7

8

4 5 5 7 4 4 4

１の数の合計

π

5

5

3

3

3

4

7

3

1 1 0 1 1 1 0

0 1 1 1 0 1 1

1 1 0 1 0 0 0

0 0 0 1 1 0 1

0 1 1 1 0 0 0

0 0 1 1 1 1 0

1 1 1 1 1 1 1

1 0 1 0 0 0 1

１の数の合計

４列をみると１が７つも現れている。

したがって４列目にモード（速度優先/画質優先）をわりあてると速度優先が７つに対し画質優先が１つしか割り当てられない。

これはテストの不均一を示している。


組合せ網羅率によるテスト品質指標の採用

組合せ網羅率＝全ての2因子間の組合せｰ禁則組合せ

マトリクスに出現する組合せ

従来のKnowHowに基づいた方法 HAYST法による組合せ生成

網羅率30％～40％程度網羅率70％～90％

品質の違いは一目瞭然：自分の業務を定量的に判断できる

総当り表による比較：出現しない組合せ：禁則：出現組合せ：同じ因子同士


6.3.2 シナリオを用いたピンポイントテスト

コンテキスト（使用の文脈）を定義する

いつ（When）、誰が（Who）、どこで（Where）

例外シナリオを発見する

テスト観点2（下表）をフローに入れる

シナリオを業務の観点で連結していく

業務フロー、業務周期、業務データの観点を適用

複雑なテストシナリオを構築していく

強度強い弱い時期早く遅く多い少ない時間長く短く増加減少間隔広く狭く余分不足期間長く短くあるないゼロ先に後で

種類多種小種同時に並行に規模大きい小さい早く遅く距離遠い近い逆転反復挿入

速い遅いタイミング

早く遅く

高速低速広く狭く急緩多く少なく許容禁止程度いつもたまに必須任意回数多く少なく長い短い接続つなぐ切り離し切り替え上限下限方向上へ下へ広い狭い高い低い最大限最小限超過不足高い低い高く低く多い少ない遠く近く

金額大きい小さい

設定

範囲

負荷

頻度位置

数量

順序

速度

拡張


6.3.2 シナリオを用いたピンポイントテスト（続き）

業務フローの観点によるシナリオテスト

顧客からヒアリングした業務フローでは漏れる

「進む、戻る、繰り返す、止まる、超える、途切れる、分ける、纏める、無くす、変える」等々のテスト観点を使用して、データの重複や消えるなどの欠陥を検出

業務周期の観点によるシナリオテスト

顧客からヒアリングしやすい

テストデータの作成は逆演算になる

業務データの観点によるシナリオテスト

データの変化に着目したテストシナリオを作成する

上記に加えて、人・物・金・承認の流れを組み合わせる

高信頼化ソフトウェアのための開発手法ガイドブッ …（参考）NGT（Notation...

Documents

Transcript of 高信頼化ソフトウェアのための開発手法ガイドブッ …（参考）NGT（Notation...

高信頼化ソフトウェアのための 開発手法ガイドブッ …（参考）NGT（Notation...

Documents

Transcript of 高信頼化ソフトウェアのための 開発手法ガイドブッ …（参考）NGT（Notation...

高信頼化ソフトウェアのための開発手法ガイドブッ …（参考）NGT（Notation...

Transcript of 高信頼化ソフトウェアのための開発手法ガイドブッ …（参考）NGT（Notation...