読者です 読者をやめる 読者になる 読者になる

ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

「IoTの機能テスト」 #IoTテストアドカレ(15)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の15日目です。14日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Functional Testing for IoT』
  • 著者: Chris Riley
  • 参照サイト: DevOps.com

ポイント

IoTの機能テストのプロセス・ツールの課題

  • エミュレータの準備
    バイルのテストであれば、Sauce Labsなどのエミュレータがあるが、自分でデバイスを作る場合はエミュレーションの開発に時間をかけないとテストは不可能である。
  • プロダクトがフルに接続されたテスト環境の準備
    並行開発しているコンポーネントがまだ完成していないかもしれない。別のベンダーの所有物が利用できないかもしれない。
  • システムを流れるテストデータの取得
  • 品質の責任範囲の明確化
    末端からセンターまで関係するコンポーネントが多く、責任の所在を決めるのが難しい。

新しい解決策

 サービスがユーザ要求を満たしていることを担保するには、高度なテストの能力が求められる。

  • 強力なテスト戦略
    明確な要件、継続的インテグレーション、良好なコミュニケーションなど、効果的なテスト実行のためのテストの方法・プラクティスに焦点を当てる。

  • 新しいプラットフォームとテストツール
    莫大な量の生データから、次の行動につながる情報を効果的に引き出すために、高度なビューアーやシミュレータが必要。

  • グレイボックステスト
    効果的なテストケース設計のために、アーキテクチャ、OS、サードパーティーのハードウェア、ネットワーク接続のプロトコルなどを理解する必要がある。

  • リアルタイムOS
    タイミングが重要になるIoTにおいては、RTOSは中核技術。

  • テスト構成の自動化された環境
    オントロジーベースのテスト技法は、テストケースの生成と入力値の生成を自動化するアプローチにフォーカスしている。

  • 強力なバックエンド
    機能の多くがバックエンド側に固められていれば、そのテストは既存のツールで実行できるので、すべてが簡単になる。それをサポートするのがサービスの仮想化。

サービスの仮想化

 依存関係のあるコンポーネントの動作の一部をエミュレートすることで、テストインフラへの依存度を減らすことができる。以下のような場合に利用する。

  • リアルタイムなテストデータをテストできない
  • 環境がセキュアでないので、リアルタイムデータを開けない
  • テストが通常の業務を妨げてしまう

所感

 今回の資料は無線の話は軽めで、ソフトウェア的な話が中心ですね。

 「強力なバックエンド」というのは、モバイルアプリのロジックの持ち方についての以下の記事を参照しています。たとえば現在のモバイルゲームでは、いわゆるビジネスロジックをPaaS上においており、アップデートの多くはデバイスのコンフィグレーションファイルの書き換えになっているとのこと。

devops.com

 「テスト構成の自動化された環境」(Test environments with automated test configuration)は最初、「テスト環境を自由に変更できる」という意味だと理解していたのですが、ここではテストケースを自動生成できるような仕組みのことを指しているようです。
 オントロジーベースのテストについてはいくつか論文が公開されていますが、抽象的でとても難解です。たとえばこの資料(pdf)など、いかにもオサレかつ簡潔にまとめている感がありますが、やっぱりわかりません。

 そもそもオントロジーの時点でギブアップ気味なのですが、過去に読んだ本にその言葉が出てきていました。IBMのWatsonが米国のクイズ番組でチャンピオンを破るまでの話を描いた『IBM 奇跡の“ワトソン”プロジェクト』です(ありがとう、僕のEvernote)。

IBM 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる

IBM 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる

 ジョージ・ワシントンとは初代大統領か橋の名前か―そんな識別は、人間にとってどうということはない。文脈からおのずとわかる。橋は就任演説などしないし、ラッシュアワーに大統領で渋滞が起こってて、ニュージャージーからの通勤に三十分の遅れが出るなどということもない。何より、センテンス中に置かれたとき、人間と道路や橋とでは振る舞い方が違う。
 だが、人間にとって簡単なことが、コンピュータには困難きわまりない。まず、質問の構造を調べて主語と目的語と前置詞を拾い出し、次いで、業界内に何十年にもわたって創り上げられてきた網羅的な参照リストにあたる。ここには何十万という場所・物・動作と、それらの間に網の目のように張り巡らされた関係が記されている。このリストの一つ一つを「オントロジー」と呼ぶ。いわば、コンピュータのカンニングペーパーだ。たとえば finger が主語として使われていれば、それは人体構造分野に属する言葉であり、hand に関係しているか、to point や to pluck などの動詞に関係している。だが、the finger のカタチで to give という動詞の目的語になっているのなら、コンピュータは侮辱や卑猥な身振りなどの分野を探らなければならない。この識別には、かなり高度なオントロジーが必要になる。

 テスト対象のソフトウェアにおけるいろいろな要素とその関係性に関する知識をリスト化して、そこからテスト内容と入力値・期待値を導出する、というアプローチでしょうか。同様にテストケース自動生成につながるモデルベースドテストや形式手法とはまた別の技術のようにも思えます。

 16日目はコチラです。(12月16日の0時に公開されます)

kzsuzuki.hatenablog.com