AST '06から

 AST'06(The first internatinal workshop on Automation of Software Test)から最近のテスト自動化に関する研究に対する傾向をまとめてみよう。
 このAST'06は、ICSE06で併設されたワークショップであり、今年が一回目。90件の投稿から15件の論文が採用されている。つまり、おおよそ16%程度の採録率。ワークショップとしては異常な高さに思えるが、最近のアジア(場所がアジア)/アジアン(コミュニティがアジア人中心)開催の傾向として見られる石の多い玉石混合な投稿状況だったと思われ。
 投稿された90件の論文の傾向を1.解決方式の観点 、2. 問題領域の観点から分類したのが以下の通りだ。

解決方式の観点

トピック パーセント
方法論 26.7%
技術・方式 83.3%
アプリケーション 36.0%
ツール・環境 40.0%
実例・経験によるもの 20.0%

 やはり、解決方式は技術・方式などが強い。これはすでに定義されたテストアクティビティをいかに機械的に実施するかという問題を解決するものだ。「どういう理由から、どういうテストアクティビティをどのように実施すればよいか」を示すような方法論や「どういうテストをしたらどうなったから何が分かったか」というような実例・経験ベースといった内容は少ないようだ。これはソフトウェア工学一般の傾向と変わらないと思うけど、やはり実際に使うことを想定した研究って物の比率が上がってほしい気がする。

問題領域の観点

トピック パーセント
テストケース生成 60%
テストプロセスやテスト環境の管理 32%
テスト実施ツール 24%
テストの妥当性基準、カバレージ測定など 16%
テスト判定(オラクル) 4%

 こちらはテスト生成が主流であることが分かる。これは、テスト生成という領域が、「有効性が高い」からなのか「新規的なテーマが出やすい」からなのかといえば後者であると思われる。このテストケース生成に関しては、多くが、設計仕様としてUMLのモデルや形式論理記述が存在していることを前提として、それらを入力としてテストケースを生成するという話である。この手の話は、研究的な分野としては面白いかもしれないが、やはり将来的な有効性を考えると、前提が真となる日が来るのか?という意味でどうも不安が残る。

 最後に、採録された論文から意味が分からないながらも興味深いキーワードをメモっておく

  • UMLアクティビティ図に対して高カバレージを満足するテストケース生成手法
  • システム要件とテストカバレージの関係について(なんのこっちゃ)
  • 実行履歴を用いた試験の段階的洗練方式
  • 少数の典型テストデータから、必要なテストデータを派生させて生成する方式(遺伝アルゴリズムとか使うのかね)
  • オブジェクト間をまたがるテストの自動実行方式(関連ありか)
  • コスト制限を考慮したテストケースの生成方式
  • 自動テストと手動テストの実際のコスト差の報告
  • バレージツール選定ガイドライン

参照はこれを見てください。