本連載第一回から四回において、順序組み合わせテストとIDAU法について説明してきましたが、第五回以降の連載では湯本が確立したテスト手法であるIDAU法の応用研究について武田から説明したいと思います。第五回ではIDAU法のテストプロセスをツール実装し検証した研究について、第六回ではIDAU法をソースコードレベルのテストに適用するために独自の拡張を加えたCode Based IDAU法(CB-IDAU)の研究について、第七回ではCB-IDAUをバグ予測モデルのメトリクスとして応用したグラフ解析モデルについて連載していく予定です。
IDAU法のテストプロセスのおさらい
湯本の研究により、IDAU法は順序組み合わせやデータとその操作に着目したテストケース抽出技法として理論が確立され有効性も実証されました。この新しいテスト技法を実際のソフトウェアテストの現場で有効に利用する手段として、必要なインプット情報を与えれば、IDAUのテストプロセスに従い、自動的にテストケース候補を出力するテストツールの実装が有効な手段となります。またツール化により多くのソフトウェアテストに対する適用検証が可能になり、新たな研究課題の発見が期待できます。そのため、IDAU法の応用研究の最初のステップとして、IDAU法のテストツール実装を行いました。ツール実装するにあたり、まずはIDAU法のテストプロセスと実行/適用のための前提条件/制約事項について、論理的に正しく理解する必要があります。以下にこれまでの連載でも述べたれてきたIDAU法のテストプロセスについて整理します。
1.設計ドキュメントから変更が発生する機能P{Ta}、影響を受ける機能S{Ta}、関連するデータDsを抽出する。
2.拡張CRUD図を利用して各機能のデータ操作がCRUDの何れに該当するか確認する。
3.CRUD Matrixを利用してテストケースとして抽出するか否かを判定する。
4.テストケース抽出
IDAUテストツール実装
先行研究であるIDAU法の検証では、航空チケット予約システムのワークフロー情報がインプット資料として与えられましたが、今回、ツール実装の動作確認用としてAWS上にIDAU法と親和性が高いブラウザからマイクロサービスとKey-Value Storeを用いたRestfulなAPIサービスのプロトタイプを作成して実装を行いました。APIは発行するクライアントはJavaScriptを持つHTMLスクリプトをS3上にホスティングし、APIの処理にはAPI-Gateway、マイクロサービスとしてLambda、Key-ValueストアとしてDynamo-DBを利用した、以下のような簡易なシステムをツール実装のためのプロトタイプとして作成しました。さらに、このシステムの構成情報をYamlで記述することで、自然言語の仕様書ベースではなく、Yamlフォーマットのシステム構成情報を構文解析することにより、自動でIDAU法に必要な、全機能とデータ操作種別のCRUD情報をプログラムで自動解析しました。
図４のシステムをAWSに構築するための記載したYamlファイルを、IDAU法のインプット情報である機能仕様書と見立てて、Yamlファイルの構文解析による、IDAU法を用いた自動テストケース抽出ツールをPynthonにて実装しました。以下に、実際のJupyter note bookの出力を基にプロセスを記載します。
1.Yamlファイルを構文解析して、システム内に構成される機能であるマイクロサービスの実装仕様を表しているAPI-GatewayのRestfulのメソッド属性を解析することで、マイクロサービスの各機能がデータストアであるDynamo DBに対して、Create, Update, Read, Deleteのどの属性の処理を実施しているかを把握する。
2.Yamlを構文解析した結果から、全機能組み合わせに対する拡張CRUD図を作成する。
3.CRUD Matrixを抽出ルールとして実装し、各テスト実行の順序組み合わせがテストケースとし抽出されるべきか判定を行う。
4.テストケース抽出を出力する。
テスト対象と検証
実装したツールの検証を行うために、IDAU法を適用可能な前提条件を満たすテスト対象となるシステムを準備する必要があります。今回の研究では、下図8に示すTomcatのアプリケーションサーバを管理する、管理ウェブクライアントをテスト対象としました。
TomcatはJavaのアプリケーションサーバ実装のソフトウェアです。Tomcatをアプリケーションサーバとして利用する場合、Javaで実装したウェブアプリケーションのアーカイブファイルである、WarというファイルをTomcat Application Serverの特定のディレクトリに配置するDeployや、アプリケーションサーバや、アプリケーションのStart/Stop、不要になったアプリのDeleteなど、Warファイルに対する様々な操作が必要になります。Warファイルをデータ、管理ウェブクライアントのオペレーションをデータに対する操作、それらのステータスがTomcatアプリケーションサーバとして保持されている状態は、IDAU法の論文で定義された下図9のIDAUの適用モデルに類似していることが分かります。
また、IDAU法を適用するには、データに対する操作がCRUDにおける、どの操作に該当するのかを簡単に把握できる必要があります。Tomcatの操作の定義は自然言語で各メソッド実装のJavaDocに記載されており、各操作はCRUD操作に容易にマッピングすることが可能です。以下にそのイメージを記載します。
表1 操作とCRUDの関係
| ID | API仕様 | CRUD |
|---|---|---|
| 1 | list – List the context paths of all currently installed web applications for this virtual host. Each context will be listed with the following format path:status: sessions. Where path is the context path. Status is either running or stopped. Sessions are the number of active Sessions. |
R |
| 2 | deploy – Install and start a new web application attached to context path /xxx, based on the contents of the web application archive found at the specified URL. |
C |
| 3 | reload – Reload the Java classes and resources for the application at the specified path. |
U |
| 4 | resources – Enumerate the available global JNDI resources, optionally limited to those of the specified type (fully qualified Java class name), if available. |
R |
| 5 | server – Display system OS and JVM properties. |
C |
| 6 | sessions – Deprecated. Use expire. |
R |
| 7 | expire – List session idle time information about the web application attached to context path /xxx for this virtual host. |
D |
| 8 | start – Start the web application attached to context path /xxx for this virtual host. |
U |
| 9 | stop – Stop the web application attached to context path /xxx for this virtual host. |
U |
| 10 | undeploy – Shutdown and remove the web application attached to context path /xxx for this virtual host and remove the underlying WAR file or document base directory. |
D |
| 11 | findLeak | R |
| 12 | vminfo – Write some VM info. |
R |
| 13 | thread dump – Write a JVM thread dump. |
C |
結果と考察
結果として、上記のTomcatのクライアントサーバーシステムの機能情報をインプット情報とし、IDAU法の実装ツールを適用し、IDAU法で抽出すべき78ケースが自動的に抽出可能であることが、実際のシステムを対象として確認できました。
表2 ツール実行結果
| ID | Method | Test Case Number |
|---|---|---|
| 1 | IDAU Test Tool | 78 |
IDAU法のツール実装や自動化という観点では、さらに多くの事例に適用しコスト効果を計測して、その有効性や適用可能な前提条件の検証を深めていく必要がありますが、今回のIDAU法の応用研究では、これらのツール実装の過程にて考えられる以下の仮説が、さらに後続の研究に続く主たる目的になります。
まず、IDAU法のテストプロセスをツール実装する過程において、Input情報である業務フローの理解や、データに対する各操作がCRUDのいずれに相当するのかというアノテーションを付けていく作業の作業が、マニュアル作業であり自動化が難しいのと、データと操作の情報が全てインプット情報に記載されていない可能性や作業ミスによる漏れが避けられない可能性が考えられます。ツール実装の動作確認においては、Yamlにより形式的にシステムの仕様を構文解析で機械的に読み込めるようにしましたが、実際のシステム開発のテストにおいては仕様ドキュメントが何かしらの形式言語で100%記載されていることは稀なケースです。また、先行研究のIDAU法の検証においては、テストケースの抽出率の高さである正確度(Accuracy)のみに着目しており、偽陰性や偽陽性については評価されていませんでした。さらに処理フロー、と操作CRUD情報さえ分かれば、本来IDAU法がターゲットしていたシステムテストフェーズにこだわる必要もないことも分かりました。このことから、研究では、今後の後続研究のために、以下の２つの仮説を立てて、簡単なフィージビリティ検証を実施しました。
仮説１．３番地コードに変換した後のCFGに変換したプログラムのグラフ構造データは有限の呼出関係により構成された閉塞有向グラフとして表現が可能であり、そのグラフ構造からIDAU法に基づく２部グラフを抽出することが可能である。
そのため、IDAU法が当初適用対象としていた設計ドキュメントをインプットとしたシステムテストや機能結合テストフェーズよりも、プログラムの単体テストの方がツール化やテスケース抽出性能の観点からは親和性が高いのではないか？
仮説２．バグ解析のメトリクスとして応用可能ではないか？
IDAU法をソースコードレベルのテストに応用する過程において、3番地コードに変換されたCFGが生成され、この数学的グラフ構造に対して数学的な徴量を識別することが可能であるため、IDAUや数学的な特徴量を組み合わせることで、ソースコードに対する静的バグ予測モデルとしての応用が可能ではないか？
仮説に対するフィージビリティ検証
本研究では考察にて立てた２つの仮説について、今後の後続研究として研究テーマになり得るかは判断するための、簡易なフィージビリティ検証を実施しました。それぞれの詳細な説明については、次回以降の連載にて記載する予定なので、今回は概要と検証結果のみ示します。
仮説1 に対するフィージビリティ検証
今回、テスト対象としたTomcat Client実装のうち、WarファイルをデプロイするJavaメソッドのコードに対して、３番地コードに変換されたCFGを生成して、ソースコードレベルでのIDAU法の適用を行い、テスト対象となり得る２項部分グラフの抽出を試みました。結果として、5755個のテストケースを抽出でき、実現可能であることがわかりました。図10に実際の３番地コードの一種であるJimpleコードに変換されたCFGの一部と、CRUD情報のアノテーションのイメージを示します。
図10 CFGとCRUD情報のアノテーションイメージ
仮説2 に対するフィージビリティ検証
同様にTomcat Client実装のDeployメソッドのソースコードを用いて、仮説１で導出したソースコードレベルのIDAU法の結果情報に加えて、数学的な特徴量である、中心性(図11)とコミュニティ(図12, 図13,図14)の計算を行い、プログラム構造と特徴量との関係を可視化してみました。数学的なグラフ計算と可視化にはRのigraphライブラリを用いました。結果として、数学的なグラフ特徴量で重み付けされる箇所とIDAU法でテスト対象とされる箇所にはばらつきがあり、且つ、数学的な特徴量とソースコードにおいてバグが発生しそうな箇所とは相関性がありそうな結果が出ており、それぞれをバグ予測のメトリクスとしてバグ予測が可能であるという仮説は、実際にはさらに大規模なデータとより多くのメトリクスを説明変数として用いて検証する必要がありますが、検証してみる価値はありそうな感触が得られました。
図11 ボナチッチパワー中心性特徴量をCFGに重み付けした例
図12 リンクコミュニティ特徴量をCFGに重み付した例
図13 リンクコミュニティ閾値計算
図14 リンクコミュニティメンバーシップヒートマップ
まとめ
今回は、IDAU法をツールとして実装して実際のシステムに適用してみた結果と、その過程で導き出した２つの仮説に対する簡単な検証結果について説明しました。結果として、いずれも小規模で簡易な検証ですが、実現性はありそうだということが分かったため、後続の研究としてこらら２つの仮説に基づく新しい２つのテスト「CB-IDAU」と「GMT」を後続研究として掘り下げていきます。次回の第六回の連載では、IDAU法をソースコードのテストに応用した「CB-IDAU」の研究について説明したいと思います。
第1回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第2回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第3回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第4回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第6回：波及全使用法(IDAU)をソースコードレベルのテストに応用したコードベースド波及全使用法(CB-IDAU)
