20140610 秋山-ss2014

SS2014

SS 開発本部／秋山浩一

2014 年 6 月 10 日

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

ソフトウェア設計における「組合せテスト向けの因子分類」の活用について

目次

1. 因子分類方法の整理①. 要因分析技法②. HAYST 法③. タグチメソッド

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

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

① 要因分析技法② HAYST 法③ タグチメソッド

1. 因子分類方法の整理


① 要因分析技法

1980 年代



概要• 1984 年（ 30 年前！）• 富士通　辰巳敬三氏ら• 直交表を用いた組合せテストで「外部仕様のテスト（入出力関係をブラックボックステスト）」を因子（結

果に影響する入力：例えば投入金額）・水準（因子が取り得る状態： 10 円， 100 円など）で整理した

4 つの観点① 機能の観点（外部機能からコマンド，オペランドの入力方法，形式などを入力の因子としている）

② 環境の観点（ハード構成 / 種別，サブシステム，ファイルなどを状態の因子し＝環境因子としている）

③ 結果の観点（帳票出力，画面表示結果，表示メッセージなどを分析している）

④ その他の観点（互換性 / 整合性 / 負荷などを分析している）

要因分析表（何を組み合わせるかの分析）• 上記 4 つの観点のうち 1 番目と 2 番目を用いて，

「因子・水準（因子の状態）」の表を作成• 要因分析表の因子・水準を直交表に

割りつけて組合せテストを実施（組み合わせる仕組みは直交表にこだわらない）

① 要因分析技法

② ＨＡＹＳＴ法

2000 年代


© 2014 Fuji Xerox Co., Ltd. All rights reserved. 7

入力信号因子

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 年代


9

設計にも使っている

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

概要• 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

Documents