More Related Content Similar to ゆもつよ博士論文説明資料公開
Similar to ゆもつよ博士論文説明資料公開 (20) More from Tsuyoshi Yumoto
More from Tsuyoshi Yumoto (9) ゆもつよ博士論文説明資料公開3. 問題意識
2018/2/5
1. 緒論
学籍番号 201430172 2
ソフトウェアの規模と複雑度合いは増加の一途
必要とされるテストケースの数はJonesの研究からみて増大する.
多くの人員がテストケースを作る仕事にかかわるようになる.
Testing
increaseinsize
increasecomplexity
Testing
Development
・Requirement
・Specification
・Design
・CodeDevelopment
・Requirement
・Specification
・Design
・Code
FP規模は
30年間で
10倍に増加
Longstreet
Quantity
FP Test cases
Quantity
FP Test cases
テストケース数はFP(function point)
総計の1.3乗~1.5乗 Jones
6. 論文構成
• 本論文の構成は以下のとおり
2018/2/5
1. 緒論
学籍番号 201430172 5
第1章 緒論 – 問題意識と研究テーマ
第2章 システムテストにおけるブラックボックステストの課題
第3章
テスト分析結果の
ばらつき傾向とその影響
第4章
I/O テストデータパター
ンを使ったテストケース
抽出手法
第5章
データ共有タスク間の順
序組合せテストケース
抽出手法
第6章 結論 – まとめ
参
考
論
文
IEEE ICSTW 2015
(Conference)
IEEE ICSTW 2016 (Conference)
電気学会論文誌 C 2017
(Journal)
8. 研究の対象
• テストレベル
– システムテストレベル
• 開発した単体の「タスク」が
がすべて統合されるため,
規模の増大と複雑性の増加の
影響が大きい.
• テスト開発プロセス
– テスト分析とテスト設計
• テスト分析にてテスト対象を
詳細化
• テスト設計にてテストケースを
抽出
• テスト設計の種類
– ブラックボックステスト
2018/2/5
2.システムテストにおけるブラックボックステストの課題
学籍番号 201430172 7
V model (Forsberg,1995 et.al)
Develop system
Performance Specification
and System VerificationPlan
Integrate System andPerform
System Verificationto
Performance Specification
テスト計画
テストプロセス
テスト分析 テスト設計 テスト実装 テスト実行 終了基準の評価
テスト開発プロセス
12. 予備実験の概要
• 目的
– テスト分析手法を適用する前のテスト分析での結果のばらつき傾向,及び
その傾向と手法適用後の結果との相関を調べること.
• 実験の概要
– ワークショップを通じてグループ単位,個人単位の実験を実施.
• グループ単位の実験(2回実施)
– ①1企業の同一製品開発チームのメンバーを4〜5人にグルーピングして実施(6サンプル)
– ②オープンな研修にて,別々の企業の参加者を4〜5人にグルーピングして実施(2サンプル)
• 個人単位の実験(1回実施)
– テスト技術者コミュニティ主催のワークショップを通じて実施(57サンプル)
– 前述した「テストカテゴリベースドテスト」を利用した.
2018/2/5
3.テスト分析結果のばらつき傾向とその影響
学籍番号 201430172 11
各自のこれま
での経験
テスト分析手法の
知識
各自のこれまでの経
験をベースにした
グループワーク
最初のグループワー
ク+知識
テスト
分析結果
参加者間の
意見交換
テスト
分析結果
テスト
ベース
参加者間の
意見交換
各自のこれま
での経験
テスト分析手法の
知識①
(単一機能)
各自の経験をベース
にした個人ワーク
各自の経験
+知識①での
個人ワーク
各自の経験
+知識①+知識②
での個人ワーク
テスト
分析結果
テスト
分析結果
参加者間の意見
交換
テスト分析手法の
知識②
(統合機能)
テスト
分析結果
テスト
ベース
個人単位では57人分のサンプルを収集グループ単位では8つのサンプルを収集
18. 適用評価
• 実験の目的
– I/O テストデータパターンを使う分析手法が,現実のテス
ト設計と比較して網羅的であることの確認を目的とする.
• 評価方法
– 実験対象は,実在するオンラインのモバイル写真共有アプ
リケーションを使った.モバイル写真共有アプリケーショ
ンの実際の開発にて使われたテストケースと、提案する手
法で分析した結果を比較する.
– テスト対象フィーチャのテストベースを分析し,画像デー
タ,画像の情報、設定データ,外部コマンドを入力データ,
出力データとして扱うこととした. そして,テスト実行時
の追記したデータの流れをシミュレーションし,該当する
I/O テストデータパターンを明らかにした.その後,I/O テ
ストデータパターンと既存の分析手法であるテストカテゴ
リベースドテストを併用してテスト分析を行った.
2018/2/5
4. I/O テストデータパターンを使ったテストケース抽出手法
学籍番号 201430172 17
19. 適用評価の題材3
2018/2/5
4. I/O テストデータパターンを使ったテストケース抽出手法
学籍番号 201430172 18
写真を扱うアプリです。
サーバー群
端末の画像
アップロード
ダウンロード
画像参照
・・・
ログイン/ログアウト
アップロード
ダウンロード
画像参照
・・・
テスト対象:
アプリが中⼼。
サーバーとのやり取
りにも着⽬するが、
APIのテストは別途
サーバー側で⾏う。
モバイル写真共有
アプリケーション
Feature
アカウント新規登録
ログイン
ホーム
設定
マイフォト
グリッドビュー
フロービュー
マップビュー
ピクチャービュー
再生
スライドショー
写真詳細情報/画像一枚編集
画像移動・削除
アップロード
ダウンロード
共有
静的画面
20. 適用評価の結果
• 網羅度合いの向上
– 実プロジェクトの結果と適用評価結果の両者を比較すると,I/O テストデータ
パターンを利用したテスト分析の結果が実プロジェクトより多くの項目を特
定できたことが確認できている.
• 考察
– P1 が特にテストカテゴリと実プロジェクトの差異が大きいことがわかる.P1
は外部からの入力を行い,外部に出力する最も単純なパターンであり,I/O テ
ストデータパターンから見て,単純なことを確認する仕様項目が漏れている.
2018/2/5
4. I/O テストデータパターンを使ったテストケース抽出手法
学籍番号 201430172 19
0
10
20
30
40
50
60
70
80
90
Test Category Real Project
Upload Grid View
0
5
10
15
20
25
30
35
40
P1 P2 P3 P4 P6 P7 P9 sum
Upload Grid View
I/Oテストデータパターン 実プロジェクト
22. Ini
変更タスクTai
(R+1)
Outi
AS
StlDsj
So k (最初の実行と入出力)
変更Q
Ini’
波及タスクTai’
(R)
Outi’
U:更新
U:更新
So k’ (二番目の実行と入出力)
提案手法の概要
• 変更が入りテストが必要なTaを「変更タスク」とよび,順序組み合わせ
のテストが必要な後続のTaを「波及タスク」と呼ぶ.この2タスク間の制
御を行うのがStとなる.
• テスト対象となる機能セットに対して,DFD,ERダイアグラム,CRUD
ダイアグラムをテストベースとして利用して,テストケースを抽出する.
2018/2/5
5.データ共有タスク間の順序組合せテストケース抽出手法
学籍番号 201430172 21
変更波及は,タスク間の参照が状
態と保持データを介した範囲に限
られると考える
この考えから波及を受ける
タスクを特定する
CRUD ダイアグラム
ER ダイアグラム
DFD
提案手法で利用するテストベース
機能セット
タス
ク
タス
ク
タス
ク
タス
ク
上位の制御フローは状態遷移が制御条件となる
23. 提案手法の概要
• テストケース抽出ルール
– 提案する手法は,2 タスク間の順序組合せを対象
とする.2 タスク間の順序組合せの抽出は以下の
ルールを適用する.
• ルール1: 変更タスクの特定
• ルール2: 波及タスクの特定
• ルール3: 順序組合せのテスト
ケース抽出
2018/2/5
5.データ共有タスク間の順序組合せテストケース抽出手法
学籍番号 201430172 22
変更タスク
波及タスク
上位の制御フローは状態遷移が制御条件となる
29. 結論
2018/2/5
6. 結論
学籍番号 201430172 28
研究の目的
テストケースを作成する工程に投入される人員が、必要なテストケースを網羅的に抽出し,抜
け漏れを防止できるようにすることを目的とし,適切な数のテストケースを開発するための手
法を提案し,その適用評価を行った.
テストケースの抜け漏れ テストケースの増加
課題
テスト対象をテスト設計できるサイズまで
詳細化していく過程が経験則や個人の考え
方に基づいているため,分類にばらつきが
発生し,抜け漏れにつながる.
システムテストでは, 状態遷移に伴う時系列
の組合せのテストも求められることから, テス
トケース数の爆発問題が生じる.
テーマ
I/Oテストデータパターンを使った分析 順序組合せテスト技法
テスト実行時のデータI/O の要素で分類し網
羅的に分析する方法を提案
状態遷移を持つソフトウェアにおいて,保持
データを介して影響が生ずる場合のテストに
関して,順序組合せテストケースを抽出する
手法を提案
結果
提案した方法で特定した仕様項目と実プロ
ジェクトで作られるテストケースと比較して,不
足している仕様項目の発見が可能であること
が確認
従来手法である画面遷移図からS1 網羅基準
にて抽出した状態遷移パスと提案手法を比
較して,テストケース数の削減ができる効果と,
S1 レベルの画面遷移の網羅では抽出できな
いテストケースが抽出できる
効果を確認
IEEE ICSTW 2015
(Conference)
電気学会論文誌 C 2017
(Journal)
Editor's Notes 本審査 60分のプレゼン(40分以上は行う)
リスク工学専攻の湯本剛です.
本日は,現在,博士論文の執筆を進めております「入出力データの順序情報に基づくブラックボックステスト手法に関する研究」について発表いたします.
どうぞよろしくお願いいたします.
--------
タイトル 入出力データの順序情報に基づくブラックボックステスト手法に関する研究概要本研究はブラックボックステストのテストケース抽出に抜け漏れやケース数が増 大する課題に対して,テスト対象に対する入出力データの順序情報に基づいてテストケースを抽出する 手法を提案し,合理的にテストケースを抽出することを成果とするものである
予備審査のコメント
徳島大学 泓田先生筑波大学 片岸先生 説明に文字が多すぎる.モデルなどでわかりやすく説明をしてほしい.どう素晴らしかったか?を説明してほしい
筑波大学 吉田先生 これだけで全てのことがテストできるとは思えない.他の既存のやり方とどうマッチングさせているのかとかを説明してほしい
筑波大学 倉橋先生 I/OパターンのP1が見つかって何が良いのか? 参考文献の on IEEE は書き方が違う
公式には,発表は60~90分,質疑30分です.よって,湯本さんの場合は,公式には10:00-12:00の内訳は,下記の通りです.・発表 60分・質疑 30分・最終試験 30分
場所: つくばキャンパス内総B811 セミナー室2
池袋亀戸32分
. 発表の内容ですが,論文の章構成に従い,ご覧の順に進めてまいります. まず,最初に本研究の背景です.
ソフトウェア開発の中の品質を確保する主要な技術として, ソフトウェアテストがあります.求められるテストケースの数は ソフトウェアの複雑性と規模の急激な増加に伴い増加の一途を たどっています.
ブラックボックステストの場合テストケースの数量は規模に対して1.3乗から1.5乗という研究結果があります.
また,ソフトウェアの規模は30年間の間に10倍に増大しているという調査結果もあります. 必要とされるテストケースの増加に伴い,多くの技術者がテストケースの開発に携わるようになっています.
それにもかかわらず開発の現場では,テストケースを作成するためにテスト対象を詳細化する際のルールが明確になっていないことが多いのが実情です.
投入された人員は個々の考え方に基づいてテストケースを開発し,それらがマージされていくことが,テストケースの増加,漏れの原因になっていると考えられます. そこで,本研究では,私自身の実務であるソフトウェアテストのテストケース作成方法に焦点を当て,,システムテストにおけるブラックボックステストでのテストケース作成工程に投入される人員が、必要なテストケースの抽出において抜け漏れを防止し,適正な数量にすることをテーマとしました.
テスト実行時のテスト対象に対する入出力データの順序情報に基づいてテストケースを抽出する方法を2種類提案し,その適用評価から合理的にテストケースを抽出できることを確認しました. 本論文の構成ですが,ご覧の6章からなります.
2章でまずシステムテストにおけるブラックボックステストにおける課題と,関連する先行研究について述べる.また,本研究で使用するテスト分析手法について解説します
3章では前章で述べた課題を更に分析するために,実験を行い実験結果で確認を行いました.
4章ではテスト実行時のデータの入出力に着目し、テスト対象の分析を網羅的に行う手法の提案と適用評価を行いました.
5章ではテスト実行時のデータの入出力を順番に組み合わせる必要がある際に,重要な順序組み合わせを抽出してテストケースにする方法の提案と適用評価を行いました.
最終の6章は結論を述べます. 2章では,研究対象の範囲を明確にするために定義を説明し,そこで起きている課題を述べます.
本研究では,図に示す状態と保持データを持つアプリケーションソフトウェアに対するソフトウェアテストを研究対象にします.
アプリケーションソフトウェアは,入力に対して,何らかの出力を返します.
ソフトウェアの機能は,何らかの入力を出力に変換する処理により実現されていると考えられます.
この処理を本研究ではタスクと呼びます.
タスクは,該当のテストレベルからみた入力を出力に変換している1処理でです.
そのため,タスクのサイズは,テストレベルによって決まります.
ソフトウェアテストといっても非常に広い活動の総称であるため,研究対象を明確に定義したいと思います.
テストには多くの段階があり,それはVモデルにて表現されることが一般的です.
本研究はVモデルでいうところのシステムテストを対象にします.
開発した単体のソフトウェアがすべて統合されるため,規模の増大と複雑性の増加の影響が大きく,私自身の問題意識と一致するためです.
テストの活動は計画からテストケースの作成,実行,結果の評価までありますが,テスト開発プロセスと呼ばれる部分のテスト分析と設計を対象にします.
分析にてテスト対象を詳細化してテストケースが作れる粒度にしていきます.設計にて,テストケースとして完成させていきます.
テストケースの種類はブラックボックステストを対象にします. テスト分析,設計の活動での問題点のひとつとして,テスト対象を詳細化する際の分類に対する一貫性の欠如があげられます.
テスト対象をテスト設計できるサイズまで詳細化していく方法が経験則や個人の考え方に基づいているため,複数人で分析作業をした時の分類にばらつきが発生します.
4つの表は,予備実験の中で,ある企業にて実験をさせてもらった際に,仕様書からテストケースを各自がいつも行うやり方で作ってもらった時の結果になります.
これらは個人の結果ではなく,4−5名でグルーピングして一つの回答を作ってもらった際の結果です.
同じ企業の同じプロダクトに携わる人たちでもこのように結果が変わります.
これは,テストケースの抜け漏れ,重複の原因となりうると考えています.
もう一つの問題として機能間の統合のテストケースの問題があります.
機能間の統合でのテストケース数は, 単一の機能や制御構造の和ではなく積となります
それに加え, システムテストでは, 状態遷移に伴う時系列の組合せのテストも求められることから, テストケース数の爆発問題が生じます.
時系列の組合せとして, 状態遷移テスト設計によるS1 網羅基準 (1 スイッチカバレージ )があります.これは,図のようにある状態から処理を実行し
次の状態に遷移したあとにさらにもう一度処理を実行してその後の状態までを確認する網羅基準です.
これは2 つの状態遷移間における遷移数の積となり, 膨大なテスト工数を必要とする課題があります.
この2つの課題に対する研究を進めるための前提となる先行研究であるテストカテゴリベースドテストを簡単に説明します.
私自身がテストコンサルタントをしていた中で提案し現場に適用している手法であり,検証実験を行い論文にした実績があります.
一言で言うと,問題の一つであるテスト分析の際の分類に対する一貫性の欠如の問題を解決することが目的の手法です.
論理的機能構造という分類の参照モデルを使い,一貫性のある分類を定義することで,テスト対象の詳細化を行う際にばらつきが出ることを抑えるのが狙いです.
この手法を3章の予備実験で使い現状調査を行いました.
また,4章で提案するI/Oテストデータパターンはテストカテゴリベースドテストでは不十分であった網羅性の確保の考え方を捕捉する提案となります. 3章では,前章で説明した問題に対する実証データを得るための実験を行った結果について述べます.
実験のためのワークショップを数多く行いましたが,本論文ではデータ収集が想定通り行えた3つの実験の結果を利用しました.
最初はグループ単位の実験結果の収集を2回おこない,8つのサンプルを収集しました.その後個人単位の実験結果の収集を行い,57人分のサンプルを収集しました.
ワークショップでは,最初に演習に使うテストベースを示し,参加者が各自の考えに基づいたテスト分析を実行してもらいます.
その後,テスト分析手法と実施手順を説明して手順に沿って再度テスト分析を実行してもらい,テスト分析手法の知識を与える前と後の回答を検証実験のデータとして利用しました.
正解は演習の模範回答を利用しました.
題材は2つ用意していました.いずれもサイズは同じ程度で作ってあります.
一つは組み込みソフトウエア開発をイメージした仕様書です.
ヘッドセットの1機能を対象にしています. もう一つはエンタープライズ向けソフトウエア開発をイメージした仕様書です.
飛行機予約システムの1機能を対象にしています.
グループ単位での予備実験の結果です.
各自の考え方に基づいてテストケースを作成すると結果がばらつくことがわかりました.
先ほどの分類の一貫性の欠如のスライドにて示した通りになります.
テスト分析手法適用後の結果では,8グループ中6グループにて,分類に一貫性を持たせるだけでテストケースの不足が解消されることを確認しました.
ただし,解消されるにあたり何かしらの相関関係を見出すにはいたりませんでした.サンプル数が8つと少ないことも原因の一つだと考え,個人単位での
データ収集を行うことにしました. 個人単位の予備実験の結果になります.
そのために現実のテスト設計の結果と, I/O テストデータパターンを使った分析結果を比較する.
491 151ケースあり
59,22項目
変更タスクで保持データを追加/更新し,波及タスクがその保持データを使う場合が該当する
変更タスクから波及タスクへのデータフローを決定するのは,2階層の制御フローである
状態は順序組合せの制御フローを決定する上で影響を及ぼす
最後に全体を総括します.