「IoTと、テストへのインパクト」 #IoTテストアドカレ(17)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

• タイトル: 『IoT and it's Impact on Testing』
• 著者: Bob Crews, President and Co-founder of Checkpoint Technologies
• 参照サイト: Zephyr

ポイント

IoTデバイスとそのテストの特徴

• Dr. John Barrettによると、IoTデバイスが備えている特徴は以下。
  • ユニークな識別子
  • ワイヤレス通信
  • センシングや測定を行う能力
  • 組み込みエレクトロニクス
• モバイルデバイスのテストでは、タッチスクリーンでのジェスチャーや位置情報の検知といった、新しい考慮事項が加わった。スマートデバイスでは、センサーからの入力を考慮する必要がある。たとえばフィットネスデバイスであれば、脈拍、体温、位置、標高、運動の様子など。
• デバイスは、収集したデータを人間が見られるようにしたり、モバイル機器と同期したり、クラウドにデータを送ったりする。どんな状況でも装着できることを確認するには、複雑なテストが必要になる。

テストケースの例*1

　以下のようなテストケースの例を考えてみる。

テストケース名: ヘルスフィットネスデバイス v3.2の、氷点下における、3時間の高い活動レベルでの使用
テストケースの目的: センサー機能と、長時間（3時間）の高い活動レベル（ジョギング・ランニング）を通したデータ読み取りの正確さを、氷点下（摂氏0度以下）で確認する。
テスト対象: デバイスは以下のようなモデルに合わせてプログラムされている。

• 性別: 男性
• 体重: 84Kg
• 身長: 183cm

テストステップ

• ステップ#1

  • アクション: プログラム済みのデバイスをテスト対象の腕に正しく装着し、デバイスが露出している（衣服に覆われていない）ことと、確実なモニターのために肌に接していることを確認する。
  • 期待結果: なし

• ステップ#2
  （以下省略）

• ネットワークへの接続がまばらで、位置の特定も不完全な、雑多な現実世界でのシナリオでテストを行う必要がある。
• ユーザエクスペリエンスへの配慮が必要。文字の大きさや明るさは、夜にジョギングするユーザにとって十分か？ 着けたまま寝るユーザにとってまぶしすぎないか？
• いろいろな人を採用してくる必要がある。選任のランナー、その人の体温や脈拍を測る人・・・。
• 自動化は重要であるが、スマートデバイスのテストでは効果が小さくなるかもしれない。環境をシミュレートしたり、「走る」といった物理的なイベントを自動化したりするのは、ブラウザの操作よりはるかに難しい。また、法規制のある業界（たとえば医療）では、現実世界におけるテスト以外は受け入れられないかもしれない。

QAはどう変わっていくのか

• テストプロセスにおいて、計画と管理が今後さらに重要になり、QAのロールも変わっていく。
  • テストのニーズの把握
  • テストの検討
  • テストに必要な人の検討、調整
  • テストの結果の分析、対策の管理
  • テストに関する情報の管理と関連付け（テストリリース、テストサイクル、テスト要求、テストケース、テストスクリプト、テストセット、テスト実行、欠陥、・・・）
• IoTにおいては、多彩なデバイス・ハードウェア・OS、多数のユーザ、多くのデプロイツール、リリースツールなど選択肢が極めて多い。圧倒的な数の組み合わせのテストを管理できるようにする必要がある。

所感

　これまでの資料の中では珍しく、パーソナルユースのIoTデバイスを例にとった記事でした。規格、ワイヤレスプトロコル、セキュリティといった、他の記事で声高に主張されてきたポイントにはほとんど触れず、テストの最終工程に近いところに注目した記事です。ですので、これまで有効とされてきた自動化の力も弱くなっています。現実世界における実際のユーザによるテストにおいては、自動化できる範囲がどうしても限られるからでしょう。

　一方、この工程でのテストにおいては、テストシナリオ*2が重要になってきます。
　秋山浩一さんの『ソフトウェアテスト技法ドリル』において、シナリオテストは、「さまざまな視点を織り込んだシナリオを描いてそれをテストするという方法」と説明されています。そして「シナリオに闇雲にテストの支店を入れ込むとマトリクスになってしま」うため、以下の制約を設けるとしています。

1. 人の動きを中心にシナリオを作成する: ある人が抱えている問題がソフトウェアを使用することで解決することを確認する
2. 狭く深くシナリオを書く: 広く浅くはそれ以前のテストで確認済みのはずなので、問題の出そうなところや重要な部分を確認する

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

　数学や論理に基づくテスト技法と比べて、「正解」の難しいテストと言えるでしょう。
　シナリオテストを導出するための標準的な技法は、これ以外あまり見たことがありません。たとえば鈴木三紀夫さんの2016年12月16日の一連のツイート（たとえば以下）が参考になりそうですが、「業務」とはまた違うんですよね・・・。

2011年のときの業務シナリオテストの説明って、こういうのだったの。
「業務シナリオテストのテスト設計は、ホワイトボックステスト的なものと、ブラックボックステスト的なものがある。
業務フローを使って制御フローパステスト。シナリオ構成要素を組み合わせて、組み合わせテスト。以上」

— 鈴木三紀夫 (@mkoszk) December 16, 2016

　結局、勉強しないといけないことがまた増えていくわけですね！

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

kzsuzuki.hatenablog.com

*1:※テストのステップについては、一部だけ紹介しています。ぜひ原文をご覧になってください。

*2:「テストシナリオ」「テストシナリオ」という言葉はあまりに曖昧ですが、ここではサンプルとして示されたテストケースのようなものを意図しています。

「IoTにおける自動テスト」 #IoTテストアドカレ(16)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

• タイトル: 『Automated Testing for the Internet of Things』
• 著者: Vassili van der Mersch
• 参照サイト: NORDIC APIS

ポイント

IoTプロダクトの開発

• 組み込みシステムが本質的に自己完結的で、個別に動作することができたのに対し、IoTではネットワークに接続されたオブジェクトが互いにコミュニケーションする必要がある。
• 無線ネットワークを通じたファームウェアアップデートは、ハードウェアプロダクトの陳腐化のスピードを下げることになった。プロダクトをリリースした後に、新しい機能を追加することもできる。ただし、十分なバージョン管理とテストが必要である。
• 組み込みソフトウェアには以下のような特徴があり、IoTプロダクトもその課題を引き継ぐことがある。
  • プログラマブルな電子デバイスの安全性・信頼性を担保するために、IEC 61508やMISRAなどの規制上の要求事項にも従う必要がある。
  • プログラミング言語として、CやC++が使用される。性能面では利があるが、プログラミングのリードタイムが長く、明示的なメモリ管理が必要。移植性に欠けるので、開発環境と実環境でクロスコンパイルが必要になる。
  • Webアプリケーションやモバイルアプリケーションの開発においては、継続的インテグレーション（CI）が成熟しており、テスト駆動開発も支持されている。一方組み込みソフトウェアでは、モノリシックなレガシーコードに依存性をもっていることがしばしばで、CIの原則を後から持ち込むことが難しい。
  • ハードウェアが入ってくると、アジャイル開発にも別のやり方が求められる。たとえば、前のイテレーションにおける成果を捨てるというのは、ソフトウェアと比べてコストが高い。
• IoTプロダクトのテストには、以下のような難しさがある。
  • IoTではサブシステムの所有者が様々であることがある。テストに必要なサブシステムや、依存性のあるコンポーネントが揃っているとは限らない。
  • 天気の状態、大気圧といった、現実世界の網羅的なテストデータを手に入れることが難しい。
  • ネットワーク帯域の制約、電池の故障、電波の干渉などを中心とした非機能要件が難しい。

対応方法

• 慣れたアーキテクチャを選択する（たとえばOSをLinuxのみとする、など）ことで、テスト計画において当て推量に頼らざるを得なかった範囲を絞る。
• ハードウェアからプログラミングロジックから分離することで、テストを容易にする。
• 実世界におけるユーザの入力データや環境のデータを記録しておき、テスト環境で再生することで、テストデータの品質を保つ。
• 規制や標準に対する準拠のテストは、静的解析ツールによる自動化を行う。

ハードウェアのシミュレーション

　ハードウェアのシミュレートすることで環境の一部の抽象化し、ハードウェア特性に関するテストを加速することができる。シミュレータは高度化しており、たとえば以下のような機能をサポートしている。

• パフォーマンスとメモリのテスト
• セキュリティテスト
• エッジケースのテスト
• フォールトインジェクション: ネットワーク接続状態の低下や、センサデータにノイズを発生させる電磁気的な干渉など。

「ハードウェアラボ」は、モデル・コンダクター・ハードウェアのデザインパターンに従う。

• モデル: システムを支える抽象ロジックを定義し、システムの状態を保持し、外部にAPIを提供する。
• コンダクター: ステートレスなコンポーネントで、モデルとハードウェアの間の双方向のやりとりを連携させる。
• ハードウェア: 物理的なハードウェアをラップする。コンダクターとのコミュニケーションによって、イベントを発生させたりイベントに反応したりする。

　しかしシミュレーションは完全でなく、特に人間との相互作用についてのテストは難しいため、実際のハードウェアを使用した最後の品質保証プロセスは依然として必要である。

所感

　組み込みテストの課題をそのまま引き継いだうえに、新たな難しさも増えているのがIoTのテストです。 　ハードウェアラボの「MCHデザインパターン」というのは初めて聞いたのですが、たとえば以下に情報があります。そのまんま、「ハードウェアとロジックの分離」という節です。

www.methodsandtools.com

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

kzsuzuki.hatenablog.com

「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 奇跡の“ワトソン”プロジェクト: 人工知能はクイズ王の夢をみる

　ジョージ・ワシントンとは初代大統領か橋の名前か―そんな識別は、人間にとってどうということはない。文脈からおのずとわかる。橋は就任演説などしないし、ラッシュアワーに大統領で渋滞が起こってて、ニュージャージーからの通勤に三十分の遅れが出るなどということもない。何より、センテンス中に置かれたとき、人間と道路や橋とでは振る舞い方が違う。
　だが、人間にとって簡単なことが、コンピュータには困難きわまりない。まず、質問の構造を調べて主語と目的語と前置詞を拾い出し、次いで、業界内に何十年にもわたって創り上げられてきた網羅的な参照リストにあたる。ここには何十万という場所・物・動作と、それらの間に網の目のように張り巡らされた関係が記されている。このリストの一つ一つを「オントロジー」と呼ぶ。いわば、コンピュータのカンニングペーパーだ。たとえば 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攻撃を行うという事件があった。telnetやSSHのパスワードはハードコードされており、変更ができない。
　この記事では、自宅やオフィスのの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:ハイパーリンクなしです。自己責任でお願いします。