「IoTのテスト：5つの大きな課題をどう乗り越えるか」 #IoTテストアドカレ(20)

はじめに

　この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の20日目です。19日目はコチラ。一体いつから・・・、アドベントカレンダーは12月25日に完結すると錯覚していた？

kzsuzuki.hatenablog.com

プロファイル

• タイトル: 『IoT testing: How to overcome 5 big challenges』
• 著者: TechBeacon
• 参照サイト: TechBeacon

ポイント

　IoTの時代には、効果的なテストが重要である。Iotデバイスのテストにおける考慮事項を述べる。

IoTプラットフォームが多い

　デバイスのハードウェアとソフトウェアが多彩すぎて、すべての組み合わせをテストすることはほとんど不可能。エンドユーザの情報を集め、どのデバイスとソフトウェアが使われているかを理解したうえで、最もよく使われる組み合わせを中心にテストする。

テストする通信プロトコルが多い

　現在のIoTデバイスでは、コントローラとやり取りするための様々な通信プロトコルを使っている。MQTT、XMPP、CoAPなどがよく使われており、それぞれ長所と短所がある。
　テスト設計は、IoTデバイスがどのようなプロトコル・APIを使っているかに依存する。テストツールはそれらを利用できるものでなければならない。

攻撃されるポイントとセキュリティ上の脅威が増える

　IoTデバイスの70%以上が、セキュリティ上の脆弱性を抱えているとされる。開発者やテスターは、パスワードポリシーをはじめとするセキュリティの問題にも注意を払う必要がある。

IoTアプリケーション、デバイスが多様になる

　テスターは、しっかりしたテスト戦略を持ち、アーキテクチャを理解し、デバイスとソフトウェアが適切なバージョンに設定されていることを確実にしておく必要がある。

　システムがサードパーティーのサービスを使っていれば、そのサービスの変更によりテストが失敗する可能性がある。サードパーティーのサービスが利用できない場合、サービスの仮想化を使うことで実際のサービスへの依存性を排除することができる。仮想化を行うツールがカスタマイズ可能なものであれば、様々な状況のレスポンスをテストできる。

データの高速化と負荷の増加が巨大になる

　WiFiチャネルの高負荷、信頼性の低いネットワークハードウェア、低速で一貫性のないインターネット接続など、ネットワーク状態は、デバイスの性能に重大な影響を持つ。様々なネットワーク条件でテストし、データを失うことなく適切なレスポンスができることを確認しなければならない。そのために、ソフトウェア的に様々なネットワーク状態をエミュレートするためのネットワーク仮想化を利用する。

　またテスト中は、CPU使用率やメモリ使用率のようなシステムのメトリクスをモニタする必要がある。ただIoTデバイスは、デスクトップアプリケーションのようにユーザの操作によって起動・テストされるとは限らないので、どのデバイスが利用されているのか、どのように振る舞うのかを把握する必要がある。

所感

　プラットフォームの組み合わせ、プロトコル、セキュリティ、性能など、これまでの資料でも言及されたポイントが整理されていてわかりやすいですね。

　21日目はコチラです。（いつの日か公開されます）

kzsuzuki.hatenablog.com

「モノのインターネットをテストする: ヒトの体験」 #IoTテストアドカレ(19)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

• タイトル: 『Testing the Internet of Things: The Human Experience 』
• 著者: Gerie Owen
• 参照サイト: InfoQ

ポイント

ユーザの理解

• IoTデバイスをテストするということは、人間のユーザを深く理解すること。人間との相互作用とテストしないと、品質の判断において重要な情報が欠くことになる。
• 「ヒトの体験」（human experience）というとユーザビリティが頭に浮かぶが、もっと深い。単なる見た目や使いやすさだけでなく、ユーザの感情的、物理的、知覚的な反応や、マインドセット、バイアスといった観点で、徹底的にテストする必要がある。
• デバイスを使用するうえでは多くの失敗が考えられるので、ネガティブなテストシナリオが、ポジティブなものより重要になる。非機能要件（-ability）のテストも重要。
• ヒトがデバイスに何を求めるのか、知見を集める必要がある。新しい種類のデバイスであれば、プロトタイプでユーザの反応を観察したり、デバイスに対する印象をインタビューしたりする。
• 現実世界におけるユーザのテストシナリオをどのように設計するか。「ヒトの体験」をテストする最も効果的な方法は、人間-コンピューター相互作用の設計原理を用いることである。

ペルソナ

• 「ペルソナ」は、潜在的なユーザのモデル。年齢、性別、家庭的な背景、教育レベル、職業、社会・経済的な状況、価値観、欲求といった特徴をすべてリストアップしたもの。場合によってはペルソナが動物の場合もある。
• ペルソナから、ユーザがデバイスに期待することを引き出し、それを元にテストシナリオを作る。

ユーザ価値ストーリー

• デバイスがどのようにユーザに価値をもたらすかを、「ユーザ価値ストーリー」に基づいてテストする。
  • たとえばマラソンの終盤という状況を考えて、「汗をかいている」「ゆるい上りが急坂に感じる」「群衆の声が聞こえてくる」といった状況で、ゴールの瞬間にスマートウォッチをクリックする・・・といったストーリーを記述していく。
• ペルソナとユーザ価値ストーリーに基づくテストシナリオは、物理的な期待、知覚的な期待、方向や地理に関する期待、状況に基づく期待や、バイアス、マインドセットもなどを含む。
• どんなデバイスにも複数のペルソナがあり、各ペルソナに複数のユーザ価値ストーリーがある。ペルソナとユーザ価値ストーリーを組み合わせるだけでも、多くの「ヒトの体験」シナリオが生み出される。シナリオの絞り込みのために、リスクベースドテストを使ってもよい。

所感

　IoTの中でも、人間と密接にやり取りするパーソナルデバイスを念頭においた記事。マラソンランナーとしての筆者が、自分の走りをスマートデバイスでモニター・記録していたにも関わらず、そのデータが大会側に反映されていなかったというエピソードをベースに、「ヒトの体験のテスト」についての説明をしてます。具体的で読みやすい内容でした。

　このカレンダーの前日の記事もシナリオテストに関するものでしたが、今日の資料は、ペルソナやユーザ価値ストーリーの導出の流れをわかりやすく説明してくれています。だいぶはしょっているので、ぜひ原文をお読みください。
　この中で言及されている「人間-コンピューター相互作用」については僕は知識が全然ないのですが、これから特に重要になってきそうな分野だと感じます。

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

kzsuzuki.hatenablog.com

「モノのインターネットのテスト」 #IoTテストアドカレ(18)

はじめに

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

kzsuzuki.hatenablog.com

プロファイル

• タイトル: 『Testing the Internet of Things』
• 著者: Test and Verification Solutions
• 参照サイト: Test and Verification Solutions (PDF)

ポイント

• 自律システムのソフトウェアのV&V*1には、英国のTSI*2によるPAS 754:2014という規格がある。この中で、Trustworthinessは以下の5つからなる。

  • 安全性（Safety）
  • 信頼性（Reliability）
  • 可用性（Availability）
  • レジリエンス（Resilience）
  • セキュリティ（Security）

• Trustworthinessの中でも特に、安全性とセキュリティが重要になってくる。
  安全性の規格には、たとえば以下のようなものがある。

  • IEC61508: 電気・電子・プログラマブル電子の機能安全に関する国際規格
  • DO178: 航空機搭載システム・設備のソフトウェア考慮事項に関する認証
  • EN50128: 鉄道制御・保護システムのソフトウェア
  • IEC60880: カテゴリーA機能を実行するためのコンピュータベースのシステムのソフトウェア面*3
  • IEC62304: 医療デバイスのソフトウェアとライフサイクルプロセス
  • ISO26262: 自動車の機能安全

• IoTデバイスは現在、ほとんどがセキュアでない。最初の攻撃はおそらく、もともと知られた方法（認証に対する攻撃、コードインジェクション、オーバーフローなど）で行われるだろう。新しい技術にはすぐに新しい攻撃が続き、新しい防御はその後になる。

• 防御策として、セキュアな設計やコーディングプラクティス、セキュリティのテスト、ネットワーク境界での防御、セキュアな技術・プロセス・人間などがある。
• IoTビジネスの参入障壁が低くなることで、セキュリティスキルの低い人間がたくさん参入してくることになる。脅威に対するアセスメント*4が重要である。

  所感

  　ほぼ、安全性とセキュリティに特化した内容です（スライド資料なので、単語の羅列がどうしても多いのですが）。規格がたくさんありますが、まずは自分の分野に関するものを押さえることですね。
  　セーフティとセキュリティについては、2017年1月13日に日科技連で「「IoT時代」のセーフティ&セキュリティbyデザイン ～アシュアランスケースとコモンクライテリア（ISO/IEC 15408）によるセキュリティの品質保証を考える」という長いタイトルの特別講義を行うみたいですよ。

  www.juse.or.jp

  　さて、最初に紹介されているPAS 754（Publicly Available Specification）という規格について、軽くググっただけでは日本語の資料が見当たりませんでした。
  　Wikipediaから引用（鈴木参考訳）してみます。

  The PAS defines the overall principles for effective software trustworthiness, and includes technical, physical, cultural and behavioral measures alongside effective leadership and governance. It also identifies the necessary tools, techniques and processes and addresses safety, reliability, availability, security and resilience issues.[2]
  PASは、効果的なソフトウェア信頼性のための全体的な原則を定義している。これには、効果的なリーダーシップとガバナンスとともに、技術的、物理的、文化的、そして行動的な対策を含む。また、必要なツール、技法、プロセスを特定し、安全性、信頼性、可用性、セキュリティ、レジリエンスの問題を扱う。

  　困ってしまうのは、Trustworthinessという言葉ですね。
  　まず信頼性といえば、Reliability。ISO/IEC25010の品質モデルにおける主特性である「信頼性」は、Reliabilityです。一方SQuBOKでは、副知識領域として「ディペンダビリティ」を紹介しています。JIS Z 8115:2000では

  ディペンダビリティは、Availability、Reliability、Maintenabilityを含む包括的な概念で、定性的な意味での総称として用いられる。

  としています。
  　で、PASにおけるTrustworthinessはReliabilityを含む、と。普通の英語では、ReliableもDependableもTrustworthyもそれほど変わらないようなのですが。また規格によってもそれぞれの言葉の位置づけが違ったりするようなので、注意が必要です。

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

  kzsuzuki.hatenablog.com

  *1:Verification and Validation: 検証と妥当性確認

  *2:Trustworthy Software Initiative

  *3:原子力発電所におけるセーフティレベルがA、ということのようです

  *4:ここでは、2日目の記事で紹介したOWASPがリンクされています。

kzsuzuki.hatenablog.com

「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