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

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

「IoTテストの3つの課題」 #IoTテストアドカレ(8)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の8日目です。エッこれでまだ1/3ですか? 7日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Internet Of Things. Introduction & Testing Challenges』
  • 著者: Kelly Hill
  • 参照サイト: RCR Wireless News

ポイント

 SIMカードを通じたセルラーネットワークの接続に取り組んできたCisco Jasper社がWiFiの接続にも手を伸ばすにあたり、単なる無線の機能検証を超えた3つの課題を挙げている。

サプライチェーン内での接続機能の担保

 IoTデバイスのサプライチェーン(部品製造・組み立て・販売・消費者)は、地理的にはグローバル、時間的にも数か月単位。チェーン内部の必要なタイミングで必要な接続性を発揮できることをテストしなければならない。
 たとえば、製造工程において必要な最低限のモバイルネットワーク接続や、販売先において顧客に機能を見せるためのネットワーク接続など。

セキュアなネットワーク権限の担保

 適正でセキュアなネットワーク権限に基づいてデバイスが構成されていることをテストで確認する。
 たとえばコネクテッドな*1自動販売機について、一部の人間だけが通信できて、他の人間やマシン同士の通信は限定しないといけない。

IoTデバイスの平常時のふるまいの理解

 IoTデバイスが平常時にどうふるまうかを把握しなければいけない。
 たとえば水道メーターでは、起動は1日1回、ネットワークへの通信は1回あたり数キロバイト、といった情報。期待するふるまいを適切に設定できれば、テストも可能になるし、配備後のモニターもできる。

所感

 2016年にCiscoに買収された、IoTサービスプラットフォーム事業者・JasperのTheresa Bui Revon氏へのインタビュー記事です。2つ目の「課題」はほかの記事にもあったものですが、1つ目と3つ目は目新しいですね。

 1つ目の課題について、前日の記事でもIoTデバイスのライフサイクルに言及があり、R&Dといった開発前段階から、量産以降までのテストを扱っていました。本日の資料ではこの後半部分にも焦点を当てており、量産以降の接続性の担保を強調しています。このブログは基本的に、ソフトウェアのテストをテーマに書いていますが、IoTという文脈においてはハードウェアのサプライチェーンから意識する必要があるのですね(組み込みでもそうでしょうけれど)。

 3つ目は、テストに限らず、リリース後の運用にまで含めた観点です。
 IoTでなくとも、サービスを運用しているサーバーのリソース使用率や、ネットワーク機器のI/O状態の「平常状態」を押さえたうえで、テストなり運用において異常がないかを確認する必要があります。ただIoTにおいては、その対象となるデバイスの数と種別が段違いになるので、別の難しさがありそうです。

 詳細レポートはこちらからダウンロードできるようなので、このアドベントカレンダーの後半で扱うかもしれません。
 9日目はコチラです。(12月9日の0時に公開されます)

kzsuzuki.hatenablog.com

*1:connectedという過去分詞がこのようにナチュラルに使われだすと、今後どう訳されていくんでしょう。「接続された」だと、IoTの文脈でのconnectedの意味を失ってしまうため、ここでは「コネクテッドな」という表現に逃げています。

「モノのインターネットの紹介とテストの課題」 #IoTテストアドカレ(7)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の7日目です。1週間も終わっていませんが、すでに息切れ感がありますよ。6日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Internet Of Things. Introduction & Testing Challenges』
  • 著者: Tony Opferman
  • 参照サイト: ROHDE&SCHWARZ ※リンク先は外部ページです

ポイント

IoTの概観

  • IoTのデバイスは「3つのA」の特性をもっている。
    • AWARE: 周囲の何らかの情報(位置、温度、動き、光量など)を検知することができる
    • AUTONOMOUS: デバイスからセンターに自動的にデータが送られる
    • ACTIONABLE: データは、よりよい決定を行うために使われる
  • IoTを担う無線技術がたくさんある。
  • IoTの展開における「食物連鎖」。
    バイル通信事業者 - チップセットの製造業者 - 組み込みモデム開発者 - デバイスの製造業者 - システムインテグレーター

IoTデバイスのテストの課題

  • テスト計画・テスト要件の決定
  • テスト計画の実装
  • テストのコスト
  • 無線通信のテストの専門家不在

IoTテストの段階

 テストの内容を、プロダクトのライフサイクルごとに考える必要がある。

初期のR&D/妥当性確認
  • RAT*2間ハンドオーバー
  • データのスループット: 最大データレート、リトライ
  • 電力消費: ドレイン電流、アプリケーション特有の要件
  • バイス内の共存: IoTデバイス内で起こる、複数の無線通信の共存と使用帯域の重複
  • パラメトリックテスト*3
標準準拠確認テスト

 標準に対する要件のほか、通信事業者の受け入れのための認証もある。

量産におけるテスト

 以下のような課題がある。

  • テストが限られるので、複数デバイスの同時テスト/測定などが必要
  • 適切なインタフェースがないために自動化が時に困難
  • OSが様々
  • チップセットのインタフェースが標準化されていない

所感

 無線ネットワークについては3日目の記事でも言及がありましたが、今回の資料はプロトコルよりよりハードウェアに近い部分に対するテストでした。そしてその範囲も、R&Dの段階から量産・サービスに至るまでを対象としており、これまでとはかなり色合いが違います。
 IoTのテスト自体の難しさ(たとえば複数の通信規格の混在状態)もありますが、IoTにかかわる主体が上流から下流まで多彩であること、求められるテストがライフサイクルによって様々であることが特に主張されている資料でした。

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

kzsuzuki.hatenablog.com

*1:Low Rate Wireless Personal Area Network

*2:Radio Access Technology

*3:通常parametic testingというと、統計の分布に1つ以上の仮定をおくことのようですが、ここでは無線に関係する各種の量を変化させて動作を確認することを指しているものと思われます

「性能テストのいろは: IoTにどうアプローチするか」 #IoTテストアドカレ(6)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Performance Testing 101: How to Approach the Internet of Things』
  • 著者: Henrik Rexed
  • 参照サイト: Neotys

ポイント

 IoTアプリケーションに対する負荷テスト・性能テストは、これまでのWebアプリケーション・モバイルアプリケーションと大きく違うわけではないが、理解しておくべき点はある。

  • 増大する複雑さ: 「モノ」や、それを操作するためのスマートフォンなど、考慮に入れるデバイスの数が異なる
  • モノからのメッセージの記録: Webやモバイルのように、メッセージを記録しやすい形になっているとは限らない
  • 様々な使用状況: ユーザのインターネットへの接続状態が大きな意味を持つ。帯域幅や遅延、パケットロス、同時接続数なども考慮要

 温度・電力量・メモリ使用量の変化といったシステムの統計を注意深くモニターすることと、異なるネットワークレイヤー間のレスポンスタイムを測定することも必要。そのさい、Wiresharkのようなネットワークスニファーツールが必要になる。記録することができれば、それを生成することも可能である。

 以下のように進めることになる。

  1. 対象のオブジェクトのSLAを明確にする。
  2. サーバに対し一度に接続してくることが予測されるオブジェクトの数を踏まえて最大負荷を決める。
  3. テストケースを作るために典型的なユースケースとそうでないユースケースを定義する。
  4. アプリケーションが特別なプロトコルを使用しているかを確認し、それらのプロトコルに対して迅速かつ容易に性能テストを行うことのできるテストツールを選ぶ。

所感

 これまでにはなかった、「性能」の観点での記事です。モバイルやWebと本質的には変わらないものの、デバイスの量に増加により複雑さが増していることと、プロトコルが特有であることに注意すべきとしています。
 デバイス-センサー間の近距離無線通信の方式については5日目の資料でも言及があったのですが、センサーから先のプロトコルについて意識していませんでした。知識が乏しすぎるので、一行紹介にとどめます。。

  • MQTT (Message Queuing Telemetry Transport): 本家によると、「M2MやIoTの接続プロトコル。メッセージ転送の受信・配信を行うために、きわめて軽量にデザインされている」。

  • XMPP (Extensible Messaging and Presence Protocol): Wikipediaによると、「オープンソースインスタントメッセンジャープロトコルおよび、クライアント、サーバの総称」。

  • DDS (Data Distribution Service?): Wikipediaによると、「スケーラブルでリアルタイム性があり、高信頼性・高性能で互換性のあるデータ交換を目的とした、OMG(Object Management Group)のM2M規格である」。

  • AMQP (Advanced Message Queuing Protocol): 本家によると、「アプリケーションや組織間でメッセージをやりとりするためのオープンな規格。システムを接続し、ビジネスプロセスに必要な情報を与え、目標を達成するための指示を伝える」。

  • CoAP (Constrained Application Protocol): 本家によると、「IoTにおいて制約のあるノード・ネットワークで使用されるWeb用転送プロトコル。スマートエナジーやビルディングオートメーションといったM2Mアプリケーションのために設計されている」。

 う、う~ん。抽象的でこれじゃ全然わからないですね。価値のない情報で申し訳もござらん。。。

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

kzsuzuki.hatenablog.com

「モノのインターネット セキュリティテストフレームワーク」 #IoTテストアドカレ(5)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

タイトル: 『Internet of Things (IoT) Security Testing Framework』
著者: ICSA Labs*1
参照サイト: ICSA Labs [pdf]

ポイント

 IoTのセキュリティは、デバイス単体で確保できるものではない。セキュリティ志向のIoTのテストを実行するため、具体的でテスト可能な要件のセットを開発するためのドキュメントを提供する。
 たとえば以下を定めている。

  1. 暗号化

  2. 通信

    • 認証、データ信頼性、データ完全性を提供するセキュアなプロトコル
    • 暗号化された認証メカニズム
  3. 認証

    • アドミン含む全ユーザに対する強力な認可
    • 認証のない権限の昇格に対する対応
  4. 物理的セキュリティ

    • 改竄の形跡を可視化するメカニズム
    • 内部コンポーネントへの未認証アクセスを防ぐメカニズム
  5. プラットフォームセキュリティ

    • セキュリティに関するコミュニティ内で知られた脆弱性への対応
    • 遠隔アップデートのメカニズム
  6. アラートとロギング

    • 改竄・攻撃を検知した際のアラート
    • 工場出荷状態にリセットされた際のアラート

所感

 ICSA Labでは、IoTのセキュリティに関する認証プログラムを提供しているとのことです。以下にインタビュー記事がありますが、認証プログラムが時に飯のタネビジネスに成り下がっていることを指摘し、実効性のある仕組みを作ろうとしていると主張しています。

www.darkreading.com

 元記事の内容としてはこれまでの記事と同様、インタフェースが多様さが従来のテスト対象と大きく異なるところでしすが、チェックすべきポイントががらりと変わっているわけではありません。似たり寄ったりなので、考慮事項はある整理しやすそうです。実装はともかく。

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

kzsuzuki.hatenablog.com

*1:Verizonの独立部門で、セキュリティに関する第三者テストや、プロダクトのコンプライアンス・信頼性・性能測定を提供する団体とのこと。

「モノのインターネット: 解き放たれたQA」 #IoTテストアドカレ(4)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

タイトル: 『The Internet of Things: QA Unleashed』
著者: Cognizant
参照サイト: Cognizant [pdf]

ポイント

 IoTを構成する要素は、センサーと組み込みソフトウェアを内蔵した「モノ」、モノが外部とやりとりをするための「通信」、各コンピュータによる「計算処理」の3つからなる。 IoTのテストにおいては、デバイスやセンサー単体でなく、技術的な複雑さを総合的に考える必要がある。

QAマネージャーが直面するであろう課題

  1. ハードウェアのQAとソフトウェアのQAの融合
     数百万のセンサー、多様なデバイス、知的なソフトウェアが共存するIoTでは、特定の環境でソフトウェアに限定した機能バリデーションだけでは不足。

  2. 動いているシステムだけでは不十分*1
     デバイスやソフトウェアさえそろっていればテストができるわけではない。複雑でリアルタイム性のあるシナリオ作りが大きな課題となる。

  3. 膨大な数のセンサーの相互作用
     妥当性確認を行うためのテスト環境構築自体に、卓越した知識が求められる。

IoTのテストの2つのレイヤー

  1. バイス相互作用レイヤー
    ハードウェアとソフトウェアがやり取りするレイヤー。機能テストに加えて、以下が必要になる。

    • 規格への準拠: ハードウェアベンダーによるテストだけでは不十分
    • 互換性: 多彩なデバイスをサポートする必要がある
    • セキュリティ: セキュリティとプライバシーは重大な課題
  2. ユーザ相互作用レイヤー
    「モノ」とユーザーが接するレイヤー。ユーザが途切れなくエクスペリエンスを得るために、以下が必要になる。

    • ネットワークの性能とデバイスのレベルのテスト: ネットワークの接続性や、デバイス側のバッテリーの状況など
    • ユーザビリティ・UX
    • IoTサービスとバックエンドの環境: システムの裏にある分析エンジンなどを含めた統合的なテスト

QA部門に必要となるフレームワークとソリューションの構築

  • プロトコルシミュレーター: IoTにおける多様なプロトコルを扱うのに便利
  • 膨大なデータのレコーダー: あるデバイスからのデータを、他のデバイスに対して流すことで互換性確認の助けに
  • 仮想化: IoTアプリケーションを動かすための仮想環境

QA部門がフォーカスすべきこと

  • 人々が能力を結集できるようにする
  • 統合テストを行うために協働するQAチームを作る
  • ツール開発の機会を探る
  • シミュレーションを行うためのラボを作る
  • 「ユーザとしてのテスト」というマインドを醸成する

所感

 他の記事では、デバイス側かユーザ側かのどちらかに話が寄っていることが多かったのですが、この記事では両方を扱っています。この2つでは、見る観点も必要な専門性も、違う点がかなりあると思います。また、分けるといっても最終的には統合的にテストすることが必要になるはずで、両者のQAがどう連携・情報共有していくかもカギになってきそうです。
 また、テスト特有の観点として、ユースケースの検討が出てきました。機能テストだけでも際限なくありそうなのに、それを使う場面をどのように洗い出していけばいいのか。これも大きな課題です。環境の準備の困難さも繰り返し語れれています。仮想化とシミュレーションがその助けになります。

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

kzsuzuki.hatenablog.com

*1:ちょっと解釈に自信がありません。