「組合せテスト向けの因子分類」を活用したSW設計の革新

SS2014
ソフトウェア設計における
「組合せテスト向けの因子分類」の活用について
2014年6月10日
SS開発本部／秋山浩一
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
目次
1. 因子分類方法の整理
① 要因分析技法
② HAYST法
③ タグチメソッド
2. ソフトウェア設計に因子の種別を活用する方法
① 考え方
② プロセス
③ 適用結果
④ 考察と今後の展望
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
1
1. 因子分類方法の整理
① 要因分析技法
② HAYST法
③ タグチメソッド
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
2
① 要因分析技法
1980年代
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
3
①要因分析技法
概要
• 1984年（30年前！）
• 富士通
辰巳敬三氏ら
• 直交表を用いた組合せテストで「外部仕様のテスト（入出力関係をブラックボックステスト）」を因子（結果
に影響する入力：例えば投入金額）・水準（因子が取り得る状態：10円，100円など）で整理した
4つの観点
① 機能の観点（外部機能からコマンド，オペランドの入力方法，形式などを入力の因子としている）
② 環境の観点（ハード構成/種別，サブシステム，ファイルなどを状態の因子し＝環境因子としている）
③ 結果の観点（帳票出力，画面表示結果，表示メッセージなどを分析している）
④ その他の観点（互換性/整合性/負荷などを分析している）
要因分析表（何を組み合わせるかの分析）
• 上記4つの観点のうち1番目と2番目を用いて，
「因子・水準（因子の状態）」の表を作成
• 要因分析表の因子・水準を直交表に
割りつけて組合せテストを実施
（組み合わせる仕組みは直交表にこだわらない）
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
4
② ＨＡＹＳＴ法
2000年代
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
5
②ＨＡＹＳＴ法
概要
• 2003年品質工学会で社外発表（11年前！），2007年7月（書籍）『ソフトウェアテストHAYST法入門』，
2014年7月（書籍）『事例とツールで学ぶHAYST法』
• 富士ゼロックス吉澤正孝氏，秋山浩一，山本訓稔氏ら
• 2水準系直交表をベースとしたソフトウェアの組合せテスト
（「多因子：300程度・多水準：64水準・複雑な禁則」を取り扱える）
設計の6つの観点（＋お客様の6W2Hの視点：When, Where, Who, What, Why, Whom, How, How much）
①
②
③
④
⑤
⑥
入力の観点（エンドユーザーが最終的に機能を動作させるときに入力する操作を入力因子としている）
ノイズの観点（ソフトウェア提供者が指定できない環境要因・負荷等を調合誤差因子としている）
アクティブノイズの観点（エンドユーザーのいたずらや犯罪行為を誤差因子としている）
出力の観点（ユーザーが得る結果を漏れなく挙げて分析している）
内部状態の観点（入力後にシステムが読み書きするデータベースや内部変数を状態因子としている）
システム定数の観点（設計者が決定する定数．コンパイル時に決定し，通常，エンドユーザーは変更しない）
ラルフチャート（テスト設計で使用する）
• 上記6つの観点のうちテストで使用する
1～5を整理する図
• 6は参考情報の位置づけ
FL表
ノイズ
誤差因子
z {z 1 , z 2 , z 3 ・・・}
FL表（Factor Level table）
• 因子（Factor）と水準（Level）を
整理した表
• 要因分析表と同じもの（行と列は逆に
して多因子を書きやすくした．
水準はせいぜい64個）
入力
信号因子
M {M 1 , M 2 , M 3 ,…}
出力
y
(レスポンス)
対
象
read
write
内部変数の組合せ（＝状態）
信号因子 m {m 1 , m 2 , m 3 ,…}
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
6
因
子
水
準1
水
準2
水
準3
A
a1
a2
A3
B
b1
b2
C
c1
c2
C3
D
d1
d2
D3
水
準4
C4
③ タグチメソッド
1950年代～1990年代
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
7
③タグチメソッド
概要
• 1950年代～1990年代
設計にも
使っている
• 田口玄一氏
• 直交表を用いた“ハードウェア”の設計と実験計画法による評価
4つの観点（因子種別）
① ユーザー要求の観点（ユーザーの入力を“信号因子”としている）
② 使用条件の観点（環境など，開発側で制御できない要因を“誤差因子（ノイズ）”としている）
③ 設計の観点（設計するときに決める定数を“制御因子”としている）
④ 出力の観点（信号のエネルギーがノイズに邪魔されても伝わって，出力のエネルギーにどれだけ変わるか）
ＳＮ比
• ノイズ（誤差因子：出力に寄与して
ノイズ
ノイズ
ほしくない要因）があっても
（②誤差因子）
（②誤差因子）
シグナル（信号因子：出力に寄与して
Noise
Noise
ほしい要因）が伝わるように
【電話】もしもし
【交換機】設計
【電話】もしもし
（＝ SN比が最高になるように）
（①信号因子）
（③制御因子）
（出力）
設計（制御因子の決定）をする
Signal
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
8
因子種別のまとめ
要因分析法，HAYST法，タグチメソッド
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
9
因子種別のまとめ
設
テ
テ
テ
設計へ活用
区別せず
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
10
2. ソフトウェア設計に因子の種別を活用する方法
①
②
③
④
考え方
プロセス
適用結果
考察と今後の展望
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
11
① 考え方
ソフトウェア設計と制御因子
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
12
ソフトウェア設計に因子の種別を活用する考え方
考え方（アイデア）
• ハードウェア（タグチメソッド）で使用している制御因子が使えそう
• 制御因子とは「設計者が自由に水準を決定し最適条件を求める因子（設計条件）」
• ソフトウェアテストでは使っていなかった＠HAYST法（恐らく要因効果分析法でも）
理由：コンパイルが終わった，テストの段階では定数（固定値）なので組合せ表に割り付ける必要が無いから
制御因子の具体例
•
–
–
–
–
–
–
TCP/IPのパフォーマンスを左右する定数にRwiｎ値
RWin値：何バイト受信したら受信確認を送信側に送るかの定数
低速・低品質な通信回線 → 再送信の必要性に早く気が付くように小さめの値
高速・高品質な通信回線 → （正常）受信確認がパフォーマンスを落とす
そこで開発者はRWin値を65700バイト（Windows７では）に固定
Windows 98： 8192，Me/2000のRwin値のデフォルトは，16384以下．XPで，17520バイト
RWin値のような設計者が決める設計条件のことを制御因子と呼ぶ
「設計時に設計に必要な制御因子を考えるとよいのではないか」（テスト後にRWin値に気づくのではな
く．恐らくXPまでは，リリース後に問題に気づき“驚速ｘｘ”が生まれた！？）
解決したい問題
• 現状：テスト時に問題（主にパフォーマンス問題）に気づくが機構として入っていないため，修正できない．
仕方がないのでユニットテストなど，早期のテストで性能確認を無理やり実施
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
13
② 提案プロセス
従来のプロセスのどこをどう変えるか
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
14
従来のプロセス v. s.
提案プロセス
＜従来のプロセス＞
＜提案プロセス＞
① 機能を設計する
① 機能を設計するときに性能を左右する制御因
子について十分検討する（レビューなど）
→ 「アイデアを制御因子に盛り込む」
② 性能などの「あとで問題が見つかっても直す
のに時間のかかる非機能」について前倒しで
テストする．
本来は本番環境のシステム上で測定する方が
効率は良い.
② 性能などは，バグだしのテストではなく本番
環境でパフォーマンス値を計測するだけのテ
ストとする
③ 上記②で問題が出たら再設計する
※
※ ②のテストについては問題が出なければ無駄
な工程
※ 性能の他にも“スケールアウト”など（サー
バー数を増やすと同時接続数などのサービス
レベルがあがるといった効果が出ないなど），
この手の問題が増加傾向にある
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
15
①でどのような「制御因子」を検討するかが
かぎである（次項の適用結果で述べる）
オッカムの剃刀：必要が無いなら多くの
ものを定立してはならない。少数の論理
でよい場合は多数の論理を定立してはな
らない。
上記原理・原則に反するのでは？？
【“Simple” is “best”.】
【決定を遅らせろ】by リーン開発
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
16
オッカムの剃刀：必要が無いなら多く
のものを定立してはならない。少数の
論理でよい場合は多数の論理を定立し
てはならない。
上記原理・原則に反するのでは？？
【んでね】（反しません）
上記は「曖昧な要求は実装を渋れ」と
いうことだから
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
17
③ 適用結果
 ソフトウェアにおける制御因子のパターンと効果
 バッファサイズ
 まびき量
 スケールアウト
 バージョン
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
18
ソフトウェアにおける制御因子の5つのパターン
バッファサイズ
• 特徴：同じ機能を持っていてもハードウェア装置ごとに最適値が異なる
• 事例：スキャナで何ページ分の読み取りバッファがあるか
• 適用：データの大きさと，そのばらつきを考慮して実験計画法で最適値を決定した
まびき量（サンプリング量）
• 特徴：使用条件によって最適値が異なる
• 事例：Rwin値，最新ログをいくつ保存するか
• 適用：サービスエンジニアがカスタマイズ出来るようにした
スケールアウト
• 特徴：運用中にサーバーを買い足すことでサービスレベルの向上を実現する
• 事例：ウェブ用のアプリサーバー買い足し
• 適用：レビューでスケールアウトするための制御因子があることを確認
• 効果：声「従来であれば，ユーザーが自らハードウェアのグレードアップやサーバーの増加を行ったのちに期待したほどの効果が得
られず，クレームとして要求が来そうな設計上の問題を事前に設計で抑え込めて2度手間にならずに助かった」
バージョン
• 特徴：一見，機能に影響無さそうに見えるがインストーラに影響
• 事例：ツールのバージョン
• 適用：適切な互換性と，必要最小限なファイルコピー
禁則フラグ
• 特徴：機能の動作を禁止する
• 事例：試用版，ローカライズ
• 適用：ミスの低減
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
19
④考察と今後の展望
成果と考察
今後の展望
 制御因子パターンの拡充
 設計条件の決定方法の効率化
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
20
成果と考察
成果
• コンポーネントテストと統合テストにおけるパフォーマンステストが
50%削減（従来100時間→今回50時間）
• 「制御因子」の活用パターンを示すことで比較的容易に設計改善ができる
ことが分かった
考察（半減した理由）
• 従来は，リリース直前のシステムテストレベルで見つかってもパフォーマンスは
改善できないので，コンポーネントテストレベルや統合テストレベルでもパ
フォーマンスのテストを「無理やり」していていた
• コンポーネントテストレベルや統合テストレベルでのパフォーマンスのテストの
目的や実施内容，目標値が明確になったから
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
21
今後の展望
① 制御因子パターンの拡充
• ユーザークレームから制御因子の考慮不足パターンに起因する問題をピッ
クアップして，制御因子パターンの拡充を行いより設計時に設計条件の充
実を図る
① 設計条件の決定方法の効率化
• 設計条件（制御因子の水準の最適値）を効率よく決定する方法を考える
• 内部状態を保持する「状態因子」の共有状況について，複数のラルフ
チャートを組み合わせることによって，共有リソース問題や，派生開発時
の影響度分析の効率化を行う
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
22
Xerox，Xeroxロゴ，およびFuji Xeroxロゴは，米国ゼロックス社の登録商標または商標です．

Download Report