第３回システム検証の科学技術シンポジウム 短納期ソフトウェア開発プロジェクトにおける残存 バグ数の予測 ●早くて安価なテストを目指して● 2006年10月31日 山浦恒央 (YAMAURA, Tsuneo) 東海大学情報理工学部 [email protected] 1 1. 短納期ソフトウェアの背景 (その１) 1.1 日本型 vs アメリカ型の製品出荷戦略 (従来の日本型開発) 市場への インパクト 大きさ 製品の品質的 な成熟度 大 小 早い アメリカ・インド型 早期出荷でシェアを確保するため、 品質が未成熟のまま出荷 コスト＜品質＜納期 遅い 日本型 出荷の タイミング 未成熟製品出荷による手戻り作業やコ ストを削減するため、品質の成熟を 待って出荷 コスト＜納期＜品質 2 1 1. 短納期ソフトウェアの背景 (その１) 1.1 日本型 vs アメリカ型の製品出荷戦略 (これからの日本型開発) ・マーケティング戦略の変化 ：重厚長大から軽薄短小へ (数を売るには、 販売タイミングが非常に重要。例えば、ボーナス商戦に間に合わないと 売れないない等) ・リリース時期を早めつつ、品質を上げねばならない。 →開発プロセスの改善が不可欠 大きさ 市場への インパクト 大 製品の品質的な 成熟度 小 早い アメリカ・インド型 遅い 新日本型 出荷の タイミング 従来の日本型 コスト＜品質＝納期 3 1. 短納期ソフトウェアの背景 (その２) 1.2 開発する製品の変化 (1) ∼1990年代 ・銀行オンライン・システムなど、特定組織用の巨大ソフトウェアを 全て、自前で開発していた。 →納期より、品質重視 (2) 1990年代∼2000年 ・パッケージ・ソフトウェアの台頭。 →販売タイミング、品質を自分でコントロールできた。 (3) 2000年∼ ・Web系ソフトウェア、組込み系ソフトウェアの爆発的増加 →ソフトウェアが急速に巨大化、複雑化 →納期が非常に厳しい。 4 2 1. 短納期ソフトウェアの背景 (その３) 1.3 ソフトウェア開発の特性 ソフトウェア開発での工数、開発期間、機能総量、生産性、品質の関係式 1 ⎛ 工数 ⎞ 3 ⎜ ⎟ × (開発時間 ⎝ β ⎠ )3 4 機能の総量 生産性 = 無限に開発要員やテスト 技術者を増やしても、短 縮できる期間には限りが ある。 β＝定数 工数 大 最短開発時間 最長開発時間 工期短縮には、開発プロ セス自体を改良する必 要がある。 不可能領域 非現実的領域 現実的開発時間 小 短い 長い 開発期間 5 2. テストの特性 2.1. 入力ドメイン空間とテスト空間の大きさ（テスト可能性） ●単純な構造のプログラムでも、全入力データの全組み合わせ （全パス数）は、天文学的な値になる（下記の例では、１件１秒で 実行できても、１００万年かかる）。 ●有限のリソースで、全組み合わせを検証するのは不可能。 ５＋５２＋５３＋・・・＋５１８＝４．７７×１０１２ ●しかも、ロジック抜けのバグを検出できない。 １∼18回ループ 6 3 2. テストの特性 2.2 入力ドメイン空間とテスト空間の大きさ （その１） 入力ドメイン空間に比べると、テスト空間は、圧倒的に小さい。 ⇒ 太陽の質量と、素粒子の質量ほど違う？ 入力ドメインの空間 D0 D１ テスト空間 ・・・ ・ ・・・・ ・ D２ D３ D４ D６ テスト項目 D７ D５ D８ D９ 7 2. テストの特性 2.2 入力ドメイン空間とテスト空間の大きさ （その２） 完全なテストができないのなら、テスト空間をどのように「入力ドメイン」に 割り当てて、効率の高いテストを実施するかが非常に重要。 入力ドメイン空間 効率の悪いテスト テスト空間 ・・・・ ・・ ・ ・・・ ・・ ・・・・ ・ D0 ・ ・・・・・・ ・・・・・・ D２ ・ ・・ D１ D３ D４ D６ D７ D５ D８ D９ 8 4 2. テストの特性 2.2 入力ドメイン空間とテスト空間の大きさ （その３） ●全ての入力ドメインをカバーしなければならない。 ●バグのありそうな箇所を重点的にテストする必要がある。 入力ドメイン空間 ・ 効率の良いテスト D１ テスト空間 ・ ・・・・・・・・・ ・・・・ ・ ・ D0 ・ ・ D３ ・ ・D６ ・・ D４ ・ ・ ・ D７ D５ ・ ・ ・ D９ D８ ・・ ・ D２ 9 2. テストの特性 2.2 入力ドメイン空間とテスト空間の大きさ （その４） 入力ドメイン空間 ・ ●テストだけで、全てのバグは取れない。 ⇒テストの時間、人員は有限なので、１００％のバグ 除去は不可能。従って、バグ摘出率の良いテスト 項目が必要。 ⇒製品にバグが残ることを前提に、リスク管理的に、 重大事故につながるバグを重点的に摘出する必要 あり。 ●仕様、設計段階から、バグを作りこまないために、開発 ・ ・ ・ ・ ・ ・・ ・ ・ ・ ・・ ・ ・ ・ ・ ・・・ ・ ・ ・・ ・ ・ バグ ライフサイクルを通じての品質確保プロセスが必要。 ●テスト項目が全機能を網羅するような戦略（サンプ リング）が必要。 10 5 ３．残存バグ数の動的な推定 ソフトウェア開発中に、残存バグ数を高い精度で見積もることが できると、以下の利益を享受できる。 (1) テスト終了の強力な判定基準となる。 (2) 品質目標を設定できる。 (3) 品質測定のメトリクスとなる。 (4) テスト戦略を動的に決定できる。 11 ４．残存バグ数推定法のいろいろ (1) capture/recapture モデルによる推定 (２) Gompertz曲線による推定 (３) MTBF (Mean Time Between Failure) による推定 (４) 過去の統計情報から推定 (５) サンプリングによる推定 12 6 4.1 capture/recapture modelによる残存バグ数推定 ●別名、「fish-in-the-pond」モデル。動物学での、個体母数推定法の１つ。 ●以下のステップで、池の魚の数を推定。 (1) Fｎ０ 匹の魚を捕獲して(capture)、赤く塗り、池に放す。 (2) Fｎ1 匹の魚を捕獲する(recapture)。その中に、Fr 匹の赤い魚がいた」 場合、魚の母数、Fp の推定値は以下のように計算。 Fp = Fn 0 • Fn1 Fr Ｆｎ０ (１回目の捕獲) ・ ・ ・ ・ ・ ・ Ｆｎ１ (２回目の捕獲) ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ 13 4.1 capture/recapture modelによる残存バグ数推定 ●バグ埋め込みモデルによる残存バグ数推定 プログラム中に、人工的なバグを埋め込み、デバッグで摘出した総バグ の中に、人工バグが何件含まれているかで、残存バグ数推定するもの。 ●「バグ埋め込みモデル」の欠点 (1) 人工的なバグを埋め込む行為は、「品質向上」の基本姿勢に 反する (エンジニアに心理的な抵抗感あり)。 (2) 人工バグは、すぐに嗅ぎ分けられる (smell-out)。 (3) 人工バグの修正時に、誤って正常部分も変更する危険性がある。 (4) 最大の問題は、「残存バグの推定値が、実際のバグ数より、 かなり小さい」 14 7 4.1 capture/recapture modelによる残存バグ数推定 (改訂版) ●capture/recaptureモデルの改良版 ⇒ ２チーム制モデル (1) ２チームが、独立して、同じプログラムをテストする。 (2) チーム１が、E1個、チーム２が、E2個のバグを摘出し、Ec個のバグ が、両チームに共通する場合、全バグの推定値Epは、以下となる。 Ep = E1• E 2 Ec ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ Ｅc ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ Ｅ１ (チーム１の摘出バグ) Ｅ２ (チーム２の摘出バグ) 15 4.2 Gompertz Curve による残存バグ数推定 累積数 K 0 フェーズ１ フェーズ２ フェーズ３ 0 時間 事象の成長過程（例えば、人口増加）をユニバーサルなS字 曲線として表現し、数式化したもの。 ・フェーズ１：胎動期 (準備段階) ・フェーズ２：成長期 (急激に成長する段階) ・フェーズ３：停滞期 (成長が止まり、漸近線に近づく段階) 16 8 4.2 Gompertz Curveの適用 (単位時間設定の難しさ) ⇒ １日に１時間しかテストを実施しない日と、１８時間も実施する日を同じ「１日」 としてプロットすると、正確な予測ができない。 ⇒ 例えば、２時間単位で、消化したテスト項目、摘出したバグ数をプロットする など、「正規化」が必要だが、実際に、きちんと決めるのは、困難。 未実施のテスト項目数 未実行の テスト項目数 摘出バグ累計 時間 12/30 1/5 1/12 1/19 1/26 2/2 2/9 2/16 17 4.3 MTBF (Mean Time Between Failures) による残存バグ数推定 ●MTBF 信頼性工学で、被検査対象に欠陥が発生するまでの時間。 ●適用条件 (1) システム・テストの段階 (通常機能が動作している状態) (2) テスト・データがランダム (通常稼動を想定したデータ) ●多数のランダム・データを実行させ、障害が発生する確率を求める。 18 9 4.3 MTBF (Mean Time Between Failure) による残存バグ数推定 推定の基礎となるランダム・テストの概要 ●乱数を発生させ、確率的に入力データを生成し、実行するテスト。 別名、「monkey operation」。 ●通常のテスト項目は、摘出するバグを想定し (例えば、境界に多い)、 そのバグを見つけるための項目を設計するが、ランダム・テストでは、 ターゲットとなるバグを想定しない。 ⇒ テスト効率が悪い。 ●大部分のテスト項目が、エラーとしてはじかれる。 ●バグがあることが分かっても、バグの再現が難しい。 ⇒ バグの分析、品質分析には不適。 19 4.4 過去の統計データからの残存バグ数推定 ●プロジェクトの過去の品質データ (例えば、前回のプロジェクトでの バグ密度は、4．37/KLOC) を使用する。 ●現在のプロジェクトで開発したソース・コード行数が 80KLOC の 場合、バグの推定総数、Eｐ は、 Ep = 4．37件/KLOC ×80KLOC = ３４９．６件 ●簡単に計算できる上、精度はそれほど低くはない。 20 10 4.5 サンプリング法による残存バグ数推定 ●サンプリング法による残存バグ数推定のステップ (1) 全 Tt個のテスト項目から、Ts個をサンプリングする。 (2) Ts個のテスト項目を実施して、Es個のバグを摘出した場合、 バグの母数 Ep は、以下のように推定。 ⎛ Tt ⎞ Ep = Es ⎜ ⎟ ⎝ Ts ⎠ ●サンプリング法の利点 (1) 予測に時間がかからない (特に、サンプリングしたテスト項目を 自動化した場合)。 (2) 人工バグを埋めない。 21 4.5 サンプリング法による残存バグ数推定 ●予測値の精度を上げるには、質の良い「サンプル・テスト項目」が必要。 (1) サンプル・テスト項目が、全ての機能(含エラー処理)を網羅している。 (2) サンプル・テスト項目の粒度が揃っている。 高品質サンプルがあれば、バグ数の推定値の精度が向上する。 「第４世代テスト・プロセス」と、「サンプリング法による残存バグ 数推定」を融合させた。 22 11 ５. テスト・プロセスの進化 (1) 第１世代テスト・プロセス 開発者自身が、プログラムをテストする。 (2) 第２世代テスト・プロセス 開発チーム内に、テスト・チームがある。 プロジェクト・ マネージャ プロジェクト・ マネージャ 要求仕様 概要 定義 設計 詳細 設計 テスト担当者 開発技術者 開発技術者 コーデ テスト ィング 要求仕様 概要 詳細 定義 設計 設計 第１世代テスト・プロセス コーデ デバッグ テスト ィング 第２世代テスト・プロセス 23 ５. テスト・プロセスの進化 プロジェクト・ マネージャ (3) 第３世代の品質保証プロセス ・テスト・チームが開発から独立 ①テスト依頼 ②テスト ・テスト資源が再利用されない ③出荷 ・テスト・プロセスが重複 ③出荷拒否 ＱＡ技術者 開発技術者 要求仕様 概要 詳細 コー デバッグ デバッグ テスト 定義 設計 設計 ディング 項目設計 項目 設計 (4) 第４世代のテスト・プロセス プロジェクト・ マネージャ テスト 品質開発 マネージャ （ＱＡ技術者） ・デバッグとテストを融合。 ・ＱＡ技術者がテスト・プロセスを 管理・指揮。 ・全テスト項目の実施完了で出荷。 開発技術者 ⇒早くて安いテストの実施 要求仕様 定義 概要 設計 詳細 コーディング テスト テスト 設計 項目設計 24 12 ６． 「第４世代テスト・プロセス」と「サンプリング法による残存バグ数推定」の融合 ●第４世代テスト・プロセスは、テストの専門家がテスト項目設計を管理・ 指揮するため、テスト項目自体の品質が高い。これを利用し、以下のス テップにより、サンプリングでの残存バグ数推定を実施する。 (1) テスト項目から、全機能を網羅するよう、ＱＡエンジニア(品質開発 マネージャ)がテスト項目の１０％前後をサンプリング。 (2) どの項目を選択したかは、開発者に非公開とする。 (3) サンプリングした項目を自動化 (テスト・スイート化) する。 ⇒ このテスト・スイートは、保守フェーズでは、回帰テスト として使用する。 つづく 25 ６． 「第４世代テスト・プロセス」と「サンプリング法による残存バグ数推定」の融合 (4) 同一項目によるサンプリング・テストを以下のタイミングで実施する。 ・机上デバッグ終了時 ・単体テスト終了時 ・組合せテスト終了時 ・システム・テスト終了時 つづく 机上デバッグ 単体テスト 組合せテス ト システム・テスト 同一のサンプリング・テストを実施、 残存バグ数を動的に推定 26 13 ６． 「第４世代テスト・プロセス」と「サンプリング法による残存バグ数推定」の融合 (5) ｎ回目のサンプリング・テストによる残存バグ数は、以下のように 推定する。 AEn = n −1 ∑ BAi + REn i ここで、 ＡＥｎ ＝ ｎ回目のテスト終了時点の総バグ数の推定値 ＢＡｎ ＝ ｎ回目のテストで実際に摘出したバグの数 ＲＥn ＝ ｎ回目のサンプリング・テストによる残存バグ数の推定値 机上デバッグ 単体テスト 組合せテスト システム・テスト 同一のサンプリング・テストを実施、 残存バグ数を動的に推定、 バグ摘出目標を設定 27 ６． 「第４世代テスト・プロセス」と「サンプリング法による残存バグ数推定」の融合 (6) サンプリング・テストの結果から以下を分析し、それをベースに テスト戦略を動的に決める。 ・開発者が摘出したバグ件数と、残存バグ数の推定値の比較 ・モジュールや機能ごとのバグの傾向分析（２０％のモジュール に８０％のバグが存在する） ・開発者が摘出したバグの重要度分析（e.g., スペルミスが多い等） ・開発者ごとのバグの傾向分析（e.g., メモリー開放漏れが多い等） 机上デバッグ 単体テスト 組合せテス ト システム・テスト 同一のサンプリング・テストを実施、 残存バグ数を動的に推定 28 14 ７． 「サンプリング法によるバグ数推定」の適用結果 (1) 適用プロジェクトの概要 ● Ｗｅｂベースの通信系アプリケーション。記述言語はC++。 ● プロジェクト１は新規開発。プロジェクト２∼５は、プロジェクト１のバージョンアップ。 ● プロジェクト１∼５は第３世代、Ａ∼Ｈは第４世代。 全工数(人週) 開発期間(週) 開発人員(人) プロジェクト１ (３世代その１) 開発規模 (KLOC) 103.3 456 40 12 プロジェクト２ (３世代その２) 4.6 20.5 13 2 プロジェクト３ (３世代その3) 5.6 25.5 13 3 プロジェクト４ (３世代その4) 5.9 33 16.5 3 プロジェクト５ (３世代その5) 5.0 22 16.5 3 プロジェクトＡ 15.1 63 15 4 プロジェクトＢ (４世代その1) (４世代その2) 12.0 52 18 3 プロジェクトＣ (４世代その3) 10.1 41 13 3 プロジェクトＤ (４世代その4) 15.1 57 19 3 プロジェクトＥ 6.6 26 10 3 プロジェクトＦ (４世代その5) (４世代その6) 5.8 23.5 10 3 プロジェクトＧ (４世代その7) 8.4 34.5 17 2 プロジェクトＨ (４世代その8) 6.2 24.5 11 2 プロジェクト 29 ７． 「サンプリング法によるバグ数推定」の適用結果 (2) サンプリング法適用による残存バグ数推定結果の概要 プロジェクト名 総テス ト項目 数 プロジェクト A 1427 121 プロジェクト B 1113 96 プロジェクト C 916 80 1061 93 プロジェクト D プロジェクト E プロジェクト F 673 588 サンプル・ テスト項目 数 60 67 プロジェクト G 865 88 プロジェクト H 594 63 予想残存バグ数, 摘出バグ数 摘出バグ数 予想残存バグ数 摘出バグ数 予想残存バグ数 摘出バグ数 予想残存バグ数 机上デバ ッグ終了 時 単体テス ト終了時 組合せテス ト終了時 システム・ テスト終 了時 13 5 2 0 153 59 24 0 14 6 2 0 162 70 23 0 7 2 1 0 80 23 11 0 8 3 1 0 91 34 11 0 9 3 1 0 101 34 11 0 6 4 2 0 予想残存バグ数 53 35 18 0 摘出バグ数 14 4 2 0 138 39 20 0 摘出バグ数 予想残存バグ数 摘出バグ数 予想残存バグ数 摘出バグ数 予想残存バグ数 摘出バグ数 予想残存バグ数 5 3 2 0 47 28 19 0 総摘出バ グ数 131 108 70 109 52 54 71 53 30 15 ７． 「サンプリング法によるバグ数推定」の適用結果 (3) サンプリング法適用による残存バグ数推定結果の詳細 (机上デバッグ終了時) この時点では、未実装機能も残っているため、摘出バグ数が多く、残存バグ数 の推定値は高くなる。 プロジェクト名 机上デバッグでの摘出バグ数 (実績) 机上デバッグ終了後の推定値 摘出バグ 総数 （実績） 予測精度 (推定／実績) 実摘出バグ数 総摘出バグ累計 （Ａ） 予想残存バグ数 （Ｂ） 予想総バグ数 （Ａ＋Ｂ） プロジェクト A 32 32 153 185 131 141% プロジェクト B 26 26 162 188 108 174% プロジェクト C 21 21 80 101 70 145% プロジェクト D 19 19 91 110 109 101% プロジェクト E 16 16 101 117 52 225% プロジェクト F 23 23 53 76 54 140% プロジェクト G 46 46 138 184 71 259% プロジェクト H 28 28 47 75 53 142% 31 ７． 「サンプリング法によるバグ数推定」の適用結果 (4) サンプリング法適用による残存バグ数推定結果の詳細 (単体テスト終了時) プロジェクト名 単体テストでの摘出バグ数 (実績) 実摘出バグ数 単体テスト終了後の推定値 総摘出バグ累計 （Ａ） 予想残存バグ数 （Ｂ） 予想総バグ数 （Ａ＋Ｂ） 摘出バグ総 数 （実績） 予測精度 (推定／実績) プロジェクト A 55 87 59 146 131 111% プロジェクト B 33 59 70 129 108 119% プロジェクト C 21 42 23 65 70 93% プロジェクト D 40 59 34 93 109 86% プロジェクト E 18 34 34 68 52 130% プロジェクト F 17 40 35 75 54 139% プロジェクト G 15 61 39 100 71 141% プロジェクト H 11 39 28 67 53 127% 32 16 ７． 「サンプリング法によるバグ数推定」の適用結果 (5) サンプリング法適用による残存バグ数推定結果の詳細 (組合せテスト終了時) 組合せテストでの摘出バグ数 (実績) プロジェクト名 組合せテスト終了後の推定値 摘出バグ 総数 （実績） 予測精度 (推定／実績) 実摘出バグ数 総摘出バグ累計 （Ａ） 予想残存バグ数 （Ｂ） 予想総バグ数 （Ａ＋Ｂ） プロジェクト A 35 122 24 146 131 111% プロジェクト B 31 90 23 113 108 105% プロジェクト C 19 61 11 72 70 104% プロジェクト D 33 92 11 103 109 95% プロジェクト E 11 45 11 56 52 108% プロジェクト F 9 49 18 67 54 123% プロジェクト G 8 69 20 89 71 125% プロジェクト H 9 48 19 67 53 126% 33 ７． 「サンプリング法によるバグ数推定」の適用結果 (6) サンプリング法適用による残存バグ数推定結果の詳細 (システム・テスト終了時) プロジェクト名 システム・テストでの摘出バグ数 (実績) 実摘出バグ数 システム・テスト終了後の推定値 総摘出バグ累計 （Ａ） 予想残存バグ数 （Ｂ） 予想総バグ数 （Ａ＋Ｂ） 摘出バグ総 数 （実績） 予測精度 (推定／実績) プロジェクト A 9 131 0 131 131 100% プロジェクト B 18 108 0 108 108 100% プロジェクト C 9 70 0 70 70 100% プロジェクト D 17 109 0 109 109 100% プロジェクト E 7 52 0 52 52 100% プロジェクト F 5 54 0 54 54 100% プロジェクト G 2 71 0 71 71 100% プロジェクト H 5 53 0 53 53 100% 34 17 ８． 「サンプリング法によるバグ数推定」の適用結果 利点 (1) 「第４世代テスト・プロセス」と、「サンプリング法による残存バグ数推定」 は、相性がよい。 (2) 残存バグの推定数は、実用に十分耐えるレベルの精度がある。 (3) 推定残存バグ数は、多めに出る (摘出バグ目標数として、好ましい？)。 (4) サンプリングしたテスト項目を自動化すると、迅速に推定可能となる。 (5) サンプリング・テスト項目が、回帰テスト項目になる。 早いテストが可能になる。 35 ８． 「サンプリング法によるバグ数推定」の適用結果 今後の課題 (1) テストの初期（特に、机上デバッグ終了後）では、推定精度が低い。 ⇒ 過去のバグの統計データ（例えば、3.17件/KLOC）との２本立てに する等の対策が必要。 (2) サンプリング・テストの実施時期、回数は、大きな課題。 ⇒ 机上デバッグ中では早すぎる？ ⇒ システム・テスト終了時では遅すぎる？ (3) 品質の良いプログラムほど、推定精度が高い傾向がある。 ⇒ 低品質のプログラムほど、正確な推定精度が必要。 36 18
© Copyright 2024 Paperzz
