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

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

「脆弱なIoTデバイスのテスト」 #IoTテストアドカレ(13)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Testing for vulnerable IoT devices』
  • 著者: Michael Horowitz
  • 参照サイト: COMPUTERWORLD

ポイント

 XiongMai Technologies製の多くのビデオレコーダーやカメラが脆弱性を突かれてクラックされ、ボットネットに参加させられてDDoS攻撃を行うという事件があった。telnetSSHのパスワードはハードコードされており、変更ができない。
 この記事では、自宅やオフィスののIoTデバイスが安全かどうか、Steve Gibson氏のShieldsUp!というサービスを利用した簡易チェックを紹介する。

 telnet経由で不正なtelnet要求を受け付けないかを確認するには、以下をクリックする*1

h ttps://www.grc.com/x/portprobe=23

 画面遷移先で「Stealth」が出れば、telnetについては大丈夫。「Closed」もたぶん大丈夫だが、「Open」だとtelnetのポートが開いているということで、悪人からのコマンドを歓迎しているということになる。他のプロトコルについては、portprobeの値を変えればよい。

 より徹底したテストは、わたしのページで行うことができる。

所感

 今日の資料は打って変わって、簡単なポートセキュリティチェック、という内容です。ここでの「test」は、「ソフトウェアテスト」的なテストではなく、「確認」くらいの意味ですね。
 Steve Gibsonさんは、Security Now!というやたら長時間のソフトウェアセキュリティ系Podcastをやっていて一時聴いていましたが、いつも入眠剤替わりでした・・・。

www.grc.com

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

kzsuzuki.hatenablog.com

*1:ハイパーリンクなしです。自己責任でお願いします。

「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