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

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

「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

「なぜIoTのテストが問題になるのか」 #IoTテストアドカレ(14)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Why Internet of Things (IoT) Software Testing Matters』
  • 著者: Parasoft
  • 参照サイト: Parasoft

ポイント

  • スマートホームにしろ、交通システムにしろ、IoTシステムは多くのコンポーネントが1つのシステムとして動作する。複雑な相互作用のシミュレート、個々のコンポーネントの複製、機能/非機能要件のテストは非常に難しい。システムの外で起こったことによるエラーをハンドリングできるか、シナリオを立ててテストする必要がある。
  • IoT環境は公共のネットワークを通して接続されるため、デバイスのメーカーのコントロールを超える。
    • セキュリティ: ソフトウェア自体が安全でも、ネットワークが攻撃にさらされるかもしれない。
    • 信頼性: ソフトウェアに柔軟性があっても、ネットワークの可用性がコントロール外である。
    • 規模 : 内部インフラの規模はコントロールできても、公共のネットワークはそうではない。
  • IoTは、システムオブシステムズ。たとえばコネクテッドカーはそれ自体が部品の塊だが、IoT環境では1つのコンポーネントとみなされる。
    このようなシステムでは、テストのレイヤーが「独立したコンポーネント「サブシステムの中におけるコンポーネント「より大きなシステムの中におけるコンポーネントと分かれる。
  • IoTシステムは、セーフティクリティカルシステムの故障個所になりうる。各コンポーネントに対するリスク評価が必要。
    ここでのリスクには、コンポーネントの故障についてのリスク」「故障からの復旧についてのリスク」の2つの側面がある。たとえば飛行機でも、機械的な部分の故障は何とかカバーできるかもしれないが、フライトコントロールシステムが壊れてしまえば復旧できない可能性がある。

所感

 短い資料ですが、システムオブシステムズの考えに基づくテストのレイヤーと、リスク評価はこれまであまりなかったトピックですね。
 システムオブシステムズやセーフティクリティカルシステムについては、JSQTBのお勉強の時の過去記事がありましたので、ご参考まで。

kzsuzuki.hatenablog.com

 リスク評価は、システム内のデバイスや状態の数、インタフェースの数、想定されるシナリオの無数さを考えると、テストにおいてどうしても必要になってくるものと思います。SIL(Safety Integrity Level)、および機能安全のこともよく知らないので、併せて学んでいく必要があるでしょう。

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

kzsuzuki.hatenablog.com

「脆弱な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