ソフトウェア設計における「組合せテスト向けの因子分類」の活用について
秋山 浩一
富士ゼロックス株式会社
ソリューション・サービス開発本部 / ソリューションプロジェクトマネジメント部
要旨
機能の組合せを確認するソフトウェアテストにおいて，
何の因子を組み合わせるべきかを分析することは重要な
技術として認識されており，1980 年代には要因分析技法
（富士通）としてまとめられていた．[1]
また，直交表をベースとした組合せテスト技法のひと
つである HAYST 法では 2007 年にラルフチャートを用い
た目的機能の分析と図化を提案している．[2]
しかし，これらの因子分類や図化はあくまでも組合せ
テストで組み合わせるべき因子の抜け漏れを防止するこ
とが目的であり，開発・設計での活用については言及し
ていない．そこで，因子の分類方法を整理するとともに，
因子の抽出と選定を開発時のソフトウェア設計に活用で
きないかと考えた．本論文ではどの種類の因子について
設計で考慮すべきかあきらかにした．その結果，パフォー
マンステストのなかでコンポーネントテストと統合テストと
いった開発者が実施する早期テストレベルにおいて実施
する必要が無いテストケースが判明し，それを実施しない
ことでパフォーマンステストの工数が 50%削減した．
1. はじめに
ソフトウェアの機能組合せテストにおいて，結果に影響
をあたえる要因のうち，どの要因をテストの因子に採用す
るかの判断はきわめて重要である．
従来は，因子の採用についてテスト設計の段階で初
めて考慮されてきたが，因子の種類によってはソフトウェ
ア設計段階で考慮すべきものがあると考えた．
第 2 章では，因子の分類方法の既存研究をまとめ，第
3 章では，開発・設計時に因子の分類を活用する意義に
ついて述べる，第 4 章では開発・設計時に因子の分類を
活用した結果と考察，第 5 章では今後の展望について述
べる．
2. 因子分類方法の既存研究のまとめ
2.1. 要因分析技法
1984 年に富士通では辰巳敬三氏を中心として直交表
を用いた組合せテストを研究・実施していた．
そのなかで，ソフトウェアの「外部仕様」を因子（結果に
影響を与える要因）と水準（各因子が取り得る値）の形で
整理し「要因分析表」にまとめてそれに基づいてテストケ
ースを設計する方法を「要因分析技法」と名付けた．[1]
要因分析技法では因子を４つの大きな観点から分類
している．
1 番目は「機能の観点」である．外部機能からコマンド，
オペランドの入力方法，形式，指定値 などを入力の因
子としている．
2 番目は「動作環境の観点」である．ハード構成/種別，
環境定義，サブシステム，ファイル などを状態の因子と
している．
3 番目は「結果の観点」である．帳票出力，画面表示
結果，表示メッセージ などを分析している．
最後の 4 番目は「その他の観点」として互換性/整合性
/負荷について分析している．
要因分析技法ではこれら 4 つの大きな観点から分類し
た因子のうち 1 番目と 2 番目を用いて「入力の因子×状
態」の表（「要因分析表」と呼ぶ）を作成している（表 1）．
表 1 要因分析表
2.2. HAYST 法
2007 年に富士ゼロックスは直交表をベースとした組合
せテスト技法である HAYST 法のための因子・水準を抽
出・選定するためにラルフチャート（図 1）を用いた分析と
図化を提案している．[2]
ラルフチャートでは因子を以下の 6 つの観点から分類
している．
1 番目は「入力の観点」である．エンドユーザーが最終
的に機能を動作させるときに入力する操作を入力因子
（タグチメソッドでは信号因子と呼ぶ）としている．
2 番目は「ノイズの観点」である．ソフトウェア提供者が
指定できない環境要因・負荷等を「調合誤差因子」として
水準について出力を極端に上下に狂わせる 2 種類に層
別し一つの因子に調合している．
調合誤差因子とは，複数のノイズ（タグチメソッドでは
誤差因子と呼ぶ）を出力を狂わす方向によって水準を調
合し，一つの因子にすることである．たとえば，誤差因子
A(a１，a2)，誤差因子Ｂ(ｂ１，ｂ２)が存在し，出力を小さく
する水準が a1 と b２，出力を大きくする水準が a２と b1 と
したときに調合誤差因子ＡＢは，a1・b2 と a2・b1 の２つの
水準を持つ．誤差因子が増えても同様である．
3 番目は「意識的な異常操作の観点」である．エンドユ
ーザーのいたずら（ボタンをわざと同時に押す等）や犯罪
行為（システムの故意に落とそうとしたり，セキュリティを破
ろうとしたりする行為等）をアクティブノイズとしている．
4 番目は，「出力の観点」である．ユーザーが得る結果
を漏れなく挙げる．メッセージやランプ点灯など，テスト時
の確認項目となるので漏らさないようにする．ただし，同
値分割を意識しないと多数になりすぎるので注意する．
5 番目は「内部状態の観点」である．入力後にシステム
が読み書きするデータベースや内部変数を「状態因子」
としている．ソフトウェアの動作は同じ入力であっても内部
変数の組合せで結果が変わる．したがって内部変数の
組合せ=ソフトウェアの状態となる．
最後の 6 番目は「システム定数の観点」である．コンパ
イル時に決定する定数を「制御因子」としている．ただし
HAYST 法（テスト）では，完成後のソフトウェアがテスト対
象となるので「制御因子」は（その水準が固定値，つまり 1
種類なので）使用していない．
ラルフチャートでこのように６つの観点から分類した因
子のうち，HAYST 法では 3 番目と 4 番目と 6 番目を除く
因子（信号因子，調合誤差因子，状態因子）を直交表に
割り付けてテストマトリクス（組合せ表）を作成している．
図 1 にラルフチャートのテンプレートを示す．
図 1 ラルフチャート
ノイズ
誤差因子
z {z1, z2, z3 ・・・}
入力
信号因子
M {M1, M2, M3,…}
出力
y
(レスポンス)
対
象
read
write
内部変数の組合せ（＝状態）
信号因子 m {m1, m2, m3 ,…}
2.3. タグチメソッド
ソフトウェアではないが，ハードウェアの設計で使用す
る因子についてタグチメソッドが使用している用語を整理
する．[3]
タグチメソッドでは，大きく，信号因子（ユーザの入力），
誤差因子（使用条件），制御因子（設計条件）の３つに分
類している．
誤差因子はノイズとアクティブノイズに分かれる．ノイズ
はさらに調合可能な調合誤差因子と，制御因子との交互
作用をみるため調合してはいけない標示因子にわかれ
る．
タグチメソッドの因子の考え方はシンプルである．出力
に寄与して欲しい要因をシグナル(S)，すなわち，信号因
子とし，出力に寄与して欲しくない要因をノイズ(N)，すな
わち，誤差因子とし，システムとしてこの SN 比（シグナル
がノイズ下であっても働くこと）が十分に大きくなるように
設計時に開発者が決定することができる設計変数，すな
わち，制御因子を決めるというのである．
ここで S も N もシステムにとっては望ましいか望ましく
ないかの違いはあれど，同じ入力である．電話で音声を
S，雑踏の雑音を N としたときにどちらも電話から見ると同
じ入力である．
なお，タグチメソッドでは，制御因子が多ければ多いほ
ど良いとしている．
制御因子の各々は，通常，入力に対して敏感に反応
して出力に大きく影響を与える範囲（水準）と，入力を変
えても出力をそれほど変化させない範囲（水準）を持って
いる（制御因子の影響による入出力関係は非線形であ
る）．したがって制御因子の水準を後者に揃えてやれば，
ノイズに強いロバストなシステムとなるからである．制御因
子の数が多いほど，この効果も高くなるので制御因子が
多い複雑なシステムを推奨している．
3 つの手法で用いる因子のまとめ
「要因分析技法」と「HAYST 法」と「タグチメソッド」で定
義している因子を表 2 にまとめる．
表 2 3 つの手法の因子のまとめ
カテゴリ
要因分析
HAYST
タグチ
技法
法
メソッド
入力
入力因子（信号因子）
システム定数
－
－
制御因子
外部状態
環境因子
調合
調合誤差因子，
誤差因子
標示因子
＝使用条件
アクティブノイズ
内部状態
出力
－
状態因子
（受動）信号因子
出力
表 2 を見ると要因分析技法が外部仕様の入出力と外
部状態に着目していること，HAYST 法が要因分析技法
にアクティブノイズと内部状態を加えていること，タグチメ
ソッドはさらに制御因子に着目していることが分かる．
3. 開発・設計時に因子の分類を活用する意義
3.1. 着想
表 2 で，システム定数について，タグチメソッドだけ「制
御因子」がある．その理由は，他の 2 つの技法はテストの
ために作られた技法だから，テスト時には固定された 1 水
準の因子になる制御因子は組み合わせる必要が無いか
らである．
そもそも制御因子とは，「設計者が自由に水準を決定
し最適条件を求める因子（設計条件）」と定義されてい
る．
すなわちコンパイルが終わった，テストの段階では定
数（固定値）なので組合せ表に割り付ける必要が無いか
らである．
たとえば TCP/IP のパフォーマンスに影響を与える定
数に RWin 値がある．RWin 値は受信確認を送信側に送
る間隔を何バイト単位で行うか，つまり，何バイト受信した
ら受信した旨を送信側へ通知するかを意味している．
低速で質が悪くエラーが多発するような通信回線にお
いては間違ったデータが流れてきた際に再送信の必要
性に早く気が付くように小さめの値にする必要がある．し
かし，光回線のように，高速で質の良い通信回線の場合
はあまり小さいと受信確認（正常受信確認）の回数ばかり
が増えてしまいパフォーマンスを最大化できない．
開発者は市場動向を踏まえ（たとえば Windows７では）
RWin 値を 65700 バイトに固定している．RWin 値のような
設計者が決める設計条件のことを制御因子と呼ぶ．
繰り返しになるが，制御因子の値は一般的なユーザー
が変更するものではないため，テスト時は因子として組み
合わせる必要が無い．
仮に，RWin 値という因子の列を直交表に用意して組
み合わせたとしても RWin 値の水準は 65700 バイトの 1
種類しかないので因子「RWin 値」列の水準はすべて
65700 バイトで埋まる（さらに，テスト実行時にテスト実施
者が 65700 バイトをセットするわけでもない）．ゆえに，
RWin 値をテスト時に割り付ける意味が無いからである．
しかし，RWin 定数を決める設計活動においては最適
値を決める必要がある因子なので，設計活動において制
御因子の認識は重要である．
3.2. プロセス
テストで使用している「要因分析表」や「ラルフチャート」
を用いた因子抽出・選定方法を単にそのまま開発の設計
に持って行ってもその図表には「制御因子」が存在しな
いため上手くいかない．
そこで，図１のラルフチャートの中心の四角（目的機能
を表す枠）の中に制御因子を記述するようにラルフチャ
ートのテンプレートを改めて，開発者が外部仕様を設計
する際にそれを使用し，設計レビューした．
4. 適用結果と考察
「組合せテスト向けの因子分類」を開発の設計行為へ
適用した当初，「制御因子にどのようなものがあるかピン
とこない」という声が多くの開発者から挙がった．
従来においても，開発時に様々なシステム定数を決め
ていたはずであるが，改めて明記しようとすると思いつか
ないというのである．
4.1. ソフトウェアにおける制御因子のパターン
制御因子のイメージを持ってもらうためにソフトウェア
における制御因子のパターンを調査した．調査の方法は
既存シ ステ ムのソ ースコ ードを “constant ”，も し く は，
“const”というキーワードで検索し，どのような定数が存在
しているかを調べて結果を分類した．
するとソフトウェアにおける制御因子には 4.1.1～4.1.5
の 5 つのパターンがあることがわかった．
4.1.1 バッファサイズ
大きなデータを読み書きする場合のバッファの大きさ
を定数としているパターンである．
バッファサイズはハードウェア装置によって最適値が
異なるため，装置ごとにドライバの設定ファイルに指定し，
OS が，その定数を用いている場合が多かった．
しかし，製品システムとしての，真の最適値は，その装
置が想定している平均的最適値に加えて，システムが取
り扱うであろうデータの大きさと，そのばらつきを考慮して
決定する必要がある．
従来は，そこまでは行われていなかったため，本調査
を契機としてパフォーマンスチューニングをしたケースも
あった．しかし，パフォーマンスチューニングした結果は，
従来値よりも，わずかに良くなる程度であり，あまり変わら
なかった．
4.1.2 サンプリング量
3.1 で例として述べた RWin 値は，どのくらいエラーが
発生しないと予測するかを定数としている（サボり方を決
める）パターンである．
バックアップのために最新ログをいくつ残すかといった
定数もこのパターンである．
本パターンの中には使用条件によって最適値が異な
るものも多い．それらはシステムの定数（固定値）とするの
ではなく，デフォルト値とした．具体的には，サービスエン
ジニアがカスタマイズ可能な CUI を設けるか，起動時に
読み込むコンフィグファイルで変更可能とした．
4.1.3 スケールアウト
サービスソフトウエアを購入するユーザーの多くは，導
入当初は 1 台のサーバーでスモールスタートし，徐々に
サーバーを買い足すことによってパフォーマンスが向上
することを期待している．これは，サービスソフトウエアに
限らず，アプリケーションでも同様である．
これを一般に「スケールアウトが可能」と呼んでいる．
OS が持っている仕組みだけでスケールアウトできるこ
ともあればサービスやアプリケーションに手を加える必要
があり，OS が持っている機能だけでは，サーバーや CPU
を増やしてもパフォーマンスが向上しない場合もある．
たとえば，シングル CPU をマルチ CPU に換装しても，
その OS が面倒を見るのがプロセス単位の CPU 分散タイ
ムシェアリングまでならアプリケーション単独の速さは変
わらない．このような時に，マルチ CPU の恩恵を受けたい
なら，アプリケーション自身がスレッド処理を行うプログラミ
ングをすることが必要である．
従来は，スケールアウトしないことをテストで見つけても，
ソフトウェアをスレッド化するなどの大きな修正が必要とな
るため計画したリリース時期に修正が間に合わない場合
が多かった．
テストで問題を見つけるのではなく，製品の設計フェ
ーズで制御因子としてスケールアウトするための要因が
入っているかのレビューが大切である．
リーン（無駄のない）製品開発のメソッドに，「意思決定
をできるだけ遅らせる」がある．これは，無駄なものを作ら
ないという原則に通じる良いメソッドである．しかし，開発
システムの要求や，競合他社とのベンチマーキング，そし
てそのシステムがライフ終了までに果たすべき役割から
考えて必要であれば，たとえユーザーが気づいていなか
ったとしても早めに対応しておくべきと考える．
4.1.4 バージョン
バージョンによって振る舞いやファイルの内部形式を
変更するためにバージョン番号を定数としているパター
ンである．例えば，次のような点が議論になる．
·
どのソフトウェア構成単位でどこに持たせるか
·
文字列か整数値か
·
ピリオドで，メジャーバージョン，マイナーバージョ
ン，メンテナンスバージョンを区切るのであればそ
れぞれ別々に参照可能とするか
·
それぞれの桁数に 2 桁を許すか
(4.23.7 の 23 のように 2 桁を認めるか)
·
頭ゼロの 4.023.7 のようなバージョン名を許すか
仕様書に明記が無く，リリース直前や，初期リリース時
ではなく，バージョンアップ時にバージョン番号付ルール
決めることも過去多々あり，互換性のポリシー（相互互換
性，前方互換性，上位互換性，下位互換性）さえ決まっ
ていなかったということもあった．
インストーラ作成ツールによってはバージョン番号付け
ルールに制約をかけるものがあるので，その点について
も確認が必要である．
4.1.5 禁則
機能として実装は完了していても納品時の機能要件
に含まれていない場合，機能単位で動作する・動作しな
いを制御することがある．このような時に，動作禁止フラグ
のようなものを設定するパターンである．
機能の禁止方法にもいくつかのパターンがあることが
わかっている．「機能自体を全く隠す」，「機能があること
は知らせるが GUI をインアクティブ＝不活性化する」，
「機能をキックすることはできるが，使用不可であることを
コンファーマなどで，ユーザーに通知する」，「エラーコー
ドをコール元へ戻す」などである．
これまでは禁則をどのように実装するかの仕様につい
て，仕様化はもとより，議論さえすることなくソフトウェア設
計者任せであることが多かった．
4.1.6 成果と考察
ソフトウェア設計者へ「4.1.1～4.1.5 に述べたソフトウェ
アにおける制御因子の 5 つの活用パターン」を示すこと
によって必要な仕掛けを早期にソフトウェアに入れること
ができた．
改善を推進する担当者に訊ねたところ，「現場の開発
者の抵抗や“やらされ感”はなく納得しながら改善が進ん
だ．むしろ『こういうの，後から言われると困るから設計で
決まるのは良いよね～』と好評だった」とのことであった．
プロセスの質的変化については，特に「4.1.3 スケール
アウト」に関して，開発・設計者から「従来であれば，ユー
ザーが自らハードウェアのグレードアップやサーバーの
増加を行ったのちに期待したほどの効果が得られず，ク
レームとして要求が来そうな設計上の課題を事前に抑え
込めたので 2 度手間にならずに助かった」との評価を得
た．また，商品のパンフレットにスケールアウトについて実
測値（テスト結果データ）を整理することで掲載できた（テ
ストが新バージョン製品のフィーチャーをつくった）．
一方，工数効果としては，コンポーネントテストと統合
テストにおけるパフォーマンステストが 50%削減した．これ
までは，リリース直前のシステムテストレベルで見つかっ
てもパフォーマンスは改善できないので，コンポーネント
テストレベルや統合テストレベルでもパフォーマンスのテ
ストをしていている組織が多かった．[4]
しかし，パフォーマンスは実際のハードウェア上で動か
さないと正確な測定ができないこともあり，コンポーネント
テストレベルや統合テストレベルでのパフォーマンスのテ
ストはその目的や実施内容，目標値があいまいで効果の
低いものであった．
今回，バッファサイズなどのパフォーマンスに影響を与
えることが予測される制御因子を開発・設計レビューする
ことで，製品設計フェーズでパフォーマンスの設計を十
分検討するようになった．その結果，コンポーネントテスト
レベルや統合テストレベルでのパフォーマンスのテストは，
その制御因子の効果検証にフォーカスを限定することが
できるようになった．その結果，前回のコンポーネントテス
トレベルと統合テストレベルでのパフォーマンステスト工
数を約 50%削減（従来 100 時間→今回 50 時間）した．
5. おわりに
今回，「組合せテスト向けの因子分類」をおこない，ソ
フトウェア設計において制御因子の 5 つの活用パターン
を示すことによって，検討時期の改善とパフォーマンステ
ストの工数改善をおこなうことができた．
今後，不具合情報やユーザークレームから制御因子
の考慮不足パターンに起因する問題をピックアップして，
制御因子パターンの拡充を行って，設計条件の充実を
図りたいと考えている．
あわせて，ソフトウェア設計フェーズで実施する，設計
条件（制御因子の水準の最適値）を効率よく決定する方
法とプロセスを考えたい．コンポーネントテストレベルや
統合テストレベルの結果で設計条件をチューニングする
のではなく，設計フェーズで簡易な実験を実施し，最適
値を見極めるほうが効率的だからである．
また，制御因子以外の因子の分類についても開発・設
計で活用していきたい．
特に内部状態を保持する「状態因子」の共有状況に
ついて，複数のラルフチャートを組み合わせる研究 [5] が
進んでいるのでその成果を活用したいと考えている．「状
態因子」の共有状況を分析することによって，共有リソー
ス問題や，派生開発時の影響度分析の効率ができると
考えている．
参考文献
[1] 辰巳 敬三，殿村 方規: テストケース生成ツール「Ａ
ＴＡＦ」による品質検証の試行と考察，ソフトウェアテス
トシンポジウム，２００６，
http://jasst.jp/archives/jasst06e/pdf/B4-1.pdf
[2] 吉澤 正孝, 秋山 浩一, 仙石 太郎： ソフトウェアテ
スト HAYST 法入門, 日科技連出版社, 2007
[3] 田口玄一，『品質工学便覧』，日刊工業新聞社, 2007
[4] 独立行政法人情報処理推進機構： SECBOOKS 高
信頼化ソフトウェアのための開発手法ガイドブック，
2011
[5] Tomohiko TAKAGI, Zengo FURUKAWA, Kouichi
AKIYAMA, “Ralph's Chart Analysis: Test Analysis
Technique Using Common Factors among Software
Functions”, The 18th IEEE Pacific Rim International
Symposium on Dependable Computing (PRDC 2012),
2012
© Copyright 2024 Paperzz
