ソフトウェアバグの現状 : 膨大化するソフトウエア開発と生産性 開発機能数 つの機能を開発する時間開発時間 ( 相対 ) ソフトの量 (FP) 2 2 96 97 98 99 2 2 生産性 (H/FP) 7 6 4 3 2 96 97 98 99 2 2 4 3 2 ソフトウェアエンジニアリングの効果 食い止める何かが必要 96 97 98 99 2 2 出典 :Software Metrics より 開発機能数の指数的な増加 2 開発生産性の向上生産性を考慮しても 開発時間へのインパクトは 2 年以降 急激に大きくなっている
原因結果グラフ前頁の加速 / 減速の論理式を原因結果グラフにしてみましょう 前頁の論理式 D and (not R) and (not P) = D モード D モード and アクセル = 加速ブレーキ = 減速 P NOT 加速の関係 R NOT AND D モード D AND 加速 アクセル 減速の関係 ブレーキ 減速 この様に 原因結果グラフにすると 原因と結果の関係 ( 関連 ) を把握しやすくなります
-8. 直交表が網羅する組合せ L4 直交表 太字 斜体 下線 全組合せ 太字 斜体 下線 テスト No. テスト No. テスト No.2 テスト No.2 テスト No.3 テスト No.3 テスト No.4 太字 テストNo.4 テストNo. テストNo.6 テストNo.7 テストNo.8 太字 斜体 下線 斜体 下線 2 機能間の組合せが全て存在している ( この状態を組合せ網羅率 % と定義する ) 全組合せでは直交表に存在しない組合せも出現する ( ただし テスト回数は指数関数的に増大する ) 2
実際にやってみました : プリンタ機能組み合わせテスト プリント実行指示 ドライバ設定 アプリ OS ドライバ NET WORK 印刷物 ABC プリント実行指示 ドライバ設定 アプリからの出力指示を始点として紙が出力されるまでのソフト群がテスト対象 アプリ ドライバ OS Net NET WORK Imager Decomposer Net 印字不良 / 出力可否が不具合として検出される 3
HAYST 法の結果 製品の特徴 モノクロネットワークプリンタ カラーネットワークプリンタ 因子数 :2 因子数 :34 水準数 :79 水準数 :2 不具合状況 (2 水準系直交表 L64 L28) 直交表 網羅率 不具合数 多水準の扱い 水準以上 3 水準 ~4 水準 2 水準以下 テスト数 L64 79% 件 対応する線点図 8 水準線点図 4 水準線点図 2 水準線点図 直交表 網羅率 不具合数 テスト数 L28 73% 9 件 禁則の扱い全てのテスト項目に関して 禁則組合せが出現しないように 構成 (64 項目テスト項目があったら 項目も禁則関係が出現していない 禁則にならないように 他の水準を割り当てている ) 4
6-4. 直交表の生い立ち : ラテン方陣 このような表を ラテン方陣と呼ぶ 大将中将小将 中将小将大将 小将大将中将 四方からの攻撃をバランスよく守っている
6-. 機能数と直交表によるテスト サイズ テストできる機能数 直交表 2 機能間テスト数の網羅率 3 機能間の網羅率 2 機能の組合せ数 フルコンビネーションテスト 2 機能間 3 機能ののテスト数組合せ数 3 機能間のテスト数 直交表の効率 2 機能間 3 機能間のテストのテスト L4 3 4 %.% 3 2 8 3 L8 7 8 % 9.% 2 84 3 28 32 L6 6 % 96.% 42 4 364 26 29 L32 3 32 % 98.28% 46 86 449 396 8 4 L64 63 64 % 99.8% 93 782 397 37688 22 4923 L28 27 28 % 99.6% 8 324 33337 2667 2 273 L26 2 26 % 99.8% 3238 294 2733 28498 6 877 直交表のテスト数は機能に対して 加算で増加する従来のフルコンビネーションは 掛算で増加する. 9. 8. 9. 96.2 トリプル網羅率 98.3 99.2 99.6 99.8 99.9. % 7. トリプル網羅率 直交表でテストを行うと 網羅率を保証しつつテスト数を大幅に削減できる 6.. 4.. 4 8 6 32 64 28 26 2 24 直交表 6
6-4. 直交表の利点 : テスト項目数が減る 直交表を用いない場合の組合せテスト 組合せを確認したい設定項目 ( 因子 ) と各因子のとりうる値 ( 水準 ) が次のようになっているとする 因子名 速度 高度 質量 水準名早い遅い高い低い 全ての組み合わせを考慮した実験を試みた場合には 2 2 2 = 8 通り ( 2 3 通り ) 組合せが発生する 因子数が 3 つだったから 8 通りですむが 因子数が 個の場合には 2 =.28999 通りのテストをこなさなければ 全ての組合せをテストしたことにはならない 出来るわけ無いので 何とか絞り込まなければならない 適当に間引いてしまうとやばそう なんか良い方法はないの?? SW の不具合発生は 2 因子間の組合せで発生している 2 因子間の組合せのみ % 保証するという方針で考えてみる 直交表を用いる場合の組合せテスト L4 直交表テストNo. テストNo.2 速度 高度 質量 割付け L4 直交表テストNo. テストNo.2 速度早い早い 高度低い高い 質量 速度の 早い に着目して見てみると 早い に対して 残りの因子の保有する水準との組合せが直交表の中に出現しているのが分かる 因子の水準に着目してみても同じ状況になっている テストNo.3 テストNo.3 テストNo.3 テストNo.3 遅い遅い 低い高い SW テストへは 直交表の 2 因子間の組合せは % 保証する (3 因子以上の組合せに関しては保証しない ) という性質を利用している 7
8-2. 遷移パスを自動的に抽出する方法 a j i b c S S S2 S 関係行列 S h S b S2 a S3 h g f S3 k e d S S2 S3 i g c j e f d k 状態 SからS2への遷移はイベントc によって起こるという関係を示す S S S2 S3 h b i g a c j e f d k h b i g a c j e f d k S S S2 S3 hh hb+bi ii+fg dg gi+kg ha+bc+aj ic+cj+fe jj+de gc+ej+ke bf+ad if+cd+fk jd+dk gf+ed+kk 8
9-. 成果 市場での成果 網羅率 FC 市場不具合 3 バグ検出率 [%] % 開発プロセスでの成果 網羅率 [%] 9 8 7 6 4 3 2 3% 製品 X Limoges 勘と経験 8% 件 製品 Y Oceans2TTM HAYST 法 3 市場不具合数 2 2 フローアウトバグの撲滅 (CS 向上 ) 要求定義 設計 現状 Code 単体 今後 9% 8% 998 年製品 結合 機能 % 3% 99 年製品 2 3 4 6 ヶ月 システム QA テスト 開発プロセスの加速化 (TTM 短縮 ) 評価での成果 人材開発での成果 工数 [% ] 2 8 6 4 2 従来手法 ~999 年 6 2 年 勘と経験で手作業で作成 HAYST で手作業で作成 9 6 HAYST 自動生成ツール使用 2 テストマトリクスあたりの工数比較 4 7 HAYST 手作業製品 A 製品 B 製品 C 製品 D 製品 E 製品 F 製品 G 2 年以降の製品 製品 H 2 7 製品 I 評価コストの削減 ( ツール活用 ) 2 2 6 2/9/3 22//3 27 44 6 76 94 3 3 8 64 99 22/6/3 22// 22/2/2 23//3 23/6/3 23/7/ 23// 24//9 24//3 24/6/28 2/3/8 28 % 8% 6% 4% 2% % 受講者数満足度 評価工学の確立 ( 士気向上 ) 9
9-4. 開発テスト終了時のバグ検出状況 % HAYST 法を使用したサブ 8 6 4 2 総 Bug 数 SST 不具合検出率 評価部門を含め 市場導入までに検出したバグ数を とする HAYST 法を適用安定して高い検出率 HAYST 法を使用しなかったサブ 8 6 4 2 総 Bug 数 SST 不具合検出率 HAYST 法を適用していないサブのバグ検出状況 : バラツキが大きい