ソフトウェア工学に文句をつける

本稿ではソフトウェア工学の論文を1つ例として取り上げ、その内容に文句をつけたいと思う。取り上げる論文は、ソフトウェア工学の論文としてきちんとしたもので、ソフトウェア工学のトップ会議の一つであるISSTAで発表されたものである。

Milos Gligoric et al., Comparing non-adequate test suites using coverage criteria, ISSTA’13

PDF

論文の解説

ソフトウェアがちゃんとできているか、確かめるよくあるやり方はテストである。ソフトウェアにやってきそうな入力をいくつか用意し、実際にソフトウェアに入力してみる。そしてその結果をみて、ソフトウェアが期待通りに動くか確かめる。

ここで問題は、あらゆる可能な入力に対応するテストを用意することは、ほとんどの場合、不可能であるということだ。というのも、ソフトウェアが受け付ける入力の数は膨大なものになってしまうことが多いので。

というわけで、不完全なテストの「良さ」を評価するために「カバレッジ」という概念が登場する。ソフトウェアテストのカバレッジの概念は多数提案されていて、例えば

  • コードカバレッジ:テストによって実行されるコード(例えばプログラムの文)が全体のどれだけか。この論文ではステートメントカバレッジと呼んでいる。
  • ブランチカバレッジ:プログラムの中に含まれる分岐のうち、どれだけが実行されたか
  • パスカバレッジ:プログラムの中に含まれる実行パスがどれだけ実行されたか

などなど。これらのカバレッジ基準によって、テストが評価できる…わけだが、評価基準がたくさんあるので、評価基準自体の評価が必要になる。それをしましょう、というのがこの論文。ただし、カバレッジ基準が完全に満たされている(100%のとき)場合は先行研究があるので、基準が完全に満たされない場合を考えた、というのがこの論文の新しさ。カバレッジ基準が100%満たされることはめったにないので、この論文のやっていることは意義が大きい。

さて、どのようにカバレッジ基準の妥当性を評価するか。テストは究極的にはバグを見つけるためのものなので、そのテストがバグを発見できる確率とカバレッジ基準の達成度合いの相関を見る。バグは人為的にコードをランダムに変化させることにより生成する。テストによるランダムな生成によるバグの発見率と、人間が作るバグの発見率は、相関していることが知られているので、このような評価で問題ない。

さて、この論文の結論は本稿の目的とはあまり関係ないが、一応書いておくと、ブランチカバレッジが、他の複雑な基準を押しのけて、一番良い。ただし、テストが十分行える状況ではAIMP (acyclic intra-method paths)カバレッジという基準が良いらしい。

文句をつける

さて、この論文、動機づけも明確で良いし、実験もきちんと行われていて興味深い結論を引き出している。考察も示唆的だと思う。良い論文だと思う。

それでも文句をつけたくなる。

  1. 理論的な基盤の欠如:この論文の結論の正当化には、直感に訴えた議論はあっても理論的なものはない。
  2. 特定のデータセットやツールに依存している
  3. 特定の言語(Java)とプログラミングパラダイム(オブジェクト指向言語)に限定された研究である

ランダムなバグを検出するのにどのようなテストを行えばよいか、というのは原理的には純粋に理論的な課題なはず。もちろん実際は難しいかもしれないが、近似的な議論とか、なにかできないのだろうか。大量なデータを用いた経験的な研究を行うのが最近のソフトウェア工学研究のトレンドだが、理論的な正当化が不十分であるように思う。そして、理論的な正当化が不十分であるために、次に述べるように、結果の一般性に疑念が生じる。

2.は言いがかりのように聞こえるかもしれない。実験をする以上、何かのデータセットやツールに依存せざるを得ないのは明らかではないだろうか。しかし、ソフトウェア工学分野の研究では、比較を公平にするためもあるのだろうが、同じデータセットやツールが複数の研究で繰り返し用いられている。つまり、研究分野自体が特定のデータセットに過学習しかねないように思う。

さらに言えば、現在のソフトウェア工学のほとんどがJavaプログラムを対象にしている(CやC++が対象になることもある)。これは不健全な状況だと思う。別のプログラミング言語やパラダイムが主流になったとき、またすべての研究を一からやり直すのだろうか。

ではどうすればよいか

あまり大した提言はできないのだが、まず大量データを解析して経験的に結論を下すだけではなく、なぜそれが成り立つか、理論的な考察が必要だ。理論的な考察があって初めて、得られた結果が一般性を持つのかどうか、異なったプログラミングパラダイムに適応可能か、といったことが分かるはず。

もう一つは、Javaだけではなく、異なった言語・パラダイムの研究を行うべきだということ。静的型付けがあるのとないのとではどう違うか。型推論はどのような影響を与えるか。オブジェクト指向と関数型言語ではどう違うか。などなど。

まあ、お前がまずやれ、という話になりそうだが…

ソフトウェア工学に文句をつける” への2件のフィードバック

  1. わたしはソフトウェア工学の専門ではありませんが反論を試みます。

    ご意見には
    – 蓋然的な知識への不当な評価
    – ソフトウェア工学という分野がどういう知識を目指すかについての一方的な考え
    があるように思います。

    まず蓋然的な知識の積み重ねで構築される分野は医学の、特に内科的知識についても同様だと思います。
    内科的な知見には「効果があることはわかっているがまだメカニズムまでは不明な薬・治療」「アメリカ人の被験者では効果が確認されたが日本人については確認されていない実験結果」といったものがあります。(disclaimer: 私は医学の専門家でもありませんが、メディア上の報道や議論の中にこういったものはよくみかけますよね)
    これらは「人体のメカニズムについての一般的・普遍的な知識」に到達してはいないし、到達しうるのかもわかりませんが、とにかく臨床治療や生活習慣についての知見をあたえてくれるものではあり、一般性の欠如に文句をつけたり不健全であるとするのは不当ではないでしょうか。

    ソフトウェア工学(のある部分?)が対象とする開発プロセスというものが人体と同様に複雑すぎるものであるとしたら(それはありそうなことです)、それについての知識の探求の仕方が似通ってもよく、また結果が蓋然的であっても開発プロジェクトの実践に知見を提供しうるのではないですか。
    また、ソフトウェア工学の分野では研究にthreats to validityの考察をつける習慣があるようで、これは不健全とは逆の特徴だと思います。(だんだん釈迦に説法になっているかもしれません。すみません)

    いいね

    1. 科学には第一原理から導出する理論的な方法と、実験から帰納的に導く方法があると思います。どちらが良いというわけではなく、組み合わせてバランスよく使うことが大事。

      私の言いたいことは、ソフトウェア工学の場合バランスが崩れているということです。その一例として論文を一つ取り上げました。この論文では(に限らないが)理論的に探求可能な問題を経験的にのみ取り扱っている、という問題があります。経験的な知識が悪いわけではありませんが、理論と組み合せるとより深い理解が得られると思います。例えば、医学でも単に経験的に疫学調査等をするだけでなく、結果を分子生物学などにより理論的に解釈しようとすると思います。

      また、一般性が欠如している、というよりも、一般性が欠如しているかもしれない知識を一般性があたかもあるかのように扱ってしまっている可能性がある、ということに問題を感じます。大抵、Threat of Validityの項目には実験に限界があることが書いてあるのですが、実験に限界があることは当たり前なので、言い訳にすぎないというかあまり意味がない気がします。

      Threat of Validityは大抵そりゃそうだ、みたいなことしか書いてない気がしますね。

      いいね

コメントは受け付けていません。