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

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

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

IoT

はじめに

　この記事は、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のテストに関するネットの記事を読んでいく、「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のテストに関するネットの記事を読んでいく、「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のテストに関するネットの記事を読んでいく、「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:ちょっと解釈に自信がありません。

「IoTテスティングの将来」 #IoTテストアドカレ(3)

IoT

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

タイトル: 『The future of IoT testing』
著者: Francis Adanza
参照サイト: zephyr

ポイント

　2000年代後半のモバイルの勃興のときと同様に、ソフトウェアテスターはスキルの幅を広げることを求められるとしています。モバイルの時は、従来は意識しなかったようなバッテリーの状態、ネットワークの状態や帯域幅という要素を考慮に入れることになりました。
　この資料では、IoTのテスターが直面するかもしれないテーマを4つあげています。

  1. 無線ネットワークの接続性に関するシナリオ *1
    　ネットワークが切れたときに何が起こるのか、データは保全されるのか、ネットワークが戻ったらサービスは再開できるのか・・・。

  2. スマートハウス*2のシミュレーションのためのサービス仮想化
    　ホームオートメーションが広まっていくにつれ、家の種類・構造・レイアウトといった情報をモデル化し、実際に起こるであろう条件を仮想的に再現してテストすることが必要になりそう。

  3. IoTのセキュリティ
    　IoTのプロダクト・サービスの潜在的な脆弱性について、全範囲をくまなく調べる必要がある。

  4. 広範囲に渡るインタフェースのテスト
    　あるサービスに対してユーザインタフェースとなるデバイスが多彩なので、どのデバイスのテストに力を入れるべきかを決定するために、ユーザの利用方法の分析が役立つだろう。

所感

　この記事では、スマートハウスをIoTの主要なプロダクトと捉えているようです。
　3つ目と4つ目は2日目の記事と重複していますね。インタフェースが多彩になること、それゆえ攻撃を受ける箇所も増えていること。プライバシーとセキュリティは一大テーマです。また、1つ目について、モバイルには出てこなかったような短距離・低電力型の無線ネットワークとその状態も、大きなテーマですね。

　4日目はコチラです。（12月4日の0時に公開されます）

kzsuzuki.hatenablog.com

*1:これは従来のモバイルでも意識していたものでしょうが、IoTで使用する無線ネットワークは、セルラーネットワークやWi-Fiに限りません。この資料では、BluetoothやZigBeeが挙げられていますが、他にもLoRA、SigFox、ANT+といった通信方式があるようです。

*2:ホームオートメーションの規格や団体が複数存在し、熾烈な争いを繰り広げている状態のようです。Google系ではNestが、Apple系ではHomeKitを提案しています。