東芝におけるソフトウェア厍拾匇上に匇けた勚り匢 …© 2013 toshiba...

© 2013 Toshiba Corporation

東芝におけるソフトウェア品質向上に向けた取り組み〜テスト技術を中⼼にして〜

2013年11月22日

東芝ソフトウェア技術センター

小笠原秀人（[email protected])

© 2013 Toshiba Corporation 2

目次

１. 東芝グループソフトウェア力強化

2-1. テスト設計手法

2-2. テストケース生成ツールAPTNavi

2-3. テスト管理システムTETRAPLUS

2. テスト技術


目次





2. テスト技術


事業推進体制ソフトウェア技術センター研究開発

• より魅⼒的な製品を⽣み出すために- 東芝グループのソフトウェア開発⼒を強化 -

http://www2.swc.toshiba.co.jp/jp/tech/index_j.htm

• 要求分析技術要求分析技術要求分析技術要求分析技術

• 形式手法形式手法形式手法形式手法

• プラットフォーム構築技術プラットフォーム構築技術プラットフォーム構築技術プラットフォーム構築技術

• ソースコード静的解析技術ソースコード静的解析技術ソースコード静的解析技術ソースコード静的解析技術

• ソフトウェアテスト技術ソフトウェアテスト技術ソフトウェアテスト技術ソフトウェアテスト技術


• 要求分析技術– 顧客要求を分析し、曖昧さ・抜け・矛盾を排除した

要求仕様を効率的に作成し管理する技術。要求を体系的に抽出し、優先度づける要求抽出技術と、要求仕様を検証可能なレベルで正確に表現する要求仕様化技術からなる。

• 形式手法– ⾼度な信頼性を求められるシステムに対して、要求

仕様や設計仕様を特定の規則で記述、数理的技法や計算機による網羅的探索技法を⽤いた検証をするための技術。• 形式仕様記述：⼊出⼒データや制約を中⼼に記述す

ることで製品仕様の曖昧性や抜け・矛盾のチェックをサポートする

• モデル検査：製品の動作モデルを記述し、⼤量の動作実⾏系列を網羅的に動作させて誤りを発⾒する

ソフトウェア設計・検証技術（1/3）

http://www2.swc.toshiba.co.jp/jp/tech/design.htm


• プラットフォーム構築技術– 幅広い製品シリーズを効率的に開発していくため、そ

れらに共通となるコア資産＝ソフトウェア・プラットフォームを構築し、活⽤する技術。• プラットフォーム戦略策定：製品シリーズに対して、構築

すべきプラットフォーム化範囲を定める• アーキテクチャ設計：戦略に基づき製品シリーズにおけ

る固定部と可変部を分離した設計を⾏う• ソフトウェア構造診断：構築後も進化・改変していくプラ

ットフォームの設計品質を維持、向上させる

• ソースコード静的解析技術– 実際にプログラムを動かすことなく静的に解析して、プログラム

の品質上の問題点となる箇所を抽出するための技術。コンパイル時には構文エラーや警告とならない各種コーディングルール違反を発⾒するとともに、ランタイムエラーを引き起こす各種メモリーエラーやメモリーリークを、実⾏パス探索を⾏うことで検出する。

ソフトウェア設計・検証技術（2/3）



ソフトウェア設計・検証技術（3/3）• ソフトウェアテスト技術

– 効果的・効率的で網羅性の⾼いソフトウェアテストを実現するための技術。設計プロセスとテストプロセスを並⾏で進めるWモデルで開発を進め、テスト設計とテスト管理により、上流から下流までを通して品質の作り込みを実現する。



目次





2. テスト技術


• 知識の体系と現実とのギャップがあり、どういうテストをすれば効果が上がるかがわからないので、体系的なテストを構成できず、不具合を⾒逃す– テスト設計技術

• テストの実施状況や計画とのズレが即時に把握できず、混沌としているため、有効な手が打てず、後手後手に回る– テスト管理技術

テスト技術の基本方針

サイエンスサイエンスサイエンスサイエンスにににによる知的ものづくり教育プログラムよる知的ものづくり教育プログラムよる知的ものづくり教育プログラムよる知的ものづくり教育プログラムトップトップトップトップエスエスエスエスイーイーイーイー

「テスティング（基礎）」、「テスティング（基礎）」、「テスティング（基礎）」、「テスティング（基礎）」、「「「「テスティング（応用）」テスティング（応用）」テスティング（応用）」テスティング（応用）」のののの提供提供提供提供

テスト設計手法

テストケース

生成支援ツール

APTNavi

テスト管理システム

TETRAPLUS


目次





2. テスト技術


‧何をどこまでやるかを決める何をどこまでやるかを決める何をどこまでやるかを決める何をどこまでやるかを決める

‧どんなバグに注力するかを決めるどんなバグに注力するかを決めるどんなバグに注力するかを決めるどんなバグに注力するかを決める

‧どんなテストを行どんなテストを行どんなテストを行どんなテストを行

うかを決めるうかを決めるうかを決めるうかを決める

‧テストの構成をテストの構成をテストの構成をテストの構成を

決める決める決める決める

テスト戦略

テスト設計手法の全体像とテスト設計の位置付け


• テストアーキテクチャが満たすべき要件– テストの全体構造が分かる– 個々のテストの目的が分かる

• テストアーキテクチャを表す図– テスト設計手法で提案している記述方法

LTMap(Layer Tier Map)

テストの目的が分かる

TRMap(Test Relation Map)

テストの全体構造が分かる

テストアーキテクチャ


テスト設計手法をサポートするエディタ

複数の複数の複数の複数のLTMap、、、、TRMapを同時に表示を同時に表示を同時に表示を同時に表示

ドラッグ＆ドロップドラッグ＆ドロップドラッグ＆ドロップドラッグ＆ドロップ

による直感点なテストによる直感点なテストによる直感点なテストによる直感点なテスト

仕様の追加仕様の追加仕様の追加仕様の追加

複数の複数の複数の複数のLTMap間での間での間での間での

座標の同期座標の同期座標の同期座標の同期

マップ上のテスト仕様マップ上のテスト仕様マップ上のテスト仕様マップ上のテスト仕様

を自動整列を自動整列を自動整列を自動整列

テスト管理システムテスト管理システムテスト管理システムテスト管理システム

TETRAPLUSと類似と類似と類似と類似

した画面した画面した画面した画面レイアウトレイアウトレイアウトレイアウトアンドゥアンドゥアンドゥアンドゥ

CSVファイルのファイルのファイルのファイルの

インポートインポートインポートインポート

エクスポートエクスポートエクスポートエクスポート

作成した作成した作成した作成したLTMap、、、、TRMapを画像としてを画像としてを画像としてを画像として

ダウンロードダウンロードダウンロードダウンロード


適用結果（1/2）• 電⼦デバイス系テストケース新規作成の事例

– テスト対象の設計が十分に進んでいない段階で本手法を利⽤（テスト設計のフロントローディング）

– テストのツリー構造を作成していくことで、テストの観点から注⼒すべきテストを洗い出した– 機能的な確認項目以外に、特に設計が複雑でバグ残存リスクの⾼い資源競合のテスト

を重点的に手厚く実施するテストアーキテクチャを示した


適用結果（2/2）• 社会インフラ系システムの既存のテストケースの分析の事例

– 派生開発によって蓄積してきたテストケースの中で削減できるところはないかを分析

– 品質重視のシステムであるため、仕様変更や追加によってテストが新たに加えられ続け、似たようなテストケースで重複感はあるがなかなか削減しにくく、テストケース数が多くなり過ぎていた

– 既存のテストケースを二軸のポジショニング図に配置• 初期分析として、縦軸がテスト対象の⼤きさ、横軸が要求の⼤きさを使った図と、縦軸は同じで、

横軸がテスト環境を使った図の二つの図を作成• これによって、既存のテストケースの概略特性を把握• 更に、テストケースの内容を詳細に分析し、縦軸がタスク名、横軸が機能名の図、などを⽤いて各

テストケースの特性のポジショニングを確定– 各テストケースのポジショニングを図示することによって、テストが重複しているかを

客観的に示すことができた• 数千のテストケースの中で2割程度に重複があったと分析できた• すべての重複を避けることが賢明なわけではなく、ある程度重複は許してリスクを削減することも重

要である。


目次





2. テスト技術


直交表を利用したソフトウェアテストの例• テストケースの数を合理的に減ら

し、効率化を⾏う

A B C D

1 1 1 1 1

2 1 2 2 2

3 1 3 3 3

4 2 1 2 3

5 2 2 3 1

6 2 3 1 2

7 3 1 3 2

8 3 2 1 3

9 3 3 2 1

L9直交表

因子

水準

原稿用紙分割カラー

1 A4 A4 なし白黒

2 A4 A3 2分割グレー

3 A4 B5 4分割カラー

4 A3 A4 2分割カラー

5 A3 A3 4分割白黒

6 A3 B5 なしグレー

7 B5 A4 4分割グレー

8 B5 A3 なしカラー

9 B5 B5 2分割白黒

因子

原稿 A4 A3 B5

用紙 A4 A3 B5

分割なし 2分割 4分割

カラー白黒グレーカラー

水準

81件

9件


テストケース⽣成支援ツールAPTNavi®� 「エイピーティーナビ」�All-Pair Testing Navigation Tool�バージョン v3.12

�直交表、All-pair法に基づく組み合わせテスト技術（ペア構成テスト）を利用したソフトウェアテストを支援するためのExcelマクロ（『APTNavi®マクロ』）

�付属マクロとして『直交表⽣成マクロ v2.0』も提供� 31種類の直交表テンプレートの生成� 最適直交表の⾃動選択可（⼀部追加法の利⽤も考慮）

� v3.0からは『 PICT連携 for APTNavi® 』マクロも提供


ツールによるペア構成テストの実現�APTNavi®では、2因⼦間のすべての組み合わ

せを⾒つける方法として「直交表」と「All-pair法のアルゴリズム」を採用�直交表の3因子間の組み合わせも平均的に出る

（偏りがない）という特徴を利⽤しつつテストケースがより少なくなるようにAll-pair法のアルゴリズムの中に採⽤


APTNavi®マクロ• 2機能間の動作を保証するためのテストケースを⽣成

– テストケース生成（直交表、All-pair法）– 禁則（ありえない組合せ）の回避– 網羅度算出（２因子間、３因子間）

禁則設定禁則設定禁則設定禁則設定テストケース生成テストケース生成テストケース生成テストケース生成

メニューメニューメニューメニュー

因子・水準の洗い出し因子・水準の洗い出し因子・水準の洗い出し因子・水準の洗い出し


APTNavi®を使う利点�2因⼦間の組み合わせを網羅するテストケース作成が容易

� 効率よいテストの実施� 想定していない組み合わせで不具合を発⾒することも

�2因⼦間、３因⼦間網羅度をすぐに計算�禁則がある場合の対応が容易

� 禁則が多々あるとこれを回避してテストケースを作成するのは人手だと煩雑�直交表、All-pair法の知識がなくてもテストケースの作成が可能

� ⼀方で危険（単に禁則を回避して２因子網羅の組合せを出しているだけ…）、目的にあった使い方になっているか？

� 上記手法を理解した上で使⽤することを推奨


直交表⽣成マクロ• 2水準から17水準ま

で扱えるL4からL289までの31種類の直交表テンプレート（Excel）を⽣成

• それぞれの水準の数から最適な直交表テンプレートを自動選択


東芝メディカルシステムズ事例• 検体検査システム事業部検体検査システム開発部にて『検体検

査システム（臨床化学自動分析装置）』の開発に適用

ソフトウェア品質シンポジウム

2011で発表を行い、SQiP Effective Awardを受賞

http://www.juse.or.jp/download/software/sqip2011/B3-1.pdfhttp://www.juse.or.jp/download/software/sqip2011/B3-1P.pdf


検体検査システム開発部での導入・推進の取り組み

2006年度年度年度年度 2007年度年度年度年度 2008年度年度年度年度 2009年度年度年度年度 2010年度年度年度年度

第1弾トライアル活動



直交表を利用したソ

フトウェアテストの導

入可否の検討・評価、

プロセス整備

抜け漏れ防止

による品質向

上、効率化によ

る工数削減の

ための実製品

への適用（All-Pair法導入）

開発コスト削減、

品質向上を目

的とした上流設

計への組み合

わせテスト技術

の適用の検討

テ

ス

ト

入

門

教

育

開

催


検体検査システム開発部での活動成果の⼀例�品質保証のためのテストとして継続して活用�上流設計への適用においては、仕様検討・設計の段階で仕様の

未決定箇所、仕様の理解不⾜、コーディングミスの問題を発⾒でき、後戻り工数の削減� 過去の実績から効果を推定すると問題1件あたり40Hの後戻り工数の削減が

⾒込まれ、320Hの工数削減の効果

�導入に伴い、組み合わせテスト技術だけでなく、担当者のテストに関する意識（テスト計画、テスト設計の必要性の認識）が変わった

仕様の理解不足仕様の未決定箇所コーディングミス

キャリブレーション測定 2件 2件 3件

コントロール測定 0件 0件 1件


目次





2. テスト技術


テスト管理システムTETRAPLUSの概要

テストの

レポート生成

テスト管理技術をツール化テスト管理技術をツール化テスト管理技術をツール化テスト管理技術をツール化

テスト関連情報の共有を促進テスト関連情報の共有を促進テスト関連情報の共有を促進テスト関連情報の共有を促進テスト自体の質テスト自体の質テスト自体の質テスト自体の質を改善を改善を改善を改善

テスト仕様テスト結果

Excel

テスト進捗グラフ

テスト実施カレンダー

累積不合格 &

信頼度推定グラフ

テスト実施サマリー

Excel

テストの実施

状況を複数の

ビューで可視化

サマリーを表示し

状況を把握

テスト項目を

ツリー表示し

全体像を把握

テスト結果やテスト結果やテスト結果やテスト結果や

信頼度推定グラフ信頼度推定グラフ信頼度推定グラフ信頼度推定グラフ

からからからから総合的総合的総合的総合的に判断に判断に判断に判断

テスト情報のテスト情報のテスト情報のテスト情報の集約集約集約集約とととと

可視化可視化可視化可視化による状況のによる状況のによる状況のによる状況の

共有共有共有共有


リグレッションテストへの適用

分類テストID

バージョン1 2 3 4 5 6 7 8 9 10 11 … n

新規機能1 ○2 ○ ○: × ○

基本機能

500 × ○ × ×501 ○ ○502 × ○

： ○ × ○ ○

*****

2000 ○2001 × ○ ○： ○

限界2800 ○： ○ × ○ ○

障害2900 ○ ○： ○ ○

数ヶ月の期間におけるテストの実施順序を計画

デグレード：変更によりそれまで正しく動作していた機能に予想外に悪影響を与え不合格となること

デグレード

⼀度合格になっても、他の修正などの影響でデグレードが発生している可能性もある

○：合格、×：不合格、ブランク：テスト未実施

リグレッションテスト

目的目的目的目的

・デグレードが発生して

いないことを確認

5分10分

3分


リグレッションテスト実施上の制約と解決する課題• リグレッションテスト実施上の制約

– テストで使える時間は限られている

– すべてをテストすることはできない• 解決する課題

– 開発において蓄積された客観性の⾼いデータから、デグレードが発生しそうなテストを効果的に選択する

⼤量のテスト項目の中から

テストの実施結果を利⽤して

デグレードが発生しそうなテストを選択する


テストの価値の考え方と算出方法• テストの価値

– ①：過去に不合格（×）となった割合• 過去に不合格となったテストは品質上不安があり、再実⾏の価値がある

– ②：最後に実⾏してから未実⾏となっているバージョン数• 他のテストで検出された不具合の修正などによりデグレードが起こっていないか確認す

る価値がある• 算出方法

テストID

バージョンテストの価値① テストの価値②

1 2 3 4 5 61 × ○ ○ 1/3 02 ○ ○ 0 33 ○ × ○ 1/3 0: × × ○ 2/3 1n ○ ○ 0 0


テスト選択手法• 各テストでデグレードが検出できる度合い →• を実施するための工数 →• をテスト実施するかどうか →【目的関数】

【制約条件】テストに使える工数

( )itD

( )itC

0or1=ix

it

it

it

かつ、A を選択⇔ かつ

⇒

∑=

⋅N

iii xtD

1

)(

LxtC i

N

ii ≤⋅∑

=1

)(

テスト間の関係をどのように定義すればよいか？


テスト技術のまとめ

テスト設計技術

テスト設計手法を提供（テストの取捨選択）

バグを狙い撃てるテストの資産

ノウハウ

バグを狙ったテスト

•戦略重視•テストアーキテクチャ図• Wモデル

•テスト結果の集計と可視化•予実管理•テスト推薦機能（テスト結果の分析に繋がる）

テスト管理技術

テストをやりっぱなしにしない（テスト管理）


1. 久連⽯圭、河村透、⼩笠原秀人、佐々⽊愛美：テスト管理システムを⽤いたテスト状況の可視化方法の提案、情報処理学会第73回全国⼤会、2011.

2. ⼩笠原秀人、河村透、久連⽯圭、佐々⽊愛美：導⼊容易なテスト管理システムの開発とその適⽤効果、第31回ソフトウェア・シンポジウム(SS2011)、2011.

3. 鷲⾒毅、加瀬直樹、市⽥憲明、⼩笠原秀人：テスト設計手法PROST!、第10回情報科学技術フォーラム(FIT2011)、2011.4. 中野隆司、⼩笠原秀人、松本智司：組み合わせテスト技術の導⼊・定着への取り組み、および上流設計への適⽤検討の事例、ソフトウ

ェア品質シンポジウム2011(SQiP2011).5. 市⽥憲明, 鷲⾒毅, 加瀬直樹, ⼩笠原秀人: PROST!の⼤規模テストへの適⽤ –テストアーキテクチャ設計工数をいかに削減するか–,

ソフトウェアテストシンポジウム2012(JaSST2012).6. 佐々⽊愛美, 河村透, ⼩笠原秀人: テスト結果の履歴情報を⽤いたテスト項目間の関連抽出手法の提案, 情報処理学会第74回全

国⼤会, 2012.7. ⼩笠原秀人, 加瀬直樹, 鷲⾒毅, 市⽥憲明: テスト設計手法PROST!の提案と実践, 第32回ソフトウェア・シンポジウム(SS2012).8. Noriaki Ichida, Takeshi Sumi, Hideto Ogasawara : A method of making single function tests for constituting

senario tests, ICST2013, 2013.9. ⼩笠原秀人、佐々⽊愛美、阿萬裕久：数理計画モデルに基づいた効果的なテスト選択手法の提案と実践、第33回ソフトウェア・シンポ

ジウム(SS2013).10. Hirohisa Aman, Manami Sasaki, Hideto Ogasawara: Application of the 0-1 Programming Model for Cost-

Effective Regression Test, 2013 IEEE 37th Annual Computer Software and Applications Conference.

＜東芝レビュー＞1. ⼩笠原秀人、中野隆司、⼤⾕和夫：組合せ技術を利⽤したソフトウェアテスト、東芝レビュー Vol.64 No.4、2009.2. 河村透、⼩笠原秀人：ソフトウェアのテスト管理システム、東芝レビュー Vol 66 No.1、2011.3. 加瀬直樹、鷲⾒毅、市⽥憲明：ソフトウェアのテスト設計手法、東芝レビュー Vol 67 No.6、2012.

参考文献

東芝における ソフトウェア厍拾匇上に匇けた勚り匢 …© 2013 toshiba...

Documents

東芝におけるソフトウェア厍拾匇上に匇けた勚り匢 …© 2013 toshiba...