JUnit^参考1のような標準的なテストスクリプトや、Jenkins^参考2等のCIサーバーの普及により、近年ではモジュール単体のテストでは、テストを手動で実行させることは少なく、JUnitなどのスクリプトで自動実行することが標準的となりつつあります。CIサーバーを導入して回帰試験の自動化を行うようなシステム開発であれば、以下のようなプロセスでテストが実施されます。

このように、JUnitのようなテストスクリプトとJenkinsのようなCIサーバーで回帰テストの自動化ツールを用いることで、テスト工程を自動化、高速化する事が標準的になってきてはいるものの、テスト項目を考えたり、テスト対象モジュールを駆動させるためのインプット情報であるテストデータを考えたり、それらを自動化するためのテストスクリプトをコーディングする作業は、変わらず手作業で行われているのが現状です。

テストの作業を効率化する技術には様々なものがあります。一般的に知られている手法としては、テストケースの組み合わせ抽出技法の「直交表」「All-pair法」「境界値テスト」「同値分割」などがあります。また、テストケースやテストスクリプトを自動で生成するためのテスト手法として「モデルベーステスト^参考3」があります。このようなテスト技法や自動化ツールを利用したとしても、現実的に実行可能なテストスクリプトの作成までを全自動で実施してくれるテスト自動化ツールはありませんでした。一方、近年Symolic Execution^参考4と呼ばれる技術が注目を集めています（JPF^参考5、JCUTE^参考6、KLEE^参考7、CREST^参考8など）。

これまでのテスト技法やモデルベース技法は、単にテストを効率化するための考え方や枠組みを用意するに留まり、テストデータを作成するのは常に人間の作業でしたが、Symbolic Executionでは、どのようなテストデータを用意すれば対象のテストコードを実行可能かという問題を、具体的な計算により解決してくれます。テスト対象のコードをツール内部で抽象化し、制約充足問題（CSP）^参考9を解くことにより、実行ルートの導通可能なテストデータを計算します。多くの実装ツールでは、テストデータの算出とともに、そのテストデータを含んだテスト実行可能なテストスクリプトも同時に生成します。この技術を応用すると、カバレッジテストに限定されますが、テストプロセスとして必要な（1）～（3）の作業のほぼ全てを自動化することが出来ます。しかしながら、そのようなテストの自動化を実現するには様々な問題が存在します。

Symbolic Executionの技術は研究分野では実績があるものの、実際のシステム開発の現場で広く利用されるまでには至っていません。その一つの理由として、解析性能の問題があります。テストする対象のプログラムが数値だけを扱うような単純なプログラムの場合は、テストデータを算出することは容易ですが、現実のソフトウェアプログラムは以下のような要因で非常に複雑な構成になっており、Symbolic Executionが適用できない場合が多いためです。

近年ではDynamic Symbolic ExecutionやConcolic Execution^参考10のようなアプローチも有りますが、i～iVが問題となることは共通しています。

NTTデータでは、テストデータが自動生成できないテスト対象の複雑性の問題を独自の手法で克服することで、100%ではないもののある程度の確率でテスト対象コードからテストデータ、テストスクリプトを完全に自動生成できる解析エンジン（GOYA^参考11）を開発しました。そしてこの技術をNTTデータの単体試験自動化ツール（TERASOLUNA RACTES for UT^参考12）に組み込むことで、全く新しい単体テスト自動化ツールを作成し社内に展開しはじめています。

このテスト自動化ツールは、テスト対象のソースコードに対して構造の解析を行い、自律的にテストデータの作成からJUnitのコーディングまでを全自動で行います。StringデータやJavaBeansのような構造体を持ったテスト対象でも、独自の手法で構造解析を行うことで、ある程度のカバレッジが抽出可能なJUnitコードを生成可能です。また、DIコンテナを利用した試験対象コードや外部参照をしているコードであっても解析が可能です。

テスト対象コードからテストデータを抽出しているため、完全なテストデータを作成できている訳ではないですが、導通可能なテストコードをテストデータ込みで完全に自動生成できるため、JUnitコードの生産性向上に寄与します。

今後は更に解析性能を向上させるとともに、インプット情報を設計書やインターネット上のドキュメント情報にまで広げることで、カバレッジレベルの自動テストからさらに業務的な意味も含んだテストの自動化を目指しています。