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

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

「IoTアプリケーションで自動テストをどう生かすか」 #IoTテストアドカレ(12)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『How Automation Testing can be Beneficial for IoT Application』
  • 著者: TechArcis
  • 参照サイト: TechArcis

ポイント

 自動テストは、IoTアプリケーション開発において最も便利で柔軟なアプローチと目されている。既存のアプリケーションやインタフェースの変更において、自動テストで以下のことを担保できる。

  • レスポンスタイムに問題がないこと
  • 複数のユーザが使用でき、分散環境にデプロイできること
  • インターネットを通して、あるいはローカルにデプロイできること
  • アプリケーションにおけるデータ検証が適切であること
  • リアルタイムデータが正確であること
  • 暗号化/複合化を通したアクセスコントロールされていること

 テスト自動化がIoT開発で必須である理由は以下。

  • IoTが、ITとWebサービス、そして従来の組込みシステムの複雑な合成であるため。テストも多彩でなければいけない。
  • 何でもすべてテストする必要があるため。センサーや温度計含めてすべてをテストするには、自動化が当然である。
  • 接続性とセキュリティが重要であるため。関係するプロトコルの幅が広く、サイバー犯罪の脅威に対応する方法に着目した、接続状態に関する様々なシナリオが必要である。

 IoTアプリケーション開発においては、自動化は選択肢ではなく必須のもの。
 システムの機能だけでなく、通常の使い方や普通でない使い方における、デバイスの信頼性や拡張性にも着目する必要がある。

所感

 これまでは自動化の話があまり出てこなかったのですが、ここにきてようやく重要性が言われ始めました。いくつかの記事でも触れられていましたが、組み込みからWeb/モバイルまでがつながることから、当然テスト観点も増加します。また加えて、考えられる組み合わせや状態も激増することから、自動化は必須なのでしょう。

 ただよく言われるように、価値のないテストケースを自動化したところで、価値はありません。テストを作る時点で適切なテスト計画・分析・設計が必要です。
 そうはいってもテスト設計、ましてはテスト分析はよくわからない・・・。そんなあなた(わたし)のために、テスト分析に関する勉強会が企画されています! これを勉強のキッカケにしてみてはいかがでしょうか!?

connpass.com

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

kzsuzuki.hatenablog.com

「IoTのテストでは何が変わっているのか」 #IoTテストアドカレ(11)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『How Testing for the Internet of Things (IOT) is it different?』
  • 著者: Sunil Sehgal
  • 参照サイト: LinkedIn

ポイント

  • IoTとは「内外の環境と通信し、知的な決定を行うためのセンサーあるい組み込みテクノロジーを内蔵した、物理的なモノのネットワーク」(Gartner)。
  • IoTをプロダクトを「スマート」にしている要素は以下の4つ。

    • 無線通信
    • センシング
    • 個体識別性
    • 内蔵エレクトロニクス
  • IoTのテストは、帯域、接続の品質、ネットワークからの切断など、インターネットへの接続性に関する様々な側面を確認するプロセス。ネットワークを流れるビッグデータがさらに複雑さを増加させている。IoTに対するテスト計画で考慮すべき点は以下。

    • ユーザビリティ・UX: 機能を把握し、使い方を理解できること。
    • 接続性: たとえば電力供給が断たれてもデータが失われず、復旧後に正しく配信できること。
    • セキュリティ: セキュリティ上の問題に対し、IoTデバイスは脆弱。
    • 相互接続性: 様々なデバイスが、デバイス間あるいは外部のデバイス間で機能をサポートできること。
    • 互換性: 様々な構成での動作、プロトコルやプロダクトのバージョンの上位/下位互換性。
    • 性能: ネットワーク通信と内部計算の性能。
    • 自動化: 現時点では、直観に基づいてテストするために手動テストが重要な役割を担っている。
  • 多彩なIoTサービスに対し、テストインフラへの依存性を軽減するため、サービスの仮想化がカギ。未完成のコンポーネントのふるまいをエミュレートできるような仮想化を行う。

  • 従来のテストのアプローチでは不十分。「顧客によるテスト」がキー。テストプロセスを顧客のニーズに合わせてテーラリングする。

所感

 ここ数日の資料と違って、無線通信の規格の話はありませんでした。おそらくここでは、規格認証は通っている前提なのでしょう。
 ちょっと意外だったのは、IoTのテストにおいて手動テストが重要とされている点です。もちろん上述のような規格準拠のテストやセキュリティ周りのテストは専用の自動テストツールが必要ですが、それは通過した前提で、その後のエンドユーザによるテスト(Test by Customer)により重きをおいています。シナリオテストや探索的テストといった技法・アプローチが、このあたりでは重要になってくるのでしょう。

 なお、繰り返し引用されているGartnerの予測については、コチラがおそらく元ネタですね。

www.gartner.com

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

kzsuzuki.hatenablog.com

「IoTデバイスをテストする能力」 #IoTテストアドカレ(10)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の10日目です。二けた目突入したよ! 9日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『The power of testing IoT devices』
  • 著者: Rohde & Schwarz
  • 参照サイト: Rohde & Schwarz

ポイント

 ワイヤレスなIoTデバイスにおいて鍵となるのは、正確な機能性、プロダクト利用期間における品質、そして性能である。IoTデバイスが普及し、ビジネスや個人生活により大きな影響を与えるようになると、それらへの期待も高くなる。  

ネットワーク接続性

 アプリケーションによってはグローバルなカバレッジ*1が必要で、LTE-MやNB-IoTといったセルラー*2の通信技術にフォーカスすることになる。 一方、多くのデバイスは、非セルラー系のワイヤレス技術(BluetoothWi-FiZigBee、THREAD、EnOcean、SIGFOX、LoRaなど)を用いる。
 複数のワイヤレス技術が共存しうることも含めて、IoTデバイスの通信の全体的なふるまいをテストすることが重要。「スマートメーターが地下にある」「モデムが高速移動する車の中にある」といったテストの条件や、「電池が10年以上もつ」といった要件から、設計の妥当性を確認しなければならない。

規格への準拠

 ワイヤレスデバイスでは、「適用される規格に準拠しているか」「事業者特有の要件に合致しているか」をテストする必要がある。

  • セルラー系のデバイス: GCFの要件への準拠。3GPPが定義したMTC機能に特化したテストを含む。
  • セルラー系のデバイス: ETSIやFCCが定義した規制の要件や、Bluetooth SIGやLoRa Allianceなどが定義した規格の要件を満たす必要がある。

 ワイヤレス技術のテストはこのように非常に複雑で、時間も食うしコストもかかる。Rohde & Schwarzは主要なセルラー系・非セルラー系の技術のテストおよび計測をカバーしてお...(続きを読む)

所感

 7日目の記事と出展が同じですね。通信方式と遵守すべき規格が山ほどあり、複雑きわまりないよという話とともに、「そこで弊社です!」的なトークに移っていく素直さに好感がもてます。でも確かに、ノウハウなしでこの世界に飛び込んでいくのは、玉砕ルートしかなさそうですね。

 略語がたくさん出てきたので、一部を確認しておきます。言葉を調べてメモしているだけですが。

LTE-MとNB-IoT

 こちらに2つの方式の説明がありますが、冒頭の文章から日本語率が低くてさわやかです。

LTEをベースとしたLPWAの主要方式には、NB-IoTとLTE-Mの2つがある。

 WikipediaによるとLPWAは「Low Power, Wide Area」の略で、Bluetoothなどの近距離無線(〜数十m程度)では満たせないカバレッジの無線の分類」だそうです。これまでの資料にも出てきたLoRa、SIGFOXなどはこのLPWAに分類されています。これらが免許不要のISMバンドを利用した特定小電力無線である一方、LTE-MとNB-IoTは免許が必要なバンドを使う技術です。すみません、この辺で勘弁してください。こちらに詳しい説明がありました。

wirelesswire.jp

 また無線通信規格全般について、Qiitaの以下の記事で最近の動向が説明されていました。こういう価値のある記事を読んでしまうと、我が身を振り返って泣きたくなってしまいますが。

qiita.com

GCF (Global Certification Forum)

 本家サイトによると、「GCFの認証は、製造業者が最新のスマートフォン、ハンドセット、ワイヤレスデバイスが世界のモバイルネットワークで正しく動作することを担保するためのもの」としています。NTTドコモ開示している資料によると、GCF認証試験として以下の2つがあるようです。

  • GCF Conformance Test: 端末が仕様準拠であるかのチェック(端末とシミュレータとの対向試験)
  • GCF Field Trial: 端末が複数オペレータNWとの相互接続性があるかのチェック
MTC (machine type communications)

 エリクソン・ジャパンの記事に読む限り、M2M通信と称しているものと本質的な違いはないようですが、「必ずしも人間の介入を必要としないデータ通信の一形態」と定義されているとのことです。

 とにかく無線ネットワーク規格の知識のなさが命取りになりそうです。

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

kzsuzuki.hatenablog.com

*1:ネットワーク通信のカバレッジのことだと思います。

*2:バイル通信のために通信事業者が提供しているネットワークの技術、という意味です。

「IoTテストでより賢く」 #IoTテストアドカレ(9)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Getting Smarter at IoT Testing: National Instruments』
  • 著者: Eric Starkloff
  • 参照サイト: RT Insights.com

ポイント

 急速に広がるIoTとそのデバイスにおいて、鍵となる安全性・信頼性を守るのはテストエンジニアである。デバイスの進化と物量に追随して、費用対効果の高いテストを行うには、従来の自動テストでは不十分。

 スマートなIoTデバイスのために、自動化されたスマートなテスト環境*1が必要。
 プラットフォームベースアプローチ(platform-based approach)は、構成要素同士が相互接続性を持つ柔軟なハードウェアアーキテクチャから成る単一のテスト環境上に、多数のアプリケーションの配置するもの。テスト環境のハードウェア・ソフトウェアではなく、テスト対象であるアプリケーション自体のイノベーションにフォーカスできるようにする。

 デバイスの多くの問題は、ソフトウェアの問題に置き換えることができる。

  • 飛行機内での電子機器の操作は、「機内モード」の実装により許容された。
  • Teslaは、自社の自動車にハードウェア的な問題があった際、無線でソフトウェアアップデートすることで対応した。

 同じようにテスト環境も、その時点の課題だけでなく将来の要求にも適応できるように、ソフトウェアデファインドでインテリジェントなものにする必要がある。

所感

 元記事も短いものですが、要約したらものすごく短くなってしまいました。
 これまでの資料では、自動テストについての言及は意外なほど少なかった。この資料では、テスト実行の自動化はもとより、テスト環境の自動化とスマートさ・柔軟さが重要だとしています。次々と出てくるアプリケーションごとに、そのアプリケーションにしか使えないテスト環境を準備するのは現実的でない。ソフトウェアデファインドで柔軟に構成変更のできるテストベッドを持つことが必要だということですね。

 この資料の中で言及されたTeslaのワイヤレスアップデートについては、以下などが参考になります。

www.huffingtonpost.jp

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

kzsuzuki.hatenablog.com

*1:Test Eqiopment

「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の意味を失ってしまうため、ここでは「コネクテッドな」という表現に逃げています。