20140610 秋山-ss2014

SS2014
SS開発本部／秋山浩一
2014年6月10日
© 2014 Fuji Xerox Co., Ltd. All rights reserved.
ソフトウェア設計における
「組合せテスト向けの因子分類」の活用について

目次
1. 因子分類方法の整理
① 要因分析技法
② HAYST法
③ タグチメソッド
2. ソフトウェア設計に因子の種別を活用する方法
① 考え方
② プロセス
③ 適用結果
④ 考察と今後の展望
1© 2014 Fuji Xerox Co., Ltd. All rights reserved.

② HAYST法
1. 因子分類方法の整理

1980年代

© 2014 Fuji Xerox Co., Ltd. All rights reserved. 4
概要
• 1984年（30年前！）
• 富士通辰巳敬三氏ら
• 直交表を用いた組合せテストで「外部仕様のテスト（入出力関係をブラックボックステスト）」を因子（結果
に影響する入力：例えば投入金額）・水準（因子が取り得る状態：10円，100円など）で整理した
4つの観点
① 機能の観点（外部機能からコマンド，オペランドの入力方法，形式などを入力の因子としている）
② 環境の観点（ハード構成/種別，サブシステム，ファイルなどを状態の因子し＝環境因子としている）
③ 結果の観点（帳票出力，画面表示結果，表示メッセージなどを分析している）
④ その他の観点（互換性/整合性/負荷などを分析している）
要因分析表（何を組み合わせるかの分析）
• 上記4つの観点のうち1番目と2番目を用いて，
「因子・水準（因子の状態）」の表を作成
• 要因分析表の因子・水準を直交表に
割りつけて組合せテストを実施
（組み合わせる仕組みは直交表にこだわらない）
①要因分析技法

② ＨＡＹＳＴ法
2000年代

入力
信号因子
M {M1, M2, M3,…}
出力
y
(レスポンス)
ノイズ
誤差因子
z {z1, z2, z3 ・・・}
対
象
read write
内部変数の組合せ（＝状態）
信号因子 m {m1, m2, m3 ,…}
概要
• 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表（Factor Level table）
• 因子（Factor）と水準（Level）を
整理した表
• 要因分析表と同じもの（行と列は逆に
して多因子を書きやすくした．
水準はせいぜい64個）
②ＨＡＹＳＴ法
因
子
水
準1
水
準2
水
準3
水
準4
A a1 a2 A3
B b1 b2
C c1 c2 C3 C4
D d1 d2 D3
FL表

1950年代～1990年代

設計にも
使っている
概要
• 1950年代～1990年代
• 田口玄一氏
• 直交表を用いた“ハードウェア”の設計と実験計画法による評価
4つの観点（因子種別）
① ユーザー要求の観点（ユーザーの入力を“信号因子”としている）
② 使用条件の観点（環境など，開発側で制御できない要因を“誤差因子（ノイズ）”としている）
③ 設計の観点（設計するときに決める定数を“制御因子”としている）
④ 出力の観点（信号のエネルギーがノイズに邪魔されても伝わって，出力のエネルギーにどれだけ変わるか）
ＳＮ比
• ノイズ（誤差因子：出力に寄与して
ほしくない要因）があっても
シグナル（信号因子：出力に寄与して
ほしい要因）が伝わるように
（＝ SN比が最高になるように）
設計（制御因子の決定）をする
③タグチメソッド
【電話】もしもし
（①信号因子）
Signal
【電話】もしもし
（出力）
【交換機】設計
（③制御因子）
ノイズ
（②誤差因子）
Noise
ノイズ
（②誤差因子）
Noise

因子種別のまとめ
要因分析法，HAYST法，タグチメソッド

因子種別のまとめ
設計へ活用
区別せず
設
テテテ

① 考え方
② プロセス
③ 適用結果
④ 考察と今後の展望
2. ソフトウェア設計に因子の種別を活用する方法

① 考え方
ソフトウェア設計と制御因子

考え方（アイデア）
• ハードウェア（タグチメソッド）で使用している制御因子が使えそう
• 制御因子とは「設計者が自由に水準を決定し最適条件を求める因子（設計条件）」
• ソフトウェアテストでは使っていなかった＠HAYST法（恐らく要因効果分析法でも）
理由：コンパイルが終わった，テストの段階では定数（固定値）なので組合せ表に割り付ける必要が無いから
制御因子の具体例
• TCP/IPのパフォーマンスを左右する定数にRwiｎ値
– RWin値：何バイト受信したら受信確認を送信側に送るかの定数
– 低速・低品質な通信回線 → 再送信の必要性に早く気が付くように小さめの値
– 高速・高品質な通信回線 → （正常）受信確認がパフォーマンスを落とす
– そこで開発者はRWin値を65700バイト（Windows７では）に固定
Windows 98： 8192，Me/2000のRwin値のデフォルトは，16384以下．XPで，17520バイト
– RWin値のような設計者が決める設計条件のことを制御因子と呼ぶ
– 「設計時に設計に必要な制御因子を考えるとよいのではないか」（テスト後にRWin値に気づくのではな
く．恐らくXPまでは，リリース後に問題に気づき“驚速ｘｘ”が生まれた！？）
解決したい問題
• 現状：テスト時に問題（主にパフォーマンス問題）に気づくが機構として入っていないため，修正できない．
仕方がないのでユニットテストなど，早期のテストで性能確認を無理やり実施
ソフトウェア設計に因子の種別を活用する考え方

② 提案プロセス
従来のプロセスのどこをどう変えるか

＜従来のプロセス＞
① 機能を設計する
② 性能などの「あとで問題が見つかっても直す
のに時間のかかる非機能」について前倒しで
テストする．
本来は本番環境のシステム上で測定する方が
効率は良い.
③ 上記②で問題が出たら再設計する
※ ②のテストについては問題が出なければ無駄
な工程
※ 性能の他にも“スケールアウト”など（サーバー
数を増やすと同時接続数などのサービスレベ
ルがあがるといった効果が出ないなど），こ
の手の問題が増加傾向にある
＜提案プロセス＞
① 機能を設計するときに性能を左右する制御因
子について十分検討する（レビューなど）
→ 「アイデアを制御因子に盛り込む」
② 性能などは，バグだしのテストではなく本番
環境でパフォーマンス値を計測するだけのテ
ストとする
※ ①でどのような「制御因子」を検討するかが
かぎである（次項の適用結果で述べる）
従来のプロセス v. s. 提案プロセス

オッカムの剃刀：必要が無いなら多くの
ものを定立してはならない。少数の論理
でよい場合は多数の論理を定立してはな
らない。
上記原理・原則に反するのでは？？
【“Simple” is “best”.】
【決定を遅らせろ】by リーン開発

オッカムの剃刀：必要が無いなら多く
のものを定立してはならない。少数の
論理でよい場合は多数の論理を定立し
てはならない。
上記原理・原則に反するのでは？？
【んでね】（反しません）
上記は「曖昧な要求は実装を渋れ」と
いうことだから

③ 適用結果
 ソフトウェアにおける制御因子のパターンと効果
 バッファサイズ
 まびき量
 スケールアウト
 バージョン

バッファサイズ
• 特徴：同じ機能を持っていてもハードウェア装置ごとに最適値が異なる
• 事例：スキャナで何ページ分の読み取りバッファがあるか
• 適用：データの大きさと，そのばらつきを考慮して実験計画法で最適値を決定した
まびき量（サンプリング量）
• 特徴：使用条件によって最適値が異なる
• 事例：Rwin値，最新ログをいくつ保存するか
• 適用：サービスエンジニアがカスタマイズ出来るようにした
スケールアウト
• 特徴：運用中にサーバーを買い足すことでサービスレベルの向上を実現する
• 事例：ウェブ用のアプリサーバー買い足し
• 適用：レビューでスケールアウトするための制御因子があることを確認
• 効果：声「従来であれば，ユーザーが自らハードウェアのグレードアップやサーバーの増加を行ったのちに期待したほどの効果が得
られず，クレームとして要求が来そうな設計上の問題を事前に設計で抑え込めて2度手間にならずに助かった」
バージョン
• 特徴：一見，機能に影響無さそうに見えるがインストーラに影響
• 事例：ツールのバージョン
• 適用：適切な互換性と，必要最小限なファイルコピー
禁則フラグ
• 特徴：機能の動作を禁止する
• 事例：試用版，ローカライズ
• 適用：ミスの低減
ソフトウェアにおける制御因子の5つのパターン

④考察と今後の展望
成果と考察
今後の展望
 制御因子パターンの拡充
 設計条件の決定方法の効率化

成果
• コンポーネントテストと統合テストにおけるパフォーマンステストが50%
削減（従来100時間→今回50時間）
• 「制御因子」の活用パターンを示すことで比較的容易に設計改善ができる
ことが分かった
考察（半減した理由）
• 従来は，リリース直前のシステムテストレベルで見つかってもパフォーマンスは
改善できないので，コンポーネントテストレベルや統合テストレベルでもパ
フォーマンスのテストを「無理やり」していていた
• コンポーネントテストレベルや統合テストレベルでのパフォーマンスのテストの
目的や実施内容，目標値が明確になったから
成果と考察

①制御因子パターンの拡充
• ユーザークレームから制御因子の考慮不足パターンに起因する問題をピッ
クアップして，制御因子パターンの拡充を行いより設計時に設計条件の充
実を図る
①設計条件の決定方法の効率化
• 設計条件（制御因子の水準の最適値）を効率よく決定する方法を考える
• 内部状態を保持する「状態因子」の共有状況について，複数のラルフ
チャートを組み合わせることによって，共有リソース問題や，派生開発時
の影響度分析の効率化を行う
今後の展望

Xerox，Xeroxロゴ，およびFuji Xeroxロゴは，米国ゼロックス社の登録商標または商標です．

20140610 秋山-ss2014

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Viewers also liked

Viewers also liked (7)

Similar to 20140610 秋山-ss2014

Similar to 20140610 秋山-ss2014 (20)

More from Kouichi Akiyama

More from Kouichi Akiyama (15)

20140610 秋山-ss2014