Technical Information

これからのソフトウェアをどうやってテストしよう

asset_approach_column_advanced-software-test05_hero.jpg

いつの時代も、ソフトウェアテストは重要です。継続的インテグレーションやテスト駆動開発といった、ソフトウェアテストを軸にした開発のパラダイムも生まれています。ソフトウェア開発が続く限り、ソフトウェアテストの重要性は失われないでしょう。初期のソフトウェアは単独のコンピューターで動作するものでしたが、コンピューターがネットワークを経由して他のコンピューターとつながるようになり、コンピューターシステムもソフトウェアも次第に複雑になっていきます。今では、周囲の物理的な状況をセンシングして挙動を変えるソフトウェアがあります。その代表例がスマートフォンアプリケーションです。GPSによって取得した位置情報に応じてユーザーがいる場所の付近の情報を提示するものなどがあります。また、加速度センサーや傾きセンサーなどの各種センサーのデータを用いるものもあります。ソフトウェアが複雑になる一方で、ソフトウェアテストの手法やツールも進化しています。Webインターフェースのテストのためのツールや、ソフトウェアが稼働するサーバー環境自体をテストするServerspec※1というツールも出てきています。

※1:Serverspec:https://serverspec.org/

湯村 翼 氏写真

国立研究開発法人
情報通信研究機構
博士(情報科学)
湯村  翼 氏 

20年後の未来を考えると…

20年後を考えるために、まず20年前を振り返ってみましょう(図1)。
20年前は、ポケベルが使われなくなり、PHSやiモード携帯が出始めた時期です。モバイルデバイスの進化が大きかったモバイルデバイスが急速に進化した時代ですが、進化したのはモバイルデバイスだけではありません。PCも、Windows98、Windows2000といったOSが登場し、一般家庭にどんどん普及していった時期でした。

それから20年後の現在、ガラケーを使う人は減り、スマートフォンが普及しています。 Fitbitのようなウェアラブル端末、Amazon Echoのような家に配置するデバイスが広がり、「ウェアラブルコンピューティング」「ユビキタスコンピューティング」といった技術が生活に密着した形で実装され始めました。バーチャルリアリティの技術を使ったヘッドマウントディスプレイでゲームするといったことも広がっています。

これらを実現するための画像処理や音声解析といった技術は、目には見えませんが、バックグラウンドで「機械学習」が支えています。
そして、20年後を予測したいところですが……正直どうなるかわかりません。

本稿では、ソフトウェアテストという切り口ではあまり語られないけれども、20年後にも存在していそうな技術分野・テーマを取り上げます。ユーザーインターフェース、センサーデータ、エンドユーザープログラミング、自動運転車、無線エミュレーションに関するテストについて、現状の課題を整理し、それらの解決の糸口となりうるツールや研究を紹介します。これらのツールや研究にはまだ実用には耐えうる段階ではないものも含まれるかもしれませんが、そのコンセプトに未来のソフトウェアテストを見据えるためのヒントがあるかもしれないと思っていただければ幸いです。

ソフトウェアが扱う対象は次第に広がっていく

図1:ソフトウェアが扱う対象は次第に広がっていく

新たなユーザーインターフェース

コンピューターは、要素を単純化した5大装置というモデルで表されます。5大装置の中で人間とコンピューターの接点となるのが入力装置と出力装置です。コンピューターの代表的な入力装置はキーボードとマウス、出力装置はディスプレイで、これらは内部のしくみの変遷はあるもののコンピューターの初期の頃から現在まで長い間利用されています。加えて、スマートフォンの普及により、入力装置と出力装置が一体となったタッチパネルディスプレイも広く利用されるようになりました。入力装置と出力装置を用いて、人間とコンピューターで情報を伝達するための境界はユーザーインターフェースと呼ばれます。物理的な入出力装置に加えて、出力装置に表示される画面もユーザーインターフェースに含まれます。ユーザーインターフェースのテストは、すべて手動で行われているわけではなく、さまざまな方法で自動化が進められています。例えばWebやアプリケーションの画面の任意の箇所をクリックする処理をソフトウェアとして行うSeleniumやAppiumというテストツールが使われています。

街中で情報を掲示するデジタルサイネージには、ジェスチャーによって操作する端末もあります。通常、ジェスチャー入力を用いるソフトウェアをテストするためには、開発者やテスターが体を動かしてジェスチャーを行い、それに応じた動作をチェックします。同じ動作を何度も繰り返すことになるため、これは肉体的にも非常に過酷な工程になります。
これを解消するための提案がKinect Doll※2です。Kinect Dollは、板を組み合わせて肘などの関節で結合した簡易的な人形です。これを用いて、ジェスチャー入力で用いられるボーン(人の骨格)を形作り、任意のポーズを取らせます。人がポーズを取る代わりに人形に肩代わりさせることによって、開発と検証の負担を減らします。

今後、より多種多様なユーザーインターフェースが登場すると予想されます。最近では、スマートスピーカーのような音声入力を用いた新しいインターフェースのデバイスも登場し、HoloLensやOculus Questといったヘッドマウントディスプレイも普及し始めています。このように、入出力装置というのは、技術の進化に伴ってどんどん増えていきます。それに合わせ、新しいインターフェースに適用したテストツールが出てくるのではないかと考えられます。

※2:Kinect Doll:https://www.youtube.com/watch?v=syY26n7ponM

状況に応じて振る舞いを変えるアプリケーション

周囲の状況の情報を用い、状況に応じて振る舞いを変えるアプリケーションのことを「コンテキストアウェア・アプリケーション」と呼びます。コンテキストにはさまざまな種類があります。例えば、場所や建物などの空間的コンテキストや、時刻や曜日など時間的コンテキストがあります。コンテキストの分類は、サーベイ論文 Knappmeyer et al. 2012※3にまとめられています。

例としてスマートフォンやIoTデバイスについて考えてみましょう。
これらに搭載されるソフトウェアは、センサーを用いて周囲の状況をセンシングし、コンテキストを用いて動作します。そのため、テストを行うには物理的な情報が必要となり、テストの自動化が難しくなります。スマートフォンのセンサーデータを用いたアプリケーションをテストするために、TestAware※4というツールが研究開発されています。TestAwareは、取得したセンサーデータや擬似的に生成したセンサーデータをデータベースに貯め、テスト時にこのデータを再生してテストに用います。また、同様の目的のContextMonkey※5というツールでは、カメラアプリのテストのために現地で撮った写真の代わりにGoogleストリートビューの画像を用います。

現在、身に付けるものや建物の中など、あらゆるところに小さなコンピューターが埋め込まれます。コンピューターの数は今後も増え続け、ソフトウェアはさまざまなものに搭載されるようになっていきます。それに伴い、周囲の状況を生成するテストツールも重要となっていくでしょう(図2)。

コンテキストアウェアのイメージ

図2:コンテキストアウェアのイメージ

※3:Knappmeyer et al. 2012:https://uwe-repository.worktribe.com/preview/936196/Survey_of_Context_Provisioning_Middleware.pdf
※4:TestAware:https://github.com/cluo29/TestAWARE
※5:ContextMonkey:https://github.com/manojrege/contextmonkey

ユーザー自身が開発したシステム

これまで、システム開発は、専門的な知識を持つ開発者が行うものでした。デバイスやアプリケーションにできることが増えると、それをユーザーが使いこなすことが期待されるため、専門的な知識を持たないエンドユーザーが簡易的なシステム開発をするというケースも増えていくでしょう。

IFTTT(イフト)というアプリケーションがその一例です。IFTTTは、さまざまなWebサービスやIoT製品と連携して稼働します。サービスや製品は、トリガーまたはアクションという動作として定義されています。IFTTTのユーザーは、トリガーとアクションという2種類の動作を組み合わせ、自分だけのルールを決めることができます。例えば「会社を離れた時に家のエアコンをつける」や「家から離れたら家の鍵を自動で閉める」といったものです。IFTTTを使えば、自分だけのシステムを簡単に作ることができます。

他にはMESHという、簡単な IoT システムを構築できる製品もあります。MESHは、人感センサーや温湿度センサーなどの機能を持った物理的なブロックを組み合わせてシステムの部品として使用します。iPadの画面上で線をつなぐことによって、システムの動作を決めます。いわゆるビジュアルプログラミングを行います。

IFTTTのようなアプリケーションは、専門的な知識を持つ開発者だけではなく一般のユーザーが使い、構築したシステムがうまく動作しない際には一般のユーザーがデバッグを行うことになります。このような一般ユーザーのデバッグを支援するために研究されているのがEUDebug※6です。EUDebugは、IFTTTのようなTrigger-Action型のルールで起こりうる3種類の問題「ループ」「矛盾」「冗長」について静的解析し、問題があった場合にはユーザーに提示します。

自動運転車

自動運転は、現在ソフトウェア技術の研究開発が非常に熱い領域です。Uberは、自動運転のテストを行うために、開発拠点のある米ペンシルベニア州ピッツバーグ近くに東京ドーム50個分のコースを建造中です。そのコースの中で自動運転車を走らせ、道路状況や標識の認識、車の前に擬似的な歩行者を飛び出させて車の安全機能を確認します。とはいえ、このような街スケールの大規模なテスト環境を用意できる企業や研究所は限られています。そこで、シミュレーションなど仮想環境を活用したテストが重要になってきます。

自動運転車の開発では、学習データを集めるために、コンピュータグラフィクス(CG)による仮想環境の構築が最近よく行われています。これには、UnityやUnreal Engine4といったゲームエンジンも活用されています。その仮想環境の中で車を走らせ、LiDARセンサー※7やカメラでの物体認識の学習を行います。Microsoftが開発するAirSim※8 は、オープンソースの学習用仮想環境です。ゲームエンジンで構築した仮想環境の中で自動車を走らせて学習を行って運転の精度を高めていくというものです。現在、そのような目的のツールは、自動運転と機械学習を研究開発する企業や研究所でしのぎを削って開発が進められています。

仮想環境を活用したテストは、自動運転が大きなターゲットですが、今後はスマートシティ開発において、街中にセンサーやアクチュエーターが多数設置された際の挙動を調べることなどが考えられます。そのような大規模なテストを現地で行うのは非常に大変なので、シミュレーションや仮想空間を用いたテストの有用性がより強調されていくでしょう(図3)。

ちなみに、CGによる仮想環境を用いたテストの歴史をさかのぼると、HPが2002年に行っていたUbiwise ※9という研究にたどり着きます。これは、CGでつくった3次元仮想空間の中で、デジタルカメラのテストを行うというものです。デジタルカメラのバーコード読み取り機能を、角度などの条件を変えて読み取れるかどうかなどをテストするものでした。

無線エミュレーションのイメージ

図3:無線エミュレーションのイメージ

仮想ネットワーク空間

ソフトウェアがさまざまな場所に点在するようになると、その環境を模した環境でテストが必要になってきます。例えば、店舗や自動販売機の来店検知や博物館などのナビゲーションといった屋内の測位を行うアプリケーションのテストです。

私が所属する国立研究開発法人情報通信研究機構(NICT)では、ネットワークテストベッドStarBEDを活用したソフトウェアテストの研究開発に取り組んでいます。テストベッドとは、大規模なシステム開発で用いられるテスト用プラットフォームの総称です。 テストベッドは、現実世界で運用されているシステムを危険にさらすことなく、実際の運用体制に近い状況で稼動させる目的で使われます。StarBEDでは、1000台規模のPCノードを用意し、それらを接続してクローズドなネットワークを構築しています。その中で、例えば仮想的なインターネットを作るなど、そこでしかできないネットワークの実験を行っています。現在は、コンピューター上のソフトウェアテストだけではなく、ネットワークに影響を及ぼす電波伝搬などの空間の情報をいかに取り入れてテストを行うかということを研究対象とし、空間情報を含めたネットワークのシミュレーションとエミュレーションの研究に取り組んでいます。

その一つがBluetooth Low Energy(BLE)のエミュレーションの研究です。Bluetoothのような無線通信は、通常は送信機と受信機を用意し、それらを用いてフレームを送受信することで実験や検証を行います。我々が研究開発しているエミュレーターはそれを送信機受信機の実機は用いずに全てコンピューター上で無線の送受信と同じことを行います。

無線を用いるシステムのテストには実機を用意したり設置したりするコストが伴いますが、エミュレーションを用いることでそのコストの削減に寄与できるのではないかと考えています。Bluetoothのような近距離無線通信であれば実機を用いた際の手間も小さいですが、LoRa※10
NB-IoT※11のような数km〜数十kmの伝送距離を持つLPWA と呼ばれる無線では、一対一の通信を検証するだけでも非常に大変となります。そのため、エミュレーションを用いたテストの有用性はより大きくなるでしょう。

※6:EUDebug:https://elite.polito.it/research/research-topics/488-eudebug
※7:「Light Detection and Ranging」の略。ライダー。レーザー光を走査しながら対象物に照射してその散乱や反射光を観測することで、対象物までの距離を計測したり対象物の性質を特定したりする光センサー技術。
※8:AirSim:https://microsoft.github.io/AirSim/
※9:Ubiwise:https://www.hpl.hp.com/techreports/2002/HPL-2002-303.pdf
※10:ローラ、少ない消費電力で広いエリアをカバーする無線通信方式の一つ
※11:「Narrow Band-IoT」の略。スマートフォンなどで利用されるモバイル通信技術である「LTE方式」の中でも、IoT機器向けの規格

おわりに

仮想環境を用いたテストの話をすると「実地でのテストは無くなるんですか?」と聞かれることがありますが、シミュレーションや仮想環境があれば全てのテストを実施できるとは思っていません。あくまでも最終的には現地テストを行うという前提で、事前にソフトウェアの検証を進めておくことによって、現地での検証の手間を省くというものと考えています。

機械学習やIoTなどの技術の進歩や潮流の変化とともに、ソフトウェアの役割が広がっています。それに伴い、ソフトウェアテストの形は進化していくでしょう。
エンジニアは、この流れに乗っていく必要があります。
未来の技術がどうなっているか考えることは楽しくもありますし、その技術が登場したら、それをどのようにテストするか考えることも楽しいと思います。
本稿をきっかけに未来の技術とテストに想いを馳せてみてください。