Myersの呪縛
不具合の分析とフィードバックによるテストの設計• 偉大なるMyersは重要だが罪深い原則を提示した– 「一般に、プログラムのすべてのエラーをみつけることは、非現実的でもあり、しばしば不可能でもある」• これを聞いてテスト技術者はMyersの呪縛でがんじがらめになった– ならばテストの質を向上してもムダなのではないか» 設計や分析の技術» プロセス改善だけに取り組む» あきらめる／悪循環に陥る

ソフトウェアテストシンポジウム2003
2003/3/6（木）㈱エス・キュー・シー 西 康晴

» ソフトウェア工学的活動全般に対する猜疑心を生むことになった» テストの質を向上させようとする気概が失われた

Copyright 2003 NISHI, Yasuharu

テスト項目数の発散の原因

Dr. Glenford J. Myers
CEO, IP Fabrics.
Leading rolesin the 286, the 386
and the i960.

– テストの質の向上が伴わない改善活動が増えて、不具合の低減に結びつかない取り組みが増える

Copyright 2003 NISHI, Yasuharu-2-組み合わせによる急激な発散• Myersの呪縛の本質的原因– ブラックボックステストで全ての不具合を検出しようとすると、テスト項目数が発散してしまう

全てのデータや機能などを組み合わせて網羅するようになるとテスト項目の数が発散してしまう• ブラックボックステストでテスト項目数が発散する原因– 数値範囲のテスト項目は無限に存在する» 1から10の範囲に存在する浮動小数点の数はとてもたくさんある» 境界値分析を行えば、1つの数値範囲に対して4つのテスト項目でよいテスト項目の数» 範囲内が連続であることを保証するためには、レビューなどを行う

テスト対象に含まれているバグの数– 組み合わせによるテスト項目は無限に存在する» 機能やパラメータを組み合わせてテストしないといけない» 組み合わせによってテスト項目数は指数関数的に増えていく» 直交配列表はAll-pair法を用いる場合もある-3-

テスト組織の成熟度

Copyright 2003 NISHI, Yasuharu

組み合わせの回避によるバグの見逃し

組み合わせを行わない
テスト項目の最大数検出できる不具合の数

レビューなどで組み合わせバグを防ぎ、全てのデータや機能などを組み合わせずに網羅するようになるとテスト項目の数は収束するが、不具合を全て検出できるわけではない

Copyright 2003 NISHI, Yasuharu-4-組み合わせによる穏やかな発散
テスト項目の数
組み合わせを行わないテスト項目の最大数

しかし実際には組み合わせバグを防ぎきることはできないので、不具合を全て検出するには組み合わせテストを行う必要がありテスト項目の数は緩やかに発散する

テスト項目の数
テスト対象に含まれているバグの数
テスト対象に含まれているバグの数検出できる不具合の数検出できる不具合の数

テスト組織の成熟度

テスト組織の成熟度-5-

Copyright 2003 NISHI, Yasuharu-6-

Copyright 2003 NISHI, Yasuharu

1不具合分析とフィードバックによる発散の抑制
レビューなどをきちんと行い、組み合わせテストを行わずに網羅する一方でバグ見逃しを継続的にフィードバックしていくとバグが出やすいテスト項目を多く狙えるようになるだろう

バグ見逃しのフィードバックによるテストの改善• バグ見逃しをフィードバックしてテストを改善する
ためには、知識を再利用する必要がある– 組み合わせバグには傾向があるので、そこを狙えばよい» バグは偏在する» バグの多そうな部分をあらかじめ理解しておけば、効率的にテストできる組み合わせを行わない
テスト項目の最大数– オブジェクト指向におけるクラス階層の概念を流用する
テスト項目の数

テスト対象に含まれているバグの数» クラス／インスタンス／継承構造– 組み合わせバグの見逃しのクラス階層ツリーを構築する» 組み合わせバグのパターンを抽象化・構造化して蓄積する» 蓄積したパターンに照らし合わせてテスト項目を設計する– テストを見逃しやすい兆候とバグを作り込みやすい状況を抽出する» どのようにしてバグが発生したか／バグが発生する状況や条件» 期待結果と実施結果／バグが発生するメカニズム検出できる不具合の数
テスト組織の成熟度

Copyright 2003 NISHI, Yasuharu-7--8-

Copyright 2003 NISHI, Yasuharu

フィードバックによるテスト設計の改善

バグ見逃しのナレッジマネジメント•• バグ見逃しのクラス階層の構築手順 (図6/P.52)

バグ見逃しをフィードバックすることによってテストの設計を改善し、テスト項目数の発散を防ぐ①類似のバグを収集する» バグの事例をインスタンスとして収集する» バグの記述を書き直す» 似たようなバグに分類する

1. テストを設計する（Design）–

初回は組み合わせずにテストするA

2. バグ見逃しを収集する（Collect）
3. バグ見逃しが起きやすい
ポイントを抽出する（Extract）
4. 抽出したポイントをテスト設計に追加する（Add）

D- some component is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left②abstracting
bug classesE- some component is divided
by the same t ype of comp onent- what w ould include a specific line
will be left
- the largest part is leftC- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

④inferring bug classes
with similar mechanisms- component C is divided
by component B- what w ould include a specific line
will be left
- the part fist selected is left

①類似のバグを収集する
Copyright 2003 NISHI, Yasuharu-9-- 10 -- some component is divided
by some att ribute- what w ould include a specified attribute
will be left only
- all parts is deleted or left

- component D is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left⑤deriving a bug instancefrom inferred bug classes

Copyright 2003 NISHI, Yasuharu

バグ見逃しのナレッジマネジメント

バグ見逃しのナレッジマネジメント• バグ見逃しのクラス階層の構築手順 (図6/P.52)• バグ見逃しのクラス階層の構築手順 (図6/P.52)②抽象化してバグのクラスを抽出する③同じクラスに属する新たなバグのインスタンスを導出する» 似たようなバグとして分類されたバグを、本質的に共通な部分と異なる部分に区別する» 共通な部分を残し異なる部分の記述を代名詞に置き換えることで、バグのクラスの記述を作成する» クラスの記述に当てはまるテスト対象の機能やデータ構造を探す» 当てはまったクラスの示すメカニズムや兆候を持つバグを具体化する» 当てはまった機能やデータ構造などと、具体化したバグからテスト項目を設計する- some component is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left- some component is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left②抽象化してバグのクラスを抽出する②abstracting
bug classes- some component is divided
by the same t ype of comp onent- what w ould include a specific line
will be left
- the largest part is left

④inferring bug classes
with similar mechanisms- some component is divided
by the same t ype of comp onent- what w ould include a specific line
will be left
- the largest part is left

- some component is divided
by some att ribute- what w ould include a specified attribute
will be left only
- all parts is deleted or left

④inferring bug classes
with similar mechanisms- some component is divided
by some att ribute- what w ould include a specified attribute
will be left only
- all parts is deleted or left

組み 合わせを行わ ない
テスト項 目の最 大数- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

- component C is divided
by component B- what w ould include a specific line
will be left
- the part fist selected is left

- component D is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left

テス ト項目の数検出できる不具合の 数①collecting similar bugs

- 11 -③deploying similar bugs
from the same class

テスト組織 の成熟 度⑤deriving a bug instancefrom inferred bug classes

Copyright 2003 NISHI, Yasuharu- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

※当てはまる機能やデータ構造などが多ければ、バグを見つけられる可能性は低い- some component is divided
by component A- what w ould include a specific linewill be left
- the largest part is left

- component C is divided
by component B- what w ould include a specific line
will be left
- the part fist selected is left

- component D is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left③同じクラスに属する新たなバグのインスタンスを導出する⑤deriving a bug instancefrom inferred bug classes- 12 -

Copyright 2003 NISHI, Yasuharu

2

バグ見逃しのナレッジマネジメント

バグ見逃しのナレッジマネジメント• バグ見逃しのクラス階層の構築手順 (図6/P.52)• バグ見逃しのクラス階層の構築手順 (図6/P.52)④類似のメカニズムを持つクラスを推測する⑤推測されたクラスからバグのインスタンスを導出する» 親クラスを抽出し、その親クラスから新たに可能な子クラスを論理的に推測する» クラスの記述に当てはまるテスト対象の機能やデータ構造などを探す» 当てはまったクラスの示すメカニズムや兆候を持つバグを具体化する» 当てはまった機能やデータ構造などと、具体化したバグから、テスト項目を設計する- some component is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left- some component is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left②abstracting
bug classes②abstracting
bug classes- some component is divided
by the same t ype of comp onent- what w ould include a specific line
will be left
- the largest part is left

- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

- some component is divided
by some att ribute- what w ould include a specified attribute
will be left only
- all parts is deleted or left

④類似のメカニズムを持つクラスを推測する- some component is divided
by component A- what w ould include a specific line
will be left- the largest part is left

- component C is divided
by component B- what w ould include a specific line
will be left
- the part fist selected is left

- component D is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left- some component is divided
by the same t ype of comp onent- what w ould include a specific line
will be left
- the largest part is left

テス ト項目の数- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

- some component is divided
by component A- what w ould include a specific line
will be left
- the largest part is left

③deploying similar bugs
from the same class- 13 -

適用例： CADソフトウェアの知識ツリー
クラスＸ– データオブジェクトの組み合わせのバグが検出できなかった- ある部品が分割される- 特定の条件を満たす小部品が残るはず- 特定の条件を満たす小部品が残らなかった» データオブジェクトの種類は２０万件以上– テスト項目の設計もレビューでの指摘項目の設計も同じ• 本手法を適用した

…

クラスＡ１

– 以前に仕様レビューで見逃した3件の不具合から知識ツリーを構築した– 4件の不具合が該当した- component D is divided
by anothe r component- a part with a specific condition
will be left
- the part d ependent on size or lengthis left

Copyright 2003 NISHI, Yasuharu- 14 -• CADソフトウェアに対する仕様レビュー» 過去の仕様レビューで見逃した他の不具合が検出できるかどうかで効果を測定することにした» 知識ツリーを構築した結果、クラスを32個抽出した- some component is divided
by some att ribute- what w ould include a specified attribute
will be left only
- all parts is deleted or left

⑤推測されたクラスからバグのインスタンスを導出する⑤deriving a bug instancefrom inferred bug classes

Copyright 2003 NISHI, Yasuharu

適用例： CADソフトウェアの仕様レビュー- component C is divided
by component B- what w ould include a specific line
will be left
- the part fist selected is left

検出できる不具合の 数
テスト組織 の成熟 度①collecting similar bugs

④inferring bug classes
with similar mechanisms

組み 合わせを行わ ない
テスト項 目の最 大数- ある部品が別の部品によって分割される- 特定の線分を含む小部品が残るはず- 長さや順序に基づいて小部品が残った- ある部品が部品Ａによって分割される- 特定の線分を含む小部品が残るはず- 大きい方の小部品が残った- ある部品が部品Ａによって分割される- 特定の線分を含む小部品が残るはず- 大きい方の小部品が残った

クラスＡ３３- ある部品がある属性に基づいて分割される- その属性を含む小部品が残るはず- その属性を含む小部品が残らなかった- 部品Ｄが属性Ｅに基づいて分割される- 属性Ｅを含む小部品が残るはず- 全ての小部品が削除された- 部品Ｃが部品Ｂによって分割される- 特定の線分を含む小部品が残るはず- 始めに選択された小部品が残った» 7件の潜在的不具合を指摘可能な指摘項目が設計できた- 15 -

Copyright 2003 NISHI, Yasuharu

知識の抽象化に関する注意点• 抽象化は慣れないと難しい作業である– 始めは時間がかかる

Copyright 2003 NISHI, Yasuharu

まとめ• Myersの呪縛から解き放たれる必要がある– 組み合わせによるテスト項目数の発散を回避するのが課題である» 始めはバグ１件の抽象化に２時間かかる» 慣れると１件あたり５分でできるようになる– 過度の抽象化は避ける必要がある：S/N比が落ちる» 原因はスキル不足だ» そもそも無理なプロジェクトだ» 教育やトレーニングが充実していないのが原因だ» ソフトウェア産業の構造的問題だ» 不況がすべて悪いのだ• 抽象化をする目的を常に忘れないようにする– テスト設計でバグを検出するのが目的– バグ見逃しの原因の再発を防ぐことが目的» 原因が繰り返されるからバグ見逃しも繰り返される» バグ見逃しは、人間の認知プロセスが持つ弱点の具現化である» テスト項目をレビューし改善していき、組織全体での再発を防ぐ- 17 -- 16 -

Copyright 2003 NISHI, Yasuharu• バグ見逃しをフィードバックしてテスト設計を改善することは一つの方策である– バグ見逃しの知識を抽象化し構造化して再利用する• 仕様レビューに適用したところ、効果がみられた– CADソフトウェアを対象に適用したテスト項目をレビューし改善していくことでバグ見逃しを防ぐことが重要である- 18 -

Copyright 2003 NISHI, Yasuharu

3

何かご質問はありませんか？

西 康晴
nsh@mtd.biglobe.ne.jp
Copyright 2003 NISHI, Yasuharu

4