ICST2015まるわかりDayと紹介した論文について

標準

7月4日(土)に、ICST 2015 まるわかり Day というイベントが開催されました。

イベントでは、ICST 2015で採録された35本の論文を5分間のLT形式で紹介していきます。ICSTはソフトウェアテスト関連の有名なカンファレンスで、ここに採録された論文を眺めれば、最先端のソフトウェアテスト技術を知ることができるんです。

全体的にはテストケースの自動生成にまつわる話題が多かった印象です。ホワイトボックステストですと、シンボリック実行(コンコリック実行)、ブラックボックステストですと、仕様書(自然言語やビジネスルールなど)を解析してテストケースを導出するとかです。

私も1本論文を紹介しましたのでここに載せます。

紹介した論文

紹介したのは、「Perspectives on White-Box Testing: Coverage, Concurrency, and Concolic Execution」という論文です。日本語に訳すと、「ホワイトボックステストの見通し: 網羅、並行、コンコリック実行」でしょうか。内容は、著者らの研究成果を2つ紹介しています。いちおう共通のテーマでまとめていますが、ちょっと無理矢理感はあります。ただしそれぞれの内容自体はたいへん興味深いものです。1つは、テストの網羅性を制御するためのクエリ言語とその実行環境の開発です。以下の論文紹介のスライドに概要をのせましたが、ソースコードをデータベースとみなし、FQLというクエリによって、網羅したい条件を満たすテストデータをデータベースから取り出します。この概念は、コンコリックテスト(またはモデルベーステスト)を実用的に実施するためにたいへん重要です。現実のソフトウェアを対象としたとき、いまのコンピュータ資源をもってしても全網羅テストはコストが高く、部分網羅にせざるを得ないため、網羅するところを決められる手段が必要なのです。もう1つは、並列(マルチスレッド)プログラムにコンコリックテストを実施する理論と仕組みの構築です。きっと並列プログラムの問題はほかにも研究があるのでしょうけども、考え方が理解できるとナルホドガッテン(古い)でした。これもスライドで説明しましたのでご参照ください。

 


あらためて思いますが、紹介する立場になるとそれなりに読み込まないと説明できないので、理解が深まってよいですね。たいへん勉強になりました。

シンボリック実行を利用したソフトウェアの互換性確認にかんする考察と実験

標準

先日、ソフトウェア・シンポジウム2015というイベントに参加してきました。イベントでは様々なワーキング・グループが、それぞれソフトウェアに関連するテーマで議論をしました。私は「電脳テスト道具の活用」というテーマのグループに参加し、とっても刺激をうけて帰ってきました。その議論の中で、私が考察した内容についてご紹介しました。ここにその内容をまとめます。

はじめに

いまや人間社会は、ソフトウェアなしでは成り立たない状態です。インターネットは当然ながら、電気エネルギーや鉄道などの社会インフラから身の回りの家電製品まで、ソフトウェアは至る所に存在します。今後、車の自動運転、IoT(Internet of Things)や人工知能の応用が進めば、この流れはますます加速するでしょう。

さて、人間社会は変化します。諸行無常です。それゆえ、ソフトウェアが動作している環境(文脈)も変化します。環境の変化に対応するため、ソフトウェアは継続的に更新する必要があります。余談ですが、ソフトウェアはハードウェアと違って物理的な経年劣化がないですけども、ハードあってのソフトウェアなのでハードウェアの変更(64bit環境への移植とか)でソフトウェアのメンテナンスが必要になるってところは忘れがちです。
古いソフトウェアになればなるほど、変更の必要性は高まります。

下記の図は、IPAさんのデータから抜粋させていただきました。日本におけるソフトウェア開発の実態を示したものです。
2000年以降、新規のソフトウエア開発は減少傾向にあり、逆に派生開発(既存ソフトウェアの変更)の割合は増加傾向にあります。2013年では64%が派生開発でした。

trend

派生開発によくある課題ってなんでしょうか。ここでは3つを挙げてみます。

  1. 短い開発期間
    変更に必要な手間は過小に見積もられがち。
  2. 開発情報の不足
    変更前のドキュメントがない、担当者がいない。
  3. 変更前のソフトウェアとの互換性の確保
    互換性があるべきところが確かにある、ことをどうやって確認する?

いろいろ悩みはつきませんが、ここでは3つめの課題をとりあげて、解決の道筋を考察してみたいと思います。具体的には、互換性を確認するテストについてその課題を特定し、シンボリック実行(Symbolic Execution)という技術を応用した解決方法を検討します。

シンボリック実行とは、一言でいうと、ソフトウェア(プログラム)に存在する実行可能なパス(可達パスといいます)を通すような、入力データを自動的に生成する技術です。こちらのブログ記事がわかりやすいです。

なお、対象とする互換性は、ソフトウェアの論理的動作とします。性能など、そのほかの互換性は対象外です。また、変更の範囲は、ユーザーインターフェース(外部インターフェース)に影響のない範囲とします。これは、テストケースを再利用するための条件です。


テスト計画を作るときの4つの抑えどころ

標準

先日、ソフトウェアのテスト計画をたてるという、名誉あるミッションを任命された若手エンジニアと議論しました。彼女にとっては初めての領域であって、悩ましい課題がたくさんあったようです。ずいぶん長い間議論して(2時間以上やってた)私なりの考えを伝えたつもりですが、議論がとっちらかったのでここにポイントをまとめます。


 

  1. テストは探索的なもの、テスト計画はその性質を考慮する

    ソフトウェアテスト(に限った話ではありませんが)、あるいはシステムテストは、やってみないとわからない要素が多分にあります。これはソフトウェア開発行為が本質的に開発エンジニアの能力に依存していて、品質の特徴(どこがいいか、わるいか)も人に依存していることに一因があります。
    計画時にリスクを分析し、テストでどこを攻めるべきかを決めますが、よっぽどシンプルな開発でなければ想定通りになることはまずないでしょう。そこで、計画ではテストの活動を段階に分け、各段階で見直しをするよう、スケジュールやリソース配分を考えます。初期段階では、基本的で重要な機能やリスクが高いと判断した観点を確認し、検出したバグの内容を確認します。バグが出ない箇所は優先度を下げ、バグの出た箇所に関するテストの優先度を上げます。ここでテストの観点を新規に追加したり、より詳細に攻める(たとえば因子(条件)の組み合わせを増やす)など、テスト計画を修正し、早い段階でリスクを潰します。

  2. テンプレートとしてIEEE829-2008を活用する

    テスト計画で少なくとも考慮すべき事柄のチェックとして、テストに関連するドキュメントを体系的に定義したIEEE829-2008という規格を利用しましょう。
    この規格は、ソフトウェアに要求される品質レベルによって異なるテストのドキュメント体系を示したものですが、作りたいドキュメントのテンプレートとして活用できます。テスト計画は、マスターテスト計画書を参照します。また、テスト観点毎には、レベルテスト計画書を参照します。必ずしも該当のドキュメントを作成する必要はありません。テンプレートに定義された見出しのレベルで考慮の抜け漏れがないか確認することが大事です。例えば、「テストで対象としないもの」とか「テスト自身の品質確保方針」は不明瞭になりやすい事柄です。
    なお規格ではバグ連絡票(呼び方はいろいろ)などもテンプレートがありますので、他のドキュメントも参考になると思います。

  3. 製品やサービスが達成すべき品質を定義してテストと関連付ける

    テストの網羅性について議論するとき、網羅する地図をまず明確にする必要があります。さまざまな側面から地図を作ることができますが、もっとも大切なのは、ソフトウェアやシステムが達成すべき品質です。
    品質は可能な限り具体的に客観的に定量的に表します。品質を定義するときには、まず企画主旨を理解します。その製品またはサービスがユーザーにどんな価値を提供するのか、つまり何が「売り」なのかを把握します。企画会議の資料を眺めたり、プロジェクトオーナーに聞きましょう。
    さらに、当たり前なので暗黙的になっている品質の基準がないかどうか確認します。過去の製品との互換性とか、信頼性や安定性、セキュリティなどの機能以外の品質は隠れている場合があります。考慮すべき品質に漏れがないかチェックするために、ふたたび規格を利用しましょう。ISO規格にSQuaREISO9126(こっちのほうが情報が多い)というソフトウェア(システム)の品質特性を定義したものがあります。品質特性の一覧を眺めて、重要かそうでもないかを考えます。
    ※なお前述した品質特性の例は規格の定義と一致してません

  4. まずテストの妥当性、そしてバグ収束曲線

    バグの収束はソフトウェアがリリースできるかどうかを判定する有効な指標です。ただしテストを十分にやったことが前提です。上述のように、埋めるべき地図を埋めていること、リスクを潰すよう探索ができていることを確認します。その上で、バグたちが駆逐されつつあるかを確認します。リリースを判定する人への説明では、少なくともこの2段階のストーリーを含めると説得力が増すでしょう。


以上とりあえず大事なことを4つ挙げました。テスト計画から外れた話もあるじゃないかというつっこみはごもっともです。
次はテストアーキテクチャについて議論しよう!なんて一人で盛り上がっても気持ち悪い先輩だと思われるだけなので自粛します。

 


Symbolic Path Finder のセットアップ手順

標準

JAVA言語のシンボリック実行ツールであるSymbolic Path Finder(以下SPF)のセットアップ手順を説明します。

対象はWindowsおよびLinuxですが、筆者の環境で確認したものは、Ubuntu, Windows7 64bit, Windows8 64bit です。


JPF Pluginのインストール

 

eclipseから JPF を実行するため、Pluginをインストールします。手順は Mercurial Plugin のインストールと同様です。
Locationに下記を指定します:
http://babelfish.arc.nasa.gov/trac/jpf/raw-attachment/wiki/projects/eclipse-jpf/update

JPFの設定ファイル(site.properties)の作成

  • <user.home>配下に .jpf フォルダを作成します。
    ※ user.homeは、「Help>」->「Installation Details」->「Configuration」の中に記載があります。
    筆者の場合は「user.home=C:\Users\(ユーザ名)」です。
    ※ . (ドット) で始まるフォルダはGUIからは作成できないので、コマンドプロンプトから mkdir を使って作成してください。
  • .jpf フォルダ に site.properties ファイルを作成します。
  • 作ったファイルに下記を記載します:
    ※ jpf-coreフォルダがある場所を指定します。フォルダ区切りは / (スラッシュ)なのでご注意。

    jpf-coreのダウンロードとビルド

eclipse経由でMercurialレポジトリからjpf-core (JPFを動作させるための最小構成)をダウンロードします。

  1. File -> Import -> Mercurial -> Clone repository using Mercurial -> Next を選択します。
  2. Repository Locationに http://babelfish.arc.nasa.gov/hg/jpf/jpf-core を指定します。
  3. Next を押します。
    => jpf-coreのダウンロードが始まります。
  4. 画面にしたがってNextを押していきます。
    => Package Explorer に jpf-core が表示されます。
  5. 同時にjpf-coreのBuildが走ります。
    => Consoleに BUILD SUCCESSFUL と表示されます※ eclipse でダウンロードに失敗した場合は、ターミナルから直接ダウンロードしてみます。
    eclipse の workspace に移動し、以下のコマンドを実行します

    => jpf-core フォルダにファイルがダウンロードされます。
    – eclipse の project に jpf-core を登録します。
    File -> Import -> Mercurial -> Projects from local mercurial repository -> Next を選択します。
    – jpf-core フォルダがある場所を指定します。
    => Package Explorer に jpf-core が表示されます。
    – 同時にjpf-coreのBuildが走ります。
    => Consoleに BUILD SUCCESSFUL と表示されます。

    Mercurial Pluginのインストール

eclipse経由で JPF のソースをMercurialレポジトリからダウンロードするため、Mercurial Pluginをインストールします。

  • Windowsの場合、インストール手順は下記を参照してください:
    http://d.hatena.ne.jp/absj31/20120713/1342235177
    ※ 手順では codeBeamer も入れていますが、MercurialEclipse だけで大丈夫です。
  • Linuxの場合も上記と同様ですが、インストール対象から、”Mercurial Windows Binary” を外します。

    Mercurial のインストール(Linuxのみ)

    eclipse経由で JPF のソースをMercurialレポジトリからダウンロードするため、Mercurial 本体をインストールします。

ターミナルから以下のコマンドを実行します

eclipseのインストール

  • 下記のページよりWindows 32bit版eclipseまたはLinux x68版をダウンロードします。
    https://eclipse.org/downloads/
    ※ JDKが32bit版なので、eclipseも32bit版にします。64bit版を入れても動きませんのでご注意
  • Windowsの場合、解凍したフォルダを適当な場所(例:C:\Program Files (x86)\)に置き、eclipse.exeを実行してみます。
    => 起動することを確認します。
    なお、Eclipse Luna (4.4.1) で動作確認しています。
  • Linuxの場合、解凍したフォルダを適当な場所に置き、ターミナルから eclipse を実行します。
    なお、Eclipse 3.8 で動作確認しています。

Java Path Finderのインストール

  • JDK のインストール(windows, Linux共通)
    • 下記のページよりWindows x86版JDKをインストールします。(jdk-****-windows-i586.exe)
      ※ JRE ではなく JDK なのでご注意。(Javac コンパイラが必要なため)
      http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html#javasejdk
      なお、v8_25 で動作確認しています。
  • 環境変数JAVA_HOMEの設定 (windows, Linux共通)
    • Windows(Linux)環境変数にJAVA_HOMEを追加します。
    • 変数値に、JDKのインストール先フォルダまでのパスを設定します。
      例) C:\Program Files (x86)\Java\jdk1.8.0_25

動作確認

Package Explorer から、jpf-core/src/examples を選択し、
.jpf という拡張子のファイル(例:BoundedBuffer.jpf)を右クリック -> Verify… を選択します。
=> JPF が実行され、Console に結果が表示されればOKです。

Symbolic Path Finder のインストール

無事JPFがインストールできたら、いよいよSPFのインストールを行います。
※ インストール手順は http://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/jpf-symbc の情報にもとづきます。

  • JPFの設定ファイル(site.properies) の追記
    ファイルに下記を追記します:
  • jpf-symbc のダウンロード
    jpf-core と同様の手順で jpf-symbc をダウンロードします。
    Repository Location に http://babelfish.arc.nasa.gov/hg/jpf/jpf-symbc を指定します。
  • SPFのビルド
    Package Explorer から jpf-symbc -> build.xml を右クリックし、Run As -> Ant Build を選択します。
    => ビルドが始まります。 BUILD SUCCESSFUL と表示されたらOKです。
  • 動作確認
    Package Explorer から src/examples/demo を選択し、
    .jpf という拡張子のファイル(例:NumericExample.jpf)を右クリック -> Verify… を選択します。
    => SPF が実行され、Console に結果が表示されればOKです。

以上でインストールは完了です。お疲れさまでした!